π Software Process Models (High Frequency in Exams!)
Always appears in MCQs and scenario-matching questions!
Quick Model Selector
| Model | When to Use | Key Characteristics | Exam Keywords |
|---|---|---|---|
| Waterfall | Requirements clear & fixed | Sequential, no going back | "well understood", "critical safety", "fixed requirements" |
| Incremental | Need quick delivery of core | Deliver in increments | "quickly", "core product", "business competition" |
| Evolutionary/Spiral | High risk, changing requirements | Risk management, iterative | "risk management", "gradually growing" |
| Prototyping | Unclear requirements, UI focus | Build throwaway version | "unclear requirements", "user interface", "stakeholder feedback" |
| Unified Process | Large enterprise systems | Use-case driven, architecture-centric | "use-case driven", "architecture-centric", "iterative and incremental" |
Scenario Matching Example (From Final 2022):
Q: "A compelling need to provide limited functionality to users quickly and then refine in later releases"
Step 1: Identify keywords β "quickly", "limited functionality", "refine later"
Step 2: Match to model characteristics:
β’ Waterfall? NO - it doesn't allow refinement
β’ Incremental? YES - delivers core quickly, adds features later
β’ Spiral? NO - focuses on risk, not speed
Step 3: Answer = Incremental Model
Q: "A compelling need to provide limited functionality to users quickly and then refine in later releases"
Step 1: Identify keywords β "quickly", "limited functionality", "refine later"
Step 2: Match to model characteristics:
β’ Waterfall? NO - it doesn't allow refinement
β’ Incremental? YES - delivers core quickly, adds features later
β’ Spiral? NO - focuses on risk, not speed
Step 3: Answer = Incremental Model
Multiple Choice Example:
Q: "An iterative model with emphasis on risk management that develops increasingly complete versions"
Step 1: Key phrases β "iterative", "risk management", "increasingly complete"
Step 2: Eliminate options:
a) Waterfall - NOT iterative β
b) Evolutionary/Spiral - iterative + risk β
c) Incremental - iterative but no risk focus β
Step 3: Answer = b) Evolutionary Process Model
Q: "An iterative model with emphasis on risk management that develops increasingly complete versions"
Step 1: Key phrases β "iterative", "risk management", "increasingly complete"
Step 2: Eliminate options:
a) Waterfall - NOT iterative β
b) Evolutionary/Spiral - iterative + risk β
c) Incremental - iterative but no risk focus β
Step 3: Answer = b) Evolutionary Process Model
Real Exam Scenarios - Match the Model:
Scenario 1: "System developed at several sites"
Solution: Waterfall (clear phases for distributed teams)
Scenario 2: "Requirements are huge and unclear, needs user involvement"
Solution: Prototyping (user feedback refines unclear requirements)
Scenario 3: "Hardware delivery date uncertain"
Solution: Spiral (handles uncertainty through risk management)
Scenario 4: "Use-case driven, architecture-centric, iterative"
Solution: Unified Process (these are its defining characteristics)
Scenario 1: "System developed at several sites"
Solution: Waterfall (clear phases for distributed teams)
Scenario 2: "Requirements are huge and unclear, needs user involvement"
Solution: Prototyping (user feedback refines unclear requirements)
Scenario 3: "Hardware delivery date uncertain"
Solution: Spiral (handles uncertainty through risk management)
Scenario 4: "Use-case driven, architecture-centric, iterative"
Solution: Unified Process (these are its defining characteristics)
Quick Decision Tree:
1. Requirements clear? β YES: Waterfall | NO: Continue
2. Need quick delivery? β YES: Incremental | NO: Continue
3. High risk/uncertainty? β YES: Spiral | NO: Continue
4. UI/User feedback critical? β YES: Prototyping
1. Requirements clear? β YES: Waterfall | NO: Continue
2. Need quick delivery? β YES: Incremental | NO: Continue
3. High risk/uncertainty? β YES: Spiral | NO: Continue
4. UI/User feedback critical? β YES: Prototyping
π Agile, Scrum & XP (Guaranteed Questions!)
Scrum Terminology - Must Know!
| Term | Definition | Exam Trap |
|---|---|---|
| Sprint | 2-4 weeks fixed iteration | NEVER extended for incomplete work |
| Product Owner | Prioritizes backlog, represents customer | NOT a project manager! |
| Scrum Master | Facilitator, removes obstacles | NOT managing the team directly |
| Sprint Backlog | Tasks for current sprint | For DEVELOPERS to manage themselves |
| Product Backlog | All pending features/requirements | Prioritized by Product Owner |
| Daily Scrum | 15-minute standup | 3 questions: yesterday, today, obstacles |
Development Team size: 7 people (up to 10 max) - common MCQ!
XP Practices
- Pair Programming - Two developers, one computer
- Test-First Development - Write tests before code
- Continuous Integration - Frequent code integration
- Small Releases - Frequent delivery
- Simple Design - Avoid complexity
- User Stories - Requirements as scenarios (TRUE in XP!)
Scrum MCQ Example (From Final 2022):
Q: "What is the MAIN purpose of a Sprint Backlog?"
a) For Developers to manage themselves during Sprint
b) For Scrum Master to manage progress
c) For Developers to manage hours spent
d) For Product Owner to understand commitments
Step 1: Recall Sprint Backlog ownership β Belongs to Development Team
Step 2: Eliminate wrong roles:
β’ Scrum Master doesn't manage it (b) β
β’ Product Owner manages Product Backlog, not Sprint (d) β
Step 3: Compare remaining options:
β’ Hours tracking is minor detail (c) β
β’ Self-management is core Scrum principle (a) β
Answer: a) For Developers to manage themselves
Q: "What is the MAIN purpose of a Sprint Backlog?"
a) For Developers to manage themselves during Sprint
b) For Scrum Master to manage progress
c) For Developers to manage hours spent
d) For Product Owner to understand commitments
Step 1: Recall Sprint Backlog ownership β Belongs to Development Team
Step 2: Eliminate wrong roles:
β’ Scrum Master doesn't manage it (b) β
β’ Product Owner manages Product Backlog, not Sprint (d) β
Step 3: Compare remaining options:
β’ Hours tracking is minor detail (c) β
β’ Self-management is core Scrum principle (a) β
Answer: a) For Developers to manage themselves
True/False Example:
Q: "User requirements are expressed as Scenarios in Extreme Programming"
Step 1: Recall XP terminology β User Stories = Scenarios
Step 2: Verify: XP uses "User Stories" which are scenario-based requirements
Step 3: Answer = TRUE
Common Trap: Don't confuse with Use Cases (that's RUP/Unified Process)
Q: "User requirements are expressed as Scenarios in Extreme Programming"
Step 1: Recall XP terminology β User Stories = Scenarios
Step 2: Verify: XP uses "User Stories" which are scenario-based requirements
Step 3: Answer = TRUE
Common Trap: Don't confuse with Use Cases (that's RUP/Unified Process)
Scrum Calculation Problem:
Q: "A team has velocity of 40 points. Sprint is 3 weeks. Product Backlog has 200 points. How many sprints to complete?"
Step 1: Identify given data
β’ Velocity = 40 points/sprint
β’ Total work = 200 points
Step 2: Calculate sprints
β’ Sprints needed = Total work Γ· Velocity
β’ Sprints = 200 Γ· 40 = 5 sprints
Step 3: Calculate time (if asked)
β’ Time = 5 sprints Γ 3 weeks = 15 weeks
Answer: 5 sprints (15 weeks total)
Q: "A team has velocity of 40 points. Sprint is 3 weeks. Product Backlog has 200 points. How many sprints to complete?"
Step 1: Identify given data
β’ Velocity = 40 points/sprint
β’ Total work = 200 points
Step 2: Calculate sprints
β’ Sprints needed = Total work Γ· Velocity
β’ Sprints = 200 Γ· 40 = 5 sprints
Step 3: Calculate time (if asked)
β’ Time = 5 sprints Γ 3 weeks = 15 weeks
Answer: 5 sprints (15 weeks total)
Role Identification Example:
Q: "Who is responsible for maximizing the value of the product?"
Step 1: Review each role's responsibility:
β’ Scrum Master β Process facilitator β
β’ Development Team β Creates product β
β’ Product Owner β Value maximization β
Answer: Product Owner
Remember:
β’ Product Owner = WHAT to build (value)
β’ Dev Team = HOW to build (technical)
β’ Scrum Master = Process guardian
Q: "Who is responsible for maximizing the value of the product?"
Step 1: Review each role's responsibility:
β’ Scrum Master β Process facilitator β
β’ Development Team β Creates product β
β’ Product Owner β Value maximization β
Answer: Product Owner
Remember:
β’ Product Owner = WHAT to build (value)
β’ Dev Team = HOW to build (technical)
β’ Scrum Master = Process guardian
π UML Diagrams (Drawing & Analysis Questions)
Diagram Types & When to Use
Structural Diagrams
- Class Diagram - Shows classes & relationships
- Components: Class name, Attributes, Operations
- Relationships: Association, Dependency, Generalization
Behavioral Diagrams
- Use Case - User interactions
- Sequence - Message flow over time
- Activity - Workflow/process
- State - Object state changes
Class Diagram Relationships
| Relationship | Symbol | Meaning | Example |
|---|---|---|---|
| Association | ββ | General relationship | Student β Course |
| Aggregation | βββ | Has-a (can exist separately) | Team βββ Employee |
| Composition | βββ | Part-of (cannot exist separately) | House βββ Room |
| Dependency | - - -> | Uses temporarily | Class - - -> Parameter |
| Generalization | βββ· | Inheritance (is-a) | Dog βββ· Animal |
| Realization | - - -β· | Interface implementation | Class - - -β· Interface |
Class Diagram Visibility Modifiers
| Symbol | Visibility | Access Level |
|---|---|---|
| + | Public | Accessible from anywhere |
| - | Private | Only within class |
| # | Protected | Within class and subclasses |
| ~ | Package | Within same package |
Multiplicity Notations
| Notation | Meaning | Example |
|---|---|---|
| 1 | Exactly one | Person has 1 passport |
| 0..1 | Zero or one | Person has 0..1 spouse |
| * | Zero or more | Customer places * orders |
| 1..* | One or more | Course has 1..* students |
| n | Exactly n | Team has 11 players |
| m..n | Between m and n | Car has 2..5 doors |
Remember: Aggregation = Empty diamond (can be Empty/separate), Composition = Filled diamond (must be together)
Sequence Diagram Components
- Actor - Stick figure or box
- Lifeline - Vertical dashed line
- Activation - Rectangle on lifeline (shows active)
- Messages - Horizontal arrows between lifelines
- Alt/Loop blocks - For conditions and iterations
Use Case Diagram - ATM System (Common Exam):
β Step 1: Identify Actors
β’ Customer (primary)
β’ Bank System (secondary)
β’ Admin (maintenance)
β Step 2: Identify Use Cases
β’ Login/Authenticate
β’ Withdraw Cash
β’ Check Balance
β’ Transfer Money
β’ Print Receipt
β Step 3: Identify Relationships
β’ Withdraw Cash Β«includesΒ» Authenticate
β’ Check Balance Β«includesΒ» Authenticate
β’ Print Receipt Β«extendsΒ» from all transactions
β Step 4: Draw Diagram
β Step 1: Identify Actors
β’ Customer (primary)
β’ Bank System (secondary)
β’ Admin (maintenance)
β Step 2: Identify Use Cases
β’ Login/Authenticate
β’ Withdraw Cash
β’ Check Balance
β’ Transfer Money
β’ Print Receipt
β Step 3: Identify Relationships
β’ Withdraw Cash Β«includesΒ» Authenticate
β’ Check Balance Β«includesΒ» Authenticate
β’ Print Receipt Β«extendsΒ» from all transactions
β Step 4: Draw Diagram
[Customer]ββββββ(Login)
β βΒ«includeΒ»
βββββ(Withdraw Cash)
β βΒ«extendΒ»
βββββ(Check Balance)ββββββ(Print Receipt)
β βΒ«extendΒ»
βββββ(Transfer Money)
β
[Bank System]
Class Diagram - Library System:
β Step 1: Identify Classes
β’ Book, Member, Librarian, Loan
β Step 2: Add Attributes
β’ Member ββββ Loan (1 to 0..*)
β’ Book ββββ Loan (1 to 0..*)
β’ Librarian βββ· Member (inheritance)
β’ Library βββββ Book (composition)
β Step 1: Identify Classes
β’ Book, Member, Librarian, Loan
β Step 2: Add Attributes
Book Member
--------- ---------
-ISBN: String -memberID: int
-title: String -name: String
-author: String -email: String
-available: bool -maxBooks: int
β Step 3: Add Methods
Book Member
--------- ---------
+checkOut() +borrowBook()
+return() +returnBook()
+reserve() +payFine()
β Step 4: Add Relationshipsβ’ Member ββββ Loan (1 to 0..*)
β’ Book ββββ Loan (1 to 0..*)
β’ Librarian βββ· Member (inheritance)
β’ Library βββββ Book (composition)
Sequence Diagram - Login Process:
β Step 1: Identify Objects/Actors
β’ User, LoginUI, AuthController, Database
β Step 2: Identify Messages in Order
1. User β LoginUI: enterCredentials()
2. LoginUI β AuthController: validateLogin(user,pass)
3. AuthController β Database: checkUser(user,pass)
4. Database β AuthController: userValid
5. AuthController β LoginUI: loginSuccess
6. LoginUI β User: displayHomePage
β Step 3: Draw with Proper Notation
β Step 1: Identify Objects/Actors
β’ User, LoginUI, AuthController, Database
β Step 2: Identify Messages in Order
1. User β LoginUI: enterCredentials()
2. LoginUI β AuthController: validateLogin(user,pass)
3. AuthController β Database: checkUser(user,pass)
4. Database β AuthController: userValid
5. AuthController β LoginUI: loginSuccess
6. LoginUI β User: displayHomePage
β Step 3: Draw with Proper Notation
User LoginUI AuthController Database
| | | |
|--enter----->| | |
| |--validate--->| |
| | |--check------>|
| | |<---valid-----|
| |<--success----| |
|<--display---| | |
Activity Diagram - Order Processing:
β Step 1: Identify Activities
β’ Receive Order, Check Stock, Process Payment
β’ Ship Order, Send Confirmation
β Step 2: Identify Decision Points
β’ Stock available? (Yes/No)
β’ Payment successful? (Yes/No)
β Step 3: Identify Parallel Activities
β’ Ship Order AND Send Email (concurrent)
β Step 4: Draw with Symbols
β Step 1: Identify Activities
β’ Receive Order, Check Stock, Process Payment
β’ Ship Order, Send Confirmation
β Step 2: Identify Decision Points
β’ Stock available? (Yes/No)
β’ Payment successful? (Yes/No)
β Step 3: Identify Parallel Activities
β’ Ship Order AND Send Email (concurrent)
β Step 4: Draw with Symbols
β Start
β
[Receive Order]
β
Stock?
β
β Yes β No
[Process Pay] [Notify Customer]
β β
Success? β End
β
β Yes β No
β¬Forkβ¬ [Cancel]
β β β
[Ship] [Email] β
β β
β¬Joinβ¬
β
β End
Diagram Drawing Order:
1. Use Case: Actors β Use Cases β Relationships
2. Class: Classes β Attributes β Methods β Relationships
3. Sequence: Objects β Messages (top to bottom)
4. Activity: Start β Activities β Decisions β End
1. Use Case: Actors β Use Cases β Relationships
2. Class: Classes β Attributes β Methods β Relationships
3. Sequence: Objects β Messages (top to bottom)
4. Activity: Start β Activities β Decisions β End
π― Complete UML Symbol Reference
Use Case Diagram Symbols
Represents a use case - specific function/action
π Example: "Login", "Process Payment"
πΆ
Stick FigureRepresents an actor - external entity
π Example: "Customer", "Admin", "System"
System boundary - defines system scope
π Contains all use cases
Communication between actor and use case
β οΈ SOLID LINE - No arrowhead
Mandatory inclusion of behavior
β οΈ DASHED LINE + OPEN ARROWHEAD
Optional behavior extension
β οΈ DASHED LINE + OPEN ARROW (to base)
Child inherits from parent
β οΈ SOLID LINE + HOLLOW TRIANGLE
Class Diagram Relationships
General relationship between classes
π Example: Student β Course
Weak "has-a" - parts can exist independently
β οΈ HOLLOW DIAMOND (at whole)
π Example: Team ββ Employee
Strong "has-a" - parts CANNOT exist alone
β οΈ FILLED DIAMOND (at whole)
π Example: House ββ Room
Uses temporarily/weakly depends on
β οΈ DASHED LINE + OPEN ARROW
π Example: Class uses Parameter
"is-a" relationship
β οΈ SOLID LINE + HOLLOW TRIANGLE
π Example: Dog βββ· Animal
Interface implementation
β οΈ DASHED LINE + HOLLOW TRIANGLE
π Example: Class implements Interface
Activity Diagram Symbols
Start point - filled black circle
β Beginning of workflow
End point - circle with dot
β Termination of workflow
Diamond - conditional branch
β Multiple paths based on condition
Rounded rectangle
Task or operation performed
Thick horizontal/vertical bar
β¬ Split/merge parallel flows
Circle with X
β Terminates specific flow
Sequence Diagram Symbols
Rectangle with dashed vertical line
β Shows object's existence over time
Rectangle on lifeline
β Shows when object is active
Solid line with filled arrowhead
β Waits for response
Solid line with open arrowhead
βΆ Doesn't wait for response
Dashed line with open arrow
β΅ Response to a call
Rectangle with label
For conditions and iterations
State Diagram Symbols
Filled black circle
β Start of state machine
Circle with dot inside
β End of state machine
Rounded rectangle
Object's condition at a point in time
Arrow with event label
β State change trigger
Loop back to same state
β» State remains but event processed
State containing sub-states
Hierarchical state decomposition
π― Quick Memory Tricks:
β’ Hollow = Can be separate (Aggregation, Open arrows)
β’ Filled = Must be together (Composition, Closed arrows)
β’ Dashed = Weak/temporary (Dependency, Include/Extend)
β’ Solid = Strong/permanent (Association, Generalization)
β’ Hollow = Can be separate (Aggregation, Open arrows)
β’ Filled = Must be together (Composition, Closed arrows)
β’ Dashed = Weak/temporary (Dependency, Include/Extend)
β’ Solid = Strong/permanent (Association, Generalization)
Memory trick for relationships: Empty Diamond = Apart OK (Aggregation), Filled Diamond = Forever together (Composition)
π Project Management - Critical Path (Always in Finals!)
Critical Path Method (CPM) appears in EVERY final - expect 8-10 marks!
Step-by-Step Critical Path Solution
- Draw Network Diagram - Boxes connected with arrows based on prerequisites
- Forward Pass - Calculate ES and EF
ES = Maximum EF of all predecessors
EF = ES + Duration - Backward Pass - Calculate LS and LF
LF = Minimum LS of all successors
LS = LF - Duration - Calculate Slack
Total Slack = LS - ES = LF - EF
Free Slack = ES(successor) - EF(current) - Identify Critical Path - Path where all tasks have Total Slack = 0
Tasks on critical path: EF = LF (Early Finish equals Late Finish)
Complete Critical Path Example (From Final 2022):
Given WBS: A(15 days), B(9 days), C(12, needs A), D(10, needs B), E(29, needs B)
β Step 1: Draw Network Diagram
β’ Start with tasks with no prerequisites (A, B)
β’ Add dependent tasks based on prerequisites
β’ Connect with arrows showing dependencies
β’ ES of first tasks = 0
β’ EF = ES + Duration
β’ ES of next task = Maximum EF of all predecessors
β Step 3: Project Duration
β’ Maximum EF = max(27, 19, 38) = 38 days
β Step 4: Backward Pass (Calculate LS and LF)
β’ LF of last tasks = Project Duration = 38
β’ LS = LF - Duration
β’ LF of previous = Minimum LS of successors
β Step 5: Calculate Slack
β’ Total Slack = LS - ES = LF - EF
β Step 6: Identify Critical Path
β’ Tasks with slack = 0: B, E
β’ Critical Path: B β E (38 days)
Given WBS: A(15 days), B(9 days), C(12, needs A), D(10, needs B), E(29, needs B)
β Step 1: Draw Network Diagram
β’ Start with tasks with no prerequisites (A, B)
β’ Add dependent tasks based on prerequisites
β’ Connect with arrows showing dependencies
START β A(15) β C(12) β END
β
B(9) β D(10) β END
β
E(29) β END
β Step 2: Forward Pass (Calculate ES and EF)β’ ES of first tasks = 0
β’ EF = ES + Duration
β’ ES of next task = Maximum EF of all predecessors
| Task | Calculation | ES | EF |
|---|---|---|---|
| A | Start task | 0 | 0+15=15 |
| B | Start task | 0 | 0+9=9 |
| C | After A | 15 | 15+12=27 |
| D | After B | 9 | 9+10=19 |
| E | After B | 9 | 9+29=38 |
β’ Maximum EF = max(27, 19, 38) = 38 days
β Step 4: Backward Pass (Calculate LS and LF)
β’ LF of last tasks = Project Duration = 38
β’ LS = LF - Duration
β’ LF of previous = Minimum LS of successors
| Task | Calculation | LS | LF |
|---|---|---|---|
| C | LF=38 | 38-12=26 | 38 |
| D | LF=38 | 38-10=28 | 38 |
| E | LF=38 | 38-29=9 | 38 |
| A | LF=min(LS of C)=26 | 26-15=11 | 26 |
| B | LF=min(LS of D,E)=9 | 9-9=0 | 9 |
β’ Total Slack = LS - ES = LF - EF
| Task | ES | LS | Slack | Critical? |
|---|---|---|---|---|
| A | 0 | 11 | 11 | NO |
| B | 0 | 0 | 0 | YES |
| C | 15 | 26 | 11 | NO |
| D | 9 | 28 | 19 | NO |
| E | 9 | 9 | 0 | YES |
β’ Tasks with slack = 0: B, E
β’ Critical Path: B β E (38 days)
Delay Impact Calculation:
Q: "If Task E delayed by 5 days, when will project complete?"
Step 1: Check if task is critical
β’ E has slack = 0 β It's critical
Step 2: Calculate impact
β’ Critical task delay = Project delay
β’ New duration = 38 + 5 = 43 days
Answer: 43 days
Q: "If Task D delayed by 9 days?"
Step 1: Check slack
β’ D has slack = 19 days
Step 2: Compare delay vs slack
β’ Delay (9) < Slack (19)
β’ No impact on project
Answer: No effect, still 38 days
Q: "If Task E delayed by 5 days, when will project complete?"
Step 1: Check if task is critical
β’ E has slack = 0 β It's critical
Step 2: Calculate impact
β’ Critical task delay = Project delay
β’ New duration = 38 + 5 = 43 days
Answer: 43 days
Q: "If Task D delayed by 9 days?"
Step 1: Check slack
β’ D has slack = 19 days
Step 2: Compare delay vs slack
β’ Delay (9) < Slack (19)
β’ No impact on project
Answer: No effect, still 38 days
CPM Quick Checks:
β’ Critical task: ES = LS and EF = LF
β’ Delay formula: If delay > slack, project delays by (delay - slack)
β’ Free Slack = ES(next) - EF(current) - only affects immediate successor
β’ Critical task: ES = LS and EF = LF
β’ Delay formula: If delay > slack, project delays by (delay - slack)
β’ Free Slack = ES(next) - EF(current) - only affects immediate successor
Network Diagram Box Format
ββββββββββββββββββββ
β ES | Task | EF β
β LS | Dura.| LF β
ββββββββββββββββββββ
π§ Requirements Engineering
Functional vs Non-Functional Requirements
Functional Requirements
- WHAT system should do
- Specific functions/features
- Example: "System shall send email"
- Keywords: "shall", "must", "will"
Non-Functional Requirements
- HOW system should perform
- Quality attributes
- Example: "Response time < 2 seconds"
- Types: Performance, Security, Usability
Functional vs Non-Functional Example (From Finals):
Q: "Heat sensor detects intrusion and alerts security company"
Step 1: Identify the key action
β’ "detects" and "alerts" are ACTIONS/VERBS
Step 2: Apply the rule
β’ Actions/What system does = Functional
β’ Quality/How well = Non-functional
Step 3: Verify
β’ This describes WHAT the system does
Answer: a) Functional Requirement
Q: "Heat sensor detects intrusion and alerts security company"
Step 1: Identify the key action
β’ "detects" and "alerts" are ACTIONS/VERBS
Step 2: Apply the rule
β’ Actions/What system does = Functional
β’ Quality/How well = Non-functional
Step 3: Verify
β’ This describes WHAT the system does
Answer: a) Functional Requirement
More Classification Examples:
Example 1: "System shall process 1000 transactions per second"
Step 1: Look for quality metric β "1000 per second"
Step 2: This is HOW FAST, not WHAT
Answer: Non-Functional (Performance)
Example 2: "System shall encrypt all stored passwords"
Step 1: Action word β "encrypt"
Step 2: Describes WHAT system does
Answer: Functional
Example 3: "Response time shall be less than 2 seconds"
Step 1: Quality constraint β "less than 2 seconds"
Step 2: Describes HOW WELL
Answer: Non-Functional (Performance)
Example 4: "System shall be available 99.9% of the time"
Step 1: Percentage metric β "99.9%"
Step 2: Quality attribute
Answer: Non-Functional (Reliability)
Example 1: "System shall process 1000 transactions per second"
Step 1: Look for quality metric β "1000 per second"
Step 2: This is HOW FAST, not WHAT
Answer: Non-Functional (Performance)
Example 2: "System shall encrypt all stored passwords"
Step 1: Action word β "encrypt"
Step 2: Describes WHAT system does
Answer: Functional
Example 3: "Response time shall be less than 2 seconds"
Step 1: Quality constraint β "less than 2 seconds"
Step 2: Describes HOW WELL
Answer: Non-Functional (Performance)
Example 4: "System shall be available 99.9% of the time"
Step 1: Percentage metric β "99.9%"
Step 2: Quality attribute
Answer: Non-Functional (Reliability)
Risk Classification Example:
Q: "Requirements change is what type of risk?"
Step 1: Analyze impact areas
β’ Changes affect schedule β Project Risk β
β’ Changes affect quality β Product Risk β
β’ Changes affect organization β Maybe not directly
Step 2: Check given options
a) Project risk β
b) Product risk β
c) Organizational risk β
d) a and b β
Answer: d) Both Project and Product Risk
Q: "Requirements change is what type of risk?"
Step 1: Analyze impact areas
β’ Changes affect schedule β Project Risk β
β’ Changes affect quality β Product Risk β
β’ Changes affect organization β Maybe not directly
Step 2: Check given options
a) Project risk β
b) Product risk β
c) Organizational risk β
d) a and b β
Answer: d) Both Project and Product Risk
Risk Management Strategy Example:
Q: "Risk avoidance refers to?"
Step 1: Recall risk strategies:
β’ Avoidance = Reduce probability
β’ Mitigation = Reduce impact
β’ Contingency = Plan B if it happens
β’ Acceptance = Take the risk
Step 2: Match definition
"Reducing probability" = Avoidance
Answer: a) Reducing the probability that risk will arise
Q: "Risk avoidance refers to?"
Step 1: Recall risk strategies:
β’ Avoidance = Reduce probability
β’ Mitigation = Reduce impact
β’ Contingency = Plan B if it happens
β’ Acceptance = Take the risk
Step 2: Match definition
"Reducing probability" = Avoidance
Answer: a) Reducing the probability that risk will arise
Quick Test for Requirements:
β’ Can you test it with YES/NO? β Functional
β’ Need to measure HOW MUCH/FAST/WELL? β Non-functional
β’ Has a number/metric? β Usually Non-functional
β’ Can you test it with YES/NO? β Functional
β’ Need to measure HOW MUCH/FAST/WELL? β Non-functional
β’ Has a number/metric? β Usually Non-functional
Requirements Elicitation Problems (Common MCQ)
- Stakeholders don't know what they want
- Stakeholders use their own terms (domain language)
- Conflicting requirements from different stakeholders
- Political/organizational factors influence requirements
Risk Categories
| Risk Type | Examples | Exam Tip |
|---|---|---|
| Project Risk | Schedule, budget, resources | Affects project timeline |
| Product Risk | Quality, performance issues | Affects product quality |
| Business Risk | Market changes, competition | Affects product viability |
"Requirements change" is BOTH Project Risk AND Product Risk!
ποΈ Software Architecture Patterns
Architecture Pattern Selector
| Pattern | Use Case | Key Feature | Exam Keyword |
|---|---|---|---|
| Layered | Enterprise applications | Separation of concerns | "layers", "n-tier" |
| Client-Server | Distributed systems | Request-response model | "thin/fat client" |
| Pipe & Filter | Data transformations | Sequential processing | "batch", "sequential transformations" |
| Repository | Data-centric systems | Centralized data store | "shared data", "central database" |
| MVC | Web applications | Separation of UI/logic/data | "model-view-controller" |
Architecture Selection Example (From Final 2021):
Q: "System accepts batch of data and applies series of sequential transformations"
Step 1: Identify key requirements
β’ "batch of data" β Processing chunks
β’ "sequential transformations" β Step-by-step processing
Step 2: Match to patterns
a) Pipe & Filter β Sequential data flow β
b) Repository β Central data store β
c) Client-Server β Request-response β
d) Layered β Hierarchical organization β
Step 3: Verify match
β’ Pipe & Filter: data β filter1 β filter2 β output
Answer: a) Pipe & Filter Architecture
Q: "System accepts batch of data and applies series of sequential transformations"
Step 1: Identify key requirements
β’ "batch of data" β Processing chunks
β’ "sequential transformations" β Step-by-step processing
Step 2: Match to patterns
a) Pipe & Filter β Sequential data flow β
b) Repository β Central data store β
c) Client-Server β Request-response β
d) Layered β Hierarchical organization β
Step 3: Verify match
β’ Pipe & Filter: data β filter1 β filter2 β output
Answer: a) Pipe & Filter Architecture
Architecture Scenario Matching:
Scenario 1: "Multiple users accessing shared patient records"
Step 1: Key = "shared" data
Step 2: Central storage needed
Answer: Repository Architecture
Scenario 2: "Web app with separate UI, business logic, and database"
Step 1: Three distinct layers mentioned
Step 2: Each has specific responsibility
Answer: Layered/3-Tier Architecture
Scenario 3: "Compiler processing source code"
Step 1: Sequential: lexical β syntax β semantic β code gen
Step 2: Each stage transforms data
Answer: Pipe & Filter
Scenario 4: "Web application needing different views of same data"
Step 1: Multiple views of same data
Step 2: Separation of concerns needed
Answer: MVC Pattern
Scenario 1: "Multiple users accessing shared patient records"
Step 1: Key = "shared" data
Step 2: Central storage needed
Answer: Repository Architecture
Scenario 2: "Web app with separate UI, business logic, and database"
Step 1: Three distinct layers mentioned
Step 2: Each has specific responsibility
Answer: Layered/3-Tier Architecture
Scenario 3: "Compiler processing source code"
Step 1: Sequential: lexical β syntax β semantic β code gen
Step 2: Each stage transforms data
Answer: Pipe & Filter
Scenario 4: "Web application needing different views of same data"
Step 1: Multiple views of same data
Step 2: Separation of concerns needed
Answer: MVC Pattern
MVC Component Identification:
Q: "In online banking, where does password validation logic belong?"
Step 1: Understand MVC roles
β’ Model = Business logic & data
β’ View = Presentation/UI
β’ Controller = User input handling
Step 2: Classify "validation logic"
β’ It's business rule/logic
β’ Not UI, not input handling
Answer: Model
Q: "Where does the login button belong?"
Answer: View (UI element)
Q: "Where does click event handling go?"
Answer: Controller (handles user interaction)
Q: "In online banking, where does password validation logic belong?"
Step 1: Understand MVC roles
β’ Model = Business logic & data
β’ View = Presentation/UI
β’ Controller = User input handling
Step 2: Classify "validation logic"
β’ It's business rule/logic
β’ Not UI, not input handling
Answer: Model
Q: "Where does the login button belong?"
Answer: View (UI element)
Q: "Where does click event handling go?"
Answer: Controller (handles user interaction)
Architecture Quick Match:
β’ "Sequential/Transform" β Pipe & Filter
β’ "Shared data" β Repository
β’ "Layers/Tiers" β Layered
β’ "Request-Response" β Client-Server
β’ "Different views" β MVC
β’ "Sequential/Transform" β Pipe & Filter
β’ "Shared data" β Repository
β’ "Layers/Tiers" β Layered
β’ "Request-Response" β Client-Server
β’ "Different views" β MVC
MVC Components
- Model - Data and business logic
- View - Presentation/UI
- Controller - Handles user input, updates model/view
π§ͺ Software Testing (Essential for Finals!)
Testing Levels (Always asked!)
- Unit Testing - Individual components
- Integration Testing - Component interfaces
- System Testing - Complete system
- Acceptance Testing - Customer validation
Regression Testing = Re-testing after changes (maintenance phase)
Black Box vs White Box Testing
Black Box Testing
- No code knowledge needed
- Tests functionality
- Based on requirements
- Equivalence partitioning
- Boundary value analysis
White Box Testing
- Code knowledge required
- Tests internal structure
- Path coverage
- Statement coverage
- Branch coverage
- Basis Path Testing
π Basis Path Testing (White Box Technique)
Steps for Basis Path Testing:
- Draw Control Flow Graph (CFG)
- Nodes (circles) = Sequential statements
- Diamonds = Decision points (if/while conditions)
- Edges = Flow between nodes
- Label nodes: 1, 2, 3...
- Calculate Cyclomatic Complexity
V(G) = E - N + 2
Where: E = Edges, N = Nodes
OR
V(G) = P + 1
Where: P = Predicate nodes (conditions) - Determine Independent Paths
- Number of paths = Cyclomatic Complexity
- Each path must introduce at least one new edge
- Design Test Cases
- One test case for each independent path
- Ensure all statements executed at least once
Complete Worked Example (From your image):
Code:
β Step 1: Create Control Flow Graph
β’ Nodes: 1, 2, 3, 4, 5, 6 = 6 nodes
β’ Edges: Count all arrows
- 1β2, 2β3, 2β6 (while exits)
- 3β4, 3β5, 4β5, 5β2 (loop back)
β’ Total = 7 edges
β Step 3: Calculate Cyclomatic Complexity
Method 1: V(G) = E - N + 2
V(G) = 7 - 6 + 2 = 3
Method 2: V(G) = P + 1
Predicates: while (node 2), if (node 3) = 2
V(G) = 2 + 1 = 3
β Step 4: Identify 3 Independent Paths
Path 1: 1 β 2 β 6 (Empty array, N=0)
Path 2: 1 β 2 β 3 β 5 β 2 β 6 (No min update)
Path 3: 1 β 2 β 3 β 4 β 5 β 2 β 6 (Min updated)
β Step 5: Design Test Cases
Code:
min = A[0]; I = 1; while (I < N) { if (A[I] < min) min = A[I]; I++; }β Step 1: Create Control Flow Graph
Node 1: min = A[0]; I = 1;
β
Node 2: while (I < N) [Decision]
β True β False
Node 3: if(A[I] < min) Node 6: print min
β True β False
Node 4: min=A[I] Node 5: (skip)
β β
Node 5: I++
β_______|
β Step 2: Count Nodes and Edgesβ’ Nodes: 1, 2, 3, 4, 5, 6 = 6 nodes
β’ Edges: Count all arrows
- 1β2, 2β3, 2β6 (while exits)
- 3β4, 3β5, 4β5, 5β2 (loop back)
β’ Total = 7 edges
β Step 3: Calculate Cyclomatic Complexity
Method 1: V(G) = E - N + 2
V(G) = 7 - 6 + 2 = 3
Method 2: V(G) = P + 1
Predicates: while (node 2), if (node 3) = 2
V(G) = 2 + 1 = 3
β Step 4: Identify 3 Independent Paths
Path 1: 1 β 2 β 6 (Empty array, N=0)
Path 2: 1 β 2 β 3 β 5 β 2 β 6 (No min update)
Path 3: 1 β 2 β 3 β 4 β 5 β 2 β 6 (Min updated)
β Step 5: Design Test Cases
| Path | Test Data | Expected Output |
|---|---|---|
| 1 | A=[], N=0 | Error or undefined |
| 2 | A=[5,10], N=2 | min=5 |
| 3 | A=[10,5], N=2 | min=5 |
Another Example - With Nested Conditions:
Code:
Step 1: Draw CFG
β’ Node 1: Start
β’ Node 2: if (x > 0)
β’ Node 3: if (y > 0)
β’ Node 4: z = 1
β’ Node 5: z = 2
β’ Node 6: z = 3
β’ Node 7: End
Step 2: Count
β’ Nodes = 7, Edges = 8
β’ V(G) = 8 - 7 + 2 = 3
Step 3: Three paths needed
β’ Path 1: 1β2β6β7 (x β€ 0)
β’ Path 2: 1β2β3β4β7 (x > 0, y > 0)
β’ Path 3: 1β2β3β5β7 (x > 0, y β€ 0)
Step 4: Test cases
β’ Test 1: x=0, y=0 β z=3
β’ Test 2: x=1, y=1 β z=1
β’ Test 3: x=1, y=0 β z=2
Code:
if (x > 0) { if (y > 0) z = 1; else z = 2; } else z = 3;Step 1: Draw CFG
β’ Node 1: Start
β’ Node 2: if (x > 0)
β’ Node 3: if (y > 0)
β’ Node 4: z = 1
β’ Node 5: z = 2
β’ Node 6: z = 3
β’ Node 7: End
Step 2: Count
β’ Nodes = 7, Edges = 8
β’ V(G) = 8 - 7 + 2 = 3
Step 3: Three paths needed
β’ Path 1: 1β2β6β7 (x β€ 0)
β’ Path 2: 1β2β3β4β7 (x > 0, y > 0)
β’ Path 3: 1β2β3β5β7 (x > 0, y β€ 0)
Step 4: Test cases
β’ Test 1: x=0, y=0 β z=3
β’ Test 2: x=1, y=1 β z=1
β’ Test 3: x=1, y=0 β z=2
CFG Symbols: β = Statement node, β = Decision node, β = Control flow
Quick Check: If code has 2 if-statements, you need at least 3 test cases (2+1)
Quick Check: If code has 2 if-statements, you need at least 3 test cases (2+1)
Integration Testing Strategies
- Bottom-up - Test low-level modules first
- Top-down - Test high-level modules first
- Big-bang - Test all together (risky!)
- Sandwich - Combination of top-down and bottom-up
Testing Level Identification (Common MCQ):
Q: "Testing after maintenance phase with previous test cases is?"
Step 1: Keywords = "maintenance", "previous test cases"
Step 2: Recall testing types for changes:
β’ Unit Testing = Individual components β
β’ Integration = Component interfaces β
β’ System = Complete system β
β’ Regression = Re-test after changes β
Answer: d) Regression Testing
Q: "Testing after maintenance phase with previous test cases is?"
Step 1: Keywords = "maintenance", "previous test cases"
Step 2: Recall testing types for changes:
β’ Unit Testing = Individual components β
β’ Integration = Component interfaces β
β’ System = Complete system β
β’ Regression = Re-test after changes β
Answer: d) Regression Testing
Black Box Testing - Equivalence Partitioning:
Q: "Test a field that accepts age 18-65"
β Step 1: Identify partitions
β’ Invalid: age < 18
β’ Valid: 18 β€ age β€ 65
β’ Invalid: age > 65
β Step 2: Select test values (one from each)
β’ Partition 1: age = 10 (< 18)
β’ Partition 2: age = 40 (valid)
β’ Partition 3: age = 70 (> 65)
β Step 3: Add boundary values
β’ Lower boundary: 17, 18, 19
β’ Upper boundary: 64, 65, 66
Final Test Cases:
10 (invalid low), 17, 18, 19, 40 (valid middle), 64, 65, 66, 70 (invalid high)
Q: "Test a field that accepts age 18-65"
β Step 1: Identify partitions
β’ Invalid: age < 18
β’ Valid: 18 β€ age β€ 65
β’ Invalid: age > 65
β Step 2: Select test values (one from each)
β’ Partition 1: age = 10 (< 18)
β’ Partition 2: age = 40 (valid)
β’ Partition 3: age = 70 (> 65)
β Step 3: Add boundary values
β’ Lower boundary: 17, 18, 19
β’ Upper boundary: 64, 65, 66
Final Test Cases:
10 (invalid low), 17, 18, 19, 40 (valid middle), 64, 65, 66, 70 (invalid high)
Integration Testing Strategy Selection:
Q: "You have Login β Database β Payment modules. Which integration approach?"
Bottom-Up Approach:
Step 1: Test Database (lowest level)
Step 2: Test Database + Payment
Step 3: Test Login + Database
Step 4: Test all together
Pros: No stubs needed / Cons: UI tested last
Top-Down Approach:
Step 1: Test Login (with stubs for others)
Step 2: Test Login + Database (stub Payment)
Step 3: Test all together
Pros: UI tested first / Cons: Many stubs needed
Best Choice: Bottom-up (critical payment logic tested early)
Q: "You have Login β Database β Payment modules. Which integration approach?"
Bottom-Up Approach:
Step 1: Test Database (lowest level)
Step 2: Test Database + Payment
Step 3: Test Login + Database
Step 4: Test all together
Pros: No stubs needed / Cons: UI tested last
Top-Down Approach:
Step 1: Test Login (with stubs for others)
Step 2: Test Login + Database (stub Payment)
Step 3: Test all together
Pros: UI tested first / Cons: Many stubs needed
Best Choice: Bottom-up (critical payment logic tested early)
Test Case Design Problem:
Q: "Design test cases for: if (x > 10 && y < 5) output = 'A' else output = 'B'"
β Step 1: Identify decision conditions
β’ Condition 1: x > 10
β’ Condition 2: y < 5
β’ Combined: BOTH must be true for 'A'
β Step 2: Create decision table
β Step 3: Add boundary cases
β’ Test 5: x=10, y=3 β 'B' (boundary)
β’ Test 6: x=11, y=5 β 'B' (boundary)
β’ Test 7: x=11, y=4 β 'A' (just inside)
Q: "Design test cases for: if (x > 10 && y < 5) output = 'A' else output = 'B'"
β Step 1: Identify decision conditions
β’ Condition 1: x > 10
β’ Condition 2: y < 5
β’ Combined: BOTH must be true for 'A'
β Step 2: Create decision table
| Test | x > 10 | y < 5 | Expected |
|---|---|---|---|
| 1 | T (x=15) | T (y=3) | 'A' |
| 2 | T (x=15) | F (y=7) | 'B' |
| 3 | F (x=5) | T (y=3) | 'B' |
| 4 | F (x=5) | F (y=7) | 'B' |
β’ Test 5: x=10, y=3 β 'B' (boundary)
β’ Test 6: x=11, y=5 β 'B' (boundary)
β’ Test 7: x=11, y=4 β 'A' (just inside)
Testing Quick Rules:
β’ Number of test cases = 2^n (n = conditions) for complete coverage
β’ Always test: Valid, Invalid, Boundary, Null/Empty
β’ Integration order: Critical β Supporting β UI
β’ Number of test cases = 2^n (n = conditions) for complete coverage
β’ Always test: Valid, Invalid, Boundary, Null/Empty
β’ Integration order: Critical β Supporting β UI
π Software Design Concepts
Cohesion vs Coupling
Cohesion (WANT HIGH!)
- Intra-module strength
- How related elements are within module
- High cohesion = Good design
- Single, well-defined purpose
Coupling (WANT LOW!)
- Inter-module dependency
- How modules depend on each other
- Low coupling = Good design
- Independent modules
Mnemonic: "High Cohesion, Low Coupling" = HCLC = Healthy Code, Long-lasting Code
Design Quality Attributes
- Correctness - No bugs inhibiting function
- Commodity/Suitability - Suitable for intended purpose
- Usability - Pleasant user experience
- Consistency - No contradictions or omissions
Cohesion vs Coupling MCQ (From Finals):
Q: "Which defines the degree of intra-dependability within elements of a module?"
Step 1: Parse the question
β’ "intra" = within/inside
β’ "within elements of a module" = inside one module
Step 2: Recall definitions
β’ Cohesion = INTRA-module (within) β
β’ Coupling = INTER-module (between) β
Answer: a) Cohesion
Q: "Which defines the degree of intra-dependability within elements of a module?"
Step 1: Parse the question
β’ "intra" = within/inside
β’ "within elements of a module" = inside one module
Step 2: Recall definitions
β’ Cohesion = INTRA-module (within) β
β’ Coupling = INTER-module (between) β
Answer: a) Cohesion
Design Quality Example:
Q: "Good design where program is suitable for intended purpose is?"
Step 1: Match description to attributes
β’ Correctness = No bugs β
β’ Commodity/Suitability = Suitable for purpose β
β’ Usability = Pleasant experience β
β’ Consistency = No contradictions β
Answer: b) Commodity
Q: "Good design where program is suitable for intended purpose is?"
Step 1: Match description to attributes
β’ Correctness = No bugs β
β’ Commodity/Suitability = Suitable for purpose β
β’ Usability = Pleasant experience β
β’ Consistency = No contradictions β
Answer: b) Commodity
Cohesion Analysis - Practical Example:
Evaluate this class for cohesion:
β’ validateEmail β (user-related)
β’ calculateTax β (not user management)
β’ saveUser β (user-related)
β’ sendEmail β (user communication)
β’ generateReport β (could be any report)
Step 2: Evaluate cohesion level
β’ Mixed responsibilities = LOW cohesion (BAD)
Step 3: Improve by splitting:
β’ UserManager: validateEmail, saveUser, sendEmail
β’ TaxCalculator: calculateTax
β’ ReportGenerator: generateReport
Result: HIGH cohesion (GOOD)
Evaluate this class for cohesion:
class UserManager {
validateEmail()
calculateTax() // ???
saveUser()
sendEmail()
generateReport() // ???
}
Step 1: Check if all methods relate to single purposeβ’ validateEmail β (user-related)
β’ calculateTax β (not user management)
β’ saveUser β (user-related)
β’ sendEmail β (user communication)
β’ generateReport β (could be any report)
Step 2: Evaluate cohesion level
β’ Mixed responsibilities = LOW cohesion (BAD)
Step 3: Improve by splitting:
β’ UserManager: validateEmail, saveUser, sendEmail
β’ TaxCalculator: calculateTax
β’ ReportGenerator: generateReport
Result: HIGH cohesion (GOOD)
Coupling Analysis - Practical Example:
Version 1: Creates its own dependencies = TIGHT coupling
Version 2: Dependencies injected = LOOSE coupling
Better: Version 2 (can test, change implementations easily)
// HIGH Coupling (BAD)
class Order {
Database db = new Database();
EmailService email = new EmailService();
PaymentGateway payment = new PaymentGateway();
processOrder() {
db.connect();
payment.charge();
email.send();
}
}
// LOW Coupling (GOOD)
class Order {
processOrder(IDatabase db, IEmail email, IPayment payment) {
db.save(this);
payment.charge(amount);
email.notify(customer);
}
}
Analysis:Version 1: Creates its own dependencies = TIGHT coupling
Version 2: Dependencies injected = LOOSE coupling
Better: Version 2 (can test, change implementations easily)
SOLID Principles Quick Check:
Q: "A class should have only one reason to change" - Which principle?
Step 1: Match to SOLID
β’ S = Single Responsibility β
β’ O = Open/Closed
β’ L = Liskov Substitution
β’ I = Interface Segregation
β’ D = Dependency Inversion
Answer: Single Responsibility Principle
Q: "A class should have only one reason to change" - Which principle?
Step 1: Match to SOLID
β’ S = Single Responsibility β
β’ O = Open/Closed
β’ L = Liskov Substitution
β’ I = Interface Segregation
β’ D = Dependency Inversion
Answer: Single Responsibility Principle
Remember the Goal:
β’ HIGH Cohesion = Related things together (GOOD)
β’ LOW Coupling = Independent modules (GOOD)
β’ Mnemonic: "HC-LC" = Healthy Code - Lasting Code
β’ HIGH Cohesion = Related things together (GOOD)
β’ LOW Coupling = Independent modules (GOOD)
β’ Mnemonic: "HC-LC" = Healthy Code - Lasting Code
β‘ Quick Exam Reference
Common Traps to Avoid
- β Waterfall is NOT suitable for accommodating changes
- β Scrum Master is NOT a project manager
- β Sprint Backlog is NOT for Product Owner to manage
- β Requirements change affects BOTH project and product risk
- β Sprints are NEVER extended for incomplete work
Must-Remember Numbers
- Scrum team size: 7 (max 10)
- Sprint duration: 2-4 weeks
- Daily Scrum: 15 minutes
- CMM Levels: 1-5 (Initial to Optimizing)
Acronyms to Know
| CMM | Capability Maturity Model | Process improvement |
| XP | Extreme Programming | Agile methodology |
| MVC | Model-View-Controller | Architecture pattern |
| WBS | Work Breakdown Structure | Project tasks |
| CPM | Critical Path Method | Project scheduling |
Last-Minute Checklist
- β Know all Scrum roles and artifacts
- β Can calculate critical path (ES, EF, LS, LF, Slack)
- β Know when to use each process model
- β Can distinguish functional vs non-functional requirements
- β Know testing levels order
- β Remember cohesion (high) vs coupling (low)
- β Can identify architecture patterns from descriptions