27-08-2012, 08:08
(Questo messaggio è stato modificato l'ultima volta il: 27-08-2012, 08:26 {2} da Mariano.)
Nel corso dei precedenti articoli abbiamo potuto osservare come le applicazioni informatiche, all’esordio, godevano di ben poca attenzione dal punto di vista dell’organizzazione e gestione del processo produttivo. Lo sviluppatore del software era l’utilizzatore del proprio programma, quindi non sviluppava per un cliente o per il mercato. La tipologia di processo legata allo sviluppo conveniva su basi definite come codifica e modifica (code – and – fix), cioè un procedimento iterativo entro cui il software si adatta progressivamente a ciò che l’utente – progettista intende realizzare.
L’esponenziale incremento della complessità e criticità delle applicazioni in concomitanza dello sviluppo di un mercato del software, ha palesato l’inefficienza ed inadattabilità del metodo descritto. Nasce dunque una riflessione su come improntare e gestire il processo di produzione del software, tentando, sostanzialmente, di capire quale fosse il ciclo di vita di un prodotto. E’ quanto faremo nel corso di questo ed altri successivi articoli, attraverso dei modelli di tipo flessibile ed evolutivo e modelli che basano la propria impostazione su paradigmi di tipo maggiormente formalizzato.
Il ciclo di vita a cascata
Questo modello prevede che il ciclo di vita legato ad un’applicazione passi attraverso una sequenza di fasi poste tra esse in cascata entro la quale ciascuna riceve ingressi dalla precedente e produce delle uscite che diverranno al loro volte degli ingressi per le fasi successive. Osserviamo un esempio possibile di questo modello:
Altri modelli che si attengono alla medesima filosofia procedurale sono di fatto possibili, quindi adottati da svariate organizzazioni come modelli di produzione standard. Il paradigma sopra descritto deve essere considerato appunto in cascata, quindi in una progressione di fasi tale per cui da una si procede alla successiva, senza ritorni verso quella precedente.
Le uscite intermedie che una fase produce come ingresso per quella successiva rappresentano i cosiddetti semilavorati del processo, in pratica la documentazione cartacea scritta in linguaggio naturale, come ad esempio l’uscita dallo studio di fattibilità che rappresenta un documento contenente i risultati dello studio medesimo, mentre l’uscita dalla fase di analisi e specifica dei requisiti è un documento che contiene la descrizione dettagliata dei requisiti di un’applicazione. I soli semilavorati formalizzati rappresentano quanto prodotto dalle attività di programmazione (il codice di ogni singolo modulo scritto in linguaggio di programmazione) ed integrazione (il sistema complessivo costituito da più modelli di programma ed eventualmente correlati a dei componenti di libreria).
Il modello che stiamo analizzando, oltre a definire le fasi che andranno a scomporre il processo e quindi eventuali attività interne alle fasi, si determina anche nella definizione precisa di contenuti e struttura relativi ai semilavorati da produrre e, durante la delicata fase di pianificazione, le date entro le quali i medesimi dovranno essere prodotti.
La definizione dei contenuti e della struttura inerente i semilavorati definisce i requisiti da soddisfare, ciò diviene pertanto fondamentale alfine di garantire una successiva attività di controllo per quanto riguarda la qualità dei semilavorati. Suddetta attività di controllo è altresì preponderante alfine di certificare l’avanzamento del processo in base al piano stabilito. Facciamo un esempio: qualora sia previsto che l’attività di progettazione venga completata entro una specifica data, è necessario verificare che i semilavorati correlati, quindi la documentazione di progetto, siano rilasciati e superino il controllo di qualità entro la data prevista.
E’ importante notare che, per funzionare correttamente, il modello debba essere davvero a cascata, cioè che non vi siano, in alcun modo, dei ritorni ad una fase precedentemente già svolta. Chi adotta il modello del processo produttivo sopra descritto tende ad implementarlo con delle linee guida sul modo di condurre le varie fasi, determinando il compimento ordinato della procedura, evitando così che vi siano dei ricicli. Questi vengono visti come fattori di disturbo poiché rendono il processo difficilmente governabile: la verifica di completamento di una determinata fase legata ad una data specifica perderebbe inesorabilmente di significato al cospetto di un procedimento a ritroso che comporterebbe il disfare e ripetere di quanto considerato concluso.
Uno degli aspetti che maggiormente influenza la definizione di modello di processo è indubbiamente quello che riguarda la natura dei diversi ruoli di produttore e committente dell’applicativo. In linea di massima possiamo derivare i seguenti ruoli:
Nei casi sopra descritti la natura delle fasi e, più specificatamente la struttura del modello di ciclo vitale adottato possono differenziarsi notevolmente. Ad esempio nel primo caso non è richiesta una specifica formalizzazione né particolari attività di pianificazione e controllo del processo. Nell’ultimo caso diviene invece fondamentale la fase inerente distribuzione ed installazione in modo che possa essere assicurata la collocazione sul mercato del prodotto con massima soddisfazione degli utenti.
L’esponenziale incremento della complessità e criticità delle applicazioni in concomitanza dello sviluppo di un mercato del software, ha palesato l’inefficienza ed inadattabilità del metodo descritto. Nasce dunque una riflessione su come improntare e gestire il processo di produzione del software, tentando, sostanzialmente, di capire quale fosse il ciclo di vita di un prodotto. E’ quanto faremo nel corso di questo ed altri successivi articoli, attraverso dei modelli di tipo flessibile ed evolutivo e modelli che basano la propria impostazione su paradigmi di tipo maggiormente formalizzato.
Il ciclo di vita a cascata
Questo modello prevede che il ciclo di vita legato ad un’applicazione passi attraverso una sequenza di fasi poste tra esse in cascata entro la quale ciascuna riceve ingressi dalla precedente e produce delle uscite che diverranno al loro volte degli ingressi per le fasi successive. Osserviamo un esempio possibile di questo modello:
- Studio di fattibilità
- Analisi e specifica dei requisiti
- Progettazione
- Programmazione e test di unità
- Integrazione e test di sistema
- Manutenzione
- Distribuzione e installazione
Altri modelli che si attengono alla medesima filosofia procedurale sono di fatto possibili, quindi adottati da svariate organizzazioni come modelli di produzione standard. Il paradigma sopra descritto deve essere considerato appunto in cascata, quindi in una progressione di fasi tale per cui da una si procede alla successiva, senza ritorni verso quella precedente.
Le uscite intermedie che una fase produce come ingresso per quella successiva rappresentano i cosiddetti semilavorati del processo, in pratica la documentazione cartacea scritta in linguaggio naturale, come ad esempio l’uscita dallo studio di fattibilità che rappresenta un documento contenente i risultati dello studio medesimo, mentre l’uscita dalla fase di analisi e specifica dei requisiti è un documento che contiene la descrizione dettagliata dei requisiti di un’applicazione. I soli semilavorati formalizzati rappresentano quanto prodotto dalle attività di programmazione (il codice di ogni singolo modulo scritto in linguaggio di programmazione) ed integrazione (il sistema complessivo costituito da più modelli di programma ed eventualmente correlati a dei componenti di libreria).
Il modello che stiamo analizzando, oltre a definire le fasi che andranno a scomporre il processo e quindi eventuali attività interne alle fasi, si determina anche nella definizione precisa di contenuti e struttura relativi ai semilavorati da produrre e, durante la delicata fase di pianificazione, le date entro le quali i medesimi dovranno essere prodotti.
La definizione dei contenuti e della struttura inerente i semilavorati definisce i requisiti da soddisfare, ciò diviene pertanto fondamentale alfine di garantire una successiva attività di controllo per quanto riguarda la qualità dei semilavorati. Suddetta attività di controllo è altresì preponderante alfine di certificare l’avanzamento del processo in base al piano stabilito. Facciamo un esempio: qualora sia previsto che l’attività di progettazione venga completata entro una specifica data, è necessario verificare che i semilavorati correlati, quindi la documentazione di progetto, siano rilasciati e superino il controllo di qualità entro la data prevista.
E’ importante notare che, per funzionare correttamente, il modello debba essere davvero a cascata, cioè che non vi siano, in alcun modo, dei ritorni ad una fase precedentemente già svolta. Chi adotta il modello del processo produttivo sopra descritto tende ad implementarlo con delle linee guida sul modo di condurre le varie fasi, determinando il compimento ordinato della procedura, evitando così che vi siano dei ricicli. Questi vengono visti come fattori di disturbo poiché rendono il processo difficilmente governabile: la verifica di completamento di una determinata fase legata ad una data specifica perderebbe inesorabilmente di significato al cospetto di un procedimento a ritroso che comporterebbe il disfare e ripetere di quanto considerato concluso.
Uno degli aspetti che maggiormente influenza la definizione di modello di processo è indubbiamente quello che riguarda la natura dei diversi ruoli di produttore e committente dell’applicativo. In linea di massima possiamo derivare i seguenti ruoli:
- Produttore e committente coincidono
- Produttore e committente sono entità distinte sotto il punto di vista organizzativo all’interno della medesima azienda.
- La software house sviluppa un software specifico (custom software) per un committente specifico
- La software house sviluppa un pacchetto da immettere sul mercato e non per uno specifico committente
Nei casi sopra descritti la natura delle fasi e, più specificatamente la struttura del modello di ciclo vitale adottato possono differenziarsi notevolmente. Ad esempio nel primo caso non è richiesta una specifica formalizzazione né particolari attività di pianificazione e controllo del processo. Nell’ultimo caso diviene invece fondamentale la fase inerente distribuzione ed installazione in modo che possa essere assicurata la collocazione sul mercato del prodotto con massima soddisfazione degli utenti.