Ingegneria del Software

Transcript

1 Seminario Ingegneria del Software Ingegneria del Software L esperienza Engineering Sergio Oltolina Senior Technical Manager Architetture e Consulenza Direzione Centrale Ricerca e Innovazione sergio.oltolina@eng.it Milano 12 maggio 2008

2 Engineering Azienda Ricavi S&S Personale 709 mln ricavi 1. IBM Italia Accenture Italia ENGINEERING 3. Almaviva Fonte: ComputerWorld Italia Dati settembre Microsoft HP Italia 512, EDS Italia 499, ASSETTO AZIONARIO Mercato 33% Soci fondatori 67%

3 Gruppo Engineering 35 sedi in Italia 2 sedi UE, a Bruxelles e Dublino Engineering Do Brasil a San Paolo per il Sud America dipendenti risorse esterne 800 clienti oltre 400 business specialists

4 Linee di Business e Segmenti di Mercato

5 Dir. Ricerca&Innovazione - Missione Ricerca 200 risorse dedicate 25 progetti acquisiti un network di oltre 50 partner internazionali Centro di ricerca e sviluppo di tecnologie per l'ingegneria del Software Studio e promozione di principi, metodi e tecnologie per il più largo beneficio di tutte le strutture aziendali. partecipazione in progetti di ricerca con cofinanziamento nazionale od internazionali disseminazione dei risultati in corsi, seminari, pubblicazioni, ecc.

6 Dir. Ricerca&Innovazione - Missione Innovazione Obiettivi Accelerazione dell'introduzione di nuove tecnologie Riduzione dei rischi (sperimentazione, valutazione, prototipazione, ecc.) Continuo aggiornamento delle conoscenze Supporto alle strutture aziendali (in fase di offerta e progetto) Idee per progetti di ricerca Sperimentazioni tecnologiche Componenti replicabili Ricerca Innovazione Produzione Risultati di progetti di ricerca Verifiche architetturali e tecnologiche Soluzioni replicabili

7 Il Business da Ricerca a Produzione La realtà il sistema ricerca non favorisce l innovazione di prodotto, ma di processo e conoscenza scarsi trasferimenti su prodotti (es.: IDEAS) trasferimenti significativi di competenze tecnologiche web (anni 90) web services, SOA, Grid (oggi) NESSI: competenza, infrastruttura OS, processo (domani)

8 Agenda Qualità e Miglioramento dei processi I Processi aziendali Qualità - CMMI Software Process Improvement un esempio In Engineering Lessons learned L infrastruttura a supporto dei progetti Infrastruttura API Mappatura processi CMMI - tools della infrastruttura API Le attività di misura Cosa e come misurare Il project management L avvio del progetto Approccio La scelta del modello di sviluppo Il modello di sviluppo Engineering La gestione dei rischi Il processo di stima Open source Le iniziative Engineering SpagoWorld Qualità nei prodotti OS Modelli di valutazione Qualipso Il percorso Engineering Lessons learned

9 Qualità e miglioramento dei processi L innovazione di processo I Processi aziendali Qualità CMMI Software Process Improvement

10 Processi aziendali Principio ispiratore la soddisfazione del Cliente e la riduzione del rework 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à).

11 Monit.&measur. processes Data collection & analysis Internal audit Customer Nonconf..mgt. Claims mgt. Processi aziendali Process Management responsibility Quality mgt. plan Mgt. review Quality Processes Document mgt. Record mgt. Process improvement Resource mgt. Prev.&corr. actions Purchasing IS&Products design&dev Consulting services IT services design&supply Training design&supply Customer Order mgt. Project mgt. Products & Services development processes

12 La Qualità Certificazioni Engineering ISO (da gennaio 1994) NATO AQAP-110/150 (da dicembre 1996) SW-CMM lev.2 (febbraio 2005) CMMi lev.3 (ottobre 2007) The Frameworks Quagmire (fonte:

13 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); l oggettività adottata nella misurazione delle prestazioni definite; la ricerca dell eccellenza e conformità nell Organizzazione (che è garante verso il Cliente), piuttosto che nelle singole persone che ne fanno 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. (alcuni modelli sono specializzati in comparti specifici, ma proprio per questo possono risultare più e forse troppo leggeri sugli altri).

14 CMMi Capability (qualità attesa dei risultati di un processo) Maturity (capacità di garantire la qualità dei prodotti in uscita dai processi) Model 5 Focus su un processo continuo di miglioramento I 5 Livelli di Maturità I 5 livelli di Maturità Optimising 4 Processi misurati e controllati Managed 3 Processi descritti e ben compresi Parola chiave omogeneità Defined 2 1 Progetti in grado di ripetere compiti preventivamente Definiti Parola chiave replicabilità Processi non prevedibili e Scarsamente controllati Parola chiave eroismo Initial Repeatable

15 ITIL per la gestione dei servizi Information Technology Infrastructure Library (ITIL) Definito in UK negli anni 90 Un set di specifiche a supporto degli IT managers per realizzare servizi di buon livello da erogare agli utenti Best practices per la gestione di servizi IT che indirizzano un approccio di qualità per ottenere efficacia ed efficienza nell utilizzo dei sistemi informativi. ITIL si basa sull esperienza collettiva acquisita a livello internazionale in attività commerciali e governative, che è stata distillata in un approccio consistente e coerente oggi largamente utilizzato come uno standard de-facto.

16 Processi Aziendali Business Sviluppo software Manutenzione software Requisiti tecnologici e operativi Rilascio nuovi sviluppi Rilascio modifiche Gestione problemi e change Help desk Incident Problem Change. Service Level Management CMMI ISO 9001:2000 ITIL Capacity Cost Security.. CMMI for Services (CMMI-SVC) draft

17 Il ciclo di miglioramento Bilanciare qualità del servizio di business (erogato globalmente) e costi Gestire i processi di erogazione dei servizi IT Definire responsabilità (Process Owner, Resp. Sviluppo sw, Resp. specifico servizio IT, Condividere e far conoscere processi e norme per facilitare la comunicazione ed eliminare le barriere tra reparti diversi Misurare Monitorare continuamente (confronto con gli SLA) Migliorare il processo (dialogo continuo con Cliente e Attori del processo)

18 Il ciclo di miglioramento AZIENDA CARATTERIZZAZIONE DEFINIZIONE OBIETTIVI DEFINIZIONE MODELLI CONSOLIDAMENTO CONOSCENZA PROGETTO n PROGETTO 1 CARATTERIZZAZIONE DEFINIZIONE OBIETTIVI SCELTA PROCESSO SVILUPPO ESECUZIONE PROCESSO SVILUPPO ANALISI DATI MISURE ANALISI DATI PRODOTTO Analisi dei problemi Individuazione delle cause Definizione delle azioni di miglioramento

19 Esempio - Processo di test Il Test è un processo autonomo parallelo e pervasivo rispetto al ciclo di sviluppo indipendentemente dal processo di sviluppo adottato procede in modo continuo dall avvio del progetto fino alla sua conclusione con lo scopo di verificare e sottoporre a validazione tutti gli oggetti prodotti nel corso dello sviluppo per ottenere un prodotto finale pienamente utilizzabile che soddisfa i requisiti in modo accettabile, esente da difetti.

20 Esempio - Processo di test Analisi dei Requisiti Disegno Archietturale Verifica Codifica Test Rilascio Validazione

21 Esempio - Processo di test Best Practices Definire una strategia per affrontare il test Considerare tutte le tipologie di test ( non solo test funzionale) Individuare i rischi Progettare i casi di test considerando il punto di vista dell utente (use case,scenari, operatività) Automatizzare procedure ripetitive Analizzare le cause delle anomalie per intervenire sul processo

22 Lesson Learned 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, analisi earned value): si riduce il rischio operativo Storicizzazione dei dati rende disponibili grandezze quantitative oggettive: sono possibili misure e identificazione di aree di intervento Metodi condivisi rendono fungibili le persone anche in contesti diversi: possibilità di crescita professionale dei singoli e riduzione del rischio-persona nei progetti Liv 2 e 3 Replicabilità: I progetti sono in grado di ripetere sistematicamente i compiti di cui sono incaricati, perché i processi adottati nascono da metodi comuni e consolidati Omogeneità: soluzioni standard a livello di organizzazione, contestualizzate al singolo progetto Strumenti : tools ed applicazioni per il progetto = esperienza codificata. Gli strumenti diventano il wizard per lavorare secondo le regole dell organizzazione.

