ComputerScience&Co

Androidiani

noreply@blogger.com (Daniele Santamaria) — Mon, 09 Apr 2012 09:55:00 +0000

Vinci un HTC Evo 3D con Androidiani.com

http://www.androidiani.com/il-meglio-della-settimana-android/vinci-un-htc-evo-3d-con-androidiani-com-94230#more-94230

Esempi di Programmazione in NVIDIA CUDA

noreply@blogger.com (Daniele Santamaria) — Fri, 28 Oct 2011 08:04:00 +0000

Esempi di programmazione in CUDA.
Download

TIM Olicard 100 su Ubuntu 10.10

noreply@blogger.com (Daniele Santamaria) — Tue, 12 Apr 2011 15:22:00 +0000

Avendo acquistato la suddetta chiavetta, posto una guida per la corretta configurazione su ubuntu. La prima cosa da NON fare, qualora disponiate di una versione a 32 bit di ubuntu è di non installare il pacchetto presente nella chiavetta. La seconda cosa da non fare è collegare la chiavetta. Prima inseriamo un paio di regole per il corretto riconoscimento del modem. Da un terminale inseriamo prima:

sudo gedit /etc/udev/rules.d/10-OLIdatacarddisk.rules

e inseriamo nel file il seguente contenuto.

KERNEL=="sr[0-9]",SYSFS{idVendor}=="0b3c",SYSFS{idProduct}=="c700",SYMLINK="GKxdatacarddisk",RUN+="/usr/bin/eject -s %k"

Questo permetterà di disattivare l'unita cd associata alla chiavetta (quella contenente i driver di installazione). Alla inoltre vengono associati altri dispositivi: ttyUSB0, ttyUSB1,ttyUSB2,ttyUSB3,ttyUSB4. Quello che interessa a noi è il primo, ttyUSB0. Tuttavia è possibile, specialmente se disponete di un pc con più di un core, che ttyUSB0 non venga registrato come modem, registrando al suo posto una tra ttyUSB2 e ttyUSB3. In questo caso da terminale digitiamo:

sudo gedit /etc/udev/rules.d/11-OLIdatacardmodules.rules

e inseriamo nel file il seguente contenuto:

KERNEL=="ttyUSB[23]",ACTION=="add",SYSFS{idVendor}=="0b3c",SYSFS{idProduct}=="c000",RUN+="/bin/sleep 2"

Se disponiamo di un pc multicore. In ogni caso dobbiamo sempre inserire la seguente riga nello stesso file:

SYSFS{idVendor}=="0b3c",SYSFS{idProduct}=="c000",RUN+="/sbin/modprobe usbserial vendor=0x0b3c product=0xc000"

