Differenze tra le versioni di "Conway's law"

Da Caos per caso.
Jump to navigation Jump to search
none>TheHacker
m (una versione importata)
 
(3 versioni intermedie di 2 utenti non mostrate)
Riga 4: Riga 4:
  
 
La legge di Conway non era intesa come uno scherzo o un koan zen, ma come una valida osservazione sociologica. È una conseguenza del fatto che due moduli software A e B non possono interfacciarsi correttamente a meno che il progettista e realizzatore di A non comunichi con il progettista e realizzatore di B. Perciò la struttura dell' interfaccia di un sistema software presenterà necessariamente una congruenza con la struttura sociale dell'organizzazione che l'ha prodotta.
 
La legge di Conway non era intesa come uno scherzo o un koan zen, ma come una valida osservazione sociologica. È una conseguenza del fatto che due moduli software A e B non possono interfacciarsi correttamente a meno che il progettista e realizzatore di A non comunichi con il progettista e realizzatore di B. Perciò la struttura dell' interfaccia di un sistema software presenterà necessariamente una congruenza con la struttura sociale dell'organizzazione che l'ha prodotta.
 +
 +
{{quote|"If the parts of an organization (e.g., teams, departments, or subdivisions) do not closely reflect the essential parts of the product, or if the relationship between organizations do not reflect the relationships between product parts, then the project will be in trouble... Therefore: Make sure the organization is compatible with the product architecture."|James O. Coplien and Neil B. Harrison}}
  
 
La legge è dunque basata sull'osservazione che un software modulare viene progettato rispecchiando i rapporti sociali fra i progettisti dell'azienda che lo ha realizzato.
 
La legge è dunque basata sull'osservazione che un software modulare viene progettato rispecchiando i rapporti sociali fra i progettisti dell'azienda che lo ha realizzato.
  
 
{{quote|le organizzazioni che progettano sistemi ... sono indotte a generare design che sono copie dei legami nelle organizzazioni stesse.|M. Conway}}
 
{{quote|le organizzazioni che progettano sistemi ... sono indotte a generare design che sono copie dei legami nelle organizzazioni stesse.|M. Conway}}
 
{{quote|"If the parts of an organization (e.g., teams, departments, or subdivisions) do not closely reflect the essential parts of the product, or if the relationship between organizations do not reflect the relationships between product parts, then the project will be in trouble... Therefore: Make sure the organization is compatible with the product architecture."|James O. Coplien and Neil B. Harrison}}
 
  
 
In parole povere: il risultato di un progetto di un sistema dipende dal modo in cui l'organizzazione che lo produce  comunica.
 
In parole povere: il risultato di un progetto di un sistema dipende dal modo in cui l'organizzazione che lo produce  comunica.
Riga 17: Riga 17:
 
Prove a sostegno della legge di Conway sono state pubblicate da ricercatori del MIT e della Harvard Business School che, utilizzando "l'ipotesi del mirroring" come concetto equivalente alla legge di Conway, hanno trovato forti riscontri a sostegno della tesi, in particolare hanno trovato, ad esempio, che team distribuiti tendono a sviluppare prodotti più modulari.
 
Prove a sostegno della legge di Conway sono state pubblicate da ricercatori del MIT e della Harvard Business School che, utilizzando "l'ipotesi del mirroring" come concetto equivalente alla legge di Conway, hanno trovato forti riscontri a sostegno della tesi, in particolare hanno trovato, ad esempio, che team distribuiti tendono a sviluppare prodotti più modulari.
  
Pertanto assicurati che la struttura dell'organizzazione sia compatibile con l'architettura del prodotto che deve sviluppare.
+
Pertanto assicurati che la struttura dell'organizzazione sia compatibile con l'architettura del prodotto che intendi sviluppare.
  
 
== Risorse esterne ==
 
== Risorse esterne ==

Versione attuale delle 14:24, 11 apr 2020

La Legge di Conway è una celebre frase attribuita all'informatico Melvin Conway nel 1967. Fu soprannominata Legge di Conway per la prima volta dai partecipanti del National Symposium on Modular Programming del 1968.

Qualsiasi organizzazione che progetti un sistema (definito in senso lato) produrrà un progetto la cui struttura è una copia della struttura di comunicazione dell'organizzazione.
M. Conway

La legge di Conway non era intesa come uno scherzo o un koan zen, ma come una valida osservazione sociologica. È una conseguenza del fatto che due moduli software A e B non possono interfacciarsi correttamente a meno che il progettista e realizzatore di A non comunichi con il progettista e realizzatore di B. Perciò la struttura dell' interfaccia di un sistema software presenterà necessariamente una congruenza con la struttura sociale dell'organizzazione che l'ha prodotta.

"If the parts of an organization (e.g., teams, departments, or subdivisions) do not closely reflect the essential parts of the product, or if the relationship between organizations do not reflect the relationships between product parts, then the project will be in trouble... Therefore: Make sure the organization is compatible with the product architecture."
James O. Coplien and Neil B. Harrison

La legge è dunque basata sull'osservazione che un software modulare viene progettato rispecchiando i rapporti sociali fra i progettisti dell'azienda che lo ha realizzato.

le organizzazioni che progettano sistemi ... sono indotte a generare design che sono copie dei legami nelle organizzazioni stesse.
M. Conway

In parole povere: il risultato di un progetto di un sistema dipende dal modo in cui l'organizzazione che lo produce comunica.

Conferme alla legge

Prove a sostegno della legge di Conway sono state pubblicate da ricercatori del MIT e della Harvard Business School che, utilizzando "l'ipotesi del mirroring" come concetto equivalente alla legge di Conway, hanno trovato forti riscontri a sostegno della tesi, in particolare hanno trovato, ad esempio, che team distribuiti tendono a sviluppare prodotti più modulari.

Pertanto assicurati che la struttura dell'organizzazione sia compatibile con l'architettura del prodotto che intendi sviluppare.

Risorse esterne