23 Lesson Learned L applicazione di un metodo e l uso degli strumenti richiede disciplina E necessario considerare le resistenze al cambiamento Il tempo speso nell analisi e prevenzione dei problemi ha sempre ritorni positivi

24 Il project management Il project management L avvio del progetto Approccio La scelta del modello di sviluppo Il modello di sviluppo Engineering La gestione dei rischi Il processo di stima Lessons learned

25 Il Progetto Contesto di Riferimento Tipologie di progetto: Sviluppo ex-novo Manutenzione ordinaria Manutenzione evolutiva Elementi caratterizzanti: Dimensione Ambiente: Grado di innovazione Rischio Gruppo di lavoro (Team) Tempo Fattori determinanti: Scopo (requisiti, caratteristiche) Piano (tempi e costi) Qualità (difetti) Risorse (Team)

26 L avvio del progetto Criterio guida per l attivazione l dell infrastruttura a supporto dei progetti: implementare ciò che da valore alla realizzazione 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

27 Il Processo di sviluppo Il Focus del CP è sul Processo Il risultato di entrambi è il PRODOTTO Il Focus del GdL è sul Prodotto

28 Modello di sviluppo - Metodologie Affrontare il tema delle metodologie di sviluppo è particolarmente delicato perchè: il tema è vasto esiste ponderosa letteratura ed esperienza sia nella Ricerca che nell Industria si rischia di rimanere chiusi in un ambito teorico. L aspetto critico da affrontare e risolvere è: individuare un organizzazione efficiente che tramite l esecuzione ottimale dei processi interni consenta una crescita nel mercato con il mantenimento di assetti organizzativi stabili, anche se tatticamente adattabili all evoluzione del contesto indotta dal mercato stesso.

29 Il Processo Modelli Waterfall Requisiti An.Funz. Modello evolutivo: Unified Process Progett. Modello lineare: EwebMo Sviluppo Test Rilascio Agile Modeling Modello adattivo:

30 Modello di sviluppo 6 buoni motivi per: affrontare lo sviluppo software in presenza di: requisiti non certi ambiente di sviluppo non certo ambiente di erogazione certo e non adattabile risorse umane creative ed indipendenti ridurre i costi di sviluppo (utilizzo ripetuto di tools e standard) rispettare tempi e costi di sviluppo favorire il riuso (componenti, conoscenza) migliorare il processo con l adozione di un approccio ripetibile crescere assieme: senza metodo, emerge solo chi possiede particolari caratteristiche naturali (metafora dello sport)

31 PROCESSO DI SVILUPPO MACRO-FASI DI SVILUPPO PROCESSI DI SUPPORTO Analisi dei Requisiti PROCEDURE STRUMENTI (TOOLS) PROCESSO DI TEST Modello di Sviluppo Processo di Misura Assicurazione Qualità Gestione della Configurazione Gestione del progetto Processo di Stima Gestione dei Rischi Progettazione Sviluppo Test Rilascio

32 Il Processo Contesto dell Agilit Agilità La scelta del processo può essere fatta in base a considerazioni su rischio di progetto, tecnologia, variabilità dei requisiti. Tecnologia Requisiti Innovativa, non nota Innovativa, nota Familiare Ben conosciuta Irregolari Instabili Normali Stabili J. Highsmith: Adaptive Software Development

33 Il Processo Appr. Evolutivo-Iterativo Combinazione di approccio Risk-driven e Client-driven Risk-driven Sceglie gli aspetti più rischiosi, più difficili per le prime iterazioni (soprattutto dal punto di vista architetturale) Client-driven La scelta delle features da sviluppare nelle prime iterazioni è fatta dal cliente che sceglie le caratteristiche di maggior valore per lui Scelta nelle prime iterazioni delle caratteristiche tecnicamente più rilevanti e difficili (di interesse per chi sviluppa) e di maggior valore di business (di interesse per il cliente) + QUALITA + VALORE

34 Gestione Rischi Gestire il rischio di un progetto significa occuparsi attivamente del suo successo (R. Meli) Il rischio è connaturato ad ogni processo di sviluppo: è legato ad eventi futuri è legato al cambiamento è collegato alle scelte (area di indeterminatezza) La gestione dei rischi è essenziale nei processi di sviluppo evolutivi/iterativi: controllo delle iterazioni

