Linee guida allo sviluppo di software riusabile multiuso per la Pubblica Amministrazione. Gianluigi Raiss Dirigente CNIPA

Transcript

1 Linee guida allo sviluppo di software riusabile multiuso per la Pubblica Amministrazione Gianluigi Raiss Dirigente CNIPA

2 Agenda Considerazioni i i introduttive tti sulla attuale scarsa efficienza del riuso nella P.A. Contenuti, destinatari e uso delle linee guida La strategia proposta per aumentare l efficienza del riuso del software nella P.A. Conclusioni Sviluppare per il riuso 1

3 Considerazioni introduttive sulla attuale scarsa efficienza del riuso nella P.A. Sviluppare per il riuso 2

4 Motivazioni al riuso di software Perché si ricorre al riuso? Contenimento della spesa. Abbreviamento dei tempi di sviluppo. Recupero di esperienze progettuali e organizzative consolidate e sperimentate. Miglioramento progressivo della qualità delle applicazioni e del know how sul loro utilizzo. Standardizzazione dei software e miglioramento della facilità di manutenzione ed evoluzione. Standardizzazione dei modelli di dati. Sviluppare per il riuso 3

5 I costi del riuso Riusare ha sempre un costo. I costi del riuso sono aggregabili in 6 categorie. Costi di analisi preliminare del progetto. Costi di progettazione dell intervento t di riuso. Costi di realizzazione dell intervento. Gestione del progetto. Trasferimento di know how e change management. Bonifica e normalizzazione banche dati. Adattamento del software riusato. Costi finanziari legati all acquisto di tecnologia ICT. Costi di adeguamento dei processi, informazione e sensibilizzazione all utilizzo dei nuovi servizi. Costi di gestione operativa e manutenzione post-riuso. Sviluppare per il riuso 4

6 Una evidente contraddizione Il riuso di software nella P.A., nonostante il CAD (ed altre norme) non ha finora prodotto un apprezzabile miglioramento dei parametri target del riuso. I cataloghi di software riusabile della P.A. sono semi vuoti, si fa poco riuso e i costi del riuso sono quasi sempre alti. I costi di manutenzione rimangono alti. Eppure, la P.A. è complessivamente proprietaria di oltre 13,2 milioni di function point equiv.di software custom. (1) La P.A. prevede poi di spendere per il 2009 circa 249 milioni di euro in acquisto di software applicativo custom (e 705 nel ). (2) (1) Fonte Relazione annuale CNIPA per il 2007 (2) Fonte Piano triennale CNIPA Sviluppare per il riuso 5

7 Perché si riusa poco nella PA? Perché il riuso non è ancora una soluzione efficiente i nel razionalizzare le spese IT della P.A.? Le cause sono molte, sia organizzative, sia tecniche. Un possibile primo elenco di cause ne individua almeno 10, 4dinatura organizzativa e 6 di natura tecnica. Sviluppare per il riuso 6

8 Limitazioni di natura organizzativa (1/2) 1) Troppi centri di spesa nella P.A., difficili da coordinare nelle loro politiche di acquisto. 2) Mancanza di incentivi al riuso: le singole P.A. non percepiscono il vantaggio di cedere in riuso ad altre P.A. il proprio software, né di rendere il proprio software più facilmente riusabile. 3) Non è facile quantificare i costi del riuso ex ante (per decidere se riusare), ed ex post (per fissare cosa pagare a chi ha realizzato il progetto di riuso). Mancano metriche condivise e standard per misurare il riuso (in termini dimensionali) e per assegnargli un valore economico. Sviluppare per il riuso 7

9 Limitazioni di natura organizzativa (2/2) 4) Sono ben poche le regole del riuso note e condivise nella comunità dei potenziali soggetti interessati al riuso. In particolare andrebbero fissati in modo univoco: Aspetti giuridici (diritti di proprietà, limitazioni di responsabilità, concetto di opere derivate.). Topologia e organizzazione dei cataloghi dove reperire il software riusabile, Semantica e sintassi per descrivere i contenuti dei cataloghi. Modalità di inserimento e prelievo di software dai cataloghi, responsabilità in merito all aggiornamento del software presente nei cataloghi, gestione della configurazione e della documentazione. Sviluppare per il riuso 8

