ALLEGATO 1.2 METODOLOGIE E LINEE GUIDA DI MISURA DEI FUNCTION POINT

Transcript

1 ALLEGATO 1.2 METODOLOGIE E LINEE GUIDA DI MISURA DEI FUNCTION POINT Pagina 1 di 64

2 Sommario 1 INTRODUZIONE Obiettivo e ambito di applicazione del documento Terminologia specifica e abbreviazioni Riferimenti normativi Riferimenti bibliografici Riferimenti interni Avvertenze d uso MISURAZIONE DEI FUNCTION POINT Standard e Momenti di Misura in Function Point Generalità sui Function Point I Function Point per la Misura della Dimensione Funzionale del Software FP come misura di base per la valorizzazione di altre metriche Livelli di misurazione dei Function Point Standard per la misura dei FP Standard per la stima (misura grezza o approssimata) dei FP Modalità di fornitura delle misure / stime Aggiornamento delle dimensioni del patrimonio software (baseline) Applicazione Software Misurabile (ASM) Linee Guida per l interazione tra ASM Architettura Tecnologica Stratificata Modello di riferimento per le architetture a componenti Comunicazione / condivisione dati tra ASM Replica di dati relativi a DB aziendali e batch di allineamento Incorporamento servizi di altre ASM Linee Guida Generali per la stima/misura dei FP (LG-G) Funzioni di tipo transazionale richieste su più canali Elaborazioni complesse e individuazione dei processi elementari Gestione dei menu dinamici Storicizzazione Gestione dei log Form di visualizzazione dei dati da modificare/cancellare Gestione dell Help Output parametrici Funzioni di Log-on (cfr. Knowledge Base) Gestione informazioni di controllo/ configurazione Linee Guida su Graphical User Interface e Function Point (LG-GUI) Linee Guida per Applicazioni Web-based (LG-Siti Web) Linee Guida per Applicazioni Data Warehouse (LG-DW) Linee Guida per Applicazioni GIS (LG-GIS) Linee Guida per Applicazioni Middleware (LG-MW) MOMENTI E MODI DI UTILIZZO DELLE MISURAZIONI Modelli di produzione e punti di stima/misura funzionale Modello di produzione a cascata (waterfall) Modello di produzione incrementale Pagina 2 di 64

3 3.1.3 Modello di produzione evolutivo VALORIZZAZIONE INTERVENTI DI SVILUPPO E MEV FUNZIONALE Stima dell entità dell intervento Misura Funzionale Contrattuale Valorizzazione del Riuso Valorizzazione della Replica Misurazione delle varianti di requisiti funzionali in corso d opera Modalità di calcolo della MFC Correzione sul PUN per Modello di Produzione (MP) Fattore di Correzione Complessivo sul PUN (FCC) Modalità di calcolo dei fattori di correzione Prezzo Unitario Corretto (PUC) Calcolo del corrispettivo di un Intervento Pagina 3 di 64

4 1 INTRODUZIONE 1.1 Obiettivo e ambito di applicazione del documento Il documento ha l obiettivo di presentare: le indicazioni generali con le quali LI intende gestire l applicazione della metrica in Function Point (FP) nell ambito dell Appalto. le Linee Guida con le quali LI intende gestire l applicazione della metrica in Function Point (FP) nell ambito dell Appalto. Esse forniscono indicazioni coerenti con quanto previsto dagli specifici White Paper emanati dall IFPUG citati in bibliografia [BIB08][BIB09][BIB10][BIB11][BIB12][BIB13] la modalità di utilizzo, gestione e calcolo dei corrispettivi per gli interventi di Sviluppo e Manutenzione Evolutiva Funzionale previsti dall Appalto. 1.2 Terminologia specifica e abbreviazioni Ambito Ambito del conteggio L ambito del conteggio definisce le funzionalità che saranno incluse in un particolare conteggio di function point. L ambito: definisce un (sotto)insieme del software oggetto di misura; ASM Applicazione Software Misurabile Pagina 4 di 64 è determinato dallo scopo stabilito per il conteggio; identifica quali funzioni dovranno essere incluse nel conteggio così da fornire risposte rilevanti all obiettivo del conteggio; potrebbe includere più di un applicazione. Raggruppamento funzionale adatto per la misura in FP BFC Base Functional Component Elementi di base alla misurazione funzionale. Nella FPA IFPUG corrispondono agli EI, EO, EQ, EIF, ILF DET Data Element Type Un campo non ripetuto riconoscibile all utente E&QFP Early & Quick Function Point Tecnica di stima dei FP adottata nell Appalto EFP Enhancement Function Point Misura in FP di un progetto di Manutenzione Evolutiva Funzionale EI External Input Processo Elementare di tipo Input EIF External Interface File Gruppo logico di dati usato in sola lettura e

