"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.
Modelli di stima dei costi nel software
Cocomo (Constructive Cost Model) è ritenuto comunemente il modello per la stima dei costi più completo ed affidabile in ambito software.
Achievements and Challenges in Cocomo-Based Software Resource Estimation (su IEEE Software, September-October 2008) è un articolo scritto dal padre di Cocomo, Barry Boehm, insieme a Ricardo Valerdi del MIT.
L'articolo fa il punto sullo stato dell'arte, le criticità e le tendenze nell'evoluzione dei modelli previsionali.
Achievements and Challenges in Cocomo-Based Software Resource Estimation (su IEEE Software, September-October 2008) è un articolo scritto dal padre di Cocomo, Barry Boehm, insieme a Ricardo Valerdi del MIT.
L'articolo fa il punto sullo stato dell'arte, le criticità e le tendenze nell'evoluzione dei modelli previsionali.
Tecnologie digitali e disintegrazione sociale
The Dea[r]th of Human Understanding. La penuria (la morte) della comprensione umana. Un articolo di Neville Holmes su IEEE Computer, ottobre 2008.
Holmes cita Nicholas Carr (Is Google Making Us Stupid?), ma espande la sua analisi sul ruolo e sugli effetti dei videogiochi. Pessimista, e convincente.
Holmes cita Nicholas Carr (Is Google Making Us Stupid?), ma espande la sua analisi sul ruolo e sugli effetti dei videogiochi. Pessimista, e convincente.
Princìpi di software testing (Meyer)
Da un articolo di Bertrand Meyer, uno dei nomi più importanti nel campo del software design:
- Principle 1: Definition. To test a program is to try to make it fail.
- Principle 2: Tests versus specs. Tests are no substitute for specifications.
- Principle 3: Regression testing. Any failed execution must yield a test case, to remain a permanent part of the project’s test suite.
- Principle 4: Applying oracles. Determining success or failure of tests must be an automatic process.
- Principle 5: Manual and automatic test cases. An effective testing process must include both manually and automatically produced test cases.
- Principle 6: Empirical assessment of testing strategies. Evaluate any testing strategy, however attractive in principle, through objective assessment using explicit criteria in a reproducible testing process.
- Principle 7: Assessment criteria. A testing strategy’s most important property is the number of faults it uncovers as a function of time.
10 novembre 2008
La nuvola
The cloud - la nuvola. L'infrastruttura di elaborazione evaporata.
O, meglio, servizi di elaborazione erogati allo stesso modo dell'energia elettrica, da grandi centrali che garantiscono una continua disponibilità. Le stanno costruendo, tra gli altri, Microsoft, Google, IBM, HP, Amazon.
Una soluzione attraente - in termini di costi - per diverse tipologie di potenziali clienti. Ma con rischi significativamente diversi rispetto ad altre forme di outsourcing.
Al cloud computing è dedicato un inserto pubblicato il 23 ottobre dall'Economist.
O, meglio, servizi di elaborazione erogati allo stesso modo dell'energia elettrica, da grandi centrali che garantiscono una continua disponibilità. Le stanno costruendo, tra gli altri, Microsoft, Google, IBM, HP, Amazon.
Una soluzione attraente - in termini di costi - per diverse tipologie di potenziali clienti. Ma con rischi significativamente diversi rispetto ad altre forme di outsourcing.
Al cloud computing è dedicato un inserto pubblicato il 23 ottobre dall'Economist.
21 ottobre 2008
Italia: 80.000 imprese IT
La Camera di Commercio di Milano ha pubblicato i risultati di una propria elaborazione sui dati del registro imprese.
Riporto l'intestazione:
"LA CARICA DELLE 80 MILA IMPRESE INFORMATICHE ITALIANE
+7,4% in quattro anni, 4 miliardi di euro di commercio estero
25 mila nuove assunzioni di personale qualificato nel 2008
Lombardia e Milano prime in Italia per imprese. Seguono Roma e Torino."
Userei meno trionfali, visto lo stato dell'economia italiana in generale e del settore IT in particolare. 80 mila imprese (la grande maggioranza individuali!) è un dato sconsolante, indice di frammentazione e debolezza.
Riporto l'intestazione:
"LA CARICA DELLE 80 MILA IMPRESE INFORMATICHE ITALIANE
+7,4% in quattro anni, 4 miliardi di euro di commercio estero
25 mila nuove assunzioni di personale qualificato nel 2008
Lombardia e Milano prime in Italia per imprese. Seguono Roma e Torino."
Userei meno trionfali, visto lo stato dell'economia italiana in generale e del settore IT in particolare. 80 mila imprese (la grande maggioranza individuali!) è un dato sconsolante, indice di frammentazione e debolezza.
UML 2.2 e SysML 1.1
L'Object Management Group (OMG) ha approvato le nuove versioni di:
UML (Unified Modeling Language) 2.2, disponibile per il download la documentazione in formato beta con barre di cambiamento per evidenziare le pochissime novità.
SysML (Systems Modeling Language) 1.1, disponibile per il download al SysML Forum.
UML (Unified Modeling Language) 2.2, disponibile per il download la documentazione in formato beta con barre di cambiamento per evidenziare le pochissime novità.
SysML (Systems Modeling Language) 1.1, disponibile per il download al SysML Forum.
14 ottobre 2008
Software perfetto
"Perfect Software and other illusions about testing". È un libro di Gerald Weinberg, uscito da poco.
Tra tutte le attività collegate al software, il testing è l'attività più fraintesa. Anche dai professionisti dello sviluppo.
Il libriccino è sottile, scritto bene, si legge in fretta, non entra in dettagli tecnici. Un'ottima introduzione alla realtà del testing, per chiunque lavori in un progetto, per i manager, per i committenti. Anche per chi di software sa poco o nulla.
Tra tutte le attività collegate al software, il testing è l'attività più fraintesa. Anche dai professionisti dello sviluppo.
Il libriccino è sottile, scritto bene, si legge in fretta, non entra in dettagli tecnici. Un'ottima introduzione alla realtà del testing, per chiunque lavori in un progetto, per i manager, per i committenti. Anche per chi di software sa poco o nulla.
09 ottobre 2008
Story Maps
Rappresentare le funzionalità di un sistema in un modo comprensibile sia agli stakeholders che agli sviluppatori. E inoltre utile per indicare le priorità.
La tecnica delle "story maps" è semplice. Jeff Patton la descrive in questo intervento.
La tecnica delle "story maps" è semplice. Jeff Patton la descrive in questo intervento.
02 ottobre 2008
Moscow e priorità
Il primo corso a cui partecipai sull'analisi dei sistemi - tanti anni fa - insegnava ad usare per i requisiti una classificazione MoSCoW.
MoSCoW è un acronimo che sta per:
* Must have - si deve avere
* Should have - si dovrebbe avere
* Could have - si potrebbe avere
* Won't have - non si deve avere
Non ho mai usato la classificazione MoSCoW, anche se suggestiva. E non l'ho mai insegnata nei miei corsi. Ho sempre usato la tecnica di classificare i requisiti in termini di priorità, che ritenevo più efficace.
In realtà, comunque, non mi sono mai messo a ragionare a fondo sulla classificazione MoSCoW. L'ha fatto invece James Shore, in un intervento che condivido.
MoSCoW è un acronimo che sta per:
* Must have - si deve avere
* Should have - si dovrebbe avere
* Could have - si potrebbe avere
* Won't have - non si deve avere
Non ho mai usato la classificazione MoSCoW, anche se suggestiva. E non l'ho mai insegnata nei miei corsi. Ho sempre usato la tecnica di classificare i requisiti in termini di priorità, che ritenevo più efficace.
In realtà, comunque, non mi sono mai messo a ragionare a fondo sulla classificazione MoSCoW. L'ha fatto invece James Shore, in un intervento che condivido.
Precisare i requisiti
Un intervento di Tom Gilb su Requirements Network:
"Requirements Relationships: A Theory, some Principles, and a Practical
Approach"
Tom Gilb è uno dei padri dell'approccio iterativo e
incrementale, con il metodo Evo (1988).
Per quanto riguarda la gestione dei requisiti, il suo contributo
fondamentale è stato l'introduzione di Planguage, un linguaggio per
precisare i requisiti.
Requirements Network è un sito che pubblica settimanalmente articoli
sulla gestione requisiti.
Bisogna registrarsi con user e password per accedere, scaricare
articoli, commentare, intervenire.
"Requirements Relationships: A Theory, some Principles, and a Practical
Approach"
Tom Gilb è uno dei padri dell'approccio iterativo e
incrementale, con il metodo Evo (1988).
Per quanto riguarda la gestione dei requisiti, il suo contributo
fondamentale è stato l'introduzione di Planguage, un linguaggio per
precisare i requisiti.
Requirements Network è un sito che pubblica settimanalmente articoli
sulla gestione requisiti.
Bisogna registrarsi con user e password per accedere, scaricare
articoli, commentare, intervenire.
I requisiti si scoprono meglio dopo
Esprimere requisiti per un sistema che esiste già è molto più facile che esprimerli per uno che non esiste ancora.
Vedi il sistema, lo usi, capisci quello che non funziona, quello che manca, quello che si potrebbe, vorrebbe, dovrebbe migliorare. Immediato.
Molto più facile che rispondere a domande su come si vorrà qualcosa che non esiste ancora, o sulla correttezza di un modello, o di una specifica.
Su questo assunto (di semplice buon senso) concordano tutti gli esperti di sviluppo software.
Naturalmente, bisogna vedere come trarne le conseguenze quando si cala l'assunto in un contesto di sviluppo professionale, con relazioni cliente-fornitore, contratti, ecc.
Su questo, un intervento interessante di Martin Fowler.
Vedi il sistema, lo usi, capisci quello che non funziona, quello che manca, quello che si potrebbe, vorrebbe, dovrebbe migliorare. Immediato.
Molto più facile che rispondere a domande su come si vorrà qualcosa che non esiste ancora, o sulla correttezza di un modello, o di una specifica.
Su questo assunto (di semplice buon senso) concordano tutti gli esperti di sviluppo software.
Naturalmente, bisogna vedere come trarne le conseguenze quando si cala l'assunto in un contesto di sviluppo professionale, con relazioni cliente-fornitore, contratti, ecc.
Su questo, un intervento interessante di Martin Fowler.
TED: idee che vale la pena diffondere
TED (Technology Entertainment Design). Ideas worth spreading.
Una collezione di video di durata contenuta (in genere non più di 20 minuti), con relatori e contenuti eccellenti. Non solo IT, purtroppo senza sottotitoli.
Tra quelli che ho visto:
Jill Bolte Taylor: My stroke of insight
Ken Robinson: Do schools kill creativity?
Benjamin Zander: Classical music with shining eyes
Una collezione di video di durata contenuta (in genere non più di 20 minuti), con relatori e contenuti eccellenti. Non solo IT, purtroppo senza sottotitoli.
Tra quelli che ho visto:
Jill Bolte Taylor: My stroke of insight
Ken Robinson: Do schools kill creativity?
Benjamin Zander: Classical music with shining eyes
16 settembre 2008
Il web per i cellulari
La prossima estinzione del WAP, secondo quanto pubblicato da Software Development Times. I cellulari sono ormai diventati dei normali client.
Italia ancora meno competitiva nell'IT
La conferma di un trend, secondo una ricerca pubblicata dalla Economist Intelligence Unit e ripresa dal sito di Computerworld Italia
13 luglio 2008
Le scuole in Finlandia
Insegnare è un mestiere prestigioso, e selettivo. In Finlandia.
L'educazione è considerata "the centrepiece of national identity. So hard work and good behaviour are the norm; teaching tempts the best graduates (nearly nine out of ten would-be teachers are turned down)." Economist, 26 giugno 2008
Nove candidati all'insegnamento su dieci vengono scartati. I risultati si vedono: gli allievi delle scuole finlandesi compaiono ai vertici delle classifiche internazionali per capacità di comprensione ed espressione testuale, matematica, scienze.
L'educazione è considerata "the centrepiece of national identity. So hard work and good behaviour are the norm; teaching tempts the best graduates (nearly nine out of ten would-be teachers are turned down)." Economist, 26 giugno 2008
Nove candidati all'insegnamento su dieci vengono scartati. I risultati si vedono: gli allievi delle scuole finlandesi compaiono ai vertici delle classifiche internazionali per capacità di comprensione ed espressione testuale, matematica, scienze.
04 luglio 2008
Co-evoluzione di problemi e soluzioni
Mentre ragioniamo sulle possibili soluzioni ad un problema, la stessa definizione del problema può dover essere riformulata.
Uno studio interessante sul disegno creativo, di Kees Dorst e Nigel Cross: "Creativity in the design process: co-evolution of problem-solution"
Il modello di co-evoluzione tra spazio dei problemi e spazio delle soluzioni è stato formalizzato in:
Maher, M L, Poon, J and Boulanger, S Formalising design exploration as co-evolution: a
combined gene approach, in Gero, J S and Sudweeks, F (eds.) Advances in Formal Design Methods for CAD, Chapman and Hall, London, UK (1996)
Uno studio interessante sul disegno creativo, di Kees Dorst e Nigel Cross: "Creativity in the design process: co-evolution of problem-solution"
Il modello di co-evoluzione tra spazio dei problemi e spazio delle soluzioni è stato formalizzato in:
Maher, M L, Poon, J and Boulanger, S Formalising design exploration as co-evolution: a
combined gene approach, in Gero, J S and Sudweeks, F (eds.) Advances in Formal Design Methods for CAD, Chapman and Hall, London, UK (1996)
You Tube e simili
Mi colpiscono soprattutto due cose:
1. che nessuno, mai, prima d'ora, neppure i centri informativi più ricchi che siano mai esistiti, ha mai avuto a disposizione questa varietà di registrazioni in tempi così rapidi. Possiamo vedere ciò che è stato trasmesso ieri dalle televisioni di tutto il mondo, ma possiamo anche vedere filmati realizzati da una miriade di produttori non professionali, con punti di vista eventualmente contradditori rispetto alle versioni degli eventi rese pubbliche dai governi e dalle fonti informative consolidate.
2. che nessuno, mai, prima d'ora, ha mai potuto vedere e ascoltare tante persone viventi o vissute. Posso vedere filmati di Nietzsche, del Mahatma Gandhi, di Jimi Hendrix, di qualunque personaggio pubblico di cui abbia mai sentito parlare che sia vissuto negli ultimi cento anni o più. Ascoltare le voci. Diventerà (è già diventato) normale, ma io, oggi, lo trovo impressionante.
1. che nessuno, mai, prima d'ora, neppure i centri informativi più ricchi che siano mai esistiti, ha mai avuto a disposizione questa varietà di registrazioni in tempi così rapidi. Possiamo vedere ciò che è stato trasmesso ieri dalle televisioni di tutto il mondo, ma possiamo anche vedere filmati realizzati da una miriade di produttori non professionali, con punti di vista eventualmente contradditori rispetto alle versioni degli eventi rese pubbliche dai governi e dalle fonti informative consolidate.
2. che nessuno, mai, prima d'ora, ha mai potuto vedere e ascoltare tante persone viventi o vissute. Posso vedere filmati di Nietzsche, del Mahatma Gandhi, di Jimi Hendrix, di qualunque personaggio pubblico di cui abbia mai sentito parlare che sia vissuto negli ultimi cento anni o più. Ascoltare le voci. Diventerà (è già diventato) normale, ma io, oggi, lo trovo impressionante.
Incremental Commitment Model
Barry Boehm e Jo Ann Lane: "Using the Incremental Commitment Model to Integrate System Acquisition, Systems Engineering, and Software Engineering", in CrossTalk, October 2007
Many projects have difficulties in integrating their hardware, software, and human factor aspects.
In comparison to the software-intensive RUP, the ICM also addresses hardware and human factor integration. It extends the RUP phases to cover the full system life cycle: An Exploration phase precedes the RUP Inception phase, which is refocused on valuation and investment analysis. The RUP Elaboration phase is refocused on architecting (a term based on describing concurrent development of requirements, architecture, and plans),
which adds feasibility evidence; the RUP Construction and Transition phases are combined into the Development phase; and an additional Operation phase combines
operations, production, maintenance, and phase-out. Also, the names of the milestones
are changed to emphasize that their objectives are to ensure stakeholder commitment
to proceed to the next level of resource expenditure based on a thorough feasibility and risk analysis, and not just on the existence of a set of system objectives and a set of architecture diagrams. Thus, the RUP Life-Cycle Objectives (LCO) milestone is called the Architecture Commitment Review (ACR) in the ICM, and the RUP Life-Cycle Architecture (LCA) milestone is called the Development Commitment Review (DCR).
In comparison to the sequential waterfall and V-model, the ICM explicitly does the following:
• Emphasizes concurrent engineering of requirements and solutions.
• Establishes feasibility rationales as pass/ fail milestone criteria.
• Enables risk-driven avoidance of unnecessary documents, phases, and reviews.
• Provides support for a stabilized current-increment development concurrently with a separate change processing and rebaselining activity to prepare for appropriate and stabilized development of the next increment.
Many projects have difficulties in integrating their hardware, software, and human factor aspects.
In comparison to the software-intensive RUP, the ICM also addresses hardware and human factor integration. It extends the RUP phases to cover the full system life cycle: An Exploration phase precedes the RUP Inception phase, which is refocused on valuation and investment analysis. The RUP Elaboration phase is refocused on architecting (a term based on describing concurrent development of requirements, architecture, and plans),
which adds feasibility evidence; the RUP Construction and Transition phases are combined into the Development phase; and an additional Operation phase combines
operations, production, maintenance, and phase-out. Also, the names of the milestones
are changed to emphasize that their objectives are to ensure stakeholder commitment
to proceed to the next level of resource expenditure based on a thorough feasibility and risk analysis, and not just on the existence of a set of system objectives and a set of architecture diagrams. Thus, the RUP Life-Cycle Objectives (LCO) milestone is called the Architecture Commitment Review (ACR) in the ICM, and the RUP Life-Cycle Architecture (LCA) milestone is called the Development Commitment Review (DCR).
In comparison to the sequential waterfall and V-model, the ICM explicitly does the following:
• Emphasizes concurrent engineering of requirements and solutions.
• Establishes feasibility rationales as pass/ fail milestone criteria.
• Enables risk-driven avoidance of unnecessary documents, phases, and reviews.
• Provides support for a stabilized current-increment development concurrently with a separate change processing and rebaselining activity to prepare for appropriate and stabilized development of the next increment.
Agile è troppo rigido...
Kunal Mittal Executive Director, IT, Sony Pictures Entertainment: The software development life cycle for Web 2.0. Realize the benefits of agile development.
"You've probably read about extreme programming, Scrum, and other agile development processes. To me, those are also probably too rigid [...] User stories, iterative development and releases, and a simple planning game are the key elements of your new process. It's also a good idea to include a quality assurance and testing cycle, as well as user-acceptance testing."
Secondo me, esagera. Ma è indicativo del fatto che l'approccio agile è ritenuto ormai consolidato.
18 giugno 2008
Google ci sta facendo diventare stupidi?
'Is Google Making Us Stupid?' è un articolo di Nicholas Carr, pubblicato su The Atlantic Online, July/August 2008.
Il titolo è ad effetto, ma il nostro istupidimento non è causato in modo specifico da Google. Il problema è "What the Internet is doing to our brain", le modifiche che Internet porta al nostro modo di apprendere e pensare.
Carr segnala, partendo dalla propria personale esperienza e da quella di altri utenti, che chi frequenta in modo sistematico la rete si abitua ad una modalità di apprendimento e di elaborazione del pensiero diverse rispetto a quelle a cui era abituato. Più frammentarie, meno riflessive. Per alcuni versi, il discorso rimanda a quello trattato trent'anni fa da Neil Postman (in Amusing Ourselves to Death - anche in italiano) sugli effetti del modello culturale visuale - pubblicitario - televisivo.
Il wiki e la civiltà
The Software Practitioner è una newsletter (a pagamento) curata da Robert Glass. Sul numero gratuito di maggio 2006, scaricabile come esempio, in fondo, c'è una storiella intrigante sul wiki e la civiltà, di Peter e Dorothy Denning.
Tecnologie di collaborazione
Peter Denning, Peter Yaholkovsky: 'Getting to "We". Solidarity, not software, generates collaboration.' in Communications of the ACM, April 2008.
'Collaboration occurs when a community creates a solution to a messy problem that takes care of all their concerns at the same time. Collaboration is an ideal achieved far less often than it is invoked. It is often confused with information sharing, cooperation, or coordination. Most of our “collaboration technologies” are actually tools for information sharing.
[...] Collaboration does not mean that you give up or compromise your dearest concerns. It means designing a solution that recognizes your concerns. The process often leads to a reconfiguration of everyone’s concerns. The hallmark of successful collaboration is the
experience of solidarity and new energy: a “we”.'
L'offshoring cresce
Charalambos L. Iacovou and Robbie Nakatsu: 'A Risk Profile of Offshore-Outsourced Development Projects' in Communications of the ACM, June 2008.
'According to Forrester Research, 65% of American and European enterprises (with 1,000 or more employees) currently use offshore providers for application development; another 13% plan to begin doing so in the next year. Two years ago, only 45% of such organizations utilized offshore vendors to develop applications.'
Lo sviluppo in team distribuiti a livello internazionale
Michael Cusumano: 'Managing Software Development in Globally Distributed Teams' in Communications of the ACM, February 2008.
Cusumano raccomanda uno sviluppo agile, basato su un contratto "iterativo" tra cliente e fornitore, con definizione progressiva dei requisiti e distribuzione guidata dalle scelte architetturali.
Nulla di nuovo e di rilevante, se non un segnale di quanto gli approcci agili siano ormai considerati come la base necessaria anche per lo sviluppo software distribuito.
L'insegnamento e le stringhe
Alistair Cockburn: Teaching is pushing a string; learning is pulling the string
People keep asking, "What is the difference between teaching and learning? What is the instructor's role? After years of noodling, here's what I end up with:
Teaching is putting various strings in front of the students to pull on. The role of the instructor is to select and lay out the strings, indicate something about the meaning of pulling on them, etc.
Learning is their pulling on any of those strings. The role of the student is to select some strings, pull on them, abstract/note something about what happens. The instructor can't really know which strings the student is pulling on, or what the student will learn/abstract/note.
Note that this applies to parenting as much as to teachers.
21 maggio 2008
Cosa leggere - Grandi libri
Stando così le cose in Italia, due problemi mi stanno particolarmente a cuore.
Prima di tutto, la sistematica sottovalutazione del merito e della competenza, che da trent'anni ci fa perdere competitività nel mondo.
Poi, la trasmissione del sapere. Che è un effetto della sottovalutazione del merito, come si vede dai meccanismi di selezione a livello di docenze universitarie, a livello di quadri politici, e di management in una parte consistente del settore pubblico. Ma che è anche una concausa del declino della competitività italiana. I paesi in cui si studia poco e male vanno sempre peggio, in una economia mondiale basata sulla conoscenza e sull'innovazione.
Cosa leggere. Nel sessantotto avevo dieci anni, ma il clima culturale degli anni seguenti vedeva con sospetto la tradizione, si amava piuttosto la rottura degli schemi. In quel contesto, la proposta di percorso culturale formulata da Mortimer Adler (negli Usa, prima metà del novecento) non mi era arrivata. E se fosse arrivata, l'avrei guardata con molto sospetto. Sbagliavo.
Adler proponeva un percorso di apprendimento basato sulla lettura dei Grandi Libri, in una certa sequenza. La scelta dei libri e della sequenza è certamente incompleta, e riflette uno specifico punto di vista (quello di Adler) e una specifica cultura (quella statunitense della prima metà del secolo scorso). Ma la lista di Adler ha tre vantaggi:
Prima di tutto, la sistematica sottovalutazione del merito e della competenza, che da trent'anni ci fa perdere competitività nel mondo.
Poi, la trasmissione del sapere. Che è un effetto della sottovalutazione del merito, come si vede dai meccanismi di selezione a livello di docenze universitarie, a livello di quadri politici, e di management in una parte consistente del settore pubblico. Ma che è anche una concausa del declino della competitività italiana. I paesi in cui si studia poco e male vanno sempre peggio, in una economia mondiale basata sulla conoscenza e sull'innovazione.
Cosa leggere. Nel sessantotto avevo dieci anni, ma il clima culturale degli anni seguenti vedeva con sospetto la tradizione, si amava piuttosto la rottura degli schemi. In quel contesto, la proposta di percorso culturale formulata da Mortimer Adler (negli Usa, prima metà del novecento) non mi era arrivata. E se fosse arrivata, l'avrei guardata con molto sospetto. Sbagliavo.
Adler proponeva un percorso di apprendimento basato sulla lettura dei Grandi Libri, in una certa sequenza. La scelta dei libri e della sequenza è certamente incompleta, e riflette uno specifico punto di vista (quello di Adler) e una specifica cultura (quella statunitense della prima metà del secolo scorso). Ma la lista di Adler ha tre vantaggi:
- fornisce una guida sintetica, che la scuola a miei tempi non dava in modo altrettanto efficace
- include testi sia "umanistici" che "scientifici", contribuendo a superare la distanza tra le due culture
- non contiene testi mediocri o scadenti.
Letteratura divertente
Sembra quasi un ossimoro (in questo caso, due parole che dicono una il contrario dell'altra).
Eppure esiste, in Italia, una letteratura divertente. Non solo quella lontana del tempo e considerata minore, dall'Ariosto in poi, che può essere difficile da leggere oggi perché la lingua è cambiata (almeno un po'). Esiste anche una letteratura italiana recente (del novecento) divertente. Achille Campanile, per fare un nome (ad esempio Gli asparagi e l'immortalità dell'anima, Vite di uomini illustri, Il povero Piero). O Ermanno Cavazzoni (es. Vite brevi di idioti).
La letteratura divertente esiste, ma non viene insegnata a scuola (ai miei tempi, negli anni settanta, non veniva neppure citata), né data da bere in televisione. L'unica è il passaparola.
Eppure esiste, in Italia, una letteratura divertente. Non solo quella lontana del tempo e considerata minore, dall'Ariosto in poi, che può essere difficile da leggere oggi perché la lingua è cambiata (almeno un po'). Esiste anche una letteratura italiana recente (del novecento) divertente. Achille Campanile, per fare un nome (ad esempio Gli asparagi e l'immortalità dell'anima, Vite di uomini illustri, Il povero Piero). O Ermanno Cavazzoni (es. Vite brevi di idioti).
La letteratura divertente esiste, ma non viene insegnata a scuola (ai miei tempi, negli anni settanta, non veniva neppure citata), né data da bere in televisione. L'unica è il passaparola.
16 maggio 2008
Lo saprò quando lo vedrò
Barry Boehm - Making a Difference in the Software Century
Un eccellente articolo su IEEE Computer, marzo 2008 (in realtà, si tratta di un estratto della introduzione scritta da Boehm per l'antologia dei propri scritti, pubblicata nel 2007 da IEEE CS Press-John Wiley & Sons ).
Riporto un paio di passi.
Il primo, sulla difficoltà per gli utenti di chiarire i requisiti in anticipo :
"Spesso, quando si chiede agli utenti di specificare come vorrebbero interagire con una nuova applicazione, essi rispondono “Lo saprò quando la vedrò” (IKIWISI - I’ll Know It When I See It). In questi casi, usare un modello a cascata sequenziale, specificare-prima-i-requisiti, diventa di solito la ricetta per un sistema inefficace e per un mucchio di costosi rifacimenti".
Il secondo, sul conflitto tra punti di vista ed interessi tra gli stakeholder di progetto:
"Il fatto che ci siano molti conflitti potenziali tra i principali stakeholder significa che il progetto può entrare in situazioni in cui uno vince e un altro perde. E una situazione del genere di solito diventa una situazione in cui perdono tutti.
In situazioni simili è importante gestire le aspettative degli stakeholder, lavorare di più per assicurare che la soluzione proposta sia fattibile e adeguata agli interessi di tutti, e negoziare un insieme globalmente soddisfacente e vantaggioso di specifiche, piani e risorse, prima di procedere con lo sviluppo. Quando si negoziano i requisiti, nei momenti iniziali è meglio sostituire termini che possono essere interpretati come non negoziabili, ad esempio il termine 'requisiti' (cose richieste con autorità e diritto) con parole come 'obiettivi' e 'scopi'."
07 maggio 2008
About us
aboutus.org è un'organizzazione che ha tra i suoi obiettivi il miglioramento dei servizi offerti dalle aziende su web, attraverso critiche costruttive e pubbliche da parte degli utenti.
L'ho scoperta perché attualmente vi lavora Ward Cunningham (tra le altre cose, ideatore dei Wiki e ispiratore di Extreme Programming), le cui iniziative sono normalmente da seguire con attenzione.
Potrebbe servire a diffondere anche in Italia la pratica della critica pubblica e costruttiva dei servizi web?
L'ho scoperta perché attualmente vi lavora Ward Cunningham (tra le altre cose, ideatore dei Wiki e ispiratore di Extreme Programming), le cui iniziative sono normalmente da seguire con attenzione.
Potrebbe servire a diffondere anche in Italia la pratica della critica pubblica e costruttiva dei servizi web?
28 aprile 2008
Being Your Own Boss
Watts Humprey è il padre del Software Engineering Institute e del Capability Maturity Model.
In una serie di cinque articoli, tratteggia l'atteggiamento mentale di sviluppatori e manager nei confronti dello sviluppo software.
1: The Ideal Job
2: The Autocratic manager
3: Knowledge Work
4: Being a Victim
5: Building Trust
In una serie di cinque articoli, tratteggia l'atteggiamento mentale di sviluppatori e manager nei confronti dello sviluppo software.
1: The Ideal Job
2: The Autocratic manager
3: Knowledge Work
4: Being a Victim
5: Building Trust
Legge di Conway
"Ogni organizzazione che progetti un sistema (sistemi informativi, e non solo) produrrà inevitabilmente un design la cui struttura è una copia della struttura comunicativa dell'organizzazione."
Melvin E. Conway “How Do Committees Invent?” Datamation 14(4), April 1968
In altri termini, esiste uno stretto rapporto tra l'organizzazione dello sviluppo e l'architettura dei sistemi che un'organizzazione produce.
Conoscevo la legge di Conway grazie agli Organizational Patterns of Agile Software Development di James Coplien e Neil Harrison, ma non avevo letto il testo originale di Melvin Conway, apparso nel 1968. Vale la pena farlo.
Melvin E. Conway “How Do Committees Invent?” Datamation 14(4), April 1968
In altri termini, esiste uno stretto rapporto tra l'organizzazione dello sviluppo e l'architettura dei sistemi che un'organizzazione produce.
Conoscevo la legge di Conway grazie agli Organizational Patterns of Agile Software Development di James Coplien e Neil Harrison, ma non avevo letto il testo originale di Melvin Conway, apparso nel 1968. Vale la pena farlo.
Patterns of Agile Adoption
Un articolo di Mike Cohn su Agile Journal delinea alcuni possibili percorsi per modificare il processo di sviluppo di un'organizzazione verso una maggiore agilità.
Cohn descrive tre coppie di alternative:
- partire con progetti pilota o intervenire contemporaneamente su tutti i progetti ("Start Small or go All In?")
- iniziare dalle pratiche agili più "tecniche" o partire dall'approccio iterativo ("Technical Practices First or Iterative First?")
- partire di nascosto o pubblicizzare in anticipo il cambiamento ("Stealth Mode or a Public Display of Agility?")
Per ognuna delle alternative, vengono elencati vantaggi e svantaggi.
10 aprile 2008
Usabilità ed esperienza utente
"Usability" e "user experience" sono espressioni diverse. La prima per qualcuno rimanda a problemi di forma, la seconda a problemi di sostanza. Ma non è così. Un intervento interessante al riguardo è stato pubblicato da Tom Stewart, il chair del gruppo di lavoro per l'aggiornamento dello standard ISO 13407 - the International Standard for Human Centred Design.
"The ISO concept of usability is much closer to this definition of user experience than it is to the concept of ‘easy to use’ so we have decided to use the term user experience in the new version of ISO 13407 (which will be called ISO 9241-210 to bring it into line with other
usability standards"
"The ISO concept of usability is much closer to this definition of user experience than it is to the concept of ‘easy to use’ so we have decided to use the term user experience in the new version of ISO 13407 (which will be called ISO 9241-210 to bring it into line with other
usability standards"
Scrum e pattern organizzativi
Un altro materiale interessante relativo a Scrum è stato prodotto da Jim Coplien. Coplien è, tra le altre cose, autore del testo fondamentale sui pattern organizzativi, cioè sui principi guida organizzativi per lo sviluppo software.
James Coplien, Neil Harrison: Organizational Patterns of Agile Software Development, Prentice-Hall 2005 (il titolo è purtroppo fuorviante, in quanto il testo non parla in specifico dei processi agili, ma dei pro e dei contro delle diverse modalità di organizzare lo sviluppo software).
A proposito di Scrum, è disponibile (sul sito di Jeff Sutherland, uno degli originatori di Scrum) una recente presentazione di Coplien che mappa Scrum ai pattern organizzativi, e ne evidenzia la necessità di un'adozione consapevole.
James Coplien, Neil Harrison: Organizational Patterns of Agile Software Development, Prentice-Hall 2005 (il titolo è purtroppo fuorviante, in quanto il testo non parla in specifico dei processi agili, ma dei pro e dei contro delle diverse modalità di organizzare lo sviluppo software).
A proposito di Scrum, è disponibile (sul sito di Jeff Sutherland, uno degli originatori di Scrum) una recente presentazione di Coplien che mappa Scrum ai pattern organizzativi, e ne evidenzia la necessità di un'adozione consapevole.
Scrum scalabile
Scrum è un processo agile nato per fare fronte in modo controllato a situazioni progettuali con requisiti poco determinati, e instabili. Dato che si tratta di situazioni progettuali comuni, Scrum si sta diffondendo.
Un articolo di Scott Ambler sottolinea la necessità di riflettere sulle modalità di adozione di Scrum nelle organizzazioni, sfruttandone i vantaggi ma senza dimenticare gli insegnamenti di decenni di storia dell'Information Technology e dello sviluppo software.
Un articolo di Scott Ambler sottolinea la necessità di riflettere sulle modalità di adozione di Scrum nelle organizzazioni, sfruttandone i vantaggi ma senza dimenticare gli insegnamenti di decenni di storia dell'Information Technology e dello sviluppo software.
Modernizzazione del software
Computerworld segnala l'offerta di servizi da parte di HP per la modernizzazione di applicazioni legacy. I servizi offerti si avvalgono di strumenti (non in vendita) che analizzano il codice e ne evidenziano su grafici le parti più bisognose di rifacimento o modifica. Tra i concorrenti di HP sul fronte della modernizzazione vengono citati IBM e Microfocus.
L'idea di modernizzazione del software è intrigante dal punto di vista di marketing e ancora di più dal punto di vista teorico.
L'idea di modernizzazione del software è intrigante dal punto di vista di marketing e ancora di più dal punto di vista teorico.
02 aprile 2008
Il mercato dei Database relazionali
Un articolo su Information Week fa il punto sulla diffusione dei principali database management system.
Vengono presi in esame prodotti commerciali e open source. La crescente diffusione dei DBMS open source non sembrerebbe intaccare le quote di mercato dei prodotti commerciali, e del resto il contesto dei DBMS open source è in movimento, particolarmente dopo l'acquisizione di MySql AB da parte di Sun.
Vengono presi in esame prodotti commerciali e open source. La crescente diffusione dei DBMS open source non sembrerebbe intaccare le quote di mercato dei prodotti commerciali, e del resto il contesto dei DBMS open source è in movimento, particolarmente dopo l'acquisizione di MySql AB da parte di Sun.
31 marzo 2008
CMMI + altri metodi e standard
Se si cerca la soluzione unica e definitiva ai problemi dello sviluppo e della gestione dei sistemi informatici, può capitare di pensare che CMMI (Capability Maturity Model Integration), ISO, ITIL, CoBIT, Six Sigma, lean, processi agili, ecc. siano tra loro alternativi. Non è così, afferma Mike Phillips del Software Engineering Institute, che chiarisce le relazioni tra i diversi approcci al miglioramento dell'IT.
Per analisi più dettagliate delle relazioni tra CMMI e altri approcci, un buon punto di partenza è questo.
Per analisi più dettagliate delle relazioni tra CMMI e altri approcci, un buon punto di partenza è questo.
L'analista (definizione di Karl Wiegers)
"Lo sviluppo dei requisiti è un’attività di esplorazione. L’analista non è un semplice scrivano che registra ciò che dicono i clienti. L’analista è un investigatore che pone domande per stimolare il ragionamento dei clienti, cercando di scoprire informazioni nascoste e di generare nuove idee."
Karl E. Wiegers: More About Software Requirements, Microsoft Press 2006.
Karl E. Wiegers: More About Software Requirements, Microsoft Press 2006.
Scegliere lo strumento giusto per la gestione dei requisiti - o forse nessuno
Selecting The Right Requirements Management Tool — Or Maybe None Whatsoever.
Un report di Forrester Research (Carey Schwaber e Peter Sterpe), del settembre 2007.
Riporto l'executive summary:
"Many of today’s requirements management tool purchases are misguided: Application development and program management professionals often buy requirements management tools for the wrong reasons and select tools that are out of line with their needs. To avoid purchasing tools that are more complex and more expensive than necessary, app dev organizations need to be realistic about the problems that a requirements management tool can address, the level of tooling that they require, and their ability to build and maintain tool integrations."
Nelle indicazioni finali, viene suggerito di prendere in considerazione strumenti integrati in una soluzione complessiva di ALM (Application Lifecycle Management), piuttosto che strumenti stand-alone, isolati.
Il report è scaricabile, previa registrazione, dal sito di Computerworld.
Un report di Forrester Research (Carey Schwaber e Peter Sterpe), del settembre 2007.
Riporto l'executive summary:
"Many of today’s requirements management tool purchases are misguided: Application development and program management professionals often buy requirements management tools for the wrong reasons and select tools that are out of line with their needs. To avoid purchasing tools that are more complex and more expensive than necessary, app dev organizations need to be realistic about the problems that a requirements management tool can address, the level of tooling that they require, and their ability to build and maintain tool integrations."
Nelle indicazioni finali, viene suggerito di prendere in considerazione strumenti integrati in una soluzione complessiva di ALM (Application Lifecycle Management), piuttosto che strumenti stand-alone, isolati.
Il report è scaricabile, previa registrazione, dal sito di Computerworld.
UML - Apogeo 2007 (recensione)
Autore: Enrico Amedeo
Titolo: UML. Imparare a descrivere sistemi orientati agli oggetti graficamente e in modo standard.
Editore: Apogeo. Anno edizione: 2007
Punti di forza:
Titolo: UML. Imparare a descrivere sistemi orientati agli oggetti graficamente e in modo standard.
Editore: Apogeo. Anno edizione: 2007
Punti di forza:
- Discreta copertura di UML, corredata da esempi Java. Utile per l'aggancio tra UML e gli aspetti di programmazione.
- Prezzo contenuto (7,50 euro)
- Alcune imprecisioni concettuali, (ad esempio il fatto che i diagrammi di sequenza consentano di descrivere il dettaglio dell'implementazione degli algoritmi).
- Parecchia attenzione ai dettagli, manca però qualche accenno all'uso di UML per la rappresentazione di alto livello dell'architettura del sistema.
UML pratico - Paravia 2007 (recensione)
Autori: Ernesto Damiani, Mauro Madravio, Andrea Bőhm
Titolo: UML pratico. Con elementi di ingegneria del software. 2a edizione.
Editore: Paravia Bruno Mondadori Editori. Anno edizione: 2007
Titolo: UML pratico. Con elementi di ingegneria del software. 2a edizione.
Editore: Paravia Bruno Mondadori Editori. Anno edizione: 2007
Punti di forza:
- Introduzione generalissima a varie tematiche relative allo sviluppo software, tra cui UML. Forse valida come primo approccio all'ingegneria del software, ma solo in ambito universitario.
Punti di debolezza:
- Sulle 150 pagine, solo 50 circa parlano di UML. Diagrammi di attività, stato, package, componenti e deployment sono condensati in 10 pagine. Il livello è davvero elementare.
- UML 2 non è trattato, nonostante la data di pubblicazione sia il 2007, se non in un appendice di 2 pagine copiata quasi integralmente da un mio articolo (non citato).
Elenco strumenti gestione requisiti
Pubblicato da Incose (International Council on Systems Engineering). Utile.
Consente un confronto delle caratteristiche dei diversi strumenti di gestione requisiti. Con riferimenti ai siti dei produttori, che hanno la responsabilità delle dichiarazioni pubblicate (la cui attendibilità, pertanto, è tutta da verificare) e del loro aggiornamento.
Consente un confronto delle caratteristiche dei diversi strumenti di gestione requisiti. Con riferimenti ai siti dei produttori, che hanno la responsabilità delle dichiarazioni pubblicate (la cui attendibilità, pertanto, è tutta da verificare) e del loro aggiornamento.
Le iniziative metriche durano poco
Secondo Ed Yourdon, solo il 10% circa delle iniziative intraprese dalle organizzazioni per impiantare un sistema metrico in ambito software ha una durata superiore ai 18 mesi.
Perché? I motivi, secondo Yourdon, sono principalmente legati ai conflitti politici interni alle organizzazioni.
Perché? I motivi, secondo Yourdon, sono principalmente legati ai conflitti politici interni alle organizzazioni.
Previsioni a partire dai function point
In un intervento sulla mailing list requirements-engineering, Capers Jones, un'autorità nelle statistiche relative allo sviluppo software, ha fornito queste indicazioni:
"Function point size raised to the 0.4 power gives a useful prediction of
development schedules in calendar months. (Agile projects should use the 0.34
power).
Function point size raised to the 1.25 power gives a useful and alarming
prediction of the probable number of bugs that will be encountered.
Function point size raised to the 1.2 power predicts numbers of test cases
needed.
Function point size divided by 150 predicts development team size."
"Function point size raised to the 0.4 power gives a useful prediction of
development schedules in calendar months. (Agile projects should use the 0.34
power).
Function point size raised to the 1.25 power gives a useful and alarming
prediction of the probable number of bugs that will be encountered.
Function point size raised to the 1.2 power predicts numbers of test cases
needed.
Function point size divided by 150 predicts development team size."
Software Quality Requirements
Il numero di IEEE Software di Marzo-Aprile 2008 ha come tema centrale la gestione dei requisiti di qualità.
Tra gli spunti, un confronto tra Tom Gilb e Alistair Cockburn sulla precisazione i requisiti. Gilb sostiene l'esigenza di quantificare, Cockburn ritiene che in un contesto agile non sia il caso di farlo, e che in alcuni casi possa risultare dannoso.
A differenza di quanto normalmente accade, l'esito del confronto non è per nulla conciliatorio, segno di un contrasto profondo tra i rispettivi punti di vista.
Tra gli spunti, un confronto tra Tom Gilb e Alistair Cockburn sulla precisazione i requisiti. Gilb sostiene l'esigenza di quantificare, Cockburn ritiene che in un contesto agile non sia il caso di farlo, e che in alcuni casi possa risultare dannoso.
A differenza di quanto normalmente accade, l'esito del confronto non è per nulla conciliatorio, segno di un contrasto profondo tra i rispettivi punti di vista.
Planguage
Tom Gilb – Competitive Engineering. A Handbook for Systems Engineering, Requirements Engineering, and Software Engineering using Planguage. - Elsevier 2005
È un testo pesante, faticoso. Però vale la pena faticare, perché Planguage è un linguaggio con costrutti utili per precisare i requisiti.
È un testo pesante, faticoso. Però vale la pena faticare, perché Planguage è un linguaggio con costrutti utili per precisare i requisiti.
IBM e Telelogic
L'acquisizione di Telelogic da parte di una società controllata di IBM non si è ancora completata, ma è in via di conclusione. Da verificare le ricadute sui prodotti nell'area della gestione requisiti (Doors e Requisite(Pro) e del visual modeling UML (Tau, Rational Architect e Rational Modeler).
CrossTalk, marzo 2008
Nel numero di marzo 2008 di CrossTalk ("The Journal of Defense Software Engineering", la rivista software dei militari USA), tra le altre cose:
- Un articolo di Ellen Gottesdiener su "Good Practices for Developing User Requirements". L'aspetto più interessante è un elenco di modelli utilizzabili per rappresentare i requisiti utente.
- Un articolo di David Coe che riporta dati sperimentali, per quanto in ambito universitario, sull'uso degli Use Case Points.
- Un articolo di Ellen Gottesdiener su "Good Practices for Developing User Requirements". L'aspetto più interessante è un elenco di modelli utilizzabili per rappresentare i requisiti utente.
- Un articolo di David Coe che riporta dati sperimentali, per quanto in ambito universitario, sull'uso degli Use Case Points.
Il cliente - Mahatma Gandhi
Nell'inserto speciale dell'Economist sull'e-government, una citazione del Mahatma Gandhi:
"Who is the customer? The customer is the most important visitor on our premises. He is not dependent on us. We are dependent on him. He is not an interruption of our work. He is the purpose of it. He is not an outsider in our business, he is part of it. We are not doing him a favour by serving him. He is doing us a favour by giving us an opportunity to do so."
La citazione è tratta da un discorso tenuto da Gandhi in Sudafrica, dove svolse attività come avvocato negli anni tra il 1893 ed il 1895.
"Who is the customer? The customer is the most important visitor on our premises. He is not dependent on us. We are dependent on him. He is not an interruption of our work. He is the purpose of it. He is not an outsider in our business, he is part of it. We are not doing him a favour by serving him. He is doing us a favour by giving us an opportunity to do so."
La citazione è tratta da un discorso tenuto da Gandhi in Sudafrica, dove svolse attività come avvocato negli anni tra il 1893 ed il 1895.
E-government: successi ed insuccessi
Inserto speciale in The Economist del 16 febbraio 2008 su tecnologie e governo. Particolarmente interessante un articolo sugli investimenti nel settore della sanità nel Regno Unito.
L'importanza delle parole
Un eccellente (non è una novità) intervento di Gerry McGovern , esperto di gestione dei contenuti (content management), che sottolinea quanto sia decisiva l'importanza della comunicazione testuale per il successo di una iniziativa sul web.
La storia degli inizi di Rational
Descritta nel suo blog da Grady Booch. Rational è stata una delle società leader nel mondo dell'object oriented e del visual modeling, ed è nota soprattutto per essere all'origine dell'Unified Modeling Language (UML). Rational è stata acquisita 5 anni fa da IBM.
Informatici in Italia
Dalla newsletter AICA (Associazione Italiana per il Calcolo Automatico) n.23 di Novembre-Dicembre 2007, leggo che :
"Sul portale della Borsa Nazionale del Lavoro è stata attivata la sezione dedicata al Settore ICT che consentirà agli oltre 1,3 milioni di specialisti informatici del nostro Paese di orientarsi e aggiornarsi nello scenario particolarmente mutevole del settore fornendo informazioni specifiche, strumenti e servizi utili ai professionisti ICT. "
La notizia è interessante, ma se il numero degli specialisti informatici in Italia è questo, come è possibile che a livello di pubblica opinione, di politica e di relazioni di lavoro si parli così poco di questo milione ed oltre di persone?
"Sul portale della Borsa Nazionale del Lavoro è stata attivata la sezione dedicata al Settore ICT che consentirà agli oltre 1,3 milioni di specialisti informatici del nostro Paese di orientarsi e aggiornarsi nello scenario particolarmente mutevole del settore fornendo informazioni specifiche, strumenti e servizi utili ai professionisti ICT. "
La notizia è interessante, ma se il numero degli specialisti informatici in Italia è questo, come è possibile che a livello di pubblica opinione, di politica e di relazioni di lavoro si parli così poco di questo milione ed oltre di persone?
La partecipazione degli utenti ai progetti
Erica L. Wagner and Gabriele Piccoli:"Moving Beyond User Participation to Achieve Successful IS Design" in Communications of the ACM, december 2007
L'articolo mette in luce con estrema chiarezza uno dei nodi principali dello sviluppo software.
"We suggest that rather than fighting human nature by trying to force the participation of user groups throughout a project, we should broaden our thinking about development and implementation methodologies to reflect what happens in practice. We find that in practice user participation can be most powerful after ‘go live’ when users are truly engaged.
[...] we acknowledge it will be difficult to fully engage users before the software begins to affect their daily lives, which are generally at ‘go live.’ Yet, we are not suggesting there is no value in user involvement via prototyping or phased roll-out techniques. When properly implemented, these techniques can help increase communication, provide some valuable feedback in the design process, and generally improve goodwill on the user side. But it is critical to recognize that trying to force engagement of user groups throughout a project goes against human nature. We should therefore expand our thinking about the stages of the systems development life cycle, and incorporate this broadened perspective into whichever methodology is used.
We need to recognize that implementation extends beyond “flipping the switch.” Legitimizing the post-implementation activities that are often kept as a shameful secret — a sign of project failure — will help to manage expectations and avoid much of the conflict that erodes trust between the user community, project champions, and the development team by more naturally mimicking human behavior.
[...] It is time to speak honestly about the gap between our intentions to build working systems and our ability to do so in practice. This gap is typically not caused by a lack of effort on behalf of developers or users, but rather is the result of misdirected efforts. The systems development and implementation process will continue to be overly challenging if we work against the tide by trying to make users fit our theories of how and when they should participate in development initiatives."
L'articolo mette in luce con estrema chiarezza uno dei nodi principali dello sviluppo software.
"We suggest that rather than fighting human nature by trying to force the participation of user groups throughout a project, we should broaden our thinking about development and implementation methodologies to reflect what happens in practice. We find that in practice user participation can be most powerful after ‘go live’ when users are truly engaged.
[...] we acknowledge it will be difficult to fully engage users before the software begins to affect their daily lives, which are generally at ‘go live.’ Yet, we are not suggesting there is no value in user involvement via prototyping or phased roll-out techniques. When properly implemented, these techniques can help increase communication, provide some valuable feedback in the design process, and generally improve goodwill on the user side. But it is critical to recognize that trying to force engagement of user groups throughout a project goes against human nature. We should therefore expand our thinking about the stages of the systems development life cycle, and incorporate this broadened perspective into whichever methodology is used.
We need to recognize that implementation extends beyond “flipping the switch.” Legitimizing the post-implementation activities that are often kept as a shameful secret — a sign of project failure — will help to manage expectations and avoid much of the conflict that erodes trust between the user community, project champions, and the development team by more naturally mimicking human behavior.
[...] It is time to speak honestly about the gap between our intentions to build working systems and our ability to do so in practice. This gap is typically not caused by a lack of effort on behalf of developers or users, but rather is the result of misdirected efforts. The systems development and implementation process will continue to be overly challenging if we work against the tide by trying to make users fit our theories of how and when they should participate in development initiatives."
Sondaggio sul Business Process Management
Business Process Trends ha pubblicato il sondaggio "The State of BPM - 2008", con risposte ottenute a fine 2007. Per quanto sondaggi di questo tipo siano poco scientifici, alcuni dati sui trend sono interessanti.
Per scaricare il sondaggio è necessaria una registrazione al sito.
Per scaricare il sondaggio è necessaria una registrazione al sito.
CMMI e processi agili
Un sondaggio curato da Scott Ambler per la Dr. Dobb's Agile Newsletter.
Inoltre, una serie di articoli sui processi adeguati per i progetti brevi sul numero di febbraio 2008 di CrossTalk, the Journal of Defense Software Engineering. Tra cui un articolo di Capers Jones che mette in rapporto CMMI e processi agili.
Inoltre, una serie di articoli sui processi adeguati per i progetti brevi sul numero di febbraio 2008 di CrossTalk, the Journal of Defense Software Engineering. Tra cui un articolo di Capers Jones che mette in rapporto CMMI e processi agili.
Casi d'uso e requisiti non funzionali
Casi d'uso per requisiti non (strettamente) funzionali. Alistair Cockburn riporta un esempio di caso d'uso per il richiamo di un servizio in ambito SOA.
Intervista al CEO di Infosys
Intervista al CEO di Infosys, la maggiore software house indiana, su Information Week. Aspettative crescenti dei clienti sull'outsourcing, esperienza e formazione degli sviluppatori indiani, differenze culturali.
Mega e BPMN
MEGA integrerà, nella proprie soluzioni per la modellazione dei processi e per l’enterprise architecture, l’ultima versione degli standard di Business Process Modeling Notation (BPMN™).
La MEGA Modeling Suite con l’ultima versione degli standard BPMN sarà disponibile nel corso del primo trimestre 2008.
La MEGA Modeling Suite con l’ultima versione degli standard BPMN sarà disponibile nel corso del primo trimestre 2008.
Costo e produttività delle risorse umane
Martin Fowler discute il legame fra talento, produttività e costo nello sviluppo software. Di come, cioè, avvalersi della collaborazione di risorse relativamente più costose possa comportare vantaggi sotto il profilo economico.
07 gennaio 2008
Un consiglio sentimentale
Da Ward Cunningham, sulla mailing list software testing. Cunningham è, tra le altre cose, ideatore del Wiki, di FIT - Framework for Integrated Testing, e di Extreme Programming. Ecco il consiglio:
'I have found that the world is the way it is for reasons very different from those often given as explanation. If you want to change the world, you need to understand all the forces that apply, and especially forces that are in flux. Then you stand a chance.
I don't, however, recommend that you debug your spouse. An old and wise friend of mine, who is still married to his high school sweetheart, says, "you have to decide, do you want to be right? or do you want to be loved?" '
'I have found that the world is the way it is for reasons very different from those often given as explanation. If you want to change the world, you need to understand all the forces that apply, and especially forces that are in flux. Then you stand a chance.
I don't, however, recommend that you debug your spouse. An old and wise friend of mine, who is still married to his high school sweetheart, says, "you have to decide, do you want to be right? or do you want to be loved?" '
23 dicembre 2007
Italia e competenza
La salvaguardia degli interessi consolidati, dei clan e dei privilegi è in conflitto con la valorizzazione del merito e della competenza individuali.
Accade in tutto il mondo. Nei paesi vitali, la valorizzazione del merito e delle competenze (nella scuola e nel mondo del lavoro) trainano l'economia e la società. In Italia, come nel terzo mondo, di solito la difesa dei privilegi e l'appartenenza a un clan hanno la meglio.
La percezione diffusa in Italia è che studiare sia inutile, e che lavorare con coscienza, professionalità e impegno non produca alcun beneficio per chi lo fa. Ecco perché l'Italia scivola nel terzo mondo.
Accade in tutto il mondo. Nei paesi vitali, la valorizzazione del merito e delle competenze (nella scuola e nel mondo del lavoro) trainano l'economia e la società. In Italia, come nel terzo mondo, di solito la difesa dei privilegi e l'appartenenza a un clan hanno la meglio.
La percezione diffusa in Italia è che studiare sia inutile, e che lavorare con coscienza, professionalità e impegno non produca alcun beneficio per chi lo fa. Ecco perché l'Italia scivola nel terzo mondo.
Il pianeta dove scomparivano le cose
Roberto Casati e Achille Varzi: Il pianeta dove scomparivano le cose. Esercizi di immaginazione filosofica. Einaudi 2006 .
Per bambini, e non solo. Stimolante nei temi, semplice e colloquiale nei toni, accompagnato da disegnini elementari e simpatici. Da non perdere.
Anche: Roberto Casati e Achille Varzi: Semplicità insormontabili. 39 storie filosofiche. Laterza 2004
Per bambini, e non solo. Stimolante nei temi, semplice e colloquiale nei toni, accompagnato da disegnini elementari e simpatici. Da non perdere.
Anche: Roberto Casati e Achille Varzi: Semplicità insormontabili. 39 storie filosofiche. Laterza 2004
27 novembre 2007
Testi di storia dell'informatica
Su Mondo Digitale settembre 2007 (rivista dell'AICA) c'è un articolo di Corrado Bonfanti "Corsi di Storia dell'Informatica nelle università italiane".
Cita i testi di storia dell'informatica più utilizzati dai docenti:
Letture consigliate: le più gettonate
Opere che i docenti hanno suggerito a chi volesse approfondire.
Il numero di ❑ indica il rispettivo score.
❑ ❑ ❑ ❑ M.R. Williams: A History of Computing Technology. Prentice-Hall, 1985.
Trad.it. [possibilmente da evitare!] Storia dei computer. Dall’abaco ai calcolatori elettronici. Franco Muzzio, 1989.
❑ ❑ W. Aspray (editor): Computing Before Computers. Iowa State University Press, 1990.
❑ ❑ P.E. Ceruzzi: A History of Modern Computing. The MIT Press, 2003 (2nd ed.).
Trad.it. Storia dell’informatica: dai primi computer digitali all’era di internet. Apogeo, 2006.
❑ ❑ M. Davis: The Universal Computer – The road from Leibniz to Turing; 2000.
Trad.it. Il calcolatore universale: da Leibniz a Turing. Adelphi, 2004.
❑ M. Calvo, F. Ciotti, G. Roncaglia, M.A. Zela: Internet 2004. Laterza, 2003.
❑ M. Campbell-Kelly, W. Aspray: Computer: A History of the Information Machine. Basic Books - HarperCollins Publishers, 1996.
❑ A.D. Chandler: Inventing the Electronic Century. The Free Press, 2001.
Trad.it. La rivoluzione elettronica. Egea - Università Bocconi editore, 2003.
❑ G. Ifrah: Histoire universelle des Chiffres. Éditions Seghers, 1981.
Trad.it. Storia universale dei numeri. Arnoldo Mondadori, 1983.
❑ M. Morelli: Dalle calcolatrici ai computer degli anni cinquanta. Franco Angeli, 2001.
❑ R.W. Sebesta: Concepts of Programming Languages. Addison-Wesley, 2006 (7th ed.).
Cita i testi di storia dell'informatica più utilizzati dai docenti:
Letture consigliate: le più gettonate
Opere che i docenti hanno suggerito a chi volesse approfondire.
Il numero di ❑ indica il rispettivo score.
❑ ❑ ❑ ❑ M.R. Williams: A History of Computing Technology. Prentice-Hall, 1985.
Trad.it. [possibilmente da evitare!] Storia dei computer. Dall’abaco ai calcolatori elettronici. Franco Muzzio, 1989.
❑ ❑ W. Aspray (editor): Computing Before Computers. Iowa State University Press, 1990.
❑ ❑ P.E. Ceruzzi: A History of Modern Computing. The MIT Press, 2003 (2nd ed.).
Trad.it. Storia dell’informatica: dai primi computer digitali all’era di internet. Apogeo, 2006.
❑ ❑ M. Davis: The Universal Computer – The road from Leibniz to Turing; 2000.
Trad.it. Il calcolatore universale: da Leibniz a Turing. Adelphi, 2004.
❑ M. Calvo, F. Ciotti, G. Roncaglia, M.A. Zela: Internet 2004. Laterza, 2003.
❑ M. Campbell-Kelly, W. Aspray: Computer: A History of the Information Machine. Basic Books - HarperCollins Publishers, 1996.
❑ A.D. Chandler: Inventing the Electronic Century. The Free Press, 2001.
Trad.it. La rivoluzione elettronica. Egea - Università Bocconi editore, 2003.
❑ G. Ifrah: Histoire universelle des Chiffres. Éditions Seghers, 1981.
Trad.it. Storia universale dei numeri. Arnoldo Mondadori, 1983.
❑ M. Morelli: Dalle calcolatrici ai computer degli anni cinquanta. Franco Angeli, 2001.
❑ R.W. Sebesta: Concepts of Programming Languages. Addison-Wesley, 2006 (7th ed.).
10 novembre 2007
Refactoring
da IEEE Software, Sep/Oct 2007, J.B.Rainsberger a pag. 27:
"You already need to refactor your system, but there's never a good time to start refactoring, so start now."
"You already need to refactor your system, but there's never a good time to start refactoring, so start now."
Avvocati
da Hernando De Soto - The Mistery of Capital. Why Capitalism Triumphs in the West and Fails Everywhere Else - Basic Books 2000, p. 199
"Using economic data from fifty-two countries from 1960 to 1980, Samar K. Datta and Jefferey B. Nugent have shown that for every percentage point increase in the number of lawyers in the labor force (from, say, 0.5 to 1.5 percent), economic growth is reduced by 4.76 to 3.68 percent - thus showing that economic growth is inversely related to the prudence of lawyers."
"Using economic data from fifty-two countries from 1960 to 1980, Samar K. Datta and Jefferey B. Nugent have shown that for every percentage point increase in the number of lawyers in the labor force (from, say, 0.5 to 1.5 percent), economic growth is reduced by 4.76 to 3.68 percent - thus showing that economic growth is inversely related to the prudence of lawyers."
07 novembre 2007
Due punti come separatore
Ancora Alessandro Manzoni citato nel libro di Gensini, questa volta da un testo del 1868, "Dell'unità della lingua e dei mezzi di diffonderla".
"Ci pare di dover distinguere i mezzi che sarebbe fattibile di mettere in pratica, anche senza attendere la formazione del nuovo vocabolario, da quegli altri che, di necessità, devono seguirne la pubblicazione.
I primi sarebbero: insegnanti di Toscana, nel maggior numero possibile, o anche educati in Toscana, da mandarsi nelle scuole primarie delle diverse province; esclusivamente toscani, ove ce ne sia, per le cattedre di lingua nelle scuole magistrali e normali:
Alcuni sussidi, sui fondi appositi iscritti per le scuole primarie nel bilancio del Ministero dell'istruzione pubblica, da assegnarsi a que' Comuni che si provvedessero di maestri nati od educati in Toscana:
Conferenze tra l'anno, od anche solo ne' mesi autunnali, nelle quali de' maestri e delle maestre di Toscana si rechino nelle varie province, per intrattenere i maestri e le maestre delle scuole primarie in letture di libri classici e di libri moderni (pezzi opportunamente scelti) notando gli arcaismi dei primi, e sostituendo le locuzioni dell'uso, avvertendo i provincialismi, i neologismi inutili de' secondi, colla stessa sostituzione:
Persone competenti, delegate nelle città capoluoghi dalla primaria magistratura, ed ufizialmente, che rivedano non solo qualunque iscrizione, avviso, od insegna devasi esporre in pubblico, ma anche le notizie che gli uffici regi o municipali forniscono ai giornalisti, per le loro cronache quotidiane:
Abbecedari, catechismi e primi libri di lettura nelle scuole, scritti o almeno riveduti da Toscani, sempre colla mira di cercare la diffusione della lingua viva:
Dare, come premio, a qualche allievo ed allieva delle scuole normali e magistrali, che ne abbiano fornito il corso con profitto e segni d'eminente capacità, il mezzo di passare un'annata scolastica in Firenze, per farci la pratica in una delle migliori scuole primarie:
Raccomandare ai membri de' corpi scientifici, quando la trattazione delle materie essenziali ne concedesse loro il tempo, di determinare fra loro le norme per una concorde e costante nomenclatura in que' rami scientifici che sono più accessibili al pubblico, come la storia naturale, la meccanica, la matallurgia, ecc.
I mezzi di diffusione poi, i quali dovrebbero seguire la pubblicazione del nuovo vocabolario sarebbero:
Provvedere che tutte le scuole governative, cos' dette secondarie, abbiano per ciascuna classe, degli esemplari del nuovo vocabolario, in quantità proporzionata al numero degli alunni:
Curare che del vocabolario si faccia anche un'edizione la più economica possibile, per renderne facile l'acquisto a ciascuno scolare:
Avere, per le scuole elementari ed anche per le scuole tecniche, de' piccoli vocabolari domestici d'arti e mestieri, compilati sul nuovo vocabolario della lingua, e alcuni, anche, figurati:
Dare in premio, nelle diverse scuole, insieme ad un'opera di bona letteratura, una copia del vocabolario, od anche, secondo la scuola, de' piccoli vocabolari che ne sono estratti:
Cercare che, anche in tutte le scuole femminili, i libri i più elementari sieno raccomandati o prescritti in modo che si diffonda sempre più, nelle città e nelle campagne, la cognizione della bona lingua viva, affinché si giunga così, a poco a poco, a renderla nota e familiare anche ai bambini."
"Ci pare di dover distinguere i mezzi che sarebbe fattibile di mettere in pratica, anche senza attendere la formazione del nuovo vocabolario, da quegli altri che, di necessità, devono seguirne la pubblicazione.
I primi sarebbero: insegnanti di Toscana, nel maggior numero possibile, o anche educati in Toscana, da mandarsi nelle scuole primarie delle diverse province; esclusivamente toscani, ove ce ne sia, per le cattedre di lingua nelle scuole magistrali e normali:
Alcuni sussidi, sui fondi appositi iscritti per le scuole primarie nel bilancio del Ministero dell'istruzione pubblica, da assegnarsi a que' Comuni che si provvedessero di maestri nati od educati in Toscana:
Conferenze tra l'anno, od anche solo ne' mesi autunnali, nelle quali de' maestri e delle maestre di Toscana si rechino nelle varie province, per intrattenere i maestri e le maestre delle scuole primarie in letture di libri classici e di libri moderni (pezzi opportunamente scelti) notando gli arcaismi dei primi, e sostituendo le locuzioni dell'uso, avvertendo i provincialismi, i neologismi inutili de' secondi, colla stessa sostituzione:
Persone competenti, delegate nelle città capoluoghi dalla primaria magistratura, ed ufizialmente, che rivedano non solo qualunque iscrizione, avviso, od insegna devasi esporre in pubblico, ma anche le notizie che gli uffici regi o municipali forniscono ai giornalisti, per le loro cronache quotidiane:
Abbecedari, catechismi e primi libri di lettura nelle scuole, scritti o almeno riveduti da Toscani, sempre colla mira di cercare la diffusione della lingua viva:
Dare, come premio, a qualche allievo ed allieva delle scuole normali e magistrali, che ne abbiano fornito il corso con profitto e segni d'eminente capacità, il mezzo di passare un'annata scolastica in Firenze, per farci la pratica in una delle migliori scuole primarie:
Raccomandare ai membri de' corpi scientifici, quando la trattazione delle materie essenziali ne concedesse loro il tempo, di determinare fra loro le norme per una concorde e costante nomenclatura in que' rami scientifici che sono più accessibili al pubblico, come la storia naturale, la meccanica, la matallurgia, ecc.
I mezzi di diffusione poi, i quali dovrebbero seguire la pubblicazione del nuovo vocabolario sarebbero:
Provvedere che tutte le scuole governative, cos' dette secondarie, abbiano per ciascuna classe, degli esemplari del nuovo vocabolario, in quantità proporzionata al numero degli alunni:
Curare che del vocabolario si faccia anche un'edizione la più economica possibile, per renderne facile l'acquisto a ciascuno scolare:
Avere, per le scuole elementari ed anche per le scuole tecniche, de' piccoli vocabolari domestici d'arti e mestieri, compilati sul nuovo vocabolario della lingua, e alcuni, anche, figurati:
Dare in premio, nelle diverse scuole, insieme ad un'opera di bona letteratura, una copia del vocabolario, od anche, secondo la scuola, de' piccoli vocabolari che ne sono estratti:
Cercare che, anche in tutte le scuole femminili, i libri i più elementari sieno raccomandati o prescritti in modo che si diffonda sempre più, nelle città e nelle campagne, la cognizione della bona lingua viva, affinché si giunga così, a poco a poco, a renderla nota e familiare anche ai bambini."
Alessandro Manzoni e l'ingegno
"I doni dell'ingegno non si acquistano, come lo indica il nome stesso; ma tutto ciò che lo studio, che la diligenza possono dare, non istarebbe certamente per me ch'io non lo acquistassi."
è dalla seconda Introduzione (1823) a "Fermo e Lucia".
Riportato da Stefano Gensini, "Breve storia dell'educazione linguistica dall'Unità ad oggi", Carocci 2005. Tra l'altro, il libro tratta il difficile e tormentato processo che ha portato all'adozione generalizzata di una lingua italiana unitaria a partire dai dialetti. Molte affinità con il processo che stiamo vivendo in direzione di un'adozione generalizzata della lingua inglese.
è dalla seconda Introduzione (1823) a "Fermo e Lucia".
Riportato da Stefano Gensini, "Breve storia dell'educazione linguistica dall'Unità ad oggi", Carocci 2005. Tra l'altro, il libro tratta il difficile e tormentato processo che ha portato all'adozione generalizzata di una lingua italiana unitaria a partire dai dialetti. Molte affinità con il processo che stiamo vivendo in direzione di un'adozione generalizzata della lingua inglese.
Education: how to be top
Economist, October 20th 2007, p.74-75
"What works in education: the lessons according to McKinsey
There are big variations in educational standards between countries. These have been measured and re-measured by the OECD's Programme for International Student Assessment (PISA) which has established, first, that the best performing countries do much better than the worst and, second, that the same countries head such league tables again and again: Canada, Finland, Japan, Singapore, South Korea.
Those findings raise what ought to be a fruitful question: what do the successful lot have in common? Yet the answer to that has proved surprisingly elusive. Not more money. Singapore spends less per student than most. Nor more study time. Finnish students begin school later, and study fewer hours, than in other rich countries.
Now, an organisation from outside the teaching fold—McKinsey, a consultancy that advises companies and governments—has boldly gone where educationalists have mostly never gone: into policy recommendations based on the PISA findings. Schools, it says*, need to do three things: get the best teachers; get the best out of teachers; and step in when pupils start to lag behind. That may not sound exactly “first-of-its-kind” (which is how Andreas Schleicher, the OECD's head of education research, describes McKinsey's approach): schools surely do all this already? Actually, they don't. If these ideas were really taken seriously, they would change education radically.
Begin with hiring the best. There is no question that, as one South Korean official put it, “the quality of an education system cannot exceed the quality of its teachers.” Studies in Tennessee and Dallas have shown that, if you take pupils of average ability and give them to teachers deemed in the top fifth of the profession, they end up in the top 10% of student performers; if you give them to teachers from the bottom fifth, they end up at the bottom. The quality of teachers affects student performance more than anything else.
[...] Teaching the teachers
Having got good people, there is a temptation to shove them into classrooms and let them get on with it. For understandable reasons, teachers rarely get much training in their own classrooms (in contrast, doctors do a lot of training in hospital wards). But successful countries can still do much to overcome the difficulty.
Singapore provides teachers with 100 hours of training a year and appoints senior teachers to oversee professional development in each school. In Japan and Finland, groups of teachers visit each others' classrooms and plan lessons together. In Finland, they get an afternoon off a week for this. In Boston, which has one of America's most improved public-school systems, schedules are arranged so that those who teach the same subject have free classes together for common planning. This helps spread good ideas around. As one educator remarked, “when a brilliant American teacher retires, almost all of the lesson plans and practices that she has developed also retire. When a Japanese teacher retires, she leaves a legacy.”
[...] But there is a pattern in what countries do once pupils and schools start to fail. The top performers intervene early and often. Finland has more special-education teachers devoted to laggards than anyone else—as many as one teacher in seven in some schools. In any given year, a third of pupils get one-on-one remedial lessons. Singapore provides extra classes for the bottom 20% of students and teachers are expected to stay behind—often for hours—after school to help students.
None of this is rocket science. Yet it goes against some of the unspoken assumptions of education policy. Scratch a teacher or an administrator (or a parent), and you often hear that it is impossible to get the best teachers without paying big salaries; that teachers in, say, Singapore have high status because of Confucian values; or that Asian pupils are well behaved and attentive for cultural reasons. McKinsey's conclusions seem more optimistic: getting good teachers depends on how you select and train them; teaching can become a career choice for top graduates without paying a fortune; and that, with the right policies, schools and pupils are not doomed to lag behind.
"What works in education: the lessons according to McKinsey
There are big variations in educational standards between countries. These have been measured and re-measured by the OECD's Programme for International Student Assessment (PISA) which has established, first, that the best performing countries do much better than the worst and, second, that the same countries head such league tables again and again: Canada, Finland, Japan, Singapore, South Korea.
Those findings raise what ought to be a fruitful question: what do the successful lot have in common? Yet the answer to that has proved surprisingly elusive. Not more money. Singapore spends less per student than most. Nor more study time. Finnish students begin school later, and study fewer hours, than in other rich countries.
Now, an organisation from outside the teaching fold—McKinsey, a consultancy that advises companies and governments—has boldly gone where educationalists have mostly never gone: into policy recommendations based on the PISA findings. Schools, it says*, need to do three things: get the best teachers; get the best out of teachers; and step in when pupils start to lag behind. That may not sound exactly “first-of-its-kind” (which is how Andreas Schleicher, the OECD's head of education research, describes McKinsey's approach): schools surely do all this already? Actually, they don't. If these ideas were really taken seriously, they would change education radically.
Begin with hiring the best. There is no question that, as one South Korean official put it, “the quality of an education system cannot exceed the quality of its teachers.” Studies in Tennessee and Dallas have shown that, if you take pupils of average ability and give them to teachers deemed in the top fifth of the profession, they end up in the top 10% of student performers; if you give them to teachers from the bottom fifth, they end up at the bottom. The quality of teachers affects student performance more than anything else.
[...] Teaching the teachers
Having got good people, there is a temptation to shove them into classrooms and let them get on with it. For understandable reasons, teachers rarely get much training in their own classrooms (in contrast, doctors do a lot of training in hospital wards). But successful countries can still do much to overcome the difficulty.
Singapore provides teachers with 100 hours of training a year and appoints senior teachers to oversee professional development in each school. In Japan and Finland, groups of teachers visit each others' classrooms and plan lessons together. In Finland, they get an afternoon off a week for this. In Boston, which has one of America's most improved public-school systems, schedules are arranged so that those who teach the same subject have free classes together for common planning. This helps spread good ideas around. As one educator remarked, “when a brilliant American teacher retires, almost all of the lesson plans and practices that she has developed also retire. When a Japanese teacher retires, she leaves a legacy.”
[...] But there is a pattern in what countries do once pupils and schools start to fail. The top performers intervene early and often. Finland has more special-education teachers devoted to laggards than anyone else—as many as one teacher in seven in some schools. In any given year, a third of pupils get one-on-one remedial lessons. Singapore provides extra classes for the bottom 20% of students and teachers are expected to stay behind—often for hours—after school to help students.
None of this is rocket science. Yet it goes against some of the unspoken assumptions of education policy. Scratch a teacher or an administrator (or a parent), and you often hear that it is impossible to get the best teachers without paying big salaries; that teachers in, say, Singapore have high status because of Confucian values; or that Asian pupils are well behaved and attentive for cultural reasons. McKinsey's conclusions seem more optimistic: getting good teachers depends on how you select and train them; teaching can become a career choice for top graduates without paying a fortune; and that, with the right policies, schools and pupils are not doomed to lag behind.
28 settembre 2007
18 settembre 2007
Tyler Cowen - How to work and play a little better
The Economist, September 8th 2007
Mr Cowen is a professor of economics at George Mason University in Fairfax, Virgina, and a co-owner of marginalrevolution.com, one of the best economics blogs on the internet.
“Discover Your Inner Economist” joins a recent school of books demystifying and popularising economics that began with Steven Landsburg's “Armchair Economist” in 1993, and conquered the bestseller lists in 2005 with “Freakonomics” by Steven Levitt and Stephen Dubner. It stands apart from its predecessors by making its revelations not so much about the way the world works as about the way we ourselves work (and play) and how we can take practical steps to do both better.
Tyler Cowen: Discover Your Inner Economist: Use Incentives to Fall in Love, Survive Your Next Meeting, and Motivate Your Dentist - Dutton 2007
Mr Cowen is a professor of economics at George Mason University in Fairfax, Virgina, and a co-owner of marginalrevolution.com, one of the best economics blogs on the internet.
“Discover Your Inner Economist” joins a recent school of books demystifying and popularising economics that began with Steven Landsburg's “Armchair Economist” in 1993, and conquered the bestseller lists in 2005 with “Freakonomics” by Steven Levitt and Stephen Dubner. It stands apart from its predecessors by making its revelations not so much about the way the world works as about the way we ourselves work (and play) and how we can take practical steps to do both better.
Tyler Cowen: Discover Your Inner Economist: Use Incentives to Fall in Love, Survive Your Next Meeting, and Motivate Your Dentist - Dutton 2007
Lustiger, cardinale cattolico, ed ebreo
From The Economist, Aug 16th 2007
Aaron Jean-Marie Lustiger, cardinale di Parigi, ebreo di origini polacche; sua madre morì ad Auschwitz.
AT THE funeral of Jean-Marie Lustiger, at Notre Dame de Paris on August 10th, his second cousin Jonas Moses-Lustiger read a psalm in Hebrew and placed on the coffin a jar of earth that had been gathered on the Mount of Olives. Then another cousin, Arno Lustiger, bent over the coffin to recite Kaddish. Only when those things were done was the body of Cardinal Lustiger carried inside the cathedral, where Catholic panoply took over.
There was no question of mixing the rites; the cardinal, said his staff, would not have liked that. Yet they were mixed in himself. He was a Jew by birth, instinct, emotion and devotion; he was a Catholic by conversion and conviction. He cracked Jewish jokes, and put on a suit and kippa to go to synagogue, although the evening would find him in his soutane again. For him, Christianity was simply the fruit of Judaism; his first religion came to completion in his second. Christ, in his eyes, was the Messiah of Israel, his cross worthy of a yellow star. And since the mission of Israel was “to bring light to the goyim”, preaching the gospel became his own mitzvah.
Every detail of his funeral, with its two rites, he carefully arranged himself. Then he wrote his epitaph:
I was born Jewish. I received the name of my paternal grandfather, Aaron. Having become Christian by faith and baptism, I have remained Jewish. As did the Apostles.
Aaron Jean-Marie Lustiger, cardinale di Parigi, ebreo di origini polacche; sua madre morì ad Auschwitz.
AT THE funeral of Jean-Marie Lustiger, at Notre Dame de Paris on August 10th, his second cousin Jonas Moses-Lustiger read a psalm in Hebrew and placed on the coffin a jar of earth that had been gathered on the Mount of Olives. Then another cousin, Arno Lustiger, bent over the coffin to recite Kaddish. Only when those things were done was the body of Cardinal Lustiger carried inside the cathedral, where Catholic panoply took over.
There was no question of mixing the rites; the cardinal, said his staff, would not have liked that. Yet they were mixed in himself. He was a Jew by birth, instinct, emotion and devotion; he was a Catholic by conversion and conviction. He cracked Jewish jokes, and put on a suit and kippa to go to synagogue, although the evening would find him in his soutane again. For him, Christianity was simply the fruit of Judaism; his first religion came to completion in his second. Christ, in his eyes, was the Messiah of Israel, his cross worthy of a yellow star. And since the mission of Israel was “to bring light to the goyim”, preaching the gospel became his own mitzvah.
Every detail of his funeral, with its two rites, he carefully arranged himself. Then he wrote his epitaph:
I was born Jewish. I received the name of my paternal grandfather, Aaron. Having become Christian by faith and baptism, I have remained Jewish. As did the Apostles.
11 settembre 2007
The Chimera of Software Quality
by Les Hatton, in IEEE Computer, August 2007.
"Nobody knows how to produce a fault-free program. Nobody even knows how to prove it even supposing one we were magically provided. I teach my students that in their whole careers, they are unlikely ever to produce a fault-free program and if they did, they would never know it, they could never prove it and they could not systematically repeat it. It provides a usefully humble starting point.
[...] I've analysed enough failed systems in my time to know that there are two classic symptoms of a system on its way to the fairies. First, no independent audit is allowed and second, talking heads tell you everything is fine when the ultimate users tell you the opposite.
[...] The Linux kernel is now arguably the most reliable complex software application
humanity race has yet produced, with a mean time between failures reported in tens and in some cases, hundreds of years. Poetically, the development environment of Linux, which leverages the contributions of thousands of Web volunteers who give their spare time for the public good, breaks just about every rule which software process experts hold dear."
"Nobody knows how to produce a fault-free program. Nobody even knows how to prove it even supposing one we were magically provided. I teach my students that in their whole careers, they are unlikely ever to produce a fault-free program and if they did, they would never know it, they could never prove it and they could not systematically repeat it. It provides a usefully humble starting point.
[...] I've analysed enough failed systems in my time to know that there are two classic symptoms of a system on its way to the fairies. First, no independent audit is allowed and second, talking heads tell you everything is fine when the ultimate users tell you the opposite.
[...] The Linux kernel is now arguably the most reliable complex software application
humanity race has yet produced, with a mean time between failures reported in tens and in some cases, hundreds of years. Poetically, the development environment of Linux, which leverages the contributions of thousands of Web volunteers who give their spare time for the public good, breaks just about every rule which software process experts hold dear."
20 agosto 2007
Parnas on abstractions
Communications of the ACM, June 2007, p.7
"Use the Simplest Model, But Not Too Simple
Jeff Kramer's view, expressed in his article "Is Abstraction the Key to Computing?" (Apr. 2007), that abstraction is indeed a key concept in computing, especially in software design, is correct but far from new. It's a lesson I learned from the late E.W. Dijkstra 40 years ago and underlies every software development method proposed since then. Dijkstra said many useful things. Among them is the most useful definition of "abstraction" I know: "An abstraction is one thing that represents several real things equally well." This positive definition is more useful than the more typical ones Kramer quoted that emphasize the elimination of information. Dijkstra's clarifies what must remain.
Dijkstra's definition allows us to distinguish between an abstraction and a lie. When a model makes assumptions that are not true of a real object (such as infinite memory), these assumptions are often defended by saying "It is an abstraction." Using Dijkstra's definition, such models are not abstractions. Rather than represent several things equally well, they represent nothing at all. Because they embody unrealistic assumptions, one cannot trust the conclusions that might be drawn from them.
Models that are not abstractions in Dijkstra's sense may provide insight or understanding but can also mislead. Programs based on them may not work, and theories based on them may yield results not relevant in the real world.
Many computer science courses fail to teach students how to develop abstractions because they use models that are not abstractions but lies. Students must be taught the implications of an idea often attributed to Albert Einstein: "Everything should be as simple as possible but not simpler." Finding the simplest model that is not a lie is the key to better software design."
David Lorge Parnas
Limerick, Ireland
"Use the Simplest Model, But Not Too Simple
Jeff Kramer's view, expressed in his article "Is Abstraction the Key to Computing?" (Apr. 2007), that abstraction is indeed a key concept in computing, especially in software design, is correct but far from new. It's a lesson I learned from the late E.W. Dijkstra 40 years ago and underlies every software development method proposed since then. Dijkstra said many useful things. Among them is the most useful definition of "abstraction" I know: "An abstraction is one thing that represents several real things equally well." This positive definition is more useful than the more typical ones Kramer quoted that emphasize the elimination of information. Dijkstra's clarifies what must remain.
Dijkstra's definition allows us to distinguish between an abstraction and a lie. When a model makes assumptions that are not true of a real object (such as infinite memory), these assumptions are often defended by saying "It is an abstraction." Using Dijkstra's definition, such models are not abstractions. Rather than represent several things equally well, they represent nothing at all. Because they embody unrealistic assumptions, one cannot trust the conclusions that might be drawn from them.
Models that are not abstractions in Dijkstra's sense may provide insight or understanding but can also mislead. Programs based on them may not work, and theories based on them may yield results not relevant in the real world.
Dijkstra's work showed that two distinct skills are related to abstractions:
- Being able to work with a given abstraction; and
- Being able to develop a useful abstraction.
Many computer science courses fail to teach students how to develop abstractions because they use models that are not abstractions but lies. Students must be taught the implications of an idea often attributed to Albert Einstein: "Everything should be as simple as possible but not simpler." Finding the simplest model that is not a lie is the key to better software design."
David Lorge Parnas
Limerick, Ireland
30 maggio 2007
The Sarbanes-Oxley Act: implications for large-scale IT outsourcing
James A. Hall, Stephen L. Liedtka, "The Sarbanes-Oxley Act: implications for large-scale IT outsourcing", Comm ACM 03-2007
"Until they are certain that outsourcing IT management is the best possible option, firms would do well to maintain and invest in their own in-house IT assets.
[...]
Two sections of SOX are especially important to corporate IT departments:
Section 404. Called “Management Assessment of Internal Controls,” it mandates that corporate CEOs implement internal controls over their financial reporting systems, physically test these controls, and certify in writing that they function correctly. As a practical matter, the vast majority of controls are embedded in computer technologies that involve virtually
all of an organization’s financial transaction processing systems; and
Section 302. Called “Corporate Responsibility for Incident Reports,” it requires senior financial executives to disclose deficiencies in internal controls and fraud (whether material or not). Also, public accounting firms must attest in their audit opinions to the adequacy
and function of their client firms’ internal controls. Prior to SOX, auditing standards required
auditors only to be “familiar” with internal controls.
[...]
While large-scale IT outsourcing may appear to be a way to address the costs of SOX compliance, outsourcing contracts can actually increase the likelihood that a firm will fail to
comply with both the detail and the spirit of SOX.
Specifically, large-scale IT outsourcing increases the risk that top management and boards of directors will be unable to fulfill their oversight duties; that firms will employ ineffective internal controls over financial statements; that financial reports will be inaccurate
and/or misleading; and that firms will fail to protect shareholder wealth.
[...]
Finally, we note that an outsourcing client’s competitive success depends on the vendor’s ability to perform. Electronic Data Systems Corp. (EDS) has demonstrated the potential for vendor failures to have drastic, perhaps unforeseeable, financial repercussions.
EDS has struggled due to a variety of factors, including its own financial reporting failures and the bankruptcies of two of its largest customers—WorldCom and US Airways. In order to cut costs, EDS terminated 7,000 employees, which affected its ability to serve its clients. Following an 11-year low in share prices in 2002, EDS stockholders filed a class-action
lawsuit against the company. Vendors experiencing such serious financial and legal problems clearly threaten the viability of their strategic partners, as well as their ability to maintain internal controls and completely and accurately present financial information."
"Until they are certain that outsourcing IT management is the best possible option, firms would do well to maintain and invest in their own in-house IT assets.
[...]
Two sections of SOX are especially important to corporate IT departments:
Section 404. Called “Management Assessment of Internal Controls,” it mandates that corporate CEOs implement internal controls over their financial reporting systems, physically test these controls, and certify in writing that they function correctly. As a practical matter, the vast majority of controls are embedded in computer technologies that involve virtually
all of an organization’s financial transaction processing systems; and
Section 302. Called “Corporate Responsibility for Incident Reports,” it requires senior financial executives to disclose deficiencies in internal controls and fraud (whether material or not). Also, public accounting firms must attest in their audit opinions to the adequacy
and function of their client firms’ internal controls. Prior to SOX, auditing standards required
auditors only to be “familiar” with internal controls.
[...]
While large-scale IT outsourcing may appear to be a way to address the costs of SOX compliance, outsourcing contracts can actually increase the likelihood that a firm will fail to
comply with both the detail and the spirit of SOX.
Specifically, large-scale IT outsourcing increases the risk that top management and boards of directors will be unable to fulfill their oversight duties; that firms will employ ineffective internal controls over financial statements; that financial reports will be inaccurate
and/or misleading; and that firms will fail to protect shareholder wealth.
[...]
Finally, we note that an outsourcing client’s competitive success depends on the vendor’s ability to perform. Electronic Data Systems Corp. (EDS) has demonstrated the potential for vendor failures to have drastic, perhaps unforeseeable, financial repercussions.
EDS has struggled due to a variety of factors, including its own financial reporting failures and the bankruptcies of two of its largest customers—WorldCom and US Airways. In order to cut costs, EDS terminated 7,000 employees, which affected its ability to serve its clients. Following an 11-year low in share prices in 2002, EDS stockholders filed a class-action
lawsuit against the company. Vendors experiencing such serious financial and legal problems clearly threaten the viability of their strategic partners, as well as their ability to maintain internal controls and completely and accurately present financial information."
The effects of online advertising
Scott McCoy, Andrea Everard, Peter Polak, Dennis F. Galletta: The effects of online advertising, Comm ACM 03-2007
"Our findings suggest that advertisements do have significant effects on retention of the site. Also, advertising content that is non-congruent with the site’s content seems to lead to greater effort in reconciling the differing content, and ultimately greater memory of both the Web site and the advertisement. Intrusiveness is also important for both Web site designers and advertisers. Pop-ups and pop-unders seem to be more intrusive than in-line ads, implying
that users should not be interrupted from their online tasks to close the extraneous windows.
[...]
Designers should realize the magnitude of ill effects caused by advertising.
Although some of the differences were not large in magnitude, reducing the likelihood of a person’s return by 11% might be a cost that is too great for a site host to bear. Discovering that pop-up and in-line ads differ greatly in measures of intrusiveness, a host might play it safe and make use of in-line ads. As theory and practice begin to converge in this area, perhaps
what has been described so often as a wild new frontier might finally take a few steps toward being tamed."
"Our findings suggest that advertisements do have significant effects on retention of the site. Also, advertising content that is non-congruent with the site’s content seems to lead to greater effort in reconciling the differing content, and ultimately greater memory of both the Web site and the advertisement. Intrusiveness is also important for both Web site designers and advertisers. Pop-ups and pop-unders seem to be more intrusive than in-line ads, implying
that users should not be interrupted from their online tasks to close the extraneous windows.
[...]
Designers should realize the magnitude of ill effects caused by advertising.
Although some of the differences were not large in magnitude, reducing the likelihood of a person’s return by 11% might be a cost that is too great for a site host to bear. Discovering that pop-up and in-line ads differ greatly in measures of intrusiveness, a host might play it safe and make use of in-line ads. As theory and practice begin to converge in this area, perhaps
what has been described so often as a wild new frontier might finally take a few steps toward being tamed."
Theoretical Reflections on Agile Development Methodologies
Sridhar Nerur e VenuGopal Balijepally, "Theoretical Reflections on Agile Development Methodologies", Comm ACM 03-2007 . Con una lista di riferimenti eccellente.
"The progression of thought in software development parallels the maturation of design ideas in architecture and strategic management. The traditional mechanistic worldview is today being challenged by a newer agile perspective that accords primacy to uniqueness, ambiguity,
complexity, and change, as opposed to prediction, verifiability, and control. The goal of optimization is being replaced by flexibility and responsiveness.
[...]
The tenets of agile methods depart from the traditional orthodoxy of software development. This shift in philosophy is not unusual, as similar patterns of intellectual evolution have emerged in other disciplines. A look at architecture and strategic management reveals that
the progression of ideas in them is remarkably similar to conceptual pattern shifts in software design."
"The progression of thought in software development parallels the maturation of design ideas in architecture and strategic management. The traditional mechanistic worldview is today being challenged by a newer agile perspective that accords primacy to uniqueness, ambiguity,
complexity, and change, as opposed to prediction, verifiability, and control. The goal of optimization is being replaced by flexibility and responsiveness.
[...]
The tenets of agile methods depart from the traditional orthodoxy of software development. This shift in philosophy is not unusual, as similar patterns of intellectual evolution have emerged in other disciplines. A look at architecture and strategic management reveals that
the progression of ideas in them is remarkably similar to conceptual pattern shifts in software design."
21 aprile 2007
Management Theory - Rhythm and blues
Economist, March 31st 2007
"Employees may be reluctant to admit this, but managers should take heed: teams that like each other also seem to work better together".
(a partire da una riflessione sulla composizione dei ggruppi di voga nelle regate annuali che contrappongono Oxford a Cambridge).
"Employees may be reluctant to admit this, but managers should take heed: teams that like each other also seem to work better together".
(a partire da una riflessione sulla composizione dei ggruppi di voga nelle regate annuali che contrappongono Oxford a Cambridge).
Iscriviti a:
Post (Atom)