Un libro di Enzo Mari sul design:
Lezioni di disegno. Storie di risme di carta, draghi e struzzi in cattedra. Rizzoli 2008.
Il design (architettura, ma molti spunti sono trasferibili al software), la formazione al design, la società. Scritto e disegnato a mano, con intrecciarsi sapiente di testo corsivo e disegni.
27 luglio 2009
10 luglio 2009
Etica del software
Un numero speciale di IEEE Computer, June 2009, sugli aspetti etici della produzione di software.
Tra gli articoli, "The public is the priority: making decisions using the Software Engineering Code of Ethics", di Donald Gotterbarn e Keith W. Miller, che spiega come si può e si deve usare il Codice Etico di Sviluppo Software di ACM e IEEE Computer Society, del quale potete trovare qui la versione italiana.
Tra gli articoli, "The public is the priority: making decisions using the Software Engineering Code of Ethics", di Donald Gotterbarn e Keith W. Miller, che spiega come si può e si deve usare il Codice Etico di Sviluppo Software di ACM e IEEE Computer Society, del quale potete trovare qui la versione italiana.
Al prezzo più basso
Nelle gare d'appalto, spesso vince il fornitore che offre il prezzo più basso. E cominciano i guai, dato che "offerte e stime troppo basse sono spesso indicative di una scarsa competenza".
"How to avoid selecting bids based on overoptimistic cost estimates", è un articolo di Magne Jorgensen, pubblicato su IEEE Software May/June 2009.
L'articolo riporta i risultati di una serie di studi e sondaggi, e offre una serie di raccomandazioni utili per il processo di selezione.
"How to avoid selecting bids based on overoptimistic cost estimates", è un articolo di Magne Jorgensen, pubblicato su IEEE Software May/June 2009.
L'articolo riporta i risultati di una serie di studi e sondaggi, e offre una serie di raccomandazioni utili per il processo di selezione.
Come rompere il software
How to break software. A Practical Guide to Testing, di James A. Whittaker, Addison-Wesley 2002.
Poca teoria, tanta pratica, suggerimenti concreti, anche un CD con tool per simulare problemi (poca memoria, connessioni interrotte, hardware mal funzionante...) nell'ambiente che ospita le applicazioni da testare. Testo utile e ben scritto.
Poca teoria, tanta pratica, suggerimenti concreti, anche un CD con tool per simulare problemi (poca memoria, connessioni interrotte, hardware mal funzionante...) nell'ambiente che ospita le applicazioni da testare. Testo utile e ben scritto.
Software per il sociale
Negli Usa, da anni, la computer science ha perso attrattiva per i giovani come oggetto di studio universitario. Per renderla più attraente, sostiene Michael Buckley, professore a Buffalo, è necessario che i problemi informatici trattati durante la formazione universitaria (casi studio, esercizi) contribuiscano a risolvere problemi sociali.
Michael Buckley: Computing as Social Science, Communication of the ACM, April 2009.
Michael Buckley: Computing as Social Science, Communication of the ACM, April 2009.
Fucine di software
Le Software Forges (fucine di software) sono ambienti collaborativi nati per lo sviluppo e la diffusione di software open source, il più famoso dei quali è probabilmente SourceForge. Negli ultimi anni, l'esperienza ha avuto un progressivo allargamento anche agli ambiti aziendali, con la creazione di fucine di software all'interno di singole organizzazioni.
Dirk Riehle e altri suoi colleghi di SAP spiegano su IEEE Software March/April 2009 le caratteristiche della fucina interna di SAP e fanno alcuni confronti con quelle, sempre interne, di IBM, HP e Microsoft.
Dirk Riehle e altri suoi colleghi di SAP spiegano su IEEE Software March/April 2009 le caratteristiche della fucina interna di SAP e fanno alcuni confronti con quelle, sempre interne, di IBM, HP e Microsoft.
Tracciabilità multimediale dei requisiti
I requisiti si possono scoprire in molti modi. Anche con registratori e videocamere, ormai presenti in diversi telefoni cellulari. Come gestire la tracciabilità, quando la fonte documentale del requisito è un audio o un video?
Il tema è oggetto di un articolo di Olly Gotel e Stephen Morris, "More than Just 'Lost in Translation'", su IEEE Software March/April 2009.
04 giugno 2009
Sull'Italia attuale
"If a nation expects to be ignorant and free, in a state of civilization, it expects what never was and never will be."
Thomas Jefferson
Software Embedded: dati
"Il mercato mondiale per i sistemi embedded è di circa 160 miliardi di euro, con una crescita annuale del 9 per cento.
[...]
Le nuove auto hanno attualmente da 20 a 70 control unit, con più di 100 milioni di linee di codice [...]".
L'articolo, di Christof Ebert e Capers Jones su IEEE Computer di aprile 2009, è ricco di dati utili per la comprensione delle specificità e del peso economico della "nicchia" dell'embedded nel contesto del mercato software globale: "Embedded Software: Facts, Figures, and Future".
[...]
Le nuove auto hanno attualmente da 20 a 70 control unit, con più di 100 milioni di linee di codice [...]".
L'articolo, di Christof Ebert e Capers Jones su IEEE Computer di aprile 2009, è ricco di dati utili per la comprensione delle specificità e del peso economico della "nicchia" dell'embedded nel contesto del mercato software globale: "Embedded Software: Facts, Figures, and Future".
23 maggio 2009
Giochi per educare gli informatici
"Puzzling Problems in Computer Engineering", un articolo di Behrooz Parhami su IEEE Computer, marzo 2009.
Una serie di giochi-problemi messi a punto dall'University of California, Santa Barbara. L'articolo è a pagamento, ma l'autore ha pubblicato un sito web da cui i giochi-problemi possono essere scaricati gratuitamente.
Una serie di giochi-problemi messi a punto dall'University of California, Santa Barbara. L'articolo è a pagamento, ma l'autore ha pubblicato un sito web da cui i giochi-problemi possono essere scaricati gratuitamente.
Accreditare i software engineer?
"Licensing Software Engineers?" è un articolo di Philippe Krutchen su IEEE Software, nov/dec 2008.
Krutchen parte citando Dilbert di Scott Adams: "The goal of a software engineer is to retire without having caused any major catastrophe", e argomenta in modo convincente in favore di una qualche forma di accreditamento per chi progetta sistemi critici.
Afferma tra l'altro: "Accreditare i software engineer non c'entra nulla con l'escludere qualcuno dallo sviluppo software. Solo alcuni devono mettere la firma su un progetto di software critico, che può causare la morte di persone. Non tutti quelli che lavorano in un ospedale devono essere dottori ."
Krutchen parte citando Dilbert di Scott Adams: "The goal of a software engineer is to retire without having caused any major catastrophe", e argomenta in modo convincente in favore di una qualche forma di accreditamento per chi progetta sistemi critici.
Afferma tra l'altro: "Accreditare i software engineer non c'entra nulla con l'escludere qualcuno dallo sviluppo software. Solo alcuni devono mettere la firma su un progetto di software critico, che può causare la morte di persone. Non tutti quelli che lavorano in un ospedale devono essere dottori ."
22 maggio 2009
Organizzazione e qualità del software
La complessità dell'organizzazione coinvolta nello sviluppo software potrebbe essere il fattore più importante per prevedere la qualità del software stesso.
Uno studio empirico condotto da due ricercatori Microsoft e da Victor Basili (Università del Maryland) definisce otto misure relative alla struttura organizzativa, e le applica su dati provenienti dal progetto di Windows Vista.
Secondo lo studio, le misure sulla struttura organizzativa costituiscono un indicatore affidabile per prevedere la qualità del software. Più affidabile di altri indicatori che vengono usati comunemente, come il numero di difetti pre-release, il numero di dipendenze, la complessità ciclomatica, il numero di modifiche in corso d'opera.
Uno studio empirico condotto da due ricercatori Microsoft e da Victor Basili (Università del Maryland) definisce otto misure relative alla struttura organizzativa, e le applica su dati provenienti dal progetto di Windows Vista.
Secondo lo studio, le misure sulla struttura organizzativa costituiscono un indicatore affidabile per prevedere la qualità del software. Più affidabile di altri indicatori che vengono usati comunemente, come il numero di difetti pre-release, il numero di dipendenze, la complessità ciclomatica, il numero di modifiche in corso d'opera.
TED in italiano
TED (Technology Entertainment Design) è un ciclo di conferenze internazionali molto interessante.
La durata massima di ogni conferenza è di 20 minuti, e i relatori ed i temi affrontati sono eccellenti.
Ora alcune delle conferenze sono state sottotitolate in italiano, e vale la pena godersele.
La durata massima di ogni conferenza è di 20 minuti, e i relatori ed i temi affrontati sono eccellenti.
Ora alcune delle conferenze sono state sottotitolate in italiano, e vale la pena godersele.
19 aprile 2009
I bambini imparano da soli
Un video che mi ha colpito. Un computer collegato a internet messo a disposizione di bambini in remoti villaggi indiani, senza insegnanti, per bambini che non conoscevano l'inglese. E i risultati.
Su TED, la presentazione di Sugata Mitra.
Su TED, la presentazione di Sugata Mitra.
04 aprile 2009
Hardware/Software Codesign
An adaptive hardware/software codesign model enables consumer electronics companies to reduce production cost and maximize profits by progressively modifying codesign options over the life cycle.
A Survival Kit: Adaptive Hardware/Software Codesign Life-Cycle Model, di Dong-hyun Lee e altri, su IEEE Computer, febbraio 2009.
A Survival Kit: Adaptive Hardware/Software Codesign Life-Cycle Model, di Dong-hyun Lee e altri, su IEEE Computer, febbraio 2009.
24-Hour Knowledge Factory
Tre turni: uno in Africa o Europa, uno in Asia, uno in America.
Tutti lavorano di giorno, alla luce del sole (anche con benefici per la salute, dato che lavorare di notte aumenta i rischi di cancro al seno e alla prostata).
L'articolo è di Amar Gupta, su IEEE Computer di gennaio 2009.
Tutti lavorano di giorno, alla luce del sole (anche con benefici per la salute, dato che lavorare di notte aumenta i rischi di cancro al seno e alla prostata).
L'articolo è di Amar Gupta, su IEEE Computer di gennaio 2009.
10 marzo 2009
Product Owner
Il Product Owner è uno dei ruoli principali di Scrum, uno dei processi agili più diffusi.
In italiano, lo si può tradurre come "proprietario del prodotto", o "responsabile del prodotto".
Dal punto di vista di chi sviluppa software, corrisponde in linea di massima al ruolo di "committente", cioè di chi ha la responsabilità di decidere i requisiti da soddisfare, le priorità di realizzazione, l'accettabilità dei risultati forniti dagli sviluppatori.
Certamente è il ruolo più importante per il successo di un prodotto, di un sistema. Ma è arduo da svolgere, perché non esiste un percorso formativo per diventare Product Owner, e può capitare che il ruolo non sia riconosciuto in termini di autorità e responsabilità all'interno delle organizzazioni.
Sul ruolo di Product Owner, uno scritto interessante di Jeff Patton.
In italiano, lo si può tradurre come "proprietario del prodotto", o "responsabile del prodotto".
Dal punto di vista di chi sviluppa software, corrisponde in linea di massima al ruolo di "committente", cioè di chi ha la responsabilità di decidere i requisiti da soddisfare, le priorità di realizzazione, l'accettabilità dei risultati forniti dagli sviluppatori.
Certamente è il ruolo più importante per il successo di un prodotto, di un sistema. Ma è arduo da svolgere, perché non esiste un percorso formativo per diventare Product Owner, e può capitare che il ruolo non sia riconosciuto in termini di autorità e responsabilità all'interno delle organizzazioni.
Sul ruolo di Product Owner, uno scritto interessante di Jeff Patton.
01 marzo 2009
Il (software) design come fatto sociale
Richard Gabriel è uno dei leader storici della comunità dei software design pattern.
Ha pubblicato da poco uno scritto interessante, Designed as Designer, in cui affronta la tesi romantica della creazione di un design (di un'architettura) come espressione totalmente autonoma di un'individualità. Non è certo il primo a smontare la creatività romantica, ma la sua argomentazione è supportata da esempi illuminanti.
Gabriel evidenzia come ogni design (di un edificio, di una poesia, di un software) sia il frutto di due relazioni:
Ha pubblicato da poco uno scritto interessante, Designed as Designer, in cui affronta la tesi romantica della creazione di un design (di un'architettura) come espressione totalmente autonoma di un'individualità. Non è certo il primo a smontare la creatività romantica, ma la sua argomentazione è supportata da esempi illuminanti.
Gabriel evidenzia come ogni design (di un edificio, di una poesia, di un software) sia il frutto di due relazioni:
- del designer con altri designer, e più in generale con altre persone (collaboratori, revisori, ecc.)
- del designer con il materiale trattato, che condiziona e influenza ogni scelta di design
Lo sviluppo sw è un fatto sociale, più che tecnologico
"As we realize that software development is often more about people - collaboration, communication, and coordination - than technology, developing 'soft skills' such as meeting-management techniques is becoming more important".
Nell'articolo "When Robert Rules", su IEEE Software Jan/Feb 2009, Philippe Krutchen segnala un metodo di gestione delle riunioni pubblicato nel 1896 da un generale USA, Henry M. Robert, e ancora utile oggi, le Robert's Rules of Order.
Nell'articolo "When Robert Rules", su IEEE Software Jan/Feb 2009, Philippe Krutchen segnala un metodo di gestione delle riunioni pubblicato nel 1896 da un generale USA, Henry M. Robert, e ancora utile oggi, le Robert's Rules of Order.
06 febbraio 2009
Evolutionary System Development
Un articolo di Peter Denning, Chris Gunderson e Rick Hayes-Roth, tre esperti IT di lungo corso che lavorano attualmente per la US Navy, la marina statunitense, segna a mio avviso una tappa importante nel percorso verso la piena affermazione dei processi agili.
"The software engineering community has hotly debated preplanned versus agile processes. After a while they reached a truce where they agreed that preplanning is best for large systems
where reliability and risk-avoidance are prime concerns, and agile is best for small to medium systems where adaptability and user friendliness are prime concerns.
We challenge that conclusion. Preplanning is ceasing to be a viable option for large systems. [...]
Whereas preplanned development seeks to avoid risks, evolutionary development mimics nature and embraces risks. The developers purposely expose emerging systems to risks to see how they fail, and then they build better system variants. It is better to seek risk out
and learn how to survive it. [...]
All the evidence says that that evolutionary processes works for systems large and small, and that risk seeking is the fastest route to fitness. There is too much at stake to continue to allow us to be locked into a process that does not work."
L'articolo è stato pubblicato nel numero di dicembre 2008 di Communications of the ACM.
"The software engineering community has hotly debated preplanned versus agile processes. After a while they reached a truce where they agreed that preplanning is best for large systems
where reliability and risk-avoidance are prime concerns, and agile is best for small to medium systems where adaptability and user friendliness are prime concerns.
We challenge that conclusion. Preplanning is ceasing to be a viable option for large systems. [...]
Whereas preplanned development seeks to avoid risks, evolutionary development mimics nature and embraces risks. The developers purposely expose emerging systems to risks to see how they fail, and then they build better system variants. It is better to seek risk out
and learn how to survive it. [...]
All the evidence says that that evolutionary processes works for systems large and small, and that risk seeking is the fastest route to fitness. There is too much at stake to continue to allow us to be locked into a process that does not work."
L'articolo è stato pubblicato nel numero di dicembre 2008 di Communications of the ACM.
Iscriviti a:
Post (Atom)