5 quindi esterno al confine applicativo. EO External Output Processo Elementare di tipo Output EQ External Inquiry Processo Elementare di tipo Interrogazione FP Function Point Misura funzionale di un prodotto software FPA Function Point Analysis Metodologia con cui si misurano i Function Point FSM Functional Size Measurement Misure funzionali del software FTR File Type Referenced File logico interno (ILF) letto o mantenuto dalla funzione, oppure un file esterno di interfaccia (EIF) letto dalla funzione (da EI/EQ/EO) FUR Functional User Requirements GSC General System Characteristic Requisiti utente funzionali, quelli che possono essere misurati dalla FPA Parametro globale di valutazione di un sistema software IFPUG International FP Users Group Gruppo internazionale degli utilizzatori dei Function Point ILF Internal Logical File Gruppo logico di dati usato in lettura/scrittura interno al confine applicativo. ISBSG International Software Benchmarking Standards Group MEV Manutenzione Evolutiva del SW Organismo internazionale che dispone di un data base di benchmarking aperto, non proprietario Classe di fornitura; può riguardare i requisiti funzionali o non funzionali di una ASM già esistente RET Record Element Type Un sottogruppo di dati riconoscibili (dall'utente) all'interno di un ILF/EIF UFP Unadjusted Function Point Misura non aggiustata tramite il VAF VAF Value Adjustment Factor Fattore di Aggiustamento del Valore 1.3 Riferimenti normativi [BIB01] ISO/IEC, :2007 Information technology Software measurement Functional size measurement - Part 1: Definition of Concepts, JTC 1 / SC 7, ISO/IEC, 2007 [BIB02] IFPUG, Manuale delle Regole di Conteggio dei Function Point 4.3.1, 2011 [BIB03] DPO, Early & Quick Function Point Manuale di Riferimento v.1.0, Gennaio 2012 [BIB04] DPO, Simple Function Point Functional Size Measurement Method - Manuale di Riferimento v.1.0, Dicembre 2013 Pagina 5 di 64

6 1.4 Riferimenti bibliografici [BIB05] GUFPI-ISMA, LGC-FP Linee Guida per l uso Contrattuale dei Function Point, Luglio 2006 [BIB06] CNIPA, Linee Guida sulla qualità dei beni e dei servizi ICT per la definizione ed il governo dei contratti della PA, Manuale 2 Strategie di Acquisizione delle Forniture ICT, Febbraio 2007 [BIB07] CNIPA, Linee Guida sulla qualità dei beni e dei servizi ICT per la definizione ed il governo dei contratti della PA, Manuale 1,2,3,4,5,6,7 [BIB08] IFPUG, Hints to Counting Applications in a Client/Server environment, 2004 [BIB09] IFPUG, Function Point & Counting Enterprise Data Warehouses - Release 1.0, 2007 [BIB10] IFPUG, Function Points & Counting GUI Application Features Release 1.0, 2008 [BIB11] IFPUG, Sizing Component-Based Development Using Function Points, 2009 [BIB12] IFPUG, Function Points & Counting Middleware Software Applications Release 1.0, 2009 [BIB13] IFPUG, Considerations for Counting with Multiple Media, 2009 [BIB14] COCOMO II Model definition manual versione 2.1 [BIB15] IFPUG, Practical Guidelines for Documenting the Function Point Count Release 1.0, Riferimenti interni [BIB16] LI-ALM-SISMET-FP-LG-GUI#10 [BIB17] LI-ALM-SISMET-FP-LG-SITIWEB [BIB18] LI-ALM-SISMET-FP-LG-DW [BIB19] LI-ALM-SISMET-FP-LG-GIS [BIB20] LI-ALM-SISMET-FP-LG-MIDDLEWARE 1.6 Avvertenze d uso I Riferimenti normativi costituiscono la base di riferimento per le regole da applicare in un qualsiasi conteggio di Function Point. La Bibliografia è costituita da letture di approfondimento e orientamento da non considerarsi, però, vincolanti dal punto di vista normativo. Nel caso in cui una Linea Guida (LG) contenuta nel presente documento sia in contrasto con l impostazione di uno dei documenti sopra citati prevarrà il contenuto della Linea Guida qui riportata. Alcune Linee Guida presenti in questo documento sono espresse in termini imperativi in quanto sufficienti a determinare la scelta di conteggio. Altre consentono di identificare candidature per elementi di conteggio che, però, per essere confermate devono rispondere ai criteri specifici espressi dal manuale delle regole di misura standard [BIB02]. Pagina 6 di 64

7 Nell ambito dell applicazione delle presenti Linee Guida in attività operative che producono verbali di conteggio, aggiornamenti del db misure funzionali e così via, per riferire correttamente una LG occorre riportare il numero di versione del presente documento e il numero progressivo della LG. Versioni successive del documento potranno avere numeri progressivi diversi per la stessa LG. Riportando il versioning del documento le LG sono riferite in modo univoco. Esempi di uso corretto sono: V1.01_LG3 Pagina 7 di 64

8 2 MISURAZIONE DEI FUNCTION POINT 2.1 Standard e Momenti di Misura in Function Point Generalità sui Function Point In accordo con l orientamento dello standard internazionale ISO/IEC :2007 [BIB01], i requisiti utente, relativi ad un applicazione software, possono essere suddivisi in tre classi principali: Requisiti Funzionali, Requisiti Tecnici e Requisiti di Qualità. I secondi e i terzi sono noti anche come Requisiti Non Funzionali. Le misure funzionali del software (FSM Functional Size Measurement), a cui appartengono i Function Point IFPUG, sono legate esclusivamente alla prima delle tre categorie. Lo scopo dei Function Point IFPUG è quello di fornire una misura obiettiva della quantità di funzioni offerte da un applicazione ai suoi utenti (umani e/o altri Sistemi Informativi) quantificando cosa permette di fare, in termini di dati a disposizione e operazioni su di essi I Function Point per la Misura della Dimensione Funzionale del Software I Function Point misurano le dimensioni del software quantificando le funzionalità in esso contenute e visibili dall utente. La caratteristica della metrica è quella di misurare l aspetto funzionale esterno del prodotto, non quello implementativo quasi mai conosciuto dall utente e comunque molto legato all aspetto tecnologico. Essere svincolati dall aspetto tecnologico vuol dire poter giungere ad una misura dello sviluppo software in fasi anche relativamente alte del ciclo di vita. La conoscenza anticipata nel tempo (nei momenti di pre-analisi, analisi e progettazione), della dimensione funzionale del software, agevola la comunicazione tra i vari attori coinvolti nel processo di realizzazione e manutenzione del software e consente un analisi temporale dell andamento del progetto FP come misura di base per la valorizzazione di altre metriche La caratteristica di affidabilità dei Function Point si risolve nella capacità che offre il metodo di giungere allo stesso risultato di misura qualora il conteggio venga effettuato da diverse persone in tempi diversi (entro un ragionevole margine di errore). La disponibilità di un dato dimensionale certo, con caratteristiche di indipendenza rispetto agli attributi specifici dei progetti software (quali metodologie, strumenti, linguaggi impiegati per lo sviluppo), facilita la predisposizione di programmi di misurazione che seguono ciascun progetto dalle fasi iniziali di avvio a quelle finali di consegna all utente. I Function Point, infatti, messi in relazione ad altre misurazioni del processo interno, sono alla base di altre importanti metriche di produttività e di qualità quali ad esempio la capacità produttiva in FP/annopersona, la stabilità applicativa come numero di interventi di modifica/fp, l affidabilità di un applicazione come malfunzionamenti/fp complessivi, il numero di casi di test previsti, etc. Pagina 8 di 64

9 2.1.4 Livelli di misurazione dei Function Point Nella pubblicazione Practical Guidelines for Documenting the Function Point Count [BIB15] l IFPUG esprime gli elementi minimi che costituiscono la documentazione di misura. Essi sono: 1. L obiettivo della misura e il tipo di misura; 2. L ambito della misura e il confine dell applicazione; 3. La data di misura; 4. La versione dello standard CPM di riferimento; 5. La versione delle Linee Guida locali; 6. Ogni deroga dalle Linee Guida locali; 7. Ogni assunzione e scelta di misura fatta; 8. Il risultato della misura; 9. Una lista di tutte le funzioni (transazionali e dati) con le rispettive classi (ADD, CHG, ), tipologie (EI,EO,EQ,ILF,EIF), complessità e numero di FP assegnati. A questi elementi minimi si possono aggiungere ulteriori elementi di approfondimento come la lista nominativa dei DET, i legami tra le funzioni, i legami con la documentazione tecnica utilizzata per la misura etc. In base a questi suggerimenti e al fine di garantire a LI omogeneità e fruibilità dei risultati dell attività di misura in FP sono identificati i seguenti 4 livelli di documentazione della misurazione: Livello A: Misura approfondita In aggiunta agli elementi minimi: Tutte le funzioni sono individuate nominalmente, documentate e classificate utilizzando il numero preciso di DET, RET ed FTR I DET di ogni transazione e archivio logico sono individuati nominalmente Sono mantenute referenze incrociate tra elementi di conteggio (transazioni e archivi logici) Sono identificati i documenti tecnici utilizzati per la misura Sono memorizzate note e spiegazioni sugli elementi ed eventuali aspetti di conteggio rilevanti. Livello B: Misura dettagliata In aggiunta agli elementi minimi: Tutte le funzioni sono individuate nominalmente, documentate e classificate utilizzando i range di DET, RET ed FTR previsti nelle tabelle di complessità IFPUG Sono identificati i documenti tecnici utilizzati per la misura Sono memorizzate note e spiegazioni sugli elementi ed eventuali aspetti di conteggio rilevanti. Pagina 9 di 64

10 Livello C: Misura grezza (stima) Saranno presenti tutti gli elementi minimi fatta esclusione per il punto 9. In aggiunta: Tutte le funzioni sono individuate nominalmente, documentate e classificate per categoria tipologica: Transazioni o Unspecified Generic Elementary Process (UGEP) e Dati o Unspecified Generic Data Group (UGDG) Ad ogni elemento di tipo transazionale si associa un valore di complessità di default pari a 4,6 FP Ad ogni elemento di tipo dati si associa un valore di complessità di default pari a 7 FP Sono identificati i documenti tecnici utilizzati per la misura Sono memorizzate note e spiegazioni sugli elementi ed eventuali aspetti di conteggio rilevanti. Livello D: Misura approssimata (stima) Per questo livello di misura è richiesta l applicazione del metodo Early & Quick FP [BIB03] a qualunque grado di approfondimento previsto dal metodo (Sommario, Intermedio, Dettagliato). Sono memorizzate note e spiegazioni sugli elementi ed eventuali aspetti di conteggio rilevanti. Le misure richieste all accettazione dei nuovi sviluppi e delle manutenzioni evolutive funzionali saranno di norma a livello B ma per obiettivi di controllo LI potrà richiedere, a sua discrezione, di ottenere per ogni intervento di sviluppo o manutenzione evolutiva funzionale, una documentazione di livello A. In fasi anticipate dei cicli di vita di produzione, a seconda del livello di informazioni disponibili o della urgenza nell ottenimento della misura o dello scopo di utilizzo della misura stessa, potranno essere richieste al fornitore misure di livello C o D. In questi casi si parlerà di Stima di FP. Il livello C è considerato accettabile per la prima valorizzazione patrimoniale richiesta al fornitore. Per le modalità di fornitura delle misure/stime si faccia riferimento al Capitolo Errore. L'origine riferimento non è stata trovata Standard per la misura dei FP Ai fini della misura funzionale del software oggetto dell Appalto si farà riferimento alla versione in italiano dello standard IFPUG [BIB02], limitatamente alla componente Non Pesata ovvero senza l applicazione del Fattore di Aggiustamento del Valore. Lo standard internazionale IFPUG è integrato dalle Linee Guida per l interpretazione delle regole di misura in vari contesti d uso. Tali Linee Guida si articolano in: Pagina 10 di 64

11 - LG di approccio, che introducono il concetto di Applicazione Software Misurabile così come definito ed utilizzato in LI; - LG di conteggio generali, che descrivono indicazioni di conteggio di casistiche generali meritevoli di una puntuale interpretazione; - LG di conteggio specifiche per ambito, declinate nei diversi ambiti specifici di riferimento (Datawarehouse, Siti Web, GIS, GUI, Middleware, EDMA, ), per esplicitare indicazioni di conteggio nei contesti applicativi e tecnici più significativi nella realtà LI. Le prime due categorie di linee guida sono riportate nel seguito del presente documento. Le LG di conteggio specifiche per ambito sono descritte in documenti separati e saranno consegnate ai fornitori aggiudicatari dell appalto in sede di stipula del contratto. Si precisa che tali LG non contengono indicazioni che impattano sui meccanismi di riconoscimento dei corrispettivi economici dell appalto, ma esclusivamente interpretazioni univoche di conteggio. Poiché le linee guida sono, per loro natura, suscettibili di evoluzione nel tempo (ad esempio per effetto di aggiornamenti della metodologia o a causa di nuove esigenze di interpretazione in ambiti tecnologici o applicativi specifici, e comunque a discrezione di LI), ogni modifica delle Linee Guida che interverrà dopo la stipula contrattuale dovrà essere specificamente approvata dalle Parti Passo preliminare per la misura funzionale Il processo di misurazione deve prevedere la realizzazione di una mappatura dei Requisiti Funzionali sul modello IFPUG ai fini della loro misurazione (vedi Figura 1). La mappatura implica l individuazione del modello architetturale di riferimento e l applicazione delle Linee Guida che contestualizzano l applicazione nei particolari ambiti d uso. Functional User Requirements (FUR) Fase di Mappatura FUR nella forma del modello del software generico secondo IFPUG Fase di Misurazione Dimensione funzionale Modelli architetturali del SW sia generico che specifico Fase di Mappatura Linee Guida Fase di Misurazione Regole e Metodo Risorse per la misurazione funzionale Figura 1 - Mappatura dei requisiti funzionali Pagina 11 di 64

12 Procedura standard per la misura funzionale Una volta attuata la mappatura dei requisiti funzionali sul modello di base alla misura funzionale IFPUG, le procedure per il conteggio dei Function Point saranno usate in modo invariato e saranno conservati i passi da seguire per giungere al numero finale di Function Point, fatta eccezione per la componente relativa al Fattore di Aggiustamento del Valore, che non sarà utilizzato, in conformità con le indicazioni dell ISO e di DigitPA. Di seguito si riporta il diagramma dei passi di misura corrispondente allo standard Figura 2 : Procedura standard IFPUG I Function Point sono una modalità di misura di prodotto, non di processo, per cui: il conteggio per progetto di sviluppo è inteso come conteggio delle funzionalità del software rilasciate dal progetto di sviluppo il conteggio per progetto di manutenzione evolutiva è inteso come conteggio delle funzionalità del software rilasciate dal progetto di manutenzione evolutiva (funzionale) ; nell ambito della manutenzione evolutiva è previsto anche il conteggio per progetto di manutenzione evolutiva sotto soglia piccola MEV funzionale che è inteso come conteggio delle funzionalità del software rilasciate dal processo di piccola MEV funzionale il conteggio per applicazione è inteso come il conteggio delle funzionalità del software che sono disponibili dopo il primo sviluppo e le successive attività di MEV funzionale Standard per la stima (misura grezza o approssimata) dei FP In tutti i casi in cui sarà consentito un livello della misura pari a C o D, sarà utilizzato il metodo degli Early & Quick Function Point, riferito in [BIB03]. La tecnica Early & Quick Function Point è disponibile dal 1997 per rendere possibile il dimensionamento di progetti o sistemi software partendo da informazioni anche non dettagliate, impiegando impegno e tempo inferiori rispetto a quelli richiesti per le misure standard. Tali informazioni non dettagliate sono di solito reperibili nelle fasi alte del ciclo di vita del software, quando non tutte le informazioni richieste per una misura standard di livello A o B sono a disposizione (ossia la lista dei campi processati e dei file referenziati, letti e/o scritti dalle transazioni del sistema ma anche l identificazione di tutti i processi elementari o gli archivi logici). Pagina 12 di 64

13 La tecnica E&QFP è riferita nelle Linee Guida per l uso Contrattuale dei Function Point del GUFPI-ISMA 1.4 e nelle "Linee guida sulla qualità dei beni e dei servizi ICT per la definizione ed il governo dei contratti della Pubblica Amministrazione" del CNIPA [BIB06]. La tecnica Early & Quick (E&Q) è un insieme consistente di concetti e procedure che, anche se applicato a informazioni non dettagliate di un sistema o di un progetto, consente di mantenere la struttura generale e i concetti essenziali dei metodi standard di misura della dimensione funzionale. Sul metodo, di pubblico dominio, è disponibile un manuale di riferimento standard all indirizzo: Questo metodo presenta il vantaggio di poter essere usato a qualunque grado di approssimazione si desideri, dal livello A fino al livello D delle categorie introdotte in precedenza, in quanto il livello più basso della decomposizione funzionale usato dalla tecnica E&Q corrisponde proprio ai BFC del metodo IFPUG cioè agli EI, EO, EQ, ILF o EIF ai vari livelli di complessità. In questo modo è possibile utilizzare lo stesso modello del software dalla stima sommaria iniziale fino alla misura approfondita facendolo evolvere mano a mano che le informazioni si rendono disponibili nel corso della vita del progetto. La qualità della stima dipende essenzialmente dal livello di informazione disponibile e utilizzabile. Il livello C di misurazione è, inoltre, coerente con il nuovo metodo di misura funzionale Simple Function Point introdotto nel 2011 e completamente compatibile sia con il metodo IFPUG che con quello Early & Quick FP. La nuova metrica Simple Function Point (SiFP) ha la caratteristica di misurare i requisiti utente funzionali con la stessa precisione del metodo standard IFPUG e di essere con essa totalmente compatibile in termini di valorizzazione: ovvero il rapporto di conversione tra una misura IFPUG FP ed una SiFP è pari ad 1. Questo comporta che possano essere utilizzati tutti i risultati di analisi effettuate sulla base delle misure IFPUG, a partire dai dati ISBSG di produttività fino ai prezzi unitari di scambio sul mercato, dai tassi di difettosità alle valorizzazioni patrimoniali. Il modello alla base della metrica SiFP coincide con quello IFPUG 4.x per quanto riguarda l impostazione generale, il confine, l ambito, la definizione di processo elementare e di archivio logico con le relative prassi, le formule. A causa della minore necessità di dettagli informativi, il metodo SiFP può essere utilizzato su un livello di specifiche funzionali di granularità molto minore e quindi più anticipata nel ciclo di vita di sviluppo. Il metodo è disponibile nel pubblico dominio sul sito dell'associazione SiFPA al seguente indirizzo: Modalità di fornitura delle misure / stime Le misure in FP prodotte dal Fornitore nei vari momenti previsti dai modelli di fornitura, dovranno essere consegnate in formato elettronico utilizzando l apposito software (Sfera ver. 3 o successive, oppure Sfera Light). Nel caso il fornitore non disponga di Sfera ver. 3 o successive, LI consegnerà il prodotto Sfera Light in licenza d uso gratuita e temporanea per Pagina 13 di 64

14 tutta la durata contrattuale e nel numero di copie adeguato alle necessità di interfacciamento con il sistema metrico LI. Per quanto riguarda la classificazione delle misure da registrare nello strumento Sfera o Sfera Light, la corrispondenza con i livelli cui al par è la seguente: Livello Metodo di Misurazione Approccio di misura A IFPUG standard B IFPUG standard C IFPUG E&Q 3.1 SiFP standard D IFPUG E&Q 3.1 Nella Figura seguente si riporta uno schema esemplificativo delle fasi di un generico ciclo di vita di sviluppo del software e dei corrispondenti momenti di misura. E opportuno sottolineare che tali momenti di misurazione si applicano a conteggi di tipo Sviluppo e Manutenzione Evolutiva (MEV). Tali momenti di misurazione sono definiti Stima Iniziale (ST1), Misura Iniziale (ST2), Misura Finale (ST3), e i relativi deliverable devono essere prodotti unitamente alla documentazione di progetto e/o altri prodotti previsti alla fine di ogni fase (cfr. 3.1 Modelli di produzione e punti di stima/misura funzionale. Pertanto: - una prima Stima è effettuabile nel momento di misurazione ST1, e può essere rieseguita anche nei momenti ST2 e ST3 con livello di dettaglio crescente; - la Misura funzionale può essere effettuata per la prima volta nel momento ST2 (e non prima), in quanto necessita di dettagli specifici non disponibili nelle fasi precedenti, e va ripetuta nel momento ST3 per fornire la Misura Finale dell Intervento. Pagina 14 di 64

15 In tutti i casi in cui è consentito un livello della misura pari a C o D, sarà utilizzato il metodo degli Early & Quick Function Point 3.1. Questo metodo presenta il vantaggio di poter essere usato a qualunque grado di approssimazione si desideri, in quanto il livello più basso della scomposizione funzionale usato dalla tecnica E&Q corrisponde proprio ai BFC del metodo IFPUG 4.3.1, cioè agli EI, EO, EQ, ILF o EIF ai vari livelli di complessità. Con questa tecnica è possibile utilizzare lo stesso modello (Metodologia e Approccio) di misurazione del software dalla stima sommaria iniziale fino alla misura approfondita, facendo evolvere la misurazione mano a mano che le informazioni si rendono disponibili nel corso della vita del progetto. La qualità della stima/misura dipenderà essenzialmente dal livello di dettaglio dei requisiti disponibile e utilizzabile. Di seguito uno schema che rappresenta i momenti di stima/misura in FP in relazione alle fasi del modello di produzione del software. (*) Vedasi allegato 1.4 Cicli di vita del Software, par. 1.1 e seguenti (**) I numeri illustrati sono solo indicativi Aggiornamento delle dimensioni del patrimonio software (baseline) Al termine di ogni attività misurata in FP che produce una variazione di rilievo del patrimonio rappresentato nell Inventario delle Applicazioni Software Misurabili, ovvero in caso di interventi di sviluppo o manutenzione evolutiva funzionale a progetto, il Fornitore dovrà consegnare tutte le informazioni necessarie all aggiornamento stesso. Periodicamente (dopo al massimo sei mesi dalla presa in carico e, successivamente, ogni 12 mesi) sarà prevista un attività di allineamento tra misure registrate nell inventario e applicazioni sviluppate o modificate nel periodo precedente. Pagina 15 di 64

16 2.2 Applicazione Software Misurabile (ASM) Considerando che, nel linguaggio informatico comune, il concetto di Applicazione Software può corrispondere ad una collezione tecnologica di moduli e procedure raggruppate non necessariamente in ragione delle prospettive di business, è necessario introdurre il concetto di Applicazione Software Misurabile in FP (ASM). Si definisce come ASM un aggregato di funzionalità logiche basato sul business, sui criteri di gestione organizzativa dei domini applicativi e analizzato dal punto di vista utente. I criteri di identificazione delle ASM sono suggeriti dall IFPUG nei suoi standard [BIB02] e dalle Linee Guida espresse nel seguito. La definizione delle ASM è necessaria al fine di identificare la natura degli archivi logici (interni o ILF esterni o EIF) e per la determinazione delle transazioni identiche (all interno di una ASM non si conteggiano transazioni identiche che compaiono in più punti dei menu di utilizzo, si conteggiano transazioni identiche se utilizzate in ASM diverse nonché per la corretta misurazione delle comunicazioni tra ASM. LG 1 Ambito e ASM Un progetto o intervento di sviluppo o manutenzione evolutiva funzionale misurabile in FP è caratterizzato da un ambito che può riguardare una o più ASM. La scelta dell ambito di conteggio non ridefinisce i confini tra le ASM. Ad esempio un certo progetto può riguardare allo stesso tempo lo sviluppo di una nuova ASM e la manutenzione evolutiva di ASM pre-esistenti che con essa devono interfacciarsi. L ambito del conteggio include sia la parte ex-novo che la modifica di funzionalità esistenti ma i conteggi vanno fatti per ogni ASM in modo separato per poi totalizzare i valori dei FP così generati in un conteggio di progetto o di lotto. L identificazione delle ASM è guidata da principi logici, e non tecnici, focalizzati sul punto di vista Utente. Il confine è individuato basandosi sul punto di vista dell utente. L attenzione è su ciò che l utente può capire e descrivere. Il confine fra applicazioni collegate è basato su aree funzionali distinte dal punto di vista dell utente e non in funzione degli aspetti tecnici. A questi principi generali si posso affiancare i seguenti suggerimenti operativi. LG 2 Confini di una ASM Per individuare il confine di una ASM, aggregare funzionalità e dati in base alla presenza delle affinità organizzative, funzionali e semantiche delle informazioni che sono mostrate/gestite tramite tali funzionalità. L individuazione dei confini delle applicazioni dovrebbe rispettare i principi della progettazione strutturata del software noti come: minimizzazione dell accoppiamento e massimizzazione della coesione. In altri termini, le interdipendenze funzionali ed operative tra ASM distinte dovrebbero essere minime o nulle mentre all interno di una ASM non dovrebbero esservi parti tra loro completamente autonome e indipendenti, dal punto di vista operativo e logico; dovrebbero essere ridotti al minimo le ASM di tipo contenitore, in cui le diverse funzionalità sono accomunate dal solo Pagina 16 di 64

17 fatto di non poter essere altrove o dalle modalità di fruizione tecnologiche o da altri fattori non appartenenti alla logica del punto di vista dell utente. LG 3 Servizi software (componenti, web services etc.) messi a disposizione da una ASM per altre ASM devono essere considerati incorporati, come processi elementari o come parte di processi elementari, nelle ASM che li attivano secondo quanto previsto nelle considerazioni sulla comunicazione svolte successivamente. La definizione delle ASM è di completa responsabilità del proprietario delle Applicazioni Software cioè di Lombardia Informatica. Il Catalogo delle ASM sarà consegnato entro l inizio della fornitura. Esso documenta i confini tra le ASM del Patrimonio LI e costituirà, quindi, la base per tutti i conteggi e stime contrattuali. Di norma i confini tra le ASM resteranno stabili per la durata dell appalto; tuttavia, in caso di necessità organizzative di LI, essi potranno essere revisionati di comune accordo tra le Parti. 2.3 Linee Guida per l interazione tra ASM Architettura Tecnologica Stratificata Le architetture software di Lombardia Informatica sono caratterizzate dalla distribuzione di componenti di elaborazione dati su piattaforme tecnologiche separate e cooperanti. Sempre più spesso l esecuzione di un processo è attuata in modo dinamico sull elemento dell architettura più adeguato in un determinato momento. Tale organizzazione consente di fare riuso di componenti generalizzate (spesso chiamati servizi) attraverso la standardizzazione e specializzazione sia delle funzionalità che contribuiscono a raggiungere gli obiettivi applicativi che delle loro interfacce. I modelli che descrivono tali architetture usano il concetto di layer (strato) che costituisce un modo di aggregare tali componenti in base a criteri di omogeneità di rappresentazione e modalità di utilizzo. Un layer è caratterizzato, dunque, da un certo livello di astrazione nella rappresentazione di dati e funzioni che è legato, a sua volta, alla prospettiva di un utilizzatore tipico associabile a quel particolare layer. Ad esempio, il layer applicativo è legato ai bisogni e modi di utilizzo di un sistema da parte di un utente cosiddetto di business, ovvero finale. Un layer di DBMS è legato ai requisiti di trattamento e memorizzazione dei dati indipendentemente dal loro contenuto semantico per l utente finale, si tratta, cioè, di un layer che considera le informazioni più da un punto di vista strutturale che di merito. I layer più utilizzati in LI per aggregare i componenti a livello di classi (approccio OO) Allegato 1.2 METODOLOGIE E LINEE GUIDA DI MISURA DEI FUNCTION Figura POINT 3 - Organizzazione dei Layers Pagina 17 di 64

18 sono: Presentation Layer: contiene l interfaccia utente, tipicamente il browser internet. Da qui vengono richiamate le classi presenti nel Business Layer. Business Layer: contiene le classi che svolgono le funzioni di elaborazione richieste. Possono essere richiamate da una o più classi presenti nel Presentation Layer o anche da classi presenti nello stesso strato. Data Access Layer: contiene le classi che consentono la gestione dei dati del DB. Possono essere richiamate dalle classi del Business Layer. Tale modello, però, è visto da una prospettiva tecnologica orientata alla progettazione e realizzazione smart del codice software e non da quella di un fruitore applicativo. Esso, dunque, enfatizzando gli aspetti di distribuzione e relazione delle componenti client e server residenti su specifici nodi fisici di una rete di elaborazione dati, non si presta ad una individuazione degli oggetti software da misurare dal punto di vista applicativo, come previsto dagli standard internazionali di misura funzionale (ISO 14143). Un processo elementare, applicativo, inizia in genere con l attivazione da parte dell attore di business di funzionalità gestite dall interfaccia per la raccolta delle informazioni per ricerche o scrittura dati, procede attraverso funzionalità di analisi delle richieste e di formulazione, in base alle regole applicative, dei passi procedurali necessari a fornire una risposta alla richiesta utente attraverso, generalmente, la consultazione o la scrittura di archivi permanenti, fino a chiudere lo scenario d uso con un nuovo attraversamento dell interfaccia grafica verso l attore attivante o altro attore. Questo insieme di passi, considerati significativi e inscindibili dal punto di vista dell utente applicativo finale, attraversano più volte i layer precedentemente identificati in presentation, business e data. Questo significa che una separazione del software seguendo quella strada non consente l individuazione dei corretti oggetti software da misurare nella prospettiva funzionale applicativa. Sarà naturalmente possibile usare le suddivisioni indicate, nel caso in cui si voglia effettuare una misura funzionale di un componente software di livello middleware Modello di riferimento per le architetture a componenti Un modello più usabile per la fase di mappatura delle applicazioni di Lombardia Informatica sul modello generico alla base di una misurazione funzionale è quello illustrato nella Figura 4. Pagina 18 di 64

19 Sistema Informativo a livello Enterprise Application Layer App 1 App 2 App n Software Layers Application Component Layer (Business Generalized Services) Technical Component Layer (Technical Generalized Services) Database Management System Layer DBMS 1 DBMS 2 Operating System Layer (File System) Figura 4 : Architettura software da una prospettiva di misurazione in FP Nello schema vediamo che un sistema enterprise può essere considerato come un interfaccia per l attivazione di un insieme di applicazioni che si affacciano agli utenti attraverso una molteplicità di canali e che si poggiano, a loro volta, su una serie di sottostanti strati di software (layers) ognuno dei quali può offrire servizi ai layer sovrastanti in modo diretto o indiretto. Le frecce indicano il verso di chiamata delle componenti su strati sottostanti. Tra il layer applicativo classico e quello del software d ambiente sono stati introdotti due strati intermedi: quello delle componenti di business generalizzate e quello delle componenti tecniche generalizzate. Le prime sono funzioni di business riconoscibili a livello applicativo dagli utilizzatori del sistema ma non sufficientemente autonome da essere considerate parte del livello superiore ovvero ASM indipendenti; esse rappresentano più dei pezzi riconoscibili di software che necessitano di essere composti e aggregati tra loro al fine di rispondere ad un bisogno utente completo (ad es. una componente per la verifica di un codice fiscale da inserire in vari processi elementari del livello applicativo). Le seconde sono funzioni tecniche generalizzate di aiuto per la gestione delle applicazioni (come ad esempio i programmi di stampa o per la realizzazione di form generici ma anche i gestori della sicurezza fisica, i sistemi di controllo input/output, i servizi di rete, quelli di gestione e supporto degli accessi, i servizi client-server). Un esempio di oggetti appartenenti allo strato Business Generalized Services è dato dalle reti mediche. La DG Sanità della Regione Lombardia è impegnata dal 2004 in un numero crescente di progetti di Reti di Patologia: questi progetti, per la loro numerosità, per la quantità degli attori coinvolti e per l estensione delle funzioni previste, rappresentano una sorta di svolta culturale nell organizzazione del lavoro e, di conseguenza, una sfida sia dal punto di vista organizzativo che tecnologico. In questo scenario le tecnologie informatiche e telematiche rappresentano il fattore abilitante nei processi di condivisone del dato clinico e di sviluppo delle potenzialità della rete. La proposta di attuazione dei requisiti prevede la costruzione di una Piattaforma Regionale per le Reti di Patologia (PRRP) che comprenda un insieme di moduli comuni, integrati da altre componenti dedicate alla gestione dei dati prodotti nelle diverse Reti Tematiche, che potranno a loro volta essere riutilizzati nell ambito di altri contesti basati sull infrastruttura del progetto CRS-SISS che rappresenta l infrastruttura portante e garantisce la condivisione di dati amministrativi e clinici in un contesto tecnologico di alto profilo e di rigoroso rispetto del dettato normativo in merito alla tutela dei dati stessi. Pagina 19 di 64

20 In sintesi, in questo modello, uno strato middleware contiene un insieme di funzioni definite dall utente/progettista che lavorano per supportare specifici requisiti di modularizzazione e di indipendenza dall hardware o dai sistemi operativi e dagli ambienti DBMS. Le funzionalità del middleware, essendo generalizzate, possono poi essere utilizzabili da diverse applicazioni (Figura 5), anche non considerate inizialmente nella definizione degli strati dell architettura tecnica. Sistema Informativo a livello Enterprise Application Layer App 1 App 2 App n Software Layers Application Component Layer (Business Generalized Services) Technical Component Layer (Technical Generalized Services) Database Management System Layer DBMS 1 DBMS 2 Operating System Layer (File System) Figura 5 : Collegamento tra componenti La Function Point Analysis IFPUG prevede il dimensionamento delle funzionalità come percepite da un utente esterno, mentre le funzionalità fornite dal middleware sono spesso trasparenti per l utente esterno, nonostante quest ultimo usufruisca dei vantaggi derivanti dalla loro presenza nei sistemi. Ad esempio, una transazione di logon per l autenticazione degli utenti abilitati all accesso ai sistemi può essere considerata come un EI (External Input) dal punto di vista dell utente mentre dal punto di vista del progettista ci potrebbero essere molte altre funzioni elementari e/o transazioni intermedie, eseguite dal middleware e necessarie per il completamento del servizio di autenticazione. I requisiti funzionali possono quindi essere rappresentati nelle specifiche di sistema, a livelli di aggregazione e astrazione anche disomogenei tra loro. La fase di Mappatura introdotta al capitolo avrà il compito di allocare i requisiti funzionali (FUR) sui vari strati software (layers) identificando componenti da misurare in modo indipendente uno dall altro. LG 4 Layers e misura patrimoniale La misura patrimoniale di un software appartenente ad un certo strato è espressa solo in funzione delle componenti percepite e misurate su quello strato e non di quelle superiori da cui è utilizzato o inferiori che utilizza. In altri termini la dimensione patrimoniale in FP di un applicazione software (valida, ad esempio, per il calcolo dei livelli di servizio) non deve essere frutto della somma di misure effettuate su layers diversi. Pagina 20 di 64

21 LG 5 Layers e misure contrattuali Misure su layers diversi possono, però, su richiesta di LI essere sommate tra loro, utilizzando il concetto di ambito, per scopi contrattuali o gestionali diversi dalla valutazione patrimoniale. Ad esempio una misura sul layer Technical Generalized Services può essere presa per remunerare lo sviluppo di componenti middleware che il Fornitore abbia necessità di costruire ex-novo per gestire particolari tecnologie o requisiti utente non funzionali che i sistemi di produzione di mercato oppure quelli vincolati da Lombardia Informatica non consentono di trattare in modo standardizzato. E il caso di una particolare interfaccia utente georeferenziata oppure del driver di governo di un apparato tecnologico commissionato ad hoc. Riassumendo: Ogni Applicazione Software Misurabile (ASM) può essere distribuita, quindi, su più layer, ognuno dei quali contiene componenti software generalizzati (tecnici o di business) concepiti per dare un supporto specifico e riusabile al trattamento di particolari requisiti funzionali o non funzionali dello strato applicativo. Ad esempio, le componenti di presentation management servono per liberare l interfaccia grafica dalla dipendenza dai device fisici o ad implementare requisiti di georeferenzialità (funzioni GIS). L identificazione delle componenti generalizzate appartenenti a strati inferiori di quello di business è fondamentale anche nella valorizzazione della quantità di Riuso attribuibile ad ogni misura di progetto per la determinazione dei corrispettivi contrattuali Comunicazione / condivisione dati tra ASM Le ASM hanno spesso necessità di comunicare o condividere dati con altre ASM. Tali esigenze si concretizzano in scambio di flussi informativi o in condivisione di archivi, come illustrato nella Figura 6 Pagina 21 di 64

22 ATTIVATO Database Management System Layer Application Component Layer (Business Generalized Services) Technical Component Layer (Technical Generalized Services) DBMS 1 DBMS 2 Operating System Layer (File System) ATTIVANTE ATTIVATO Applicazione Software Misurabile Database Management System Layer Application Component Layer (Business Generalized Services) Technical Component Layer (Technical Generalized Services) DBMS 1 DBMS 2 Operating System Layer (File System) ATTIVANTE ATTIVATO Applicazione Software Misurabile Database Management System Layer Application Component Layer (Business Generalized Services) Technical Component Layer (Technical Generalized Services) DBMS 1 DBMS 2 Operating System Layer (File System) ATTIVANTE ATTIVATO Applicazione Software Misurabile Database Management System Layer Application Component Layer (Business Generalized Services) Technical Component Layer (Technical Generalized Services) DBMS 1 DBMS 2 Operating System Layer (File System) ATTIVANTE ATTIVATO Applicazione Software Misurabile Database Management System Layer Application Component Layer (Business Generalized Services) Technical Component Layer (Technical Generalized Services) DBMS 1 DBMS 2 Operating System Layer (File System) ATTIVANTE ATTIVATO Applicazione Software Misurabile Database Management System Layer Application Component Layer (Business Generalized Services) Technical Component Layer (Technical Generalized Services) DBMS 1 DBMS 2 Operating System Layer (File System) ATTIVANTE ATTIVATO Database Management System Layer Application Component Layer (Business Generalized Services) Technical Component Layer (Technical Generalized Services) DBMS 1 DBMS 2 Operating System Layer (File System) ATTIVANTE Gara 3/2014/LI - Procedura aperta ai sensi del D.Lgs. n. 163/2006 per l affidamento dei Applicazione Software Misurabile Applicazione Software Misurabile Applicazione Software Misurabile Application Component Layer Applicazione Software Misurabile (Business Generalized Services) Applicazione Software Misurabile Application Component Layer Application Component Layer (Business Generalized Services) Technical Component Layer (Technical Generalized Services) Technical Component Layer (Technical Generalized Services) (Business Generalized Services) Technical Component Layer (Technical Generalized Services) Database Management DBMS 1 DBMS 2 ATTIVATO System Layer Operating System Layer (File System) ATTIVANTE ATTIVATO Database Management System Layer DBMS 1 DBMS 2 ATTIVANTE Database Management DBMS 1 DBMS 2 ATTIVATO System Layer Operating System Layer (File System) ATTIVANTE Operating System Layer (File System) Figura 6 : Comunicazioni tra Applicazioni Software Misurabili I dati condivisi tra due ASM possono essere trasferiti secondo i seguenti casi: A. tramite schermate on-line (dati attributi di sessione o parametri di chiamate http); B. tramite accesso diretto ai file su altri sistemi; C. tramite accesso ai file su altri sistemi mediato da meccanismi di tipo messaggio/risposta (uso di servizi ); D. tramite il trasferimento di file; Il caso A è normato dal manuale CPM IFPUG [BIB02]. Per quanto riguarda i casi B e C occorre considerare che la comunicazione può essere modellata sia a livello fisico, attraverso i diversi meccanismi implementativi (protocolli) dati dai linguaggi e dagli ambienti tecnologici, che a livello logico che da tali meccanismi è indipendente. LG 6 Livello logico della comunicazione/condivisione Nel modellare la comunicazione/condivisione tra ASM al fine di misurarla in FP occorre trascurare di considerare la collocazione fisica dei servizi o classi o routine destinati ad implementare tutta o parte della comunicazione/condivisione e concentrarsi sul modello logico della comunicazione. Se guardiamo le comunicazioni da una prospettiva di tipo logico ai fini di una loro misurazione funzionale possiamo determinare l ulteriore seguente Linea Guida. LG 7 Comunicazione peer to peer Rientrano tra i candidati BFC delle ASM (EI, EO, EQ) le funzionalità di comunicazione peer to peer (a livello logico) se e solo se esse corrispondono ai criteri di identificazione dei Pagina 22 di 64

23 processi elementari IFPUG ovvero sono autonome, significative e lasciano il sistema in uno stato di coerenza funzionale. LG 8 Incorporamento funzioni Qualora le comunicazioni siano solo strumentali alla esecuzione di processi elementari più ampi che utilizzano componenti distribuite, allora tali servizi devono considerarsi richiamati ed incorporati nel processo che richiede il servizio, pur se tecnicamente sono allocati o attribuiti in ownership ad altre applicazioni rispetto a quella in misurazione. In altri termini, gli elementi costituenti la comunicazione tecnica (DET trasmessi e ILF o EIF referenziati) contribuiranno alla complessità delle transazioni logiche che li utilizzano nell ASM attivante. In considerazione di quanto scritto, il caso C del precedente elenco si riconduce, a seconda delle situazioni meglio illustrate nel seguito, al caso B oppure al caso D. Nel modellare lo scambio/condivisione dati tra due ASM vi sono, quindi, fondamentalmente due modelli, corrispondenti ai casi B e D dell elenco precedente. Al fine di distinguere le due situazioni si riportano le seguenti Linee Guida. Al fine di comprendere meglio le successive LG introduciamo gli elementi da considerare per caratterizzare la comunicazione logica / condivisione dati tra ASM: 1) l avvio (quale è l ASM attivante e quale l ASM attivata), 2) la sincronia della comunicazione (il processo elementare attivante deve attendere le risposte del processo elementare attivato prima di potersi concludere ed eventualmente anche il viceversa), 3) il verso della comunicazione (una via o due vie), 4) il grado di autonomia dell attivante nel reperire le informazioni (accede direttamente ai dati di origine nei modi e tempi voluti o dipende dalla risposta dell applicazione attivata) 5) la storicità del flusso informativo di scambio (si disaccoppia dai dati operazionali da cui proviene rappresentandone una fotografia ad un tempo t non più aggiornata in caso di cambiamento dei dati di origine). Quando si parla di comunicazione asincrona e sincrona, in generale, ci si può riferire a due diversi aspetti: quello tecnico e quello logico. Nella prima prospettiva, il meccanismo specifico di interconnessione può consentire di disaccoppiare la comunicazione attraverso strumenti come il message queueing o lo store and forward o, viceversa, di mantenere una sincronia fisica dei processi software cooperanti attraverso strumenti come i web services. Nella seconda prospettiva, invece, quella adottata nel presente approccio, indipendentemente dal meccanismo tecnico, si deve guardare il contenuto semantico dei processi elementari che necessitano di comunicazione, per capire se i flussi dati interscambiati con altre sorgenti informative siano coerenti o no rispetto ai criteri di significatività per l utente, di autonomia e di coerenza funzionale del sistema al termine del processo stesso, che l IFPUG prevede. Pagina 23 di 64

24 Una comunicazione tecnicamente asincrona potrebbe essere logicamente sincrona in quanto il processo elementare che l ha invocata non può terminare in mancanza di quelle risposte che dal solo punto di vista tecnico potrebbero essere disaccoppiate per motivi di disegno tecnico ed opportunità tecnologica Avvio Le comunicazioni tra Applicazioni Software Misurabili possono riguardare il funzionamento di un applicazione in modalità attivata (risponde, cioè, a stimoli provenienti da altri sistemi) o in modalità attivante (invia stimoli ad altri sistemi). Ai fini della distinzione delle due situazioni occorre identificare l evento che scatena la comunicazione (triggering event) Sincronismo e verso di comunicazione Le comunicazioni possono essere, quindi, logicamente sincrone o asincrone. Nel primo caso un processo elementare dell applicazione attivante richiede uno scambio informativo con un altra applicazione e non termina finché tale scambio non sia avvenuto: i processi elementari corrispondenti nelle due applicazioni sono concomitanti. La comunicazione può essere unilaterale o bilaterale ma è, in ogni caso, basata su un flusso di dati dinamico gestito dalle due parti da transazioni logiche che operano in modo sincrono. Nel secondo caso il processo elementare dell applicazione attivante emette lo stimolo e la comunicazione informativa e termina il suo compito senza attendere la risposta da parte dell applicazione attivata che svolge le sue funzioni in autonomia. La comunicazione è quindi unilaterale (fatta esclusione di eventuali informazioni di controllo sul buon andamento del trasferimento dati) Autonomia e storicità nel reperimento dei dati Una ASM che deve ricevere informazioni da parte di un altra ASM può accedere a tali dati in autonomia relativamente a tempi e modalità oppure è condizionata dal ricevere tali dati da parte di un processo elementare specificatamente predisposto nell applicazione emittente. La differenza sostanziale in termini di conteggio è che nel primo caso l accesso ai dati è modellato attraverso la referenza (FTR) ad uno o più files logici presente/i in un processo elementare dell applicazione ricevente che utilizza tali dati. Nel secondo caso l applicazione emittente prepara un flusso dati che esporterà attraverso un EO/EQ attraverso il confine dell applicazione verso l applicazione ricevente che attiverà una transazione di tipo EI preposta al raccoglimento dei dati stessi senza la referenza FTR agli archivi eventualmente utilizzati dall emittente, esattamente come fossero digitati da un attore umano attraverso un device di input. In genere nel primo caso i dati sono acceduti nel loro stato istantaneo di validità corrente, nel secondo caso il flusso dati è storicizzato al momento della estrazione da parte dell applicazione emittente e, nel momento del loro utilizzo da parte dell applicazione ricevente, potrebbero non essere corrispondenti ed aggiornati allo stato corrente degli archivi originali. Gli schemi seguenti illustrano i due casi e i criteri di scelta relativi. Pagina 24 di 64