10 Limitazioni di natura tecnica (1/6) 1) C è poco software disponibile per essere riusato. La principale giustificazione delle P.A. è la specificità delle loro applicazioni custom. Il riuso più frequente nella P.A. è quello di intere applicazioni software, le cui specifiche funzionali sono però solo in parte esportabili da una amministrazione ad un altra. (ri)-adattare le specifiche funzionali di una applicazione software è un operazione costosa (richiede anche di rifare l analisi funzionale e di riscrivere le specifiche). Ogni P.A. che riusa vuole poi introdurre personalizzazioni al prodotto, che hanno anch esse un costo non trascurabile. Sviluppare per il riuso 9

11 Limitazioni di natura tecnica (2/6) 2) Non circolano molte informazioni sul software disponibile nella P.A. per il riuso. Poche P.A. hanno un catalogo del proprio p software applicativo (tanto meno di quello riusabile ). I pochi esistenti non sono tra loro collegati, né sono indicizzati in repertori pubblici o consultabili dall esterno esterno. Sviluppare per il riuso 10

12 Limitazioni di natura tecnica (3/6) 3) La documentazione progettuale e di manutenzione associata al software da riusare è spesso carente. Raramente i produttori forniscono all acquirente, insieme al software, tuttitti i documenti pogett progettuali, i casi di test e ogni altra documentazione in forma utile per facilitare un possibile riuso del software. Le notazioni usate nei documenti progettuali non sempre sono standard, i documenti sono spesso incompleti o non aggiornati. Spesso la documentazione disponibile non permette neppure di comprendere se un determinato prodotto può essere o no candidato al riuso (in base all esame delle specifiche funzionali e tecniche). Sviluppare per il riuso 11

13 Limitazioni di natura tecnica (4/6) 4) Il software applicativo custom di proprietà della P.A. non è stato progettato per essere riusato. Non è quasi mai stato progettato con una architettura a componenti singolarmente riusabili, in modo che anche solo singoli componenti funzionali e tecnici possano essere riusati. Le caratteristiche tecniche del software applicativo esistente non sono quasi mai quelle ottimali per il riuso. Manca, del resto, una definizione standard degli attributi che connotano un software riusabile (nella ISO/IEC 9126 la riusabilità non è normata). La qualità del software disponibile al riuso non è quasi mai certificata. Sviluppare per il riuso 12

14 Limitazioni di natura tecnica (5/6) 5) I software custom della P.A. hanno spesso dipendenze tecnologiche non facilmente eliminabili. I prodotti software custom sviluppati per la P.A. sono stati spesso realizzati a partire da pacchetti applicativi proprietari, dai quali non sono facilmente separabili: per riusarli, occorre acquistare le licenze d uso di tali pacchetti. Il software open source è ancora raro nella P.A. Molti software custom della P.A. sono vincolati a usare solo determinati middleware,, sistemi operativi etc il cui uso impone al soggetto riusante altri costi. Molti software custom della P.A. candidati al riuso sono vecchi di molti anni e quindi parzialmente inefficienti rispetto allo stato dell arte della tecnologia e difficili da inserire in altri contesti tecnologici più aggiornati. Sviluppare per il riuso 13

15 Limitazioni di natura tecnica (6/6) 6) Il riuso non deve limitarsi al codice sorgente! Il valore del codice sorgente in un progetto di sviluppo software non supera in genere il 20-30% del costo complessivo dello sviluppo. Unaincidenzaanalogahalafasedispecificadeirequisitie di progettazione tecnica, così come il testing. Eppure, finora il riuso ha riguardato molto poco gli elementi non software : schemi progettuali, patterns, casi di test, schemi di dati e di documentazione. Riusare anche questi elementi può aumentare notevolmente l efficienza del riuso. Sviluppare per il riuso 14

