17-02-2012, 13:17
Come per qualsiasi altro prodotto, il software viene sviluppato tramite un proprio processo produttivo improntato su di una struttura che può esercitare una notevole influenza sulla qualità del prodotto finale, oltre che, chiaramente, sul costo dello svolgimento che porta alla realizzazione del prodotto medesimo. Questo processo produttivo è indicato come ciclo di vita del software e verrà analizzato negli articoli successivi.
Il ciclo produttivo del software, a differenza di quanto può determinarsi nella produzione di altri beni, rappresenta un processo del quale non è facile, talvolta addirittura impossibile, scorgere il compimento. In pratica non è affatto agevole distinguere dove abbia termine il processo di sviluppo di una applicazione e dove inizi la successiva evoluzione. Per quanto riguarda il software possiamo affermare che la sua evoluzione è in diretta proporzione alla sua flessibilità, infatti in nessun altro prodotto è presente questa peculiarità legata alla flessibilità come può esserlo per il software. E’ possibile apportare dei mutamenti anche radicali alla funzionalità offerta dal software operando semplicemente dei cambiamenti minimi alla struttura progettuale, agendo solamente a livello del flusso delle istruzioni. Il cambiamento, perlomeno in apparenza, sembra piuttosto comodo, è sufficiente un editor per apportare qualsivoglia modifica e, si badi bene, non sussiste proporzionalità tra estensione della modifica, in termini di linee di codice aggiunte, modificate o eliminate, ed estensione delle funzionalità.
La flessibilità del software non deve comunque indurre a facili entusiasmi, modificare il flusso operativo nel suo percorso è abbastanza semplice, ma non altrettanto ottenere che gli adeguamenti apportati sortiscano l’effetto desiderato. Sovente, molto più di quanto si possa pensare, capita che una modifica effettuata per correggere un errore ne generi di nuovi, anche peggiori, non solo, è anche possibile che non rimuova l’errore e che la situazione degeneri. Va comunque detto che la flessibilità è indubbiamente una peculiarità che differenzia profondamente il software da altri prodotti. Ad esempio su di un’arma sarà possibile innestare un silenziatore o altri accessori che rimarranno comunque e sempre tali, mentre un applicativo che opera sulla giacenza di articoli di magazzino può essere trasformato in un sistema sofisticato in grado di gestire fatturazione e contabilità.
Come abbiamo accennato e spiegheremo nel corso degli articoli successivi, la capacità intrinseca del software ad essere flessibile, quindi ad evolversi con una certa facilità, determina comunque un prezzo che va pagato: seppur condizione di base, la flessibilità non è sufficiente affinché il software abbia ad evolvere in un percorso stabile.
Altra caratteristica che rende il software totalmente differente il suo processo produttivo da quello di altri prodotti, come già accennato, è il processo manifatturiero di assemblaggio del prodotto, poiché trattasi di un processo di ingegneria che consiste essenzialmente in attività di progettazione e non di produzione intesa tradizionalmente.
Formulate queste doverose premesse su alcuni concetti che determinano le caratteristiche del software è opportuno porsi una domanda estremamente importante: quali possono essere i parametri tramite i quali valutare, oggettivamente, un processo produttivo o un prodotto software? In altre parole, quali potrebbero essere le specifiche in grado di determinarne la qualità.
Ci preme osservare, a questo punto, che il criterio di qualità al quale bisogna ambire è indubbiamente quello che riguarda i prodotti, questo perché la qualità dei medesimi deve essere logica conseguenza di un processo produttivo che preveda l’utilizzo di risorse limitate dal punto di vista finanziario, personale qualificato e, naturalmente, tempo impiegato alla realizzazione del progetto. Occorre pertanto ricercare una soluzione che sia di compromesso e possa sviluppare il prodotto ottimale non valutato in termini astratti ed assoluti, ma in relazione e connessione alle risorse disponibili, oltre che al rispetto dei vincoli prestabiliti in sede di committenza.
In assenza di vincoli contrattuali e procedurali, disponendo inoltre di risorse infinite, l’unico obbiettivo si focalizzerebbe esclusivamente nel massimizzare la qualità del prodotto, quindi l’oggetto da inserire nel mercato con la chiara intenzione di massimizzare altresì la soddisfazione dell’utente che dovrà utilizzare il prodotto.
Il ciclo produttivo del software, a differenza di quanto può determinarsi nella produzione di altri beni, rappresenta un processo del quale non è facile, talvolta addirittura impossibile, scorgere il compimento. In pratica non è affatto agevole distinguere dove abbia termine il processo di sviluppo di una applicazione e dove inizi la successiva evoluzione. Per quanto riguarda il software possiamo affermare che la sua evoluzione è in diretta proporzione alla sua flessibilità, infatti in nessun altro prodotto è presente questa peculiarità legata alla flessibilità come può esserlo per il software. E’ possibile apportare dei mutamenti anche radicali alla funzionalità offerta dal software operando semplicemente dei cambiamenti minimi alla struttura progettuale, agendo solamente a livello del flusso delle istruzioni. Il cambiamento, perlomeno in apparenza, sembra piuttosto comodo, è sufficiente un editor per apportare qualsivoglia modifica e, si badi bene, non sussiste proporzionalità tra estensione della modifica, in termini di linee di codice aggiunte, modificate o eliminate, ed estensione delle funzionalità.
La flessibilità del software non deve comunque indurre a facili entusiasmi, modificare il flusso operativo nel suo percorso è abbastanza semplice, ma non altrettanto ottenere che gli adeguamenti apportati sortiscano l’effetto desiderato. Sovente, molto più di quanto si possa pensare, capita che una modifica effettuata per correggere un errore ne generi di nuovi, anche peggiori, non solo, è anche possibile che non rimuova l’errore e che la situazione degeneri. Va comunque detto che la flessibilità è indubbiamente una peculiarità che differenzia profondamente il software da altri prodotti. Ad esempio su di un’arma sarà possibile innestare un silenziatore o altri accessori che rimarranno comunque e sempre tali, mentre un applicativo che opera sulla giacenza di articoli di magazzino può essere trasformato in un sistema sofisticato in grado di gestire fatturazione e contabilità.
Come abbiamo accennato e spiegheremo nel corso degli articoli successivi, la capacità intrinseca del software ad essere flessibile, quindi ad evolversi con una certa facilità, determina comunque un prezzo che va pagato: seppur condizione di base, la flessibilità non è sufficiente affinché il software abbia ad evolvere in un percorso stabile.
Altra caratteristica che rende il software totalmente differente il suo processo produttivo da quello di altri prodotti, come già accennato, è il processo manifatturiero di assemblaggio del prodotto, poiché trattasi di un processo di ingegneria che consiste essenzialmente in attività di progettazione e non di produzione intesa tradizionalmente.
Formulate queste doverose premesse su alcuni concetti che determinano le caratteristiche del software è opportuno porsi una domanda estremamente importante: quali possono essere i parametri tramite i quali valutare, oggettivamente, un processo produttivo o un prodotto software? In altre parole, quali potrebbero essere le specifiche in grado di determinarne la qualità.
Ci preme osservare, a questo punto, che il criterio di qualità al quale bisogna ambire è indubbiamente quello che riguarda i prodotti, questo perché la qualità dei medesimi deve essere logica conseguenza di un processo produttivo che preveda l’utilizzo di risorse limitate dal punto di vista finanziario, personale qualificato e, naturalmente, tempo impiegato alla realizzazione del progetto. Occorre pertanto ricercare una soluzione che sia di compromesso e possa sviluppare il prodotto ottimale non valutato in termini astratti ed assoluti, ma in relazione e connessione alle risorse disponibili, oltre che al rispetto dei vincoli prestabiliti in sede di committenza.
In assenza di vincoli contrattuali e procedurali, disponendo inoltre di risorse infinite, l’unico obbiettivo si focalizzerebbe esclusivamente nel massimizzare la qualità del prodotto, quindi l’oggetto da inserire nel mercato con la chiara intenzione di massimizzare altresì la soddisfazione dell’utente che dovrà utilizzare il prodotto.