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)
venerdì 4 luglio 2008
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.
mercoledì 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”.'
Iscriviti a:
Post (Atom)