16 Contenuti, destinatari e uso delle linee guida Sviluppare per il riuso 15

17 Le linee guida del CNIPA Per contribuire tib i a superare le cause della attuale inefficienza del riuso di software nella P.A., il CNIPA ha pubblicato un documento Linee guida allo sviluppo di software riusabile multiuso che, partendo dall analisi di queste cause, propone per quelle di natura tecnica e per parte di quelle organizzative delle soluzioni per rimuoverle o comunque diminuirne l impatto negativo sul riuso. Le linee guida sono in tipografia e saranno disponibili sul sito del CNIPA nei prossimi giorni. Sviluppare per il riuso 16

18 Il metodo per la definizione delle LG Le linee guida sono state definite da una community network che ha coinvolto CNIPA, pubbliche amministrazioni, Società partecipate, Università e Associazioni di categoria: CNIPA CONSIP INAIL INPS SOGEI Assinform Esperti (da Università e Associazioni) Sviluppare per il riuso 17

19 Contenuti delle linee guida Documento di circa 100 pagine, diviso in una Premessa e 12 capitoli (2 introduttivi tti i e 10 di contenuti) ti) + 4 appendici. Definisce una strategia in 8 passi per rimuovere le cause della attuale inefficienza del riuso di software nella P.A. La strategia non riguarda il riuso di software già esistente, ma intende rendere più facilmente riusabile il nuovo software custom che sarà acquisito dalla P.A. La strategia proposta è sostanzialmente una contaminazione della pratica del riuso con quella dello sviluppo di software open source e con i principi delle tecnologie SOA (Service Oriented Architecture).. Sviluppare per il riuso 18

20 Natura dei contenuti Per attuare ogni passo della strategia le linee guida forniscono delle raccomandazioni di natura tecnica, organizzativa, metodologica per raggiungere gli obiettivii previsti. Le raccomandazioni fornite non sono specifiche tecniche di dettaglio, né definiscono una nuova metodologia per sviluppare software, ma sono dei requisiti che le specifiche tecniche e le metodologie di sviluppo di software custom dovrebbero rispettare nel caso di sviluppi ad hoc su commessa della P.A. Sviluppare per il riuso 19

21 Destinatari e uso delle linee guida Destinatarie dirette delle raccomandazioni sono le P.A. di cui all art. 1 del d.lgs 39/1993 (le linee guida fanno parte delle iniziative CNIPA finalizzate a dare attuazione al dpcm 31 maggio 2005, n. 157, di razionalizzazione della spesa pubblica per l ICT), ma anche altre amministrazioni pubbliche possono farne uso. Un possibile uso delle raccomandazioni è nel confezionamento dei capitolati ti tecnici i relativi i ai progetti di sviluppo di software custom. Sviluppare per il riuso 20

22 Indice delle linee guida (1/3) Premessa (motivazioni al documento). 1) Referenze (i partecipanti alla stesura del documento). 2) Contenuti, destinatari e utilizzo del documento. 3) Analisi i del perimetro attuale del concetto di riuso nella PAC (evoluzione del concetto, riuso vs reingegnerizzazione e diffusione, riuso vs qualità del software e dei dati, riuso vs riusabilità e vs portabilità, fattori abilitanti il riuso, riuso vs architetture software SOA.. ). 4) Introduzione ad alcuni elementi innovativi che possono estendere il concetto di riuso, come i web services e i componenti funzionali multiuso riusabili in ottica SOA. 5) Analisi i della situazione i attuale del riuso nella Pubblica Amministrazione, in particolare dei limiti del riuso come attualmente praticato. Sviluppare per il riuso 21