25 . Gara 3/2014/LI - Procedura aperta ai sensi del D.Lgs. n. 163/2006 per l affidamento dei LG 9 Accesso logico diretto ai dati Il Sistema B accede logicamente in modo diretto ai dati del Sistema A al fine di effettuare una interrogazione (EQ/EO) oppure di processare un EI. Il file logico X è un ILF per l ASM A ed è un EIF per l ASM B. Sistema A ILF X Utilizza i Dati EI EO/EQ EIF (ILF) Sistema B X (EQ/ EO) (EI) 1. l'iniziativa è presa da B 2. il processo elementare attivante deve attendere le risposte del processo elementare attivato prima di potersi concludere 3. la comunicazione è a due vie (richiesta/risposta) 4. l'attivante è autonomo nel reperire le informazioni 5. il flusso informativo di scambio non è disaccoppiato dai dati operazionali da cui proviene. LG 10 Invio-ricezione flusso dati In questo caso non siamo in presenza di condivisione di archivi logici ma di scambio di un flusso dati preparato dall applicazione A e messo a disposizione dell applicazione B al fine di realizzare un aggiornamento di uno o più ILF oppure di effettuare una interrogazione (EQ/EO) Sistema A ILF / EIF EQ / EO (EI) (IIF) Sistema B (EQ/ EO) (EI) 1. l'iniziativa è presa da A 2. il processo elementare attivante non deve attendere le risposte del processo elementare attivato prima di potersi concludere 3. la comunicazione è a una via 4. l attivato non è autonomo nel reperire le informazioni 5. il flusso informativo di scambio è disaccoppiato dai dati operazionali da cui proviene Replica di dati relativi a DB aziendali e batch di allineamento Cosa si conta nel caso in cui una ASM A (oggetto di conteggio) debba utilizzare dati gestiti da una ASM B che vengono replicati fisicamente all'interno della ASM A? LG 11 Replica di dati relativi a DB aziendali Nel caso in cui l'utente di A abbia percezione che il DB incluso nella ASM oggetto di conteggio possa contenere dati disallineati rispetto al DB aziendale gestito da B si conta un ILF per la ASM A ed un EI per il batch di allineamento, oltre all'eif della ASM B. Negli altri casi si conta solo l'eif del DB di B (es. il DB locale è stato creato solo per minimizzare i tempi di reperimento delle informazioni o per altri motivi prestazionali e non funzionali). Pagina 25 di 64

26 Ad esempio: Una ASM A gestisce le prenotazioni aeree di un'agenzia di viaggi. In tale ASM viene gestito un DB locale sulla disponibilità dei voli, aggiornato con una determinata periodicità rispetto al DB della compagnia aerea. Durante il processo di prenotazione in agenzia, l'utente attiva un processo elementare per verificare l'effettiva disponibilità sul DB della compagnia aerea; in tal caso l'utente ha percezione del possibile disallineamento dei due DB, quindi si conta l'eif della compagnia aerea oggetto di consultazione per verificare l'effettiva disponibilità dei posti, un ILF per il DB locale ed un EI di allineamento delle informazioni locali Incorporamento servizi di altre ASM Possono esistere casistiche in cui occorra realizzare una ASM (sviluppo ex-novo) oppure modificare una ASM esistente (MEV funzionale) che contenga processi elementari che utilizzano servizi di altre applicazioni che devono a loro volta essere creati, modificati, cancellati o che restino immutati. I servizi software (componenti, web services etc.) messi a disposizione da una ASM per altre ASM non sono funzioni complete di business ma rappresentano più dei pezzi riconoscibili di software che necessitano di essere composti e aggregati tra loro al fine di rispondere ad un bisogno utente completo (ad es. una componente per la verifica di un codice fiscale da inserire in vari processi elementari del livello applicativo, i servizi di accesso comune). I servizi possono anche coincidere con funzioni tecniche generalizzate di aiuto per la gestione delle applicazioni (come ad esempio i programmi di stampa o per la realizzazione di form generici ma anche i gestori della sicurezza fisica, i sistemi di controllo input/output, i servizi di rete, i servizi client-server). La figura seguente illustra i diversi elementi funzionali introdotti finora per aiutare nella comprensione di cosa e dove conteggiare nel caso di un intervento di sviluppo o manutenzione evolutiva funzionale. Pagina 26 di 64