35 Gestione Rischi FASE DI REALIZZAZIONE DEL PROGETTO M onitoraggio Identificazione e Classificaz ione dei rischi Valutazione dei risch i Identificazione e Pianificazione delle az ioni Attuaz ione az ioni definizioni e verifiche dei fatti, eventi situazioni priorità, pesi, opp ortunità piani e az ioni, perfezionam enti Identificaz ione e Classificaz ione dei rischi Valutazione dei rischi Identificazione della soluz ioni di progetto FASE DI PREPARAZIONE DEL PROGETTO

36 Processo di stima Il problema di stimare i costi di sviluppo software è critico per le organizzazioni che devono conoscere nel modo più accurato possibile la dimensione e l impegno di realizzazione prima di procedere all avvio di un progetto, momento in cui le informazioni utilizzate per la stima si possono basare su requisiti incompleti o errati. La stima dello sviluppo software deve fornire due informazioni per decidere se affrontare lo sviluppo di un progetto: la dimensione del costo di sviluppo la dimensione del tempo necessario attraverso la: scomposizione del problema individuazione del ciclo di sviluppo stima delle dimensioni del software da sviluppare.

37 Processo di Stima Metriche di stima Dimensionali interne Source Lines of Code (SLOC) Dimensionali esterne (funzionali) Function Points (FP) Objects Points, Web Objects Metrica Metrica FP: FP: External ExternalInputs (EI) (EI) External ExternalOutputs (EO) (EO) External ExternalInquiries (EQ) (EQ) Internal Internalfile file (ILF) (ILF) External ExternalInterfaces (EIF) (EIF) Approccio Approccio tradizionale tradizionale Giudizio Giudizio degli degli esperti esperti Function FunctionPoint Analysis Analysis COCOMO COCOMO Metodi di stima Metodi diretti (giudizio degli esperti, stime per analogia) Metodo derivati (algoritmici o parametrici) Stime per decomposizione Stime process oriented Approccio Approccio evolutivo evolutivo COCOMO COCOMO II II WEBMO WEBMO (J. (J. Reifer) Reifer) EwebMO EwebMO (Engiweb.com) (Engiweb.com)

38 Processo di Stima STIMA INIZIALE Piano di lavoro iniziale OFFERTA RISTIMA AD AVVIO PROGETTO ESTIMATION TOOL ACCOUNTING DB PROGETTO STIME/RISCHI DB AZ. RISTIMA IN CORSO PROGETTO Monitoraggio scostamenti AGGIORNAMENTO PIANO DI LAVORO

39 Lesson Learned Nei progetti reali requisiti incompleti, instabili o ambigui specifiche (dei requisiti) non interpretate correttamente specifiche (dei requisiti o dei test) non aggiornate data di fine progetto anticipata data di fine progetto non prorogabile (tempi stretti di progetto) attività sottostimate o costo imposto l utente finale non è stato coinvolto (il Cliente non è l utente finale del sistema) incomprensioni tra le Unità Organizzative difficoltà di comunicazione nel gruppo di lavoro

40 Lessons Learned Persone Definizione dello stile di commitment Comunicazioni di progetto Aspetti organizzativi di supporto Modalità e capacità di gestione del team Individuazione key-user Formazione Supporto all avvio Problema Portata del problema (contesto, obiettivi, funzionalità, aspetti particolari, ) e suoi confini Processo Organizzazione, procedure, mezzi (tools) e consuetudini (practices) utilizzate per sviluppare uno specifico progetto o prodotto software; il ciclo di sviluppo indica le strategie secondo le quali è organizzato il processo di sviluppo

41 Lesson Learned Modello flessibile: procedure a bassa prescrittività utilizzo di practices linee guida di riferimento ampia scelta di modelli e tools di supporto knowledge base (e rete di competenze) di supporto

42 Lesson Learned Adozione di practices anticipare il test sviluppi time-boxed gestione dei trade-offs utilizzo di use cases o user stories riutilizzo delle risorse esistenti documentare quando necessario comunicazioni strette peer review (ispezionare la progettazione ed il codice) test automatici di non regressione, se possibile