23 Indice delle linee guida (2/3) 6) Sintesi della strategia proposta per superare i limiti attuali all efficienza i del riuso di software. 7) Le caratteristiche tecniche che devono possedere i componenti software custom di nuovo sviluppo per poter essere considerati riusabili. 8) I requisiti di un processo di produzione del software orientato a realizzare componenti riusabili e a riusare nel processo produttivo componenti già disponibili e semilavorati, basato sull utilizzo di appositi cataloghi di componenti software riusabili e su una dinamicai costruttiva tti di tipo get-put. t 9) I requisiti di massima dei cataloghi dei componenti software riusabili che le varie P.A. dovrebbero costruire per ospitare i componenti via via acquisiti. Sviluppare per il riuso 22

24 Indice delle linee guida (3/3) 10) I contenuti di massima della documentazione che va realizzata nel processo di sviluppo per poter poi più facilmente riusare un componente software (Piano del riuso, libretto del riuso, Piano della qualità). 11) Un analisi dell organizzazione che, nelle P.A., può favorire il riuso di componenti software, come prescritto nelle linee guida, e dare maggiore efficienza al processo di riuso. 12) Un analisi dell impatto dello sviluppo di software riusabile sui costi di un progetto di sviluppo software. Appendici: 1) Reuse Maturity Model, 2) Criteri di valutazione della qualità del software, 3) Misure della quantità di riuso in un progetto di sviluppo software, 4) Struttura base del Capitolato Tecnico per un servizio di sviluppo di software riusabile. Sviluppare per il riuso 23

25 Cosa non contengono le linee guida Le linee guida non contengono: Una trattazione specifica delle implicazioni giuridiche del riuso (proprietà del software, limiti di responsabilità, limiti al riuso di componenti licenziati open source etc..). La definizione dei meta dati che descrivono i cataloghi dei componenti riusabili e il meta catalogo che li repertoria e indirizza. i Sviluppare per il riuso 24