Che ci permetterà di riconoscere il modem. A questo punto riavviamo e, a sistema completamente carico, inseriamo la chiavetta. Da Network Manager configuriamo una nuova connessione a banda larga mobile (il nostro dispositivo sarà indicato come "0b3c DataCard Device". A questo punto potremmo usare la nuova connessione per collegarci a internet. Se per caso non dovesse connettersi ( verrà mostrato il messaggio "si è ora disconnessi dalla rete") apriamo un terminale e digitiamo:

sudo gedit /var/log/messages

Diamo un'occhiata al log file e assicuriamoci che siano presenti delle voci simili alle seguenti:

usb 2-1.1: generic converter now attached to ttyUSB0
usbserial_generic 2-1.1:1.1: generic converter detected
usb 2-1.1: generic converter now attached to ttyUSB1
usbserial_generic 2-1.1:1.2: generic converter detected
usb 2-1.1: generic converter now attached to ttyUSB2
usbserial_generic 2-1.1:1.3: generic converter detected
usb 2-1.1: generic converter now attached to ttyUSB3
usbserial_generic 2-1.1:1.4: generic converter detected
usb 2-1.1: generic converter now attached to ttyUSB4
usbcore: registered new interface driver usbserial_generic
usbserial: USB Serial Driver coreswitched to 0b3c:c000 (: DataCard Device)

e le seguenti voce nel momento in cui tentiamo di connetterci:

Using interface ppp0
Connect: ppp0 <--> /dev/ttyUSB0

Se in quest'ultima riga, al posto di USB0 appare USB2 o USB3, assicuriamo che il secondo file sia stato creato nel modo corretto (controlliamo bene i doppi apici) ed eventualmente settiamo lo sleep ad un valore più alto (cambiando il 2 con 5 ad esempio).

HighLighting Syntax per Cuda su Scite

noreply@blogger.com (Daniele Santamaria) — Mon, 11 Apr 2011 13:37:00 +0000

Scaricare il file e sostituirlo a quello presente in Scite. Permette di evidenziare le keyword CUDA.

Download HSCS

Aggiornato il 11/05/2011 ore 19.13.

Il Semantic Web

noreply@blogger.com (Daniele Santamaria) — Sat, 02 Apr 2011 19:42:00 +0000

La mia tesi di laurea: " I linguaggi del semantic web e applicazione per la catalogazione di reperti archeologici"

Esempi WebProgramming

noreply@blogger.com (Daniele Santamaria) — Thu, 02 Sep 2010 16:37:00 +0000

esempi svolti di web programming (JavaScript,AJAX,PHP).

Download

N

noreply@blogger.com (Daniele Santamaria) — Sun, 29 Aug 2010 18:14:00 +0000

Namespace: lo spazio dei nomi è un contenitore logico al quale vengono assegnati degli elementi (identificatori). Un namespace è identificato da una URI. Gli elementi che appartengono al namespace hanno la seguente nomenclatura: la URI del namespace seguito da un separatore e da un nome univoco che identifica l'elemento (local name) per quel namespace . Nei linguaggi di programmazione un namespace è un contenitore logico di variabili.

Esercizi Svolti C#

noreply@blogger.com (Daniele Santamaria) — Fri, 27 Aug 2010 08:27:00 +0000

Esercizi svolti sul linguaggio C# adatto a chi è nuovo del linguaggio(o della programmazione)

Download

Introduzione a XML

noreply@blogger.com (Daniele Santamaria) — Sun, 04 Jul 2010 09:35:00 +0000

Introduzione a XML con esempi

Download

ImageSoft

noreply@blogger.com (Daniele Santamaria) — Fri, 02 Jul 2010 13:45:00 +0000

ImageSoft, un software di elaborazione di immagini digitali

Download

introduzione ad Ajax-JSON

noreply@blogger.com (Daniele Santamaria) — Fri, 25 Jun 2010 17:03:00 +0000

introduzione ad ajax e JSON con esempi

Download

Introduzione a PHP

noreply@blogger.com (Daniele Santamaria) — Fri, 25 Jun 2010 17:02:00 +0000

Introduzione a php con esempi

Download

Introduzione a Javascript

noreply@blogger.com (Daniele Santamaria) — Fri, 25 Jun 2010 17:01:00 +0000

introduzione a javascript con esempi.

Download

Esempi pratici su Java2D

noreply@blogger.com (Daniele Santamaria) — Wed, 26 May 2010 15:38:00 +0000

Raccolta di codici sorgenti che mostrano come si realizzano interfaccie grafiche ed effetti su immagini in java.

Raccolta 1

Raccolta 2 by anonimo

Ultima modifica 28/05/2009 ore 13.54

Utilizzo delle classi Java2D

noreply@blogger.com (Daniele Santamaria) — Wed, 26 May 2010 15:33:00 +0000

Codici sorgenti che mostrano come si utilizzano le classi per il disegno di interfaccie grafiche in Java.

Download

Metodi Formali nel Processo di Sviluppo del Software

noreply@blogger.com (Daniele Santamaria) — Sat, 10 Apr 2010 16:11:00 +0000

I metodi formali nel processo di sviluppo del software permettono di creare una specifica più completa, uniforme e non ambigua rispetto alle metriche usate tradizionalmente e di ridurre il numero di errori. Tale specifica, basata su cognizioni matematiche, può essere dimostrata, corretta ed eseguita ad alto livello. In questo post ci occuperemo del metodo delle Abstract State Machine per l'analisi e il design del software. Il metodo ASM, permette di seguire il processo di sviluppo dalla raccolta dei requisiti fino all'implementazione, gestendo la dimensione del software, la sua complessità ed affidabilità, permette una modellazione di alto livello accurata, al livello di astrazione attraverso una catena modelli di sistema con livelli di astrazione via via sempre più raffinati. Contrariamente ad UML permette inoltre una maggiore accuratezza. L'Abstract State Machine è un modello di computazione espresso con una notazione rigorosa dal punto di vista matematico e rivolto alla pratica grazie alla sua comprensibilità. Si individuano diverse categorie di ASM: Le Basic ASM, basate su determinismo e parallelismo, idonee per programmi flat; Le Turbo ASM, basate su composizione sequenziale e iterazione, idonee per applicazioni con chiamate ricorsive; Le Multi-Agent ASM (sincrone e asincrone) sono definite come un insieme di agenti che eseguono la loro ASM in parallelo.

Le ABS consistono in un vocabolario ∑, un insieme di stati iniziali, un insieme di regole, un simbolo di regola distinto chiamato "main rule" . Gli stati possono essere visti come delle memorie astratte; il vocabolario

∑ è una collezione finita di simboli funzionali tali che:

ogni simbolo ha una arietà, i nomi di funzione nullari vengono anche chiamati costanti.
i simboli di funzione possono esseer statici ( undef, true, false)
oppure dinamici ( monitorati, condivisi, di output ecc)

Uno stato S sul vocabolario ∑ è una coppia (D,I) dove D rappresenta il dominio e I la funzione di interpretazione dei simboli funzionali in ∑. D è anche chiamato "base set" dello stato, è possibile definire funzioni parziali, una relazione ha sempre valori true,false o undef, nelle applicazioni D viene spesso suddiviso in universi più piccoli. In uno stato i simboli di funzione e gli argomenti delle funzioni sono le locazioni di memoria mentre i valori delle funzioni sono i loro contenuti. Definiamo una "locazione" di uno stato S come una coppia costituita da un simbolo funzionale n-ario f e un insieme di n elementi (a1,...an) del dominio D. Definiamo un aggiornamento per S, una coppia (l,v) dove l è una locazione di S e v un elemento di D. Un insieme di aggiornamenti viene detto consistente se non ha aggiornamenti in collisione, ovvero se per ogni locazione l e tutti gli elementi u,w è vero che se (l,v),(l,w) appartengono all'insieme allora v=w. Se un insieme di aggiornamenti consistente U viene "sparato" in un dato stato allora il risultato è un nuovo stato. In questo nuovo stato rimane inalterato il contenuto delle locazioni non considerate, mentre per ogni (l,v) in U il contenuto della locazione l nel nuovo stato sarà v. Se un insieme di aggiornamenti U consistente viene sparato in un nuovo stato S, il nuovo stato risultante S+U viene determinato univocamente.Le regole di transizione dell'ASM definiscono la sintassi del programma; interpretando il programma nello stato corrente viene determinato un insieme di aggiornamenti che sparati sullo stato corrente realizzano il nuovo stato. Le regole di transizione sono:

skip ,regola di skip

f(s1,...sn) .= t ,regola di Update.

P par Q ,regola di Block.

if t then P else Q ,regola di Condition

let x=t in P ,regola di Let

forall x with y do P , regola di Forall

choose x with y do P ,regola di Choose

Una dichiarazione di regola per un simbolo di regola r di arietà n è una espressione r(x1,...xn)=P , dove P è una regola di transizione e x1,...xn sono le variabili libere di P. In una chiamata ad una regola r(t1,...tn) le variabili xi vengono sostituite con i parametri ti.

Le ASM non prevedono variabili globali. I parametri formali della testa sono le uniche variabili che hanno uno scope globale. Diciamo che una macchina M può fare una mossa da uno stato S ad uno stato T e scriviamo S => T se

se la main rule di M restituisce un insieme di aggiornamenti consistente U partendo dallo stato S e
T = S+U

Gli aggiornamenti in U vengono detti aggiornamenti interni ( per distinguerli dai possibili aggiornamenti di locazioni monitorate o condivise). T viene detto stato interno successivo. La computazione di una ASM comincia nello stato iniziale, non appena viene compiuta una mossa la computazione procede richiedendo solo che le mosse dell'ambiente che aggiornano le locazioni monitorate e condivise producano uno stato nuovo per la mossa successiva. Se uno stato la macchina non può produrre un insieme di aggiornamenti consistente oppure non è in grado di produrre nessun insieme di aggiornamento lo stato viene definito l'ultimo della computazione.

Il collaudo del software

noreply@blogger.com (Daniele Santamaria) — Tue, 30 Mar 2010 14:30:00 +0000

1.0 Introduzione

Prima di essere consegnato un software dovrebbe essere esente da bug. L'attività che mira a scovare i bug viene chiamata "collaudo". Il collaudo può essere condotto dagli stessi sviluppatori o da dei collaudatori esterni, dai clienti (alpha test) o dagli utenti finali (beta test). Il collaudo noto come "black box" mira a dimostrare la correttezza implementativa dei requisiti funzionali (funzioni errati o inesistenti, errori di interfaccia, errori di strutture dati o nei database esterni, errori di comportamento ecc). Solitamente, quando si parla di test sull'input si mira ad realizzare delle classi di equivalenza,ovvero dei gruppi che riunisco i possibili valori che possono essere passati, senza tentarli tutti. Il collaudo "white box" mira invece ad esaminare i cammini logici del software (ad esempio cosa succede quando tutti i cicli iterativi si chiudono ai casi limiti. Una tecnica di collaudo white box è stata proposta da Tom McCabe basata sulla costruzione di un "grafo di flusso" che rappresenti il flusso di controllo del programma. Lo scopo di questo test è far si che il programma esegua ogni istruzione,completi ogni ciclo iterativo, e valuti tutte le condizioni if/else (vedremo in dettaglio dopo). Un altra tecnica white box è la matrice di adiacenza del grafo di flusso basata sulla costruzione di una matrice rappresentante il flusso del programma i cui pesi (1,0) rappresentano la probabilità che un arco venga percorso. Ogni cella può inoltre essere interpretata come il tempo di elaborazione necessario all'attraversamento di un arco e la quantità di memoria richiesta per farlo. Altre tecniche sono mirate esclusivamente a testare i cicli iterativi (Collaudo per cicli) o i costrutti di selezione (collaudo per condizioni). Vediamo adesso alcune categorie precise di difetti:

1.Esecuzione di un calcolo nella parte errata di un costrutto di controllo: il collaudo per cicli farà eseguire zero,una o più volte un loop per individuare l'errore.

2.Loop Infinito: anche qui il collaudo per cicli può aiutare a scovare la causa di loop.

3.Precondizioni per un algoritmo: ciò che deve essere fatto prima che il controllo passi ad uno specifico algoritmo può causare problemi durante l'esecuzione dell'algoritmo stesso. Il collaudo per condizioni può fare emergere il problema.

4.Null Conditions: quando viene passato un valore null il programma si blocca o si comporta anomalmente. Anche qui risulta utile il collaudo per condizioni e dei testi specifici per scovare eventuale istruzione che assegna il valore null.

5.Off-by-one errors: Cicli eseguiti troppe volte o poche volte non producono i risultati attesi. La soluzione consiste in test mirati e collaudi per cicli.

6.Errore di precedenza degli operatori: Soluzione basata sull'ispezione del codice e sul test dei micro-moduli.

7.Algoritmi numerici: strutture dati o variabili troppo piccole per contenere i dati necessari: Soluzione basata sul testare l'input con valori grandi o grandi mole di dati.

8.Errori di parsing: passare al programma ciò che non si aspetta. Soluzione basata sul test dei micromoduli e dell'input.

9.Linguaggi orientati agli oggetti: In questo caso bisogna usare combinazioni di collaudi white box e black box, test mirati delle procedure e dei metodi, test sui micromoduli. Bisogna collaudare anche l'interazione tra le varie classi, basandosi anche sui modelli comportamentali per meglio comprendere come esse interagiscono. Solitamente si procede testando le singole classi e sistematicamente si aggregano altre classi per essere testate insieme (soluzione bottom-up) o in alternativa si testano prima insiemi di classi per poi passare al test delle singole classi (soluzione top-down). Se il software ha subito modifiche,gli stessi test condotti nella versione precedente vanno rieseguiti per assicurare la stabilità e la correttezza delle modifiche stesse. Se si ricorre a collaudatori esterni bisogna fornire una descrizione dettagliata del test da effettuare, dello stato iniziale e finale del sistema, dei risultati attesi. Inoltre il collaudatore non deve essere influenzato dalla struttura interna del software e non deve essere a conoscenza dei meccanismi interni altrimenti la sua capacità di operare potrebbe subirne influenza.

2.0 Grafi di flusso e complessità ciclomatica

Il grafo è una struttura che ben si adatta a rappresentare il flusso del software. Per stimare il numero massimo di collaudi da effettuare per testare ogni istruzione del programma (cioè eseguire almeno una volta ogni singola istruzione, il metodo non comprende test sugli input!) bisogna calcolare la complessità ciclomatica. La complessità ciclomatica è il numero di cammini linearmente indipendenti nel grafo). Esistono diversi metodi per effettuare il calcolo; sia V(G) la complessità ciclomatica, N il numero di nodi, E gli archi, P le componenti connesse. V(G) sarà allora dato da

1) V(G)=R=E-N+2 ; in questo caso V(G)=R cioè la complessità ciclomatica è uguale al numero delle regioni (cioè le zone che gli archi e i nodi formano).
2) V(G)=E-N+2P;
3)V(G)= π+1; π è il numero di predicati (cicli for-while e if-else,AND,OR ecc).

