jump to navigation

La metafora tra i ponti ed il software lunedì 6 febbraio 2012

Posted by andy in pensieri.
Tags: , , ,
add a comment

Ho letto un post sulle metafore per l’associazione di ponti ed edifici al software.

Il tema è quello dell’utilizzo della metafora come mezzo per facilitare la comprensione del mondo del software sfruttando analogie nel mondo fisico.

In effetti la principale differenza che il post trova tra i due mondi è la contrapposizione tra la staticità del mondo fisico (ponti, edifici, …) e la continua evoluzione del software.

Personalmente sposterei l’attenzione  su un aspetto più sostanziale: il ponte, l’edificio, la panchina e la madia sono modi per modificare la realtà.
Il software invece è uno strumento per meglio comprendere ed accedere alla sostanza della realtà.

La cosa è forse un po’ ‘tirata per i capelli’, ma credo che valga la pena di un approfondimento: i ponti (etc.) sono mezzi per facilitare la fruizione della realtà.
Il software è invece un mezzo per facilitare la modellizzazione e la comprensione della realtà.

Senza entrare nel merito delle conoscenze necessarie, la considerazione vale in entrambi i domini: se non si hanno appropriate conoscenze di fisica e di meccanica, il ponte crollerà, e se non si hanno equivalenti conoscenze nell’ambito dell’informatica, anche questa creerà più problemi e disservizi che altro, di fatto realizzando programmi e soluzioni che risulteranno inutili ed abbandonate come un ponte incompleto o crollato.

Annunci

Metodologie RUP vs. Agile nello sviluppo del software martedì 12 gennaio 2010

Posted by andy in tecnologia.
Tags: , , , , , ,
add a comment

Lo sviluppo del software vede sempre più il confronto tra metodologie altamente strutturate (RUP) e quelle che vorrebbero essere le più elastiche possibili (Agile).

Il conflitto è, in parte, tra coloro che vogliono assicurare la qualità formale rispetto alla qualità sostanziale.

Il giusto, o il meglio, ovviamente non sta né da una parte né dall’altra, ma più probabilmente nel mezzo.

Ma in che modo?

Non posso che condividere il pensiero che la programmazione sia un fatto artigianale, in quanto frutto di un’invenzione; tutto ciò che non è più artigianale si trasforma in software consolidato, librerie, componenti standard.

Da programmatore riesco perfettamente a capire quanto possa stare ‘stretto’ l’abito di colui che produce righe di codice secondo regole e schemi.

Da responsabile della Qualità, ritengo che la bellezza e le promesse della metodologia RUP siano il Santo Graal per la produzione del software.

Le metodologie di tipo Agile sono soltanto un compromesso, per venire incontro all’ingestibilità innata dei programmatori (quelli bravi, soprattutto), delle specifiche del cliente in eterno divenire, la documentazione (costosissima) che non riesce mai ad essere allineata allo stato dell’arte del progetto, dei budget di progetto per definizione sottodimensionati e dei tempi di consegna spesso irragionevoli.

In medio stat virtus, dicevano i latini, e già Aristotele era giunto a questa conclusione.

Il problema è riuscire a definire (e in qualche modo a formalizzare) quale sia questa via di mezzo.

L’eccessiva formalizzazione porta a spendere più tempo a ‘vestire’ il progetto (specifiche, documentazione, etc.) che a realizzare l’obiettivo finale.

L’eccessiva libertà porta in breve tempo a risultati vicini all’optimum, lasciando tuttavia dei lavorati (o semilavorati) con costi di manutenzione impredicibili.

L’arte sta, probabilmente, nel concentrarsi nel punto di incontro tra sviluppo ed utilizzo del software, tra fornitore e cliente.

È in questo punto che si scopre se il lavoro risponde ai requisiti o meno, ed in cui emergono i requisiti nascosti.

Sostanzialmente è il momento del collaudo che, da istante finale del lavoro, deve diluirsi nel tempo, affinando i punti e gli elementi di controllo.

Ad esempio, invece che lasciare al fornitore le attività di installazione, sarebbe molto più appropriato gestire internamente tale attività, o comunque delegarla ad una società terza: in questo modo qualsiasi mancanza in termini di documentazione dell’architettura e delle procedure di compilazione ed installazione apparirebbe in modo palese dal mancato funzionamento del sistema.

E lo stesso vale per la formazione agli utenti ed al personale incaricato di gestire il sistema: interponendo una figura terza, tutte le carenze documentali verrebbero immediatamente a galla.

