analisi-disegno.com
Nei progetti di sviluppo software il ruolo di committente è essenziale. È il ruolo che di solito esprime la richiesta da cui avrà origine il progetto, legata a precisi obiettivi di business. Decide i principali requisiti che guideranno lo sviluppo, e che dovranno essere coerenti con quegli obiettivi. Alla conclusione del progetto, è il committente che accetta il prodotto finale.
Anche durante il progetto è il committente che deve prendere le decisioni più rilevanti. Spetta infatti a lui (o lei) decidere quali funzionalità e quali caratteristiche rientrano nei confini del progetto, e quali no. E quali sono i limiti di costo sostenibili ed i vincoli temporali da rispettare.
Quando poi una delle tre variabili principali di progetto (cose da fare, tempi e costi) cambia in corso d'opera, per effetto di eventi non previsti all'inizio, diventa necessario valutare gli impatti del cambiamento. La decisione su cosa sia opportuno variare come conseguenza diventa cruciale, ed è nuovamente di competenza del committente.
Se ad esempio emerge durante il progetto la necessità di realizzare una funzionalità inizialmente non prevista, bisogna valutare se sia possibile aumentare i fondi necessari per svilupparla, se dilazionare i tempi di rilascio, se aggiungere la nuova funzione eliminando o rimandando altre funzioni previste inizialmente, ma meno urgenti.
Decisione che spetta di diritto al committente, perché riguarda considerazioni legate agli obiettivi di business che solo lui può valutare in modo completo, e che rientrano nelle sue responsabilità.
Analogamente spettano al committente le decisioni da prendere quando si verificano casi di ritardo nei tempi di sviluppo: conviene spostare in avanti la data di rilascio del prodotto o mantenere la data prevista inizialmente, riducendo le funzionalità del prodotto precedentemente concordate?
Dal momento che il committente è il ruolo che prende le decisioni più critiche per il progetto (compresa, se e quando è il caso, quella di interromperlo), si tratta di un ruolo indispensabile, e deve essere chiaro a tutti chi lo riveste per tutta la durata del progetto stesso. Uno dei fattori di rischio più pericolosi in un progetto di sviluppo software è la situazione in cui non è chiaro chi abbia il ruolo di committente, o in cui la persona ufficialmente designata a svolgere tale ruolo non abbia la capacità, la volontà o l'autorità sufficienti a prendere le decisioni quando diventa necessario farlo.
Il problema, in casi simili, è che il committente è un ruolo difficilmente sostituibile. In situazioni progettuali in cui altri ruoli sono svolti in modo poco efficace, si può far fronte con degli interventi correttivi in corso d'opera, come affiancamenti o sostituzioni; è invece improbabile che si possa invece intervenire con correzioni quando ad essere debole è il committente.
*** BPMN 2.0 ***
BPMN 2.0 è stato ufficializzato dall'OMG e pubblicato con data gennaio 2011.
Da notare che l'acronimo è rimasto identico, ma i termini corrispondenti sono un po' cambiati. BPMN non significa più "Business Process Modeling Notation", bensì "Business Process Model and Notation".
*** Process Knowledge Initiative ***
La Process Knowledge Initiative nasce per promuovere una standardizzazione della terminologia nell'ambito dell'analisi dei processi.
I diversi framework e standard esistenti (tra cui ad esempio BPMN, UML, IDEF, SCOR, VCOR, ITIL, APQC hanno marciato finora separatamente, per cui il medesimo concetto viene denominato in modo diverso.
Promotori dell'iniziativa di standardizzazione sono il BPM Group della Queensland University of Technology (QUT), l'International Institute of Business Analysts (IIBA), Kemsley Design, la rivista online BPTrends e l'Object Management Group (OMG).
Secondo i promotori, la confusione terminologica costituisce un freno per la diffusione dell'analisi dei processi e del BPM, e l'obiettivo dell'iniziativa è quindi di risolverla, definendo in modo univoco alcuni termini fondamentali.
Per il momento è disponibile, nel wiki dell'iniziativa, una bozza di lavoro del Body of Knowledge.
*** Casi d'uso 2011 ***
Ivar Jacobson, l'ideatore dei casi d'uso, ha pubblicato sul suo blog due interventi sullo stato dell'arte della tecnica:
Nel primo intervento, Jacobson spiega perché la tecnica continua ad essere usata con successo, e fa il punto su alcuni fraintendimenti. Nel secondo intervento, Jacobson propone due evoluzioni della tecnica, legate alla gestione incrementale dello sviluppo e al trattamento degli aspetti derivanti dai requisiti non funzionali.
*** Libro: Documentare le architetture software (2a edizione) ***
Uno dei testi fondamentali sulle architetture software è "Documenting Software Architectures. Views and Beyond", lavoro collettivo di una serie di esperti del Software Engineering Institute (SEI). La seconda edizione (2010) del testo lo ha ulteriormente migliorato, grazie a due innovazioni significative.
In primo luogo è stata recepita la lezione degli approcci agili, e non viene dato per scontato un alto livello di formalizzazione nella documentazione dei sistemi. Per gli esperti del SEI è essenziale chiarire quali sono le effettive esigenze di comunicazione, a partire dall'individuazione degli stakeholder interessati all'architettura del software e dall'esame delle loro esigenze: quanto e cosa documentare dipende dal contesto.
L'altra innovazione significativa riguarda l'uso dello Unified Modeling Language (UML). Mentre nella prima edizione del libro gli autori mettevano in luce le lacune dello standard (allora in versione 1.4), ora considerano le versioni 2.x di UML come una base solida per le esigenze di documentazione delle architetture software.
Paul Clements, Felix Bachmann, Len Bass, David Garlan, James Ivers, Reed Little, Paulo Merson, Robert Nord, Judith Stafford: Documenting Software Architectures. Views and Beyond (2nd Edition) - Addison Wesley 2010
Se volete, potete contribuire ad ANALISI-DISEGNO:
ANALISI-DISEGNO viene spedito a chi ne fa richiesta. La pubblicazione non avviene con periodicità predefinita e regolare.
Archivio notiziari | Notiziario precedente | Notiziario successivo
analisi-disegno.com , servizi e materiali per lo sviluppo dei sistemi software, a cura di Adriano Comai.