Costruito il grafo e calcolata la complessità ciclomatica è possibile costruire i casi di test che seguano i cammini linearmente indipendenti del grafo.

3.0 Collaudo d'interclasse e di integrazione

E' fondamentale testare i componenti dal punto di vista dell'interfacciamento con altre componenti. Solitamente questa categoria di test viene scritta a partire dai modelli comportamentali. Dopo aver testato i componenti singolarmente questi devono essere aggregati per ottenere il software finale, questa fase prende il nome di integrazione delle componenti. Esistono tre approcci ai test di integrazione:

Collaudo:BingBang; si costruisce tutto il software e poi si testa nella sua interezza.E' una tecnica sconsigliata il più delle volte perchè non mette in evidenza gli errori meno visibili.
Collaudo Incrementale: le componenti vengono aggregate poco per volta (solitamente due componenti per volta) e la componente risultante viene testata singolarmente, poi si procede iterativamente. Può essere Top-Down ( si parte dal modulo principale al quale vengono aggregate via via le componenti di basso livello); Bottom-Up: si parte dalle componenti di basso livello e si termina con il modulo principale.
Collaudo per Regressione: questo genere di collaudo avviene sempre dopo il collaudo di tipo 1. o 2. e mai da solo. Consiste nel ripetere test svolti durante le prime fasi del collaudo (test ai singoli componenti o test di aggregazione) per confermare che le modifiche effettuate per l'integrazione non abbiano ottenuto effetti indesiderati.

