To agne

Si descrivano i prodotti del processo di progettazione architetturale. Quali diverse prospettive/decisioni sull’architettura del sistema devono venir considerate in fase di progettazione?

La progettazione architetturale è un processo atto a stabilire la struttura complessiva di un sw, ciò prevede non solo la costruzione astratta dei componenti e la specificazione dei servizi che offrono ma anche le possibili comunicazioni tra di essi.

E’ uno dei primi processi di system design. Esplicitando l’architettura la comunicazione con gli stakeholder è semplificata, aiuta a capire i requisiti non funzionali e puo’ essere riusata su una gamma di sistemi.

Processo:

• strutturazione del sistema, il sistema viene decomposto in molti sottosistemi principali e definite le comunicazioni tra di essi.

Presentato con diagramma a blocchi. Modelli: deposito, sottosistemi che scambiano dati, implementato con dati comuni in DB oppure proprio DB per sottosistema. Client-Server, mostra come dati e processi sono distribuiti e modelli a macchina astratta, per modellare l’interfaccia dei sottocomponenti, sistema a livelli con servizi offeri per livello.

• modellamento del controllo, vengono definite le relazioni di controllo tra le varie parti del sistema.

Controllo centralizzato: un sottosistema ha il controllo su tutti. Call-return: modello di routine top-down, il controllo inizia dalla cime e scende, per sistemi sequenziali. Modello manager: per sistemi concorrenti, un componente controlla lo stop o l’inizio degli altri processi.

Controllo eventi: ogni sottosistema puo’ rispondere a eventi esterni, da altri sotto sistemi o dall’ambiente del sistema. Modello broadcast: un evento viene mandato a tutti i sottosistemi e chi puo’ gestirlo lo esegue. Modello guidato da interrupt: usato nei sistemi real-time dove c’è un interrupt-hadler che gestisce le interruzioni e le passa ad altri componenti per l’esecuzione.

• decomposizione modulare

i sotto-sistemi idetificati vengono decomposti in moduli. Due livelli di decomposizioni modulari:

Una OO dove il sistema è decomposto in oggetti interagenti. Struttura del sistema è un insieme di oggetti debolmente accoppiati con interfacce ben definite.

Modello data flow il sistema è decomposto in moduli funzionali che trasformano input in output.

Ci possono essere anche architetture specifiche di dominio. Due tipi fondamentali: modelli generici, sono astrazioni di sistemi reali (modello compilatore, bottom-up) e i modelli di referenza, più astratti e ideali, modelli derivanti da studio del dominio di applicazione (Top-down).

