GUIMARÃES, Valéria Aparecida [1]
LARA, Alexander Prado [2]
PUTTINI, Ricardo Staciarini [3]
GUIMARÃES, Valéria Aparecida; LARA, Alexander Prado; PUTTINI, Ricardo Staciarini. Point Application Analysis eletto in progetti SOA. Rivista scientifica multidisciplinare Knowledge Center. Edizione 08. Anno 02, Vol. 01. pp 88-102, novembre 2017. ISSN:2448-0959
Sommario
Stimare le dimensioni di un software per lo sviluppo è essenziale per ottenere una stima affidabile dei costi e di tempo. Una delle tecniche di misurazione più utilizzati e documentato per ottenere la dimensione di un software è la funzione Point Analysis (FPA), che, però, ha la sua applicabilità ai progetti che utilizzano l'approccio alla Service Oriented Architecture (SOA) spesso messo in discussione. Questo documento presenta il risultato dell'applicazione della APF su un sistema sviluppato interamente utilizzando l'approccio SOA, che ha permesso ulteriore confronto delle stime prodotte da APF con fatica, tempo e costi effettivi del progetto.
Parole chiave: Software di stima, Misuratore Software, APF, SOA.
1. Introduzione
Stimare le dimensioni di un software da sviluppare è essenziale per ottenere una stima affidabile dei costi e dei tempi (Wilkie, 2011), ma funziona correttamente questo tipo di stima è nominato dalla letteratura come una delle più grandi sfide affrontate dagli amministratori di questa zona (Pressman 2011; Wilkie, 2011; KAUR, 2016). Ciò è dimostrato, ad esempio, Roetzheim (2000), che ha guidato per 18 anni, approfondite ricerche, che ha concluso che le principali cause di fallimento dei progetti software sono legati a stime dei costi e dei poveri calendario di attuazione, e non per problemi tecnici, team di politica o di sviluppo.
Anche se non è una scienza esatta, perché l'influenza delle variabili umane, tecniche, ambientali e politiche (SOARES, 2013), le tecniche di misurazione (e metriche) software in grado di contribuire in modo significativo alla generazione di stime più assertivo, che diminuisce la discrepanza tra quanto previsto e quanto è stato realizzato e per rilevare le tendenze e anticipare problemi fornendo un controllo dei costi più efficiente, riducendo il rischio, migliorando la qualità e garantire che gli obiettivi aziendali vengono raggiunti (FLORAC 1997 ; Pressman, 2008; Tichenor, 2013; SOARES, 2013).
Una delle tecniche di misurazione più utilizzati e documentato per ottenere la dimensione funzionale di un software è APF (l'acronimo in inglese FPA Function Point Analysis) (IFPUG, 2010; Wilkie, 2011; SOARES, 2013). Questo metodo è stato pubblicato a metà degli anni '70 da Allan Albrecht (ALBRECHT, 1984) e migliorato dalla International Function Point Users Group (IFPUG), ed è già ben consolidata e ampiamente usato in tutto il mondo (IFPUG, 2010; Calazans, 2011; SISP, 2015). Il metodo utilizza punti funzione (PF) come unità di misura (IFPUG, 2010).
Nonostante il consolidamento di APF come tecnica per il dimensionamento della dimensione funzionale del software (Lindskoog, 2009; IFPUG, 2010) e la continua lo sforzo per il miglioramento e l'evoluzione del metodo, ci sono scenari in cui la loro adozione non è diretto. progetti software che seguono approccio orientato architecture (SOA) – Architettura per lo sviluppo del software il cui principio fondamentale è quello di costruire servizi riutilizzabili e interoperabili (ERL 2005), fa parte dell'elenco delle impostazioni in cui viene messa in discussione l'applicazione della APF .
Discussioni circa l'applicabilità del metodo per progetti SOA sono stati costanti e molte sfide restano da superare per l'adozione. (Gencel, 2008; Lindskoog, 2009; Gomes, 2012). Questa difficoltà deriva da diversi fattori, in cui si evidenziano il fatto che, in progetti SOA, molte caratteristiche sono progettati per il riutilizzo, che lo rende comune per l'ambito di un progetto rompere la portata funzionale dell'applicazione in fase di sviluppo ( ERL, 2005). Inoltre, SOA, sistemi complessi hanno bisogno di essere suddiviso in servizi e gran parte dello sforzo di analisi e di progettazione è legata proprio al processo di decomposizione e il successivo ripristino dei servizi. Questo processo richiede l'esplicita richiesta di metodi e principi per realizzare accoppiamento lasco, capacità composizione, la standardizzazione e la mediazione transazione, tra gli altri, che non sono presenti nello sviluppo del software convenzionale (ERL 2008). Così, metriche e benchmark di stima sforzo utilizzati per lo sviluppo tradizionali non possono essere applicati direttamente in progetti SOA (Lindskoog, 2009; Farrag, 2015).
In questo contesto, l'articolo presenta i risultati di uno studio di caso che coinvolgono la misura, attraverso l'APF, un software completamente sviluppato utilizzando l'approccio SOA per dopo confrontarli con lo sforzo, tempo e costi effettivi dispensati in esecuzione software. Il lavoro è stato sviluppato a partire dai dati raccolti da un vero e proprio progetto, che gli autori hanno avuto accesso completo.
Questo articolo è organizzato come segue: la sezione 2 riassume i concetti di base relativi alla Analisi PF e SOA, così come importanti lavori scientifici che hanno guidato la proposta. La sezione 3 presenta la metodologia di lavoro adottata, mentre la sezione 4 presenta i risultati ottenuti. Infine, la sezione 5 riporta le principali conclusioni e commenti finali.
2. concetti
2.1 Function Point Analysis (FPA)
Come già accennato, l'APF è una tecnica per misurare software o progetto di sviluppo / manutenzione del software gestito dalla International Function Point Users Group (IFPUG) e che mira ad ottenere la dimensione "Function Points funzionali "(PF), considerando il punto dell'utente di vista (IFPUG, 2010). L'IFPUG pubblicare e tenere aggiornato Manuale Practices Conteggio (CPM – Manuale Pratiche conteggio), che contiene le regole e il processo da seguire per garantire risultati più coerenti nell'applicazione della APF (IFPUG, 2010).
Le organizzazioni possono applicare questo standard internazionale per misurare le dimensioni di un software per: (i) per stimare sforzo, costo e il tempo necessario per lo sviluppo, il mantenimento e il miglioramento di software; (Ii) fornire supporto all'analisi di qualità e produttività; (Iii) fornire un fattore di normalizzazione per il confronto di software (IFPUG, 2010). Il suo utilizzo ha molti benefici che includono: le regole di conteggio obiettivo, l'indipendenza della soluzione e la programmazione linguaggio tecnologico e la possibilità di stimare generazione già nelle prime fasi del ciclo di vita del software (SISP, 2015).
L'applicazione del metodo prevede l'esecuzione delle seguenti operazioni, dettagliate nella CPM (2010): (i) avere la documentazione disponibile; (Ii) individuare lo scopo e il tipo di punteggio, determinare la portata del conteggio e il confine della domanda; (Iii) misura delle funzioni di dati, che sono i requisiti utente funzionali relativi al recupero di stoccaggio e / o dati e sono classificati in file logico interno (ALI) – gruppi di dati logici trattenute all'interno del confine dell'applicazione, e file di interfaccia esterna (IEA) – si fa riferimento solo dall'applicazione oggetto di valutazione; (Iv) misurare le funzioni di transazione, che sono funzioni fornite all'utente per l'elaborazione dei dati da un'applicazione e sono classificati in (a) Ingressi esterni (EE) – responsabile per l'elaborazione dei dati o informazioni di controllo che hanno origine all'esterno della applicazione del bordo; (B) ambulatoriali (CE) – responsabile per l'invio di dati o informazioni di controllo che vengono fuori dell'applicazione del confine; (C) Uscite esterne (SE) – responsabile per l'invio di dati o informazioni di controllo che vengono dall'applicazione del confine, compresi logica di elaborazione aggiuntivo, oltre al identificato in un ambulatoriale; (V) calcolando la dimensione funzionale; (Vi) di documenti e segnalato il conteggio. Cioè, dalla documentazione di progetto o software e sotto il punto di vista (requisiti funzionali) per l'utente derivano PF in termini di funzionalità offerte e dei dati coinvolti. Avendo la quantità di PF e sulla base di modelli come le stime semplificato Girl (Vazquez 2012) o il modello COCOMO II (Boehm, 2009), sono derivati da sforzo, tempo e costo di un progetto.
2.2 Service Oriented Architecture (SOA)
SOA è un approccio architetturale per lo sviluppo del software il cui principio fondamentale è quello di costruire servizi riutilizzabili e interoperabili (ERL 2005). Secondo ERL (2005), il servizio è l'unità fondamentale del servizio orientato logica (logica della soluzione), cioè, le caratteristiche applicative sono disponibili in forma di servizio.
Una logica è considerato quando alcuni service-oriented principi, noti come principi SOA sono applicati in una significativa estensione della soluzione (ERL 2005). ERL secondo (2008) sono otto di questi principi: (i) contratto di normalizzazione; (II) servizi loosely coupled; (III) estrazione servizio; (IV) capacità di servizio riutilizzo; (V) servizio autonomia; (VI) stato di servizio di indipendenza; (VII) la visibilità del servizio (scoperta capacità); e (VIII) capacità di servizio della composizione.
SOA cerca, attraverso l'applicazione dei principi: aumentare l'allineamento tra business e IT; federalizzazione (l'accesso ai servizi è standardizzato al fine di unificare la visione dei suoi clienti); il fornitore diversità; il ritorno sugli investimenti (ROI); e agilità organizzativa; e di ridurre l'onere di IT per l'organizzazione (ERL 2008). Così, SOA consente di creare applicazioni che rispondere più rapidamente alle esigenze di business, in quanto i servizi sono costruiti in modo standardizzato, essendo in grado di interoperare (comunicare) con l'altro in un modo standard e trasparente, indipendentemente dalla piattaforma, fornitori o tecnologie cui sono stati costruiti in o correre.
Anche se è stato intorno per qualche tempo, la SOA ha guadagnato la protuberanza solo dalla metà degli anni 2000 (ERL 2005). Secondo una recente indagine (WinterGreen, 2014), il mercato SOA è in rapida crescita. Il rapporto di ricerca indica che il mercato SOA ha raggiunto US $ 5.7 miliardi di dollari nel 2013 e potrebbe raggiungere US $ 16,4 miliardi entro il 2020. Secondo l'indagine, questa crescita significativa è dovuta al fatto che SOA offrono processi automatici più efficienti e fornire IT la possibilità di investire più del bilancio sulla crescita del business. Inoltre, con soluzioni software disaccoppiati (indipendenti), servizi SOA possono essere riutilizzati in modo efficiente.
3. Presentazione della metodologia di lavoro adottato
La misurazione attraverso l'uso di PF per ottenere la dimensione funzionale di REFERENCE DESIGN, eseguita applicando le regole di conteggio stabilite CPM (IFPUG, 2010), volte ad identificare, attraverso un'analisi comparativa, quale sarebbe il costo , tempo e sforzi reali erogato nella realizzazione del progetto e dei risultati ottenuti dall'applicazione di APF. Così, è stato possibile valutare se l'utilizzo del APF sarebbe adatto per la misura di progetto (sviluppato sotto l'approccio SOA).
Selezione 3.1 Progetto
La scelta del disegno in uso si è verificato naturalmente, in quanto la società in cui gli autori di lavoro è stata incaricata di strutturare l'adozione della SOA da un'organizzazione per motivi di riservatezza delle informazioni, sarà nominato contraente nel corso di questo articolo .La progetto mirava, in generale, la struttura di adozione della SOA da parte del contraente. attività sono state sviluppate per la strutturazione, sviluppo, attuazione e controllo del programma di adozione SOA attraverso l'esecuzione di attività che includeva, entres altro, creando un sistema sviluppato interamente utilizzando l'approccio SOA e per essere chiamati REFERENCE DESIGN over questo articolo.
3.2 Misura Reference Design
misurazione PROGETTAZIONE DI RIFERIMENTO attraverso l'uso di PF è stata eseguita dopo una completa attuazione e la diffusione del software. Così, abbiamo deciso di effettuare un conteggio dettagliato, che considera anche la quantità di funzioni transazionali, la complessità funzionale (bassa, media, alta) di ciascuna funzione singolarmente. Essi sono stati utilizzati come ingressi di misura, oltre a manufatti prodotti durante lo sviluppo del progetto, l'accesso al software in esecuzione. Contiamo anche con la perizia dei membri del team di progetto.
Sforzo 3.3 Estimating Software Progetto
Diversi modelli di stima lo sforzo di progetti software, sulla base di PF, sono attualmente disponibili, e le stime semplificata del modello (Vazquez (2012)) e modello COCOMO II (Boehm, 2009) il più utilizzato (SISP, 2015). In questo studio, abbiamo utilizzato le stime modello semplificato, lo stesso utilizzato dalla SISP (2015).
4. risultati sperimentali
4.1 Reference Design
Questa sezione presenta i risultati effettivi ottenuti dall'attuazione del Progetto di riferimento, che include informazioni sui costi del team di progetto, fatica, tempo e di progetto.
4.1.1 Project Team
Tabella 1 indica il personale assegnato allo sviluppo della soluzione. Essi presentano le informazioni sul numero di persone che ha partecipato al progetto per tipo di risorsa / ruolo, il ruolo della risorsa assegnata alla squadra con i loro rispettivi porcentam del particação e la relativa dedica, in termini percentuali, di un / ruolo specifico delle risorse nel corso l'intero progetto.
4.1.2 Il tempo e sforzo Raggiunto
REFERENCE DESIGN durato sei mesi e lo sforzo reale è stata misurata registrando ore in JIRA, uno strumento che consente il monitoraggio dei progetti attraverso attività di registrazione e reporting. La tabella 2 mostra lo sforzo erogato nel rendere ogni fase di sviluppo del progetto.
Tabella 2: sforzo Reference Design fatto
| fase progettuale | orario |
| Business Modeling and Analysis | 1076 |
| implementazione | 826 |
| Tesi e Implementazione | 268 |
| Ore totali | 2170 |
4.1.3 Costo Held
Il costo è stato calcolato ore all'unità UST conversione (Technical Services), che è l'unità medico utilizzato per quantificare il lavoro. Cioè, la quantità di ore-uomo viene convertito in UST come definizione contrattuale per ricavare i costi. Il calcolo dei UST tiene conto della complessità dell'attività svolta (bassa, media e alta). Tabella 3 mostra il risultato della conversione di ore / UST per ogni fase del progetto.
Tabella 3: Costo progetto di riferimento Diretto
| fase progettuale | orario | UST |
| Modellazione e analisi | 1076 | 1765 |
| implementazione | 826 | 894 |
| Tesi e Implementazione | 268 | 304 |
| Ore totali | 2170 | 2963 |
Considerando la quantità contratta UST di R $ 247,50, il progetto ha avuto un costo complessivo di R $ 733,342.50
4.1.4 Risultati generali
La Tabella 4 mostra la sintesi di sforzo, tempo e costi erogato nel rendere il progetto di riferimento, che servono come base per un'analisi comparativa al risultato della misurazione della dimensione funzionale del software tramite mp uso.
Tabella 4: Risulto totale
| PROGETTAZIONE DI RIFERIMENTO | |
| Sforzo (ore): | 2170 |
| Termine (mesi): | 6 |
| Costo (R $): | R $ 733,342.50 |
4.2 Misurare la dimensione del Funzionale – IFPUG
La misura funzionale del software dimensione utilizzando FP considerata l'applicazione nel suo complesso, con la vista funzionale punto di vista dell'utente, come raccomandato dalla norma APF IFPUG (IFPUG, 2010). Tabella 5 mostra l'obiettivo (obiettivo o scopo di misurare) ed ambito di misurazione (insieme o sottoinsieme di applicazioni che vengono misurate). Tabella 6 mostra brevemente il risultato del conteggio corrispondente al valore della dimensione funzionale del progetto di riferimento. Il personale sforzo periodo di bypass e il costo è stato determinato sulla base di stime modello semplificato, che sono presentati nella tabella 7.
Tabella 5: Scenario funzionale PROGETTAZIONE riferimento di misura
| scenario funzionale | |||
| Scopo della misura | progetto di riferimento misurazione della dimensione funzionale (APF IFPUG) sviluppato come il contraente del programma di adozione della SOA. | ||
| misura Scope | Applicazioni Reference Design | ||
Tecnica Conteggio: determina se il conteggio è indicativo stimato o rotto. Il conteggio indicativo è basato solo sulle informazioni relative alle funzioni di dati, vale a dire dal numero di file logici (Alis e SIA). Il conteggio stimato ritiene, alla quantità di funzioni di dati, informazioni sulle funzioni di transazione in modo che in modo che le esigenze degli utenti devono essere più dettagliata. Come per i conteggi dettagliati, più la quantità di funzioni transazionali, è necessario determinare la complessità funzionale (bassa, media, alta) di ciascuna funzione singolarmente (nesma, 2015).
Tipo Count: sono tre possibili tipi di conteggio: (i) lo sviluppo: Come la funzionalità fornita agli utenti che considerano la prima installazione del software. (Ii) il miglioramento / Manutenzione: Modifiche correlate, è, ha aggiunto, modificato o eliminato, per una funzionalità software esistente. (Iii) Applicazione: misurazione della funzionalità che un'applicazione offre all'utente. Un'applicazione è insieme coerente di procedure e dati automatizzate, che mira a sostenere un obiettivo aziendale e costituito da uno o più componenti, moduli o sottosistemi (IFPUG, 2010).
Dimensione del progetto funzionale: si riferisce al valore della dimensione funzionale del kit di sviluppo.
Produttività Notte (h): Si riferisce al numero di ore produttive su una persona. Questo lavoro è stato considerato come 6 ore / giorno, come raccomandato dal (SISP, 2015).
Productivity Index (ore / FP): si riferisce alla quantità di tempo dedicato alla produzione di 1 PF. Determinazione del valore dell'indice di produttività dipende da diversi fattori, che possono includere, tra gli altri, la dimensione piattaforma tecnologica, la sicurezza, le prestazioni, usabilità e di progetto. Ogni organizzazione dovrebbe avere un proprio tavolo di produttività, considerando i dati storici da progetti precedenti.
Sforzo (persona / ora): Si riferisce al numero di ore da erogare nella consegna progetto, o la consegna di una certa dimensione funzionale. Si è calcolato sulla base del design funzionale e la dimensione del l'indice di produttività (dimensione (PF) x Indice Produttività (HH / FP)).
Ambiente: Si riferisce l'esponente per essere utilizzato nella formula per determinare il termine consigliato. La tabella 1 mostra le opzioni disponibili. Questo è stato selezionato il "OO Sistema – Object Oriented System", che più si avvicina alle caratteristiche di un progetto SOA.
Altro periodo: Si è calcolato secondo la formula Capers Jones[Jones,2007].
Mensile di carico di lavoro (ore): Si riferisce al numero di ore di lavoro lavorate per persona in mese.
Squadra: Si riferisce alla quantità di risorse necessarie per lo sviluppo del progetto e deve essere considerato l'assegnazione percentuale di risorse al progetto. In questo risultato, il team di progettazione 6.2 caratteristiche potrebbe corrispondere, per esempio, un gruppo di 12 persone con 50% di allocazione e un capo progetto con il 20% assegnato al progetto.
Personale informati: Si riferisce alla squadra che ha lavorato in modo efficace allo sviluppo del progetto. Ha lo scopo di sostenere le altre simulazioni di fatica e tempo e la distribuzione delle risorse nella squadra in base alla dedizione di ciascuno al progetto.
Altre simulazioni stime: altre simulazioni stime sono stati generati in base alla squadra informata e considerando la riduzione termine. Il valore del punto funzione utilizzata è stata definita sulla base di riferimenti storici della società contraente. costi di progetto sono stati calcolati senza considerare il periodo di riduzione e considerando il periodo di riduzione.
5. conclusioni
5.1 Analisi critica della proposta
Dall'analisi dei risultati ottenuti dall'applicazione di APF e riferimento esecuzione disegno si è concluso che il costo effettivo della progettazione SOA e ottenuti dalla misurazione da PQ ha valori significativamente differenti (costo effettivo: R $ 733.342 50 e la stima dei costi: R $ 349,600.00). C'è stata anche una differenza significativa tra lo sforzo necessario per lo sviluppo del progetto e lo sforzo reale (vero sforzo: ore 2170 e fatica stimata: 6992 ore). Il costo effettivo e stimato (costo effettivo: R $ 733,342.50 contro costo stimato: R $ 593,620.00) ha mostrato solo valori relativamente vicini nello stimare metodo del costo di bypass considera la riduzione dei tempi di sviluppo del progetto in relazione al tipo raccomandato idealmente ( in tempo reale: 6 mesi in funzione del tempo consigliato: 7.71 mesi).
Così, si è concluso che l'APF ha risultati molto diversi rispetto ai risultati effettivi, e quindi non adatto per la misurazione di progetti SOA. Soma è anche il fatto che l'APF non conta nel suo punteggio i requisiti non funzionali, che sono comuni in molte applicazioni SOA, come ad esempio i servizi di riutilizzo e di composizione. Oltre a non consentire la soluzione di misura frammentato, cioè la misura individualmente per servizio. Questa è una caratteristica molto desiderata quando si tratta di misurare progetti SOA, che possono comportare la costruzione di una soluzione completa o solo un sottoinsieme di questi servizi, e può anche comportare la costruzione di un solo servizio specifico.
5.2 Limitazioni e lavoro futuro
Il lavoro è stato limitato a misurare solo un progetto. Inoltre, ha usato un solo metodo per derivare le stime di sforzi, costi e tempi. In futuro lavoro, l'applicazione di APF in una maggiore diversità di progetti e l'uso di altri metodi di stima può trarre vantaggio, in quanto fornirà una maggiore affidabilità nelle conclusioni. Sarà anche di grande importanza per proporre un metodo specifico per misurare le dimensioni di software SOA, che cerca di seguire i concetti puri di IFPUG rispetto alla misura funzionale, ma anche considerare la necessità di soluzione di misura frammentaria, nonché la misura di requisiti non funzionali.
riferimenti
ALBRECHT, IBM J. Allan Il CIS e Guideline 313. AD / M Produttività 1984.
Boehm, B.W. Software Stima dei costi con COCOMO II. Prentice Hall, New Jersey, 2009.
Calazans Angelica; LISBONA Irina; OLIVEIRA Marcelo. Valutazione dei sistemi generali Caratteristiche di analisi Function Point – APF applicando le GQM – Goal, domande, Metriche. VII Simposio Internazionale sul Software Process Improvement. Sao Paulo. Novembre 2011.
ERL, Thomas. Service-Oriented Architecture: Concepts, tecnologia e design. Crawfordsville: Prentice Hall PTR, Aug. Del 2005.
ERL, Thomas. SOA Principi di Service Design. Prentice Hall, 2008.
Farrag, Esraa A.; Moawad Ramadan; IMAM, Ibrahim F. Un approccio per lo sforzo stima della Service Oriented Architecture (SOA) Progetti. JSW, v. 11, n. 1, p. 44-63, 2016.
Florac, William A.; PARK, Robert E.; CARLETON, Anita D. software di misura pratico: di misura per la gestione dei processi e miglioramento. Carnegie Mellon UNIV PITTSBURGH PA-SOFTWARE ENGINEERING INST 1997.
Gencel, Cigdem; DEMIRORS, Onur. misurazione della dimensione funzionale rivisitato. Le transazioni ACM sulla Ingegneria del Software e metodologia (TOSEM) v. 17, n. 3, p. 15, 2008.
GOMES, Yuri Marx Pereira. dimensione funzionale, lo sforzo e il costo dei progetti SOA con punti funzione. n. LXVIII, novembre 2012.
IFPUG – International Point UTENTE FUNZIONE GROUP. Pratiche manuali Punti funzione count. Versione 4.3.1, gennaio 2010.
IFPUG – International Point UTENTE FUNZIONE GROUP. Manuale di pratiche di valutazione. Versione 2.3, maggio 2015.
JONES, I costi C. valutando software. Seconda Edizione, McGraw Hill, 2007.
Kaur, Prabhjot. Una rassegna di software metrica e di misurazione. International Journal di applicazioni informatiche e Information Technology, vol. 9, n. 2, p. 187, 2016.
Jeff Lindskoog. L'applicazione di Function Point ambiente all'interno del SOA. EDS, una società HP. St. E. Hoffer 1401 Kokomo, IN 46902. Stati Uniti d'America. Settembre 2009.
Nesma – Olanda Funzione Punti Utenti. Inizio Function Point Analysis. Luglio 2015.
Pressman, Roger S. Ingegneria del Software: un approccio professionale. 7 ° edizione. Ed: McGraw Hill, 2011.
ROETZHEIM, William H. stima dei costi del software. SVILUPPO SOFTWARE-SAN FRANCISCO, v. 8, n. 10, p. 66-68, 2000.
SISP. Metriche sceneggiatura Software SISP: versione 2.1, Ministero della Pianificazione, Bilancio e Gestione. Segretario della Logistica e Information Technology. Brasilia: MP 2015.
SOARES DOS REIS, Julio Cesar; BARBOSA, Marcelo Werneck. PROPOSTA DI PREVENTIVO PER REQUISITI TECNICI. Ufficiale di Sistemi e Informatica-RSC, v. 3, n. 1, 2013.
Charley Tichenor, SNAP-Case Study 2 (VSN 1. 0): Come utilizzare Function Point e SNAP per migliorare il software acquisizioni contratto. IFPUG. Giugno 2014.
VAZQUEZ, Carlos E.; SIMÕES, Guilherme Siqueira; ALBERT, Renato Machado. Analisi Function Point: misura, stima e la gestione dei progetti software. 12 ° edizione, Editor Erica Ltda, San Paolo 2012.
Wilkie George F. et al. Il valore di dimensionamento software. Tecnologie dell'informazione e del software, vol. 53, n. 11, p. 1236-1249, 2011.
[1] Laurea in Ingegneria Elettrica – UNB
[2] Dottore in Ingegneria e gestione della conoscenza
[3] Dottorato di Ricerca in Ingegneria Elettrica presso l’Università di Brasilia (2004), dove insegna presso il Dipartimento di Ingegneria Elettrica dal 1998. Ha stage di dottorato presso L’Ecole Supérieure d’Electricité (Supélec), Rennes / Francia (2001/2002) e la fase di post Dottorato di ricerca presso l’Istituto svedese per l’informatica (SICS), Stoccolma / Svezia (2011). È stato coordinatore dell’Inform Technology Centre (NTI) di UnB (2006-2008) e Direttore del Computing Center (CPD) di UnB (2007-2008). Opera in progetti di ricerca, sviluppo tecnologico e l’innovazione, e la consulenza, in collaborazione con diverse aziende ed enti governativi in questioni relative alle TIC, dove opera nella definizione della strategia, modello di governance, la tecnologia di prospezione e di trasferimento tecnologico. Le sue attuali aree di interesse includono: cloud computing, architettura orientata ai servizi, gestione dei processi aziendali, sistemi distribuiti e applicazioni di tecnologia dell’informazione negli ambienti governativi.