Diviene quindi fondamentale che all’inizio non vengano posti requisiti troppo specifici, ma soltanto quelli sostanziali, quelli che discriminano tra l’usabilità o meno del prodotto finale, tra l’eseguibilità o meno, tra l’integrabilità o meno, nonché la sua affidabilità nel tempo.

Metodologia, strumenti, linguaggi, componenti software .. tutti elementi di fatto ininfluenti ai fini del risultato, se il controllo diviene sostanziale e non formale; se il prodotto viene verificato rispetto alle reali esigenze del cliente, e con continuità.

Ovviamente, e con questo concludo, occorre assolutamente sviluppare una nuova cultura (e ribadisco ‘cultura’, rispetto al termine ‘metodologia’) per l’identificazione e la definizione dei requisiti di progetto.

il software e garanzie mercoledì 13 maggio 2009

Posted by andy in Internet e società, tecnologia.
Tags: , ,
add a comment

Un problema ormai datato, quello delle garanzie offerte per il software. Mentre ai consumatori sono riconosciuti dei diritti sanciti dalla legge per i beni materiali, per quelli immateriali (il software, giustappunto) questi diritti non sono riconosciuti.
Ma esistono realmente delle differenze?

A parte il software di tipo militare, o comunque quello che viene sviluppato su commessa, garanzie sul software di fatto non ne esistono.

Con ‘garanzie’ intendiamo quegli aspetti che responsabilizzano il produttore nei confronti del cliente a fronte di danni sofferti da questi a causa del proprio prodotto.

Qualunque prodotto materiale, dal tostapane alla macchina fotografica, è soggetto ad un periodo minimo di garanzia imposto per legge, entro il quale il prodotto non conforme alle specifiche deve essere sostituito a costo zero per il cliente, e addirittura se questi viene a soffrirne danni, può rivalersi sul produttore.

Andando a leggere i diritti concessi all’utente nei contratti di licenza (EULA) dei produttori software più importanti, si scopre che in caso di non corrispondenza alle specifiche del prodotto, il produttore in generale si riserva il diritto di valutare se gli convenga sviluppare e fornire un aggiornamento al software, o rimborsare il prezzo del prodotto.

In nessun modo vengono contemplati, ad esempio, danni derivanti da un antivirus che non funziona, o da un software di compressione o di backup che perda i dati.

Il reale danno per l’utente non è il costo del software, ma il danno al proprio business, e in nessun modo il rimborso del costo della licenza può essere in grado di risarcire il danno subito, senza contare che toglie all’utente il diritto di utilizzare il software.

Gli utenti spingono per equiparare i prodotti immateriali (il software) a quelli materiali, in modo da godere dei medesimi diritti garantiti dalla legge.

Dall’altra parte i produttori insistono nel ribadire la sostanziale differenza tra i due tipi di beni.

Persino la Commissione Europea ha iniziato a valutare con attenzione come le società produttrici di software dovrebbero essere ritenute responsabili per la sicurezza e l’efficacia del loro codice. La Commissione sembra quindi intenzionata ad estendere anche ai software le leggi di protezione dei consumatori in vigore per i manufatti fisici.

Si cerca quindi di responsabilizzare i produttori di software.

Ma in pratica, cosa sta accadendo? Il mercato sta affrontando una transizione di fase: si passa dal tempo in cui il software era realizzato da un’elite, e quindi chiuso (closed source) ad un’era in cui l’utente si sta rendendo conto che il software è conoscenza, ed in questo senso deve essere di tutti (open source).

La competizione che si è scatenata contrappone quindi prodotti sviluppati cooperativamente a quelli sviluppati in un’ottica di business tradizionale.

Un aspetto interessante della questione riguarda i brevetti sul software: i brevetti sono stati pensati per proteggere gli investimenti, e questo sicuramente vale per i beni materiali; ma se il software, in quanto bene immateriale, può essere trattato alla stessa stregua? Possiamo utilizzare due pesi e due misure?

Forse esiste un modo per interpretare la situazione e trovare una mediazione che incontri sia le esigenze degli utenti che gli interessi dei produttori: l’idea è quella di far pagare la Qualità.

Dal momento che esistono delle metodologie per verificare la qualità, la robustezza e la sicurezza del software, si potrebbe pensare che si potrebbe consentire la richiesta di un fee di licenza soltanto per il software che abbia superato una certificazione di parte terza rispetto alle metodologie stabilite come riferimento.