43 Infrastruttura API (Access Point Information) L infrastruttura a supporto dei progetti Infrastruttura API Mappatura processi CMMI - tools della infrastruttura API Le attività di misura cosa e come misurare

44 Infrastruttura API (Access Point Information) Componenti della infrastruttura: Descrizione dei processi Definizione procedure, modelli, practices Ambiente a supporto dei progetti (Portale API) In corso di sperimentazione e implementazione Ambiente per la raccolta dati e la misura dei processi di sviluppo (Spago4Q)

45 Infrastruttura API (Access Point Information) CMMI istituzionalizza i processi Practices Agili permettono alta flessibilità ed adattabilità e possono rendere più efficiente l implementazione del CMMI mediante: Collaborazione con l utente per identificare le funzionalità importanti, definire gli use case e le priorità di realizzazione Anticipazione delle attività di testing Rilasci frequenti (bisettimanali o mensili) del software realizzato Automatizzare quanto più possibile le attività ripetibili di build, deploy e test. Peer review tecniche e condivisione con l utente

46 Infrastruttura API (Access Point Information) API Portal (Access Point to Information) ECM Estimation Forum Chat Projects Table Peer Review Risk Management Projects Risks Estimations Budget DB MS Project Server / Web Access Project Plan and Balance Management Tools Project Plan Repository Polarion and SVN Requirements mangement Test management Bugs tracking Workflow Collaboration Work Item and SW Configuration Repository ETL Extractors Data Analysis Reports / Dashboard KPIs Management Measurements DWH

47 Infrastruttura API (Access Point Information) Il bignami In 50 righe : I principali eventi di un progetto Cosa fare e chi lo deve fare Quali strumenti usare (tools e modelli di infrastruttura) Normativa di riferimento (link al SGQ) La libreria delle Lessons Learned : condivisione di esperienze e di conoscenza Piano di lavoro, wbs, piano di configurazione,.. precompilati e pronti all uso Rischi ricorrenti nei progetti sw quanto impatto e quali azioni mitiganti Pillole di letteratura tecniche di stima, cicli di sviluppo, processo di test Esperienza Engineering di cui far tesoro best practices di progetti La normativa Aziendale Il Sistema Gestione Qualità, le Procedure di Gruppo,.

48 Infrastruttura API (Access Point Information) Gestione documenti via CM open source exo Catalogazione; versioning; profilatura; pubblicazione web Navigazione semplice (like Gestione Risorse ) e motore di ricerca Rischi e Stime 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 MS Project server 2003 per il Piano di Lavoro Pubblicabile sul web, per la condivisione con il GdL Templates predefiniti per la redazione Analisi automatiche di avanzamento progetto (Earned Value)

49 Infrastruttura API (Access Point Information) Polarion per il ciclo di sviluppo 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 Altri servizi del portale Il registro dei miei progetti Dashboard di progetto : actual/budget, zona pericolo Comunicazioni di servizio nel gdl : chat, forum Annunci e news Problemi e suggerimenti Collegamenti utili

50 Infrastruttura API (Access Point Information) Pianificazione e controllo (PP e PMC) Stime Deve esistere un metodo di stima condivisibile Devono essere fatte le ristime periodiche Tool di stima API In alternativa Metodo proprio documentato Piano di lavoro Deve esistere un piano di lavoro aggiornato periodicamente Devono essere pianificate review e riesami interni al Gdl o con DAQ Le risorse devono essere assegnate alle attività Le attivita devono essere consuntivate In caso di deviazioni definire azioni correttive Microsoft project Server ed eventualmente consuntivazione con Polarion delle attività di realizzazione (time-boxed non superiori a 4/6 settimane)

51 Infrastruttura API (Access Point Information) Gestione requisiti (REQM, RD) Requisiti Devono essere censiti e categorizzati (Funzionali, interfaccia, tecnologici,..), Deve essere definita l importanza del requisito per l utente Deve essere gestito lo stato e le variazioni del requisito Deve essere gestita la tracciabilità requisito-test case Practices: deve essere compreso il punto di vista dell utente tramite prototipi e use case. Tool Polarion Gestisce il workflow dei requisiti e l assegnazione ai tasks di analisi, sviluppo, test. Gestione change Request Gestisce notifiche automatiche; a fronte di variazioni sono notificate le persone interessate.

52 Infrastruttura API (Access Point Information) Sviluppo (TS, PI) Sviluppo Deve esistere un documento che descrive l architettura del sistema e come sarà implementata Deve esistere un documento di progettazione tecnica e di descrizione delle interfacce (se necessario) Devono essere eseguite build e deploy del prodotto Practices: è opportuno che i rilasci siano frequenti e che l utente possa condividere la soluzione sviluppata. Tool Polarion e tool per automatizzare build e deploy Gestione dei task di sviluppo Automazione di build e deploy

53 Infrastruttura API (Access Point Information) Gestione della configurazione (CM) Gestione della configurazione software e documentale Deve esistere un tool per la gestione della configurazione Tool Svn e portale API Svn può essere utilizzato per il software e per i documenti Il portale può essere utilizzato per la pubblicazione di documenti da condividere Risk Management (RSKM) Rischi Devono essere censiti Devono essere definite le azioni di contingency Devono essere periodicamente monitorati Tool gestione rischi API

54 Infrastruttura API (Access Point Information) Verifica e validazione (VE, VA) Verifica Devono essere eseguite le peer review (documenti di architettura e progettazione) tool peer review API Verbale e consuntivazione peer review Validazione Deve esistere un master test plan Devono essere descritti i test case, i test case devono essere correlati ai requisiti Devono essere gestite le anomalie Practices: gli use case aiutano ad identificare i test case. Il processo di test deve essere avviato parallelamente alla fase di analisi e sviluppo tool Polarion Gestione dei test case e della tracciabilità con i requisiti Gestione anomalie

55 Processo di Misura Obiettivi: - creazione di un repository Aziendale - cruscotto per il capo progetto e i responsabili di Unità org. - raccolta non invasiva delle misure

56 Processo di Misura cosa misurare Obiettivi: SEZIONE 1 - GQM - non solo indicatori economici Gli obiettivi di misura sono individuati sulla base di esigenze di business e di contenimento dei costi Obiettivo Domanda Concetto misurabile Indicatore / metrica Analisi ed interpretazione SEZIONE 2 - MISURE Algoritmo per il calcolo di indicatori e metriche Definizione delle Soglie Dati per il calcolo di indicatori e metriche Correlazione con indicatori di altre aree di misura Correlazione con practice del Modello di Qualità adottato Mappatura con le Specific Practices del processo Measurement and Analisys del CMMI. Legenda: SP1.1 Stabilire gli obiettivi di misura SP1.2 Specificare le misure SP 1.3 Specificare le procedure di Data collection SP2.1 Raccogliere i dati SP 1.4 Specificare criteri e procedure di analisi dei dati SP2.3 Memorizzare i dati e i risultati SP2.2 Analizzare i dati raccolti SP 2.4 Comunicare i risultati

57 Processo di Misura cosa misurare SEZIONE 3 - DATA COLLECTION Sorgente dei dati Attributi Frequenza di raccolta Modalità di raccolta Regole per acquisizione automatica Filtraggio e trascodifica valori SEZIONE 4 - COMUNICAZIONE Destinatari indicatori e metriche Mappatura con le Specific Practices del processo Measurement and Analisys del CMMI. Legenda: SP1.1 Stabilire gli obiettivi di misura SP1.2 Specificare le misure SP 1.3 Specificare le procedure di Data collection SP2.1 Raccogliere i dati SP 1.4 Specificare criteri e procedure di analisi dei dati SP2.3 Memorizzare i dati e i risultati SP2.2 Analizzare i dati raccolti SP 2.4 Comunicare i risultati Riservatezza Grafico dell'indicatore

58 Processo di Misura cosa misurare Aree di misura CUSTOMER SATISFACTION Tasso 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 anomalie Variabilità requisiti dettaglio (per mese) Trend variabilità requisiti ( per stato e per mese) MONITORAGGIO Distribuzione requisiti per priorità Distribuzione requisiti per categoria Distribuzione stato per categoria PERFORMANCE Requisiti completati (valore assoluto) Costo rework

59 Processo di Misura cosa misurare ANOMALIE Andamento risoluzione bugs Rispetto SLA nei tempi di risoluzione dei bug (per severità) MONITORAGGIO Distribuzione 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 PERFORMANCE Costo 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 collaudo Complessità 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)

60 Processo di Misura cosa misurare 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ù anomalie Efficacia peer review PROJECT MANAGEMENT Earned value Scostamento costi per metafase Scostamento effort per metafase Scostamento durata per metafase AFFIDABILITÀ STIME scostamento peso % delle metafasi tra prima stima e consuntivo RISCHI Rischi per stato Aperti/chiusi/ ecc, Rischi per gravità (zona rossa, gialla, verde) Rischi per categoria

61 Processo di Misura come misurare è un prodotto FOSS rilasciato con licenza (GNU LGPL) 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 InformationTechnology SESAR (Software Engineering Software Architecture Research Lab)

62 Spago4Q - Architectural overview Project repositories Meta Model & DataWareHouse Analytical tool PM repositories Cost (budget, estimation, actual risk) (MSOffice, OpenOffice) Artifacts repositories SVN CVS Polarion Development tools Eclipse Extractors Interfaces Staging Area ETL Spago4Q Meta Model ETL DM Measure1 DM Measure 2 DM Measure.. Dashboard Report OLAP What If Data mining Configuration&Administration Config&Admin Repositories Data source connection Thresholds value management Access control list

63 Spago4Q - Meta Model Methodology Organization Project Access control based on the user profile Requirements Bug KPI Test Measurement framework Assessment framework

64 Spago4Q - Definizione metriche e configurazioni Le metriche sono individuate con un approccio GQM(Goal Question Metric) Ogni progetto può personalizzare le soglie definite come standard. Le metriche possono essere associate a modelli di qualità (CMMI, ISO, altri) per verificare l adempimento delle practices. La raccolta delle misure è non invasiva 16 Project functional technical performance availability Project name Information Need (GQM) must should could would 0 Evaluation Instability requirements KPI TVR = Requirements variability # Req. Nuovi # Req. Modificati # Req. Cancellati Practice # Req. Approvati # Req. Censiti CMMI : REQM SP 1.3

65 Open Source Open source Le iniziative Engineering SpagoWorld Qualità nei prodotti OS Modelli di valutazione Qualipso Il percorso Engineering

66 Engineering dal 2001 sviluppa e gestisce software Open Source (qualità, innovazione, open standard, ) Supporto professionale (Open Source Software Network) Diffusione delle soluzioni (consorzi, relazioni, ) Coinvolgimento di diversi soggetti (università, ricerca, ) Alleanze e sinergie (aziende OSS, contribuzioni, ) Focalizzazione su iniziative industriali (progetti, aziende, utenti, ) Sviluppo continuo di nuove integrazioni

67 SpagoBI 2.0 Business Intelligence SpagoBI Server, la piattaforma di integrazione SpagoBI Studio, l'ambiente di sviluppo integrato SpagoBI Meta, il nuovo ambiente focalizzato sui metadati SpagoBI SDK, il nuovo layer di integrazione per usare SpagoBI da applicazioni esterne Il Modello Analitico di SpagoBI Server offre diverse soluzioni per ogni area analitica: Reports, per presentare dati strutturati Analisi OLAP, per navigare attraverso i dati Dashboards in tempo reale, per monitorare i KPI Processi di data mining Statistiche geo-referenziate, per pubblicare con una rappresentazione geografica i dati archiviati in normali data warehouse free inquiry (QbE), per comporre liberamente le proprie interrogazioni, dossier analitici, per condividere e archiviare informazioni pubbliche e private documenti office, per pubblicare documenti office sotto il governo del model comportamentale processi ETL/EII per raccogliere dati da molte e diverse sorgenti

68 Spagic Spagic è una infrastruttura che integra un insieme di strumenti visuali e di applicazioni di back-end rivolti alla progettazione, sviluppo e gestione di soluzioni SOA/BPM.

69 Un unica visione Free software: nessuna vendita di licenze (GNU LGPL) Approccio Piattaforma di Integrazione vs Prodotto Consentito l uso commerciale (anche in soluzioni proprietarie) Attenzione a progetti e servizi: vendita di competenza nello sviluppo di progetti (bisogni degli utenti, requisito e peculiarità dei progetti) Attenzione all uso industriale Apertura alla comunità e alle esigenze della ricerca Creazione di un ecosistema del valore Un segno distintivo nel dominio Open Source