Quando un test viene documentato vanno inserite le seguente informazioni:

ID e titolo descrittivo del test; va indicata l'importanza del test, il sistema,sottosistema o modulo testato deve essere chiaramente indicato facendo riferimento anche ai documenti di specifica dei requisiti e architetturale.
Istruzioni del collaudatore: cosa e come fare, come mettere il sistema nello stato iniziale e quale input fornire.
Risultato Atteso: cosa ci si aspetta dal test, ovvero come si dovrebbe comportare il sistema se non vi fossero bug o errori.
CleanUp: come arrestare il sistema dopo il test o riportarlo allo stato precedente all'esecuzione del test.
Risultato: il risultato del test e se l'esito è negativo riportare l'errore (o il bug).

La Seconda Fase del Progetto:Modello Analitico e Progettuale.

noreply@blogger.com (Daniele Santamaria) — Mon, 29 Mar 2010 20:20:00 +0000

1.0 La modellazione Analitica

La modellazione analitica prevede la revisione di tutti i requisiti (funzionali e non), la definizione degli scenari, degli attori, la modellazione del flusso dei dati, delle classi analitiche e della loro organizzazione, la modellazione comportamentale e la revisione dei diagrammi per verificarne la correttezza e la precisione.

La modellazione basata sugli scenari permette di comprendere come l'utente interagisce con il sistema e di costruire dei modelli analitici e progettuali in base alla specifica dei requisiti. Si utilizzano due tecniche:

I casi d'uso: descrivono una specifica situazione in cui l'utente interagisce con il sistema, dal punto di vista di un attore ben definito.Un attore può essere una persona fisica o uno strumento che utilizza il sistema.
Diagramma di attività: affianca il caso d'uso fornendo una rappresentazione grafica del flusso di interazioni nella situazione specificata.
Diagramma SwimLane: rappresenta il flusso di attività di un caso d'uso permettendo di individuare l'attore o la classe analitica che ha responsabilità per l'azione descritta.

La modellazione basata su classi permette di identificare le classi analitiche, gli attributi e le operazioni che definiscono il comportamento di un oggetto. Il modello comportamentale rappresenta invece come il sistema risponderà a stimoli o eventi esterni. Viene rappresentato mediante diagrammi di stato e di sequenza.

2.0 Modellazione Progettuale

La modellazione progettuale sfrutta il modello analitico selezionando una architettura appropriata per il software, crea le classi e le componenti del progetto, traducendo ogni descrizione di una classe analitica in una classe progettuale, definendo i metodi associati a ciascuna classe i problemi di ereditarietà, progetta ogni interfaccia necessaria per i sistemi o dispositivi esterni,l'interfaccia utente, specifica la sequenza di attività in base a gli scenari utente, crea un modello comportamentale dell'interfaccia, specifica gli algoritmi a un livello di astrazione basso, le strutture dati e revisiona ciascun componente. La modellazione progettuale deve essere una conseguenza diretta del modello analitico e deve essere incentrata sull'architettura e sul design dei dati.

Design dell'interfaccia

noreply@blogger.com (Daniele Santamaria) — Mon, 29 Mar 2010 19:56:00 +0000

Una interfaccia è bene realizzata se essa risponde all'esigenze di coloro che la devono utilizzare. Solitamente essa deve essere facile da imparare,semplice da usare e da capire, deve nascondere i meccanismi interni che la alimentano e deve essere uniforme e in linea con le abitudini e le abilità dell'utente. Non Dovrebbe inoltre non fare uso intesivo della memoria principale. Per tali motivi bisogna prima individuare il tipo di utente destinatario (esperto, tecnico,impiegato ecc), capire le sue necessità e le sue abitudini,comprendere l'ambiente in cui opera e le attività di cui si devono occupare. Bisogna inoltre capire se sono in grado di accedere a funzioni avanzate, se sono abili nell'uso della tastiera, dei tasti di scelta rapida e così via. Utilizzando queste informazioni si può produrre un disegno preliminare e fornire un primo prototipo. In base ai test prodotti e alla valutazione del cliente stesso, i vari prototipi possono essere sviluppati fino al raggiungimento del prodotto finale. Gli errori in cui si incappa spesso durante la realizzazione dell'interfaccia sono i seguenti:

Tempi di risposta eccessivi.
Menù e comandi poco intuitivi.
Errori nell'esecuzione dei comandi
Scarsa accessibilità dell'applicazione.
Problemi di Internazionalizzazione.
Interfaccia poco intuitiva, a volte frustrante.

Gestione delle Configurazioni Software

noreply@blogger.com (Daniele Santamaria) — Mon, 29 Mar 2010 19:35:00 +0000

Il processo di gestione della configurazione software è un attività ausiliaria con lo scopo di riconoscere, gestire e controllare il cambiamento nel software informando gli interessati. La gestione deve godere di alcune proprietà:

Gestione delle versioni: ogni versione deve essere archiviata permettendo ai programmatori di fare il downgrade quando necessario.
Monitoraggio delle dipendenze: i cambimenti delle dipendenze devono essere archiviati.
Monitoraggio dei requisiti: i cambiamenti nei requisiti devono essere opportunamente monitorati.
Gestione della configurazione: le configurazioni rappresentano rappresentano specifici risultati del processo.
Audit Trail: bisogna tener conto di chi,quando e perchè ha portato ad un cambiamento.

Un sistema per il controllo delle versioni deve prevedere un database di progetto per catalogare tutti gli oggetti di configurazione rilevanti, deve permettere di gestire le diverse versione consentendo all'ingegnere del software di raccogliere tutti gli oggetti al fine di costruire una specifica versione del software. Anche i bug presenti nelle diversi versioni vanno monitorati. Il controllo di cambiamento prevede diverse fasi. Una volta riconosciuta l'esigenza di una modifica e approvata si assegna del personale al compito, vengono raccolte le informazioni dagli archivi, si procede alla modifica e ai testi, si registrano e si archiviano i nuovi cambiamenti. Il diagramma di flusso è il seguente:

1.Richiesta di modifica dall’utente
2.Lo sviluppatore valuta la richiesta
3.Si produce una relazione
4.L’autorità di controllo delle modifiche decide
5.a.La richiesta è posta in coda oppure
5.b.Richiesta respinta e l’utente viene informato.
6.Si riconosce l’esigenza di una modifica
7.Assegnazione del personale agli SCI
8.Estrazione degli SCI dall’archivio
9.Modifica
10.Revisione del cambiamento
11.Documento acquisito per il collaudo
12.Esecuzione SQA e collaudo
13.Ratifica delle modifiche da iincludere nella nuova versione
14.Costruzione della nuova versione del software
15.Revisione per tutti gli elementi della configurazione
16.Inserimento delle modifiche nella nuova versione

Piano di Gestione della Qualità

noreply@blogger.com (Daniele Santamaria) — Sat, 27 Mar 2010 16:08:00 +0000

1.0 Introduzione

Il piano di gestione della qualità ha lo scopo di pianificare,controllare e migliorare la qualità del prodotto. Per qualità generalmente si indica la conformità del prodotto ai requisiti, alle pratiche e alle politiche stabilite e alle proprietà che i consumatori percepiscono essere di alta qualità. La fase di pianificazione prevede di stabilire le intenzione e l'atteggiamento del team riguardo la qualità del prodotto. I fattori di qualità, individuati da McCall sono:

Correttezza: grado di aderenza del software alle specifiche
Efficienza: quantità di risorse e di codice necessarie perché il programma adempia alla propria funzione
Affidabilità: grado con cui un programma svolge la propria funzione con la precisione richiesta. (tolleranza all’errore, accuratezza, semplicità)
Integrità: grado con cui è possibile controllare l’accesso al software o ai dati da parte di persone non autorizzate. (controllo e valutazione degli accessi)
Facilità d’uso: indical’impegno necessario per imparare a usare il software, a prepararne i dati d’ingresso e a interpretarne i dati d’uscita.
Facilità di manutenzione: misura l’impegno necessario per localizzare e correggere un errore nel programma
Flessibilità: misura l’impegno necessario per modificare il programma
Collaudabilità: misura l’impegno necessario per stabilire, tramite collaudo, se un programma svolge la funzione prevista
Portabilità: misura l’impegno richiesto per trasportare un programma da un ambiente hardware o software, a un altro.
Riutilizzo: misura il grado con cui un programma (o alcune sue parti) può essere utilizzato di nuovo in altre applicazioni.
Interoperabilità: misura l’impegno richiesto a far interagire il programma con altri programmi

Un buon piano di qualità inoltre deve includere anche le seguenti attività:

Selezione delle pratiche per la garanzia di qualità: identificazione di tool specifici e tecniche per il monitoraggio della qualità dello sviluppo del software.
Valutazione del piano di progetto software: è una delle revisioni più importanti e difficili da condurre
Accettazione della valutazione dei requisiti: definisce le caratteristiche di un prodotto accettabile.4.
Valutazione della specifica: valuta se le specifiche sono conformi alle attese.
Valutazione del processo di design: valuta se il processo di design è conforme alle attese6.
Valutazione delle pratiche di codifica: come sopra per la codifica.
Valutazione del processo di test ed integrazione: come sopra per test ed integrazione.

Lo scopo delle revisione è individuare gli errore nel processo di sviluppo del software e bloccarne la propagazione. Solitamente il team si riunisce in piccoli gruppi per analizzare parti specifiche e relativamente piccole del software al fine di effettuarne una valutazione. Tutte le revisioni verranno registrate e documentate. Disponendo di una descrizione rigorosa dei requisiti è possibili ricorrere a dimostrazioni formali per verificarne la correttezza. Le revisioni formali sono note con il nome di Quality Gate.

2.0 Quality Gate

Il processo di verifica è basato su checklist (risposte vero o falso su domande standard). Per il processo di sviluppo la checklist è:

La portata del software è definita in maniera chiara?
La terminologia è ben definita?
Le risorse sono ragionevoli? Sono disponibili?
L’analisi dei rischi è stata fatta? E il piano contenimento e/o prevenzione?
I compiti sono stati definiti, programmati e allocati?
Le stime di costo e programmazione sono ragionevoli?
E’ stato applicato uno standard nella stesura della documentazione?
Come sarà controllato il piano del progetto?
E’ necessario un ambiente per lo sviluppo del software?
Come è stata condotta la revisione?

Per i requisiti software invece:

Tutte le funzioni sono state definite, descritte, vincolate in maniera non ambigua?
Per ogni requisito funzionale è stato introdotto anche un requisito di performance, e il requisito funzionale è testabile?
Gli input e gli output sono stati tutti definiti in termini di range, protocolli,.. in modo che il designer del software possa essere soddisfatto?
E’ stato fatto un piano di test e di integrazione? I criteri di accettazione dei test sono stati già negoziati con il cliente?
Lo studio di fattibilità è completo?
L’analisi dei rischi è stata iniziata/completata?
Sono stati applicati degli standard alla documentazione?

Per la specifica architetturale:

Ci sono ancora dei requisiti aperti? Se sì, si progetta di chiuderli?
Il partizionamento è completo e documentato?
Tutte le interfacce hardware e software interne ed esterne sono state definite adeguatamente in termini di protocolli, range ecc..?
Il modello dei dati è stato completamente e accuratamente definito?
I requisiti software di basso livello sono tracciati nei requisiti software di alto livello in maniera completa ed accurata?
Possono essere soddisfatti i requisiti non funzionali?
Il partizionamento soddisfa i criteri di modularità?
Sono state definite le interfacce fra i moduli?
Il design della struttura dati è consistente con i requisiti dei dati?
Manutenibilità e flessibilità sono attributi di qualità considerati nel design?
Quali attributi di qualità sono applicati?
Gli standard di documentazione sono stati raggiunti?
Sono stati applicati degli standard nella pseudocodifica? Se sì, come sono stati applicati?

Per la specifica di dettaglio:

Sono stati tenuti in considerazione tutti i requisiti?
La specifica dettagliata è consistente con la precedente?
Lo pseudocodice o i diagrammi sono stati correttamente trasformati in codice? Hanno soddisfatto gli standard richiesti?
Sono stati soddisfatti gli standard per la documentazione?
I commenti soddisfano degli standard?
I tipi di dati e la dichiarazione dei dati è corretta?
I dati sono corretti?
Sono stati tenuti in conto gli attributi di qualità?

Per il testing

I criteri di accettazione dei test sono stati definiti, negoziati ed accettati? Le revisioni sono state fatte come richiesto?
I piani di test sono stati preparati e revisionati?
L’attività di testing è stata presa in considerazione in altre fasi di sviluppo?
Gli ambienti di test (strumenti e risorse) sono definiti in maniera adeguata e disponibili quando necessario?
La tracciabilità fra requisiti e test di conferma è stata completata e corretta?
Le funzioni principali sono confermate presto nella fase di testing?
Sono stati definiti degli standard per condurre i test? I tester sono stati sottoposti a training?
Sono stati definiti test limite e test di stress?
Il testing è fatto in maniera completa?
La gestione degli errori e delle eccezioni è stata testata?

Per la valutazione della revisione:

Il materiale è completo?
Il materiale è stato distribuito in tempo?
Gli standard applicabili sono disponibili?
I partecipanti erano preparati a contribuire?
La valutazione è iniziata in tempo?
La revisione è stata condotta attraverso protocolli standard?
E’ stato identificato un certo numero di difetti?
Sono stati riportati gli attributi di qualità?
Si e’ cominciato a tracciare i difetti?

3.0 Capability Maturity Model

Il Capability Maturity Model è il più famoso modello di valutazione e miglioramento.Ogni processo è caratterizzato da tre proprietà: La capability, l'insieme dei risultati che un processo consente di conseguire; performance, la misura dei risultati effettivi ottenuti nell'applicazione del processo; maturity,l’efficacia del processo e della estensione e precisione con cui le fasi e le attività dello stesso sono esplicitamente definite, gestite, misurate e controllate. Sono individuati 5 livelli di maturità: iniziale,ripetibile,definito,controllato e ottimizzato. Ad ogni livello è associata una previsione di performance. Quando il livello è iniziale, il processo di produzione è instabile e disorganizzato per cui nulla è prevedibile.Al livello ripetibile, esiste già una struttura in grado di gestire costi,scheduling delle attività ed i cambimenti che vengono apportati. Al livello definito, il processo è ben fondato su metodologie e tecniche di ingegneria del software sia per quanto riguarda gli aspetti operativi che quelli manageriali. Al livello gestito, il processo produttivo un dettagliato piano di misura per il controllo della qualità del processo e del prodotto. Al livello ottimizzato,è stata istituzionalizzata una politica di gestione della qualità. Il CMM prevede inoltre per l'accertamento una checklist da tarare ed adottare in base alle realtà aziendali.

Il Piano di Progetto

noreply@blogger.com (Daniele Santamaria) — Wed, 24 Mar 2010 10:20:00 +0000

1.0 Generalità

Il piano di progetto è un documento versionato redatto dal project manager allo scopo di stimare i tempi. i costi e le risorse necessari alla realizzazione del progetto. Si divide in due parti, La Pianificazione, per pianificare le attività future, e La Consuntivazione,per avere un riscontro tra le attività pianificate e quelle effettuate. Il piano di progetto comprende:

Definizione degli Obbiettivi.
Analisi dei Rischi
Descrizione del modello di processo di sviluppo.
Suddivisioni in milestone.
Attività di progetto.
Stima dei costi.
Consunto di attività.

Chiameremo Attività un lavoro svolto nel progetto, con una durata e un costo ben preciso. Chiameremo invece Deliverable un risultato che deve essere prodotto per completare un progetto o una sua parte.

2.0 Work BreakDown Strucutre (WBS)

Il WBS è un di elementi del progetto che definisce i limiti complessivi del progetto, ovvero tutto ciò che è dentro i limiti del progetto. E' rappresentato da una struttura gerarchica in cui ogni livello discendente rappresenta una descrizione più dettagliata dell'elemento del progetto. Per costruire un WBS si parte dai deliverable principali, che nello schema rappresentano la radice. Se per il deliverable non siamo in grado di stimare costo e durata, si passa a un successivo livello di dettaglio, rappresentato da un discendente. Ad ogni elemento viene associato un identificatore univoco, gli elementi più in basso nella gerarchia sono chiamati work packages. Le attività che devono essere eseguite per produrre i deliverable vanno identificate e documentate. Ogni attività è descritta da risorse utilizzate e relativi documenti in input, durata (in giorni), costi e realtivi documenti in output, legami di precedenza con altre attività e figura responsabile. Per ogni attività va individuata la dipendenza con altre attività. Si indiviudano tre tipi di dipendenze. Le dipendenze obbligatorie, inerenti alla natura del lavoro che deve essere fatto; le dipendenze discrezionali, definite ed imposte dal team. Questo tipo di dipendenze va documento con attenzione in un documento chiamato Best Practices;le dipendeze esterne, che coinvolgono attività di progetto e non. Le dipendenze vengono rappresentate con un diagramama di precedenza, composto da noti collegati da frecce, in cui i nodi collegati sono le attività legate da dipendenza e la freccia rappresenta il verso della dipendenza (chi dipende da chi). Calcolare il tempo previsto per il completamento del progetto è una operazione affidata a membri con alta esperienza. Solitamente si analizza il percorso critico del progetto (l'attività con minore flessibità di stima) e si sommano i tempi di tutte le attività. Le attività e i relativi tempi sono illustrati graficamente in uno schema chiamato Slack Time. Le attività possono sollevare conflitti nei casi in cui i loro slack time stessi sono in conflitto. Solitamente si tenta di realizzare le attività con slack maggiore, si ridistribuiscono le risorse o si frammentano le attività.

3.0 Modello COCOMO

Il modello COCOMO (Constructive Cost Model) è un metodo di stima dei costi di sviluppo di un software. Esso prevede che il processo di sviluppo del software sia basato sul modello a cascata. Esso comprende tre diversi livelli di stima. Stima di base, approssimata,veloce,scarna di dettagli limitata dalla mancanza di informazioni più precise circa il progetto; Stima intermedia maggiormente accurate e dettagliate, usufruisce di informazioni quali ambiente di sviluppo e altri parametri;Stima Dettagliata, fornisce la stima migliore in quanto usufruisce di tutte le informazioni sul progetto e sulle sue fasi.

Il modello CoCoMo di base distingue tre modalità di sviluppo del software: Organic mode, il team di sviluppo consiste di un numero piccolo di sviluppatori di esperienza che hanno familiarità con l’area di applicazione e con l’ambiente di sviluppo,inoltre e dimensioni del prodotto sono piccole o medie; semidetached mode, il team di sviluppo consiste di un misto di persone con e senza esperienza, che lavorano insieme da poco,la dimensione del prodotto può essere media o grande;Embedded mode,richiede un elevata quantità di risorse,il prodotto ha requisiti stringenti riguardo ad affidabilità, performance,schedule ed interfacce,la dimensione del prodotto è media o grande e generalmente complessa. Il modello CoCoMo intermedio mantiene le stesse distinzioni del modello di base ma introduci 15 nuovi Cost Driver. Il modello dettagliato invece tiene conto dei Cost Drivers del modello precedente ma in funzione delle varie fasi di sviluppo del software. Negli anni '90 fu introdotto il modello CoCoMo II per adattarsi ai nuovi processi di sviluppo come riuso, composizione e paradigmi orientati agli oggetti.

La prima fase del progetto: L'Analisi

noreply@blogger.com (Daniele Santamaria) — Wed, 17 Mar 2010 16:23:00 +0000

1.0 L'analisi del Dominio

Studiare e comprendere bene il dominio del problema da affrontare costituisce il primo passo verso lo studio della fattibilità e della comprensione dei requisiti. Le informazioni necessarie a tale scopo posso essere acquisite in modi diversi, interviste a clienti, documentazioni presenti o di progetti passati, soluzioni già note a problemi affrontati in passato. L'analisi del dominio è un documento vitale per la stesura del documento successivo, l'analisi dei requisiti, solitamente è versionato ma può essere mantenuto in forma unica e viene diviso in aree:

Visione generale sulla società committente, breve descrizione del prodotto richiesto, ecc
Glossario (definizioni, acronimi, abbreviazioni)
Conoscenze generali sul dominio
Caratteristiche dei clienti e degli utenti
L’ambiente di utilizzo
Compiti e procedure attualmente eseguiti
Software competitori
Similarità ad altri domini

2.0 Verso i requisiti

Il passo successivo è stabilire la portata del software., ovvero il contesto in cui si inserisce il software, i dati trattati (input e output), come trasforma l'input in output (funzionalità) e con quali prestazioni. E' una fase critica in quanto può portare al fallimento del prodotto se il team non comprende realmente le esigenze del cliente, e quindi la portata del software è stata mal elaborata, le funzionalità sono state mal elaborate e vanno quindi modificate diverse volte nel corso della realizzazione del progetto. Barry Boehm chiamò W5H2 le sette domandi da porsi in fase di stesura della portata. Esse sono:

Perchè il sistema deve essere realizzato ?
Cosa deve fare ?
Quando sarà completato ?
Chi sono i responsabili ?
Come sono organizzati ?
Come sarà fatto il lavoro dal punto di vista tecnico e manageriale ?
Quante e quali risorse richiede ?

3.0 L'analisi dei Requisiti

Individuiamo due tipi di requisiti. I requisiti funzionali, che rappresentano le caratteristiche che ci si aspetta dal prodotto, senza i quali lo stesso prodotto non ha senso di esistere, ed i requisiti non funzionali, ovvero tutti i requisiti relativi a tempi di consegna (requisiti temporali), budget economico a disposizione del cliente (requisiti economici), disponibilità del servizio offerto dal prodotto, efficienza e carichi elaborativi (requisiti di servizio), responsabilità organizzativa (requisiti organizzativi), architettura, espandibilità, modularità, interoperabilità ed riusabilità ( requisiti di progettazione),caratteristiche di sicurezza (requisiti di sicurezza),specifiche tecnologiche (requisiti tecnologici), usabilità, documentazione, supporto e formazione (requisiti di utilizzo). Ogni requisito deve essere caratterizzato da:

Numero: identificatore univoco per il requisito
Tipo: categoria a cui il requisito appartiene (organizzativo,economico ecc)
Descrizione: dettagli aggiuntivi
Richiedente: chi ha espresso il requisito.
Data: data di espressione del requisito.
Importanza: quanto è importante per il richiedente (abbastanza,molto,indispensabile ecc)
Priorità: entro quanto tempo il requisito deve essere implementato
Interrelazione: con quali altri requisiti, il requisito ha relazione
Status: grado di stabilità del requisito (in progettazione,verificato,implementato,proposto)

4.0 Analisi dei Punti Funzione

L'analisi dei punti funzione è un metodo volto a suddividere un programma in moduli più piccoli al fine di poterli analizzare meglio. Sono un tipo di misura capace di misurare un'applicazione dal punto di vista dell'utente riuscendo a ricavare un indice delle dimensioni dell'applicazione a partire dalle funzionalità che deve fornire. In particolare misurano le funzionalità dell'utente il ritmo di sviluppo e di mantenimento a prescindere dalla tecnologia con cui si implementa il prodotto, consentono di convertire la dimensione, in linee di codice, dell' applicazione in qualsiasi linguaggio nella dimensione dell’applicazione equivalente scritta in un altro linguaggio, consentono di misurare la produttività di un progetto scritto usando più linguaggi di programmazione. Un software è essenzialmente un insieme definito di processi elementari che interagiscono combinandosi tra loro. In una applicazione software individuiamo dati in movimento (external input, external output, external
inquiries) e dati in riposo (internal logic file, external interface file). Il numero di punti funzione per input rappresenta la produttività software. Può essere migliorata incrementando gli output con gli stessi input, decrementando gli input con gli stessi output, decrementando gli input incrementando gli output. Il conteggio dei punti funzione avviene seguendo diverse fasi: 1) determinare il tipo di conteggio ( sviluppo, miglioramento, applicazione). 2) Determinare i confini dell'applicazione. Il confine indica il limite tra l'applicazione che viene misurate e le applicazioni esterne. 3) Identificare e valutare i tipi di funzione di transizione per determinare il loro contributo al conteggio dei punti funzione. 4)Identificare e valutare i tipi di funzione dato per determinare il loro contributo al conteggio dei punti funzione. 5)Determinare il valore del fattore di aggiustamento. 6) Effettuare i calcoli. Individuiamo alcune funzioni standard:

