analisi-disegno.com
Già presso gli antichi Egizi, racconta lo storico greco Erodoto (5 secolo a. C.), i medici erano specializzati.
"L'arte della medicina è da loro [Egizi] divisa nel modo seguente: ognuno è medico di una sola malattia e non di più. Ogni luogo perciò è pieno di medici, perché ci sono i medici degli occhi, quelli della testa, dei denti, quelli delle malattie intestinali e quelli delle malattie incerte." (Erodoto, Storie, libro II, 84).
Proprio come i nostri attuali specialisti. Anche se non abbiamo una specializzazione in malattie incerte. Se ne occupano i medici di base, i generalisti.
La divisione del lavoro, in termini generali e non legati allo sviluppo software, ha due ragioni d'essere. Da una parte, la complessità delle conoscenze necessarie per svolgere il lavoro. Dall'altra, le esigenze economiche ed organizzative, che mirano a contenere i costi e migliorare i risultati.
Alcuni mestieri richiedono conoscenze complesse, e questo è un fattore
che spinge alla specializzazione. Per i medici, così come per gli
informatici.
Ruoli distinti. Capo progetto, analista, progettista software,
specialista di data base, progettista di interfacce utente,
programmatore, tester, sistemista esperto in software di base. Eccetera.
Le specializzazioni portano spesso ad ulteriori specializzazioni.
Analista? Analista business, analista di processi, analista di sistema,
analista funzionale. Programmatore? Programmatore Java, programmatore
Perl, programmatore dotNet.
Per realizzare un sistema, per fornire risultati in un progetto, sono necessari più tipi di conoscenza. Le diverse competenze, i diversi punti di vista devono incontrarsi e collaborare. Integrarsi. In ogni progettazione esistono conflitti di requisiti, situazioni di stallo, vincoli temporali ed economici, e bisogna prendere delle decisioni. E per prendere decisioni serve una visione d'insieme. Generale.
Negli ultimi anni è emersa, nelle organizzazioni IT più complesse, la
figura dell'architetto software, come figura esperta e con un ampio
spettro di competenze. L'architetto software non è uno specialista, ma è
la figura che riesce a comprendere i conflitti tra le diverse esigenze
che emergono dai diversi campi specialistici, ed è in grado di risolvere
i conflitti e prendere decisioni grazie alla propria esperienza e
capacità di sintesi.
Idealmente, si ispira alla descrizione dell'architetto (non software)
fornita dal romano Vitruvio.
"L'architetto ideale dovrebbe essere una persona di lettere, un matematico, familiare con gli studi storici, uno studioso appassionato di filosofia, con conoscenze di musica, non ignorante di medicina, istruito sugli aspetti legali, familiare con l'astronomia ed i calcoli astronomici." - Vitruvio, circa 25 a.C.
Auguri... Ma se guardiamo ad un'altra figura rilevante per i progetti
di sviluppo software, l'analista, lo spettro delle conoscenze necessarie
è anche qui molto ampio. L'analista può doversi occupare di
problematiche di business, come di vincoli tecnologici e di aspetti
legati alla sicurezza ed all'usabilità.
Conoscere tecniche di analisi dei processi, progettazione dati, e
notazioni varie (UML, BPMN, eccetera). Padroneggiare tecniche di
comunicazione, orali e scritte.
E i capi progetto? Non devono forse padroneggiare una molteplicità di aspetti (tempi, costi, contenuti da produrre, rischi) e di relazioni (committenti, stakeholder, gruppo di lavoro, staff)?
Architetto software, capo progetto, analista sono esempi di ruoli
complessi, che portano a pensare che una forte specializzazione nel
settore informatico sia di fatto inevitabile.
Eppure esiste una tendenza di segno opposto, verso una possibile
ricomposizione dei ruoli specializzati. Ne parleremo prossimamente.
*** Il 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.
"Il libro è secondo me una curiosa combinazione di cose vere se prese singolarmente, ma che messe insieme forniscono un messaggio complessivo sbagliato. È come se il giovane autore del libro non avesse mai incontrato una metrica che non gli piaceva. Il messaggio profondo del libro sembra essere che le metriche sono una buona cosa, più metriche sarebbe meglio, e più ce ne sono meglio è."
*** Jacobson su UML ***
Ivar Jacobson (uno dei padri di UML): Taking the temperature of UML
"Dopo tutto, UML era solo una notazione, non una panacea. Oggi si guarda a UML con una prospettiva più equilibrata. UML non è un silver bullet, come veniva pubblicizzato dieci anni fa. Ma non è neppure male come accademici, agilisti e proponenti di altre notazioni affermavano cinque anni fa. Usato in modo appropriato è un mezzo pratico per elevare il livello di astrazione del software, dal livello del codice a quello del sistema complessivo."
*** 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.
"Praticamente tutto il software open source è software libero; le due espressioni descrivono quasi la stessa categoria di software. Ma esprimono punti di vista basati su valori fondamentalmente diversi. L'open source è una metodologia di sviluppo; il software libero è un movimento sociale. Per il movimento del software libero, il fatto che il software sia libero è un imperativo etico, perché solo il software libero rispetta la libertà degli utenti."
*** 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:
Per entrambe queste categorie di sistemi, esiste una distinzione rigorosa tra l'evoluzione del kernel e l'evoluzione delle altre parti più periferiche, che si articola in gestioni dei requisiti e delle scelte architetturali da effettuare su due piani distinti.
The Metropolis Model. A New Logic for Development of Crowdsourced Systems, in Communications of the ACM, 07/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:
Se volete, potete contribuire ad ANALISI-DISEGNO:
ANALISI-DISEGNO viene spedito a chi ne fa richiesta. La pubblicazione non avviene con periodicità predefinita.
Archivio notiziari | Notiziario precedente | Notiziario successivo
analisi-disegno.com , servizi e materiali per lo sviluppo dei sistemi software, a cura di Adriano Comai.