"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.
23 maggio 2009
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.
04 febbraio 2009
Comunità di contenuti
Un articolo di Wojciech Cellary, universitario di Poznan, "Content Communities on the Internet", confronta le comunità territoriali (le relazioni che si stabiliscono nel luogo in cui si risiede) con le comunità che si formano su internet in merito ad uno specifico argomento (ad esempio gli appassionati della Fiat 500, o le persone interessate agli standard ISO9000).
L'analisi comparativa fa emergere alcuni aspetti interessanti, tra cui:
L'analisi comparativa fa emergere alcuni aspetti interessanti, tra cui:
- nelle comunità di contenuti, il fatto che le relazioni si stabiliscano su un unico argomento porta naturalmente ad una radicalizzazione delle posizioni
- affinché la comunità di contenuti si sviluppi in modo positivo, la partecipazione non deve essere anonima.
Libro su BPMN
Scritto da Stephen White (il coordinatore del gruppo di lavoro che ha prodotto e fa evolvere lo standard) con la collaborazione di Derek Myers: BPMN Modeling and Reference Guide, Future Strategies 2008.
BPMN (Business Process Modeling Notation) è lo standard per la rappresentazione dei processi di business, gestito dall'Object Management Group (OMG).
Il libro non aggiunge nulla a quanto contenuto nella specifica ufficiale OMG, scaricabile gratuitamente - ma è organizzato e scritto in un modo più comprensibile. Alcuni esempi sono diversi rispetto a quelli presenti nella specifica ufficiale - in altri casi, gli esempi sono identici.
Si poteva fare di meglio, dato il livello di competenza degli autori, ma il libro costituisce comunque un'utile introduzione all'argomento.
BPMN (Business Process Modeling Notation) è lo standard per la rappresentazione dei processi di business, gestito dall'Object Management Group (OMG).
Il libro non aggiunge nulla a quanto contenuto nella specifica ufficiale OMG, scaricabile gratuitamente - ma è organizzato e scritto in un modo più comprensibile. Alcuni esempi sono diversi rispetto a quelli presenti nella specifica ufficiale - in altri casi, gli esempi sono identici.
Si poteva fare di meglio, dato il livello di competenza degli autori, ma il libro costituisce comunque un'utile introduzione all'argomento.
29 gennaio 2009
PMBOK 4
Nuova edizione del Project Management Book of Knowledge (PMBOK), la quarta, uscita il 31-12-2008.
Il Project Management Institute (PMI) ha pubblicato un contemporaneo aggiornamento anche di altri tre propri standard:
Il Project Management Institute (PMI) ha pubblicato un contemporaneo aggiornamento anche di altri tre propri standard:
- Organizational Project Management Maturity Model (OPM3)
- Program Management
- Portfolio Management
Le migliori scuole del Piemonte
Classifica delle scuole medie superiori del Piemonte, compilata dalla Fondazione Agnelli.
Magari le singole collocazioni sono discutibili. Magari sono discutibili anche i criteri di valutazione.
Ma è comunque un grosso passo avanti il fatto che si pensi a rendere esplicita, pubblicamente confrontabile e discutibile, la domanda che genitori e studenti si fanno, da sempre, su quali siano le scuole più affidabili.
Da notare la collocazione in graduatoria delle scuole private, giù giù giù.
Magari le singole collocazioni sono discutibili. Magari sono discutibili anche i criteri di valutazione.
Ma è comunque un grosso passo avanti il fatto che si pensi a rendere esplicita, pubblicamente confrontabile e discutibile, la domanda che genitori e studenti si fanno, da sempre, su quali siano le scuole più affidabili.
Da notare la collocazione in graduatoria delle scuole private, giù giù giù.
06 gennaio 2009
Fare attenzione, sempre più difficile
Email, SMS, Facebook, ... se non si è disciplinati, gli stimoli che ci distraggono ci possono risucchiare.
La capacità di lavorare, di progredire, di ottenere risultati si basa sulla concentrazione, sul prestare attenzione. Ma ogni fonte informativa ed ogni canale di comunicazione si ripromettono di ottenere, sia pure per poco, la nostra attenzione. Di distrarci dal nostro focus.
Questo articolo di Mike Elgan lo spiega bene. Sei ore di lavoro concentrato ottengono ben di più di dodici ore di lavoro inframmezzato da email, telefonate, sms, navigazioni web, ecc.
La capacità di lavorare, di progredire, di ottenere risultati si basa sulla concentrazione, sul prestare attenzione. Ma ogni fonte informativa ed ogni canale di comunicazione si ripromettono di ottenere, sia pure per poco, la nostra attenzione. Di distrarci dal nostro focus.
Questo articolo di Mike Elgan lo spiega bene. Sei ore di lavoro concentrato ottengono ben di più di dodici ore di lavoro inframmezzato da email, telefonate, sms, navigazioni web, ecc.
29 novembre 2008
Usabilità, requisiti e progetti agili
Jakob Nielsen è un esperto di usabilità. Nella sua newsletter Alertbox parla del rapporto tra usabilità e approcci agili. L'argomentazione di Nielsen prende l'avvio dai requisiti:
"Requirement specifications are always wrong.
At best — when derived with care — the requirements might reflect what
users want. More commonly, however, they reflect the desires of user
'representatives' who are too far removed from the coalface to know the
details of the real work. In any case, what users want and what users need
are two different things, which is why it's long been a primary usability
guideline to watch what users do, rather than listen to what they say".
"Requirement specifications are always wrong.
At best — when derived with care — the requirements might reflect what
users want. More commonly, however, they reflect the desires of user
'representatives' who are too far removed from the coalface to know the
details of the real work. In any case, what users want and what users need
are two different things, which is why it's long been a primary usability
guideline to watch what users do, rather than listen to what they say".
CMMI e Agile
Il Software Engineering Institute (SEI) è un'istituzione finanziata dal governo e da grandi aziende USA. Nei corsi che tengo sono solito raccomandare il sito del SEI come una delle fonti più autorevoli di documentazione sulle tematiche dello sviluppo software. Documenti di alta qualità, e gratuiti.
Tra le altre cose, il SEI è noto per aver creato il CMMI-SW (Capability Maturity Model Integration), un modello per la valutazione del grado di maturità delle organizzazioni che sviluppano software. Modello applicato dal governo americano e da molte organizzazioni internazionali per selezionare i propri fornitori nello sviluppo software.
Il CMMI-SW è spesso ritenuto, a torto, come un modello che porta a burocratizzare lo sviluppo, pesante e con effetti negativi sulla produttività e sulla flessibilità. Può essere applicato così, è vero. Ma pesantezza e burocrazia non sono affatto insite nel modello, bensì sono causate da chi lo interpreta in modo superficiale.
Una recente pubblicazione del SEI, "CMMI or Agile: Why Not Embrace Both!" evidenzia la compatibilità del CMMI con gli approcci agili.
Tra le altre cose, il SEI è noto per aver creato il CMMI-SW (Capability Maturity Model Integration), un modello per la valutazione del grado di maturità delle organizzazioni che sviluppano software. Modello applicato dal governo americano e da molte organizzazioni internazionali per selezionare i propri fornitori nello sviluppo software.
Il CMMI-SW è spesso ritenuto, a torto, come un modello che porta a burocratizzare lo sviluppo, pesante e con effetti negativi sulla produttività e sulla flessibilità. Può essere applicato così, è vero. Ma pesantezza e burocrazia non sono affatto insite nel modello, bensì sono causate da chi lo interpreta in modo superficiale.
Una recente pubblicazione del SEI, "CMMI or Agile: Why Not Embrace Both!" evidenzia la compatibilità del CMMI con gli approcci agili.
Risorse educative aperte
Global Warming Toward Open Educational Resources, un articolo di Richard G. Baraniuk e C. Sidney Burrus su Communications of the ACM, settembre 2008.
Sulla diffusione di ambienti e strumenti gratuiti per la formazione. Tra cui:
MIT: Open-CourseWare e OCW consortium
Rice University: Connexions
Open University: OpenLearn
Carnegie Mellon University: Open Learning Initiative
Sulla diffusione di ambienti e strumenti gratuiti per la formazione. Tra cui:
MIT: Open-CourseWare e OCW consortium
Rice University: Connexions
Open University: OpenLearn
Carnegie Mellon University: Open Learning Initiative
Destino degli strumenti Telelogic
Dopo parecchi mesi, si è delineato il quadro di integrazione degli strumenti Telelogic (per la gestione dei requisiti e per la modellazione UML - SysML) in ambito IBM.
Il problema essenziale era come far convivere l'offerta Telelogic con l'offerta concorrente della linea Rational. Un paio di articoli (SDTimes , eWeek) fanno finalmente emergere cosa IBM propone ai propri clienti.
Il problema essenziale era come far convivere l'offerta Telelogic con l'offerta concorrente della linea Rational. Un paio di articoli (SDTimes , eWeek) fanno finalmente emergere cosa IBM propone ai propri clienti.
Iscriviti a:
Post (Atom)