analisi-disegno.com

I benefici della certificazione CMMI non sono quelli di ricevere un "bollino", ma di migliorare in modo sostanziale la produttività e la qualità dello sviluppo software.
Con un ritorno di investimento molto elevato, particolarmente per i livelli più elevati (4 - Managed e 5 - Optimizing).

Sul tema, il numero monografico Jan/Feb 2012 di Crosstalk - The Journal of Defense Software Engineering

Ho pubblicato una breve presentazione dello standard ISO 25010 “Systems and software engineering - System and software quality models”, uscito nel 2011.

ISO 25010 fornisce una classificazione di requisiti non funzionali (o “attributi di qualità”) che sostituisce quella del precedente standard ISO 9126. La nuova classificazione distingue tra requisiti sulla qualità intrinseca del prodotto (“product quality”) e requisiti sulle caratteristiche inerenti all'uso del prodotto (“quality in use”).

Ottimo articolo sulla codifica del software, ricco di indicazioni pratiche ed esempi concreti. "Coding Guidelines: Finding the Art in the Science" di Robert Green e Henry Ledgard, su Communications of the ACM December 2011.

Il messaggio di fondo: focalizzarsi su come si scrive il codice, non sui commenti al codice:

"Programmers must achieve a level of clarity, continuity, and beauty when writing code. This means focusing on the code and its clarity, balance, and symmetry, not on its length or comments. While this concept does not advocate the removal of comments or negate their use and importance in appropriate situations, it does suggest that programmers must use comments wisely and judiciously. The focus should be on developing code that, for the most part, clearly communicates intent and functionality. This practice will automatically reduce the need for many comments."

Ci sono ancora architetti software che non sviluppano? Sì, nelle organizzazioni ancora influenzate dall'approccio a cascata. Ma il fenomeno è in calo, afferma Philippe Krutchen in IEEE Software, May/June 2011, Walking across the Seam.

"In our industry, I see fewer software architects throwing their designs over the wall to the hordes of programmers. In many organizations, these entities— architects and programmers—are roles, not individuals, and we've known for a long time that the best architects are also implementers; and vice versa, the best programmers understand the function of architecture and respect it.

The architect-programmer dichotomy might still exist, mostly in large organizations, as a sort of remnant of the waterfall approach, where the organization tended to match the phases. But today, the most successful software development organizations are staffed by people with a broad range of competencies, able to embrace multiple roles. We hear calls for more T-shaped individuals and less hyperspecialists."

Perché ci sono poche donne nel mondo del software? Poche, si intende, rispetto a quante potrebbero essercene, costituendo almeno il 50% della popolazione.

Per inclinazione? Per attitudine? Improbabile, sostiene Martin Fowler in questo articolo.

Fowler sottolinea come la compresenza di persone diverse tra loro (per genere, per razza, per cultura) nel settore del software sia estremamente vantaggiosa. E come in Cina, ad esempio, la presenza delle donne nel mondo del software sia, in percentuale, molto più alta che negli USA.

Solo quando il software viene effettivamente usato dagli utenti possiamo sapere se a loro va bene o no. Ovvio, no?

Tutte le attività di testing che facciamo prima del rilascio, comprese quelle di far usare il sistema a "utenti proxy" (cioè non agli utenti reali, ma a persone che vorrebbero rappresentare gli interessi degli utenti reali), non ci possono dare la certezza del fatto che il software sarà davvero apprezzato.

Possiamo fare ipotesi, speculazioni, ragionare in termini di probabilità. Ma la realtà verrà fuori solo dopo il rilascio.

Elisabeth Hendrickson ne parla in "What Software Has in Common with Schrödinger’s Cat".

Ivar Jacobson, ideatore dei casi d'uso, ha pubblicato una presentazione di "Use Cases 2.0" (è richiesta una registrazione per scaricarla).

L'elemento più interessante è il concetto di "use case slice" (fetta di caso d'uso).

La "use case slice" corrisponde ad un insieme di scenari e di relativi casi di test da implementare in modo incrementale. Solo alcuni tra i possibili percorsi all'interno del caso d'uso, non tutti.

A volte può anche essere opportuno rilasciare la "slice" prima che l'intero caso d'uso sia completato, in quanto rappresenta già da sola un elemento di valore per gli utenti del sistema. In questo modo lo sviluppo di "slice" successive si coniuga efficacemente con gli approcci iterativi e incrementali.

Un esempio di documentazione UML di architetture software, conforme alle indicazioni del libro "Documenting Software Architectures. Views and Beyond" è stato pubblicato da Paulo Merson e Darpan Saini.

L'esempio è disponibile sul sito del Software Engineering Institute.

Anche interessante un'intervista a Paulo Merson su InfoQ.

Acquisire in uno strumento UML o SysML dei modelli creati con un altro strumento. Esigenza molto comune, per proteggere gli investimenti di modellazione precenenti nel momento in cui si decide di passare ad uno strumento diverso.

L'interoperabilità tra strumenti UML è stata possibile fin dalla partenza di UML, grazie allo standard di interscambio XMI (XML Model Interchange). Solo che il livello di interoperabilità era spesso poco soddisfacente.

Nel 2009 si è costituito, nell'ambito dell'Object Management Group (OMG), il Model Interchange Working Group (MIWG), che ha l'obiettivo di migliorare il livello di interscambio tra strumenti UML/SysML.
Ne fanno parte questi produttori (tra parentesi i relativi prodotti):

• Atego (Artisan Studio)
• IBM (Rational Software Architect)
• Sodio (IBM Rhapsody)
• NoMagic (MagicDraw)
• Softeam (Modelio)
• Sparx Systems (Enterprise Architect)

Il gruppo ha comunicato i risultati dei propri lavori, che dimostrano un significativo miglioramento del livello di interscambio tra i prodotti usati nello studio.