Theory
वे Documents जो एक Project को Describe करते हैं
एक software project technical documents के एक set से describe होता है, हर एक इसकी story का एक अलग हिस्सा capture करते हुए। हर एक क्या है यह जानना, और इन्हें clearly produce करना, एक professional skill है और directly आपकी project report shape करती है।
यह lesson core technical documents list करता है: problem statement और requirements (what और why), UML और ER जैसे design diagrams (यह कैसे structured है), और testing और deployment documentation (यह काम करता है, और इसे कैसे run करें)। आपने अपने project के लिए इनमें से ज़्यादातर create किए; यहाँ हम इन्हें एक coherent set की तरह name करते हैं। साथ में, ये एक project को पूरी तरह और professionally document करते हैं।
At a glance
| Document | यह क्या Capture करता है |
|---|---|
| Problem Statement और Requirements | कौन सी problem solve होती है और system को क्या करना चाहिए (functional और non-functional) |
| Design Diagrams (UML, ER) | System कैसे structured है: UML (class, use-case, sequence), ER (database), architecture, DFD |
| Testing Documentation | Test plans, test cases, और test results/reports (evidence यह काम करता है) |
| Deployment Documentation | System कैसे deployed, installed, और run होता है (plus user docs) |
Theory
Requirements, Design Diagrams, Testing, Deployment
Problem statement और requirements story open करते हैं: project कौन सी problem solve करता है और, SRS में, exactly system को क्या करना चाहिए (functional और non-functional)। यह what और why है।
Design diagrams how दिखाते हैं। UML diagrams software structure और behaviour model करते हैं, एक class diagram classes और इनके relationships दिखाता है, एक use-case diagram दिखाता है users क्या कर सकते हैं, एक sequence diagram दिखाता है objects समय के साथ कैसे interact करते हैं। ER diagrams database model करते हैं। Architecture और DFDs picture complete करते हैं।
Testing documentation (test plans, cases, और result reports) evidence provide करता है system काम करता है, क्या test हुआ और outcomes। Deployment documentation explain करता है system को कैसे deploy और run करें, plus user instructions। हर document एक dimension cover करता है; साथ में ये पूरे project को describe करते हैं।
Quiz
कौन से technical documents दिखाते हैं एक project का system कैसे structured है?
- Test result reports
- UML (class, use-case, sequence) जैसे design diagrams और ER diagrams, plus architecture और DFDs
- सिर्फ़ deployment guide
- सिर्फ़ problem statement
Show the answer
UML (class, use-case, sequence) जैसे design diagrams और ER diagrams, plus architecture और DFDs
Design diagrams, UML diagrams (class, use-case, sequence), ER diagrams (database), plus architecture diagrams और DFDs, वे हैं जो दिखाते हैं एक system कैसे STRUCTURED है (इसका design)। Option A, test result reports, evidence provide करता है system काम करता है (testing), यह कैसे structured है नहीं। Option C, deployment guide, explain करता है system को कैसे deploy और run करें, एक अलग concern। Option D, problem statement, बताता है कौन सी problem solve होती है और क्यों, system कैसे built है नहीं। हर document एक dimension cover करता है: requirements (what/why), design diagrams (कैसे structured है), testing (यह काम करता है), deployment (कैसे run करें)।
Think first
एक Big Description की बजाय कई अलग-अलग Documents क्यों Produce करें?
Project की documentation को separate documents (requirements, design, testing, deployment) में क्यों split करें एक की बजाय? फिर tap कीजिए।
Show the answer
क्योंकि हर document एक DIFFERENT PURPOSE और AUDIENCE serve करता है, और इन्हें separate रखना हर एक को focused, findable, और maintainable रखता है, जबकि सब कुछ एक giant description में cram करना confusing, navigate करना hard, और up to date रखना hard होता। सोचिए किसे क्या चाहिए। कोई जो verify कर रहा है system को WHAT करना चाहिए (एक client, एक tester, एक evaluator requirements met हुईं यह check करते हुए) को requirements/SRS चाहिए, और वे इसे design internals या deployment steps के through wade किए बिना find करने में able होने चाहिए। STRUCTURE समझने या extend करने की ज़रूरत वाले एक developer को design diagrams चाहिए (UML, ER), और वे इन्हें साथ और clear चाहते हैं, test cases के बीच buried नहीं। कोई जो check कर रहा है system WORKS यह करता है उसे testing documentation चाहिए (plans, cases, results)। इसे run या install करने के task वाले किसी को deployment documentation चाहिए। इनमें से हर reader का एक distinct question है, और dedicated documents हर एक को exactly relevant part quickly find और इस्तेमाल करने देते हैं। Separation MAINTENANCE भी aid करता है: जब design change होता है, आप design document update करते हैं; जब tests change होते हैं, test docs; unrelated content disturb किए बिना, तो हर एक accurate रहता है। एक single mega-document, इसके contrast में, सभी concerns को साथ mix करता है, तो readers को उनकी ज़रूरत का piece hunt करना पड़ता है, related information scattered है, और एक aspect update करना दूसरों के साथ tangling का risk लेता है, पूरी चीज़ को जल्दी stale और unwieldy बनाते हुए। यह separation-of-concerns principle को mirror करता है जो आप पूरे engineering में मिले हैं: distinct चीज़ों को distinct रखिए तो हर एक clear और manageable रहे। आपकी project report के लिए, ये documents report के SECTIONS (requirements, design, testing, deployment) से भी map होते हैं, तो इन्हें separately produce करना मतलब है आपकी report practically खुद-ब-खुद लिख जाती है। तो multiple focused documents extra bureaucracy नहीं हैं; ये वह तरीका है जिससे आप documentation को clear, navigable, और maintainable रखते हैं, हर एक एक kind के reader के लिए एक kind का question answer करते हुए। एक tangled description से distinct concerns के लिए distinct documents बेहतर हैं।
Summary
Key takeaways
- एक project technical documents के एक set से describe होता है, हर एक इसकी story का एक अलग हिस्सा capture करते हुए।
- Problem statement और requirements (SRS) बताते हैं कौन सी problem solve होती है और system को क्या करना चाहिए (what और why)।
- Design diagrams structure दिखाते हैं: UML (class, use-case, sequence diagrams), ER diagrams (database), plus architecture और DFDs।
- Testing documentation (test plans, cases, और result reports) evidence provide करता है system काम करता है।
- Deployment documentation explain करता है system को कैसे deploy, install, और run करें, plus user instructions।
- Separate, focused documents हर एक एक different purpose और audience serve करते हैं, clear, findable, और maintainable रहते हुए, और ये आपकी report के sections से map होते हैं।
- Memory hook: requirements (what/why), design diagrams UML/ER (कैसे structured), testing (यह काम करता है), deployment (कैसे run करें)।