UNIT 1 –

Short Answer Questions (5 marks each)

1. Discuss the advantages of the Spiral Model over the Waterfall Model.

The Spiral Model, proposed by Barry Boehm, improves significantly on the rigid, linear nature of the
Waterfall Model. The major advantages are:

1. Risk Management is Integral

Risk analysis is performed in every phase of Spiral. High-risk areas (e.g., unclear requirements, new
technology) are identified early. This makes Spiral suitable for large, complex, mission-critical
projects.

Waterfall has no structured risk handling, making it dangerous for uncertain projects.

2. Iterative & Evolutionary

Spiral is inherently iterative. The product evolves through multiple spirals (cycles), and each iteration
ends with a working prototype or deliverable.

Waterfall is non-iterative—after a phase is completed, it cannot be revisited easily.

3. Continuous Customer Feedback

Each loop involves customer evaluation. This leads to:

• Better alignment with requirements

• Early detection of misunderstandings

• Improved customer satisfaction

In contrast, Waterfall only involves the customer at the beginning and end.

4. Accommodates Changing Requirements

Spiral naturally welcomes requirement changes during development, making it suitable for:

• R&D projects

• Innovation-heavy systems

• Projects with evolving needs

Waterfall assumes requirements are fixed, which is unrealistic in modern software development.

5. Early Prototyping

Spiral encourages prototyping during early iterations, helping clarify requirements, user
expectations, and interface behavior.

Waterfall typically produces a prototype late, if at all.

6. Better Project Control

Spiral allows:

• Frequent progress evaluations

 • Cost and schedule refinement

• Early error detection

Waterfall delays integration and testing until the end, leading to late discovery of issues.

2. Short notes on Feasibility Study and its Types.

Feasibility Study – Definition

A Feasibility Study assesses whether a proposed software project is:

• Technically possible

• Economically viable

• Operationally acceptable

• Legally compliant

• Possible within time constraints

It determines if the project should proceed.

Types of Feasibility

1. Technical Feasibility

Assesses whether the organization has:

• Required technology

• Hardware/software tools

• Technical expertise

• Support infrastructure
Example: Does the team know machine learning if the system requires it?

2. Economic Feasibility (Cost–Benefit Analysis)

Determines if the project is financially viable.

Includes:

• Development cost

• Operational cost

• Maintenance cost

• Tangible & intangible benefits

Uses ROI, NPV, payback period.

3. Operational Feasibility

Evaluates:

• Whether users accept the system

 • Whether the system fits current workflows

• Whether management supports the project

Example: A complex system that employees refuse to use is operationally unfeasible.

4. Schedule Feasibility

Determines whether the project can be completed within:

• Deadlines

• Time constraints

• Customer expectations

If the timeline is unrealistic, the project becomes risky.

5. Legal Feasibility

Ensures compliance with:

• Cyber laws

• Data protection regulations

• Copyrights, patents

• Industry standards

Example: Storing customer data must comply with privacy laws.

3. Discuss the Basic COCOMO Model in detail.

The Basic COCOMO (Constructive Cost Model) is a software cost estimation model created by Barry
Boehm.

Purpose

To estimate:

• Effort (person-months)

• Time (months)

• People required

Based on the size of software measured in KLOC (thousand lines of code).

Basic COCOMO Formula

1. Effort (E):

𝐸 = 𝑎 × (KLOC)𝑏 (person-months)

2. Development Time (T):

𝑇 = 𝑐 × (𝐸)𝑑 (months)
 PEOPLE=EFFORT/TIME
3. Staffing Requirement:
𝐸
People =
𝑇

COCOMO Project Categories

Type Description Examples Constants (a, b, c, d)

Small, simple projects with a=2.4, b=1.05, c=2.5,

Organic Payroll systems
experienced teams d=0.38

Semi- Compilers, real-time a=3.0, b=1.12, c=2.5,

Medium complexity, mixed teams
Detached DB d=0.35

a=3.6, b=1.20, c=2.5,

Embedded High complexity, stringent constraints Air-traffic control
d=0.32

Characteristics of Basic COCOMO

