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".
29 novembre 2008
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)
Iscriviti a:
Post (Atom)