Thomas Jefferson
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."
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.
Iscriviti a:
Post (Atom)