27 Figura 7: Incorporamento servizi tra Applicazioni Software Misurabili LG 12 Conteggio di servizi incorporati Un intervento di sviluppo o manutenzione evolutiva funzionale di una ASM (in figura ASM01) che comporta l aggiunta, modifica o cancellazione di servizi comuni su un altra ASM (in figura ASM02), dovrà conteggiare su ASM01 le funzionalità utente di livello business richieste e su ASM02 i servizi comuni condivisi tra più ASM coinvolti da operazioni di aggiunta, modifica o cancellazione al fine di implementare i requisiti utente funzionali dell intervento su ASM01. Si riportano nel seguito le principali casistiche che si possono verificare. Supponiamo che un processo elementare pe0103 di ASM01 utilizzi un servizio0203 di ASM02. Gli scenari significativi sono: 1. ADD di pe0103 su ASM01 ADD di servizio0203 su ASM02 2. ADD di pe0103 su ASM01 CHG di servizio0203 su ASM02 3. ADD di pe0103 su ASM01 nulla su servizio0203 su ASM02 4. CHG di pe0103 su ASM01 ADD di servizio0203 su ASM02 5. CHG di pe0103 su ASM01 CHG di servizio0203 su ASM02 6. CHG di pe0103 su ASM01 DEL di servizio0203 su ASM02 7. CHG di pe0103 su ASM01 nulla su servizio0203 su ASM02 8. DEL di pe0103 su ASM01 CHG di servizio0203 su ASM02 9. DEL di pe0103 su ASM01 DEL di servizio0203 su ASM DEL di pe0103 su ASM01 nulla su servizio0203 su ASM nulla su pe0103 su ASM01 CHG su servizio0203 su ASM02 Pagina 27 di 64

28 In tutti i casi in cui sia necessario effettuare un abbattimento per riuso di servizi riferirsi al capitolo Errore. L'origine riferimento non è stata trovata.. Gli eventuali abbattimenti per riuso non vanno effettuati sui conteggi patrimoniali ma solo per il conteggio di interventi di sviluppo o manutenzione evolutiva funzionale ADD di pe0103 ADD di servizio0203 In questo caso il processo elementare in ASM01 viene creato contestualmente alla realizzazione di un servizio comune in ASM02. Conteggio in ASM01 Il conteggio del processo elementare di business pe0103 viene abbattuto per riuso di componenti in misura proporzionale all entità del risparmio di lavoro che si ottiene usando il servizio0203. Tale abbattimento non riguarda il conteggio patrimoniale. Conteggio in ASM02 Il servizio0203 non pre-esiste e viene conteggiato per intero come ADD modellandolo come processo elementare di middleware ADD di pe0103 CHG di servizio0203 In questo caso il processo elementare in ASM01 viene creato contestualmente alla modifica di un servizio comune pre-esistente in ASM02. Conteggio in ASM01 Il conteggio del processo elementare di business pe0103 viene abbattuto per riuso di componenti in misura proporzionale all entità del risparmio di lavoro che si ottiene usando il servizio0203. Tale abbattimento non riguarda il conteggio patrimoniale. Conteggio in ASM02 Il servizio0203 viene conteggiato per intero come CHG modellandolo come processo elementare di middleware ADD di pe0103 nulla su servizio0203 In questo caso il processo elementare in ASM01 viene creato utilizzando un servizio comune pre-esistente in ASM02 che non subisce modifica. Conteggio in ASM01 Il conteggio del processo elementare di business pe0103 viene abbattuto per riuso di componenti in misura proporzionale all entità del risparmio di lavoro che si ottiene usando il servizio0203. Tale abbattimento non riguarda il conteggio patrimoniale. Conteggio in ASM02 Non si conteggia nulla CHG di pe0103 ADD di servizio0203 In questo caso il processo elementare pre-esistente in ASM01 viene modificato creando al contempo un nuovo servizio comune in ASM02. Conteggio in ASM01 Il conteggio del processo elementare di business pe0103 viene abbattuto per riuso di componenti in misura proporzionale all entità del risparmio di lavoro che si ottiene usando il servizio0203. Tale abbattimento non riguarda il conteggio patrimoniale. Pagina 28 di 64

29 Conteggio in ASM02 Si conteggia per intero il servizio CHG di pe0103 CHG di servizio0203 In questo caso il processo elementare pre-esistente in ASM01 viene modificato modificando al contempo un servizio comune pre-esistente in ASM02. Conteggio in ASM01 Il conteggio del processo elementare di business pe0103 viene abbattuto per riuso di componenti in misura proporzionale all entità del risparmio di lavoro che si ottiene usando il servizio0203. Tale abbattimento non riguarda il conteggio patrimoniale. Conteggio in ASM02 Si conteggia per intero il servizio CHG di pe0103 DEL di servizio 0203 In questo caso il processo elementare pre-esistente in ASM01 viene modificato cancellando al contempo il pre-esistente servizio comune in ASM02 ed incorporando le sue funzioni. Conteggio in ASM01 Il conteggio del processo elementare di business pe0103 viene abbattuto per riuso di componenti in misura proporzionale all entità del risparmio di lavoro che si ottiene incorporando il servizio0203. Tale abbattimento non riguarda il conteggio patrimoniale. Conteggio in ASM02 Il servizio0203 viene conteggiato per intero come DEL CHG di pe0103 nulla sul servizio 0203 In questo caso il processo elementare pre-esistente in ASM01 viene modificato lasciando inalterato il pre-esistente servizio comune in ASM02. Conteggio in ASM01 Il processo elementare di business pe0103 viene conteggiato per intero come CHG. Conteggio in ASM02 Non si conta nulla DEL di pe0103 CHG di servizio0203 In questo caso il processo elementare pre-esistente in ASM01 viene cancellato comportando dei cambiamenti al pre-esistente servizio comune in ASM02. Conteggio in ASM01 Il processo elementare di business pe0103 viene conteggiato per intero come DEL. Conteggio in ASM02 Si conteggia per intero come CHG il servizio DEL di pe0103 DEL di servizio0203 In questo caso il processo elementare pre-esistente in ASM01 viene cancellato comportando la cancellazione del pre-esistente servizio comune in ASM02. Conteggio in ASM01 Il processo elementare di business pe0103 viene conteggiato per intero come DEL. Pagina 29 di 64

30 Conteggio in ASM02 Il servizio0203 viene conteggiato per intero come DEL DEL di pe0103 nulla sul servizio0203 In questo caso il processo elementare pre-esistente in ASM01 viene cancellato lasciando inalterato il pre-esistente servizio comune in ASM02. Conteggio in ASM01 Il processo elementare di business pe0103 viene conteggiato per intero come DEL. Conteggio in ASM02 Non si conta nulla nulla su pe0103 CHG su servizio0203 In questo caso il processo elementare pre-esistente in ASM01 resta inalterato mentre il preesistente servizio comune in ASM02 cambia per esigenze indipendenti da ASM01 e senza implicazioni per esso. Conteggio in ASM01 Non si conta nulla. Conteggio in ASM02 Il servizio0203 viene conteggiato per intero come CHG. Pagina 30 di 64

31 2.4 Linee Guida Generali per la stima/misura dei FP (LG-G) Funzioni di tipo transazionale richieste su più canali Per funzioni di tipo transazionale richieste su più canali si intende la replicazione di una stessa funzionalità su più mezzi di fruizione. LG 13 Funzioni di tipo transazionale richieste su più canali All interno di una stessa ASM, i processi elementari identici, che differiscono esclusivamente per il mezzo di fruizione (canale), si contano una sola volta a livello logico per determinarne il contributo agli UFP rilasciati. La replicazione, però, avrà una influenza sul valore della Misura Funzionale Contrattuale (MFC) come illustrato nella sezione Elaborazioni complesse e individuazione dei processi elementari Quando, nell analisi dei requisiti funzionali, si incontra una funzione composta da molti passi elaborativi, la domanda che ci si pone è se essa sia da considerarsi come un solo processo elementare o come un insieme di processi elementari tra loro indipendenti. Il valore in FP complessivo associabile alla funzione identificata può cambiare e anche di molto a seconda della decisione. Esempi di questo tipo di funzioni sono i workflow, i grossi batch di elaborazione off line oppure le maschere multi processo nelle quali il flusso di lavoro si costruisce dinamicamente in base alle scelte che l utente opera all interno di una interfaccia comune. Nell ambito dell utilizzo di una funzionalità software possiamo definire come punti di consistenza funzionale quelli raggiunti i quali non è necessario ripristinare il sistema in uno stato precedente all avvio della funzione in caso di terminazione anomala o di annullamento della stessa da parte dell utente. Un processo di roll-back consente di ripristinare automaticamente un punto di consistenza precedente alle operazioni della transazione fallita o interrotta. Fermo restando che il principio base a cui rifarsi nel prendere la decisione è la definizione di processo elementare della FPA, al riguardo si stabiliscono le seguenti Linee Guida. LG 14 Analisi di variabili di stato relative ai processi/dati Nell ambito di un flusso di lavoro supportato da una funzionalità software, la presenza di variabili di stato relative alle strutture dati significative per l utente, che descrivono la natura dei dati in ogni momento memorizzati e disponibili per la consultazione, è di guida nella identificazione dei punti di consistenza funzionale. Occorre individuare tutte le attività che consentono di passare da un punto di consistenza a un altro contrassegnato da valori diversi delle variabili di stato. In altri termini le funzionalità vengono aggregate in passi autonomi ognuno dei quali fa passare la ASM da uno stato di consistenza ed equilibrio ad un altro. Pagina 31 di 64

32 Consideriamo, ad esempio, un workflow di gestione di una pratica di mutuo. La pratica, per arrivare al compimento, subisce stati successivi di lavorazione auto-consistenti, operati da personale diverso, tracciati e consultabili in termini di mappatura e di statistiche e così via. Sebbene all utente finale interessi la chiusura della pratica, è obbligatorio suddividere la funzione complessiva in processi elementari singoli intermedi, uno per ogni passaggio di stato della pratica. LG 15 Analisi di processi di roll-back Un processo elementare che può operare cambiamenti nelle strutture dati (EI, EO) è associabile a uno o più processi di roll-back che devono essere tra loro alternativi e non sequenziali. Tutte le attività interessate dai processi di roll-back così individuati fanno parte del processo elementare in questione. LG 16 Maschere multi processo Quando ci si trova a cospetto di un interfaccia che riunisce in una stessa videata o in videate correlate diversi percorsi alternativi costruiti dinamicamente in funzione delle scelte di compilazione dei campi da parte dell utente occorre prescindere dalla modalità di interazione e immaginare l equivalente situazione funzionale nella quale i diversi processi elementari attivabili possano essere selezionati separatamente uno dall altro a partire da un menu di scelta Gestione dei menu dinamici Archivi logici per la gestione dei menu dinamici I menu di scelta delle funzioni da attivare in sede di esecuzione, che sono generalmente offerti dall'interfaccia utente, non sono mai da contare secondo il metodo standard. Questo è però valido solo per la navigazione statica ovvero per la presentazione di opzioni fisse indipendentemente dalla tipologia di utente e dai suoi privilegi. LG 17 Menu dinamici: parte dati Nel caso di menu dinamici, nel quale l'elenco delle funzionalità offerte cambia in funzione dell'utilizzatore o di altre variabili d'ambiente e che contengono a volte elenchi di ultimi file aperti o opzioni più frequentemente usate, siamo in presenza della necessità di mantenere traccia permanente di queste abilitazioni e voci di menu e/o opzioni ricorrenti. Nasce quindi la necessità di identificare un file logico interno contenente informazioni sulle funzioni abilitabili in funzione delle permission e sugli ultimi file aperti. Pagina 32 di 64

33 Transazioni per la gestione dei menu dinamici LG 18 Menu dinamici: parte transazionale In corrispondenza del file logico interno per la gestione di menu dinamici esisterà, per ogni applicazione che ne fa uso, una transazione di scrittura (per gli ultimi file aperti e altre informazioni registrate in corso d utilizzo) ed una di enquiry deputata alla costruzione del menu dinamico. La scelta delle funzionalità da attivare nei menu dinamici, invece, non sarà contata esplicitamente Storicizzazione Archivi logici per la storicizzazione Nel realizzare un sistema software, talvolta, è necessario prevedere per i dati uno stato "corrente" ovvero considerato in corso di validità e uno o più stati storicizzati che si riferiscono a "fotografie coerenti" dei dati stessi prese in momenti particolari della vita passata del sistema. Tali dati storici possono o no essere significativi dal punto di vista della misura. Per poter riconoscere l'esistenza di specifici archivi logici di storicizzazione occorre verificare l'esistenza (anche disgiunta ovvero non contemporanea) di alcune condizioni. LG 19 Condizioni per il trattamento della storicizzazione sui dati l'utente considera significativa la differenza di stato tra dati correnti (aggiornati e in corso di validità) e dati storici (cristallizzati e fuori corso di validità). il requisito di storicizzazione non dipende solamente da esigenze di ottimizzazione di prestazioni o da altri requisiti non funzionali. i valori del file storico non possono essere riprodotti o derivati dai dati correnti presenti nel sistema, cioè dal corrispondente file logico corrente. Un criterio determinante per l'esistenza di un file storico è quindi il range di validità temporale che l'utente riconosce al file logico corrente cioè il periodo temporale entro il quale i dati di un certo file logico devono essere mantenuti accessibili on line attraverso transazioni operazionali ordinarie ovvero incentrate sulla gestione corrente. Un esempio è quello di un file contenente multe elevate a cittadini la cui prescrizione è fissata in 5 anni. Scaduto il tempo di prescrizione le multe sono cancellate (logicamente) dal file corrente e spostate (logicamente) in un archivio storico da cui possono essere consultate con specifiche transazioni distinte da quelle correnti. accedendo con transazioni di interrogazione ai file logici, non è obbligatorio fornire, tra gli attributi di filtro, le date di validità che consentono di differenziare i dati correnti da quelli storicizzati in quanto tale differenziazione è garantita in automatico dal sistema e questa è una condizione nota all'utente. gli attributi logici nel file storico sono differenti da quelli presenti nel file corrente, per esempio sono presenti dei dati aggregati che hanno significato solo in quanto relativi a dati storici. Pagina 33 di 64

