Theory
Softwareનું life cycle હોય છે
Software એક જ leapમાં build થતું નથી; need સમજવાથી લઈને finished system maintain કરવા સુધી તે life cycleની phasesમાંથી પસાર થાય છે. આને Software Development Life Cycle (SDLC) કહે છે. દરેક phaseમાં શું નક્કી થયું અને શું કરવામાં આવ્યું તે documentation capture કરે છે.
તમારા projectમાં તમે આ process lived કરી છે. અહીં તે explicitly સમજીએ છીએ અને એક મહત્વનો difference જોઈએ: તમે કયા development modelમાં કામ કરો છો તેના આધારે documentation કેટલી કરવી તે બદલાય છે. Traditional modelsમાં heavy up-front documentation થાય છે; Agileમાં light અને continuous documentation થાય છે.
At a glance
| Phase | Documentation produced |
|---|---|
| Requirements | SRS, એટલે systemએ શું કરવું જોઈએ |
| Design | Design documents અને diagrams: architecture, UML, ER, DFD |
| Implementation | Code, comments અને inline documentation |
| Testing | Test plans, test cases અને test reports |
| Deployment / maintenance | Deployment guides અને user documentation |
Theory
દરેક phaseમાં documentation
દરેક SDLC phase decisionsની documentation trail છોડે છે.
Requirementsમાંથી SRS બને છે, જેમાં systemએ શું કરવું જોઈએ તે લખાય છે. Designમાંથી architecture, UML, ER અને DFD જેવા design documents તથા diagrams બને છે. Implementationમાં helpful comments સાથે code બને છે. Testingમાંથી test plans, test cases અને reports બને છે, જેમાં શું test થયું અને results શું આવ્યા તે લખાય છે. Deployment અને maintenanceમાંથી deployment guides અને user documentation બને છે.
આ documentationથી બીજા લોકો અને future તમે system સમજી તથા maintain કરી શકો છો. તે project reportમાં પણ સીધું feed થાય છે. દરેક phaseની documentation એ કેમ અને કેવી રીતે decisions લેવાયા તેની memory છે.
Theory
Traditional અને Agile documentation
Documentation કેટલી કરવી તે development model પર આધારિત છે.
Traditional models, જેમ કે Waterfall, sequential છે. દરેક phase આગળની phase પહેલાં complete થાય છે અને તેમાં heavy, detailed documentation થાય છે. Requirements thoroughly document કર્યા પછી design અને પછી development થાય છે. Stable અને well-understood requirementsવાળા projects માટે આ યોગ્ય હોઈ શકે છે.
Agile iterative છે. Work short cycles અથવા sprintsમાં થાય છે, working software વારંવાર deliver થાય છે અને requirements બદલાય તો team adapt કરે છે. Documentation lighter અને just-enough હોય છે અને આખરે એકસાથે નહીં, પરંતુ continuously બને છે.
કોઈ model simply better નથી. Situation પ્રમાણે model પસંદ થાય છે. Difference સમજવાથી context પ્રમાણે documentation exhaustive અને up-front રાખવી કે lean અને continuous, તે નક્કી કરી શકો છો.
Quiz
Traditional Waterfall અને Agile modelsમાં documentation કેવી રીતે અલગ છે?
- Agileને Waterfall કરતાં ઘણી વધુ up-front documentation જોઈએ છે
- Traditional/Waterfall sequential રીતે ભારે documentation up front કરે છે, જ્યારે Agile lighter just-enough documentation continuously બનાવે છે અને change સાથે adapt કરે છે
- કોઈ model documentation વાપરતું નથી
- બંને exactly same રીતે document કરે છે
Show the answer
Traditional/Waterfall sequential રીતે ભારે documentation up front કરે છે, જ્યારે Agile lighter just-enough documentation continuously બનાવે છે અને change સાથે adapt કરે છે
Traditional/Waterfall sequential modelમાં next phase પહેલાં heavy અને detailed documentation UP FRONT થાય છે. Agile iterative છે અને LIGHTER, just-enough documentation continuously બનાવે છે; તે working software અને change adaptation પર focus કરે છે. Option A reverse છે: heavy up-front documentation Waterfallની ખાસિયત છે. Option C ખોટું છે: બંને documentation વાપરે છે; difference amount અને timingમાં છે. Option D પણ ખોટું છે: heavy-and-up-front અને lean-and-continuous approaches અલગ છે.
Think first
Agile lighter documentation કેમ પસંદ કરે છે અને શું તે સારું છે?
Documentation valuable છે, તો Agile deliberately ઓછું documentation કેમ બનાવે છે? પછી tap.
Show the answer
કારણ કે Agile RESPONDING TO CHANGE અને WORKING SOFTWARE deliver કરવાને priority આપે છે. Requirements બદલાય ત્યારે heavy up-front documentation ઝડપથી outdated થઈ શકે છે. Agile documentationને LEAN અને CONTINUOUS રાખે છે, જેથી useful coordination થાય પણ adaptation slow ન પડે.
ઘણા modern projectsમાં requirements શરૂઆતથી fully known અથવા stable નથી. Usersના feedback, market changes અને teamના learningથી requirements evolve થાય છે. Strict Waterfallની જેમ શરૂઆતમાં exhaustive documentation કરો અને પછી requirements બદલાય તો ઘણું documentation wrong અથવા outdated બની શકે છે. તેને current રાખવા effort software buildથી દૂર જઈ શકે છે.
Agile તેથી just ENOUGH documentation બનાવે છે, જે communication અને coordination માટે જરૂરી હોય, અને તેને work સાથે continuously update કરે છે. Close collaboration, conversation અને working software પણ understanding communicate કરે છે. આ approach teamને paperworkના mountain વગર fast અને flexible રાખે છે.
તે હંમેશા best છે એવું નથી. Evolving requirements અને speed જરૂરી હોય ત્યારે Agileનું lean documentation strength છે. Stable requirements, regulation, safety અથવા large teamsવાળા aerospace, medical અને enterprise projectsમાં thorough records જરૂરી હોઈ શકે છે, ત્યાં heavier documentation યોગ્ય છે.
Agile documentationના valueને reject કરતું નથી; તે context પ્રમાણે deliberate trade-off છે. Professional skill એ છે કે situation માટે યોગ્ય level of documentation પસંદ કરવું: maximum અથવા minimum નહીં, પરંતુ right amount.
Summary
Key takeaways
- SDLC phases છે: requirements, design, implementation, testing, deployment અને maintenance.
- દરેક phase documentation બનાવે છે: requirementsથી SRS, designથી diagrams, implementationથી code/comments, testingથી plans/reports અને deploymentથી user/deployment docs.
- Documentation decisions record કરે છે, system સમજવા અને maintain કરવા મદદ કરે છે અને reportમાં ઉપયોગી બને છે.
- Traditional/Waterfall sequential છે અને heavy detailed documentation up front કરે છે.
- Agile iterative sprintsમાં lighter just-enough documentation continuously બનાવે છે.
- Agile evolving requirementsમાં flexibility માટે યોગ્ય છે; stable અથવા regulated projectsમાં heavy documentation જરૂરી હોઈ શકે છે.
- Memory hook: SDLCની દરેક phase documentation છોડે છે; Waterfall heavy-and-up-front, Agile lean-and-continuous; context પ્રમાણે right amount પસંદ કરો.