• Best suited for early project estimation

• Simple and quick

• Less accurate than Intermediate and Detailed COCOMO because it lacks cost drivers

Long Answer Questions (15 marks each)

4. Explain the Spiral Model in detail (software life cycle model that incorporates risk).

Introduction

The Spiral Model, developed by Barry Boehm (1986), is a risk-driven software development model
combining:

• Iterative development

• Prototyping

• Risk analysis

• Customer involvement

It is shaped like a spiral, with each loop representing a development phase.

Structure of the Spiral Model

Each loop of the spiral consists of four main phases:

1. Determining Objectives, Alternatives, and Constraints

• Identify goals for the iteration

 • Explore alternative solutions

• Identify constraints (cost, regulations, technology limitations)

2. Risk Identification and Analysis

This is the core of the model.

Activities:

• Identify all potential risks (technical, managerial, operational)

• Analyze risks quantitatively and qualitatively

• Develop mitigation strategies

• Build prototypes to reduce uncertainty

Example:
A new UI design is prototyped before committing to full development.

3. Development & Engineering

Depending on the iteration:

• Design

• Coding

• Integration

• Testing

• Refinement of prototypes

Early iterations may only develop mockups; later iterations produce full modules.

4. Customer Evaluation & Planning for Next Iteration

• Present deliverables to customer

• Gather feedback

• Decide whether to continue, modify, or cancel the project

• Plan next loop (resource allocation, schedule updates)

Advantages

• Excellent for large, complex, risky projects

• Strong customer involvement

• Flexibility in requirements

• Early detection of errors

• Continuous risk evaluation

• Produces early versions of the system via prototypes

Disadvantages
 • Expensive due to repeated evaluations

• Requires skilled risk analysts

• Not ideal for small projects

• Hard to manage many iterations

Applications

Used in:

• Military projects

• Banking systems

• High-budget government systems

• Mission-critical embedded systems

5. What is an Agile Process? List the Manifesto for Agile Software Development.

Agile Process – Definition

Agile is a lightweight, adaptable, iterative methodology for software development aimed at:

• Rapid and continuous delivery of working software

• Close customer collaboration

• Flexibility to accommodate changing requirements

• Improved communication and teamwork

Agile methods include: Scrum, XP, Kanban, Crystal, FDD.

Characteristics of Agile

• Incremental delivery

• Time-boxed iterations (sprints)

• Continuous integration and testing

• Self-organizing teams

• Minimal documentation but high functionality

• Frequent customer involvement

UNIT 2 – SYSTEM DESIGN & MODELING (FULL DETAILED ANSWERS)

Short Answer Questions (5 marks each)

6. What is a Data Dictionary? Why is it used? Give an example.

Definition

A Data Dictionary is a centralized repository that stores detailed descriptions of all data items used in
a system, including:
avoids data redundancy
• Data names promotes consistency

improves communication
• Types

• Sizes

• Allowed values

• Relationships

• Sources and destinations

It serves as a reference guide for analysts, designers, and developers.

Why It Is Used

1. Avoids data redundancy – ensures each data element is defined once.

2. Promotes consistency – all team members use the same data definitions.

3. Improves communication – analysts, designers, testers understand data clearly.

4. Supports DFD and database design – ensures accurate modeling.

5. Assists validation – ensures inputs and outputs are correct.

Example (Data Dictionary Entry)

Element Name: Student_ID

Description: Unique identification number assigned to each student
Type: Integer
Length: 6 digits
Range: 100000–999999
Source: Registration Form
Destination: Student Database, Fee Module

Such tables are repeated for every data element used in the system.

7. Differentiate between Physical and Logical Data Flow Diagrams.

Logical DFD Physical DFD

Shows what the system must do Shows how the system will be implemented

Focuses on business functions and

Focuses on hardware, software, files, and people
information flow

Technology-independent Technology-dependent

Used in system analysis Used in system design

Logical DFD Physical DFD

Shows processes like “Operator inputs data using

Shows processes like “Validate Customer”
terminal”

Shows data stores conceptually Shows actual files/databases

Example difference:

• Logical: “Process Payment”

