4.5.1
Intuition 30-second pictureSDLC (Software Development Life Cycle) bas wo recipe hai jo ek team follow karti hai — ek vague wish ("humein ek app chahiye") ko working, maintained software mein convert karne ke liye . Neeche har model ek hi sawaal ka alag jawab deta hai:
"Hum decisions kab lock karte hain, aur feedback kab lete hain?"
Waterfall sab kuch pehle lock kar leta hai, feedback bahut baad mein aata hai.V-Model waterfall hi hai + har design step ka ek testing twin hota hai.Iterative pehle ek rough poora version banata hai, phir re-loop karke improve karta hai.Agile almost kuch bhi lock nahi karta, feedback lagaataar aata rehta hai.
Poora chapter actually ek kahaani hai "galat hone ka cost late ho" vs. "galat hone ka chaos baar baar ho" ke baare mein.
Intuition Core economic factProject mein koi defect jitna gehra ghus jaata hai use find karne se pehle, usse fix karna utna hi zyada costly hota hai. Yahi famous cost-of-change curve hai: agar ek galat samjhi hui requirement ko requirements phase mein fix karna 1× cost karta hai, toh design mein roughly 10×, coding mein 100×, aur release ke baad 1000× cost karta hai.
Har SDLC model ek strategy hai jo defect-detection ko PEHLE push karne ki koshish karta hai (ya loops ko itna sasta banata hai ki late hona bhi zyada hurt nahi karta).
Definition Classic five phases
Requirements — software ko kya karna chahiye? ("wishes")Design — yeh kaise structured hoga? (architecture + modules)Implementation (coding) — actual code likho.Testing (verification & validation) — kya yeh spec aur need se match karta hai?Deployment & Maintenance — ship karo, phir poori life mein fix/extend karo.
Phases mein split kyun karte hain? Kyunki insaan ek saath "sab kuch" apne dimag mein nahi rakh sakta. Phases = time mein separation of concerns .
Definition Waterfall modelEk linear, sequential model jahan har phase poori tarah complete aur sign off honi chahiye pehle ki agli shuru ho. Ek phase ka output = agli phase ka input, bilkul "neeche ki taraf" behta hai jaise paani — koi wapas jaana nahi (pure form mein).
Intuition Yeh kyun banaya gaya tha aur kab yeh shine karta haiYeh manufacturing & construction ke kaam karne ke tarike se mila hua hai: chhat banane ke baad neenva (foundation) nahi daal sakte. Waterfall assume karta hai ki requirements stable hain aur pehle se achhi tarah samjhi gayi hain . Yeh tab shine karta hai jab late change ki cost waise bhi unavoidable ho (e.g. safety-critical firmware, regulatory/contract-bound projects ) aur documentation mandatory ho.
Common mistake Steel-man: "Waterfall bas outdated hai aur hamesha bura hota hai."Yeh sahi kyun lagta hai: Agile marketing ne humein isse sneer karna sikhaya; real projects mein rarely frozen requirements hoti hain.
Fix: Waterfall tab optimal hota hai jab requirements sach mein frozen HO aur change forbidden ho (medical device certification, fixed-price government contracts). Failure mode waterfall khud nahi hai — balki isse tab use karna jab requirements actually volatile hain. Model ko requirement-stability se match karo, fashion se nahi.
Intuition Yeh waterfall mein kya add karta haiWaterfall ko ek V ki shape mein mod do. Left arm neeche jaana = decomposition (requirements → design → code). Right arm upar jaana = integration/testing. Killer idea: left side ka har development phase, right side ke ek test phase ke saath same level par pair hota hai .
Requirements ⟷ Acceptance testing (kya yeh user need poori karta hai?)
System design ⟷ System testing
Architecture/high-level design ⟷ Integration testing
Module/detailed design ⟷ Unit testing
(V ka bottom) ⟷ Coding
Intuition WHY pair karte hain — sabse gehri baatJab tum ek requirement likhte ho, tum turant design karte ho ki tum kaise prove karoge ki yeh met hai . Isse requirements testable banna zaroori ho jaata hai, vague wishes ("fast hona chahiye") ko pehle hi pakad leta hai kyunki tum khud se poochhne par majboor ho "main 'fast' ko kaise test karunga?". Verification ("kya humne ise sahi banaya?") upar jaate waqt hoti hai; validation ("kya humne sahi cheez banayi?") top par.
Verification vs Validation mein confusion
Kyun confused hote hain: Dono ka matlab roz-marra English mein "checking" hota hai.
Fix mnemonic: Ver ification = "kya humne cheez sahi (right) banayi?" (spec ke against). Validation = "kya humne valid cheez banayi?" (user ki real need ke against). Tum ek product ko perfectly verify kar sakte ho jo kisi ne chahaa hi nahi tha.
Definition Iterative modelSystem ko baar baar cycles (iterations) mein banao, har baar ek working — lekin pehle crude — version of the whole product milta hai, har loop mein refine hota hai. Incremental har loop mein nayi pieces add karta hai; real projects dono blend karte hain ("iterative & incremental").
Intuition WHY ek bade pass ki jagah loop karte hainKyunki tum ise run hote dekh kar seekhte ho. Iteration "paper par design karo, umeed karo yeh sahi hai" ko "kuch chhota ship karo, measure karo, correct karo" mein convert karta hai. Yeh risk ko pehle tackle karta hai: sabse scary/uncertain part iteration 1 mein karo, taki agar yeh impossible hai toh tum saste mein pata lag jaaye.
Isse Forecast-then-Verify jo process mein built-in ho samjho: har iteration ek hypothesis hai ("yeh design kaam karega") jo ek running build ke against test hoti hai.
Worked example Search engine par Iterative vs Waterfall
Waterfall: poore ranking algorithm, full UI, sab filters spec karo → 9 mahine → pehla demo. Agar ranking galat hai, toh 9 mahine mein pata chalega (cost ≈ k 4 Iterative: iter1 = basic keyword search end-to-end (2 hafte). Users ko dikhao. iter2 = ranking add karo. iter3 = filters. Har loop running software deta hai, toh galat ranking iter2 mein pakdi jaayegi, 9 mahine mein nahi.
Yeh step (users ko pehle dikhana) kyun? Yeh cost-of-change curve ko collapse karta hai kyunki defects chaar phases deep ki jagah ek iteration deep mein detect hoti hain.
Yeh koi single process nahi balki ek mindset / family of iterative methods hai (Scrum, XP, Kanban) jo Agile Manifesto (2001) par bani hai. Kaam chhote, fixed-length sprints / iterations (1–4 hafte) mein hota hai, har baar potentially shippable increments deliver hote hain, aur continuous customer collaboration hoti hai.
Intuition WHY agile waterfall ko beat karta hai jab requirements baar baar badalti hainAgar requirements har mahine badalti hain, toh waterfall ka pehla "lock" lagaataar invalidate hota rehta hai → endless expensive rework. Agile kabhi aage ka lock nahi karta ; yeh har sprint mein re-plan karta hai, toh ek requirement change bas agli sprint ke backlog mein near-1× cost par ghus jaata hai. Agile ek tax deta hai (constant re-planning ka overhead, kam up-front architecture) saste change kharidne ke liye.
Common mistake Steel-man: "Agile ka matlab koi documentation aur planning nahi."Kyun sahi lagta hai: "Working software over comprehensive documentation" sunne mein lagta hai "docs skip karo."
Fix: Yeh kehta hai jab trade-off karna ho toh working software prefer karo — docs bilkul khatam karo nahi. Saari design skip karna ("cowboy coding") aur isse Agile kehna #1 abuse hai. Agile phir bhi plan karta hai (sprint planning, backlog), phir bhi document karta hai (just enough, just in time).
Intuition Woh 20% jo 80% answer decide karta haiSirf poochho: Requirements kitni stable hain, aur late change kitna costly hai?
Stable + change forbidden/regulated → Waterfall / V-Model .
Bada & risky + running checkpoints chahiye → Iterative .
Volatile + customer available + fast feedback wins → Agile .
Model
Feedback timing
Best when
Weakness
Waterfall
Late (testing ke baad)
Frozen reqs, heavy docs
Late discovery = k 4
V-Model
Test pehle design hota hai, run late
Safety-critical, traceability
Change ke liye abhi bhi rigid
Iterative
Har cycle ke baad
Bada, high-risk, evolving
Achhi iteration planning chahiye
Agile
Har sprint (continuous)
Volatile reqs, close customer
Fixed contracts mein scope/budget mushkil
Sabhi SDLC models ke existence ko kaun sa economic curve justify karta hai? Cost-of-change/defect curve — defect fix karna har baad wale phase mein ~10× zyada expensive ho jaata hai (c p ≈ c 0 k p
Waterfall ko ek line mein define karo. Ek linear, sequential model jahan har phase poori tarah complete aur sign off hoti hai agli shuru hone se pehle, koi wapas jaana nahi.
Waterfall actually sahi choice kab hota hai? Jab requirements stable/frozen hoon aur change forbidden ya waise bhi costly ho (e.g. regulated, safety-critical, fixed contracts).
V-Model Waterfall mein kya add karta hai? Yeh har development (left arm) phase ko same level par ek corresponding testing (right arm) phase ke saath pair karta hai.
V-Model pairing: requirements ⟷ ? aur module design ⟷ ? Requirements ⟷ acceptance testing; module/detailed design ⟷ unit testing.
Verification vs Validation? Verification = "kya humne ise sahi banaya?" (spec ke against). Validation = "kya humne sahi cheez banayi?" (user need ke against).
Iterative model ka core idea? System ko baar baar cycles mein banao, har baar ek running lekin crude version milta hai jo loops mein refine hota hai; risky parts pehle tackle hote hain.
Iteration defect cost kyun reduce karta hai? Yeh defects ko phases deep ki jagah ek iteration deep (running software) mein detect karta hai, cost-of-change curve ko collapse karta hai.
Kya Agile ek single process hai? Nahi — yeh ek mindset/family hai (Scrum, XP, Kanban) jo Agile Manifesto par based hai, chhote sprints mein continuous feedback ke saath kaam karta hai.
4 Agile Manifesto values batao. Individuals & interactions > processes & tools; working software > comprehensive docs; customer collaboration > contract negotiation; responding to change > following a plan.
SDLC model choose karne ka ek sawaal? Requirements kitni stable hain aur late change kitna costly hai?
Common Agile myth aur uska correction? Myth: "no docs/no planning." Correction: trade-offs mein working software prefer karo, lekin phir bhi plan karo (sprints/backlog) aur just enough document karo.
Recall Feynman: ek 12-saal ke bacche ko samjhaoSocho apne dost ke liye LEGO castle banana.
Waterfall: tumhara dost poore castle ko ek baar describe karta hai, tum apne kamre mein jaate ho, poori cheez secretly banate ho, aur end mein dikhate ho. Agar unhein drawbridge chahiye tha — toh ab kuch nahi ho sakta, tumhe woh wall todhni padegi jo tumne glue ki thi.
V-Model: same, lekin har part ke liye jo tumhara dost describe karta hai, tum yeh bhi agree karte ho ki tum ise kaise check karoge ("gate khulna chahiye" → "hum ise push karke test karenge"). Toh tum kuch bhi test karna nahi bhoolte.
Iterative: tum jaldi se ek chhota rough castle banate ho, dost ko dikhate ho, phir baar baar improve karte rehte ho.
Agile: tumhara dost poore time tumhare saath baithta hai ; har kuch minutes mein tum progress dikhate ho aur woh kehta hai "aur towers chahiye!" toh tum kabhi zyada der tak galat cheez nahi banate.
Badi seekh: jitna zyada tum apna kaam dikhane mein wait karte ho, utni zyada expensive tumhari galtiyan hoti hain.
Mnemonic 4 models aur unka feeling yaad karo"Water Vanishes Into Air" → W aterfall (rigid paani neeche bahta hai), V -model (testing twin), I terative (re-loops), A gile (hawa ki tarah halka, hamesha badalta).
Aur V-Model ke liye: "Ver = Right (spec), Val = Valid (need)."
Worked example Mini end-to-end: regulation ke under ek banking appRequirements legally fixed hain; auditors ko har rule se ek test tak traceability chahiye.
V-Model yahan kyun jeet jaata hai: Har regulatory requirement design time par ek acceptance/system test ke saath pair hoti hai → full traceability matrix. Volatility kam hai, toh Agile ki constant re-planning koi fayda nahi deti aur audit trail ko kamzor kar deti.
Yeh step (tests pehle pair karna) kyun? Regulators iska proof maangte hain ki har requirement verify ki gayi hai; V-Model woh proof structure mein hi bake kar deta hai.
Cost of Change Curve — har model ke peeche economic engine.Verification and Validation — V-model ki backbone.Scrum / Kanban / Extreme Programming — concrete Agile flavours.Requirements Engineering — woh phase jिसकी stability model decide karti hai.Software Testing — Unit Integration System Acceptance — V ka right arm.Risk Management — iterative scary parts ko front-load kyun karta hai.
locks nothing constant feedback
