• Vedi
• Modifica
• Versioni
• Stampa

Processi

I Processi

Autori: Alberto Taiocchi

Processi e organizzazioni

• Processo è un insieme di attività correlate che trasforma ingressi in uscite. Non deve essere visto solo come qualcosa di tecnico in quanto coinvolge diversi aspetti:
  • organizzativi, cosa deve fare il personale.
  • umani, il processo deve essere possibile entro i limiti umani.
  • cognitivi, conoscere il dominio applicativo del processo.
• Prodotto è il risultato dell’esecuzione di un processo
• Progetto è l’esecuzione di più processi

Modellare e classificare i processi

Modellare un processo significa capire il funzionamento dell’organizzazione, capire il funzionamento può portare a delle migliorie). Un processo è un’attività complessa e difficile da gestire. Per migliorarne la gestione viene suddiviso in fasi diverse (specifica, progettazione e codifica). Una volta suddiviso in fasi successive, queste vengono assegnate a gruppi diversi di persone con compiti e competenze diverse (suddividere per gestire, verificare, ridurre i rischi). Il processo è composto da diverse azioni e può essere strutturato nella seguente maniera:

• Comunicazioni, comunicare e collaborare con il cliente, è fase di raccolta dei requisiti e attività affini.
• Pianificazione, stabilisce un piano per il successivo lavoro di ingegneria del software. Descrive le operazioni da svolgere, i rischi, le risorse necessarie, i prodotti da realizzare e la pianificazione del lavoro.
• Modellazione, creazione di modelli che consentono allo sviluppatore e al cliente di comprendere meglio i requisiti software e progettuali
• Costruzione, generazione del codice e attività di collaudo necessarie per individuare gli errori.
• Implementazione, software fornito al cliente che valuta il prodotto e fornisce indicazioni basate sulla propria valutazione.

Un processo di qualità porta ad avere un prodotto qualità.

Processi software

Lo sviluppo di software è un processo complesso, richiede uno sforzo collettivo complesso e creativo. La qualità del prodotto software non dipende solo dalla qualità del processo ma anche dalle persone, dall’organizzazione e dalle procedure utilizzate per sviluppare, controllare e gestire il codice. I processi software vengono distinti in tre classi:

1. Processi primari, progettazione, sviluppo e manutenzione
2. Processi di supporto, documentazione, configurazione, qualità, verfica
3. Processi organizzativi, gestione processi, infrastruttura, miglioramenti, addestramento e formazione.

Modelli di processo di sviluppo software – life cycle

Sono modelli che rappresentano le fasi da seguire e l’ordine per poter realizzare un processo. Ne esistono diversi, non esiste quindi un processo migliore in assoluto, ma quello più adatto per una determinata situazione.

Code and fix

E’ un non modello, viene usato in attività non identificate nE’ organizzate. Si utilizza solo in progetti piccoli e non gestiti. Si basa, ciclicamente,sulle attività di codifica e prova.

Sequenziale o a cascata

E’ stato introdotto da Royce nel 1970. Si utilizza questo modello quando i requisiti del sistema sono abbastanza noti, oppure quando si deve adattare o estendere un sistema esistente. Questo modello è da considerare solo con requisiti ben definiti e stabili. Lo sviluppo procede tramite una sequenza lineare di attività. Ognuna di quest’ultime produce un risultato intermedio usato a valle dall’attività successiva. E’ fortemente sconsigliato iniziare una fase successiva fino a che non si è terminata la precedente. Le attività principali da compiere sono:

• Specifica, cosa deve fare il software (risultato dell’analisi dei requisiti), funzioni,dati, caratteristiche non funzionali, obiettivi, contesto, utenti
• Progettazione, come deve essere fatto il prodotto software che realizza le specifiche, architettura, componenti,connessioni tra componenti, progetto dettagliato
• Codifica, cioè la realizzazione del codice (sorgenti, prodotto installabile, procedura di installazione)
• Test, acquisizione di una sufficiente fiducia che il codice realizza le prestazioni specificate e progettate, e che soddisfi le esigenze di chi lo ha commissionato

Questo è un modello molto criticato, ma allo stesso tempo è molto usato. Il progetto reale si conforma raramente allo schema sequenziale del modello. Ogni modifica è causa di confusione a mano a mano che il progetto avanza tanto che i costi aumentano quando le modifiche vengono fatte più in la nel tempo. Altro motivo di disapprovazione è che per il cliente è difficile enunciare esplicitamente tutti i requisiti. Questo tipo di modello non è in grado di governare l’incertezza. Il modello a cascata solo al termine dell’arco temporale porta a una versione funzionante dei programmi, un problema grave è che conduce a stati bloccanti cioè tutte le attività a valle di una determinata attività rimangono in stallo fino a quando l’attività a monte non viene completata.

Modello incrementale

Si utilizza questo modello quando i requisiti iniziali sono piuttosto ben definiti, ma l’ampiezza stessa dell’attività di sviluppo preclude un processo lineare. Una soluzione attuabile in questa situazione è quella di fornire all’utente un insieme limitato di funzionalità per poi affinare ed espanderle nelle release successive. Come prima cosa si sviluppano i componenti più critici e più urgenti, poi nelle release successive avverranno le integrazioni. Nella versione 1 si avrà il prodotto base che soddisfa i requisiti fondamentali, nelle versioni successive fino alla finale verranno apportate delle modifiche volte a soddisfare le esigenze del cliente oppure implementeranno nuove funzioni. E’ utile usare questo modello in situazioni quali:

• Data di consegna stretta. Si decide di fornire uno o più incrementi entro la data critica e gli altri a succedere.
• Disponibilità di persone insufficiente a garantire l’implementazione completa nei termini di tempo stabiliti per il progetto.
• Se nei primi stadi si dispone di un piccolo team, quando il progetto diventa più grosso il team si può allargare.

Modello a prototipo

Si sviluppa un prototipo come strumento per comprendere i requisiti. Si adotta questa tecnica quando:

• Il cliente definisce gli obiettivi in maniera generale e non dettagliata
• Il cliente non riesce a fornire indicazioni precise riguardo ai dettagli
• Lo sviluppatore può non essere sicuro dell’efficienza di un algoritmo

Bisogna ricordare che il modello ottenuto è un prototipo. Si deve resistere a trasformare un prototipo in un programma perchè il risultato sarà scadente.

Modello iterativo

