Disegno versus Produzione 2/3



       _P_ er realizzare software le attività di disegno e produzione si combinano insieme. Trovo che sia molto facile confondere quello che è disegno da quello che è produzione e molte sviste sul disegno credo che nascono proprio da questo.




   Riporto le distinzioni che ho trovato in questo articolo  POSITIVE VS NEGATIVE ITERATION IN DESIGN, G Ballard che propone dei criteri per distinguere vantaggi e sprechi nel disegno e nella produzione.




        Il disegno agisce nel mondo del pensiero e della immaginazione per "creare una ricetta"  (strutturare un sw in namespace, in classi, in livelli, etc.),  la produzione riguarda le attività materiali per "realizzare la ricetta" (dalle operazioni di stesura del codice sino alla preparazione del pacchetto di installazione)


        il disegno viene giudicato per quanto è adatto a realizzare un sw che soddisfa le necessità del cliente e degli utenti mentre la produzione è giudicata sulla aderenza alle specifiche (quelle che derivano dal disegno)


        nel disegno la variabilità e varietà dei risultati è un valore perché quando c'è una sola scelta possibile non c'è bisogno del disegno che invece è utile quando c'è una varietà di scelte possibili, nella produzione la variabilità dei risultati è come un difetto


        nel disegno (ripetere) una iterazione da valore perché esplorare (ad es. fare uno spike cioè  un prototipo parziale e provvisorio)  fa capire meglio il problema e suggerisce alternative, nella produzione (ripetere) una iterazione significa "rifare" un lavoro ed è uno spreco.






Tags :   |  |  |  |

Print | posted @ domenica 14 settembre 2008 20.21

Comments on this entry:

Gravatar # re: Disegno versus Produzione 2/3
by Marco Abis at 14/09/2008 22.04

Per me "produzione" in ambito software e' quella che fa il compilatore-linker che seguendo una specifica del disegno (il codice!) devono essere in grando di produrre ripetutamente lo stesso risultato :-)
  
Gravatar # re: Disegno versus Produzione 2/3
by Luca Minudel at 15/09/2008 0.24

ho trovato più efficace la definizione classica del'ing. del sw che distingue il concetto di disegno (stesura del progetto = "creare la ricetta") da quello di produzione (implementazione secondo le specifiche del disegno = "fare/cucinare la ricetta") per traferire sul sw quello che Ballard ha imparato/scoperto sul disegno - anche quando i metodi agili uniscono nella pratica disegno e codifica in modo inestricabile i 2 concetti restano distinti

ecco 2 esempi
- modifico il sw e ri-eseguo i test di accettazione a mano; x Ballard è rework cioè una (re)iterazione negativa di produzione
- invece esploro/evolvo il disegno del sw sino a riuscire a automatizzare i test di accettazione; x Ballard sono (re)iterazioni positive di disegno
- - -
- cambia un valore scolpito nel codice e devo modificare il codice per aggiornarlo; x Ballard è rework cioè una (re)iterazione negativa di produzione
- invece esploro/evolvo il disegno della applicazione sino a rendere il valore configurabile; x Ballard sono (re)iterazioni positive di disegno

che ne pensi?
  

Your comment:

Title:
Name:
Email:
Website:
 
Italic Underline Blockquote Hyperlink
 
 
Please add 2 and 8 and type the answer here: