Open Source per la Qualità del software l'approccio di ... · Nessun costo di licenza (acquisto e...

2.5 Italia LicenseEngineering Group www.eng.it1

Sergio OltolinaSenior Technical Manager Architetture e Consulenza

Direzione Centrale Ricerca e [email protected]

www.eng.itPerugia 19 marzo 2010

Open Source per la Qualità del software

l'approccio di Engineering


Gruppo Engineering

721 (milioni Euro)Ricavi

2009


Gruppo Gruppo Engineering

FinanceOil &

Services

Utility

Industry

Telco & Media

P. A. Locale e Sanità

Ricerca &Innovazione

M E R C A T O

P. A. Centrale

CENTRI DI COMPETENZA

ENTERPRISE CONTENT

MANAGEMENTSICUREZZA OUTSOURCING

AUTOMAZIONE& CONTROLLi

SAPOPEN

SOURCE E B.I.



36 Sedi� 33 in Italia� 1, rappresentativa, a Bruxelles � 1, in Irlanda, Engitech Ltd., a Dublino� 1 in Sud America, Engineering Do Brasil,

a San Paolo

6,635 Dipendenti & 1,900 Risorse esterne� Professionisti con grandi Capacità e Conoscenze

in ambito di Business e di Tecnologia

� L’alta percentuale di personale esterno risponde all’esigenza di Flessibilità del Mercato

Clienti e progetti all’estero pari al 10% del fatturato



Engineering è Partner e Socio Fondatore di NESSI.NESSI persegue l’obiettivo di sviluppare una Strategia condivisa che consenta di rafforzare la Capacità di Innovazione e di Business dell’industria europea del Software e dei Servizi.

NESSI: Networked European Software & Service Initiati ve

Engineering è Partner di OW2Leader nella BI initiative e membro della SOA initiative

OW2 Consorzio: Object Web 2

Framework Java EE Business Intelligence

SOA / BPM Qualità del Software

SPAGO World: eco sistema Open source internazionale www.spagoworld.org


Agenda

Qualità e Open Source• Cosa è utile valutare in un prodotto Open Source • Modelli di assessment• Il progetto di ricerca Europeo Qualipso

Qualità in Engineering• Framework per la qualità• L’esperienza Engineering

Spago4Q esempio di utilizzo (demo)“Spago4Q una soluzione Free Open Source per la misura, l’analisi ed il monitoraggio della qualità di prodotto, processo, servizi IT”

Spago4Q• Il processo di misura• Architettura• QESTnD Multidimensional Model


� L’utilizzo di OSS aumenta il lavoro per aziende nazionali� Frena fortemente la creazione di monopoli� Autonomia rispetto ai vendor stranieri (multinazionali)� Pubblico accesso e libertà nell’informazione� Sicurezza ed integrità (controllo completo del codice)� Il software proprietario non favorisce l’innovazione (brevetti software, protezioni di mercato, road-map “proprietaria”)

Motivazioni politico-industriali

Perché scegliere il software OS

Motivazioni tecnico-economiche

� Abbattimento del costo delle licenze� Indipendenza dai vendor� Numero di fornitori di servizi potenzialmente più elevato rispetto al software proprietario� Il software open source consente agli sviluppatori locali di adattare le soluzioni alle esigenze dello specifico paese� Favorisce il Riuso� Open Standards e Interoperabilità


Come scegliere il software OS

� Nessun costo di licenza (acquisto e gestione)� Diverso TCO (Total Cost of Ownership)� Soluzione supportata nel tempo (manutenzione)� Sostituibilità dei fornitori� Soluzione aperta (facilita lo sviluppo di progetti di integrazione)� Riduzione del time-to-market� Maggiore qualità, flessibilità e riuso� Interoperabilità, compatibilità, portabilità� Spinta all’adozione di standard aperti

VANTAGGI

� Test più elevato in fase di rilascio� Difficoltà a creare skill e supporto interno� Complessità di gestione� Rischio di avviare progetti sperimentali non finalizzati al business� Scarsi servizi di integrazione e supporto� Politica delle licenze

CRITICITA’

Non tutto il FLOSS è uguale:bisogna saper valutare e scegliere!


� Numero di sviluppatori attivi� Numero di downloads del software� Soddisfazione degli sviluppatori� Livello di attività del progetto� Tempo intercorrente tra i rilasci� Tempo di chiusura dei bugs� Reputazione del progetto

Elementi di valutazione OSS

Elementi di valutazione “classici”

� Completezza� Manutenibilità� Testabilità� Usabilità� Documentazione� ….

Elementi di valutazione


Metodi di valutazione della qualità dei prodotti FLOSS

Altri� Open Source Maturity Model (Navica 2004) � Open Source Maturity Model (Cap Gemini 2003)� Open Source Catalogue (Optaros) www.eosdirectory.com www.optaros.com

� IRCA (Weehler) www.dwheeler.com/oss_fs_eval.html

� ohloh www.ohloh.net

Il software open source non è “intrinsecamente” di qualità superiore a quello proprietario, ma la sua qualità è “misurabile” direttamente dall’utilizzatore

� QSOS (Atos Origin 2004)� OpenBRR (Carnegy Mellon e altri 2006)� OMM (Qualipso Open Maturity Model 2009)


www.qsos.org

Qualification and Selection of Open Source sofware

Realizzato da Atos Origin, rilasciato in licenza GNU FD L

QSOS

E’ disegnato per aiutare a differenziare il punto di vista tecnicoda quello funzionale

E’ strutturato in 4 fasi


www.qsos.orgQSOS – Fase 1 Define

Supporta la definizione di criteri di valutazione in base ad es. a famiglie software, tipi di licenze, tipi di communities


QSOS Fase 2 Assess

I risultati di questo step costituiscono una collezione di schede (Identity Card) che raccolgono per ogni elemento di valutazione commenti e considerazioni utili ad assegnare il punteggio

Sono valutate tre differenti prospettive: • Copertura funzionale• Rischi dal punto di vista utente• Rischi dal punto di vista dell’erogatore del servizio

•Industrialized solution•Independence of developments

•Developments realized at 100% by employees of a single company•60% maximum•20% maximum

•MySQL AB is the unique copyrigth owner of most part of source code (except some storage engines) and employs core team members•Score : 0/2

www.qsos.org


www.qsos.orgQSOS – Fase 3 Qualify

Definizione di pesi per introdurre filtri su bisogni e vincoli relativi all’utilizzo del prodotto nell’ambiente dell’utente.


www.qsos.orgQSOS – Fase 4 Select

Consente di identificare il prodotto che soddisfa i requisiti iniziali e permette di selezionare all’interno della famiglia di prodotti più prodotti da comparare tra di loro.


OPENBRR

• un assessment aperto e flessibile ma al tempo stesso standardizzato

• la definizione di un processo di assessment sistematico e trasparente sia per FLOSS che per software proprietari

• la comparazione di differenti prodotti software

Open Business Readiness Rating

Rispetto ai metodi precedenti propone:

www.openbrr.org


OPENBRR

4 requisiti per un buon modello di valutazione del software:

1. Deve evidenziare tutte le caratteristiche importanti del prodotto. Deve fornire una panoramica completa di tutte le caratteristichesia positive che negative

2. Il processo di valutazione e il sistema di valutazione devono essere facili da capire. La terminologia deve essere facile da usare.

3. Il modello deve essere flessibile e deve adattarsi ai rapidi cambiamenti all'interno del settore IT.

4. Il modello deve essere coerente se usato su differenti target. La coerenza del modello permette la comparazione dei prodotti software appartenenti a diversi domini.

Obiettivo: realizzare un modello scientifico che contiene una mappatura chiara tra i dati di valutazione, il punteggio per ogni elemento ed il valore finale del rating.

www.openbrr.org


OPENBRR

Categorie di valutazione

� Functionality

� Operational software characteristics:

Reliability, scalability, performance, usability, security, installation, interoperability

� Support and service

� Documentation

� Development process:

Leadership, project data, task assignments *

� Software Technology Attributes *

Architecture, code quality

� Adoption

Size, Activity level, community * Disponibile per OS non per software proprietari

www.openbrr.org


OPENBRR www.openbrr.org


� Creazione di una lista di candidati per una valutazione più approfondita; in questa fase è consigliabile utilizzare alcuni indicatori per aiutare a selezionare i progetti più interessanti, quali:

� Tipo di licenza.� Conformità agli standard� Referenze� Esistenza di una organizzazione alle spalle che supporta lo sviluppo del progetto.� Linguaggio di programmazione utilizzato� Supporto dell’internazionalizzazione� Esistenza di altre valutazioni di enti esterni � Esistenza di pubblicazioni� Il progetto è seguito da analisti (IDC, Gartner, ..)

Quick Assessment Filter

OPENBRR – Fase 1 www.openbrr.org


�Analisi approfondita delle caratteristiche dei proget ti per ordinare le categorie e assegnare la functional orientation. �Normalizzazione dei dati delle metriche (proprietàmisurabili del progetto), in particolar modo le metriche che nonsono facilmente misurabili ma a cui è associata una valutazione qualitativa (che può essere soggettiva). Organizzazione delle metriche in aree di interesse indicate come categorie a cui associare un peso.� Identificazione dell’ambito di utilizzo del progetto(sperimentazione, ambiente di produzione, …) e della tipologia (web browser, web server, office, …), da cui derivare la functional orientation intesa come combinazione del tipo e ambito e identificata come “peso associato alla singola categoria” (serve per normalizzare le metriche contenute in essa): percentuale associata ad ognuna delle categorie scelte e utilizzate per la valutazione

Functional Usage Weighting

OPENBRR Fase 2 www.openbrr.org


� Raccolta dei dati : per ogni categoria sono identificate un insieme di metriche che possono essere modificate (aggiungendo o togliendo metriche specifiche per la tipologia), queste sono generiche e valgono per tutti i tipi di progetti; solo la categoria “funzionale” contiene delle metriche che sono specifiche della tipologia di progetto in valutazione.I valori da assegnare alle singole metriche devono essere normalizzati tra 1 e 5; per le metriche qualitative sono proposte alcune linee guida

Data Collection & Processing



Data translation

� Trasformazione dei dati nella valutazione BRRTerminate le fasi precedenti viene generata la valutazione finale BRR sommando le singole metriche, con risultato un numero tra 1 e 5.Per la valutazione delle metriche è disponibile un foglio MS-excel utilizzabile come template su cui aggiungere le varie metriche funzionali.



OPENBRR www.openbrr.org


www.qualipso.org

10 aree di indaginesu OSS

Qualipso

Progetto di ricerca Europeo a cui partecipano anche Ci na e Brasile


Qualipso - Principali Attività www.qualipso.org

LEGAL ISSUES: Providing guidelines and tools to facilitate an intellectual property trackingprocess with open source, and defining a coherent family of OSS licenses, compliant withnational laws and European regulations. BUSINESS MODELS: Defining methods, development processes, and business models tofacilitate the use of Open Source Software (OSS) by the industry. TRUSTWORTHY RESULTS: Studying qualities that can sustain trust in Open Source components. TRUSTWORTHY PROCESS: Developing a new Capability Maturity Model-like approach toassessing the quality of OSS. This model will be discussed with CMM’s originators, the Software Engineering Institute (SEI), with a view to formalising it as an official extension of CMMI®. NEXT GENERATION FORGE: Designing and implementing the “QualiPSo Factory”, anintegrated next generation forge that will facilitate and support the development of viableindustrial OSS systems. COMPETENCE CENTER: Developing a long lasting network of professionals caring for the quality of Open Source Software for enterprise computing. Six QualiPSo CompetenceCentres - running the collaborative platforms, tools and process developed in this project –will be set up to support the development, deployment and adoption of OSS by private and public Information Systems Departments, large companies, SMEs, end users and ISVs. Ofthese Competence Centres, four will be based in Europe (in Berlin, Madrid, Paris, Rome), one in China and one in Brazil (São Paulo).


http://qualipso.icmc.usp.br/OMM/

Qualipso - Trustworthy process

OMM Open Maturity Model

RDMP: Roadmap

REQM: Requirements Management

PP1: Product Planning 1

CM: Configuration Management

MST: Maintainability and Stability

DFCT: Number of commits and bug reports

ENV: Environment

LCS: Licenses

QTP: Quality of the Testing Process

STD: Use of Established and Widespread Standards

PDOC: Project Documentation

Basic Level

PP2: Project Planning 2

DSN 1: Design 1

TST 1: Test 1

PMC: Project Monitoring and Control

PPQA: Process and Product Quality Assurance

STK: Stakeholders

RDMP2: Roadmap 2

TST2: Test 2

RSKM: Risk Management

DSN 2: Design 2

PI: FLOSS Product Integration

REP: Reputation

RASM: Results of third party assessment

CONT: Contributions

Intermediate Level Advanced Level


The OMM process model is expected to be useful for the followingusers:

• Companies that adopt/develop FLOSS projects• Companies that integrate FLOSS into their products• FLOSS community practitioners, such as developers (analysts,

programmers, testers) and FLOSS project managers

The main goals, the OMM users can reach are:• Improving their development processes following OMM practices• Development of a project by following OMM• Evaluation of a project hosted externally to the QualiPSo Factory• Evaluation of a project hosted internally to the QualiPSo Factory

Qualipso - OMM


Qualipso - OMM

Model Structure


Qualipso - OMM

Assessment process


Qualipso - OMM

Metrics collection


Qualipso - OMM

User’s requests Rating results

Assessment framework environment


0772E

5050D

3251C

1652B

0773A

practices not ratedrated practicestotal number of practicesratingTWE

3

2

1

0

2

0

1

2

3

A B C D E

Rat

ing

Rating Profile

0

1

2

3

4

5

6

7

8

A B C D E

TWE

numbe

r of p

ractices

practices not rated

rated practices

Qualipso - OMM

Rating

L’Assessor decide il valore finale del rating per ogni TWE

Rating calcolato sulla base delle metriche raccolte per ogni practice


Risultato di una sperimentazione condotta nel progetto Qualipso

Characteristics of the FLOSS software development are appropriately addressed in the assessment method

Comparazione tra OpenBRR, QSOS, Qualipso OMM

The process area in the assessment method cover all sig nificant software development process requirements and effectively reflec t activities that a software development organization should be accomplishi ng


The assessment is easy to understand and apply to a FLOSS community/organization

The assessment method does not impose constraints that wo uld limit and preventother organization from adapting the model to their own spe cific neeeds

Comparazione tra OpenBRR, QSOS, Qualipso OMM


Agenda


Introduzione • Framework e modelli di qualità• L’esperienza Engineering




La Qualità – Principi ispiratori

� Miglioramento continuo (caratterizzato da obiettivi "progressivi" dei quali si verifica, di volta in volta, il raggiungimento e dall’identificazione delle principali cause che producono il rework e conseguente aumento dei costi).

� Centralità del processo (il processo è il punto su cui concentrare gli sforzi di miglioramento per ottenere la qualità attesa nei prodotti e nei servizi che ne sono output).

