W2: Software Process Models
Models & Identifiers:
Model When to Use Rules of Thumb
Fixed, well-known
Waterfall Used in billing systems, banking
requirements
Aviation, medicine (test after every dev
V-Model Safety-critical + verification
phase)
Incremental Early delivery is needed When you want working modules quickly
Prototyping User unsure about system UI-based systems (ATM, mobile apps)
Spiral Risky & expensive projects Government, military software
CBSE Components can be reused E-commerce, login, payment reuse
RAD Build quickly with tools Short deadline, GUI-based apps
Tip: If you see “unclear requirements” → Prototype,
“modular + reusable” → CBSE,
“risky + big” → Spiral
W3: Agile Development
Method Use When Key Terms
XP Skilled devs, flexible client Story cards, Pair programming, CI, Refactoring
Small team, frequent Sprint, Product Backlog, Burndown Chart, Daily
Scrum
feedback Scrum
Continuous work, visual
Kanban No sprints, WIP limit, task cards, JIT board
tracking
Scrum Artifacts:
• Product Backlog: All features
• Sprint Backlog: Features for current sprint
• Burndown Chart: Remaining work vs time
• Sprint: 2–4 week mini-projects
• Sprint Review: Evaluation
• Scrum Master: Facilitates team
• Product Owner: Prioritizes requirements
W4: Understanding Requirements
Type Description
Functional What the system does (login, search)
Non-Functional How the system behaves (speed, security)
User Requirements Written for customers (natural language)
System Requirements Technical, for devs (SRS doc)
Example Q: Write 2 functional + 2 non-functional requirements for a self-checkout system
W5: Requirement Engineering Process
Four Key Steps:
1. Feasibility Study: Is it worth building? Budget, time, tech check
2. Elicitation & Analysis: Interview, brainstorm, scenarios
3. Specification: Create requirement docs (SRS)
4. Validation: Review, check accuracy
Discovery Techniques:
• Interviews
• Brainstorming
• Ethnography (observe users)
• Prototypes
• Use Cases
Tip: If asked how to collect requirements → list these techniques
W8: Use Case Modeling
Element Meaning
Actor External user (stick figure)
Use Case Task/system function (oval)
System Boundary Box containing use cases
<<include>> Mandatory use case
<<extend>> Optional use case
Exam Tip:
Use <<include>> when it always happens
Use <<extend>> when it's optional or conditional
W9: Activity Diagram
Symbol Use
● Start
◎ End
◇ Decision (yes/no)
➤ Arrow (flow)
▌▐ Fork/Join (parallel)
Capsule Activity step
Think of it as a flowchart of what the user/system does step by step
W10: Class Diagram
Element Symbol
Class Rectangle with name, attributes, methods
Association Line
Inheritance Arrow with hollow triangle
Aggregation Empty diamond
Composition Filled diamond
Tip: Inheritance = "is-a", Aggregation = "has-a"
W11: Sequence Diagram
Concept Meaning
Object Box at top
Lifeline Vertical dashed line
Message Horizontal arrow
Return Dashed arrow
Activation Narrow vertical rectangle
Use for: showing the flow of messages over time (e.g., login)
W12: ERD (Entity Relationship Diagram)
Element Use
Entity Rectangle
Attribute Oval
PK Underlined
Relationship Diamond
Element Use
Cardinality 1:1, 1:N, M:N
Use when asked about data modeling or database
W13: Data Flow Diagram (DFD)
Symbol Meaning
Process Circle (e.g. Verify Payment)
External Entity Rectangle (e.g. Customer)
Data Store Open rectangle (e.g. DB)
Data Flow Arrow (→)
Levels:
Level 0 = Context diagram (one process)
Level 1 = Expanded (detailed) version
W14: Software Quality Assurance (SQA)
Concept Meaning
SQA Ensures process quality
Review Types Peer, Walkthrough, Formal
Inspection Formal peer review
CMM 0–5 maturity scale for process quality
ISO 9126 Software product quality standard
W15-1: Software Testing (Part 1)
Type Description
Unit Test a function
Integration Test combined modules
System Test whole app
Acceptance Client testing
Regression Retest after changes
V vs V:
• Verification: Are we building it right?
• Validation: Are we building the right thing?
W15-2: Test Case Steps
Test Case Template
Field Example
Test Case ID TC_01
Title Login Test
Preconditions User exists
Steps 1. Enter username, 2. Enter password
Expected Result Redirect to dashboard
W16-1: Software Project Management (SPM)
Concept Description
Project Temporary effort to create software
Management Spectrum People, Product, Process, Project
Concept Description
MOI Model Motivation, Organization, Innovation
Stakeholders Managers, Users, Developers
Project Phases:
1. Initiation
2. Planning
3. Execution
4. Monitoring
5. Closure
W16-2: Software Project Scheduling
Concept Description
Task Network Shows task flow and dependencies
Critical Path Longest path (must finish on time)
Gantt Chart Horizontal task timeline (created by Henry Gantt)
Milestone Diamond in Gantt chart (no duration)
40-20-40 Rule:
Phase Effort
Analysis + Design 40%
Coding 20%
Testing 40%
Bonus: Model Selection – Ultimate Cheat Table
Clue from Question Model
Fixed requirements, no change Waterfall
Safety-critical V-Model
Client unsure Prototyping
Want reuse CBSE
Want working modules quickly Incremental
Risk, budget high Spiral
GUI tool, tight deadline RAD
Daily client feedback, team of 5–10 Scrum / XP
Flow tasks visually, no sprints Kanban
Stages of Testing:
1. Unit Testing – Test individual components.
2. Integration Testing – Test interactions between components.
3. System Testing – Test entire system functionality.
4. Acceptance Testing – Customer verifies the system.
Stubs and Drivers:
• Used in Integration Testing.
• Stub: Simulates a called component (lower level).
• Driver: Simulates a calling component (higher level).
Requirements Engineering
Types of Requirements:
• Functional: What the system should do.
• Non-Functional (NFRs): Constraints (performance, usability, reliability, etc.)
RE Process Activities:
1. Feasibility Study
2. Requirement Elicitation & Analysis
3. Specification
4. Validation
5. Requirements Management
Stakeholders:
• End-users, customers, IT staff, regulators, etc.
Q4: Suggest a Suitable Process Model
A process model depends on:
• Requirements clarity
• Risk level
• Feedback needs
• Project size and domain
Example Choices:
Scenario Suggested Model Reason
Unclear Requirements Prototyping Builds quick mockups for feedback
High Risk (AI, scalable) Spiral Iterative with risk analysis
Modular, growing features Incremental Feature-by-feature delivery
Business apps CBSE Reuse of existing components
Q5: Product Backlog vs Sprint Backlog
Feature Product Backlog Sprint Backlog
Owner Product Owner Scrum Team
Feature Product Backlog Sprint Backlog
Content All possible features (dynamic) Features selected for 1 sprint
Priority Basis ROI or value to business Based on team’s capacity
Updates Constantly evolving Frozen during sprint
Q7: Scrum – Artifacts, Roles, Phases, Pros & Cons
Scrum Artifacts:
1. Product Backlog – List of all features/requirements
2. Sprint Backlog – Tasks selected for the sprint
3. Burn Down Chart – Visual of work remaining vs time
Roles:
• Product Owner – Prioritizes features
• Scrum Master – Removes blockers
• Team – Builds product
Phases:
• Planning → Sprint → Closure
• Review done at sprint end
Pros:
• Team empowerment
• Adaptive to changes
• Frequent delivery
Cons:
• Not ideal for large, rigid systems
• Customer involvement is intense
• Risk of uncontrolled scope change
Q8: Ethnography in Requirement Discovery
What is Ethnography?
An observation-based technique where engineers immerse themselves in the user’s
environment to understand real workflows and routines.
Example:
In a warehouse, employees may bypass certain steps due to time constraints. Ethnography
reveals this — interviews might miss it.
Best for:
• Operational staff
• Understanding actual vs reported behavior
• Capturing unstated requirements
Q9: Interviews vs Prototyping
Aspect Interviews Prototyping
Pros Direct info, stakeholder voice Visual feedback, early validation
Cons Time-consuming, subjective Misleading expectations, not scalable
Combine both when: Requirements are unclear and users need to see features to give
feedback
Q11: Core RE Processes
Activity Explanation
Can we build this system with our time, cost, tech, and
Feasibility Study
goals?
Requirement Elicitation &
Work with users to discover what they really need
Analysis
Activity Explanation
Validation Ensure what’s written = what users want
Specification Document requirements in standard format
All of this results in a Requirements Document for further use.
ADDITIONAL HIGH-VALUE SHORT QUESTIONS
These may appear in MCQs or short writing:
Q: What is the 40-20-40 Rule?
Suggested time/effort split in software projects:
• 40% → Analysis & Design
• 20% → Coding
• 40% → Testing & Debugging
More relevant in safety-critical systems (e.g., medical)
Q: What are Stubs and Drivers?
Term Description Testing Type
Stub Simulates a lower-level module Used in top-down testing
Driver Simulates a higher-level module Used in bottom-up testing
Q: Difference between Primary and Secondary Actor?
Actor Type Role
Primary Actor Initiates the interaction (e.g., customer places an order)
Secondary Actor Supports or assists the process (e.g., payment gateway, database)
Q: What is a User Story?
A short description of a requirement from the user’s point of view:
Format:
As a <role>, I want <feature> so that <benefit>
E.g. As a student, I want to view results so that I can track performance.
Q: What is a Burn Down Chart?
A graph used in Scrum showing remaining work vs. sprint time. Helps track progress and
detect delays.
Q: Kanban Board?
A visual Agile board with columns like:
• To Do → In Progress → In Review → Done
Used for just-in-time delivery and task tracking
Summary Table of Must-Know Terms
Term Meaning
User Story Agile feature description
Stub / Driver Testing support modules
Feasibility Study Determines practicality
Validation Ensure correct requirements
Product/Sprint Backlog Agile to-do lists
Ethnography Observe users in real-world setting
Burn Down Chart Tracks sprint progress
Term Meaning
40-20-40 Rule Time allocation: design, code, test
Primary Actor Initiates use case
Secondary Actor Assists in use case
The critical path is the longest sequence of dependent tasks in a project that must be
completed on time for the whole project to finish on schedule.
If any task on the critical path is delayed, the entire project is delayed.
Why is it Important?
• Determines minimum project duration
• Helps in resource prioritization
• Identifies non-flexible tasks (with zero slack)
How to Identify the Critical Path:
1. List all tasks in the project.
2. Estimate duration for each task.
3. Identify dependencies (which task comes after which).
4. Draw a task network (also called activity network).
5. Calculate total time for each path from start to end.
6. Longest path = Critical Path
Term Meaning
Task Network A visual map showing how project tasks depend on each other
Dependency When one task must finish before another starts
Slack/Float Extra time a task can be delayed without delaying the project
Critical Path Longest chain of tasks with zero slack
Gantt Chart A timeline view showing task duration and overlap visually