26 Aspetti standard delle linee guida Ripresa di standard internazionali di larga diffusione. Per favorire la diffusione delle raccomandazioni, tutte quelle presentate nelle linee guida sono in linea, o direttamente tratte, dagli standard di ingegneria del software più diffusi (soprattutto dagli standard ISO). Coerenza con altri documenti CNIPA sullo stesso tema. Le raccomandazioni contenute nelle linee guida completano quelle già contenute nelle già edite Linee guida CNIPA per la gestione di un progetto di riuso di software già esistente e di proprietà della P.A. (disponibili sul sito enellelinee Guida alla qualità degli appalti ICT (disponibili sul sito Sviluppare per il riuso 25

27 La strategia proposta per aumentare l efficienza del riuso del software nella P.A. Sviluppare per il riuso 26

28 La strategia proposta (1/2) La strategia proposta dalle linee guida per aumentare l efficienza del riuso nella P.A. si basa su 8 elementi: Aumentare la disponibilità di informazioni sul software riusabile bl diproprietà della P.A. Prevedere la possibilità del riuso anche a livello di singoli componenti, anziché dell intera applicazione software. Definire le caratteristiche che deve avere un software per essere facilmente riusabile. Definire un processo di sviluppo che contribuisca a rendere il software più riusabile. Sviluppare per il riuso 27

29 La strategia proposta (2/2) Gli ulteriori 4 elementi della strategia: Definire un libretto di istruzioni al riuso da associare a ogni software riusabile per supportarne il riuso. Creare in ogni P.A. centri di competenza sul riuso. Definire una licenza di libero riuso per facilitare gli adempimenti connessi con un riuso. Risolvere le questioni aperte di natura giuridica e amministrativa che possono facilitare il riuso. Sviluppare per il riuso 28

30 Una strategia in 4 punti (+ 4) Punto 1 1) Aumentare la circolazione di informazioni sui software disponibili per essere riusati. Ogni P.A. dovrebbe definire un catalogo del software applicativo di sua proprietà, descritto in modalità standard (e.g. utilizzando le specifiche OMG RAS basate su XML). Alcuni possibili contenuti dei cataloghi delle P.A.: aspetti funzionali e tecnici delle applicazioni, documentazione disponibile (progettuale e operativa), descrizione di singoli componenti riusabili, eventuali dipendenze tecnologiche dei componenti, avvertenze per il loro riuso. Sviluppare per il riuso 29

31 Il catalogo del software riusabile I cataloghi delle singole P.A. dovrebbero essere indicizzati e repertoriati in un meta-catalogo a cura di un soggetto terzo (ad esempio il CNIPA), per facilitare la ricerca di contenuti. I cataloghi potrebbero essere resi interrogabili in maniera applicativa sia dall interno che dall esterno dell amministrazione (e.g. usando web services, via porta di dominio su SPC). Vanno definite le regole per fare ricerche nei cataloghi, riusare i software contenuti nei cataloghi, modificarli, ripopolare i cataloghi con nuovi elementi etc. Sviluppare per il riuso 30

32 Topologia dei cataloghi della P.A. Catalogo presso P.A. n Ad ogni modifica trasmette la notizia al meta catalogo Contiene la descrizione dei componenti riusabili e le istruzioni su come riusarli Contiene il repertorio dei componenti riusabili presenti nei cataloghi della P.A. Catalogo presso P.A. 1 Meta catalogo presso CNIPA Catalogo presso P.A. 2 Il meta catalogo richiede ila descrizione del componente al catalogo e lo trasmette al soggetto richiedente Cerca un componente da riusare nel meta catalogo, che lo indirizza al catalogo specifico della P.A. Sviluppare per il riuso 31

33 Una strategia in 4 punti (+ 4) Punto 2 2) Aumentare il livello di granularità del riuso, prevedendo il riuso a livello anche di singoli componenti, anziché solo di intere applicazioni. Per rendere ciò possibile occorre chiedere ai fornitori di sviluppare il nuovo software custom secondo la logica dei componenti funzionali singolarmente riusabili. L attuale pratica industriale i di sviluppo del software utilizza il modello di costruzione da quello dell hardware, che viene realizzato in maniera modulare, assemblando componenti standard preconfezionati, eventualmente da adattare. I moderni linguaggi di programmazione sono intrinsecamente orientati al riuso di componenti (si basano su principi di Object Oriented - information hiding, alta coesione interna e basso coupling tra moduli - librerie di patterns, routines etc..). Le architetture SOA permettono di costruire software assemblando componenti già esistenti, anche tecnologicamente eterogenei. Sviluppare per il riuso 32

34 Architetture applicative Un architettura applicativa è composta, di norma, di più strati o livelli (gli strati sono detti layers e la loro pila stack ) con compiti (funzioni/servizi) specializzati. Anche gli strati tisono fatti di componenti che svolgono funzioni specializzate. Nello strato funzionale sono i componenti che gestiscono la logica applicativa (di business) specifica del sistema informativo. Nello strato abilitante sono i componenti che forniscono allo strato funzionale servizi ricorrenti nei sistemi informativi. Nello strato base sono i S.O., i middleware, i RDBMS e i componenti di software di base. FUNZIONALE ABILITANTE BASE HARDWARE Sviluppare per il riuso 33

35 Architetture applicative e riuso Applic caz. verticali Applic caz. verticali Applicaz. trasvers. Applicaz. trasvers. Singoli componenti FUNZIONALE Intere applicazioni ABILITANTE Componenti di Infrastruttura BASE Componenti di servizio Componenti di processo Livelli dello stack Tipologie di componenti tecnici che popolano lo strato abilitante dell architettura software Esempio di riuso di componenti negli strati (segnalati con la trama) Sviluppare per il riuso 34

36 Componenti abilitanti Vista tecnica (1/2) Possibile classificazione dei componenti dello strato abilitante delle architetture software. Strato abilitante, funzioni di infrastruttura (esempio) autenticazione, autorizzazione e accesso, tracciatura e log, firma (elettronica o digitale), pagamento elettronico, monitoraggio di applicazioni e processi, posta elettronica (anche certificata), gestione documentale a norma CNIPA (protocollo informatico). Sviluppare per il riuso 35

