software engineering

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.

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.

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)

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.

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.

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'."

"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.

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.

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.

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."