34 Talvolta il requisito di storicizzazione può essere implementato attraverso l'apposizione su ogni record di un certo file logico di una coppia di date (dette di audit) corrispondenti all'inizio di validità del record stesso e alla sua fine. Questa modalità, però, è solo una soluzione tecnica che potrebbe dar adito a diverse impostazioni logiche. Al di là delle modalità di implementazione dei requisiti di storicizzazione occorre sempre verificare la validità delle condizioni riportate precedentemente Transazioni di storicizzazione Esistono transazioni di storicizzazione quando l'utente chiede esplicitamente o implicitamente la disponibilità di funzionalità per l'inserimento, l'estrazione o la manipolazione di dati storici in modo distinto dai dati correnti ovvero usando transazioni che abbiano dati elementari o trattamenti logici diversi da quelle che operano sui dati correnti. LG 20 Condizioni per il trattamento della storicizzazione sulle transazioni Quando una capability di backup-recovery è fornita automaticamente dai sistemi operativi o di gestione dei DB e consiste nella replica completa di tutti i dati così come congelati a un certo istante nel tempo, essa non è da contarsi in FP né tra le transazioni né tra i dati. Occorre, invece, considerare nel conteggio FP le transazioni e i dati di storicizzazione che implicano trattamenti logici articolati e differenziati in funzione delle operazioni che si vogliono svolgere su tali dati storici Gestione dei log Archivi logici per la gestione dei log I log sono archivi deputati al mantenimento di informazioni sugli accessi degli utilizzatori alle varie funzioni delle ASM per la tracciatura delle operazioni svolte. LG 21 Gestione dei log: parte dati Una distinzione fondamentale, ai fini del conteggio in FP, è quella derivante dalla identificazione o meno di specifici requisiti utente (espliciti o impliciti) in termini di tracciatura. E necessario, quindi, capire se tale funzione sia richiesta come parte integrante dei requisiti applicativi o se, viceversa, sia effettuata e inclusa negli strumenti standard di esercizio e non considerata come essenziale dal punto di vista utente. In caso di risposta affermativa circa la significatività e utilità, si potrà considerare, generalmente, un file logico interno di log la cui struttura dipenderà dagli specifici requisiti di tracciatura Transazioni per la gestione dei log LG 22 Gestione dei log: parte transazionale Il File di Log sarà un FTR in più per tutte le transazioni (EO,EI) che l utente richiede di tracciare. Occorre considerare che, in virtù della necessità di tracciare un EQ, questo non potrà più rimanere tale in quanto verrebbe a cadere il requisito di non scrittura di file logici da parte degli EQ che si trasformano, dunque, in EO. Oltre a questo, sarà probabilmente Pagina 34 di 64

35 necessario realizzare delle funzioni di accesso ai log per enquiry (EQ) o per statistiche (EO) Form di visualizzazione dei dati da modificare/cancellare Un form di modifica/cancellazione dei dati di uno o più ILF prevede la possibilità di visualizzare le informazioni memorizzate in modo da decidere su quali effettuare le operazioni. Cosa si conta per la visualizzazione delle informazioni propedeutica alla modifica/cancellazione? LG 23 Form di visualizzazione ante modifica/cancellazione Si conta un EQ per il processo di visualizzazione dei dati già memorizzati nell'applicazione ed oggetto di modifica/cancellazione, anche nel caso in cui il requisito di visualizzazione non sia esplicitato unitamente a quello di modifica/cancellazione Gestione dell Help Archivi logici per la gestione dell Help LG 24 Gestione Help: parte dati Per ogni specifica ASM si conta un EIF per l help di campo e un EIF distinto per l help di maschera e di applicazione. Nel caso in cui vengano fornite funzionalità utente per la variazione dei contenuti dell help gli EIF si tramutano in ILF Transazioni per la gestione dell Help LG 25 Gestione Help: parte transazionale La transazione che richiama un help di campo è un EQ così come quella che richiama un help di maschera e di applicazione è un altro EQ distinto dal precedente Output parametrici Output parametrico sui campi da visualizzare Cosa si conta per il form che permette di lanciare un report specificando i campi da visualizzare? LG 26 Output parametrico sui campi da visualizzare Si conta un solo processo elementare per il form e per il report con il numero massimo di DET/FTR presenti Output parametrico sui campi di filtro Cosa si conta per il form che permette di lanciare un report specificando i valori di filtro? LG 27 Output parametrico sui campi di filtro Pagina 35 di 64

36 Nel caso in cui i campi di filtro sono raggruppabili in insiemi mutuamente esclusivi, si conta un processo elementare per ciascun insieme considerando i DET/FTR interessati dall'insieme oggetto di conteggio, altrimenti si conta un solo processo elementare con il numero massimo di DET/FTR presenti Output parametrico sui campi di filtro e sui campi da visualizzare Cosa si conta per il form che permette di lanciare un report specificando i campi da visualizzare ed i valori dei filtri? LG 28 Output parametrico sui campi di filtro e sui campi da visualizzare Nel caso in cui i campi di filtro sono raggruppabili in insiemi mutuamente esclusivi, si conta un processo elementare per ciascun insieme considerando i DET/FTR interessati dall'insieme oggetto di conteggio (form+report), altrimenti si conta un solo processo elementare (form+report) con il numero massimo di DET/FTR presenti Funzioni di Log-on (cfr. Knowledge Base) Cosa si conta per le funzionalità che permettono il log-on ad un sistema? Distinguiamo due casi: 1. Accesso gestito come single sign on (effettuato da un applicazione separata dalla ASM in conteggio) 2. Accesso gestito direttamente dalla ASM in conteggio. Nel caso 1 il riconoscimento dell utente è escluso dal conteggio e vale la seguente LG LG 29 Funzioni che utilizzano le permission Ogni transazione il cui comportamento è influenzato dalle permission dovrà avere tra i file referenziati, tutti quelli necessari a determinare i livelli di accesso e utilizzo possibili. Essi saranno EIF per la ASM in conteggio. Nel caso 2 vale la seguente: LG 30 Funzioni di Log-on Il Log-on va considerato un EI che aggiorna l archivio logico interno parametri di configurazione dell'applicazione" che sarà utilizzato dalle transazioni della ASM in modo analogo a quanto previsto dalla Errore. L'origine riferimento non è stata trovata. e che costruisce tutti i menu dinamici della ASM che, quindi, non saranno conteggiati separatamente Gestione informazioni di controllo/ configurazione Come si conta la gestione delle informazioni non di tipo applicativo, ma di controllo/configurazione (es. dei layout: orientamento delle stampe, colore delle videate)? LG 31 Informazioni di controllo/ configurazione Si conta: Pagina 36 di 64

37 - un ILF relativo ai "parametri di configurazione dell'applicazione", - ciascun processo elementare necessario per gestire tale ILF, - per i processi oggetto di tale parametrizzazione un FTR per la consultazione dei "parametri di configurazione dell'applicazione". Qualora le funzionalità oggetto di parametrizzazione fossero disponibili mediante l'utilizzo di un prodotto di mercato acquistato da LI ed inglobato nell'applicazione non si contano FP per tali funzionalità (ad es. report realizzati mediante SAP Crystal Reports, Business Objects). Pagina 37 di 64

38 2.5 Linee Guida su Graphical User Interface e Function Point (LG-GUI) La GUI è un modo di interazione con gli utilizzatori dei sistemi informativi che privilegia gli aspetti grafici e l utilizzo di strumenti di interazione visuali, come mouse, tavolette grafiche, touch screen etc. Il software che gestisce la GUI non costituisce ASM a sé stante ma è incorporato in tutte le ASM che sfruttano tale modalità di interazione. Una Interfaccia Utente Grafica (GUI) è costituita da: - una o più finestre - vari elementi di interfaccia iconica Una finestra è una qualsiasi area sullo schermo che viene gestita come risorsa individuale caratterizzata da - propri eventi a cui è sensibile, - una sua geometria (posizione, dimensione), - sue strutture dati accessorie (es. color map). Ci sono finestre a top-level (gestite dal window manager) e sottofinestre (contenute in altra finestra detta genitrice). Gli elementi di interfaccia sono oggetti con aspetto grafico e/o sensibilità a particolari eventi che "popolano" una finestra e permettono interazione con l'utente. Per le linee guida di misurazione in FP di questo tipo di applicazioni si rimanda al documento [BIB16] LI-ALM-SISMET-FP-LG-GUI#10. Di seguito è riportato il sommario dei contenuti presenti nella Linea Guida citata. Sommario 1. Introduzione 1.1 Acronimi e Termini 1.2 Riferimenti Documentali 1.3 Ambito di applicazione del documento 2. Linee Guida di conteggio delle GUI Barra di scorrimento (scroll bar) Combo box List box Check box Gruppo di Radio Buttons Bottone Bottone dinamico Text box Box con Spin Button Schede sovrapposte (Multipage Tabs) Finestre multiple (Multipage) Frame dinamico Finestra di dialogo Menu fisso e menu a tendina Struttura ad albero Pagina 38 di 64

39 Barra di stato Barra degli strumenti Puntatore dinamico del mouse Controllo grafico per attribuire un valore Rappresentazione grafica di dati Oggetto grafico interattivo Elementi multimediali 2.6 Linee Guida per Applicazioni Web-based (LG-Siti Web) Siti, portali e applicazioni web sono definibili come insiemi logicamente collegati di funzionalità software interattive e di dati che soddisfano specifici requisiti di business implementati all interno di sistemi internet, intranet o extranet. Esempi possono essere: brochure di presentazione, newsletter, bacheca elettronica, raccolta di pubblicazioni da scaricare, questionario, forum di discussione, sistema di accettazione ordini, motori di ricerca, etc. Un sito o portale web può essere considerato come una modalità di interfacciamento verso l utente finale o l amministratore, di applicazioni software di vario tipo. La home page di un sito o di un portale è, in effetti, corrispondente ad un insieme integrato di finestre fisiche attraverso le quali le varie applicazioni offrono le loro funzionalità alla fruizione dell utente, indipendentemente da quanto avviene nelle altre finestre contemporaneamente presenti. Ai fini di semplificare l analisi delle regole IFPUG da applicare per questo tipo di implementazioni, le applicazioni WEB-based saranno suddivise logicamente in due classi distinte in base alle loro caratteristiche di base, ma quasi sempre integrate nell uso corrente: le applicazioni web navigazionali e le applicazioni web transazionali. Applicazioni Web Navigazionali La maggior parte dei siti web sono paragonabili a pubblicazioni elettroniche di dati testuali, audio e video disponibili in linea per la navigazione ed il cui paradigma di riferimento è l ipertesto o l ipermedia. In questo tipo di software l utente è autonomo nella scelta dei percorsi e delle attività e non viene guidato in modo procedurale. Non è possibile, quindi, individuare vere e proprie transazioni in senso classico. Inoltre i flussi di dati si svolgono essenzialmente in una direzione, dal server verso il client, salvo per le scelte di navigazione. Le pagine mostrate sono nella maggior parte dei casi statiche, anche se a volte vengono composte in modo dinamico in base a scelte utente o ad informazioni raccolte in modo autonomo dal server (log di navigazione, cookies). Applicazioni Web Transazionali Si tratta di vere e proprie applicazioni di tipo strutturato il cui paradigma di riferimento è costituito dal sistema informativo transazionale classico. Esempi di questa seconda classe di sistemi sono il commercio elettronico (internet), la raccolta di informazioni di rendiconto sulle attività svolte dai dipendenti (intranet), l accesso ai sistemi operativi di magazzino da parte dei clienti - fornitori (extranet). Pagina 39 di 64

40 E ormai comune l integrazione tra i due tipi di sistemi, per cui spesso siti e portali web presentano una componente navigazionale ed una transazionale. Ne sono un esempio i siti di presentazione delle aziende sanitarie che consentono anche di prenotare i servizi da loro offerti: la parte di presentazione dell azienda è prevalentemente navigazionale, mentre quella di prenotazione è transazionale. Per le linee guida di misurazione in FP di questo tipo di applicazioni si rimanda al documento [BIB17] [LI-ALM-SISMET-FP-LG-SITIWEB]. Di seguito è riportato il sommario dei contenuti presenti nella Linea Guida citata. Sommario 1. Introduzione 1.1 Acronimi e Termini 1.2 Riferimenti Documentali 1.3 Ambito di applicazione del documento 2. Linee Guida per l applicazione della procedura standard della misura funzionale 2.1 Identificare i Requisiti utente funzionali Tipologie di Utenti 2.2 Determinare il Tipo di conteggio Attività di Publishing e Restyling 2.3 Identificare Scopo e Ambito del conteggio 2.4 Identificazione del Confine dell Applicazione Aspetti generali per l identificazione del confine Aspetti specifici per l identificazione del confine nei Siti Web 2.5 Contare le Funzioni di tipo Dati 2.6 Contare le funzioni di tipo Transazionale 3. A1: Case Study 3.1 Sistema Portali Regione Lombardia Premessa Minisito lingua inglese: esempio di conteggio delle funzioni navigazionali Esempio di conteggio delle funzioni transazionali del SPRL 2.7 Linee Guida per Applicazioni Data Warehouse (LG-DW) Il Data Warehouse è una raccolta di dati integrata, orientata al soggetto, variabile nel tempo e non volatile di supporto ai processi decisionali. L'integrazione dei dati costituisce la principale caratteristica distintiva del DW rispetto ad altri sistemi di supporto alle decisioni. Esso si differenzia in modo sostanziale dai normali sistemi gestionali che hanno il compito di automatizzare le operazioni di routine. Sul tema della misurazione funzionale dei data warehouse esiste oggi un white paper IFPUG che è punto di riferimento per gli approcci di misura [BIB09]. Pagina 40 di 64