37 Componenti abilitanti Vista tecnica (2/2) Strato abilitante, funzioni di processo (esempio): il processo che governa l emissione di un certificato di residenza, il processo di approvazione di una richiesta di acquisto, il processo che governa la gestione dello svolgimento di una gara di appalto on-line. Strato abilitante, funzioni di servizio (esempio): gestione del personale, contabilità analitica o economica, gestione degli acquisti, erogazione di servizi al cittadino e alle imprese. Sviluppare per il riuso 36

38 Componenti abilitanti Altra vista Per il governo delle conoscenze Sistemi di ingegneria progettazione e automazione (CAD, CAE) Sistemi di georeferenziazione sistemi informativi territoriali Sistemi di trattamento immagini ed estrazione informazioni da immagini Sistemi per il controllo di processi produttivi e di ambienti Sistemi di asset management Sistemi per la contabilità e il controllo di gestione Per il governo delle risorse (finanziarie, materiali e umane) Sistemi di riconoscimento vocale Sistemi di business intelligence Motori di ricerca, funzionalità semantiche e sistemi ad apprendimento Sistemi di project management Sistemi di gestione documentale e workflow Supply chain management systems (procurement, logistica) Sistemi di gestione delle risorse umane8 Customer relationship management systems Soluzioni per l interoperabilità e l interazione tra banche dati Content management systems Sistemi di identificazione, autorizzazione ed accesso Soluzioni per l interoperabilità e l interazione tra servizi Soluzioni di collaborazione Per il governo delle interazioni relativamente sia a conoscenze sia a risorse Sviluppare per il riuso 37

39 Componenti per natura giuridica I componenti che costituiscono una moderna architettura software possono avere diversi status giuridici, rilevanti ai fini del riuso: Componenti già di proprietà del committente, il cui riuso, modifica ed eventuale reinserimento nel catalogo dei componenti riusabili ai fini della cessione in ulteriore riuso ad altre P.A. non haparticolari i vincoli. Componenti COTS, di proprietà di imprese private, il cui riuso è soggetto o all acquisto acqu da parte del riusante e la cui successiva cessione ad altre P.A. non è possibile. Componenti open source, il cui riuso è possibile, ma per i quali la modifica e successiva cessione ad altre P.A. ai fini di un nuovo riuso è soggetta a limitazioni. Sviluppare per il riuso 38

40 Una strategia in 4 punti (+ 4) Punto 3 3) Sviluppare componenti software con caratteristiche tecniche che ne facilitino il riuso. Le linee guida CNIPA individuano 12 attributi che caratterizzano un componente software riusabile (adattamento dello standard ISO/IEC 9126). Forniscono raccomandazioni per la valutazione della riusabilità del software, con opportuni test. Forniscono raccomandazioni per valutare la quantità di riuso effettivamente presente in un nuovo software. Introducono il concetto di casi di test riusabili. Sviluppare per il riuso 39

41 Gli attributi di un software riusabile 1 - Modularità 2 - Interoperabilità 3 - Modificabilità 4 Conformità a standard di codifica 5 Conformità a standard di progettazione 6 - Adattabilità 7 - Analizzabilità 8 - Configurabilità Documentazione! 9 - Installabilità 10 - Coesistenza 11 - Testabilità 12 - Apprendibilità Sviluppare per il riuso 40

42 Fattori tecnici (1/4) - caratteristiche Modularità: l architettura logico funzionale dell applicazione software deve essere strutturata ad un buon livello di granularità, con componenti coesi e poco accoppiati. Interoperabilità: il software deve essere predisposto per interagire con altri sistemi noti a priori (API e interfacce aperte). Modificabilità: il software deve essere modificabile con facilità (manutenzione evolutiva, adattativa e migliorativa), per adattarlo a requisiti e contesti diversi da quelli originari. Conformità a standard di codifica: il codice deve essere scritto in modo standard, comprensibile e leggibile, al fine di agevolare la manutenzione MEV e MAC. Sviluppare per il riuso 41