Possiamo considerare l’architettura da  diversi punti di vista, come la performance: è ovvio supporre che un maggior numero di trasferimenti daranno luogo a una diminuzione nelle prestazioni del sistema.  Altri punti di vista sono la protezione (gli aspetti più critici vengono sviluppati in livelli interni non direttamente accessibili (tipo la modalità kernel di un SO), la sicurezza (isolamento dei componenti fondamentali), la disponibilità (aggiungere ridondanza in caso di guasti) e la manutenibilità (utilizzo di componenti piccoli ed autosufficienti)

Si illustri il concetto di requisiti software (tipologie, livello di dettaglio, prospettiva,…). Quali sono le differenze tra il processo di definizione dei requisiti e quello di specificazione dei requisiti?

I requisiti per un sistema sono la descrizione dei servizi forniti sal sistema e le modalità con cui vengono prestati.

Possono essere categorizzati in base a vari aspetti. la prima distinzione è tra requisiti funzionali, ossia cosa il sw deve essere in grado di fare, e non funzionali, come ad esempio vincoli di prestazioni, caratteristiche dell’interfaccia utente, … I requisiti di dominio possono ricadere in entrambe le categorie e derivano dal dominio di applicazione.

Una seconda distinzione è quella tra requisiti dell’utente, cioè specifiche caratteristiche richieste da chi andrà ad operare con il sw, sono sia funzionali che non e descritti in modo che siano facilmente letti dagli utenti, requisiti del sistema, come ad esempio la necessità di girare su SO o piattaforme hw fissate e il comportamento del sistema, sono una versione tecnica di quelli per utenti, creati come punto di partenza per il design.

I requisiti si dividono in livelli di dettaglio potenzialmente infiniti (la richiesta di un particolare servizio si differenzia dal puntualizzare le modalità con cui si vuole che tale servizio venga offerto). I requisiti possono infine essere differenziati secondo il punto di vista che esprimono. i punti di vista più comuni sono quelli del committente, dell’utilizzatore, del sistema e del progettista.

Analisi e specifica requisiti

Il processo di definizione, quindi, è il processo di raccolta dei requisiti, mentre il rpocesso di specifica dei requisiti è la successiva fase di validazione dei requisiti.

Si illustrino l’input e l’output dei seguenti due processi software: (i) l’iniziale deduzione/elicitazione & analisi dei requisiti (requirements elcitation & analysis) e (ii) la successiva specifica(zione) dei requisiti (requirements specification).

• elicitazione & analisi dei requisiti

Gli ingegneri del software lavorano con i clienti per capire il dominio di applicazione, i servizi che il sistema deve fornire,..

Per fare questo si avvalgono di alcuni metodi: documentazione sul dominio, punti di vista da parte di più stakeholder/utenti finali, interviste su set di domande, scenari con esempi di attività comunemente svolte, use case per aiutarsi, etnografia osservazione di lavoro in contesto sociale aziendale.

output: documento requisiti informale in linguaggio naturale strutturato, parla in linguaggio naturale ma manitiene uniformità. Limiti alle terminologia e uso di templates.

• specifica dei requisiti

Validazione dei requisiti, ovvero far vedere al cliente che il sistema è proprio quello che aveva definito in precedenza. E’ una fase importante perché, ingegnere e cliente vengono a punti di incontro sui requisiti, capendo cos’è c’è di erroneo in quanto definito in precedenza. Vanno controllate alcune caratteristiche quali:

• validità, i servizi forniti sono validi? vanno bene?
• coerenti, i requisiti nel documento non devono essere incoerenti, possibilmente
• completezza, devono coprire tutte le richieste del cliente
• realismo, tenere in considerazione la conoscenza tecnologica e budget
• verificabili, per evitare conflitti, fare dei test che provino ogni requisito.

Come? Attraverso prototipi, review dei requisiti analizzati da un team, e generazione di casi per i test. Le review è portata avanti dal team sviluppatore che guida il cliente attraverso i requisiti del sistema.

input ii: ouput della fase precedente
output: documento di sw reqs ufficiale, quello degli sviluppatori

Si illustri cosa sono e a cosa servono le partizioni di equivalenza utilizzate nel testing. Si descriva come si progettano nel caso del testing strutturale (white-box)

Le partizioni di equivalenza sono insiemi di valori di input raggruppati in base al fatto che producono comportamenti e/o output simili in un determinato componente o funzione. Esse sono strettamente collegate al testing strutturale white box (potrebbe essere anche black per alcuni aspetti) perché è dalla conoscenza interna del componente analizzato, che è uno dei presupposti di questo tipo di testing, che possono essere generate le partizioni. Il loro uso tipico è quello di mettere alla prova il componente dandogli in input valori di confine tra due partizioni e per verificare che il comportamento sia effettivamente differente e gli output stiano a loro volta in partizioni distinte.

Test strutturale: a scatola bianca, consiste nel derivare dei casi test in base alla struttura del programma, maggiore è la conoscenza maggiore il numero di casi. L’obiettivo è di esercitare tutte le dichiarazioni del programma.

Definizione di white-box: Testing incrementale di integrazione

Si definiscano i processi di verifica e validazione del software. Quali diverse attività di validazione vengono svolte nelle diverse fasi del ciclo di vita?

Per le definizioni vedi: V&V

I processi di verifica e validazione vengono svolti in seguito alla fase di implementazione e codifica, una o più volte e con target diversi a seconda del metodo di sviluppo adottato. Per avere una copertura completa dovrebbe essere svolta insieme alla verifica.

Cos’è un modello di qualità del software? Si elenchino le principali caratteristiche di qualità di un generico modello di qualità.

La qualità puo’ essere difinita come la totalità delle caratteristiche e degli aspetti di un prodotto software relativo alla sua abilità di soddisfare i bisgoni definiti o impliciti. Caratteristiche di qualità del software, sono gli attributi di un prodotto software dai quali la sua qualità è descritta e valutata.

Un modello di qualità del sw è un insieme di regole che devono essere rispettate in tutte le fasi del processo sw e di attributi che deve possedere un prodotto sw.

Le caratteristiche esterne sono quelle valutate durante l’esecuzione del software, quelle interne sono valutate durante l’ispezione per sviluppatori e manutentori e quella in uso misurano l’effetto di usare il software in una specifico constesto d’uso.

• affidabilità: capacità di fornire i servizi senza guasti e malfunzionamenti (è sempre la stessa minestra ma ripetere non fa male)
• efficienza: uso corretto delle risorse e tempi ragionevoli
• manutenibilità: adattabilità a modifiche, stabilità nel tempo
• portabilità: adattabilità a vari sistemi, conformità agli standard
• usabilità: facilità d’operazione e comprensione
• funzionalità: utilità dei servizi forniti, accuratezza, capacità di interagire con altri sw

Cosa significa Gestione della Qualità? Quali sono i processi principali della gestione della qualità? Cos’è lo standard ISO 9000?

La gestione della qualità è in generale un insieme di operazioni da effettuare e comportamenti da seguire affinché un prodotto venga considerato di qualità. Nel campo del sw la gestione della qualità accompagna il prodotto in tutto il ciclo di vita, dalla raccolta dei requisiti fino alla dismissione, e prevede una figura o una squadra di persone che si occupi di tutti gli aspetti riguardanti la qualità.

I processi principali della gestione della qualità controllano il processo software nella sua interezza, con particolare focalizzazione sulle fase di verifica e validazione. Tali controlli sono schedulati periodicamente e si traducono in documenti in cui i responsabili approvano l’operato degli sviluppatori o esprimono critiche (possibilmente costruttive) per far rientrare il lavoro negli standard di qualità scelti.

ISO 9000 è una famiglia di standard che contiene tutte le linee guida per i sistemi di gestione della qualità. l’ISO 9000-3 rappresenta il documento dedicato alla qualità del sw.

Si illustri il concetto di fidatezza (dependability) del software. Quali sono le sue 4 componenti principali? Come varia il costo del software all’aumentare del livello di dependability e perché?

La fidatezza rispecchia il giudizio degli utenti relativamente a quanto essi si fidano del sistema, specialmente se critico, ossia la loro fiducia nel fatto che il sw offrirà loro il servizio richiesto senza fallimenti e con tempi di reazione/risposta ragionevoli. Questo parametro è prettamente soggettivo, infatti un sw oggettivamente utile e funzionante non ha necessariamente un punteggio alto di fidatezza. Utilità e fidarsi del sistema non sono la stessa cosa, un sistema non deve essere fidato per essere utile.

Dimensioni:

• disponibilità, possibilità del sistema di fornisre il servizio quando richiesto
• affidabilità, abilità del sistema di fornire i servizi come specificato
• sicurezza, abilità del sistema di operare senza fallimenti catastrofici
• protezione, abilità di proteggere se stesso contro intrusioni

Più aumenta il livello di fidatezza richiesto più aumentano i costi. Questo perché comporta l’uso di tecniche di sviluppo più costose e hw ad hoc. Facendo così anche la fase di testing per convincere il cliente che il sistema è affidato con la fase di V&V aumenta notevolmente in tempi e quindi costo maggiore rispetto ai sistemi normali (V&V > 50%).

Nell’ambito della validazione dell’affidabilità (reliability validation) quale tipo di testing viene utilizzato e come si effettua? Cos’è un profilo operativo (operational profile) e come viene usato?

Validazione dell’affidabilità. L’affidabilità misurata dal sistema è quelal definita nelel specifiche?

Per la validazione dell’affidabilità viene utilizzato un testing dinamico denominato testing statistico. Esso prevede l’esecuzione ripetuta del sw, durante la quale vengono contati errori e malfunzionamenti. Questo tipo di testing quantifica l’affidabilità del sw e in base al livello di affidabilità da raggiungere determina se è necessario procedere con un’ulteriore fase di miglioramento.

I casi di test con cui avvengono le esecuzioni del programma sono basate sui cosiddetti profili operativi, ossia insiemi di dati creati per il testing la cui frequenza rispecchia quella con cui tali dati vengono forniti in input al sistema durante l’uso normale previsto

Cos’è e quando si usa il path testing (testing dei percorsi)?

Quali sono i suoi limiti? Come si può a priori stimare il numero di casi di test necessari per la sua esecuzione?

L’obiettivo del Path Testing è quello di assicurarsi che l’insieme dei casi di test siano eseguiti attraverso il programma almeno una volta. Il punto di partenza di questo tipo di testing è un grafo di flusso del programma che mostra i nodi come decisioni e gli archi come flusso di controllo. Ogni bivio è un pass (grazie Maria per averci lasciato queste perle!) separato. I loops sono evidenziati da cicli. E’ un tipo di testing strutturale - scatola bianca.

Non è detto che eseguire tutti i path significhi aver esaurito le combinazioni di path.

La compessità ciclomatica, definita come archi-nodi+2, è il numero di test da effettuare per controllare tutte le istruzioni, equivale al numero di condizioni del programma+1.

In che modo il modello dei processi di sviluppo software basato sulla consegna incrementale (incremental development) puo’ essere considerato una via di mezzo tra il modello a cascata (waterfall) e il modello evoluzionistico (evolutionary/prototyping)? Quali criticità supera e quali vantaggi coglie degli altri due modelli?

• sviluppo incrementale
  

Iterativo.

Sviluppo basato su incrementi successivi, invece di spedire il sistema in un’unica soluzione lo sviluppo e l’invio è dato da incrementi. Gli incrementi sono parti del sistema. Gli invii di incrementi rispecchiano la priorità data dagli utenti ai vari requisiti. Una volta che il lavoro su un incremento è iniziato, le richieste sono congelate fino all’invio/inizio successivo.

Definizione dei requisiti, assegnazione requisiti agli incrementi, design dell’architettura del sistema, dopo si inizia lo sviluppo dei vari incrementi: ogni incremento portato a termine deve essere validato separatamente, integrato al sistema già costruito e validato di nuovo. Fino a che il sistema è incompleto, il loop continua dando vita pian piano al software completo.

E’ un modello ibrido.

Vatanggi: le funzionalità del sistema sono fornite prima e non si deve attendere il completamento del sistema per utilizzarne in parte. I primi incrementi sono come prototipi ed aiutano a definire meglio i requisiti. Minore rischio di fallimento. Gli incrementi a priorità più alta, inviati prima, ricevono più testing.

Contro: non avendo le complete specifiche all’inizio è difficile identificare il ‘giusto’ incremento e la loro grandezza, come il sistema va scomposto e quali parti sviluppare prima. Difficoltà di identificare i servizi comuni.

• waterfall

Ogni processo segue un certo ordine e si comporta come una cascata, l’acqua scende e non puo’ più risalire. Questo è in teoria.

Definizione dei requisiti -> genera documento

Design del sistema e del software -> genera documento

Implementazione e tetsing -> genera documento e prodotto

Operatività e manutenzione. (Secondo Sommerville)

Contro: Purtroppo in realtà non è così, ad ogni stage dell’approcco il lavoro puo’ tornare ad uno degli altri punti.

Pro: ogni  fase è documentata e firmata prima di procedere, il manager è felice perché conosce l’esatto punto dei lavori.

• evolutionary/prototyping
  

• sviluppo esplorativo/prototipizzazione

L’obiettivo è quello di lavorare con il committente, evolvendo il sistema da una specifica iniziale. Si dovrebbe iniziare da requisiti meglio compresi.

• throw-away prototyping

L’obiettivo è capire quali sono i requisiti del sistema. Si dovrebbe iniziare da requisiti meno chiari.

Contro: poca visibilità, non ci sono documenti intermedi per sapere lo stato in cui ci troviamo, sistemi spesso con scarsa struttura, richiede conoscenze specifiche (linguaggi veloci, apposta per la prototipizzazione)

• sviluppo sistemi formali
• riuso
• sviluppo iterativo

Iterativo.

Inizia con l’intero sistema, poi cambia funzionalità/implementazione di ogni sottosistema ad ogni release.

• sviluppo a spirale

Iterativo.

Il modello a spirale è un tipo di modello iterativo in cui l’analisi del rischio e la pianificazione sono considerati di primaria importanza. In ogni ciclo della spirale sono appunto previsti l’impostazione degli obiettivi, la definizione dei rischi, la ricerca delle modalità per ridurli al minimo e la scelta del modello per la componente in corso di sviluppo. A differenza degli altri modelli più rigidi, come ad esempio il waterfall, il spirale segue una successione di passi che gli permette di rifare delle fasi già seguite in precedenza. Così facendo si garantisce che eventuali problemi non si amplifichino a dismisura perché è teoricamente sempre possibile ritornare ad un punto precedente della spirale in backtracking. In un certo senso si potrebbe affermare che il modello a spirale è simile ad un modello incrementale con sottofasi non rigidamente separate, in cui però il rischio e la pianificazione vengono messi in primo piano.

4 settori che loopano, invece di tornare indietro.

1. settare gli obiettivi in base alla fase e determinare i rischi
2. riduzione dei rischi
3. scelgo il mio tipo di sviluppo in base al rischio (interfaccia - evolutivo, sicurezza - formale)
4. ci serve un ulteriore loop?

Questo modello tiene effettivamente conto del rischio, si diminuisce l’amplificazione degli errori ed in ogni momento diventa possibile fare un backtracking.

• extreme programming

Nuovo approccio allos viluppo basato su sviluppo e consegna di piccoli incrementi di funzionalità. Richiede costante miglioramento del codice e interazione costante con il cliente durante lo sviluppo.

Il modello a consegna incrementale è una via di mezzo perché pur attenendosi alle varie fasi del processo come il modello a cascata, si basa su incrementi che possono essere considerati evoluzioni del sistema. una fase viene superata quando è definitiva come nel modello a cascata, ma richiede meno tempo in quanto non è l’intero sistema ad essere sviluppato ma i suoi blocchi componenti, ed i risultati non vengono buttati via come nel prototyping di tipo throw-away

La domanda trova risposta, la lista dei modelli/approcci verrà finita in seguito. Aggiornato.

Si illustri il processo di sviluppo del software che prevede una consegna incrementale. Si fornisca un modello del processo (in sottoprocessi) e se ne illustrino vantaggi e problemi.

Cos’è il software prototyping? In quali situazioni si utilizza e perché? Come si esegue?

La prototipizzazione è una tecnica che consiste nel costruire versioni del sw (prototipi) che evolvono dalla versione iniziale a quella finale grazie alla collaborazione con i committenti. Quando i requisiti sono stati chiariti fin dall’inizio allora si parla di sviluppo esplorativo, mentre quando si parte da requisiti vaghi lo scopo è proprio quello di scoprirli e si parla di throw-away prototyping.

Si descrivano le diverse attività svolte nell’ambito della gestione dei progetti software (software project management). Che cosa sono le “pietre miliari” (milestone)? E le cosegne (deliverable)? Quali sono le relazioni fra i due concetti?

La gestione dei progetti sw si occupa di tutti gli aspetti organizzativi di un progetto sw. A capo di tutto c’è il Project Manager, che ha la responsabilità di supervisionare il progetto in tutte le fasi, dalla raccolta dei requisiti alla fine del ciclo di vita del sw con il suo ritiro.

Il project manager:

- ha a che fare con un prodotto intangibile, il software non si tocca come una nave, per vedere i progressi si basa sulla documentazione

- non ci sono standard di processi software, variano da un progetto all’altro e non si puo’ sapere quando un processo nasconde rischi.

- i grandi progetti software spesso sono problematici anche per manger con molta esperienza, difficile scoprirne a priori i rischi. Non è detto che quello che viene appreso da un progetto possa essere utile al successivo, obsolescenza.

Scrive una proposta di come il lavoro verrà affrontato specificando anche i costi per vincere l’appalto.

Il PM sogna un gruppo di lavoro composto da persone competenti ma spesso i suoi sogni vengono disattesi per problemi di budget, disponibilità personale o training di nuovo organico.

Il progetto viene pianificato con milestones e deriverables. Monitorano il progresso in modo formale con strumenti o informale. Documenti vengono redatti, in linguaggio naturale, per utenti e stakeholders.

Project Planning, pianifo il piano di attività da svolgere, non bisogna mai essere troppo ottimisti, gli imprevisti non partono dal via! (gli imprevisti sono sempre in agguato).

La pianificazione del progetto è uno dei lavori più difficili da fare, bisogna stimare i tempi delle varia fasi del processo, organizzarli nella giusta successione, non essere troppo pessimisti/ottimisti e pensare ai processi paralleli che vanno portati avanti per poter assemblare un sotto sistema. Solitamente mappato con grafi.

Milestones= è la fine di uno stage logico, non troppo lungo ma abbastanza chiaro da far capire al manager il punto in cui si è. Le percentuali non valgono in questo lavoro. Non devono per forza essere deliverables. Sono prodotti intermedi dell’implementazione del sistema o parte di esso considerate punti definitivi conclusi, da cui partire per le fasi di sviluppo successive

Deliverables= prodotto pronto che puo’ essere spedito al cliente ed utilizzato. Quando una pietra miliare può essere consegnata al committente, essa diventa deliberable, ossia un prototipo funzionante e funzionale che può essere utilizzato e valutato dal cliente

Le due cose possono coincidere o le milestones essere passi per avvicinarsi alla parte di prodotto pronto per la consegna.

La gestione prevede quindi: allocazione delle risorse finanziarie, gestione del personale (scelta degli individui, assegnazione dei vari compiti, training,…), pianificazione delle fasi, controllo del regolare svolgimento del processo e soluzione di problemi, stesura di relazioni periodiche, rapporti con i committenti,…

Pianificare una lista di possibili rischi relativi al progetto, contare gusti, malattie, rapimenti alieni, rischi di business.

Pianificare l’uso del personale del team a disposizione, è possibile che una persona segua più progetti e quindi il tempo di disposizione per un progetto sia contato. Mappato con Gantt per le dipendeze staff-tempo.

Gestione del rischio: Analisi dei rischi di progetto e di business. Identifico i veri rischi grazie ad attività di brainstorming ed esperienza,  di ognuno penso a quali potrebbero essere le conseguenze e la probabilità che accadano. In base alla tabella deciso se è meglio evitarli, ignorarli, monitorarlo o trovare un modo per minimizzarlo.

Rivista e sistemata da Filippo.

Qual è il metodo più utilizzato per la verifica statica del software? Come si attua? Che tipo di risultati fornisce? Ha senso pensare di utilizzare solamente tale metodo per la Verifica&Validazione del sistema software?

V&V, ovvero la verifica che il sistema software rispecchi i bisogni degli utenti.

• verifica

“stiamo costruendo per bene il prodotto?” Il software deve essere conforme alle specifiche, ovvero se la sua costruzione è ‘giusta’.

- ispezioni software relative alla documentazione, specifiche, design e codice.

il metodo più utilizzato per la verifica statica del sw è senz’altro l’ispezione. essa consiste nell’analisi del codice da parte di un team di persone che comprende di solito un coordinatore, coloro che hanno scritto il codice ed persone esterne capaci di dare un giudizio tecnico. L’ispezione prevede una lista di errori e sviste comuni che possono essere commessi nella stesura del codice, che vengono così cercati e rimossi.
Questo tipo di verifica è molto efficace perché non richiede il sistema intero per essere effettuato e consente così di passare alle fasi successive.

- metodi formali di specificazione del software e codice corrispondente.

Basati sulla rappresentazione matematica del software. Dalle specifiche formali e analisi, lo sviluppo trasformazionale ‘crea’ il codice che, ovviamente, va verificato. Pro: si riduce il numero di errori, applicabile sui sistemi critici, incompletezze e inconsistenze scoperte e corrette velocemente (money-saving). Contro: occupa un tempo notevole, notevoli cosi per le specifiche.

Sono entrambi metodi statici.

- Testing delle funzionalità descritte dalle specifiche. Metodo dinamico.

• validazione

“stiamo costruendo il giusto prodotto per i clienti?” Il software deve fare quello che l’utente finale davvero richiede. E’ un processo per capire se il software soddisfa o meno i bisogni impliciti ed espliciti del cliente. Quello che l’utente finale davvero vuole è spesso ancora nelle loro teste.Usata a livello sistema/sottosistema, granularità variabile.

- testing validativo, uso del sistema, beta testing, testing statistico, simulazione). Dinamico.

Dimostra allo sviluppatore e al cliente che il software è conforme ai requisiti, il buon esito mostra che il sistema opera come dovuto.

Il testing statistico misura la frequenza tra input degli utenti ed errori riscontrati. Serve per verificare se si è raggiunto il giusto livello di affidabilità.

vedi anche: validazione dell’affidabilità

- prototipizzazione, creare prototipi del sistema per capire. Dinamico.

- ispezione di requisiti, progettazione, codice, validazione, dati per test. Statico.

Naturalmente non ha senso utilizzare solamente il metodo statico poiché così facendo rimarrebbero tutti gli errori non dipendenti dalla natura del codice ma rilevabili solo al momento dell’esecuzione, ad esempio a causa di input scorretti o particolari situazioni dipendenti dallo stato del sistema (rete sovraccarica, memoria limitata,…).

Rivisto e sistemato da Filippo. Ringrazio il mio fan numero uno, il Bardi.

placidiappunti:

FREDDO NELLE VARIE LINGUE E DIALETTI

Frig(i)dus – Latino
ψῦχος - Greco antico
Cold – Inglese
Froid – Francese
Frio – Spagnolo
Kalt – Tedesco
Kylmä – Finlandese
Freido (pron freidu) - Genovese
Fradd – Bolognese
Frèid – Piemontese
Frègg-Frecc – Lombardo
Friddo – Napoletano
Frêt - Friulano
Friddu – Calabrese

e poi?

Grazie di aver messo anche le mia lingua!

Perché è importante capire i requisiti di un sistema software? Quali sono le conseguenze di un cambiamento dei requisiti durante la varie fasi dello sviluppo? Quali sono le possibili cause di tali cambiamenti? Come si possono minimizzare gli effetti negativi di tale fenomeno?

Capire i requisiti di un sistema software è fondamentale in quando ne dipende la corretta riuscita del prodotto. Poiché i requisiti rappresentano ciò che il committente e/o l’utente si aspetta, un’erronea comprensione dei requisiti implica un software che non risponde alle esigenze di chi lo userà. Sia nel caso di requisiti dettagliati fin dall’inizio, sia quando i requisiti vengono definiti in passi successivi, è importante che ci sia chiarezza e colui che rileva i requisiti deve avere consapevolezza del dominio d’uso del software.

I requisisti di un sistema cambiano spesso, anche quando il progetto parte, questo perché gli stakeholders trovano nuovi requisiti oppure perché bisogna negoziare tra più persone un compromesso (chi paga il software non è quasi mai l’utente finale). Le conseguenze di un cambio di requisiti in corso d’opera possono essere ad esempio contraddizioni con quello che era già stato sviluppato o aumenti di complessità nella struttura del sw. tra le cause dei cambiamenti possono esserci nuovi stakeholders, variazioni del target degli utenti, evoluzioni del mercato,…

E’ utile pianificare la gestione dei requisiti:

1. identificazione dei requisiti: ogni requisito è unico.
2. gestione del cambio dei requisiti
3. politiche di tracciabilità: le relazioni tra di essi
4. CASE usati

Per minimizzare gli effetti negativi è possibile compilare una lista dei requisiti, collegare ogni voce a colui che l’aveva richiesta e documentare quali sono state le scelte dettate dai vari requisiti. In questo modo è possibile riadattare lo sviluppo in maniera oculata e conciliare eventuali requisiti discordi.

Punto 3: si tratta di analizzare il problema e le specifiche del cambio, il cosa. Successivamente si analizza il costo di un possibile cambio dei requisiti, usando tracciabilità si quantificano i costi, è una stima del come. Infine se è possibile, si procede con il cambio di implementazione.

Si presenti il modello generale per il processo di progettazione del software (software desing), illustrando le diverse attività ed i loro prodotti nelle varie fasi dalla fine della specificazione all’inizio dell’implementazione.

Il software design consiste nella traduzione dalle specifiche ad un software eseguibile in questa fase si sceglie e si progetta una struttura che realizzi le specifiche in particolare è necessario progettare tutti i vari elementi del software, ossia l’architettura, i livelli di astrazione, le interfacce, i componenti, le strutture dati e gli algoritmi; per ognuno di questi elementi viene quindi prodotta una specifica in linguaggio tecnico adatta ad essere utilizzata da coloro che scriveranno il codice del software.

• Progettazione architetturale

in particolare la progettazione architetturale prevede una scomposizione del sistema in sottosistemi, componenti, sottocomponenti e così via a seconda dei livelli di astrazione necessari, producendo la descrizione dell’architettura del software. Ci si occupa di definire i servizi offerti dai vari elementi e le modalità di interazione tra di essi.

• specificazione astratta

per ogni sotto sistema viene prodotta un specificazione astratta dei servizi

• design dell’interfaccia

per ogni sottosistema di progetta e documenta l’interfacciamento con del altre parti del sistema

• design dei componenti

allocazione dei servizi e progettazione delle interfacce proprie delle singole componenti

• design della struttura dati

scelta della struttura dati più adatta per l’implementazione, dettagliata e specificata

• design dell’algoritmo

vengono definiti gli algoritmi usati per i servizi

Si illustri il concetto di testing incrementale di integrazione. Si spieghino i due approcci al testing denominati rispettivamente black box e white box.

Testing incrementale di integrazione.

Il testing incrementale di integrazione è un tipo di testing in cui i vari sottocomponenti vengono inizialmente testati uno ad uno una volta che questa fase ha successo si procede ad integrarli, ottenendo così un componente più complesso che viene testato a sua volta. Infatti, il comportamento del componente così assemblato potrebbe presentare difetti non riscontrabili a livello dei singoli sottocomponenti. Quando tutti i componenti sono stati testati li si unisce nel sistema finito (o in un parte di esso se necessario) che viene testato nella sua interezza. Si basa sulle specifiche.

• black box

Il livello di conoscenza del componente consentito ai responsabili dell’operazione è la conoscenza del solo l’aspetto esterno del componente, ossia l’interfaccia che mette a disposizione, i servizi che fornisce ed il comportamento previsto nei vari casi.Alcuni tipi: testing dei componenti, integration testing e release testing.

• white box

I testers invece conoscono anche i meccanismi con cui i servizi offerti dal componente vengono generati, potendo in questo modo cercare i punti deboli e metterli alla prova. Tipo: testing strutturale.

il testing di integrazione incrementale tipicamente prevede una combinazione delle strategie bottom-up e top-down.

Cos’è il testing di integrazione? Quali sono le due principali strategie adottate? Si descrivano entrambe, mettendone in luce le differenze.

L’integration testing ha lo scopo di testare (sotto)sistemi formati da componenti integrati, sempre black-box.

La difficoltà principale è localizzare gli errori e per questo di usa il testing incrementale di integrazione

Le strategie sono top-down e bottom-up. La strategia top-down parte dai livelli più alti e utilizza degli stubs per i livelli inferiori. Al contrario quella bottom-up testa prima i componenti di livello più basso guidati da test drivers, che rappresentano i componenti superiori che andranno a sfruttarli.

banshee46:

ho appena finito un tubo di pringles

studia! (quoto dal tuo post di ieri ovviamente! :P )

Non dimenticare da chi sarai portata a casa e tra quali braccia ti troverai, oh cara, riserva l’ultimo ballo per me

- The Drifters

banshee46:

io:freddo!
lui:neve!
io:noia!
lui:studia!
io: amore!
lui:crudo!
io:cacca!
lui: lo stavo per dire io.Ma “cacca” dopo “amore” mi sembrava esagerato!

E’ bellissimo!

C’è solo una cosa che non ho capito.. perché crudo dopo amore?

Perché Muccino è tornato a impestarci qua in Italia?

Ha fatto un bel film con Will Smith e figlio, ottimo. Ma perché fare il seguito dell’ultimo bacio?

Io penso che le cose tristi dopo un po’ stufino, se lui solo quello sa fare, non è meglio che le faccia in grande fuori dalla patria?

Penso che una storia a lieto fine e felice per tutti i 90 min di film (o quel che è) sia meglio di una brodaglia di gente che piange, si lascia e si tradisce con crisi isteriche, ma basta cose tristi!

1FN

• ogni attributo è definito su un dominio con valori atomici
• esiste una chiave primaria

2NF

• 1NF
• campi non chiave dipendono funzionalmente dall’intera chiave composta

3NF

• 2NF
• per ogni dipendenza funziona X->Y è vera una delle seguenti condizioni:

1. X è una superchiave della relazione (insieme di attributi che identifica univocamente una tupla all’interno dell’istanza di una relazione)
2. Y è membro di una chiave della relazione (tutti gli attributi dipendono dalla chiave e non da attributi non chiave)

BCNF

• una relazione r si definisce in BCNF quando per ogni dip funz non banale X->Y allora X è superchiave di r
  

• decomposizione che non produce perdite una volta rijoinato assieme (emp -> brench, proj -> brench, rijoinando creo tuple che prima non c’erano)
• preservazione delle dipendenze, cioè la decomposizione non deve poter inserire dati illegalmente (emp -> brench, emp ->project, dove project -> brench dipendenza)

oblivious-to-jelly:

sugarmepink:

liveloveparamore:

play a game
IF YOUR FIRST NAME’S FIRST LETTER IS:
A-C put “BRB,”
D-F put “SHOULD BE”
G-I put “HE IS”
J-L put “SHE IS”
M-O put “STOP”
P-R put “NEED TO BE”
S-U put “I ENJOY”
V-X put “GROUNDED FROM”
Y-Z put “OH, I’M JUST”

NEXT!
IF YOUR LAST NAME’S FIRST LETTER IS:
A-C put “HUMPING”
D-F put “BAKING”
G-I put “TOUCHING”
J-L put “RAPING”
M-O put “SUCKING”
P-R put “SMOKING”
S-U put “PUNCHING”
V-X put “SMELLING”
Y-Z put “EATING”

LASTLY!
IF YOUR MIDDLE NAME’S FIRST LETTER IS:
A-C put “COOKIES”
D-F put “BOXES”
G-I put “FEET”
J-L put “DICKS”
M-O put “MOOSE”
P-R put “MEN”
S-U put “KEYBOARDS”
V-X put “VACCUUMS”
Y-Z put “GEESE”


REBLOG WITH YOUR RESULT!

liveloveparamore: BRB, eating moose.

BRB, punching cookies. D:

She is raping keyboards…?! o-o;

Stop eating keyboard