Ingegneria del Software

DEVOPS

DevOps, ovvero "Development" e "Operations", è una metodologia di sviluppo che è l'evoluzione del metodo agile: favorisce la comunicazione, collaborazione e integrazione tra gli sviluppatori ed esperti IT permettendo una rapida evoluzione e riducendo rischi e costi del software.

Il time to market è tiranno e agli sviluppatori si chiede maggiore velocità nella messa in produzione di software e di app. L'approccio DevOps è un modello secondo cui team di sviluppo interfunzionali programmano in maniera più rapida, rilasciando soluzioni di qualità e sicure per ambienti tradizionali e in cloud.

Chi si fregia della qualifica di DevOps non è detto né che sia uno sviluppatore capace anche di coprire l'aspetto più operativo della programmazione, né che un esperto Ops abbia imparato anche a sviluppare codice. Il fatto è che il Devops presuppone che in azienda ci sia un team interfunzionale.

dove ogni risorsa è responsabile di tutto. In ambito aziendale oggi comunque è ancora molto raro trovare un'organizzazione che possa qualificarsi come un negozio DevOps a tutto campo. Piuttosto, si tende a trovare una squadra DevOps, allineata con applicazioni specifiche, come ad esempio un team specializzato nel mobile, un altro specializzato nel checkout e via dicendo. L'adozione della metodologia DevOps è guidata da diversi fattori, come: 1. Utilizzo della metodologia agile; 2. Necessità di incrementare la frequenza dei rilasci; 3. Ampia disponibilità di un'infrastruttura virtualizzata e in cloud; 4. Incremento nell'uso di data center automatizzati. Coordinatore del rilascio Si tratta di un ruolo relativamente nuovo nelle aziende IT, il cui compito è di coordinare i rilasci in ambienti pre-produzione (di test). La necessità di tale figura viene da: - La necessità di ridurre il "gap" tra sviluppo egestione:

• Accresciuta complessità dell'infrastruttura, ad esempio applicazioni multipiattaforma;
• Incremento della frequenza dei rilasci, ad esempio per via dell'utilizzo della metodologia agile;
• Gruppi delocalizzati, come nel caso dell'utilizzo di risorse esterne o in sedi diverse.

Ingegneria dei Requisiti:

L'ingegneria dei requisiti consiste nello stabilire i servizi richiesti dal cliente e i vincoli da rispettare. I requisiti, ossia la descrizione dei servizi, sono l'output di questo processo.

Un requisito identifica un attributo, capacità, bisogno, caratteristiche o qualità che il sistema deve avere.

I requisiti si suddividono in:

• REQUISITI UTENTE: requisiti ad alto livello, in linguaggio naturale;
• REQUISITI DI SISTEMA: requisiti a basso livello e dettagliati. Essi si suddividono in:
1. Requisiti funzionali: cioè cosa il sistema deve fare e come comportarsi a seguito di determinati input.

funzionali non devono essere ambigui ma devono essere completi e consistenti (includere la descrizione di tutti i servizi e non ci devono essere conflitti);

2. Requisiti non funzionali: definiscono le proprietà e i vincoli del sistema da rispettare, possono riguardare singole componenti del sistema o il sistema completo. Si suddividono in:

• Di prodotto: riguardano le proprietà del prodotto finale (prestazioni);
• Organizzativi: conseguente di politiche organizzative (standard, implementazioni);
• Esterni: non dipendono dal progetto (etica, leggi).

3. Requisiti di dominio: sono requisiti imposti dal dominio applicativo del sistema e non soddisfarli comporterebbe l'impossibilità di utilizzare il sistema (requisiti ovvi a persone che lavorano nel dominio ma di difficile comprensione ad altri, molto spesso vengono considerati ovvi dal cliente e non vengono manifestati).

Tutti i requisiti sia "utente" che "di sistema" vengono riportati nel

Il documento dei requisiti è un documento che elenca e descrive in dettaglio i requisiti di un sistema software. Questo documento è fondamentale per guidare lo sviluppo del software e per garantire che il prodotto finale soddisfi le esigenze degli utenti. Nei metodi agili, tuttavia, la produzione di un documento dei requisiti completo e dettagliato potrebbe essere considerata uno spreco di tempo. Questo perché i requisiti sono spesso soggetti a cambiamenti frequenti e rapidi nel corso del progetto. Invece di dedicare tempo alla scrittura e alla manutenzione di un documento statico, gli sviluppatori agili preferiscono comunicare direttamente con i clienti e gli stakeholders per comprendere e soddisfare le loro esigenze in modo più flessibile. Tuttavia, ciò non significa che i requisiti non debbano essere documentati affatto. È comunque importante registrare e tracciare i requisiti in qualche modo, anche se in modo più leggero e adattabile. Questo può essere fatto utilizzando strumenti come user stories, elenchi di controllo o diagrammi. I processi di ingegneria dei requisiti includono diverse attività che possono variare a seconda del progetto, ma generalmente seguono le seguenti fasi: 1. Elicitazione dei requisiti: coinvolgere i clienti e gli stakeholders per identificare e comprendere i requisiti del sistema. 2. Analisi dei requisiti: analizzare e comprendere i requisiti raccolti, organizzarli in gruppi coerenti e identificare eventuali conflitti o ambiguità. 3. Validazione dei requisiti: verificare che i requisiti soddisfino le esigenze degli utenti e siano coerenti con gli obiettivi del progetto. 4. Gestione dei requisiti: tracciare e gestire i requisiti nel corso del progetto, tenendo conto dei cambiamenti e delle modifiche necessarie. In sintesi, sebbene la produzione di un documento dei requisiti completo possa essere considerata uno spreco di tempo nei metodi agili, è comunque importante comprendere, registrare e tracciare i requisiti in modo adattabile e flessibile per garantire il successo del progetto.Specificazione. Parte del processo di E&A sono anche le interviste che possono essere:

• Chiuse: lista di domande predefinite;
• Aperte: discussione per risolvere diversi problemi.

Le interviste non sono adatte per i requisiti di dominio. I problemi di queste fasi sono che le parti interessate non sanno cosa vogliono e i fattori esterni possono influenzare i requisiti. Nella fase di Elicitation e Analysis vengono utilizzati gli scenari e i use case; gli scenari sono delle descrizioni di esempi di utilizzo del sistema e contengono informazioni sugli eventi che possono accadere sulla situazione iniziale e finale; gli use case sono dei diagrammi che spiegano in modo grafico uno scenario. Nella fase di Validations si cerca di dimostrare che i requisiti rispecchino le reali necessità del cliente; se si presentano errori nella fase di validazione dei requisiti è ancora peggio che riscontrarli in fase di implementazione. Fare una verifica dei requisiti significa verificare la.validità (cioè che rispecchiarealmente i bisogni dell'utente), la consistenza (cioè rimuovere i conflitti), la completezza (che rispecchino le funzionalità richieste), il realismo (cioè la fattibilità) e la verificabilità. Il modo in cui vengono verificate queste proprietà può essere: - Review dei requisiti, cioè l'analisi manuale; - Prototipo, usare un modello di riferimento; - Test, per verificarne la testabilità. Gestione dei Requisiti La gestione dei requisiti si occupa del processo di gestione del cambiamento dei requisiti; è necessario tenere traccia dei cambiamenti per valutare gli impatti che essi hanno. Per capire come gestire il cambiamento al meglio, bisogna affrontare una fase di planning in cui si stabilisce il livello dei dettagli che si vuole mettere nella gestione; per fare ciò si deve innanzitutto definire in maniera univoca i requisiti e poi valutare l'impatto che un cambiamento può avere.

cambiamento potrebbe avere all'interno del sistema in termini di costi di modifica. Bisogna anche seguire le politiche di tracciabilità, ovvero definire le relazioni tra ogni requisito e tra i requisiti e il sistema; bisogna utilizzare degli strumenti di supporto.

La gestione dei requisiti prevede anche la decisione se un cambiamento dei requisiti deve essere accettato o meno; questa decisione viene presa affrontando 3 step:

1. Analisi del problema e specificazione del cambiamento = analizzare la proposta;
2. Analisi del cambiamento e dei costi = analisi dell'impatto usando la tracciabilità. Si decide se accettarlo o meno;
3. Implementazione del cambiamento.

UML è un linguaggio visuale per realizzare e documentare i software. Gli UML sono utilizzati in tutto il processo di sviluppo e non dipendono dal linguaggio di programmazione; servono per descrivere in modo più semplice il sistema. Vengono utilizzati simboli grafici e testo secondo regole sintattiche.

semantiche e pragmatiche. Esistono due versioni di UML. In UML 1 si utilizzano:

1. Viste statiche: "class diagrams", "object diagrams", "component diagrams", "deployment diagrams".
2. Viste dinamiche: "use case diagrams", "sequence diagrams", "collaboration diagrams", "statechart diagrams" e "activity diagrams".

UML 2, ufficializzata nel 2005, presenta numerose novità rispetto alla versione precedente che resta comunque quella più diffusa. Fra le principali novità abbiamo:

1. Composite structure diagram;
2. Package diagram;
3. Interaction overview diagram;
4. Diagramma temporale.

Inoltre, viene introdotto un nuovo linguaggio formale OCL (Object Constraint Language) come parte integrante di UML.

Diagrammi

USE CASE DIAGRAM

Un "Use case Diagram" rappresenta il comportamento del sistema e l'interazione con i vari attori che lo compongono, trascurandone

l'implementazione.Viene utilizzato solitamente per definire i requisiti dell'utente.Le componenti di un diagramma di questo tipo sono:

• Attori: cioè qualcuno o qualcosa che interagisce con il sistema. È indicato con il simbolo di un omino;
• Use Case (o caso d'uso): rappresenta una funzionalità del sistema; si rappresenta con un cerchio. I casi d'uso sono ricavati tramite le interviste con gli utenti.
• Associazioni: cioè relazioni che intercorrono tra attori e casi d'uso; rappresentano le funzionalità che sono offerte all'attore.

Le associazioni possono essere di diversi tipi:

• Inclusione: una funzionalità inclusa nello use case;
• Estensione: una funzionalità opzionale richiamabile dallo use case stesso;
• Generalizzazione/Specializzazione: attori specifici hanno accesso esclusivo a determinati use case. Anche gli use case possono essere specificati.

INTERACTION DIAGRAM

Gli

“interaction diagrams” vengono utilizzati per rappresentare gli scenari, ovvero l’istanza di uno use case, cioè il comportamento della funzionalità considerata. Si chiamano così perché specifichiamo il comportamento tra due oggetti che interagiscono; si suddividono in Sequence Diagrams e Collaboration Diagrams.

SEQUENCE DIAGRAM

I “sequence diagrams” si focalizzano sul flusso temporale dell’interazione e sui messaggi scambiati. Raffigurano gli oggetti coinvolti nello scenario e la sequenza di messaggi scambiati tra gli oggetti necessari per svolgere la funzionalità dello scenario. I diagrammi di sequenza sono talvolta chiamati diagrammi di eventi o scenari di eventi, mostrano come linee verticali parallele (linee di vita) diversi processi o oggetti che vivono simultaneamente e come frecce orizzontali