• Physical: “POS Terminal sends payment data to SQL Server database via API”

Long Answer Questions (15 marks each)

8. Draw Context Level and Level 1 DFD for a given system (Example: Library System).

Since diagrams cannot be drawn directly, I will describe them exactly as you should draw in your
exam.

A. Context Level DFD (Level 0)

System: Library Management System

Entities:

• Student

• Librarian

Main Process:
0. Library Management System

Data Flows:

• Student → Book Request → System

• System → Issue Status / Due Date → Student

• Librarian → Book Update Information → System

• System → Reports → Librarian

Data Stores: Not shown at Level 0.

B. Level 1 DFD

Break the main process into sub-processes:

1. 1.0 Manage Books

2. 2.0 Manage Members

3. 3.0 Issue Books

4. 4.0 Return Books

Data Stores:

• D1: Book Database

• D2: Member Database

• D3: Transaction Database

Flow Explanation:

• Student sends Book Request → 3.0 Issue Books

• Issue Books checks Member Database and Book Database

• Issue Books updates Transaction Database

• Return Books updates Transaction Database and Book Database

• Librarian updates Book Database through Manage Books

Use arrows to show these flows.

9. What is a Structure Chart? Draw one for any DFD.

Definition

A Structure Chart is a hierarchical representation of modules in a software system. It shows:

• Module breakdown

• Calling relationships

• Data flow between modules

• Control flow

• Coupling and cohesiveness

It is produced during design, usually after creating a DFD.

Symbols Used

• Rectangle = Module

• Arrow = Data transfer

• Control flags = Conditions

Example Structure Chart for Library System

Library System

_______/ | \_______

/ | \

Manage Books Issue Books Return Books

 | | |

Update DB Check Availability Update Transaction

This chart shows the system’s top-level module broken into functional modules.

UNIT 3 – CODING, TESTING & DOCUMENTATION

Short Answer Questions (5 marks each)

10. Write short notes on: Verification and Validation.

Verification

• Ensures the software is built according to specifications.

• Activities include:

o Reviews

o Walkthroughs

o Inspections

• Conducted during every development phase.

• Objective: “Are we building the product right?”

• Focuses on static analysis (no execution).

Validation

• Ensures the system meets the customer’s actual needs.

• Activities include:

o Testing

o User Acceptance Testing (UAT)

• Objective: “Are we building the right product?”

• Focuses on dynamic testing (executing the code).

11. Write short notes on White Box Testing.

Definition

White Box Testing (Structural Testing) examines the internal logic and code structure.
Tester must know the programming language.

Techniques
 1. Statement Coverage – every statement executes at least once.

2. Branch Coverage – checks all decisions (if-else).

3. Path Coverage – tests all possible paths.

4. Basis Path Testing – uses cyclomatic complexity to identify independent paths.

5. Loop Testing – tests loop boundaries.

Advantages

• Reveals hidden errors

• Optimizes internal code

• Ensures completeness of logic

12. What is Regression Testing?

Regression Testing is performed after changes such as:

• Bug fixes

• Enhancements

• New features

Purpose:
To ensure existing functionality remains unaffected and no new bugs are introduced.

Regression testing is repeated throughout:

• Integration testing

• System testing

• Maintenance

Long Answer Questions (15 marks each)

13. Differentiate between Integration and System Testing; explain Functional Testing and Test Case.

Integration Testing

• Tests combined modules

• Detects interface errors

• Performed after unit testing

• Types:

o Big Bang
 o Top-Down

o Bottom-Up

o Sandwich

• Ensures data flows correctly between modules.

System Testing

• Tests the entire system as a whole

• Verifies complete functional and non-functional requirements

• Types:

o Performance testing

o Security testing

o Recovery testing

• Conducted by professional testers.

Functional Testing

• Black-box technique

• Validates functional requirements

• No need to know internal code

• Examples:

o Login verification

o Transaction processing

o Report generation

Test Case (Definition and Role)

A Test Case is a documented set of:

• Inputs

• Preconditions

• Test procedure

• Expected output

Role:

• Ensures complete testing

• Reduces ambiguity

