Fornire valore agli stakeholder (le parti interessate al rilascio di un prodotto) è ciò che si chiede allo sviluppo software.
Ma le specifiche dei requisiti spesso dettagliano solo i dettagli sulle funzionalità, anziché affrontare in modo diretto gli interessi degli stakeholder e chiarire ciò che per gli stakeholder è davvero importante.
"What's Fundamentally Wrong? Improving our Approach Towards Capturing Value in Requirements Specification", un articolo di Tom Gilb con Lindsey Brodie, su Requirements Network (per leggerlo, serve una registrazione gratuita).
Visualizzazione post con etichetta software. Mostra tutti i post
Visualizzazione post con etichetta software. Mostra tutti i post
30 agosto 2010
29 giugno 2010
Tecno austerità
"Meno è meglio".
"I tecnologi si stanno risvegliando ai vantaggi del minimalismo, per due motivi: il fastidio per l'eccessivo numero di funzionalità dei prodotti da parte dei clienti che vogliono solo che le cose funzionino, e una forte richiesta da parte di clienti meno ricchi provenienti dai paesi in via di sviluppo."
The Economist, 12 giugno 2010.
"I tecnologi si stanno risvegliando ai vantaggi del minimalismo, per due motivi: il fastidio per l'eccessivo numero di funzionalità dei prodotti da parte dei clienti che vogliono solo che le cose funzionino, e una forte richiesta da parte di clienti meno ricchi provenienti dai paesi in via di sviluppo."
The Economist, 12 giugno 2010.
26 maggio 2010
Giochi per la formazione IT
Il mio interesse per il software è scaturito, trent'anni fa, quando mi è stato presentato un problema da risolvere con un flow chart, e mi ha appassionato come i giochi della Settimana Enigmistica.
L'uso dei giochi per la formazione sta forse crescendo: "Puzzle-Based learning for Engineering and Computer Science", su IEEE Computer, April 2010. (In inglese, i puzzle non sono solo i giochi in cui si incastrano le tesserine, ma anche tutti i giochi logici, linguistici, enigmistici, matematici.)
L'uso dei giochi per la formazione sta forse crescendo: "Puzzle-Based learning for Engineering and Computer Science", su IEEE Computer, April 2010. (In inglese, i puzzle non sono solo i giochi in cui si incastrano le tesserine, ma anche tutti i giochi logici, linguistici, enigmistici, matematici.)
15 aprile 2010
Testing SOA
Il Software Engineering Institute (SEI) ha pubblicato un report sul testing in architetture Service Oriented (SOA).
Il report comprende 65 raccomandazioni per affrontare i problemi specifici delle architetture SOA.
Il report comprende 65 raccomandazioni per affrontare i problemi specifici delle architetture SOA.
Chaos Report 2009
Il Chaos Report è una fonte informativa molto citata sulle percentuali di successo dei progetti di sviluppo software. Ha una copertura di migliaia di progetti internazionali, in vari settori merceologici.
L'edizione 2009, pubblicata come sempre da Standish Group, indica un significativo peggioramento rispetto ai report precedenti.
32% di successo (progetti completati nei tempi e nei costi previsti, con le funzioni previste).
44% di successo o insuccesso parziale (progetti in ritardo, costi extra, meno funzioni di quanto richiesto).
24% di fallimento (progetti cancellati o che hanno prodotto sistemi mai usati).
"I risultati di quest'anno rappresentano il più alto tasso di fallimento nell'ultimo decennio", secondo lo Standish Group.
L'edizione 2009, pubblicata come sempre da Standish Group, indica un significativo peggioramento rispetto ai report precedenti.
32% di successo (progetti completati nei tempi e nei costi previsti, con le funzioni previste).
44% di successo o insuccesso parziale (progetti in ritardo, costi extra, meno funzioni di quanto richiesto).
24% di fallimento (progetti cancellati o che hanno prodotto sistemi mai usati).
"I risultati di quest'anno rappresentano il più alto tasso di fallimento nell'ultimo decennio", secondo lo Standish Group.
12 marzo 2010
Metodi formali di sviluppo software
Perché i metodi formali di sviluppo software, sovente amati nel mondo accademico, non hanno avuto successo nel mondo reale?
Il motivo non è una presunta scarsa professionalità degli sviluppatori, ma il fatto che i metodi formali non sono adeguati per l'uso in ambiti operativi:
"Reports that formal methods are ready for industrial use must be taken with a grain of salt; if they were ready, their use would be widespread."
E il motivo non è neppure una presunta mancanza di fondi per la ricerca:
"More money is not the answer. [...] Research in formal methods for software development has been very well funded. More money won't help; more thinking will."
Sono affermazioni di David Parnas, uno tra i più autorevoli teorici del mondo del software.
David Lodge Parnas: "Really Rethinking 'Formal Methods'", in IEEE Computer, January 2010.
Il motivo non è una presunta scarsa professionalità degli sviluppatori, ma il fatto che i metodi formali non sono adeguati per l'uso in ambiti operativi:
"Reports that formal methods are ready for industrial use must be taken with a grain of salt; if they were ready, their use would be widespread."
E il motivo non è neppure una presunta mancanza di fondi per la ricerca:
"More money is not the answer. [...] Research in formal methods for software development has been very well funded. More money won't help; more thinking will."
Sono affermazioni di David Parnas, uno tra i più autorevoli teorici del mondo del software.
David Lodge Parnas: "Really Rethinking 'Formal Methods'", in IEEE Computer, January 2010.
21 gennaio 2010
Automation Paradox
"when a Metro subway train rammed into another train in Washington, D.C. last June, designers had to confront the unpleasant reality that automation may have been the cause.
The accident, which killed nine people and injured 80, may have been rooted in a computer malfunction and the operator’s inability to manually apply the brakes quickly enough.
The Metro train accident lies at the heart of what human factors experts refer to as the “automation paradox.” As automated systems become increasingly reliable and efficient, the more likely it is that human operators will mentally “switch off” and rely upon the automated system. And as the automated system becomes more complex, the odds of an accident or mishap may
diminish, but the severity of a failure is often amplified."
"Making Automation Work", di Samuel Greengard, in Communications of the ACM, dicembre 2009
The accident, which killed nine people and injured 80, may have been rooted in a computer malfunction and the operator’s inability to manually apply the brakes quickly enough.
The Metro train accident lies at the heart of what human factors experts refer to as the “automation paradox.” As automated systems become increasingly reliable and efficient, the more likely it is that human operators will mentally “switch off” and rely upon the automated system. And as the automated system becomes more complex, the odds of an accident or mishap may
diminish, but the severity of a failure is often amplified."
"Making Automation Work", di Samuel Greengard, in Communications of the ACM, dicembre 2009
24 dicembre 2009
Contesto, requisiti, architettura
Tra i rischi che impattano sulle architetture software due sono particolarmente rilevanti:
- la definizione dei confini del sistema (cioè del contesto, delle relazioni del sistema con altri sistemi esterni)
- la vaghezza o la mancata definizione dei requisiti non funzionali
Self-Management dei gruppi di lavoro
"The basic work unit in innovative software organizations is the team rather than the individual."
Uno studio relativo ai problemi che incontrano i gruppi di lavoro auto-organizzati nell'ambito dello sviluppo software, effettuato su 5 gruppi di lavoro in 3 organizzazioni, per la durata di tre anni, da un gruppo di ricercatori norvegesi.
Lo studio si è concentrato sia su problemi ingenerati all'interno dei gruppi di lavoro, sia su problemi derivanti dalla cultura e dai comportamenti organizzativi.
Alcune raccomandazioni conclusive:
Uno studio relativo ai problemi che incontrano i gruppi di lavoro auto-organizzati nell'ambito dello sviluppo software, effettuato su 5 gruppi di lavoro in 3 organizzazioni, per la durata di tre anni, da un gruppo di ricercatori norvegesi.
Lo studio si è concentrato sia su problemi ingenerati all'interno dei gruppi di lavoro, sia su problemi derivanti dalla cultura e dai comportamenti organizzativi.
Alcune raccomandazioni conclusive:
- Formare le persone anche su temi non strettamente legati al loro ruolo
- Collocare il gruppo in un'unica stanza
- Valorizzare i generalisti
- Far crescere la fiducia e la responsabilizzaazione
- Assegnare le persone a un solo progetto per volta.
Documentazione agile
"In other engineering disciplines, the need to produce design documentation is considered de rigeur, a sometimes unpleasant but necessary chore for the sake of higher good. [...]
The primary consumers of design documentation are those who are responsible for maintaining and evolving the system.
[...] we need design documentation at a higher level of abstraction, stripped of unnecessary technological detail and closely coupled to application concepts and requirements. These should incorporate design rationale, including descriptions
of rejected design alternatives. These are, in fact, architectural specifications: technology-independent descriptions of the higher-level structure and behavior of systems along with key design principles."
Bran Selic, Agile Documentation, Anyone?, in IEEE Software, nov/dec 2009.
The primary consumers of design documentation are those who are responsible for maintaining and evolving the system.
[...] we need design documentation at a higher level of abstraction, stripped of unnecessary technological detail and closely coupled to application concepts and requirements. These should incorporate design rationale, including descriptions
of rejected design alternatives. These are, in fact, architectural specifications: technology-independent descriptions of the higher-level structure and behavior of systems along with key design principles."
Bran Selic, Agile Documentation, Anyone?, in IEEE Software, nov/dec 2009.
Scratch: programmazione per bambini
Scratch è un linguaggio di programmazione pensato per i bambini.
Per chi lo usa (anche per gli adulti), è molto divertente, e permette di fare un sacco di cose interessanti.
Dal punto di vista tecnico è potente: il MIT (Massachusetts Institute of Technology) Media Lab ha realizzato un eccellente linguaggio didattico.
Su Communications of the ACM, novembre 2009, un articolo di presentazione da parte degli autori (scaricabile ma a pagamento per i non soci ACM).
Altri articoli su Scratch (gratis).
Per chi lo usa (anche per gli adulti), è molto divertente, e permette di fare un sacco di cose interessanti.
Dal punto di vista tecnico è potente: il MIT (Massachusetts Institute of Technology) Media Lab ha realizzato un eccellente linguaggio didattico.
Su Communications of the ACM, novembre 2009, un articolo di presentazione da parte degli autori (scaricabile ma a pagamento per i non soci ACM).
Altri articoli su Scratch (gratis).
Silos nei sistemi IT bancari
http://www.economist.com/businessfinance/displaystory.cfm?story_id=15016132
La mancata integrazione degli applicativi ha creato e continuerà a creare problemi per le banche.
La mancata integrazione degli applicativi ha creato e continuerà a creare problemi per le banche.
23 novembre 2009
Software sviluppato dagli utenti
La distinzione tra utenti e sviluppatori software sta rapidamente svanendo, scrivono Gerhard Fischer, Kumiyo Nakakoji e Yunwen Ye su IEEE Software, September/October 2009.
"Crediamo che gli esperti di dominio, cioè coloro che hanno i problemi, debbano farsi carico di svilupparsi il software che serve loro. [...]
The World Wide Web’s short history provides convincing evidence of the quick dissolution of the sharp distinction of design and use. In the Web’s
first decade, a clear separation between developers and users was predominant, in which users used whatever professional Web developers gave them.
As we enter the Web 2.0 era, we’re witnessing a much richer ecology of user participation. Users now also participate in various development activities
that continuously evolve Web applications through adoption, adaptation, appropriation, and mashing-up of existing Web systems."
"Crediamo che gli esperti di dominio, cioè coloro che hanno i problemi, debbano farsi carico di svilupparsi il software che serve loro. [...]
The World Wide Web’s short history provides convincing evidence of the quick dissolution of the sharp distinction of design and use. In the Web’s
first decade, a clear separation between developers and users was predominant, in which users used whatever professional Web developers gave them.
As we enter the Web 2.0 era, we’re witnessing a much richer ecology of user participation. Users now also participate in various development activities
that continuously evolve Web applications through adoption, adaptation, appropriation, and mashing-up of existing Web systems."
25 settembre 2009
Review architetturali
Un survey sui modi in cui vengono effettuate le revisioni architetturali nelle aziende:
Muhammad Ali Babar, Ian Gorton: "Software Architecture Review: The State of Practice", in IEEE Computer, 07/2009.
Alcuni risultati. Per lo più, le revisioni architetturali:
Muhammad Ali Babar, Ian Gorton: "Software Architecture Review: The State of Practice", in IEEE Computer, 07/2009.
Alcuni risultati. Per lo più, le revisioni architetturali:
- avvengono in modo informale e non sistematico
- non vedono coinvolti esperti esterni all'organizzazione
- vengono svolte solo nelle fasi iniziali dei progetti, non durante la realizzazione effettiva
Modello Metropoli
Proposto da Rick Kazman e Hong-Mei Chen, come modello di sviluppo software distinto rispetto ai modelli waterfall, evolutivo ed agile.
Il modello Metropoli è adatto a progetti di sviluppo di sistemi "crowdsourced", cioè quelli in cui il ruolo del contributo di volontari è fondamentale. Due categorie principali:
"The Metropolis Model. A New Logic for Development of Crowdsourced Systems", in Communications of the ACM, 07/2009.
Il modello Metropoli è adatto a progetti di sviluppo di sistemi "crowdsourced", cioè quelli in cui il ruolo del contributo di volontari è fondamentale. Due categorie principali:
- prodotti open source, come Linux, Apache, Firefox, ecc.
- "community-based service systems", come Wikipedia, YouTube, Facebook, ecc.
"The Metropolis Model. A New Logic for Development of Crowdsourced Systems", in Communications of the ACM, 07/2009.
Free Software e Open Source
Anche se quasi sempre i prodotti "open source" sono disponibili gratuitamente, si tratta di due filosofie ben distinte. Lo ribadisce Richard Stallman, padre della Open Software Foundation, in "Why 'Open Source' Misses the Point of Free Software", in Communications of the ACM, 06/2009.
"Nearly all open source software is free software; the two terms describe almost the same category of software. But they stand for views based on fundamentally different values. Open source is a development methodology; free software is a social movement. For the free software movement, free software is an ethical imperative, because only free software respects the users' freedom."
"Nearly all open source software is free software; the two terms describe almost the same category of software. But they stand for views based on fundamentally different values. Open source is a development methodology; free software is a social movement. For the free software movement, free software is an ethical imperative, because only free software respects the users' freedom."
Software Engineering sorpassato?
Software Engineering: An Idea Whose Time Has Come and Gone?
Tom DeMarco, IEEE Software, July/August 2009
Quanto è importante, quanto decisivo il ruolo delle metriche e dei sistemi di controllo per il successo di un progetto? DeMarco rianalizza uno dei suoi testi più influenti, Controlling Software Projects, del 1982, e ne critica l'impostazione globale.
"The book for me is a curious combination of generally true things written on every page but combined into an overall message that’s wrong.
It’s as though the book’s young author had never met a metric he didn’t like. The book’s deep message seems to be, metrics are good, more would be better, and most would be best. [...]
I’m gradually coming to the conclusion that software engineering is an idea whose time has come and gone. I still believe it makes excellent sense to engineer software. But that isn’t exactly what software engineering has come to mean. The term encompasses a specific set of disciplines including defined process, inspections and walkthroughs, requirements engineering, traceability matrices, metrics, precise quality control, rigorous planning and tracking, and coding and documentation standards. All these strive for consistency of practice and predictability.
Consistency and predictability are still desirable, but they haven’t ever been the most important things."
Tom DeMarco, IEEE Software, July/August 2009
Quanto è importante, quanto decisivo il ruolo delle metriche e dei sistemi di controllo per il successo di un progetto? DeMarco rianalizza uno dei suoi testi più influenti, Controlling Software Projects, del 1982, e ne critica l'impostazione globale.
"The book for me is a curious combination of generally true things written on every page but combined into an overall message that’s wrong.
It’s as though the book’s young author had never met a metric he didn’t like. The book’s deep message seems to be, metrics are good, more would be better, and most would be best. [...]
I’m gradually coming to the conclusion that software engineering is an idea whose time has come and gone. I still believe it makes excellent sense to engineer software. But that isn’t exactly what software engineering has come to mean. The term encompasses a specific set of disciplines including defined process, inspections and walkthroughs, requirements engineering, traceability matrices, metrics, precise quality control, rigorous planning and tracking, and coding and documentation standards. All these strive for consistency of practice and predictability.
Consistency and predictability are still desirable, but they haven’t ever been the most important things."
10 luglio 2009
Etica del software
Un numero speciale di IEEE Computer, June 2009, sugli aspetti etici della produzione di software.
Tra gli articoli, "The public is the priority: making decisions using the Software Engineering Code of Ethics", di Donald Gotterbarn e Keith W. Miller, che spiega come si può e si deve usare il Codice Etico di Sviluppo Software di ACM e IEEE Computer Society, del quale potete trovare qui la versione italiana.
Tra gli articoli, "The public is the priority: making decisions using the Software Engineering Code of Ethics", di Donald Gotterbarn e Keith W. Miller, che spiega come si può e si deve usare il Codice Etico di Sviluppo Software di ACM e IEEE Computer Society, del quale potete trovare qui la versione italiana.
Al prezzo più basso
Nelle gare d'appalto, spesso vince il fornitore che offre il prezzo più basso. E cominciano i guai, dato che "offerte e stime troppo basse sono spesso indicative di una scarsa competenza".
"How to avoid selecting bids based on overoptimistic cost estimates", è un articolo di Magne Jorgensen, pubblicato su IEEE Software May/June 2009.
L'articolo riporta i risultati di una serie di studi e sondaggi, e offre una serie di raccomandazioni utili per il processo di selezione.
"How to avoid selecting bids based on overoptimistic cost estimates", è un articolo di Magne Jorgensen, pubblicato su IEEE Software May/June 2009.
L'articolo riporta i risultati di una serie di studi e sondaggi, e offre una serie di raccomandazioni utili per il processo di selezione.
Come rompere il software
How to break software. A Practical Guide to Testing, di James A. Whittaker, Addison-Wesley 2002.
Poca teoria, tanta pratica, suggerimenti concreti, anche un CD con tool per simulare problemi (poca memoria, connessioni interrotte, hardware mal funzionante...) nell'ambiente che ospita le applicazioni da testare. Testo utile e ben scritto.
Poca teoria, tanta pratica, suggerimenti concreti, anche un CD con tool per simulare problemi (poca memoria, connessioni interrotte, hardware mal funzionante...) nell'ambiente che ospita le applicazioni da testare. Testo utile e ben scritto.
Iscriviti a:
Post (Atom)