43 Fattori tecnici (2/4) - caratteristiche Conformità a standard di progettazione: lessico standard, notazioni standard, scelte architetturali orientate verso elementi di larga diffusione che consentono più facilmente il riuso (piattaforme di esecuzione, protocolli di comunicazione, accesso ai dati etc..). Adattabilità: la capacità del software di essere adattato con facilità e a costi contenuti per il suo utilizzo in ambienti noti a priori (con funzioni di personalizzazione e configurazione in dotazione al software stesso). Analizzabilità: capacità del software a essere esaminato per fini diagnostici diretti a individuare malfunzioni e difetti, o per individuare d le parti da modificare. df Sviluppare per il riuso 42

44 Fattori tecnici (3/4) - caratteristiche Configurabilità: la capacità di un prodotto software di essere configurato con facilità per rispondere a differenti esigenze e/o condizioni ambientali note a priori. Installabilità: la capacità di un prodotto software di essere installato con facilità in un insieme predefinito di ambienti operativi. Coesistenza: la capacità di un prodotto software di coesistere con altri software indipendenti (noti a priori) in un ambiente comune, condividendo id d risorse comuni. Sviluppare per il riuso 43

45 Fattori tecnici (4/4) - caratteristiche Testabilità: la capacità di un prodotto software di essere sottoposto a verifiche durante tutto il suo ciclo di vita; disponibilità di casi di test riusabili e adattabili. Apprendibilità: la capacità di un prodotto software di essere appreso con facilità dagli utenti nelle sue modalità d utilizzo. Documentazione: la completezza della documentazione progettuale associata al software, con una chiara definizione dei casi d uso permessi agli utenti, descrizione del comportamento statico e dinamico del software, coerenza tra software consegnato per il riuso e documentazione progettuale, disponibilità dei formati dati. Sviluppare per il riuso 44

46 Una strategia in 4 punti (+ 4) Punto 4 4) Definire un processo di sviluppo software adatto allo sviluppo di componenti riusabili. La prima azione del processo deve essere quella di valutare se già esistono componenti software riusabili adatti a soddisfare i requisiti del progetto e, se esistono, prelevarli (get) dal catalogo in cui si trovano. La documentazione progettuale (e i casi di test) vanno realizzati pensando ad un possibile riutilizzo (notazioni standard di rappresentazione, consistenza, esaustività...). La codifica del software deve seguire regole quanto più possibili standard. L ultima fase del processo è la pubblicazione (put) dei componenti riusabili nel catalogo dell Amministrazione. Sviluppare per il riuso 45

47 Schema del processo di produzione Linee guida sviluppo sw Linee guida riusabile 1 qualità forniture ICT 4 5 Definizione Riuso e Sviluppo specifiche di adattamento t nuova massima 2 componenti applicazione Make or Buy or Reuse Linee guida sviluppo sw riusabile Nuovi 3 Ricerca componenti componenti riusabili riusabili META catalogo Catalogo PAn Catalogo PA2 Catalogo PA1 Sviluppare per il riuso 46

48 Una strategia in 4 punti (+ 4) Punto 5 5) Associare al software da riusare un libretto del riuso. Il libretto è un manuale operativo (di istruzioni), predisposto dallo sviluppatore al momento della realizzazione del software, a supporto di chi vorrà successivamente riutilizzare il prodotto. Contiene informazioni su come adattare il software a vari contesti operativi (noti a priori), su come personalizzare e parametrizzare il software, su come installarlo, su come farlo eventualmente evolvere per arricchirlo di ulteriori funzioni. Sviluppare per il riuso 47

