ERRORI & ORRORI DELLA
PROGRAMMAZIONE
…. COME EVITARLI
Ferruccio Militello
20 dicembre 2013
Argomenti dell’incontro
• Chi sono e cosa faccio
• Regole della «buona informatica»
• Un esempio pratico di un «disastro»
Ferruccio Militello
Amministratore Unico di IT4PMI
Consulente di Informatica
Forense per la G.d.F.
La progettazione
di un sistema
informatico
• Requisiti funzionali
• Requisiti prestazionali
• Requisiti di sicurezza
• Sviluppo di un modello
• Realizzazione del prodotto
•
•
•
•
•
Test singolo
Test integrato
Collaudo
Diffusione
Addestramento
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.)
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
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
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
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.
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.
Naming guidelines
Per Naming Guidelines 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).
Sono Camel Cased i nomi che hanno l’iniziale della
prima parola minuscola e le iniziali delle rimanenti
parole maiuscole (es. httpContext).
Il Processo di produzione del sw
Rigorosità e formalità
Separazione dei problemi
Modularità
Astrazione
Previsione dei cambiamenti
Generalità
Incrementalità
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.
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
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
Test e collaudo
• Prevedere l’imprevedibile
• Fatelo provare a qualcuno senza dargli indicazioni
• Tu lo useresti questo programma ?
FIPONLINE
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!
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»)
Invio di una email
From: [email protected]
To: [email protected]
Cc: [email protected]
Date: Fri, 18 Oct 2013 18:57:38 +0200
Subject: CU Ufficiale N. 127 del 18/10/2013 : Comitato
Regionale CP VARESE
In 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
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»)
La classifica
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
Error Message: 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..
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.
DOMANDE?