L’approccio è un po’ quello della ISO9001 (o anche altre norme, ma credo che questa sia la più nota): non è obbligatoria, ma se si vuole partecipare a certe gare, occorre aver preventivamente investito in una certificazione esterna della metodologia utilizzata.

Vuoi risparmiare sul costo di produzione del software? OK, ma se non non fornisci garanzie, non chiedere più di tanto (che so, per Windows, 10 Euro possono andare bene?)
Se invece certifichi il tuo prodotto (pensiamo a Windows server), a questo punto si possono anche chiedere migliaia di Euro di licenza.

Un approccio simile è quello di RedHat, MySQL, etc. che rendono disponibile gratuitamente il proprio prodotto, ma si fanno pagare un fee per la versione Enterprise, sulla quale forniscono garanzie, liste di certificazione, ed un servizio di risoluzione dei problemi.

In sostanza, la Qualità si paga.

La PA ed i monopòli del software martedì 7 ottobre 2008

Posted by andy in Etica, Miglioramento.
Tags: , , , , , ,
add a comment

Retaqgio di un tempo passato, ancora oggi il software sviluppato da aziende private per la PA è di fatto gestito in regime di monopolio.

Pur essendo i sorgenti del software ufficialmente proprietà della PA, non basta che vengano consegnati dei CD pieni di codice per poter affermare che il software sia stato realmente consegnato.

Un software è realmente consegnato quando il materiale che viene fornito è sufficiente per mettere in condizione il ricevente di poterne riprodurre ed installare una versione funzionante, e di poterne effettuare la manutenzione.

In realtà questo non accade, o accade solo parzialmente, lasciando di fatto nelle mani delle aziende sviluppatrici  il controllo ed il monopolio per la manuntezione correttiva ed evolutiva.

Pur essendo un comportamento eticamente scorretto, e pur essendovi dell’intenzionalità da parte dei privati nel sostenere questo stato di cose, non è tuttavia possibile dare a questi tutti i torti e le responsabilità della cosa.

Una (buona) parte delle responsabilità cade sulla PA per una serie di ragioni:

  • in primis perché non vengono create le appropriate condizioni commerciali per una reale competitività sulle offerte; il software esistente è sì nelle mani della PA, ma questo non viene reso disponibile al mercato dei potenziali fornitori se non dietro esplicita richiesta ed in occasione di un bando di gara; questo significa che nessuna azienda ha la possibilità di poter prendere in mano il software con anticipo tale da poter effettuare una valutazione economica oggettiva per partecipare alle gare;
  • in secondo luogo perché vengono imposte condizioni commerciali non negoziabili talmente tirate che non rimane al fornitore lo spazio per la desiderata gestione della Qualità del prodotto, che viene pertanto limitata al minimo indispensabile;
  • non da ultimo il fatto che la PA in generale non si è attrezzata con strutture proprie interne preposte alla presa in carico del software, con la responsabilità di riprodurre i prodotti ed i sistemi commissionati all’esterno partendo dalla documentazione e dai sorgenti forniti;
  • da ultimo, e tutto sommato abbastanza grave, il fatto che la PA non è in grado di stabilire delle linee guida strategiche sufficientemente chiare e condivise (o imposte) tra tutti i ministeri e gli enti, e non è spesso in grado di identificare con chiarezza e precisione nei contratti i requisiti del prodotto da realizzare, lasciando così troppi gradi di libertà al fornitore, che di fatto progetta e consegna ciò che ritiene meglio per sé più che per il cliente.

Non bisogna poi sorvolare su progetti che, pur essendo incompleti o insoddisfacenti, devono per forza di cose essere collaudati con esito positivo pena la decadenza dello stanziamento dei fondi.

Ed in tutto questo marasma annaspano e devono destreggiarsi coloro che (interni ed esterni) si trovano, loro malgrado, a dover mandare avanti la baracca, sopperendo con le proprie capacità e la propria buona volontà ai problemi che si presentano di volta in volta.

Ma i tempi stanno cambiando, ed a breve inizieranno a palesarsi gli effetti dei germi del rinnovamento.

I principali elementi penso che saranno:

  • la definizione di standard di interoperabilità nazionali, e sovranazionali;
  • l’apertura del codice e delle specifiche al mercato;
  • la valorizzazione delle risorse interne della PA;
  • la valorizzazione della peer review da parte sia degli specialisti interni che del pubblico.