Theory
Project describe કરતા documents
Software projectને અનેક technical documents દ્વારા describe કરવામાં આવે છે. દરેક document project storyનો અલગ ભાગ capture કરે છે. કયા documentમાં શું હોય છે તે જાણવું અને તેને clear રીતે તૈયાર કરવું professional skill છે અને project report પર સીધી અસર કરે છે.
Core documents છે: problem statement અને requirements (what અને why), UML અને ER જેવા design diagrams (system કેવી રીતે structured છે), અને testing તથા deployment documentation (system કામ કરે છે અને કેવી રીતે ચલાવવું). Project દરમિયાન તમે આમાંથી ઘણાં documents બનાવ્યા છે; હવે તેમને એક coherent technical set તરીકે સમજો.
At a glance
| Document | What it captures |
|---|---|
| Problem statement અને requirements | કઈ problem solve થાય છે અને systemએ શું કરવું જોઈએ (functional અને non-functional) |
| Design diagrams (UML, ER) | Systemની structure: UML class/use-case/sequence, ER database, architecture અને DFD |
| Testing documentation | Test plans, test cases અને test results/reports, એટલે system works તેનો evidence |
| Deployment documentation | System deploy, install અને run કેવી રીતે કરવું, સાથે user docs |
Theory
Requirements, design, testing અને deployment
Problem statement અને requirements storyની શરૂઆત કરે છે: project કઈ problem solve કરે છે અને SRSમાં systemએ exactly શું કરવું જોઈએ: functional અને non-functional requirements. આ what અને why છે.
Design diagrams how બતાવે છે. UML diagrams software structure અને behaviour model કરે છે: class diagram classes અને relationships બતાવે છે, use-case diagram users શું કરી શકે તે બતાવે છે અને sequence diagram સમય સાથે objects કેવી રીતે interact કરે છે તે બતાવે છે. ER diagram database model કરે છે. Architecture અને DFDs systemનું picture complete કરે છે.
Testing documentationમાં test plans, test cases અને result reports હોય છે. તે શું test થયું અને outcome શું આવ્યો, એટલે system works તેનો evidence આપે છે. Deployment documentation system deploy, install અને run કેવી રીતે કરવું તે સમજાવે છે, સાથે user instructions પણ આપી શકાય છે. દરેક document એક dimension cover કરે છે; સાથે મળીને આખો project describe થાય છે.
Quiz
Project system કેવી રીતે structured છે તે કયા technical documents બતાવે છે?
- Test result reports
- UML design diagrams (class, use-case, sequence), ER diagrams, architecture અને DFDs
- માત્ર deployment guide
- માત્ર problem statement
Show the answer
UML design diagrams (class, use-case, sequence), ER diagrams, architecture અને DFDs
UML diagrams, ER diagrams, architecture diagrams અને DFDs system કેવી રીતે STRUCTURED છે તે બતાવે છે. Test result reports system WORK કરે છે તેનો evidence આપે છે, structure નહીં. Deployment guide system deploy અને run કેવી રીતે કરવું તે કહે છે. Problem statement WHAT problem solve થાય છે અને WHY તે મહત્વપૂર્ણ છે તે કહે છે, system કેવી રીતે build થયું તે નહીં. યાદ રાખો: requirements = what/why, design = how structured, testing = works evidence, deployment = how to run.
Think first
એક મોટા descriptionને બદલે અલગ documents શા માટે?
Requirements, design, testing અને deploymentને એક જ લાંબા documentમાં કેમ ન લખવું? પછી tap.
Show the answer
કારણ કે દરેક documentનો DIFFERENT PURPOSE અને AUDIENCE હોય છે. Separate documentsથી દરેક topic focused, findable અને maintainable રહે છે; એક giant description confusing અને hard to navigate બને છે.
Client, tester અથવા evaluatorને systemએ WHAT કરવું જોઈએ તે ચેક કરવું હોય તો SRS/requirements જોઈએ. Developerને structure સમજવી હોય તો UML અને ER design diagrams જોઈએ. System works તે verify કરવા testing plans, cases અને results જોઈએ. Install અથવા run કરનારને deployment documentation જોઈએ. દરેક readerનો question અલગ છે અને dedicated document તેને relevant answer ઝડપથી શોધવા દે છે.
Separation maintenanceમાં પણ મદદ કરે છે. Design change થાય તો design document update કરો; tests change થાય તો testing docs update કરો. Unrelated content disturb થતું નથી. Single mega-documentમાં concerns mix થાય છે, information શોધવી મુશ્કેલ બને છે અને એક ભાગ update કરતાં બીજું tangle થઈ શકે છે.
આ software engineeringના separation-of-concerns principle જેવું છે: અલગ concernsને અલગ રાખો, જેથી દરેક clear અને manageable રહે. Reportના sections પણ આ documents સાથે map થાય છે, તેથી અલગ documents તૈયાર કરવાથી report લખવું સરળ બને છે. Focused documents bureaucracy નથી; તે clarity અને maintainabilityની રીત છે.
Summary
Key takeaways
- Project technical documentsના setથી describe થાય છે અને દરેક project storyનો અલગ ભાગ capture કરે છે.
- Problem statement અને requirements/SRS શું problem solve થાય છે અને systemએ શું કરવું જોઈએ તે બતાવે છે.
- UML class, use-case અને sequence diagrams, ER diagrams, architecture તથા DFDs systemની structure બતાવે છે.
- Testing documentationમાં test plans, test cases અને result reports હોય છે અને system works તેનો evidence આપે છે.
- Deployment documentation system deploy, install અને run કેવી રીતે કરવું તે સમજાવે છે, સાથે user instructions પણ હોઈ શકે છે.
- Separate focused documents અલગ purposes અને audiences માટે clear, findable અને maintainable રહે છે.
- Memory hook: requirements = what/why, UML/ER design = how structured, testing = that it works, deployment = how to run.