Theory
Software का एक Life Cycle होता है
Software एक leap में build नहीं होता; यह phases के एक life cycle से गुज़रता है, need समझने से finished system maintain करने तक। यही Software Development Life Cycle (SDLC) है, और हर phase पर, documentation capture करता है क्या decide और done हुआ।
आपने अपने project में यह जिया। यह lesson इसे explicitly frame करता है, और एक important distinction add करता है: आप कितना document करते हैं यह depend करता है आप कौन सा model follow करते हैं इस पर। Traditional models upfront heavily document करते हैं; Agile lightly और continuously document करता है। SDLC और इन models को समझना आपकी report और professional life के लिए matter करता है, जहाँ आप इनमें से एक approach के under काम करेंगे।
At a glance
| Phase | Produce हुई Documentation |
|---|---|
| Requirements | SRS (system को क्या करना चाहिए) |
| Design | Design documents और diagrams (architecture, UML, ER, DFD) |
| Implementation | Code, comments और inline docs के साथ |
| Testing | Test plans, test cases, और test reports |
| Deployment / Maintenance | Deployment guides और user documentation |
Theory
हर Phase पर Documentation
हर SDLC phase एक documentation trail छोड़ता है जो इसके decisions record करता है।
Requirements SRS produce करता है (system को क्या करना चाहिए)। Design design documents और diagrams produce करता है (architecture, UML, ER, DFD)। Implementation helpful comments के साथ code produce करता है। Testing test plans, cases, और reports produce करता है (क्या test हुआ और results)। Deployment और maintenance deployment guides और user documentation produce करते हैं।
यह documentation matter करती है क्योंकि यह दूसरों (और आपके future self) को system समझने और maintain करने देती है, और यह directly आपकी project report में feed होती है। हर phase की docs यह memory हैं चीज़ें क्यों और कैसे की गईं, तो phase खत्म होने पर कुछ भी important lost न हो।
Theory
Traditional vs Agile Documentation
आप कितना document करते हैं यह development model पर depend करता है।
Traditional models (Waterfall जैसे) sequential हैं: हर phase, heavy, detailed documentation के साथ, अगला शुरू होने से पहले complete होता है। आप requirements thoroughly document करते हैं, फिर design thoroughly, और वगैरह। यह stable, well-understood requirements वाले projects को suit करता है।
Agile iterative है: work short cycles (sprints) में proceed करता है, frequently working software deliver करते हुए और change के लिए adapt करते हुए, exhaustively upfront की बजाय continuously produced lighter, just-enough documentation के साथ। Agile heavy paperwork से ज़्यादा working software और responsiveness को value करता है।
कोई भी simply 'better' नहीं है; ये अलग situations को suit करते हैं। पर difference जानना आपको बताता है आपका context कौन सा level of documentation expect करता है, exhaustive और upfront, या lean और continuous।
Quiz
Traditional (Waterfall) और Agile models के बीच documentation कैसे अलग है?
- Agile को Waterfall से कहीं ज़्यादा heavy up-front documentation चाहिए
- Traditional/Waterfall sequence में heavily upfront document करता है, जबकि Agile continuously produced lighter, just-enough documentation इस्तेमाल करता है और change के लिए adapt करता है
- कोई भी model कोई documentation इस्तेमाल नहीं करता
- ये exactly same तरीके से document करते हैं
Show the answer
Traditional/Waterfall sequence में heavily upfront document करता है, जबकि Agile continuously produced lighter, just-enough documentation इस्तेमाल करता है और change के लिए adapt करता है
Traditional/Waterfall models sequential हैं और अगले phase पर जाने से पहले heavily और thoroughly UPFRONT document करते हैं, जबकि Agile iterative है और continuously produced LIGHTER, just-enough documentation इस्तेमाल करता है, working software और change के लिए adapting को favour करते हुए। Option A इन्हें reverse करता है: Waterfall है, Agile नहीं, जो heavy up-front documentation पर emphasise करता है। Option C wrong है: दोनों models documentation इस्तेमाल करते हैं, ये कितना और कब में अलग हैं, whether में नहीं। Option D wrong है: ये काफ़ी अलग document करते हैं (heavy-and-up-front vs lean-and-continuous)। Difference जानना आपको बताता है आपका project या workplace कौन सी documentation expect करता है।
Think first
Agile Lighter Documentation क्यों Favour करता है, और क्या यह एक Good चीज़ है?
Documentation valuable है, तो Agile deliberately इसमें से कम क्यों produce करता है? फिर tap कीजिए।
Show the answer
क्योंकि Agile CHANGE का RESPOND करना और WORKING SOFTWARE deliver करना prioritise करता है, और heavy up-front documentation एक costly burden बन सकती है जो requirements change होते ही out of date हो जाती है, तो Agile documentation को LEAN और CONTINUOUS रखता है, useful होने के लिए enough पर इतना नहीं कि यह adaptation slow करे, जो उन projects के लिए एक good fit है जहाँ requirements evolve होती हैं। Reasoning heavy up-front documentation की एक real problem से शुरू होती है: बहुत सारे projects में, especially modern software में, requirements start में पूरी तरह known या stable NOT हैं; ये change होती हैं जैसे users feedback देते हैं, market shift होता है, और team सीखती है। अगर आप upfront exhaustive documentation में heavily invest करते हैं (जैसे strict Waterfall करता है), फिर जब requirements change होती हैं, वह documentation का ज़्यादातर हिस्सा outdated या wrong हो जाता है, और इसे perfectly current रखना effort consume करता है जो actual software build करने में जा सकता था। Agile इसका response 'working software over comprehensive documentation' और 'responding to change over following a plan' (Agile principles से) value करके देता है: यह effectively communicate और coordinate करने के लिए बस ENOUGH documentation produce करता है, work proceed होते हुए continuously created, और यह understanding convey करने के लिए close collaboration, conversation, और working software खुद पर ज़्यादा rely करता है। यह team को flexible और fast रहने देता है, paperwork का एक mountain drag किए बिना change के लिए adapt करते हुए। क्या यह एक good चीज़ है? यह context पर depend करता है, जो honest answer है। EVOLVING requirements और speed और adaptability की ज़रूरत वाले projects के लिए (modern software और startups में common), Agile की lean documentation एक strength है। STABLE, well-understood requirements वाले projects के लिए, या जहाँ regulation, safety, या large teams thorough records demand करती हैं (aerospace, medical, big enterprise systems), heavier documentation genuinely valuable है और Waterfall-style thoroughness sense बनाती है। तो Agile की lighter documentation laziness या documentation की value का rejection नहीं है; यह एक deliberate trade-off है जो adaptability और working software prioritise करता है, जहाँ change expected है वहाँ appropriate, जबकि acknowledge करते हुए दूसरे contexts को ज़्यादा चाहिए। Professional skill यह जानना है कौन सा approach आपकी situation को fit करता है, और इसके लिए right level पर document करना, यह assume करने की बजाय ज़्यादा (या कम) documentation हमेशा better है। Context के लिए right amount of documentation, maximum या minimum नहीं, goal है।
Summary
Key takeaways
- Software Software Development Life Cycle (SDLC) के through build होता है: requirements, design, implementation, testing, deployment, और maintenance।
- हर phase documentation produce करता है: requirements -> SRS; design -> design docs/diagrams; implementation -> code+comments; testing -> test plans/reports; deployment -> deployment/user docs।
- यह documentation decisions record करती है तो system समझा और maintain किया जा सके, और यह आपकी project report में feed होती है।
- Traditional/Waterfall models sequential हैं heavy, detailed documentation के साथ upfront done।
- Agile iterative है (sprints) continuously produced lighter, just-enough documentation के साथ, working software और change के लिए adapting को favour करते हुए।
- Agile lightly document करता है flexible रहने के लिए जब requirements evolve होती हैं; heavier documentation stable requirements या regulated/large projects को suit करती है।
- Memory hook: SDLC phases हर एक documentation छोड़ता है; Waterfall heavy-and-up-front document करता है, Agile lean-and-continuous, context के लिए right amount।