• Provides traceability

• Helps reproduce failures

Example Test Case:

Field Description

Test ID TC_Login_01

Input Username, Password

Expected Output Login successful

14. Explain Black Box & White Box testing with examples; perform Basis Path Testing.

Black Box Testing

equivalent partitioning
• Tests functionality boundary value analysis

decision table
• Does not inspect internal code

• Techniques:

o Equivalence Partitioning

o Boundary Value Analysis

o Decision Table

Example:
Test ATM withdrawal without knowing internal code.

White Box Testing

• Tests internal code

• Techniques:

o Branch testing

o Path testing

o Loop testing

Basis Path Testing Steps

Given pseudocode:

1. Read X

2. If X > 0 then

3. Print "Positive"

4. Else

5. Print "Non-Positive"
6. End If

Step 1: Draw Control Flow Graph (CFG)

Nodes: 1 → 2 → 3 or 5 → end.

Step 2: Compute Cyclomatic Complexity

Formula:

𝑉(𝐺) = 𝐸 − 𝑁 + 2 = 5 − 4 + 2 = 3

Step 3: Independent Paths

1. Path 1: 1 → 2 → 3 → End

2. Path 2: 1 → 2 → 5 → End

Two test cases required (positive, non-positive).

15. Control Flow Graph (CFG), Cyclomatic Complexity, Calculation

Control Flow Graph

Cyclomatic Complexity is a software metric used to measure

Graph showing: how complex a program’s control flow is. It was introduced by
Thomas McCabe
• Nodes = statements Cyclomatic Complexity=E−N+2P

• Edges = control flow Where:

Used for path analysis. E = number of edges (transitions)

Cyclomatic Complexity (McCabe’s Metric) N = number of nodes (statements/blocks)

Measures complexity of code.

P = number of connected components (usually 1 per function)

Formula:

𝑉(𝐺) = 𝐸 − 𝑁 + 2

or

𝑉(𝐺) = 𝑃 + 1

(P = number of decision points)

Interpretation

• 1–10: simple, low risk

• 11–20: moderate

• 21–50: complex

• 50: untestable
 UNIT 4 – SOFTWARE PROJECT MANAGEMENT

Short Answer Questions (5 marks)

16. Write short notes on Software Project Plan.

A Software Project Plan is a detailed document describing how the project will be executed,
monitored, and controlled.

Contents

1. Project Scope

2. Objectives

3. Project Schedule (Gantt chart)

4. Cost estimation (COCOMO/FP)

5. Risk Management Plan

6. Resource allocation

7. Quality Management Plan

8. Communication Plan

17. What is PERT and Gantt Chart?

PERT (Program Evaluation and Review Technique) PERT is a network based scheduling technique

• Network-based scheduling technique

• Used for uncertain activity times

• Uses three estimates: Optimistic (O), Most Likely (M), Pessimistic (P)

• Expected time formula:

𝑂 + 4𝑀 + 𝑃
𝑇𝐸 =
6

Gantt Chart
variance=(pessimistic-optimistic/6)^2

• Bar chart showing activities vs time

• Shows start and end dates

• Tracks progress

Long Answer (15 marks)

18. PERT Chart: Draw activity network, find critical path, calculate duration.

(Example explanation)

slack = latest start - earliest start

Steps:

1. Identify activities and dependencies

2. Draw network diagram

3. Compute TE for each using PERT formula

4. Determine all paths

5. Sum TE for each path

6. The longest path = Critical Path

7. Total TE of critical path = project completion time

(Insert numerical if you give activities)

UNIT 5 – OBJECT-ORIENTED MODELING WITH UML

Short Answer (5 marks)

19. Explain types of messages in UML Sequence Diagram.

1. Synchronous Message
Sender waits for receiver to finish.
Example: Function call.

2. Asynchronous Message
Sender does not wait.
Example: Message queue.

3. Return Message
Sends output back.

4. Create Message
Used when an object is created at runtime.

5. Delete Message
Object lifetime ends.

Long Answer (15 marks)

20. Draw a Use Case Diagram (any scenario)

Example: ATM System

Actors:

• Customer

• Bank Server

Use Cases:

• Authenticate User
 • Withdraw Cash

• Check Balance

• Deposit Money

Relationships:

• “Authenticate” is included in all other use cases.

21. Draw Sequence or Class Diagram

Sequence Diagram for ATM Withdrawal

Lifelines:
actors
• Customer

• ATM

• Bank Server

• Database

Messages:

1. insertCard()

2. enterPIN()

3. validatePIN()

4. requestWithdrawal()

5. debitAccount()

6. dispenseCash()

22. Types of Feasibility Study

A Feasibility Study determines whether a proposed system is practical, economically justified, and
technically achievable.
Its major types are:

1. Technical Feasibility

• Checks whether the technology required for the project exists.

• Includes hardware, software, networking, database, and technical skills.

• Example: Can the system run on existing servers?

2. Economic Feasibility

• Determines whether the benefits outweigh the costs.

• Uses Cost–Benefit Analysis, ROI, Payback period.

• Includes development cost, maintenance cost, operational cost, and expected benefits.
3. Operational Feasibility

• Checks whether the system will work in the organization.

• Examines user acceptance, organizational changes required, training needs, etc.

• Ensures the solution solves the real problem.

4. Schedule Feasibility

• Determines whether the system can be developed within the given timeline.

• Important for market-driven products where deadlines are strict.

5. Legal Feasibility

• Ensures the system complies with laws and regulations.

• Examples: Data privacy laws, licensing, intellectual property rights.

6. Environmental Feasibility (Sometimes included)

• Ensures that the system or hardware does not harm the environment.

23. Basic COCOMO Model

COCOMO (Constructive Cost Model) by Barry Boehm is used to estimate effort, development time,
and team size.

Basic COCOMO Formula

Used in early stages when details are minimal.

Effort (E):

𝐸 = 𝑎 × (𝐾𝐿𝑂𝐶)𝑏 (person-months)

Development Time (D):

𝐷 = 𝑐 × (𝐸)𝑑 (months)

Values of a, b, c, d for different modes

Mode Description a b c d

Organic Simple projects, small teams 2.4 1.05 2.5 0.38

Semi-Detached Intermediate complexity 3.0 1.12 2.5 0.35

Embedded Real-time, complex 3.6 1.20 2.5 0.32

Outputs of Basic COCOMO

• Effort in PM (person-months)
 • Development time in months

• Average staff required = Effort / Development time

24. Coupling & Cohesion

Cohesion

• Degree to which elements inside a module belong together.

• High cohesion is GOOD → easier to maintain, reuse, test. functional

coincidental
Types of Cohesion (Best → Worst) procedural
temporal
1. Functional Cohesion → Best (each module does exactly ONE task) communicational
sequential
2. Sequential logical
3. Communicational

4. Procedural

5. Temporal

6. Logical

7. Coincidental → Worst (random tasks grouped together)

Coupling

• Degree of interdependence between modules. data

• Low coupling is GOOD → modules are independent. stamp
control
Types of Coupling (Worst → Best) common
content
1. Content Coupling → Worst (access internal code of another module)

2. Common

3. Control

4. Stamp (Data Structure sharing)

5. Data Coupling → Best (modules share only required data)

25. Data Dictionary (with example)

A Data Dictionary (DD) is a structured repository that stores descriptions of all data items used in the
system.

Contents

• Data item name

 • Type (string, integer, Boolean)

• Size

• Description

• Allowed values

• Relationships

Example

Data Name Type Size Description

Customer_ID Integer 5 Unique ID for customer

Customer_Name String 30 Full name

Order_Date Date 10 Purchase date

Use:

• Ensures consistency in naming and formats

• Helps developers, designers, testers

26. White Box Testing / Basis Path Testing

White Box Testing

Testing based on internal logic, code structure, and control flow.

Techniques

• Statement coverage

• Branch coverage

• Basis path testing

• Loop testing

• Condition coverage

Basis Path Testing

• Invented by McCabe

• Uses Control Flow Graph (CFG)

• Cyclomatic Complexity (V(G)) = Number of independent paths

