Archivi categoria: software engineering

agile, software engineering

Incremental Commitment Model

Lascia un commento

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.

agile, outsourcing, software engineering

Lo sviluppo in team distribuiti a livello internazionale

Lascia un commento

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.

cliente, project management, requisiti, software engineering, usabilità

Lo saprò quando lo vedrò

Lascia un commento

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’.”

organizzazione, software engineering

Legge di Conway

Lascia un commento

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

software engineering

Modernizzazione del software

Lascia un commento

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.

software engineering

Previsioni a partire dai function point

Lascia un commento

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