Errori & orrori della programmazione

1. Errori & orrori della programmazione …. come evitarli Ferruccio Militello 20 dicembre 2013

2. Argomenti dell’incontro • Chi sono e cosa faccio • Regole della «buona informatica» • Un esempio pratico di un «disastro»

3. Ferruccio Militello Amministratore Unico di IT4PMI Consulente di Informatica Forense per la G.d.F.

4. La progettazione di un sistema informatico

5. Requisiti funzionali • Requisiti prestazionali • Requisiti di sicurezza • Sviluppo di un modello • Realizzazione del prodotto • Test singolo • Test integrato • Collaudo • Diffusione • Addestramento

6. I requisiti • I requisiti devono innanzitutto essere acquisiti • Le fonti possono essere molto diversificate tra loro: • Dagli utenti con: • interviste • documentazione apposita • Dalla documentazione esistente: • normative (leggi, regolamenti di settore) • regolamenti interni, procedure aziendali • realizzazioni preesistenti • Dalla modulistica • La raccolta dei requisiti è un’attività difficile e non standardizzabile; in genere procede di pari passo con la fase di analisi (la prima analisi stimola nuove domande, ecc.)

7. Interazione con gli utenti È un’attività da considerare con molta attenzione, in quanto: • utenti diversi possono fornire informazioni diverse • utenti a livello più alto hanno spesso una visione più ampia ma meno dettagliata In generale, risulta utile: • effettuare spesso verifiche di comprensione e coerenza • verificare anche per mezzo di esempi (generali e relativi a casi limite) • richiedere definizioni e classificazioni • far evidenziare gli aspetti essenziali rispetto a quelli marginali

8. Suddivisione logica • I dati • Informazioni codificate e strutturate • Memorizzazione permanente e/o temporanea • Le funzioni da svolgere • elaborazioni • interrogazioni • acquisizioni • stampe • trasferimenti (estrazioni, pubblicazioni) • Risorse tecnologiche • sistema di elaborazione (hardware) • di memorizzazione • di trasmissione (infrastruttura di rete lan, wan, internet) • di ingresso / uscita

9. Progettazione • Scelta della soluzione • Client – server • Applicazione web • Scelta della base dati • MS SQL Server • Oracle • MySQL • Altri db relazionali • Scelta del linguaggio di programmazione • C# • VisualBasic • Html + scripting (vbscript o javascript) • Altri linguaggi

10. Documentazione del codice Oltre a tutta la documentazione a corredo di tutte le fasi alte del ciclo di vista del software, è fondamentale anche la documentazione interna del codice. Una corretta e completa documentazione del software facilita e supporta molte fasi del ciclo di vita: • Testing • Integrazione • Manutenzione • Reverse Engineering e Reengineering L’utilizzo di standard di documentazione noti presenta diversi vantaggi: • Semplicità di scrittura della documentazione; • Possibilità di valutare e verificare velocemente la completezza della documentazione; • Possibilità di generare automaticamente manuali utente e diagrammi statici di dettaglio.

11. Documentazione del codice E’ importante prestare attenzione alla qualità della documentazione del codice. La documentazione interna al codice dovrebbe essere: • Coerente; • Consistente • Non devono esserci ambiguità o contraddizioni; • Conforme ad uno standard; • Tracciabile • Deve essere possibile poter collegare, nella maniera più rapida possibile, i concetti presenti nel codice con la loro documentazione e con i concetti ad esso associati.

12. Namingguidelines PerNamingGuidelines si intende un insieme di regole da seguire nella scelta dei nomi di variabile. Si definiscono Pascal Cased i nomi che hanno le iniziali maiuscole (es. RegisterClientScriptCallBack). SonoCamel Cased i nomi che hanno l’iniziale della prima parola minuscola e le iniziali delle rimanenti parole maiuscole (es. httpContext).

13. Il Processo di produzione del sw Rigorosità e formalità Separazione dei problemi Modularità Astrazione Previsione dei cambiamenti Generalità Incrementalità