𝑉(𝐺) = 𝐸 − 𝑁 + 2

Where:

• E = Number of edges
 • N = Number of nodes

Each independent path is executed at least once to ensure complete logic coverage.

27. Verification vs Validation

Verification

• "Are we building the product right?"

• Ensures the system meets design specifications.

• Activities: Reviews, inspections, walkthroughs.

Validation

• "Are we building the right product?"

• Ensures software meets user needs and requirements.

• Activities: Testing, UAT (User Acceptance Testing).

Differences

Verification Validation

No code execution Involves code execution

Checks design Checks functionality

Static Dynamic

Done by QA team Done by testing/user

28. Advantages of Spiral Model over Waterfall

1. Risk Handling

o Spiral explicitly identifies and resolves risks every cycle.

o Waterfall ignores risk until late stages.

2. Iterative Development

o Spiral allows refinement through multiple iterations.

o Waterfall is rigid and linear.

3. Customer Feedback

o Customer reviews each spiral.

o Waterfall collects feedback only at the end.

4. Flexibility
 o Changes can be incorporated easily.

o Waterfall finds changes costly.

5. Better Resource Allocation

o Risk analysis prevents waste of time and cost.

6. Early Prototypes better control on projects

o Spiral produces prototypes early to validate requirements.

Group C (Long Answer – 15 marks each)

These answers are high-detail, exam-ready, and structured.

29. Numerical on Function Point Analysis (FPA)

I will provide the full solution with formula, steps, and example.

Steps in FPA

1. Identify functions:

o EI (External Input)

o EO (External Output)

o EQ (External Inquiry)

o ILF (Internal Logical File)

o EIF (External Interface File)

2. Apply complexity weights.

3. Calculate UFP (Unadjusted Function Points).

4. Compute Value Adjustment Factor (VAF):

14 General System Characteristics (GSCs) rated 0–5.

𝑉𝐴𝐹 = 0.65 + 0.01 × ∑𝐹𝑖

5. Compute AFP (Adjusted Function Points):

𝐴𝐹𝑃 = 𝑈𝐹𝑃 × 𝑉𝐴𝐹

30. Draw Context Level and Level 1 DFD for a case study

I will draw text-based DFD representations or provide diagrams depending on the case study you
choose (library, store, ATM, etc.).
Just tell me the case study you want.
31. Draw a Use Case Diagram for a case study

Same—pick a system (ATM, hospital, mobile service provider).

32. Testing: Difference between Testing Levels

Unit Testing

• Tests individual modules or functions. integration

system
• Done by developers. functional
acceptance
Integration Testing

• Tests module interactions.

• Techniques: Big Bang, Incremental, Top-Down, Bottom-Up.

System Testing

• Tests full integrated system.

Acceptance Testing

• Ensures system meets business requirements.

• Types: Alpha, Beta.

33. Black-box & White-box Testing with examples

Black Box Testing equivalence partitioning

boundary value analysis

• Based on requirements, not code. decision table

• Techniques:

o Equivalence Partitioning

o Boundary Value

o Decision Table

o State Transition

• Example: Testing login functionality by giving valid/invalid credentials.

White Box Testing

coverage

• Based on internal code structure. loops testing

conditions testing
• Techniques: path coverage

branch coverage
o Statement Coverage basis path coverage

o Branch Coverage
 o Basis Path Testing

• Example: Testing loops and conditions in a sorting algorithm.

34. PERT/Activity Diagram, Critical Path, Duration

PERT uses three estimates per activity:

𝑂 + 4𝑀 + 𝑃
𝑇𝐸 =
6

Critical path = Longest path in the activity network.

Determines project duration.

If you provide activity data, I will solve the whole numerical.

35. Control Flow Graph & Cyclomatic Complexity

Steps

1. Convert code into nodes/edges.

2. Draw CFG.

3. Calculate:

𝑉(𝐺) = 𝐸 − 𝑁 + 2

4. Identify independent paths.

Provide code if you want a worked example.

coding structure:
Naming Conventions:
Indentation and Formatting:
Commentary and Documentation:
Code Structure and Organization:
Error Handling: