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. Analyse des points de demande de service dans les projets SOA. Magazine scientifique multidisciplinaire du Centre du savoir. Numéro 08. Année 02, vol. 01. pp 88-102, Novembre 2017. ISSN:2448-0959
Résumé
Estimer la taille d'un logiciel de développement est essentiel d'obtenir une estimation fiable du coût et du temps. L'un des plus utilisé des techniques de mesure et documenté pour obtenir la taille d'un logiciel est la fonction Analyse des points (FPA), qui, cependant, a son applicabilité aux projets qui utilisent l'approche de l'architecture orientée services (SOA) souvent remis en question. Cet article présente le résultat de l'application du CSA sur un système entièrement développé en utilisant l'approche SOA, ce qui a permis une comparaison plus approfondie des estimations produites par l'APF avec un effort, le temps et les coûts réels du projet.
Mots-clés: Logiciel d'estimation, de contrôle des logiciels, du CSA, SOA.
1. Introduction
Estimer la taille d'un logiciel à développer est essentiel d'obtenir une estimation fiable du coût et du temps (Wilkie, 2011), mais bien effectuer ce type d'estimation est nommé par la littérature comme l'un des plus grands défis auxquels sont confrontés les gestionnaires de cette région (Pressman 2011, Wilkie, 2011, Kaur, 2016). Ceci est illustré, par exemple, Roetzheim (2000), qui a dirigé pendant 18 ans, des recherches approfondies, qui ont conclu que les principales causes de l'échec des projets de logiciels sont liés aux mauvaises estimations des coûts et le calendrier de mise en œuvre, et non à des problèmes techniques, l'équipe politique ou de développement.
Bien que pas une science exacte, car l'influence des variables humaines, techniques, environnementales et politiques (SOARES, 2013), les techniques de mesure (et des mesures) logiciel peut contribuer de manière significative à la production d'estimations plus affirmées, qui diminue l'écart entre ce qui a été estimé et ce qui a été accompli et de détecter les tendances et anticiper les problèmes en fournissant un contrôle des coûts plus efficace, ce qui réduit le risque, l'amélioration de la qualité et de veiller à ce que les objectifs commerciaux sont atteints (FLORAC 1997 ; Pressman, 2008, Tichenor 2013, SOARES, 2013).
L'un des plus utilisé des techniques de mesure et documenté pour obtenir la taille fonctionnelle d'un logiciel est APF (l'acronyme en anglais FPA Fonction point Analyse) (IFPUG, 2010, Wilkie, 2011, SOARES, 2013). Cette méthode a été publié au milieu des années 70 par Allan Albrecht (ALBRECHT, 1984) et amélioré par les utilisateurs de Point International Fonction Groupe (IFPUG), et est déjà bien établi et largement utilisé dans le monde entier (IFPUG, 2010; Calazans, 2011, SISP, 2015). Le procédé utilise des points de fonction (FP) comme une unité de mesure (IFPUG, 2010).
En dépit de la consolidation de l'APF comme technique pour le dimensionnement de la taille fonctionnelle des logiciels (Lindskoog 2009, IFPUG, 2010) et l'effort continu d'amélioration et de l'évolution de la méthode, il existe des scénarios où leur adoption est pas direct. projets logiciels qui approche architecture orientée suivi (SOA) – architecture pour le développement de logiciels dont le principe fondamental est de construire des services réutilisables et interopérables (ERL 2005), fait partie de la liste des établissements où l'application du CSA est contestée .
Les discussions sur l'applicabilité de la méthode pour les projets SOA ont été constants et de nombreux défis restent à surmonter pour adoption. (Gençel, 2008; Lindskoog 2009, Gomes, 2012). Cette difficulté découle de plusieurs facteurs, dont nous mettons en évidence le fait que, dans les projets de SOA, de nombreuses fonctionnalités sont conçus pour être réutilisés, ce qui en fait commun pour la portée d'un projet briser le périmètre fonctionnel de l'application en cours d'élaboration ( ERL, 2005). En outre, la SOA, les systèmes complexes doivent être ventilés dans les services et une grande partie de l'effort d'analyse et de conception est précisément liée au processus de décomposition et la restauration ultérieure des services. Ce processus nécessite l'application explicite des méthodes et des principes pour réaliser un couplage lâche, la capacité de composition, la normalisation et la médiation des transactions, entre autres, qui ne sont pas présents dans le développement de logiciels classiques (ERL 2008). Ainsi, des mesures et des critères d'estimation de l'effort utilisés pour le développement traditionnel ne peuvent pas être appliqués directement dans des projets SOA (Lindskoog, 2009; Farrag, 2015).
Dans ce contexte, cet article présente les résultats d'une étude de cas portant sur la mesure, par l'intermédiaire du CSA, un logiciel entièrement développé en utilisant l'approche SOA pour une comparaison ultérieure avec l'effort, le temps et les coûts réels distribués dans l'exécution du logiciel. Le travail a été élaboré à partir des données recueillies à partir d'un projet réel, que les auteurs avaient accès.
Cet article est organisé comme suit: la section 2 résume les concepts de base liés à la PF analyse et SOA, ainsi que des travaux scientifiques majeurs qui ont guidé la proposition. La section 3 présente la méthodologie de travail adoptée, tandis que la section 4 présente les résultats obtenus. Enfin, la section 5 apporte les principales conclusions et observations finales.
2. concepts
2.1 Analyse des fonctions Point (FPA)
Comme déjà mentionné, le CSA est une technique de mesure de logiciel de logiciel ou de développement / maintenance du projet tenu par l'utilisateur Point International Fonction Groupe (IFPUG) et qui vise à obtenir la taille fonctionnelle « Points de fonction « (PF), compte tenu du point de vue de l'utilisateur (IFPUG, 2010). Le IFPUG publier et tenir à jour Manuel des pratiques de comptage (CPM – comptage manuel des pratiques), qui contient les règles et le processus à suivre pour obtenir des résultats plus cohérents dans l'application du CSA (IFPUG, 2010).
Les organisations peuvent appliquer cette norme internationale pour mesurer la taille d'un logiciel afin de: (i) pour estimer l'effort, le coût et le temps requis pour le développement, l'entretien et l'amélioration des logiciels; (Ii) fournir un appui à l'analyse de la qualité et de la productivité; (Iii) fournir un facteur de normalisation pour comparer les logiciels (IFPUG, 2010). Son utilisation présente de nombreux avantages qui comprennent: les règles de comptage objectif, l'indépendance de la solution technologique et langage de programmation et la possibilité d'estimer la génération déjà dans les premiers stades du cycle de vie du logiciel (SISP, 2015).
L'application de la méthode consiste à effectuer les étapes suivantes, détaillées dans la CMP (2010): (i) obtenir la documentation disponible; (Ii) identifier le but et le type de partition, déterminer la portée du comte et de la frontière de la demande; (Iii) la mesure des fonctions de données, qui sont les besoins des utilisateurs fonctionnels en ce qui concerne le stockage et / ou la récupération des données et sont classés en fichier logique interne (ALI) – groupes de données logiques retenues dans les limites de l'application, et interface externe fichier (AIE) – ne sont référencées par l'application mesurée; (Iv) mesurer les fonctions de transaction, qui sont des fonctions offertes à l'utilisateur pour le traitement de données par une application et sont classés en (a) des entrées externes (EE) – responsable du traitement des données ou des informations de commande qui ont leur origine à l'extérieur du application de la frontière; (B) Ambulatoire (CE) – responsable de l'envoi des données ou contrôler les informations qui sortent de l'application de la frontière; (C) Les sorties externes (SE) – responsables de l'envoi de données ou contrôler les informations qui sortent de l'application de la frontière, y compris la logique de traitement supplémentaire, en plus de l'identifier dans une consultation externe; (V) le calcul de la taille fonctionnelle; (Vi) document et le nombre de rapports. Autrement dit, à partir de la documentation de conception ou d'un logiciel et sous le point de l'utilisateur de vue (exigences fonctionnelles) sont dérivées PF en termes de fonctionnalités offertes et les données concernées. Avoir la quantité de PF et basée sur des modèles tels que les estimations du modèle simplifié (Vazquez, 2012) ou le modèle COCOMO II (Boehm, 2009), proviennent de l'effort, le temps et le coût d'un projet.
2.2 L'architecture orientée services (SOA)
SOA est une approche architecturale pour le développement de logiciels dont le principe fondamental est de construire des services réutilisables et interopérables (ERL 2005). Selon ERL (2005), le service est l'unité fondamentale de la logique axée sur le service (la logique de la solution), à savoir les fonctions de l'application sont disponibles sous forme de service.
Une logique est considérée lorsque certains principes axés sur les services, appelés principes SOA sont appliqués dans une extension importante de la solution (ERL 2005). Selon ERL (2008) sont huit de ces principes: (i) la normalisation des contrats; (II) à couplage lâche services; (III) abstraction de service; (IV) la capacité de réutilisation de service; (V) autonomie de service; (VI) de l'état d'indépendance de service; (VII) la visibilité du service (découverte de la capacité); et (VIII) la capacité de service de la composition.
SOA cherche, par l'application des principes: augmenter l'alignement entre les entreprises et l'informatique; fédéralisation (accès aux services est normalisé afin d'unifier la vision de ses clients); la diversité des fournisseurs; le retour sur investissement (ROI); et l'agilité organisationnelle; et réduire le fardeau des TI dans l'organisation (ERL 2008). Ainsi, SOA vous permet de créer des applications qui répondent plus rapidement aux demandes des entreprises, puisque les services sont construits de manière standardisée, pouvant interopérer (communiquer) les uns avec les autres d'une manière standard et transparente, quelle que soit la plate-forme, les fournisseurs ou technologies qu'ils ont été construits ou courir.
Bien a été autour depuis un certain temps, la SOA a seulement gagné en importance depuis le milieu des années 2000 (ERL 2005). Selon l'enquête récente (WinterGreen, 2014), le marché de la SOA est en croissance rapide. Le rapport de recherche indique que le marché a atteint SOA 5,7 milliards $ en 2013 et pourrait atteindre 16,4 milliards $ US d'ici 2020. Selon l'enquête, cette croissance significative est due au fait que la SOA offre des processus automatisés plus efficaces et de lui fournir la possibilité d'investir davantage du budget sur la croissance de l'entreprise. De plus, des solutions logicielles découplés (indépendants), les services SOA peuvent être réutilisés efficacement.
3. Présentation de la méthodologie de travail adoptée
La mesure par l'utilisation de PF pour obtenir la taille fonctionnelle de conception de référence, réalisée en appliquant les règles de comptage fixées CPM (IFPUG, 2010), visant à identifier, à travers une analyse comparative, ce qui serait le coût , le temps et l'effort réel distribué dans la réalisation du projet et les résultats obtenus à partir de l'application de l'APF. Ainsi, il était possible d'évaluer si l'utilisation de l'APF serait adapté à la mesure du projet (développé dans le cadre de l'approche SOA).
Sélection 3.1 du projet
Le choix de la conception utilisée est produite naturellement, puisque la société où les auteurs travaux ont été retenus pour structurer l'adoption de SOA par une organisation pour des raisons de confidentialité de l'information, sera nommé entrepreneur dans le cadre de cet article .La projet vise, en général, la structure de l'adoption SOA par l'entrepreneur. les activités ont été développées pour la structuration, le développement, la mise en œuvre et le suivi du programme d'adoption SOA grâce à l'exécution des activités comprenant, entres autres, la création d'un système entièrement développé en utilisant l'approche SOA et à appeler CONCEPTION DE RÉFÉRENCE sur cet article.
3.2 Mesure de conception de référence
la mesure de conception de référence par l'utilisation de PF a été réalisée après la mise en œuvre complète et le déploiement du logiciel. Nous avons donc décidé d'effectuer un décompte détaillé, qui considère également la quantité de fonctions transactionnelles, la complexité fonctionnelle (faible, moyen, élevé) de chaque fonction individuelle. Ils ont été utilisés comme entrées de mesure, en plus des artefacts produits au cours du développement du projet, l'accès au logiciel en cours d'exécution. Nous comptons également à l'avis d'experts des membres de l'équipe du projet.
3.3 Effort de projet logiciel Estimating
Plusieurs modèles pour estimer l'effort de projets logiciels, basés sur PF, sont actuellement disponibles et les estimations du modèle simplifié (Vazquez (2012)) et COCOMO II (Boehm, 2009) le plus utilisé (SISP, 2015). Dans cette étude, nous avons utilisé les estimations du modèle simplifié, le même utilisé par le SISP (2015).
4. Les résultats expérimentaux
4.1 Conception de référence
Cette section présente les résultats réels obtenus à partir de la mise en œuvre de conception de référence, qui comprend des informations sur l'équipe du projet, l'effort, le temps et les coûts du projet.
4.1.1 Équipe du projet
Le tableau 1 montre le personnel affecté au développement de la solution. Ils présentent des informations sur le nombre de personnes qui ont participé au projet par type de ressource / rôle, le rôle de la ressource allouée à l'équipe avec leur porcentam respective de particação et le dévouement relatif, en pourcentage, d'une ressource / rôle spécifique sur l'ensemble du projet.
4.1.2 Le temps et l'effort Atteint
CONCEPTION DE RÉFÉRENCE a duré six mois et l'effort réel a été mesurée par heures d'enregistrement dans JIRA, un outil qui permet le suivi des projets grâce à des activités d'enregistrement et de déclaration. Le tableau 2 montre l'effort DISTRIBUTEURS à faire chaque étape de développement du projet.
Tableau 2: effort de conception de référence fait
| Projet de phase | heures |
| Modélisation et analyse d'affaires | 1076 |
| exécution | 826 |
| Thèses et mise en œuvre | 268 |
| Heures totales | 2170 |
4.1.3 Coût Held
Le coût a été calculé en heures à l'unité de conversion TEU (services techniques), qui est l'unité médicale utilisée pour quantifier le travail. Autrement dit, la quantité d'heures de travail est converti en TEU comme définition contractuelle pour déduire les coûts. Le calcul du Trésor américain tient compte de la complexité de l'activité réalisée (basse, moyenne et haute). Le tableau 3 montre le résultat de la conversion des heures / UST pour chaque phase du projet.
Tableau 3: Coût de conception de référence Réalisation
| Projet de phase | heures | UST |
| Modélisation et analyse | 1076 | 1765 |
| exécution | 826 | 894 |
| Thèses et mise en œuvre | 268 | 304 |
| Heures totales | 2170 | 2963 |
Compte tenu de la quantité de R TEU contracté 247,50 $, le projet a un coût total de R $ 733,342.50
Résultats généraux 4.1.4
Le tableau 4 présente le résumé de l'effort, le temps et les coûts distribués pour faire la conception de référence, qui servent de base à l'analyse comparative du résultat de la mesure de la taille fonctionnelle du logiciel grâce à l'utilisation mp.
Tableau 4: Résultat global
| CONCEPTION DE RÉFÉRENCE | |
| Effort (heures): | 2170 |
| Terme (mois): | 6 |
| Coût (R $): | R $ 733,342.50 |
4.2 Mesure de la taille de la fonctionnelle – IFPUG
La mesure fonctionnelle de la taille du logiciel en utilisant l'application FP considéré dans son ensemble, avec la vue fonctionnelle du point de vue de l'utilisateur, tel que recommandé par la norme CSA IFPUG (IFPUG, 2010). Le tableau 5 montre l'objectif (objectif ou le but de la mesure) et l'étendue de mesure (ensemble ou sous-ensemble d'applications qui sont mesurées). Le tableau 6 montre brièvement le résultat de comptage correspondant à la valeur de la taille fonctionnelle du modèle de référence. La période de dérivation du personnel de l'effort et le coût a été déterminé en fonction des estimations du modèle simplifié, qui sont présentés dans le tableau 7.
Tableau 5: Scénario fonctionnelle mesure CONCEPTION DE RÉFÉRENCE
| scénario fonctionnel | |||
| Objet de la mesure | la conception de référence de mesure de la taille fonctionnelle (APF IFPUG) mis au point en tant que maître du programme d'adoption SOA. | ||
| Mesure de portée | Applications de conception de référence | ||
Comte Technique: détermine si le comptage est indicative estimée ou cassé. Le comptage indicative est basée uniquement sur des informations sur les fonctions de données, soit le nombre de fichiers logiques (Alis et EID). Le nombre estimé considère, dans la quantité de fonctions de données, des informations sur les fonctions de transaction afin que de telle sorte que les besoins des utilisateurs doivent être plus détaillées. Comme pour les comptes détaillés, plus la quantité de fonctions transactionnelles, il est nécessaire de déterminer la complexité fonctionnelle (faible, moyen, élevé) de chaque fonction individuelle (NESMA, 2015).
Type Nombre: trois types possibles de comptage: (i) le développement: Comme les fonctionnalités fournies aux utilisateurs qui envisagent la première installation du logiciel. (Ii) Amélioration / entretien: changements liés, il est, a ajouté, modifié ou supprimé, une fonctionnalité logicielle existante. (Iii) Application: mesure de la fonctionnalité d'une application permet à l'utilisateur. Une application est ensemble cohérent de procédures et de données automatisée, qui vise à soutenir un objectif commercial et se compose d'un ou plusieurs composants, des modules ou sous-systèmes (IFPUG, 2010).
Taille du projet fonctionnel: Fait référence à la valeur de la taille fonctionnelle du modèle de référence.
Productivité Nuit (h): Indique le nombre d'heures productives sur une personne. Ce travail a été considéré comme 6 heures / jour, tel que recommandé par le (SISP, 2015).
Indice de productivité (heures / FP): Fait référence à la quantité de temps consacré à la production de 1 PF. La détermination de la valeur de l'indice de la productivité dépend de plusieurs facteurs, qui peuvent inclure, entre autres, la plate-forme technologique, la sécurité, la performance, la facilité d'utilisation et la taille du projet. Chaque organisation doit avoir sa propre table de productivité, compte tenu des données historiques des projets précédents.
Effort (personne / heure): Cela fait référence au nombre d'heures à distribuer dans la réalisation du projet ou la livraison d'une certaine taille fonctionnelle. Il est calculé à partir de la conception fonctionnelle et la taille de l'indice de productivité (taille (PF) x indice de productivité (HH / FP)).
Environnement: Fait référence à l'exposant à utiliser dans la formule pour déterminer la durée recommandée. Le tableau 1 présente les options disponibles. Ceci a été choisi le « système OO – système orienté objet », qui correspond le mieux aux caractéristiques d'un projet SOA.
Autre période: elle est calculée selon la formule Capers Jones[Jones,2007].
Charge de travail mensuel (heures): Indique le nombre d'heures de travail travaillées par personne en mois.
Équipe: Fait référence à la quantité de ressources nécessaires au développement du projet et devrait être considérée comme la répartition en pourcentage de la ressource au projet. Dans le résultat ci-dessus, le 6.2 caractéristiques équipe de conception pourrait correspondre, par exemple, une équipe de 12 personnes avec une allocation de 50% et un chef de projet avec 20% alloués au projet.
Le personnel a informé: Cela fait référence à l'équipe qui a travaillé efficacement à l'élaboration du projet. Il vise à soutenir d'autres simulations d'efforts et de temps et la répartition des ressources dans l'équipe en fonction de l'engagement de chacun au projet.
D'autres simulations estimations: d'autres estimations de simulations ont été générées en fonction de l'équipe informée et compte tenu de la réduction à long terme. a été définie la valeur du point de fonction utilisée en fonction des références historiques de la société de l'entrepreneur. les coûts du projet ont été calculés sans tenir compte de la période de réduction et compte tenu de la période de réduction.
5. conclusions
5.1 Analyse critique de la proposition
De l'analyse des résultats obtenus par l'application de conception de référence CSA et d'exécution, il a été conclu que le coût réel de la conception SOA et obtenue à partir de la mesure par FP a donné lieu à des valeurs significativement différentes (coût réel: R $ 733342 50 et coût estimé: R 349,600.00 $). Il y avait aussi une différence significative entre l'effort requis pour le développement du projet et l'effort réel (réel effort: heures 2170 et effort estimé: 6992 heures). Le coût réel et estimé (coût réel: R 733,342.50 $ par rapport au coût estimé: R $ 593,620.00) ne montrent des valeurs relativement proches lors de l'estimation méthode du coût pour contourner considère que la réduction du temps pour le développement du projet par rapport au type idéalement recommandé ( temps réel: 6 mois en fonction du temps recommandé: 7,71 mois).
Ainsi, il a été conclu que le CSA avait des résultats très différents par rapport aux résultats réels, et donc ne convient pas à la mesure des projets SOA. Soma est aussi le fait que le CSA ne compte pas dans son score aux exigences non fonctionnelles, qui sont communs dans de nombreuses applications SOA, telles que les services de réutilisation et de composition. En plus de ne pas laisser la solution de mesure fragmentée, à savoir la mesure individuelle pour le service. Ceci est une caractéristique tout à fait souhaitée en matière de mesure des projets SOA, ce qui peut impliquer la construction d'une solution complète ou juste un sous-ensemble de ces services, et peut également impliquer la construction d'un seul service spécifique.
5.2 Limitations et travaux futurs
Le travail se limitait à mesurer seulement un projet. En outre, il a utilisé une seule méthode de calcul des estimations de l'effort, le coût et le temps. Dans les travaux futurs, l'application du CSA dans une plus grande diversité de projets et d'autres méthodes d'estimation peuvent bénéficier en ce qu'elle fournira une plus grande fiabilité dans les conclusions. Il sera également d'une grande importance de proposer une méthode spécifique pour mesurer la taille des logiciels SOA, qui cherche à suivre les concepts les plus purs de IFPUG par rapport à la mesure fonctionnelle, mais aussi tenir compte de la nécessité d'une solution de mesure fragmentaire, ainsi que la mesure de exigences non fonctionnelles.
références
ALBRECHT, IBM J. Allan La CEI et la ligne directrice 313. AD / M 1984 Productivité.
BOEHM, B.W. Estimation des coûts du logiciel avec COCOMO II. Prentice Hall, New Jersey, 2009.
Calazans Angelica; LISBONNE Irina; OLIVEIRA Marcelo. Évaluation des systèmes de Caractéristiques générales en matière d'analyse Fonction Point – APF en appliquant les GQM – Objectif, Questions, Métriques. VII Symposium international sur l'amélioration du processus logiciel. São Paulo. Novembre 2011.
ERL, Thomas. L'architecture orientée services: Concepts, technologie et design. Crawfordsville: Prentice Hall PTR, août 2005.
ERL, Thomas. Principes SOA de la conception des services. Prentice Hall, 2008.
Farrag, Esraa A;. Moawad Ramadan; IMAM, Ibrahim F. Une approche pour l'effort d'estimation de l'architecture orientée service (SOA) Projets. JSW, v. 11, no. 1, p. 44-63, 2016.
FLORAC, William A;. PARK, Robert E;. CARLETON, Anita D. Logiciel de mesure pratique: mesure pour la gestion et l'amélioration des processus. MELLON PITTSBURGH UNIV CARNEGIE PA-GENIE LOGICIEL INST 1997.
Gençel, Cigdem; DEMIRORS, Onur. Mesure de la taille fonctionnelle revisitée. ACM Transactions sur le génie logiciel et méthodologie (TOSEM) c. 17, no. 3, p. 15, 2008.
GOMES, Yuri Marx Pereira. taille fonctionnelle, l'effort et le coût des projets SOA avec des points de fonction. pas. LXVIII, Novembre de 2012.
IFPUG – UTILISATEUR INTERNATIONAL POINT GROUPE DE FONCTION. Manuel pratiques Points de fonction de comptage. Version 4.3.1, Janvier de 2010.
IFPUG – UTILISATEUR INTERNATIONAL POINT GROUPE DE FONCTION. Manuel des pratiques d'évaluation. Version 2.3, mai 2015.
JONES, C. L'estimation des coûts logiciels. Deuxième édition, McGraw Hill, 2007.
Kaur, Prabhjot. Un examen du logiciel métrique et mesure. International Journal of Computer Applications et technologies de l'information, vol. 9, no. 2, p. 187, 2016.
Jeff Lindskoog. L'application de points de fonction environnement dans la SOA. EDS, une société HP. St. E. Hoffer 1401 Kokomo, IN 46902. États-Unis. Septembre 2009.
NESMA – Fonction Pays-Bas Points Utilisateurs. Accueil Fonction Analyse Point. Juillet à 2015.
Pressman, Roger S. Software Engineering: une approche professionnelle. 7e édition. Ed: McGraw Hill, 2011.
ROETZHEIM, William H. L'estimation des coûts logiciels. SAN FRANCISCO DEVELOPPEMENT LOGICIEL, v. 8, no. 10, p. 66-68, 2000.
SISP. Logiciel de script métriques SISP: version 2.1, Ministère de la planification, du budget et de gestion. Secrétaire de la logistique et de la technologie de l'information. Brasilia: MP 2015.
SOARES DOS REIS, Julio Cesar; BARBOSA, Marcelo Werneck. PROPOSITION DE DEVIS POUR LES BESOINS TECHNIQUES. Journal des systèmes et ordinateur RSC, v. 3, no. 1, 2013.
Charley Tichenor, étude SNAP-Cas n ° 2 (1 VSN. 0): Comment utiliser les points de fonction et SNAP pour améliorer le contrat d'acquisition de logiciels. IFPUG. Juin 2014.
VAZQUEZ, Carlos E;. SIMÕES, Guilherme Siqueira; ALBERT, Renato Machado. Analyse Fonction point: la mesure, les estimations et la gestion des projets logiciels. 12e édition, éditeur Erica Ltda, São Paulo, 2012.
Wilkie George F. et al. La valeur du logiciel de dimensionnement. L'information et de la technologie du logiciel, vol. 53, no. 11, p. 1236-1249, 2011.
[1] Maîtrise en génie électrique – UNB
[2] Docteur en ingénierie et gestion des connaissances
[3] Doctorat en génie électrique de l’Université de Brasilia (2004), où il enseigne au Département de génie électrique depuis 1998. A doctoral à l’Ecole Supérieure d’Electricité (Supélec), Rennes / France (2001/2002) et le stade de post doctorat à l’Institut suédois d’informatique (SICS) de Stockholm / Suède (2011). Il a été coordonnateur du Centre Technologies de l’information (NTI) à UNB (2006-2008) et directeur du Centre informatique (DPC) à l’UNB (2007-2008). Il fonctionne dans des projets de recherche, de développement technologique et de l’innovation et de conseil, en partenariat avec plusieurs entreprises et entités gouvernementales dans les domaines liés aux TIC, où elle opère dans la définition de la stratégie, le modèle de gouvernance, la technologie de prospection et de transfert de technologie. Ses domaines d’intérêt actuel comprennent: cloud computing, l’architecture orientée services, la gestion des processus métier, les systèmes distribués et des applications technologies de l’information dans des environnements gouvernementaux
