અસ્પષ્ટ ગુણવત્તા હેતુને અવલોકન કરી શકાય તેવા પ્રતિસાદ અને માપન નિયમવાળા સંજોગમાં ફેરવો. “પોર્ટલ ઝડપી હોવું જોઈએ” ડિઝાઇન પસંદ કરવા કે રિલીઝ જરૂરિયાત પૂરી કરે છે તે નક્કી કરવા પૂરતું નથી.
પ્રેરકનો સ્રોત, પ્રેરક, અસરગ્રસ્ત સિસ્ટમ, કાર્યકારી પરિસ્થિતિઓ, અપેક્ષિત પ્રતિસાદ અને તેનું માપ ઓળખો. આ ભાગો ધારણાઓ સ્પષ્ટ કરે છે જેથી જુદી ટીમો સમાન દાવો ચકાસી શકે.
ઉદાહરણના રિટર્ન પોર્ટલ માટે તેના વ્યવસાયિક માલિક સાથે આ સંજોગ પર સંમત થાઓ:
આ આંકડા ઉદાહરણના લક્ષ્યો છે, ઉદ્યોગના ડિફોલ્ટ નથી. નિષ્ફળતાઓ અલગ દર્શાવો જેથી ઝડપી અસ્વીકાર વિલંબનું પરિણામ સારું ન દેખાડે. પ્રાપ્તિની પુષ્ટિ અને ગોદામમાં કામ પૂર્ણ થવું અલગ છે; તેના માટે અલગ વ્યવસાયિક સમય માપદંડ જોઈએ.
ડિઝાઇન વિનંતી કાયમી સ્વીકારી ગોદામનું કામ અસિંક્રોનસ કરી શકે. વાસ્તવિક નેટવર્ક પરિસ્થિતિઓ સહિત એ જ માર્ગ તપાસો. અનુપલબ્ધ નિર્ભરતા અને પુનઃપ્રાપ્તિ માટે અલગ સંજોગો લખો; સ્વસ્થ સિસ્ટમનો લોડ ટેસ્ટ બેમાંથી કંઈ સાબિત કરતો નથી.
સરેરાશ વિલંબ ધીમો અનુભવ પામતા વપરાશકર્તાઓને છુપાવે છે. અસ્પષ્ટ ડેટાસેટ પરિણામ ફરી મેળવવાનું મુશ્કેલ બનાવે છે. “હંમેશાં ઉપલબ્ધ” નિષ્ફળતાની સીમા કે માપનની અવધિ આપતું નથી. મજબૂત જવાબ શું, ક્યાંથી, કઈ પરિસ્થિતિમાં માપાય છે અને લક્ષ્ય પૂરતું છે તે કોણ સ્વીકારે છે તે જણાવે છે.
વિગતવાર જવાબો સાથે IT ઇન્ટરવ્યૂ પ્રશ્નોની લાઇબ્રેરી — જુનિયરથી સિનિયર સુધી.
દાન કરો