70 OW2 Consortium La scelta obbligata di non agire da soli Engineering Co-fondatore e Membro Strategico del Consorzio OW2 Mission The mission of the consortium is to develop open source middleware* and to foster a vibrant community and business ecosystem

71 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à Motivazioni politico-industriali 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 di 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 )

72 Come scegliere il software OS Nessun costo di licenza (acquisto e gestione) Diverso TCO (Total Cost of Ownership) VANTAGGI 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 Non tutto il FLOSS è uguale: bisogna saper valutare e scegliere! CRITICITA Test più elevato in fase di rilascio Identificazione delle soluzioni in-house 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

73 Qualità FOSS QSOS (Atos Origin) Open Source Maturity Model (Navica) Open Source Maturity Model (Cap Gemini) Open Source Catalogue (Optaros) OSS Watch IRCA (Weehler) ohloh OpenBRR (Carnegy Mellon e altri) Il software open source non è intrinsecamente di qualità superiore a quello proprietario, ma la sua qualità è misurabile direttamente dall utilizzatore

74 R&S Qualipso QualiPSo is a unique alliance of European, Brazilian and Chinese ICT industry players, SMEs, governments and academics to help industries and governments fuel innovation and competitiveness with Open Source software. To meet that goal, the QualiPSo consortium intends to define and implement the technologies, processes and policies to facilitate the development and use of Open Source software components, with the same level of trust traditionally offered by proprietary software.

75 Qualipso - Attività LEGAL ISSUES: Providing guidelines and tools to facilitate an intellectual property tracking process with open source, and defining a coherent family of OSS licenses, compliant with national laws and European regulations. BUSINESS MODELS: Defining methods, development processes, and business models to facilitate 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 to assessing 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, an integrated next generation forge that will facilitate and support the development of viable industrial OSS systems. COMPETENCE CENTER: Developing a long lasting network of professionals caring for the quality of Open Source Software for enterprise computing. Six QualiPSo Competence Centres - 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. Of these Competence Centres, four will be based in Europe (in Berlin, Madrid, Paris, Rome), one in China and one in Brazil (São Paulo).

76 Il percorso - Modello di business Project Centric Il fine è la realizzazione del progetto del committente per il quale la soluzione open source offre caratteristiche preferibili ad una soluzione proprietaria quali disponibilità, apertura, modificabilità, modularità, integrabilità, adattabilità, riusabilità e scalabilità. Il progetto vale molto di più della soluzione adottata. L OSS è un mezzo per la realizzazione di progetti applicativi che a loro volta sono un mezzo per la crescita del software OS. Si utilizza l OS per soddisfare i requisiti dei committenti nel costruire nel miglior modo possibile un applicazione che risulta sempre realizzata su misura e quindi adatta ; Si restituiscono alla comunità nuovi requisiti, nuovi sviluppi, feedback e contributi. Open Source e modelli di business: come creare valore per le PPAA. - Il system integrator ed il caso Engineering - G. Ruffatti, convegno PAAL 2007 di Pula (Cagliari), marzo

77 Il percorso - Tre direzioni per sostenere SpagoWorld Opportunità di Business in Engineering (progetti) fuori Engineering (progetti, servizi, partnership) Reputazione qualità, fiducia eventi, network, riviste, blogs agenzie di ricerca e consulenti (Ventana, Smile, Forrester, TWDI ) accademia Crescita della Comunità in Engineering: users groups fuori Engineering (supporto, Community day) Verso un Ecosistema del Valore

78 Il percorso L intelligenza collettiva e l innovazione richiedono un forte impulso al riuso: ricombinazione innovativa di soluzioni, conoscenze e esperienze Un azienda culturalmente agile è un azienda che sa governare l incertezzal

79 Tesi Sistema di misurazione di prodotti e comunità open source all interno di un forge. Analisi e valutazione dei modelli di misura esistenti, definizione di un modello e sua implementazione prototipale per il forge di una comunità. Valutazione e scelta di prodotti open source per la creazione di un ambiente di test per progetti sviluppati in architetture SOA composto da sistemi per il Test Management e per l esecuzione automatica di test.