41 Lo scopo dei Function Point IFPUG è quello di fornire una misura obiettiva della quantità di funzioni offerte da un ASM ai suoi utenti quantificando cosa permette di fare un applicazione, in termini di dati a disposizione e operazioni su di essi. Un DW per le sue specificità potrebbe rendere, in alcuni casi, non univoca l interpretazione delle regole di conteggio dei Function Point. Per le linee guida di misurazione in FP di questo tipo di applicazioni si rimanda al documento [BIB18] LI-ALM-SISMET-FP-LG-DW, Di seguito è riportato il sommario dei contenuti presenti nella Linea Guida citata. Sommario 1. Introduzione 1.1 Finalità e ambito di applicazione del documento 1.2 Ambito di applicazione 1.3 Acronimi e Termini 1.4 Riferimenti Documentali 2. Modello di Riferimento Note generali per l applicazione delle Linee Guida 3. Linee Guida per l applicazione della Procedura standard di Misura Funzionale 3.1 Identificare i Requisiti utente Funzionali 3.2 Determinare il Tipo di Conteggio 3.3 Identificare Scopo e Ambito del Conteggio 3.4 Identificare il Confine dell Applicazione Aspetti generali per l identificazione del Confine Aspetti specifici per l identificazione del Confine nei sistemi DW 3.5 Contare le Funzioni di tipo Dati 3.6 Contare le Funzioni di tipo Transazionale 4. Allegati 4.1 A1: CRUSCGEFO Premessa Diagramma di Confine Funzioni di tipo Dati Funzioni di tipo Transazionale 4.2 A2: DWHSIARL (Sistema di Analisi e Reporting SIARL) Premessa Diagramma di Confine Funzioni di tipo Dati Funzioni di tipo Transazionale 4.3 A3: CDGA (DWH Controllo di Gestione delle Aziende Sanitarie Locali) Premessa Diagramma di Confine Funzioni di tipo Dati Funzioni di tipo Transazionale Pagina 41 di 64

42 2.8 Linee Guida per Applicazioni GIS (LG-GIS) Un sistema informativo geografico (in lingua inglese Geographic(al) Information System, abbreviato in GIS) è un sistema informativo computerizzato che permette l'acquisizione, la registrazione, l'analisi, la visualizzazione e la restituzione di informazioni derivanti da dati geografici (geo-referenziati). Per i sistemi GIS assumono rilevanza sia gli aspetti architetturali di distribuzione su layer diversi delle funzioni elaborative, sia gli elementi di misura delle GUI che dei sistemi Web. Per le linee guida di misurazione in FP di questo tipo di applicazioni si rimanda al documento [BIB19] LI-ALM-SISMET-FP-LG-GIS. Di seguito è riportato il sommario dei contenuti presenti nelle nella Linea Guida citata. Sommario 1. Introduzione 1.1 Finalità e ambito di applicazione del documento 1. Introduzione 1.1 inalità e ambito di applicazione del documento Ambito di applicazione 1.2 Acronimi e Termini 1.3 Riferimenti Documentali 2. L Infrastruttura per l Informazione Territoriale (IIT) 2.1 La Piattaforma REGIS Prodotti Suite ESRI FME GEONORM Architettura Applicativa della piattaforma REGIS 3. Modalità di realizzazione dei Prodotti GIS 4. Linee Guida P per l ambito GIS 4.1 Identificare il Confine 4.2 Identificare i Requisiti utente funzionali 4.3 Determinare Tipo, Scopo e Ambito del Conteggio 4.4 Contare le Funzioni di tipo Dati e di tipo Transazionale (BFC) Contare le funzioni di tipo Dati Contare le funzioni di tipo Transazionale 2.9 Linee Guida per Applicazioni Middleware (LG-MW) Esistono molte applicazioni costituite, completamente o in parte, da software middleware. La presenza di componenti middleware, interne alle funzionalità, risulta essere trasparente all utilizzatore finale delle stesse. Pagina 42 di 64

43 Le componenti middleware risultano, di conseguenza, invisibili nei conteggi in FP effettuati secondo le regole ufficiali del Manuale IFPUG. Tuttavia disporre di una misura dimensionale del software middleware sarebbe necessario soprattutto per effettuare stime di effort e misure di produttività. Il documento Hints to Counting Middleware Applications" by the New Environments Committee reperibile tra i white paper della parte privata del sito IFPUG, fornisce linee guida per ottenere una misura in FP del software middleware. Riguardo le modalità di effettuazione e l utilizzo dei risultati relativi ai conteggi in oggetto, si precisa quanto segue: se un applicazione si compone sia di funzionalità riconoscibili dall utente finale che di software middleware, per essa devono essere effettuati due separati conteggi in FP: uno per le funzionalità riconoscibili dall utente finale, l altro per il software middleware. L individuazione di specifici confini e relativi conteggi di sistemi di middleware, motori generalizzati e/o parametrici, è consentita solo previo accordo con l utente, su specifica commessa di implementazione. In caso contrario, l adozione di middleware particolare, motori generalizzati e software parametrici è considerata la soluzione tecnica adottata per rilasciare software applicativo distintamente misurato, e non oggetto di misurazione ulteriore ai fini della consuntivazione e dell aggiornamento della baseline in FP. Laddove una soluzione di tipo middleware, motore generalizzato o software parametrizzato, sia riconosciuta e misurata in quanto tale, non potrà la sua misura coesistere e sovrapporsi alla misura delle funzionalità utente ottenute, in uno o più ambiti/aree funzionali, dal punto di vista dell utente: le due misure sono mutualmente esclusive in ottica di misura standard IFPUG. Per le linee guida di misurazione in FP di questo tipo di applicazioni si rimanda al documento [BIB20] LI-ALM-SISMET-FP-LG-MIDDLEWARE. Di seguito è riportato il sommario dei contenuti presenti nella Linea Guida citata. Sommario 1. Introduzione 1.1 Finalità e ambito di applicazione del documento 1. Introduzione 1.1 Acronimi e Termini 1.2 Riferimenti Documentali 1.3 Ambito di applicazione del documento 1.4 Generalità sull Analisi dei unction Point per ASM Middleware 1.5 Linee Guida per l applicazione della procedura standard della misura funzionale Identificare i Requisiti utente funzionali Tipologie di Utenti Funzionalità condivise Determinare il Tipo di conteggio Pagina 43 di 64

44 1.5.5 Identificare Scopo e Ambito del conteggio 1.6 Identificazionedel Confine dell Applicazione Aspetti generali per l identificazione del confine Aspetti specifici per l identificazione del confine Ridefinizione dei confini Linee Guida su utenti, ambito e confini 1.7 Contare le Funzioni di tipo Dati 1.8 Contare le funzioni di tipo Transazionale 2. Esempi di applicazione 2.1 Il sistema delle porte di dominio del portale di servizi di LISPA 2.2 Componente di workflow Konix Cenni architetturali della componente Il motore delle regole: Konix Descrizione delle regole tramite file XML Commands-tag funzionali Libreria di utilità SoapUtil 2.3 Libreria crittografica PKI-MW Pagina 44 di 64

45 3 MOMENTI E MODI DI UTILIZZO DELLE MISURAZIONI 3.1 Modelli di produzione e punti di stima/misura funzionale In questa sezione si riportano i principali modelli di produzione ISO del software (detti anche cicli di vita) soltanto per evidenziare i relativi momenti canonici di misura e stima dei Function Point. Gli specifici modelli adottati per l Appalto sono descritti nell Allegato 1.4. L Allegato 1.4 è il documento di riferimento che descrive i modelli di cicli di vita che possono essere richiesti al Fornitore nell ambito di ogni singolo intervento oggetto dell Appalto Modello di produzione a cascata (waterfall) Figura 8: Modello di produzione a cascata Questo modello non pone particolari problemi per l applicazione dei metodi di misura funzionale come i Function Point. Pagina 45 di 64

46 Quando Alla fine dello Studio di Fattibilità (Requisiti Utente o del Sistema) Fase Ciclo di vita (*) Come Perché Esaurita la fase Definizione dei requisiti Stima FP In questa fase questo fornisce l informazione essenziale per la verifica della fattibilità e per la pianificazione del progetto. Precisione sul valore finale (**) Probabilmente intorno a ± 20 30% Alla fine del Disegno Logico (Software Architectural Design) Alla fine delle fasi di Realizzazione e Test Durante l intero ciclo di vita Dopo la fase analisi e definizione delle specifiche funzionali e di interfaccia Dopo la fase Realizzazione e test Misura FP Misura FP Stima FP oppure Misura FP (*) Vedasi allegato 1.4 Cicli di vita del Software, par. 1.1 e seguenti (**) I numeri illustrati sono solo indicativi Questo produce la misura iniziale della baseline contro la quale vengono tracciate tutte le successive Richieste di Cambiamento. La misura finale della dimensione funzionale è utilizzata come controllo per assicurarsi che quanto richiesto sia stato effettivamente realizzato. Per supportare la Gestione del Cambiamento (vedi capitolo corrispondente) Spesso meglio del ± 10% Spesso meglio del ± 5% dipende dal livello di dettaglio Tabella 1 - Determinazione della misura in FP nel modello a cascata Pagina 46 di 64

47 3.1.2 Modello di produzione incrementale Quando si adotta un modello del ciclo di vita incrementale (cfr. Figura 9), deve essere tenuto presente che la misura del software dell applicazione finale (fatta sul sistema dopo l ultimo incremento) non è, generalmente, uguale alla somma delle misure delle funzionalità individuali dei singoli incrementi immaginati come se fossero applicazioni distinte. Eventuali duplicazioni delle Componenti Funzionali di Base (BFC) determinerebbero una misura con valore più alto di quella che si avrebbe per il sistema nel suo insieme. INTEGRATION INTEGRATION Figura 9 : Modello di produzione incrementale Vi è anche l eventuale esistenza di funzionalità temporanee aggiunte nel mezzo del processo per compensare le incompletezze del sistema informativo durante i passi incrementali e cancellate prima della fine del progetto. Un approccio più corretto alla misura funzionale del software, in questo caso, è di considerare il primo incremento come la baseline principale dello sviluppo e gli incrementi successivi come se fossero manutenzioni funzionali evolutive della baseline. In questo modo la somma delle diverse misure parziali è da considerarsi come la dimensione dei prodotti (comunque non è la dimensione dell applicazione rilasciata) e la misurazione dell incremento singolo può essere utilizzato per il fabbisogno di pianificazione e controllo. È utile evidenziare che il costo delle fasi dei requisiti e architetturali è in realtà concentrato, per l intero sistema, all inizio del progetto mentre nell approccio suggerito può apparire come se fosse distribuito lungo l intero processo. Il primo incremento può apparire come meno produttivo del consuntivo ma il resto degli incrementi appariranno essere più produttivi dei consuntivi. Misurare il riuso (all interno di ogni incremento) è un fattore chiave per una equa transazione commerciale. Pagina 47 di 64

48 Pagina 48 di 64

49 Quando Alla fine dello Studio di Fattibilità (Requisiti Utente o del Sistema) Alla fine del Disegno Logico (Software Architectural Design) Prima e dopo ogni iterazione incrementale Alla fine della fase di integrazione dell ultimo incremento Durante l intero ciclo di vita Fase Ciclo di vita Come Perché Esaurita la fase Definizione dei requisiti Dopo la fase analisi e definizione delle specifiche funzionali e di interfaccia Dopo la fase Realizzazione e test Stima FP Stima FP oppure Misura FP Misura FP Misura FP Stima FP oppure Misura FP (*) Vedasi allegato 1.4 Cicli di vita del Software, par. 1.1 e seguenti (**) I numeri illustrati sono solo indicativi In questa fase fornisce i dati essenziali per testare la fattibilità e per la pianificazione del progetto. Questo produce la dimensione ipotetica per l intera applicazione (finale). Il primo incremento costituisce la Baseline su cui saranno effettuate le successive MEV funzionali incrementali Le misure della dimensione funzionale dell incremento sono utilizzate come controllo per assicurarsi che quanto richiesto per ogni incremento, sia stato effettivamente realizzato. La misura finale della dimensione funzionale è utilizzata come controllo per assicurarsi che quanto richiesto sia stato effettivamente realizzato. Per supportare la Gestione del cambiamento Precisione sul valore finale (**) Probabilment e intorno al ± 20 30% Spesso meglio del ± 20% Spesso meglio del ± 10% Spesso meglio del ± 5% Spesso meglio del ± 5% Tabella 2 - Determinazione della misura (FP) nel modello incrementale Pagina 49 di 64

50 3.1.3 Modello di produzione evolutivo Figura 10: Modello ISO In questo modello (cfr. Figura 10) può essere utilizzata una variante dell approccio per il modello incrementale. La differenza principale è che le stime delle fasi iniziali (requisiti utente, di sistema e architetturali) sono meno accurate, in termini di proiezioni per il sistema finale. Questo significa che la stima della misura funzionale per il sistema finale è più soggetta ad errori e dovrebbe essere definita contrattualmente in termini di valori minimo, più probabile e massimo. Per la stessa ragione anche le misure intermedie di miglioramento potrebbero non essere pianificate accuratamente su una baseline definita. Anche in questo caso occorre considerare con attenzione il fattore di riuso per ogni misurazione relativa ad iterazioni successive alla prima. Pagina 50 di 64

51 Quando Come Perché Alla fine dello Studio di Fattibilità (Primo Requisito Utente o di Sistema) Prima e dopo ogni iterazione evolutiva Alla fine della fase di integrazione dell ultima evoluzione Su richiesta durante l intero ciclo di vita Stima FP Misura FP Stima FP (*)I numeri illustrati sono solo indicativi Stima FP oppure Misura FP In questa fase fornisce dati essenziali per testare la fattibilità e per la pianificazione del progetto. La stima riguarda sia il sistema nella sua probabile veste finale a seguito di tutte le iterazioni evolutive che la stima di ogni singola iterazione evolutiva. Il primo passo costituisce la baseline su cui saranno effettuate le successive MEV funzionali evolutive. Le misure della dimensione funzionale dell iterazione sono utilizzate come controllo per assicurarsi che quanto richiesto per ogni passo, sia stato effettivamente realizzato. La misura finale della dimensione funzionale è utilizzata come controllo per assicurarsi che quanto richiesto sia stato effettivamente realizzato. Per supportare la Richiesta di Cambiamento per la Gestione dei Processi Precisione sul valore finale (*) Probabilmente intorno al ± 30 40% Spesso meglio del ± 10% Spesso meglio del ± 5% Spesso meglio del ± 5% Tabella 3 - Determinazione della dimensione (FP) nel modello evolutivo Pagina 51 di 64

