La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

E RRORI & ORRORI DELLA PROGRAMMAZIONE Ferruccio Militello 20 dicembre 2013 …. COME EVITARLI.

Presentazioni simili


Presentazione sul tema: "E RRORI & ORRORI DELLA PROGRAMMAZIONE Ferruccio Militello 20 dicembre 2013 …. COME EVITARLI."— Transcript della presentazione:

1 E RRORI & ORRORI DELLA PROGRAMMAZIONE Ferruccio Militello 20 dicembre 2013 …. COME EVITARLI

2 Argomenti dellincontro 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 è unattività 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 È unattività 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 Lutilizzo 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 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 liniziale 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 lesistenza 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 Lingegneria 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 Linterfaccia 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 limprevedibile Fatelo provare a qualcuno senza dargli indicazioni Tu lo useresti questo programma ?

18 FIP ONLINE

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 ) 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 From: To: Cc: Date: Fri, 18 Oct :57: Subject: CU Ufficiale N. 127 del 18/10/2013 : Comitato Regionale CP VARESE In allegato si trasmette quanto in oggetto. Distinti 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 sullinformatica 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..

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 D OMANDE ?


Scaricare ppt "E RRORI & ORRORI DELLA PROGRAMMAZIONE Ferruccio Militello 20 dicembre 2013 …. COME EVITARLI."

Presentazioni simili


Annunci Google