14. Perché realizzare un modello Un modello permette l’esistenza di un processo pianificato e lo sviluppo NON avviene in maniera spontaneistica (caotica?), e cio` implica: • · controllo dei tempi • · controllo dei costi • · qualità dei prodotti Qualunque "industria" ha un modello per la produzione dei beni. Il modello consente: • · di pianificare le attività e le risorse necessarie • · di prevedere e controllare i costi del processo e la qualità dei prodotti L’ingegneria del software definisce metodi e procedure per lo sviluppo del software, utili ad ottenere sistemi di grandi dimensioni, di alta qualità, a basso costo, ed in breve tempo. Per conseguire tali obiettivi occorre puntare sulla qualità del processo di sviluppo del software il software come altre industrie manifatturiere.

15. L’interfaccia utente • Maschere ben formattate, chiare • Tasti funzione o menù sempre con le stesse funzioni (ricerca, cancellazione, aggiornamento) • Non deve fare scrolling (se possibile) • Piccolo help contestuale

16. Test e collaudo • Il collaudo consiste nell'eseguire un programma al fine di scoprire un errore • Rivela la presenza di errori, NON la loro assenza • Un caso di prova è valido se ha un'alta probabilità di scoprire un errore ancora ignoto • Un test (collaudo) è riuscito se ha scoperto un errore prima ignoto (non il contrario!) • Requisiti non funzionali non possono essere verificati, solo validati • Il test dei programmi deve essere usato assieme alla verifica statica

17. Test e collaudo • Prevedere l’imprevedibile • Fatelo provare a qualcuno senza dargli indicazioni • Tu lo useresti questo programma ?

18. FIPonline

19. La login al sistema • La regola prevede almeno un carattere maiuscolo e un numero • Quando fai login il controllo non c’è puoi scrivere la password tutta minuscola o tutta maiuscola che viene accettata lo stesso!

20. La designazione di una gara l'esempio è costruito tutto sulla gara 1183, serie D di oggi, 25/10/2013. Anche gara 6011 c/f del 26/10/2013 1) Designazione originale comprendeva BARONE, che poi ha rifiutato (questo è quanto appare ancora oggi su fip.it, la sostituzione è stata effettuata una settimana fa) 2) Schermata di FoL, che correttamente riporta il sostituto SORDI e la sua accettazione della gara 3) Estrazione report "gare designata": estratte le gare del 25/10/2013, vengono tutte visualizzate come in programma il 24/10/2013, compresa la 1183 4) Estrazione "arbitri disponibili" della lista regionale (associata quindi anche alla serie D) in data 25/10/2013: SORDI, designato per la 1183, viene proposto come disponibile. (vedi schermate allegato «1»)

21. Invio di una email From: presidente.va@lombardia.fip.itTo: 025666@spes.fip.itCc: presidente.va@lombardia.fip.itDate: Fri, 18 Oct 2013 18:57:38 +0200Subject: CU Ufficiale N. 127 del 18/10/2013 : Comitato Regionale CP VARESEIn allegato si trasmette quanto in oggetto.Distinti saluti. Qui il problema è che CP sta per Comitato Provinciale ma prima c’è scritto Comitato Regionale e la regione è ovviamente Lombardia

22. Il Comunicato Ufficiale delle gare La formattazione dei report di stampa, soprattutto quelli a larga diffusione (non solo ad uso interno) devono essere particolarmente curati anche nella veste grafica e non contenere errori nei dati (stampa del valore «null», gare non ordinate in ordine crescente di numero) (vedi schermate allegato «2»)

23. La classifica

24. Riepilogo Definizioni di Murpy sull’informatica Hardware: le parti di un computer che puoi prendere a calci.  Software: le parti di un computer che non funzionano. Hard Disk: la parte di un computer che si scassa nel peggior momento possibile.  Periferiche: le parti che sono incompatibili con il tuo computer.  Stampante: la parte del computer che si blocca quando non la stai guardando.  Cavo: la parte del computer che è troppo corta.  Backup: un'operazione che non viene mai eseguita in tempo.  Restore: una procedura che funziona perfettamente finché non ne hai bisogno. Memoria: la parte di un computer che è insufficiente  ErrorMessage: una richiesta di approvare la cancellazione dei tuoi stessi dati.  File: la parte di un computer che non si trova.  Processore: la parte di un computer che è obsoleta.  Manuale: la parte del tuo computer che non si capisce..

25. Riepilogo LEGGI (DI MURPHY) PER I PROGRAMMATORI 1. Qualsiasi programma, quando funziona, e' obsoleto. 2. Qualsiasi programma nuovo costa di più e ci mette di più 3. Se un programma e' utile, dovra' essere cambiato.  4. Se un programma e' inutile, dovra' essere documentato. 5. Ogni programma si espandera' fino ad occupare tutta la memoria disponibile.  6. Il valore di un programma e' proporzionale all'ingombro del suo output.  7. La complessita' di un programma si arresta solo dopo aver oltrepassato le capacita' del programmatore.

26. Domande?