� Coinvolgimento di tutta la struttura Aziendale (tutte le risorse appartenenti all'Azienda sono coinvolte nel processo di attuazione del Sistema Gestione Qualità).

“ la soddisfazione del Cliente

la riduzione del rework”


La Qualità – Certificazioni Engineering

� ISO 9001-2008

(da gennaio 1994)

� NATO AQAP-110/150

(da dicembre 1996)

� SW-CMM lev.2

(febbraio 2005)

� CMMi lev.3 (ottobre 2007)

Total Quality Management (TQM)

SIX SIGMA

ISO9001

COBIT ISOxxxx

BSxxxx CMM

CMMI PMBook

Prince ITIL

………..


Criteri di scelta dei modelli per la qualità

� Il prestigio e la diffusione internazionale del modello

� Il rigore metodologico

� La centralità sui processi (elemento chiave del modello aziendale)

� La ricerca dell’eccellenza e conformità nell’Organizzazione (che ègarante verso il Cliente), non solo nelle singole persone che nefanno parte

� La miglior copertura di tutti i processi coinvolti nella produzione/acquisizione/ integrazione di sistemi software e nell’erogazione di servizi di assistenza, manutenzione, formazione


Le vincite “perseguite”

• Disponibilità di “best practices” e “lesson learned” : le persone “entrano prima in partita” e “sbagliano meno”

• Modelli e template standardizzano il modo di operare: si riduce l’alea della soggettività individuale

• Gli strumenti indirizzano comportamenti e regole stabilite a priori: si riduce il rischio di deviare dalle policy predefinite.

• Inoltre, rendono immediati controlli e analisi diversamente complessi (es. tracciabilità requisiti per le analisi di impatto):si riduce il rischio operativo

• Metodi condivisi rendono fungibili le persone anche in contesti diversi:possibilità di crescita professionale dei singoli e riduzione del “rischio-persona”nei progetti

• Storicizzazione dei dati rende disponibili grandezze quantitative oggettive: sono possibili misure e identificazione di aree di intervento


Linee guida per lo startup del progetto

Nella fase di start up del progetto si procede alla selezione dei processi di PM necessari a soddisfare le esigenze di progetto.

Criterio guida per l’attivazione dell’infrastruttur a di PM: ” implementare ciò che da valore alla realizzazione”, ossia:

� Individuare i processi più critici, per i quali dovrà essere posta particolare attenzione nella gestione e nel monitoraggio per poi poter intraprendere azioni migliorative

� Individuare i processi produttivi più rispondenti alle esigenze per i diversi servizi da realizzare e adattarli al contesto

� Mettere a punto le Norme Operative che descrivono le modalità di implementazione delle attività regolate dalle procedure

� Individuare il livello di coinvolgimento di tutti gli attori e in particolare degli utenti, nei processo di sviluppo, manutenzione, assistenza;

� Mettere a punto i workflow previsti dai tools, selezionare le best practices e knowledge base più adatte al contesto, definire i processi decisionali

� Customizzare template, report ed eventualmente funzionalità dei tools ad es. per aggiungere informazioni specifiche per il Cliente ai workitems da gestire quali anomalie, requisiti, ecc.;

� Individuare le misure e la reportistica da produrre per soddisfare SLA


L’infrastruttura a supporto dei progetti di Engineering

Knowledge base Forum Chat

Estimation Risk ManagementCommunity

Peer Review

API Portal (Access Point to Information)

Project Plan

Requirements mangementTest management

Bugs trackingWorkflow

Projects RisksEstimationsBudget DB

MeasurementsDWH

Work Item andSW Configuration

Repository

Project PlanRepository

ETL Extractors

Data AnalysisReports / DashboardKPIs Management

MS Project Polarion and SVN


L’infrastruttura a supporto dei progetti

� Pubblicabile sul web, per la condivisione con il GdL� Templates predefiniti per la redazione� Analisi di avanzamento progetto

� Catalogazione; versioning; profilatura; pubblicazione web� Navigazione semplice (like “Gestione Risorse”) e motore di ricerca

Gestione documenti di progetto (Alfresco)

Rischi e Stime

MS Project per il Piano di Lavoro

� Zona Pericolo, rosso/giallo/verde per l’esposizione al rischio� Top Ten List, i primi dieci rischi di cui occuparsi� Alert automatici sulle stime di progetto� Un’alternativa alle stime Function Point, con modelli già predisposti� Repository storico stime e consuntivi, per raffronti act/bdg su insiemi di progetti


L’infrastruttura a supporto dei progetti

� Gestione requisiti, test, anomalie� Gestione configurazione software

� Tracciabilità bidirezionale dai requisiti ai prodotti del ciclo di sviluppo� Cruscotti e reports per l’analisi d’impatto delle variazioni

� Community� Dashboard di progetto � Comunicazioni “di servizio” nel gdl : chat, forum� Annunci e news� Problemi e suggerimenti� Calendario

Polarion per il ciclo di sviluppo

Altri servizi del portale


Il Il ciclociclo didi miglioramentomiglioramento

CARATTERIZZAZIONEDEFINIZIONE OBIETTIVIDEFINIZIONE MODELLI

CONSOLIDAMENTOCONOSCENZA

ANALISIDATI

CARATTERIZZAZIONEDEFINIZIONE OBIETTIVI

SCELTAPROCESSOSVILUPPO

ESECUZIONEPROCESSOSVILUPPO

ANALISIDATI

MISURE PRODOTTO

PROGETTO 1AZIENDAPROGETTO n

Analisi dei problemi �� Individuazione delle cause �� Definizione delle azioni di miglioramento


Agenda


Introduzione • Framework e modelli di qualità• L’esperienza Engineering




Processo di Misura – come misurare

La piattaforma è progettata per essere facilmente adattabile in contesti organizzativi complessi. Integra un sofisticato meta-modello che rende Spago4Q indipendente: dal processo da misurare e dalle applicazioni da cui raccogliere i dati.

E’ di supporto ad Organizzazione impegnate a perseguire obiettivi di miglioramento continuo, non solo nell’ambito dei processi di sviluppo software ma in generale nel monitoraggio di un proprio processo formalizzato.

Sviluppato con il contributo di University of Milan - Department of InformationTechnologySESAR (Software Engineering Software Architecture Research

Lab) http://sesar.dti.unimi.it/

www.spago4q.orgè un prodotto FOSS rilasciato con licenza (GNU LGPL)


Processo di Misura

Obiettivi: � creare un repository Aziendale

� fornire un cruscotto ai Responsabili di progetto

� raccogliere non invasivamente le misure

� supportare il processo MA del CMMI


Processo di Misura – cosa misurare – template per l’analisi

SEZIONE 1 - GQM

Obiettivo Domanda Concetto misurabile Indicatore / met rica Analisi ed interpretazione

SEZIONE 2 - MISURE

Dati per il calcolo di indicatori e metriche

Algoritmo per il calcolo di indicatori e metriche

Definizione delle Soglie

Correlazione con indicatori di altre aree di misura

Correlazione con practice del Modello di Qualità adottato

SP2.2 Analizzare i dati raccolti SP 2.4 Comunicare i risultati

SP1.2 Specificare le misureSP 1.3 Specificare le procedure di Data collectionSP2.1 Raccogliere i dati

SP2.3 Memorizzare i dati e i risultati

Mappatura con le Specific Practices del processo Measurement and Analisys del CMMI. Legenda:SP1.1 Stabilire gli obiettivi di misura

SP 1.4 Specificare criteri e procedure di analisi dei dati

Obiettivi: - non solo indicatori economici

Gli obiettivi di misura sono individuati sulla base di esigenze di business e di contenimento dei costi

Approccio Goal Question Metric


SEZIONE 3 - DATA COLLECTION

SEZIONE 4 - COMUNICAZIONE

Riservatezza

Grafico dell'indicatore

Destinatari indicatori e metriche

Attributi

Regole per acquisizione automatica

Filtraggio e trascodifica valori

SP2.2 Analizzare i dati raccolti SP 2.4 Comunicare i risultati

Sorgente dei dati

Frequenza di raccolta

Modalità di raccoltaSP1.2 Specificare le misureSP 1.3 Specificare le procedure di Data collectionSP2.1 Raccogliere i dati

SP2.3 Memorizzare i dati e i risultati

Mappatura con le Specific Practices del processo Measurement and Analisys del CMMI. Legenda:SP1.1 Stabilire gli obiettivi di misura

SP 1.4 Specificare criteri e procedure di analisi dei dati

Processo di Misura – cosa misurare – template per l’analisi


Processo di Misura – cosa misurare

� Chiavi in mano� Application Management

� Manutenzione ordinaria� Manutenzione evolutiva

Tipologie di progetto

Service desk

Utenti

Assistenza

Manut.Corr.

ChangeMan.

ReleaseMan.

ConfigMan.

Normative

Nuovo Svil.

Certif.QA

Rilascio

Sviluppo prodotto.

Infrastruttura Tecnologica

ProblemMan.

CollaudoChiusura

Servizi erogatiProject

Man. Ass. Qualità Misure

&Analisi



Gestione dei R

ischi

Rilascio

Processo di S

tima

Gestione del progetto

Gestione della C

onfigurazione

Assicurazi

one Qualità

Processo di M

isura

MACRO-FASI DI SVILUPPO

PROCESSIDI SUPPORTO

PROCESSO DI SVILUPPO

PR

OC

ES

SO

DI T

ES

T

Strumenti(Tools)

Procedure

Formazione

Miglioramento processi

Test

Sviluppo

Progettazione

An. requisiti

Modello di sviluppo

Unified ProcessAgile Modeling

Requir.

Analisys

Design

Develop.

Test

Release

Waterfall

EwebMo

Release

ReqAnalysisDesign

Development

Unit TestBuildInt/Sys. Test

Deploy

Differenti processi di sviluppoDifferenti processi di sviluppo



Aree di misura

CUSTOMER SATISFACTIONTasso milestones di progetto completate nei tempi previsti. COSTI-BUDGET Tasso scostamento budget di progetto

REQUISITI% scostamento effort risoluzione anomalie (pianificato vs consuntivato) Efficienza produttività : peso di una metafase sulla generazione delle anomalieVariabilità requisiti dettaglio (per mese)Trend variabilità requisiti ( per stato e per mese)MONITORAGGIODistribuzione requisiti per prioritàDistribuzione requisiti per categoria Distribuzione stato per categoriaPERFORMANCERequisiti completati (valore assoluto) Costo rework



ANOMALIEAndamento risoluzione bugsRispetto SLA nei tempi di risoluzione dei bug (per severità) MONITORAGGIODistribuzione Anomalie per severità e stato Distribuzione Anomalie per stato e fase di rilevazione Distribuzione Anomalie per stato e fase di origine Distribuzione Anomalie per severità e componente PERFORMANCECosto rework (La metafase gestione anomalie esiste già)Densità Anomalie per fase di rilevazione e di origine

QUALITA’Anomalie rilevate in acceptance test Peso delle anomalie gravi rilevate dopo il collaudoComplessità delle componenti sw. (indice diMc Cabe e altre metriche)Espressività del codice (metriche software)Manutenibilità del codice (metriche software)Quanto è riusabile (metriche software)Quanto è testato (metriche software)Manutenibilità (scostamento tra pianificato o SLA e consuntivato nella implementazione di una change request)



TEST% Copertura piano di test% Anomalie rilevate in Acceptance test (Efficacia del processo di test)Densità dei difetti per line di codice (o function point)PERFORMANCE% Test case eseguiti% test case che hanno rilevato una anomalia%test case che hanno rilevato più anomalieEfficacia peer review

PROJECT MANAGEMENTEarned valueScostamento costi per metafaseScostamento effort per metafaseScostamento durata per metafaseAFFIDABILITÀ STIME scostamento peso % delle metafasi tra prima stima e consuntivo

RISCHIRischi per stato Aperti/chiusi/ ecc, Rischi per gravità (zona rossa, gialla, verde)Rischi per categoria


Spago4Q – schema architettura


Spago4Q – flusso delle informazioni

Project repositories

Spago4QDWH

ComputationalRules

DashboardModels

Report

KPI Values

define resources (projects, products, services)define models (based on Goal Question Metrics or assessment framework CMMI, ISO 9001-2000)define KPIs and thresholdscreate relationships between resources, models, kpi s and thresholdsdefine ETL process and DWH dataextract information from measurement tools and load DWHcalculate KPIsdisplay the KPIs results, produce analytical docume nts


Spago4Q – Dashboard e reports

Reports

Dashboard


• Comprensione istantanea dell'andamento complessivo di un processo analizzato sulla base di differenti prospettive (es. economica, tecnica, sociale)

• Successiva analisi top-down per arrivare alla valutazione delle singole misure di base di ogni prospettiva.

Indicatore unico di performance di processo

Spago4Q – QESTnD Multidimensional model


L. Buglione and A. Abran, QEST nD: n-Dimensional Extension and Generalisation of a Software Performance Measurement Model, (2002) Advances in Engineering Software,


Un GQM per ogni dimensione:E = EconomicaS = SocialeT = Tecnica

www.semq.eu/leng/respre.htm

Open Source per la Qualità del software l'approccio di ... · Nessun costo di licenza (acquisto e...

Documents

Transcript of Open Source per la Qualità del software l'approccio di ... · Nessun costo di licenza (acquisto e...