12. At regular intervals, the team reflects on how to become more effective, then tunes
4.3. Guia e Sugest˜ oes de Utilizac ¸˜ ao
4.3 g u i a e s u g e s t ˜o e s d e u t i l i z a c¸ ˜a o
Nesta sec¸c˜ao ´e apresentado um guia e algumas sugest˜oes de utiliza¸c˜ao do Management of Planned Value que as equipas podem seguir para gest˜ao eficiente de m´etricas em projetos de desenvolvimento de software.
1. A cada entrega de cada vers˜ao do produto, estipular um tempo necess´ario para o teste por parte do utilizador final ao mesmo e recolher o feedback sobre a qualidade de uti- liza¸c˜ao.
2. Em caso de projetos de grande complexidade, risco e com grande n´umero de m´etricas para serem monitorizadas, sugere-se a cria¸c˜ao de um PMO para monitoriza¸c˜ao das m´etricas.
3. Algumas m´etricas devem ser tratadas como Key Performance Indicators (KPIs). Em caso de d´uvida, ou mesmo para confirma¸c˜ao, se determinada m´etrica deve ser tratada como KPI, devem-se efetuar dois passos: 1) perceber se a m´etrica segue objetivos SMART (ver Sec¸c˜ao1.5) e 2) responder, para cada m´etrica, positiva ou negativamente `
as seguintes quest˜oes, propostas por Kerzner [14]: • ´E preditiva?
• ´E quantific´avel?
• ´E contest´avel/discut´ıvel?
• ´E relevante?
• ´E autom´atica?
Se a maioria das respostas para determinada m´etrica for positiva, ´e prov´avel estarmos perante um KPI.
4. O gestor de projeto deve-se reunir com todos os stakeholders que considere necess´ario no in´ıcio do projeto e chegar a um acordo sobre o que constitui o sucesso do projeto.
5. O gestor de projetos deve chegar a um acordo sobre que m´etricas devem ser monitori- zadas para verificar se o sucesso foi atingido. Algumas m´etricas dever˜ao ser tratadas como KPIs.
6. O gestor de projetos (em certos casos, juntamente com o PMO) dever´a preparar dash- boards para entregar a cada stakeholder.
7. No fecho do projeto, dever´a ser mantido um registo das m´etricas utilizadas, para que possam ser reutilizadas em projetos similares no futuro.
4.3. Guia e Sugest˜oes de Utilizac¸˜ao 90
• Deve compreender a cultura e valores da organiza¸c˜ao,
• Deve funcionar como mentor a todos os que pretendam utilizar ou analisar a m´etrica,
• Deve ter respeito por toda a equipa afeta aos trabalhos relacionados com o projeto,
• Deve ser capaz de executar melhorias cont´ınuas na m´etrica, incluindo melhorias nas t´ecnicas utilizadas para medi¸c˜ao,
• Deve ser capaz de suportar a promo¸c˜ao do uso de m´etricas,
• Deve suportar o trabalho do PMO, caso este exista, ajudando a determinar se a m´etrica mant´em a sua validade.
9. ´E comum selecionarem-se m´etricas em demasia, pois tudo parece importante. Tentar encontrar um balan¸co e acordar quais as m´etricas relevantes.
10. Durante a defini¸c˜ao da m´etrica (nas fases de inicia¸c˜ao e planeamento), incluir os sta- keholders de forma a que estes possam perceber o processo e torna-lo o mais adequado poss´ıvel para que seja atingido o sucesso.
11. Pedir a opini˜ao ao pessoal mais experiente.
12. Se forem selecionadas m´etricas relativas aRH, assumir que estes apenas v˜ao ser produ- tivos durante cerca de 80% do tempo. Assim, considerar uma aloca¸c˜ao inferior a 80% para cada RH.
13. RHque est˜ao alocados a m´ultiplos projetos levam mais tempo a completar tarefas devido ao tempo necess´ario para a troca de contexto.
14. Ter sempre planos de contingˆencia para eventos inesperados e resolu¸c˜ao de problemas.
15. Reservar tempo suficiente para fazer uma estimativa adequada do projeto. As estima- tivas apressadas s˜ao estimativas imprecisas e de alto risco. Para grandes projetos de desenvolvimento, a etapa de estimativa deve ser considerada como um mini projeto.
16. Sempre que poss´ıvel, utilizar dados de projetos anteriores similares, realizados dentro da mesma organiza¸c˜ao. Isto resultar´a numa estimativa com mais precis˜ao.
17. Se a organiza¸c˜ao n˜ao recolhe dados de projetos anteriores, ser´a uma boa ocasi˜ao para iniciar a arquivar os mesmos e tornar este procedimento habitual.
18. Considerar as estimativas dos membros da equipa, pois as estimativas efetuadas por quem efetua o trabalho de desenvolvimento s˜ao mais precisas em compara¸c˜ao `as estima- tivas efetuadas por quem n˜ao est´a inclu´ıdo na equipa de desenvolvimento.
4.3. Guia e Sugest˜oes de Utilizac¸˜ao 91
19. Considerar as estimativas de v´arias pessoas e diferentes t´ecnicas para garantir o menor erro poss´ıvel.
20. Observar e relacionar as estimativas e perceber a convergˆencia ou divergˆencia entre as mesmas.
21. Re-estimar o projeto v´arias vezes durante o seu ciclo de vida de forma a manter os valores atuais e efetuar as devidas corre¸c˜oes o mais depressa poss´ıvel.
22. De forma a que se obtenham estimativas confi´aveis, devem-se considerar os seguintes passos:
• Estimar tendo por base projetos semelhantes j´a conclu´ıdos;
• Utilizar t´ecnicas de decomposi¸c˜ao simples e a partir do resultado desta gerar esti- mativas de custo e esfor¸co do projeto;
• Utilizar v´arias t´ecnicas de estimativa diferentes para poder analisar e comparar os resultados.
Apesar de serem propostas dezenas de m´etricas que podem ser monitorizadas em projetos de desenvolvimento de software, n˜ao ´e de todo vi´avel monitorizar todas as m´etricas apre- sentadas nesta disserta¸c˜ao, dado o esfor¸co necess´ario para tal atividade. Tal como referido anteriormente nesta disserta¸c˜ao, um n´umero elevado de m´etricas pode provocar atrasos e atrapalhar o progresso, levando ao insucesso do projeto.
Como o maior n´umero de m´etricas apresentadas s˜ao relativas aos modelos de qualidade, aconselha-se a reunir com o cliente e perceber quais as caracter´ısticas dos modelos que tˆem maior relevˆancia para o sistema ou software a desenvolver e que v˜ao acrescentar valor para o utilizador final.
Para perceber quais as caracter´ısticas mais relevantes, ´e proposto o seguinte m´etodo:
1. Classifica¸c˜ao da relevˆancia - solicitar ao Product Owner que classifique cada um dos fatores de qualidade do software de 1 a 5, sendo 1 menos aplic´avel e 5 mais aplic´avel, em termos do produto de software.
2. Identifica¸c˜ao de 3 fatores de qualidade chave - perguntar tanto aos stakeholders externos, como `a equipa de desenvolvimento, quais s˜ao os 3 fatores de qualidade de software que eles mais desejam e que priorizem os mesmos de 1 a 3, sendo o 1 o mais priorit´ario e 3 o menos priorit´ario. Anotar os aspetos que levaram `a decis˜ao, para compreender as necessidades de cada um.
3. Encontrar o consenso - reunir o Product Owner, os stakeholders externos e os membros da equipa de desenvolvimento de software para discutir e chegar a um consenso sobre quais as caracter´ıstica de qualidade de software que ser˜ao focadas no projeto.
4.3. Guia e Sugest˜oes de Utilizac¸˜ao 92
Este m´etodo n˜ao ´e r´ıgido, pelo que podem ser identificadas mais do que 3 caracter´ısticas de qualidade de software tidas como chave para o sucesso do produto. No entanto, deve-se manter o foco no que realmente ´e essencial.
5
C O N C L U S ˜A O
Terminado o estudo, segue-se um conjunto de conclus˜oes, identifica¸c˜ao de limita¸c˜oes e su- gest˜oes para trabalhos futuros.
Tal como apresentado no Cap´ıtulo1, esta disserta¸c˜ao pretende responder a duas perguntas de investiga¸c˜ao:
• Quais s˜ao as principais m´etricas a monitorizar durante o desenvolvimento de software de forma a concluir o mesmo com sucesso?
• Quais os processos e/ou atividades que devem ser utilizados para acompanhar as m´etricas selecionadas?
Para responder `as perguntas de investiga¸c˜ao propostas, primeiro foi feito um levantamento do estado da arte e fundamentos te´oricos sobre a disciplina da Gest˜ao de Projetos e da Engenharia de Software. Foram estudadas abordagens ´ageis e tradicionais, tendo-se optado pela metodologia Scrum para este estudo. Dentro do ˆambito da Engenharia de Software, foi percebida a importˆancia da qualidade do software para a entrega do software com sucesso, raz˜ao pela qual a qualidade tem especial destaque nesta disserta¸c˜ao.
Assim, no quarto cap´ıtulo, Management of Planned Value, foi apresentada uma sugest˜ao de um processo que se deve seguir para a gest˜ao das m´etricas, respondendo `a segunda pergunta de investiga¸c˜ao, assim como m´etricas relativas `a metodologia Scrum, um exemplo de uma dashboard EVMem contexto ´agil, e m´etricas relativas aos modelos de qualidade apresentados pela ISO 25010 (SQuaRE), respondendo `a primeira pergunta de investiga¸c˜ao. Foi ainda apresentado um conjunto de sugest˜oes e um guia que ajudam na monitoriza¸c˜ao das m´etricas em projetos de desenvolvimento de software.
O processo apresentado para gest˜ao das m´etricas consiste em quatro passos: definir o su- cesso, identificar e selecionar as m´etricas, medir o progresso e refinar e melhorar. Apesar de ser sugerida a utiliza¸c˜ao deste processo em projetos Scrum, pode tamb´em ser aplicado a projetos tradicionais ou com abordagens mistas. Neste caso poder˜ao ser feitas algumas altera¸c˜oes ao processo, de forma a torn´a-lo o mais adequado poss´ıvel. No decorrer do estudo, levantou-se a seguinte quest˜ao: ”Adicionando o processo a abordagens ´ageis, estar´a a flexibi-
94
lidade da abordagem comprometida?”. Em resposta afirmativa, a diminui¸c˜ao da flexibilidade da abordagem ´e vista como uma limita¸c˜ao do Management of Planned Value.
O maior desafio foi a identifica¸c˜ao de m´etricas gerais relativas `as carater´ısticas qualidade, pois v´arias caracter´ısticas dos modelos Quality In Use Model e System/Software Product Quality Model s˜ao relativas a um produto concreto. Mesmo partindo de um produto ou ideia concreta do produto, existem v´arias barreiras `a medi¸c˜ao da qualidade, tais como requisitos mal definidos ou que n˜ao s˜ao levados em considera¸c˜ao, a qualidade provoca custos adicionais e o cliente nem sempre tem isso em conta, existem barreiras resultantes da defini¸c˜ao pouco clara de quem s˜ao os utilizadores do sistema e quais os contextos de uso, entre outras desvantagens.
Analisando as m´etricas de qualidade propostas, existem duas m´etricas que surgem asso- ciadas `a grande maioria das sub-caracter´ısticas e que podem parecer repetidas: o ”Tempo de observa¸c˜ao”e o ”Tempo de opera¸c˜ao”. No entanto, podem ser medidas vers˜oes diferentes de cada m´etrica, dependendo da sub caracter´ıstica ou da necessidade. Por exemplo, para determinada sub caracter´ıstica, pode ser interessante registar o tempo de opera¸c˜ao total do sistema e o tempo de opera¸c˜ao de determinada funcionalidade. Estas duas m´etricas fornecem tamb´em informa¸c˜ao sobre qual foi o tempo dispensado a testar o sistema. Se o tempo de observa¸c˜ao for muito reduzido, podem n˜ao ser sido feitos testes suficientes, e a qualidade das medi¸c˜oes pode ser afetada ou estas n˜ao apresentarem a devida confian¸ca.
Na grande maioria das sub carater´ısticas ´e apresentada uma m´etrica que mede o ”N´ıvel de satisfa¸c˜ao em rela¸c˜ao a (...)”determinado aspeto de qualidade. Estas m´etricas informam sobre a experiˆencia do utilizador final em rela¸c˜ao ao uso da aplica¸c˜ao. Utilizando estas m´etricas, ´e poss´ıvel receber feedback de forma mais completa, garantindo que nenhum aspeto crucial para o sucesso ´e esquecido. O ”N´ıvel de satisfa¸c˜ao”depende tamb´em do ”Tempo de observa¸c˜ao”. Isto ´e, os n´ıveis de precis˜ao e de confian¸ca na medi¸c˜ao do ”N´ıvel de satisfa¸c˜ao”aumentam conforme o tempo dispensado pelo utilizador a testar o sistema e a observar o seu comporta- mento.
A lista de m´etricas propostas n˜ao ´e final, apesar da sua extens˜ao. Certamente que, no futuro, muitas outras m´etricas poder˜ao ser identificadas e adicionadas a esta lista. Adicionando contexto ao estudo, muitas outras m´etricas dependentes do contexto e dos crit´erios de sucesso do projeto poder˜ao ser identificadas. Apesar de terem sido propostas dezenas de m´etricas, espera-se que, aplicando a um contexto espec´ıfico, o n´umero seja bastante mais reduzido e que algumas das m´etricas selecionadas sejam tratadas como KPIs.
Este estudo pode ainda ser continuado e melhorado. Como sugest˜oes de trabalhos futu- ros, aponta-se a 1) valida¸c˜ao pr´atica desta disserta¸c˜ao num projeto real, quer este siga uma abordagem ´agil ou um abordagem tradicional na sua gest˜ao, 2) compara¸c˜ao dos resultados e conclus˜oes obtidas da aplica¸c˜ao do Management of Planned Value nas diferentes abordagens, 3) identifica¸c˜ao de Key Performance Indicators (KPIs), 4) a cria¸c˜ao de um mecanismo au- tom´atico de gest˜ao de m´etricas, 5) o desenvolvimento de um sistema de informa¸c˜ao capaz de
95
fornecer informa¸c˜ao em tempo real acerca das m´etricas selecionadas e que permita a sele¸c˜ao de m´etricas a visualizar por parte dos stakeholders, podendo estes escolher que m´etricas de- sejam analisar, ou ainda 6) identificar novas m´etricas para outras ´areas de conhecimento do PMBoK, tais como m´etricas relativas `a comunica¸c˜ao ou ao risco.
B I B L I O G R A F I A
[1] Vijay K. Vaishnavi e William Kuechler, Jr., Design Science Research Methods and Patterns: Innovating Information and Communication Technology. Boston, MA, USA: Auerbach Publications, 1st ed., 2007.
[2] Winston W. Royce, “Managing the Development of large Software Systems,” IEEE Wescon, no. August, pp. 1–9, 1970.
[3] Federal Highway Administration, Clarus Concept of Operations. 2005.
[4] Barry Boehm, “A Spiral model of software development and enhancement,” in Software Management, Seventh Edition, pp. 37–48, 2007.
[5] “The agile42 Scrum Cheat Sheet.” https://www.agile42.com/en/ agile-info-center/scrum/scrum-cheat-sheet/. Acedido em: 27 de Fevereiro de 2018.
[6] “What is Kanban.” https://sites.google.com/site/wcfpandu/what-is-kanban. Acedido em: 27 de Fevereiro de 2018.
[7] IEEE Computer Society, Pierre Bourque e Richard E. Fairley, Guide to the Software Engineering Body of Knowledge (SWEBOK(R)): Version 3.0. Los Alamitos, CA, USA: IEEE Computer Society Press, 3rd ed., 2014.
[8] International Organization for Standardization e International Electrotechnical Commis- sion, “ISO/IEC 25000:2014 Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - Guide to SQuaRE,” 2014.
[9] apppm, “Story Points Estimation.” http://apppm.man.dtu.dk/index.php/Story_ Points_Estimation. Acedido em: 31 de Mar¸co de 2018.
[10] A K Munns e B F Bjeirmi, “The role of project management in achieving project success,” International Journal of Project Management, vol. 14, no. 2, pp. 81–87, 1996.
[11] Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBoK Guide). Project Management Institute, 6a ed., 2017.
[12] Wayne Abba, “How earned value got to prime time: A short look back and glance ahead,” The Measurable News, vol. 2001, 2001.
b i b l i o g r a f i a 97
[13] Jan Terje Karlsen, “Project stakeholder management,” Engineering Management Jour- nal, vol. 14, no. 4, pp. 19–24, 2002.
[14] Harold Kerzner, Project Management Metrics, KPIs, and Dashboards: A Guide to Measuring and Monitoring Project Performance. John Wiley & Sons, 2011.
[15] Francesco Perrini e Antonio Tencati, “Sustainability and stakeholder management: The need for new corporate performance evaluation and reporting systems,” Business Stra- tegy and the Environment, vol. 15, no. 5, pp. 296–308, 2006.
[16] Capers Jones, Applied Software Measurement: Assuring Productivity and Quality. New York, NY, USA: McGraw-Hill, Inc., 1991.
[17] Standish Group, “CHAOS Report,” 1995.
[18] Capers Jones, Assessment and Control of Software Risks. Yourdon Press Series, Yourdon Press, 1994.
[19] Michael L. Cook, “Software Metrics: An Introduction and Annotated Bibliography,” SIGSOFT Softw. Eng. Notes, vol. 7, pp. 41–60, Apr.
[20] IEEE, “IEEE 610.12-1990 Standard Glossary of Software Engineering Terminology,” 1990.
[21] Cornelius T. Leondes, Intelligent Systems: Technology and Applications, Six Volume Set. Taylor & Francis, 2002.
[22] Martin Campbell-Kelly, “The Development of Computer Programming in Britain (1945 to 1955),” Annals of the History of Computing, vol. 4, no. 2, pp. 121–139, 1982.
[23] David Parnas, “On the criteria to be used in decomposing systems into modules,” Com- mun. ACM, vol. 15, pp. 1053–1058, Dec. 1972.
[24] “Software Engineering.” https://en.wikipedia.org/wiki/Software_engineering. Acedido em: 17 de Janeiro de 2018.
[25] Farzana Asad Mir e Ashly H. Pinnington, “Exploring the value of project management: Linking Project Management Performance and Project Success,” International Journal of Project Management, 2014.
[26] Kam Jugdev e Ralf Moller, “A retrospective look at our evolving understanding of project success,” IEEE Engineering Management Review, vol. 34, no. 3, pp. 110–127, 2006.
[27] Jo˜ao Varaj˜ao, “Success Management as a PM Knowledge Area - Work-in-Progress,” Procedia Computer Science, vol. 100, pp. 1095–1102, 2016.
b i b l i o g r a f i a 98
[28] Jo˜ao Varaj˜ao, Caroline Dominguez, Pedro Ribeiro e Anabela Paiva, “Failures in software project management – are we alone? a comparison with construction industry,” The Journal of Modern Project Management, pp. 22–27, 2014.
[29] Marco Liberato, Jo˜ao Varaj˜ao e Paulo Martins, “CMMI Implementation and Results: The Case of a Software Company,” Modern Techniques for Successful IT Project Mana- gement, 2015.
[30] Jo˜ao Varaj˜ao, Caroline Dominguez, Pedro Ribeiro e Anabela Paiva, “Critical Success Aspects in Project Management : Similarities and Differences Between the Construction and the Software Industry,” Tehnicki Vjesnik-Technical Gazette, vol. 21, no. 2, pp. 583– 589, 2014.
[31] Adam Collins e David Baccarini, “Project Success - A Survey,” Journal of Construction Research, vol. 5, pp. 211–231, 2004.
[32] William J. Pinkerton, Project Management : Achieving Project Bottom-Line Success. McGraw-Hill Education, 1st ed., 2003.
[33] Danie Van Der Westhuizen e Edmond P. Fitzgerald, “Defining and measuring project success,” in Defining and measuring project success, 2005.
[34] Terry Cooke-Davies, “The “real” success factors on projects,” International Journal of Project Management, vol. 20, no. 3, pp. 185–190, 2002.
[35] Harold Kerzner, Project Management: a Systems Approach to Planning, Scheduling, and Controlling. John Wiley & Sons, 2009.
[36] Jeffrey K. Pinto e Dennis P. Slevin, “Critical factors in successful project implementa- tion,” IEEE Transactions on Engineering Management, vol. EM-34, no. 1, pp. 22–27, 1987.
[37] Jeffrey K. Pinto e John E. Prescott, “Variations in Critical Success Factors Over the Stages in the Project Life Cycle,” Journal of Management, vol. 14, no. 1, pp. 5–18, 1988.
[38] Nitin Agarwal e Urvashi Rathod, “Defining ’success’ for software projects: An explora- tory revelation,” International Journal of Project Management, vol. 24, no. 4, pp. 358– 370, 2006.
[39] Gabriela Fernandes, Stephen Ward e Madalena Ara´ujo, “Identifying useful project ma- nagement practices : A mixed methodology approach,” International Journal of Infor- mation Systems and Project Management, vol. 1, no. 4, pp. 5–21, 2013.
b i b l i o g r a f i a 99
[40] Terry L. Fox e J. Wayne Spence, “The effect of decision style on the use of a project management tool,” ACM SIGMIS Database, vol. 36, no. 2, pp. 28–42, 2005.
[41] Karlos Artto, Miia Martinsuo, Perttu Dietrich e Jaakko Kujala, “Project strategy: stra- tegy types and their contents in innovation projects,” International Journal of Managing Projects in Business, vol. 1, no. 1, pp. 49–70, 2008.
[42] Andreas Auinger e Alexander Hochmeier, “An Enterprise 2.0 project management ap- proach to facilitate participation, transparency, and communication,” International Journal of Information Systems and Project Management, vol. 1, no. 2, pp. 43–60, 2013.
[43] Jo˜ao M. Fernandes e Ricardo J. Machado, Requirements in Engineering Projects. Lec- ture Notes in Management and Industrial Engineering, Springer International Pu- blishing, 2015.
[44] Evelyn J. Barry, Tridas Mukhopadhyay e Sandra A. Slaughter, “Software Project Dura- tion and Effort: An Empirical Study,” Information Technology and Management, vol. 3, no. 1-2, pp. 113–136, 2002.
[45] Anish Mittal, Kamal Parkash e Harish Mittal, “Software cost estimation using fuzzy logic,” ACM SIGSOFT Software Engineering Notes, vol. 35, no. 1, p. 1, 2010.
[46] Capers Jones, “Software project management practices: Failure versus success,” Cross- Talk: The Journal of Defense Software . . . , vol. 17, no. 10, pp. 5–9, 2004.
[47] Kunal Jamsutkar, Viki Patil e P. M. Chawan, “Software Project Quality Management,” International Journal of Engineering Research and Applications, vol. 2, no. 3, 2012. [48] Meghann L. Drury-Grogan, “Performance on agile teams: Relating iteration objectives
and critical decisions to project management success factors,” Information and Software Technology, vol. 56, no. 5, pp. 506–515, 2014.
[49] Norizan Ahmad, Faridah Ismail, Syarifah N. A. S. Alwi e Rahasnan A. Rashid, “Impor- tant client attributes that influence project success: A focus on the briefing process,” in ISBEIA 2011 - 2011 IEEE Symposium on Business, Engineering and Industrial Appli- cations, pp. 314–319, 2011.
[50] Julian Day, “Software development as organizational conversation: analogy as a systems intervention,” Systems Research and Behavioral Science, vol. 17, no. 4, pp. 349–358, 2000.
[51] William Bruce Cameron, Informal sociology: a casual introduction to sociological thin- king. Studies in sociology, Random House, 1963.
b i b l i o g r a f i a 100
[52] Tom Gilb, “Adding stakeholder metrics to agile projects,” 2004.
[53] “A Minimalist’s Approach to Project Metrics.” https://pmhut.com/ a-minimalists-approach-to-project-metrics. Acedido em: 17 de Janeiro de 2018.
[54] David Parmenter, Key Performance Indicators (KPI). 2a ed., 2010.
[55] Norman Fenton e James Bieman, Software Metrics: A Rigorous and Practical Approach. 3a ed., 2014.
[56] D. Ince, “Software metrics: introduction,” Information and Software Technology, vol. 32, no. 4, pp. 297–303, 1990.
[57] Stephen H. Kan, Metrics and Models in Software Quality Engineering. Addison-Wesley Professional, 2a ed., 2014.
[58] Luiz Fernando Capretz, “Bringing the human factor to software engineering,” IEEE Software, vol. 31, no. 2, pp. 0–2, 2014.
[59] Gary S. Lynn e Richard R. Reilly, “Measuring Team Performance,” Research-Technology Management, vol. 43, no. 2, pp. 48–56, 2000.
[60] B. A. Kitchenham e Littlewood, Measurement for Software Control and Assurance. Springer Netherlands, 1989.
[61] Frederick Winslow Taylor, The Principles of Scientific Management. Library of Ameri- can civilization, Harper & Brothers, 1911.
[62] Chiu, Y.C., An Introduction to the History of Project Management: From the Earliest Times to A.D. 1900. Uitgeverij Eburon, 2010.
[63] Jason Charvat, Project Management Methodologies: Selecting, Implementing, and Sup- porting Methodologies and Processes for Projects. Wiley & Sons, 2003.
[64] ISO 9000: Quality Management. Geneva: International Organization for Standardiza- tion, 2015.
[65] Mary Beth Chrissis, Michael Konrad e Sandra Shrum, CMMI for Development: Gui- delines for Process Integration and Product Improvement. Addison-Wesley Professional, 3a ed., 2011.
[66] Kathy Schwalbe, “Information Technology Project Management,” Course Tecnhnology,