analisi-disegno.com

bpmNEXT è una conferenza sul Business Process Management, con una particolarità: è pensata come uno scambio di informazioni e di opinioni tra i produttori di strumenti, più che come una vetrina a fini commerciali. Utile, quindi, per farsi un'idea sulle tendenze dei prodotti nel campo dei BPMS (Business Process Management Systems) e del BPMN (Business Process Model and Notation).

Resoconti della conferenza da uno degli organizzatori, Bruce Silver, da Paul Harmon e da Sandy Kemsley.

Lean Startup, di Eric Ries, è un libro sull'innovazione di prodotto, non (o almeno non solo, come farebbe pensare il titolo) sul lancio di nuove iniziative imprenditoriali.

Il successo di un prodotto, spiega Ries, nasce spesso dall'aver imparato le lezioni necessarie dal fallimento di precedenti tentativi. Per questo motivo, ogni tentativo di innovazione va condotto come un prototipo da controllare e misurare, ottenendo riscontri concreti e verificabili, rapidamente e con il minor costo possibile. Per poter poi aggiustare il tiro.

Uno dei principi basilari dell'approccio Lean: ridurre al minimo il Work in Progress, usando lotti di lavorazione minimi.
Il video mostra due modi diversi di imbustare dieci lettere. Nel primo, tutte le lettere vengono piegate, poi tutte imbustate, poi tutte le buste vengono incollate, infine tutte timbrate. Nel secondo modo, viene lavorata in modo completo una lettera-busta alla volta.

Alcune grandi aziende statunitensi, come General Electric e General Motors, ricostruiscono il proprio settore di sviluppo software, dopo anni di outsourcing, per fornire un supporto più efficace ed efficiente alle proprie strategie. Intanto, le grandi software house indiane assumono sviluppatori negli USA.

Un inserto speciale di The Economist su Outsourcing e Offshoring, con un articolo dedicato allo sviluppo software.

In molte organizzazioni la progettazione delle basi dati è un'attività centralizzata, delegata ad un ruolo distinto dai gruppi di sviluppo, la Data Base Administration (DBA).
Le ragioni sono due: favorire una migliore integrazione dei dati tra i diversi sistemi che vi accedono, e usare al meglio competenze specialistiche particolari, come quelle necessarie per ottimizzare le prestazioni negli accessi.

A volte, purtroppo, la DBA centralizzata diventa un collo di bottiglia, e ricorrere ai servizi che offre crea impedimenti e ritardi ai progetti.

Martin Fowler, nell'articolo No DBA, rileva che questi impedimenti possono portare in alcuni casi i gruppi di sviluppo alla scelta di non usare i DBMS relazionali, gestiti dalla DBA, sostituendoli con altri tipi di tecnologia, come i DBMS NoSQL, che invece la DBA non presidia e che vengono gestiti direttamente dai progetti. E che ciò accade anche quando per le caratteristiche dei progetti un DBMS relazionale andrebbe meglio.

"La Quality Assurance (operare con un alto livello di qualità) è molto più efficace del Quality Control (controllare il livello di qualità quando si ha finito di operare). Meglio introdurre criteri di usabilità dall'inizio - ancora prima di iniziare la progettazione - che aspettare fino a quando il sistema è completo per poi sottoporlo ad una validazione nel testing utente."

Jacob Nielsen, esperto di usabilità, in questo articolo su Quality Assurance e User Experience ricorda anche quella che chiama la "prima legge dell'usabilità":

"La vostra progettazione sarà comunque testata dagli utenti - potete solo scegliere se fare voi stessi i test prima del rilascio, per mettere a posto a costi inferiori gli inevitabili problemi, oppure spendere molto di più dopo il rilascio."

Quando il software è fatto bene, gli utenti lo usano senza problemi. Chi dà assistenza non è subissato dai reclami. Per chi lo fa evolvere è facile aggiornarlo, modificando le funzioni esistenti quando è il caso, o introducendone di nuove.

Non tutti, purtroppo, viviamo in questo mondo ideale. Non sempre, almeno. Perché il software può essere anche fatto male, e (se lavoriamo nel settore dello sviluppo software) può darsi che l'abbiamo fatto male noi.

Perché, a volte, il software è fatto male? In alcuni casi, per l'incompetenza di chi lo sviluppa, problema in genere superabile con un'adeguata formazione professionale. In altri casi, però, il motivo non è la mancanza di competenza. Anche sviluppatori molto capaci producono a volte software non ottimale. Per fare più in fretta, per spendere meno tempo, perché non c'è più tempo. Per rilasciare prima, in tempo, la nuova versione del software.

Ogni volta che produciamo un software con dei problemi, che lo modifichiamo in un modo non ottimale, ad esempio facendo “copia e incolla” di porzioni di codice invece di riprogettare adeguatamente il programma, diminuiamo il livello di qualità del prodotto. Rendiamo più difficili, lunghe e costose le modifiche successive, che verranno anch'esse, probabilmente, fatte male. Così il software degrada ad ogni successiva modifica, e può accadere che anche prodotti inizialmente validi peggiorino ad ogni nuovo rilascio.

Questo è il debito tecnico. “Debito tecnico” è una metafora ideata da Ward Cunningham per far capire, sia agli sviluppatori che ai non addetti ai lavori, il costo economico che ha un intervento non ottimale sul software. Ogni volta che contraiamo un debito, ad esempio un mutuo (o il debito pubblico di una nazione), dobbiamo ripagarlo con gli interessi. Nel caso del software, ogni volta che effettuiamo un intervento inadeguato, scegliendo la strada più veloce anziché la migliore, abbassiamo la qualità e rendiamo più difficili e costosi gli interventi futuri.

Questo non significa che fare in fretta non sia necessario. A volte dobbiamo per forza scegliere la strada veloce anziché la migliore, perché non abbiamo alternative. Ma poi bisogna mettere le cose a posto, se si vuole evitare il peggio.

"Separare completamente le responsabilità sul testing da quelle sullo sviluppo, creando gruppi rigidamente distinti per le due attività, produce sistemi con minore qualità", sostiene Elisabeth Hendrickson in questa intervista sull'organizzazione delle attività di testing, sull'automazione dei test di accettazione e sugli strumenti utili per il testing.

L'Object Management Group (OMG) ha pubblicato un documento sull'automazione del conteggio dei Punti Funzione (Function Point), la metrica più diffusa a livello internazionale per misurare le dimensioni delle applicazioni software (cioè per dare risposta alla domanda: quanto è "grande" un software?).

Il conteggio dei Function Point è utile sotto diversi punti di vista, per governare sistemi informativi complessi e misurare livelli di qualità e di produttività; viene spesso usato anche per stimare, negoziare e tenere sotto controllo i rapporti di outsourcing tra clienti e fornitori nell'ambito dello sviluppo software. Il conteggio viene svolto tradizionalmente in modo "manuale", ed è un'attività onerosa che richiede una elevata competenza specialistica.

Il documento OMG sull'automazione del conteggio dei Function Point, in versione beta (lo stadio precedente all'emanazione come standard ufficiale), è disponibile con il titolo "Automated Function Points" sul sito del Consortium for IT Software Quality (CISQ), nella sezione riservata ai membri: l'iscrizione è gratuita e consente lo scarico del documento.

Una conversazione tra Capers Jones, massimo esperto di "metriche" sulla qualità e sui rischi del software, e Ward Cunningham, ideatore del concetto di debito tecnico (oltre che dei wiki, dello sviluppo agile, e di varie altre cose).

La qualità della registrazione audio è scadente, ma la trascrizione merita una lettura.