49 Una strategia in 4 punti (+ 4) Punto 6 6) Creare presso ogni P.A. una community (o centro di competenza) sul riuso. Compiti della community dovrebbero essere: Supportare gli sviluppatori e i dirigenti nella valutazione dell opzione di riuso, in ogni nuovo progetto di sviluppo di software custom. Curare la pubblicazione su catalogo del nuovo software riusabile sviluppato nei progetti. Effettuare manutenzione sul software contenuto nel catalogo, al fine di aumentarne nel tempo la riusabilità. Gestire il catalogo del software riusabile, anche nei confronti di altri soggetti esterni (e.g. CNIPA). Sviluppare per il riuso 48

50 Una strategia in 4 punti (+ 4) Punto 7 7) Definire una licenza di riuso. La licenza (sul modello di quelle open source), dovrebbe essere rilasciata dalla P.A. che pubblica il componente riusabile nel proprio catalogo, a favore di tutti quei soggetti che intendono riusare il componente (sia altre P.A. sia, eventualmente, fornitori di servizi verso la P.A.). Il riuso, se effettuato da soggetti privati, dovrebbe esseree sempree senza fini di lucro, se non per i servizi i aggiuntivi eventualmente realizzati a completamento di quelli offerti dal software riusato. Sviluppare per il riuso 49

51 Una strategia in 4 punti (+ 4) Punto 8 8) Definire gli aspetti giuridici e amministrativi che facilitano il riuso. Definire i limiti della proprietà p del software (a quali oggetti software si riferisce, oltre al codice, se sono possibili proprietà disgiunte etc..). Definire i il concetto di opere derivate. Definire le limitazioni di responsabilità nel caso di riuso. Definire una metrica condivisa e oggettiva per misurare la quantità di riuso in un progetto di sviluppo software. Sviluppare per il riuso 50

52 Conclusioni Sviluppare per il riuso 51

53 Elementi già soddisfacenti Elementi di soddisfazione: Completezza delle linee guida. Utilizzo ed adattamento di standard e architetture tecniche consolidati: ISO/IEC 9126, Punti Funzione, Reuse Maturity Model, specifiche OMG RAS, Web Services, SOA, SPC. Indicazioni puntuali sui requisiti da prevedere per un servizio di sviluppo di software riusabile: Caratteristiche tecniche del software riusabile. Requisiti per il test, metriche, piano e tecniche di test. Documentazione del software per favorire il riuso. Elementi per definire e gestire un catalogo di software. Sviluppare per il riuso 52

54 Aspetti da perfezionare Alcuni aspetti richiedono ancora un approfondimento: Aspetti legali proprietà del software. Struttura di un capitolato tecnico tipo per il riuso. Struttura, sintassi e semantica del catalogo dei componenti riusabili (meta catalogo e cataloghi distribuiti). La sensibilità delle P.A. e delle imprese verso il riuso di componenti software, da affiancare a quello di intere applicazioni, va costruita nel tempo, anche con incentivi. Sviluppare per il riuso 53

55 Il ciclo virtuoso da innescare Le P.A. devono chiedere ai propri fornitori di realizzare laddove tecnicamente possibile - il nuovo software custom enfatizzandone la strutturazione in aggregazioni di moduli a loro volta singolarmente riusabili. Potranno così acquisire, al termine di ogni progetto di sviluppo, sia l applicazione software richiesta con la specifica commessa, sia un certo numero di componenti riusabili in altri successivi progetti. Con tali componenti le P.A. popolano repository di componenti software riusabili, da utilizzare come mattoni elementari per costruire altro nuovo software (per assemblaggio ), con costi progressivamente sempre più contenuti e qualità sempre migliore. Sviluppare per il riuso 54

56 Next steps Diffondere le linee guida presso le P.A. Sperimentarne l uso in progetti pilota di sviluppo software custom per la PA. Definire un capitolato tipo per lo sviluppo software. Risolvere le questioni giuridiche pendenti. Costruire i cataloghi del software riusabile delle P.A. e il meta-catalogo presso il CNIPA. Definire le regole per popolare i cataloghi (nuovi inserimenti e aggiornamenti di componenti già inseriti), per prelevare componenti dai cataloghi, per gestire più versioni dello stesso componente (se necessario). Sviluppare per il riuso 55