 |
Il forum sulla Qualità di QualitiAmo
Torna all'homepage di QualitiAmo
|
| Precedente :: Successivo |
| Autore |
Messaggio |
QualitiAmo - Stefania
Moderatore
Registrato: 16/09/07 18:37
Messaggi: 26589
|
|
| Top |
|
 |
|
|
|
filippo1974
Forumista di Qualità
Registrato: 19/10/10 12:39
Messaggi: 338
Residenza: North east of Italy
|
 Inviato: Gio Nov 04, 2010 3:43 pm Oggetto: |
 |
|
Visto che su questo argomento posso dire di "giocare un po' in casa", da una rapida lettura dell'articolo potrei dire di essere parzialmente d'accordo, nel senso che se da un lato è vero che la mappa del valore potrebbe essere scarsamente applicabile all'ambito software, sono un po' più dubbioso sul fatto che il motivo sia quello che emerge nell'articolo.
Per quanto il software sia un prodotto intangibile, è pur vero che esistono molti approcci possibili alla sua realizzazione, e quindi volendo ci si può ricondurre ad una tipologia di processo (penso ad esempio al modello Waterfall) che preveda un flusso monodirezionale, quindi più facilmente analizzabile con lo strumento della mappa del valore. Di conseguenza non sono convinto che il metodo sia necessariamente un ostacolo (nell'articolo si fa menzione dell'Agile Development ed in particolare dello Scrum che è forse l'esempio più inappropriato, dato che è già di per sé un metodo per ridurre il superfluo).
Piuttosto, secondo me la problematica è molto più semplice, tale per cui l'utilizzo della mappa del valore diviene in qualche modo ridondante: in un qualsivoglia processo di sviluppo software, l'unico passo che provoca un allungamento del time-to-market senza portare un valore aggiunto come contropartita è il bug fixing. Quest'ultima attività è un costo puro, in termini propriamente di soldi (ore uomo) che di contributo al lead time. La mancata contropartita in termini di valore è dovuta semplicemente al fatto che la correzione di anomalie è un'attività "riparatoria" per portare un prodotto ad un grado di conformità ai requisiti che in realtà avrebbe dovuto avere fin da subito.
Quindi nell'ambito dello sviluppo software uno degli approcci più importanti per la riduzione del lead time è la Defect Prevention, che di per sé non dice niente di certo, ma è semplicemente un "cappello" sotto cui ricade tutta una serie di attività che hanno come scopo il prevenire l'iniezione di bachi nel prodotto, piuttosto che rilevarli a valle dopo che sono già stati generati.
Ciao
Filippo
_________________
Filippo
Quality System Manager
"E' facile trovare le colpe. E' cercare di fare meglio che può essere difficile." - Plutarco |
|
| Top |
|
|
2p71828
Qualità è precisione
Registrato: 31/10/08 17:43
Messaggi: 2750
|
| Inviato: Gio Nov 04, 2010 6:54 pm Oggetto: |
|
|
caro filippo,
ti scrivo da principiante/amatore della programmazione e contemporaneamente affogato nella meccanica.
secondo me, ma tu mi puoi certamente confutare dalla tua esperienza, nel software si tende a lasciare più libero lo spirito che nella produzione meccanica, come se il software fosse rimasto ai figli dei fiori come mentalità.
Per l'analisi del valore di un software io vederei:
il tipo di linguaggio utilizzato e le subroutine/moduli standard importate (vs scritte ex novo), che si riflettono poi nel grado di ottimizzazione del software nel senso delle richieste hardware e dei tempi di esecuzione del cliente finale, ma che hanno di contro un impatto sul tempo di sviluppo del software stesso.
il grado e la qualità dei controlli sull'input
il grado di manutenibilità del software e dei pacchetti.
Le tipologie di output supportate
_________________
=fixed(exp(1);5)
sha-1=661bf49e78e9d958032859e811fa1ca27699207a |
|
| Top |
|
|
filippo1974
Forumista di Qualità
Registrato: 19/10/10 12:39
Messaggi: 338
Residenza: North east of Italy
|
| Inviato: Gio Nov 04, 2010 11:07 pm Oggetto: |
|
|
| 2p71828 ha scritto: | | secondo me, ma tu mi puoi certamente confutare dalla tua esperienza, nel software si tende a lasciare più libero lo spirito che nella produzione meccanica, come se il software fosse rimasto ai figli dei fiori come mentalità. |
Questo è assolutamente vero. Proprio perché il software è di per sé qualcosa di intangibile, la stessa attività di produzione del software è nell'accezione comune (e nelle pratiche di molti programmatori) più assimilata ad una sorta di arte che non ad una disciplina a cui sia applicabile un rigore scientifico.
Un approccio in stile "spirito libero" è in realtà applicabile con successo solo a gruppi di sviluppo molto circoscritti e nei quali è già presente un affiatamento interpersonale. La filosofia Agile Development, e l'approccio Scrum in particolare (che viene citato nell'articolo a cui questa discussione fa riferimento) assume la ristrettezza numerica e l'affiatamento del team come presupposti di base, condizioni "sine qua non" (anche se esistono trattati che dimostrerebbero l'applicabilità delle pratiche Agile a gruppi di scala più ampia).
L'esperienza dimostra tuttavia che al crescere della complessità stimata di un progetto (si parla di lavori che cubano diversi anni-uomo) è impossibile mantenere un team ristretto per poter continuare ad applicare la filosofia Agile e pretendere che questo team si faccia carico dell'intero progetto, pena tempi biblici di realizzazione, con la conseguenza che le scelte architetturali e tecnologiche fatte all'inizio del progetto diventano già obsolete a progetto concluso (in informatica il tempo vola...)
Di conseguenza al crescere della complessità dei progetti, la numerosità del team deve necessariamente crescere, e quindi diviene un passo obbligato l'introduzione di una metodologia standardizzata, soprattutto se ci si trova nella necessità di condividere il lavoro tra team geograficamente sparsi e magari di culture diverse (filiali estere). In queste condizioni, l'approccio "artistico" allo sviluppo diviene impossibile da gestire e deve lasciare spazio a metodologie più rigorose, fermo restando che nella gestione locale di sotto-gruppi contenuti si può continuare ad applicare una pratica di tipo Agile.
| Citazione: | Per l'analisi del valore di un software io vederei:
il tipo di linguaggio utilizzato e le subroutine/moduli standard importate (vs scritte ex novo), che si riflettono poi nel grado di ottimizzazione del software nel senso delle richieste hardware e dei tempi di esecuzione del cliente finale, ma che hanno di contro un impatto sul tempo di sviluppo del software stesso.
il grado e la qualità dei controlli sull'input |
Tutto corretto, ma se ci pensi, in un approccio metodologico allo sviluppo software, gran parte di queste tematiche vengono affrontate (dovrebbero venire affrontate) nelle primissime fasi dello sviluppo, quelle della pianificazione, quando i requisiti funzionali di un progetto vengono tradotti nel cosiddetto "high-level design", nel quale si fissano le scelte architetturali di base (tecnologie da utilizzare, ambienti e linguaggi di sviluppo, ecc.). Molte delle scelte che possono influenzare il lead-time sono quindi pianificate a monte in un unico step, dove le implicazioni sui tempi di sviluppo di determinate scelte sono (dovrebbero) essere prese in considerazione.
In particolare per quanto riguarda le pratiche di ottimizzazione del software in termini di risorse hardware richieste, si tratta di una disciplina terribilmente complessa, che nella maggior parte degli ambiti applicativi dà molti più costi dei vantaggi che offre. Al giorno d'oggi si preferisce progettare software facilmente scalabili, piuttosto che software pesantemente ottimizzati. A quel punto, se le prestazioni sono insufficienti, si acquista un server in più e lo si mette in Load Balancing con gli altri e il gioco è fatto.
L'ottimizzazione resta comunque una necessità in ambiti dove le risorse hardware sono pesantemente limitate (tipicamente nell'ambito dei terminali mobili, ad esempio gli smartphone: sicuramente non puoi migliorare le prestazioni comprando un secondo smartphone  ).
L'ottimizzazione del software, oltre a costare molto, ha lo sgradevole effetto collaterale di limitare la portabilità, e rappresenta quindi un ostacolo alla diffusione del prodotto (= minori introiti) molto maggiore del vantaggio in termini di performance in esecuzione.
| Citazione: | | il grado di manutenibilità del software e dei pacchetti. |
La manutenibilità, intesa come facilità di apportare modifiche ad un prodotto software, più che delle tecnologie impiegate è essenzialmente funzione del rispetto più o meno rigoroso di "recommended practices" sullo sviluppo del codice. A questo proposito, l'approccio "artistico" di cui si parlava sopra è uno dei nemici più pericolosi della manutenibilità, perché dipende pesantemente dall'estro artistico del singolo sviluppatore, con il pericoloso risultato di dipendere dalla presenza di questo o quel personaggio, in assenza del quale nessuno riesce a mettere le mani sulla "sua creatura". (Single Point of Failure). Convenzioni, regole di organizzazione del sorgente, sono tutte indicazioni che entrano a far parte delle "Linee guida del codice" che in genere sono formalizzate in un documento (istruzione operativa) inserito nel Sistema Gestione Qualità dell'organizzazione. Le linee guida del codice, oltre ad avere un contributo ai fini della manutenibilità, hanno anche un ruolo nella Defect Prevenction: scrivere codice in un certo modo dovrebbe (in teoria) contribuire a diminuire la possibilità di errori.
Ciao
Filippo
_________________
Filippo
Quality System Manager
"E' facile trovare le colpe. E' cercare di fare meglio che può essere difficile." - Plutarco |
|
| Top |
|
|
|
|
Non puoi inserire nuovi argomenti
Non puoi rispondere a nessun argomento
Non puoi modificare i tuoi messaggi
Non puoi cancellare i tuoi messaggi
Non puoi votare nei sondaggi
|
|
FAQ
Cerca
Lista utenti
Gruppi
Registrati
Profilo
Messaggi privati
Log in