52 4 VALORIZZAZIONE INTERVENTI DI SVILUPPO E MEV FUNZIONALE I Function Point sono utilizzabili per la valorizzazione economica degli interventi di Sviluppo e MEV funzionale nei casi di forma contrattuale a corpo e a misura di prodotto. Nel caso di forma contrattuale a misura di risorse, invece, i FP possono essere utilizzati al fine di stimare l'impegno di risorse per l'intervento ma la sua valorizzazione economica dipenderà dal costo unitario delle risorse e non dei FP. In ogni caso, la misura finale in FP dovrà essere consegnata dal fornitore per l'aggiornamento della baseline di prodotto. Nel seguito di questo capitolo saranno considerati solo i casi di forma contrattuale a corpo e a misura di prodotto. Punto di partenza per entrambe le modalità di valorizzazione economica (a corpo; a misura di prodotto) è la stima in Function Point dell entità dell intervento richiesto al fornitore (vedi 4.1 Stima dell entità dell intervento) secondo gli standard di riferimento adottati. Su di essa sono, successivamente, applicati tre elementi che incidono sul calcolo del corrispettivo attraverso la definizione della Misura Funzionale Contrattuale (MFC). Essi sono: - percentuale di Riuso, che diminuisce il numero dei FP contrattuali riconosciuti al Fornitore rispetto al valore funzionale puro dell'asm movimentata; - percentuale di Replica, che aumenta il numero dei FP contrattuali riconosciuti al fornitore rispetto al valore funzionale puro dell ASM movimentata; - consistenza delle varianti di requisiti in corso d opera autorizzate per l intervento, che aumentano il numero dei "FP movimentati" (Change Request CR). Naturalmente, nel caso di stima iniziale, il valore di FP collegabile alle CR è ignoto perchè ipotetico e non è, quindi, misurabile benché possa essere oggetto di stima in funzione della incertezza sui requisiti dovuta, ad esempio, a possibili ma non certe variazioni normative. Nel caso di forma contrattuale a corpo, le CR presunte potranno influenzare la stima economica iniziale ma saranno irrilevanti per la determinazione del corrispettivo consuntivo che è chiuso ad inizio intervento e corrisponde all'offerta iniziale. In caso di forma contrattuale a misura di prodotto, invece, le CR contribuiranno a determinare il corrispettivo finale consuntivo che, con le modalità di approvazione indicate nel capitolato tecnico, potrà essere diverso dal valore inizialmente previsto, se autorizzato. A valle del calcolo della MFC si applicano i seguenti correttivi che vanno ad agire sul prezzo unitario invece che sul size. - La percentuale dei pesi delle fasi/attività del modello di produzione affidate al fornitore, calcolata in funzione della somma dei pesi delle fasi/attività effettivamente affidate (vedi 4.3 Correzione sul PUN per Modello di Produzione (MP) - Il Fattore di Correzione Complessivo, valido a livello progetto, (vedi 4.4 Fattore di Correzione Complessivo sul PUN (FCC) Questi ultimi due correttivi di prezzo saranno calcolati solo a preventivo, in sede di attivazione dell'intervento, e non subiranno modifiche a consuntivo neppure nel caso di forma contrattuale a misura di prodotto. Pagina 52 di 64

53 4.1 Stima dell entità dell intervento LI effettua la stima dei progetti di sviluppo e/o MEV in FP applicando la metodologia Early&Quick Function Point o Simple Function Point e utilizzando lo strumento Sfera3 [BIB03]. 4.2 Misura Funzionale Contrattuale Al valore UFP (Unadjusted Function Point) determinato secondo le previste metodologie di misura e corrispondenti alle funzionalità richieste e rilasciate per l'uso all'utente, si applicano tre correttivi per giungere ad una MFC Valorizzazione del Riuso In un progetto di sviluppo o in una MEV funzionale è possibile che le nuove funzionalità da realizzare (quelle da modificare lo sono senz'altro) siano derivabili a partire da semilavorati software pre-esistenti in grado di configurare un riuso anche significativo. Nell ambito dell adeguamento della misura funzionale dovuto al riuso di software preesistenti, si definiscono due distinte fattispecie di riuso: il Riuso per incorporamento di servizi di altre ASM e il Riuso Generico. Tali fattispecie potrebbero presentarsi anche contemporaneamente; in tali casi occorrerà utilizzare una sola delle due modalità di adeguamento per riuso, selezionando quella che determina il maggior impatto di abbattimento Riuso per incorporamento di servizi di altra ASM L applicazione di tale fattore presuppone una catalogazione dei servizi comuni da parte di LI e una dichiarazione, da parte del Fornitore, dell utilizzo di servizi comuni nella documentazione di progetto sottoposta al dimensionamento. Nel caso delle funzioni di tipo transazionale il riuso nell ambito dei sistemi di LI è riferito all integrazione di servizi comuni e di componenti applicativi definiti e messi a disposizione dai framework aziendali. Per servizi comuni si intende l insieme delle classi architetturali, servizi di supporto o servizi condivisi che LI mette a disposizione al Fornitore e richiede espressamente che vengano usate per uniformare il comportamento del SW e per avere la stessa modalità di gestione di alcune tematiche che sono comuni alle applicazioni. Le modalità pratiche di incorporamento dei servizi comuni / componenti di architettura applicativa non sono rilevanti ai fini della computazione del risparmio per riuso. L'unica cosa rilevante è il riconoscimento della necessità di adottare componenti già sviluppati invece che di produrne di nuovi per quanto equivalenti. Esempi Esempio di servizi di supporto o condivisi relativi alle applicazioni nell ambito tecnologico Java : Servizio di Log permette di effettuare il log delle transazioni per tutte le applicazioni nello stesso modo. Il servizio di log centralizzato permette con una grande facilità per tutte le applicazioni che lo usano: o il monitoraggio della disponibilità dei servizi applicativi o la misurazione dei tempi di risposta Pagina 53 di 64

54 o facilità l analisi degli eventuali errori verificati nel funzionamento dell applicazione o consente la gestione in asincrono della scrittura dei log senza avere impatto sugli SLA dell applicazione Servizio di messaggistica e gestione degli errori. Questo servizio consente alle applicazioni di presentarsi all operatore/utente nello stesso modo. Servizio di archiviazione e recupero dei documenti firmati legalmente. È il servizio che permette a tutte le applicazioni che hanno questa esigenza di archiviare dei documenti firmati legalmente secondo quanto previsto dalla normativa. Tale servizio archivia in un archivio protetto sotto un dominio di sicurezza dedicato tutti i documenti firmati con la firma digitale e che sono soggetti a gestione secondo la normativa vigente. Ecc Esempio di servizi applicativi riusabili sono: Il Servizio di login con smartcard operatore Il servizio di identificazione del cittadino nell Anagrafe regionale Il servizio di identificazione del cittadino con la CRS Il servizio di firma digitale Il servizio di crypt/decrypt Riuso Generico Il Riuso Generico è una modalità di intercettazione di riuso di specifiche, codice documentazione e test case basata sul riconoscimento di "somiglianze funzionali" tra transazioni e archivi logici. L'assunto da cui parte questa modalità di riuso è che se due funzioni sono tra loro molto simili in termini di campi trattati e di logiche di elaborazione - entrambi elementi significativi e visibili per l'utente finale - le due funzioni avranno anche molti elementi tecnici in comune, in particolare la funzione (ad es. denominata "B") da realizzare per seconda potrà beneficiare del riutilizzo di semilavorati o prodotti finali predisposti per la prima (ad es. denominata "A"). La funzione "A" potrebbe essere censita nel sistema in misurazione oppure in altri sistemi accessibili. Un caso particolare di riuso generico consiste nella modifica o cancellazione di funzioni in cui possiamo assumere che la transazione "A" e "B" coincidono al fine di ricondurci allo stesso schema di trattamento. Di seguito sono rappresentati gli scenari tipici di applicazione del Riuso Generico. Scenario A Per ogni elemento di tipo transazionale (EI, EO, EQ in caso IFPUG; UGEP in caso E&QFP e SIFP) di nuova realizzazione (ADD) che riusi un elemento già presente o in fase di realizzazione nell ambito della stessa ASM, il coefficiente è pari a 0,5 (50% di abbattimento). Esempi di questa natura sono Report simili generati, in una stessa ASM, a partire da semilavorati già implementati nell ASM che si sta realizzando. Il coefficiente di Riuso generico si applica solo a elementi di tipo transazionale e non di tipo dati (come ILF, EIF o UGDG) se: Pagina 54 di 64

55 - la funzione transazionale B, rispetto alla funzione transazionale A di cui fa riuso, presenta un numero di campi logici uguali a quelli di A in misura superiore al 75%. Scenario B Per ogni elemento di tipo funzionale (EI, EO, EQ, ILF, EIF in caso IFPUG; UGEP, UGDG in caso E&QFP e SIFP) modificato (CHG) il coefficiente è sempre pari a 0,5 (50% di abbattimento). Scenario C Per ogni elemento di tipo funzionale (EI, EO, EQ, ILF, EIF in caso IFPUG; UGEP, UGDG in caso E&QFP e SIFP) cancellato (DEL), il coefficiente è pari a 0,3 (70% di abbattimento) Valorizzazione della Replica Una funzionalità replicata su più canali (mezzi di fruizione) darà, alla Misura Funzionale Contrattuale, un contributo aggiuntivo del 30% per ogni mezzo di fruizione ulteriore rispetto a quello base. Questo principio sarà applicato tutte le volte in cui la molteplicità di formato non sia ottenibile attraverso funzioni di sistema operativo o di ambiente già disponibili (ad es. stampa in pdf ottenuta da drivers commerciali disponibili nella installazione di windows) Ad esempio: un report stampato su carta replicato in modo identico come contenuto funzionale (DET, FTR, logica di trattamento) in un pdf ed in un formato di scambio xml conterà per 1,6 volte (1 + 0,3 + 0,3) il suo valore base in UFP. Ad esempio se si trattasse di un EQ semplice il valore in FP corrispondente al requisito multicanale sarebbe pari a 3 * 1,6 = 4,8 UFP. una transazione replicata in modo identico come contenuto funzionale (DET, FTR, logica di trattamento) sulle piattaforme tecnologiche web e cellulare conterà per 1,3 (1 + 0,3). Ad esempio se si trattasse di un EI medio il valore in FP corrispondente al requisito multicanale sarebbe pari a 4 * 1,3 = 5,2 UFP Misurazione delle varianti di requisiti funzionali in corso d opera Questa correzione si applica a consuntivo nel caso di forma contrattuale a misura di prodotto, mentre può essere usata a preventivo nel caso di forma contrattuale a corpo, per una stima della "instabilità dei requisiti" che possa essere considerata adeguata al fine di chiudere una proposta economica realistica. Il confronto tra i risultati delle misurazioni nel momento iniziale (preventivo, di norma ST1) e nel momento finale (consuntivo, ST3) [vedi Modalità di fornitura delle misure / stime] per un dato progetto software fornisce visibilità sull eventuale consistenza delle dimensioni funzionali dell applicazione in esame tra previsto e realizzato (scope creep), ma non è risolutivo rispetto al problema del cambiamento dei requisiti, in quanto prevede semplicemente di aggiornare la misura complessiva del sistema esaminato a completamento del progetto. Tale approccio è, in effetti, adeguato per una misurazione corretta del valore patrimoniale di un applicazione ma non è adeguato se, invece, si vogliono quantificare i cambiamenti Pagina 55 di 64

56 attuati nel corso del processo stesso di sviluppo o di manutenzione evolutiva dell applicazione. Un cambiamento dei requisiti in corso d opera richiesto da LI può avere un impatto funzionale e/o un impatto non funzionale. L impatto funzionale può comportare la creazione di nuove funzionalità logiche o strutture dati e/o può avere ripercussioni sul modo in cui altre funzionalità logiche o strutture dati devono essere trasformate o cancellate. In presenza di cambiamenti di requisiti funzionali autorizzati in corso d opera, la misura dei FP prodotti da un intervento di sviluppo o manutenzione evolutiva funzionale sarà effettuato con le seguenti modalità: Le funzionalità aggiunte (ADD), se presenti, dovranno essere sia quelle individuate originariamente che quelle introdotte successivamente con i cambiamenti dei requisiti accettati; Le funzionalità modificate (CHG), se presenti, dovranno essere sia quelle individuate originariamente che quelle introdotte successivamente con i cambiamenti dei requisiti accettati; Le funzionalità cancellate (DEL), se presenti, dovranno essere sia quelle individuate originariamente che quelle introdotte successivamente con i cambiamenti dei requisiti accettati; Una funzionalità classificata come ADD o CHG che sia modificata due o più volte attraverso cambiamenti in corso d opera verrà moltiplicata per un coefficiente 1,4; Una funzionalità aggiunta con un cambiamento dei requisiti (ADD) che sia poi cancellata successivamente con un nuovo cambiamento dei requisiti sarà abbattuta del 50% e sarà identificata per escluderla dall'aggiornamento del patrimonio. Una funzionalità cancellata (DEL) che venga ripristinata con un cambiamento dei requisiti successivo non sarà conteggiata. La figura seguente illustra le principali casistiche: Pagina 56 di 64

57 Figura 11 - Schema delle CR e delle casistiche di misura possibili Pagina 57 di 64