Si utilizza questo modello quando si sviluppa un prototipo e lo si fa evolvere nel tempo. Dopo la fase di specificazione e progettazione si hanno due fasi in loop-back quella nella quale si sviluppa il prototipo e quella successiva di test. Se il test ha dato esisto negativo si ritorna a lavorare sull’implementazione del prototipo e cos`ı via iterativamente fino a quando la fase di test darà esito positivo.

Modello a spirale

Abbina la natura iterativa della prototipazione e gli aspetti controllati e sistematici del modello a cascata consentendo un rapido sviluppo di versioni via via più complete del software. Non è un modello ma uno strumento per descrivere i modelli. Adottano un approccio ciclico per far crescere in modo incrementale il grado di definizione e implementazione di un sistema riducendo i rischi. Il modello a spirale produce dei passi e risultati intermedi che garantiscono agli stakeholder che le soluzioni del sistema sono fattibili e soddisfacenti. E’ composto da 4 parti principali che iterano ciclicamente.

1. Definizione degli obiettivi, requisiti, identificazione, alternative (‘’make’’ su misura ma più caro, ‘’buy’’ meno costoso ma devo adattare il software), vincoli, piano di gestione
2. Analisi dei rischi, studio di conseguenze e alternative, prototipi e simulazioni
3. Sviluppo e validazione, realizzazione del prodotto e verifica
4. Pianificazione, revisione risultati, decidere il proseguio, pianificazione del ciclo

Questo modello introduce la gestione del rischio e tratta anche aspetti gestionali (pianificazione e definizione obiettivi). E’ una strategia realistica per lo sviluppo di sistemi e di software di grande dimensioni. Poichè il software evolve di pari passo con l’avanzare del processo, lo sviluppatore e il cliente hanno modo di valutare meglio rischi e di reagire ad ogni stadio dell’evoluzione. Si serve della prototipazione, applicata ad ogni stadio dell’evoluzione, per ridurre i rischi.

Modello Unified Process (UP - RUP)

E’ un processo iterativo e incrementale guidato dai casi d’uso e centrato attorno all’architettura. Utilizza UML. Il processo è costituito da più cicli di sviluppo. Ogni ciclo produce una versione rilasciabile del prodotto Ogni ciclo è costituito da fasi (parzialmente sovrapposte):

• Fase di avviamento,valutazione iniziale del progetto. Stima dello sforzo inteso come costo e tempo (studio di fattibilità)
• Fase di elaborazione,sviluppo iterativo della struttura portante del prodotto attraverso i casi d’uso più importanti (architettura, baseline)
• Fase di realizzazione,accrescimento iterativo (guidato da casi d’uso) e perfettivo delle funzionalità n necessarie per il rilascio
• Fase di transizione, messa in servizio

Verifiche possibili al termine di ogni fase e ogni ciclo.

Modello per integrazione

Dopo la definzione della specifica si analizzano i modelli già esistenti. Possibili soluzioni:

• Crearne nuovi
• Ex novo tramite modifiche
• Acquisto sul mercato
• C.O.T.S (components of the shell)

Modelli agili (agile programming)

Si utilizza il modello agile quando si hanno tempi stretti e requisiti incerti. Si trova in contrapposizione con gli alti modelli più rigidi e meno flessibili. Il ‘’Manifesto for agile software development’’ descrive la filosofia del modello agile sostanzialmente in questi termini:

• Individui e loro interazioni rispetto ai processi e agli strumenti
• Importanza delle persone (meglio avere gente valida che una metodologia formale)
• Adattamento vs pianificazione (pronta risposta ai cambiamenti rispetto all’esecuzione di un piano)
• Disponibililtà di software rispetto a un’ampia documentazione
• Collaborazione con il cliente rispetto alla negoziazione dei contratti

I metodi agili sono stati sviluppati nel tentativo di superare i punti deboli presunti ed effettivi nell’ingegneria del software convenzionale. Lo sviluppo agile può fornire importanti benefici ma non può essere applicato a tutti i progetti, prodotti, gruppi di persone e situazioni. In molte situazioni non è più possibile definire completamente i requisiti prima dell’inizio del progetto. Gli ingegneri software devono essere sufficientemente agili da rispondere ad un ambiente in costante cambiamento. Un modello agile nasce quindi per rispondere in modo appropriato ai cambiamenti. Esistono due filoni principali di modelli agili eXtreme Programming e Agile Modeling Ecco i punti principali di ‘’XP Practices’’:

• Collective ownership, tutti i team possiedono tutte le conoscenze
• Customer test, rilasciare il prodotto velocemente, affinchè il cliente lo testi
• Simple design, progetto semplice da realizzzare
• Test driven development, tecnica usata da Microsoft. Programmatore+tester
• Refactoring, ristrutturazione e modifica del codice
• Continuous integration, software che funziona e che cresce progressivamente

(su questa parte, vedere anche la sezione Informatica 3 alla pagina eXtreme Programming)

Sistemi e software

La distinzione Software Engineering e System Engineering è dovuta al fatto che il software è solo un tipo di componente di un sistema, il processo di sviluppo di un sistema è più complesso ed articolato del processo di sviluppo di un prodotto software. Il software prodotto non è altro che un componente che il sistema dovrà gestire. Infatti sarà affiancato da altri componenti come l’hardware di elaborazione, la rete di comunicazione, procedure organizzative, banche dati, stampanti, ect.

Sviluppo, controllo e gestione

La creazione di un software che soddisfa le esigenze è composto da tre blocchi principali:

• Sviluppo: produzione dell’oggetto vero e proprio (Specificare, Progettare e Codificare).
• Controllo: definire ed eseguire un piano di test e controlli per acquisire fiducia nel prodotto. Può essere eseguito anche alla fine oppure durante, ogni fase (consigliato). Scovare errori o bug alla fine del progetto comporta l’investimento di più soldi per la correzione rispetto allo scoprirli al termine di ogni fase.
• Gestione: si applicano trasversalmente sia allo sviluppo che al controllo (es. sviluppo e controllo rilasciano documenti di progettazione, moduli di codice sorgente, casi di test).

Scelta dei processi adeguati

Non esistono processi che sono assolutamente migliori di altri, è necessario dunque scegliere quello più adeguato in base alle specifiche esigenze del caso tenendo conti delle dimensioni del progetto e delle variabili tempo e costo.

Processo di sviluppo di sistemi software

1. Istanziazione del processo
2. Analisi dei requisiti del sistema
3. Progetto architetturale del sistema
4. Analisi dei requisiti del software
5. Progettoarchitetturale del software
6. Progetto di dettaglio del software
7. Codifica e prova dei componenti sw
8. Integrazione dei componenti sw
9. Collaudo del software
10. Integrazione di sistema
11. Collaudo del sistema

Esempio: Azienda di 50 persone. Sviluppo applicazioni custom e servizi (software di complessità standard, elevata, sistemi ERP)

• Complessità standard

1. Specifca e progettazione
2. Codifica
3. Realizzazione documentazione
4. Rilascio

• Complessità elevata

1. Analisi dei requisiti
2. Specifca e progettazione architetturale
3. Progettazione esecutiva
4. Codifica
5. Realizzazione documentazione
6. Rilascio

• Sistemi ERP, processo ‘’lineare’’ in cui sono inseriti, dopo la progettazione

architetturale, due sottoprocessi diversi.Uno dei sottoprocessi adatta in modo iterativo il prodotto ERP alle specifiche esigenze, mentre l’altro progetta in dettaglio e realizza eventuali componenti software specifici aggiuntivi.

• Analisi dei requisiti e progettazione architetturale

1. Implementazione ERP, solo per il componente ERP.
2. Progettazione esecutiva, per le componenti custom
3. Codifica
4. Realizzazione documentazione
5. Rilascio

Valutazione e miglioramento dei processi

L’esistenza di un processo di sviluppo software non garantisce che il software venga consegnato nei tempi previsti, che risponda ai bisogni del cliente o che esibisca le caratteristiche tecniche che ne garantiranno qualità a lungo termine. I modelli devono essere affiancati da una solida pratica di ingegneria del software. Inoltre il processo deve essere valutato per garantire che risponda a un insieme di criteri di base che si sono dimostrati essenziali per il successo dell’ingegneria del software. Esistono due principali approcci alla valutazione del processo di sviluppo del software:

• Spice, Software process improved and capability determination (ISO/IEC 15504)
• 'CMM, Capability maturity model (modello per la valutazione dei fornitori) 2.6.1 SPICE - Software process improved and capability determination

Per quanto riguardo quest’ultimo possiamo dire che si tratta di uno standard che definisce un insieme di requisiti per la valutazione del processo di sviluppo software. Lo scopo dello standard è quello di assistere le organizzazioni a sviluppare una valutazione obiettiva dell’efficienza di un determinato processo di sviluppo software. Dall’osservazione di attributi di processo si determinano i livelli di capacità indicatori della qualità raggiunta nella gestione del processo stesso.

Esistono 5 livelli di maturità:

1. - Incompleto (Incomplete)

Il processo non è implementato o comunque non raggiunge i risultati attesi

1. - Eseguito (Performed), Il processo implementato raggiunge lo scopo ed i risultati attesi
2. - Gestito (Managed), Il processo Eseguito produce risultati che soddisfano i requisiti espressi, nei tempi definiti e con le risorse allocate.
3. - Stabilito (Established), Il processo Gestito è eseguito sulla base di un processo standardizzato e raggiunge risultati predefiniti.
4. - Prevedibile (Predictable), Il processo Stabilito è eseguito costantemente, entro limiti stabiliti quantitativamente e raggiungendo costantemente i risultati predefiniti.
5. - Ottimizzante (Optimizing), Il processo Prevedibile cambia dinamicamente per rispondere efficacemente ai bisogni di business attuali e futuri.

Miglioramento dei processi

Il miglioramento dei processi è una soluzione che va pianificata nel corso del tempo. Migliorare un processo significa mettere in atto un processo di controllo che misuri, analizzi e retroagisca sui processi per migliorarli. Per migliorare un processo è necessario estrarre delle variabili o misure da monitorare tra cui:

• Fatturato
• Margine lordo
• Distribuzione dei clienti
• Lamentele dei clienti
• Tempi di consegna progetti / tempi previsti
• Costi progetti / costi previsti
• Difettosità del prodotto

La norma che gestisce il miglioramento dei processi è la ISO 9001:2000. Essa suddivide i processi in 4 categorie:

1. Responsabilità della direzione
2. Gestione delle risorse
3. Realizzazione del prodotto
4. Misurazione, analisi e miglioramento