Data Functions: Internal logical files, dati mantenuti all'interno del confine dell'applicazione
External interface files, dati mantenuti all'esterno del confine dell'applicazione
Transactional Functions: External Inputs, processo elementare proveniente dall'esterno del confine
External Outputs, processo elementare che invia dati all'esterno
External Inquiries, processo elementare che controlla informazioni fuori dal confine

Tutte queste componenti vengono valutate in base a:

Record Element Type: sottogruppo di dati riconducibili dall'utente ad un IEF o EIF
File Type Referenced: file a cui si fa riferimento attraverso una transizione.
Data Element Type: campo unico riconoscibile dall'utente.

Il fattore di aggiustamento è basto su 14 caratteristiche generali di sistema , ogni caratteristica ha delle descrizioni associate per determinare i gradi di influenza, su scala da 0 a 5. Le caratteristiche generali di sistema (GSC) possono così essere elencate:

General System Characteristic Brief Description

• 1. Data communications How many communication facilities are there to aid in the transfer or exchange of
information?
• 2. Distributed data processing How are distributed data and processing functions handled?
• 3. Performance Did the user require response time or throughput?
• 4. Heavily used configuration How heavily used is the current hardware platform where the application will be executed?
• 5. Transaction rate How frequently are transactions executed daily,
weekly, monthly, etc.?
• 6. On-Line data entry What percentage of the information is entered On-Line?
7. End-user efficiency Was the application designed for end-user efficiency?
• 8. On-Line update How many ILF’s are updated by On-Line transaction?
• 9. Complex processing Does the application have extensive logical or mathematical processing?
• 10. Reusability Was the application developed to meet one or many user’s needs?
• 11. Installation ease How difficult is conversion and installation?
• 12. Operational ease How effective and/or automated are startup,back up, and recovery procedures?
• 13. Multiple sites Was the application specifically designed, developed, and supported to be installed
at multiple sites for multiple organizations?
• 14. Facilitate change Was the application specifically designed, developed, and supported to facilitate change?

5.0 Analisi dei Rischi

Durante lo sviluppo del software è possibile incorrere in numerose aree di rischio. Un ingegnere del software deve poter sviluppare dei metodi per individuare e gestire i rischi. Alcune aree di rischio di possono essere personale non adeguato o in numero insufficiente, budget non realistico, sviluppo di funzioni software errate, sviluppo di interfaccia utente errata, instabilità dei requisiti. Il fattore di rischio può essere modellato da due variabili: PF, probabilità di fallimento, CF, conseguenza del fallimento. Il fattore di rischio sarà allora dato da:
RF = PF + CF – PF*CF

Arrivare a un valore per ogni fattore richiede un’analisi completa del fattore e una solida base di esperienza. Di fatti l'assegnamento dei pesi è altamente soggettivo.

Macchina di Turing

noreply@blogger.com (Daniele Santamaria) — Fri, 12 Mar 2010 22:58:00 +0000

Download

Grammatiche Regolari

noreply@blogger.com (Daniele Santamaria) — Fri, 12 Mar 2010 22:57:00 +0000

Download