Rispondere alla domanda del testo senza inventarsi una domanda diversa.
Inventarsi una domanda diversa è un fenomeno che accade molto più spesso di quanto ci si possa immaginare (vedi ad esempio i commenti numero 4, 14, 23 e 25 in questo post).Se viene chiesto di fornire una certa informazione allora deve essere fornita esattamente quella informazione. Non fornire l'informazione richiesta significa non avere svolto l'esercizio. Non perché io sia pignolo: perché questo è un requisito basilare di ogni professione. Se chiedo ad un imbianchino di pitturarmi una camera di verde allora lui deve pitturarmi una camera di verde. Punto. Che prospettive di lavoro può avere un imbianchino che pittura la cucina invece della camera? O che pittura la camera di bianco?
Fornire informazioni che sono diverse da quelle richieste, inoltre, rende manifesto che uno non è neanche in grado di comprendere il testo di un esercizio ed attenersi ai requisiti. Una impostazione mentale di questo genere è radicalmente in contrasto con la natura dell'ingegneria. Se viene chiesto di fare un ponte allora si deve fare un ponte. Non si deve fare un frigorifero perché si ha voglia di fare un frigorifero, perché siamo più bravi a fare i frigoriferi, perché i frigoriferi sono interessanti, perché se dimostro di sapere fare un frigorifero allora è ovvio che saprò fare anche un ponte, perché basta che produca qualcosa che più o meno ha a che fare con i frigoriferi (caso frequentissimo). Come si deve valutare un elaborato di un aspirante ingegnere che non è neanche in grado di attenersi ai requisiti ma produce ciò che vuole lui?
Talvolta gli studenti si inventano una domanda diversa consapevolmente ("quello che mi è stato chiesto non lo so, però ho studiato"). L’approccio di scegliere da solo l’argomento di cui parlare, svicolando abilmente la domanda, può essere utilissimo in altri contesti (ad esempio in politica) ma è completamente negativo nell’ingegneria per gli stessi motivi sopra discussi.
Leggere correttamente il testo di un esame è fondamentale anche per i motivi descritti in questo post.
Mai descrivere traffico o tabelle in forma narrativa / discorsiva
Quando viene chiesto di descrivere una qualche forma di traffico (applicativo, pacchetti o frame), è pressoché impossibile che uno svolgimento completamente “narrativo/discorsivo” riesca a convincere il lettore che chi scrive ha veramente capito.Una risposta deve essere esaustiva e non ambigua, mentre in ogni svolgimento narrativo rimangono sempre punti non descritti e ambigui. Questo post mostra due esempi dettagliati (i commenti 13 e 19 di questo post sono altri esempi).
Esercizi in cui viene chiesto di descrivere del traffico devono essere svolti descrivendo una sequenza di elementi (messaggio, pacchetto o frame) in cui ogni elemento è descritto in modo schematico con un livello di dettaglio “adeguato”.
Per ogni elemento, deve anche essere descritto in modo esauriente e non ambiguo chi trasmette e chi riceve.
Quanto scritto per il traffico si applica in modo analogo per informazioni quali tabelle, regole di configurazione, regole di firewall e così via. In ogni caso si deve fornire un insieme di elementi facendo mente locale sul tipo di ogni elemento (coppia range-azione per una tabella di routing, quadrupla indirizzi IP/port number per una regola di firewall, nome-insiemeURL-protocollo-ACL per un realm di protezione, nome-tipo-valore per un RR e così via). Poi si deve fornire, per ogni elemento, tutte le informazioni corrispondenti al suo tipo.
