ERRORI & ORRORI DELLA PROGRAMMAZIONE

Ferruccio Militello20 dicembre 2013

…. COME EVITARLI

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 InformaticaForense 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 codiceOltre 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 codiceE’ 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 guidelinesPer 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 problemiModularitàAstrazionePrevisione dei cambiamentiGeneralitàIncrementalità

Perché realizzare un modelloUn 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 garal'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: 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 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..

RiepilogoLEGGI (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?