ANDRÉ FRANCISCO DE MOURA

Transcrição

1 ANDRÉ FRANCISCO DE MOURA METODOLOGIA COCOMO II PARA ESTIMAR ESFORCO, PRAZO E CUSTO DE UM PROJETO DE DESENVOLVIMENTO DE SOFTWARE. Trabalho de Conclusão de Curso apresentado ao curso MBA em Gerenciamento de Projetos, de Pós- Graduação lato sensu, Nível de Especialização, da FGV/IDE como prérequisito para a obtenção do título de Especialista. Orientador: Arnaldo Lyrio Barreto MARINGÁ PR 2018

2 FUNDAÇÃO GETULIO VARGAS PROGRAMA FGV MANAGEMENT MBA EM GERENCIAMENTO DE PROJETOS O Trabalho de Conclusão de Curso Metodologia COCOMO II para estimar esforço, prazo e custo de um projeto de desenvolvimento de software, elaborado por André Francisco de Moura e aprovado pela Coordenação Acadêmica do curso de MBA em Gerenciamento de Projetos, foi aceito como requisito parcial para a obtenção do certificado do curso de pós-graduação, nível de especialização do Programa FGV Management. Maringá-PR, 01 de setembro de André Barcaui Coordenador Acadêmico Executivo Arnaldo Lyrio Barreto Orientador

3 TERMO DE COMPROMISSO O aluno André Francisco de Moura, abaixo assinado, do curso de MBA em Gerenciamento de Projetos, Turma 07 do Programa FGV Management, realizado nas dependências da FGV Maringá-PR, no período de 2016 a 2018, declara que o conteúdo do Trabalho de Conclusão de Curso intitulado Metodologia COCOMO II para estimar esforço, prazo e custo em projeto de desenvolvimento de Software, é autêntico, original e de sua autoria exclusiva. Maringá-PR, 01 de setembro de 2018 André Francisco de Moura

4 RESUMO Este trabalho investiga a inter-relação entre várias características medidas de um projeto de desenvolvimento de software, variando do modelo de projeto, tamanho e métricas usadas para a gestão do projeto. Analisando várias dimensões das características do projeto, em especial o prazo e custo. Um dos elementos basilares do processo de gerenciamento de projetos de software é o planejamento, logo, o presente estudo visa expor um conjunto de atividades que estimam o prazo e custo. A metodologia de pesquisa quantitativa desta exploração foi fundamentada em pesquisas bibliográficas de autores da área, bem como livros e portais on-line de informação. Propõe, também, uma metodologia para a construção de estimativas utilizando o modelo Constructive Cost Model II (COCOMO II). O resultado desta metodologia leva em consideração a comparação do custo e prazo com o intuito de justificar uma possível nova ótica no que concerne à elaboração de estimativas. O objetivo central deste trabalho é conceituar o uso e a importância de uma metodologia para auxiliar na estimativa dos recursos e do tempo em projetos de desenvolvimento de software, bem como servir de inspiração para novos trabalhos no tema. Assim sendo, o objetivo central do trabalho perpassa pela exposição das várias formas de estimativas de prazos e custos de um projeto de software e pela evidenciação da importância de se ter as técnicas e ferramentas corretas para alcançar estimativas mais assertivas. Como tal, o estudo traz à luz uma reflexão sobre a importância dos gerentes de projeto prestarem atenção à seleção adequada dos parâmetros do projeto, uma vez que estes são conducentes para estimativas precisas. Palavras-Chave: projeto; software; cocomo; estimativa; tempo.

5 ABSTRACT This work investigates the interrelationship between several measured characteristics of a software development project, varying from the design model, size and metrics used for project management. Analyzing various dimensions of the project characteristics, especially the time and cost. One of the basic elements of the software project management process is the planning, so the present study aims to expose a set of activities that estimate the term and cost. The methodology of quantitative research of this exploration was based on bibliographical researches of authors of the area, as well as books and online information portals. It also proposes a methodology for the construction of estimates using the Constructive Cost Model II (CoCoMo II). The result of this medology takes into account the comparison of the cost and term in order to justify a possible new perspective in the elaboration of estimates. The main objective of this paper is to outline the various forms of time and cost estimates for a software project and to highlight the importance of having the correct techniques and tools to reach more assertive estimates. As such, the study brings to light a reflection on the importance of project managers paying attention to the proper selection of project parameters, since these are conducive to accurate estimates. Keywords: project; software; cocomo; estimate; time.

6 LISTA DE ABREVIATURAS AA Porcentagem de esforço de reuso devido à avaliação e à assimilação AAF Fator de Ajuste de Adaptação AAM Multiplicador de Ajuste de Adaptação CM Porcentagem de código modificado durante o reuso CMM Modelo de Maturidade de Capacidade COCOMO Modelo de Custo Construtivo COTS Software Comercial de Prateleira CPLX Complexidade do Produto DM Porcentagem de projeto modificado durante o reuso DOCU Documentação necessária aos requisitos do projeto EDS Sistemas de Dados Eletrônicos FPA- Análise de Ponto por Função GFS Software Fornecido pelo Governo GUI Interface Gráfica para Usuário PF Pontos de Função SITE Operação Multi-site SLOC Linhas de Código Fonte USA/ESD U.S. Air Force Electronic Systems Division VEXP Experiência com Máquina Virtual

7 LISTA DE FIGURAS Figura 1 Fluxo resumido de processos do gerenciamento de projetos Figura 2 - USC.COCOMO II Figura 3 - Cone da Incerteza Figura 4 - Cartas do Planning Poker Figura 5 - Pontos de casos de uso Figura 6 Conversão UFP para LOC Figura 7 Esquecia dos passos... 38

8 LISTA DE TABELAS Tabela 1 - Produção total de tic no brasil Tabela 2 - Grupo de Processos e Área de Conhecimento Tabela 3 Medição de Esforço, Prazo e Equipe Tabela 4 Coeficiente da equação básica COCOMO Tabela 5 Fatores de custo Tabela 6 Modos de desenvolvimento de software Tabela 7 Drive de Custo Tabela 8 Conjunto de regras atribuição de valor... 37

9 Sumário 1 INTRODUÇÃO CONSIDERAÇÕES INICIAIS OBJETIVOS DELIMITAÇÃO DO ESTUDO ORGANIZAÇÃO DO DOCUMENTO FUNDAMENTAÇÃO TEÓRICA GERENCIAMENTO DE PROJETO DE SOFTWARE COCOMO II CAPACITAÇÕES ADQUIRIDAS PELO USUÁRIO CONE DA INCERTEZA ESTIMATIVA DE TAMANHO DO SOFTWARE TÉCNICA DE ESTIMATIVA DE SOFTWARE PLANNING POKER PONTOS POR USE CASE E PONTOS POR OBJETO INVESTIGAÇÕES METÓDICAS DE RISCO, ESTIMAR O ESFORÇO, PRAZO E CUSTO METODOLOGIA COCOMO E COCOMO II ORIGEM DO MODELO COCOMO Modelo básico Modelo intermediário Modelo avançado COCOMO II Engenharia de Software Baseada em Valor Fatores que Influenciam a Produtividade de Programação Modelo Application Composition Modelo Early Desing Modelo Post-arquiteture Cálculos dos valores técnicos Aplicando COCOMOII passo a passo CONCLUSÃO REFERÊNCIAS BIBLIOGRÁFICAS...42

10 1 INTRODUÇÃO 1.1 Considerações iniciais Desde o início da era dos computadores na década de 40 que a estimativa de custo de desenvolvimento de software tem sido uma tarefa importante, mas difícil. Como as aplicações de software têm aumentado em tamanho e importância, também a necessidade de precisão na estimativa de custo de software tem aumentado. Desde o início dos anos 50 que os profissionais ligados ao desenvolvimento de software e os pesquisadores da área têm tentado desenvolver métodos para estimar custos de software. Os modelos de estimativa de custos de software têm aparecido na literatura ao longo das últimas décadas, no entanto a área de pesquisa de estimativa de custos de software ainda está na sua infância (Z. Zia, Rashid e uz Zaman, 2011). Segundo a ABES ( ABES, 2017), o mercado brasileiro de tecnologia da Informação, incluindo hardware, software, serviços e exportações de TI, movimentou 39,6 bilhões de dólares em 2016, representando 2,1% do PIB brasileiro e 1,9% do total de investimentos de TI no mundo. Dentre os $ 39,6 bilhões 48% é corresponde ao Desenvolvimento de Software e Serviços, assim impulsionando o Brasil para o grupo de países com economia de um elevado grau de maturidade, onde se privilegiam o desenvolvimento de soluções e sistemas. Tabela 1 - Produção total de TIC no brasil 2016 Fonte: ABES,

11 Diante dos números expressivos a indústria de software brasileira está amadurecendo, a cada dia vem buscando novas alternativas para minimizar os desvios no custo e no cronograma de seus projetos. A estimativa do esforço para o desenvolvimento de software, pode ser utilizada como entrada para analisar o investimento do projeto. Pesquisadores e profissionais forneceram estimativa de esforço por várias décadas ao longo do processo histórico, assim, grande parte deles focou na construção de modelos formais de estimativa de esforço, como o de Putnam SLIM, COOMO 81, COOMO II, COCOTS, Kemerer e Albrecht-Gaffney, que pode ser aplicado para medir em diferentes escalas de projeto (pequeno, médio e grande). A responsabilidade dos Gerentes de Projeto de Software é, de modo geral, ver quais tarefas pretendidas relacionadas ao projeto são concluídos conforme cronograma, bem como analisar se a saída do projeto atende aos requisitos do cliente. Desta forma, os gestores devem ter uma compreensão clara do objetivo dos projetos realizados, em especial a especificação do esforço necessário, para assim concluí-los e planejar os recursos necessários. É sabido que as estimativas de software são controladas por variáveis, como tamanho, complexidade, confiabilidade requerida, disponibilidade dos níveis de qualificação de pessoal e seu fator de motivação, adequação de ferramentas de software e desenvolvimento, ambiente e restrições no cronograma, orçamento e características do software. Logo, para estimar o esforço, bem como as tarefas que envolvem os processos como um todo, se faz necessária uma análise dos requisitos, bem como observar seu desenvolvimento e, por conseguinte, investigar a inter-relação entre várias características medidas de um projeto de software. Assim, é importante compreender que o desenvolvimento de um projeto de software contém mais do que simples planos de testes, redes, verificação aproximada do número de linhas de código, plataforma na qual o software deve ser desenvolvido e até mesmo a quantidade de trabalho do tempo gasto com gestão e organização das equipes de desenvolvimento, haja vista que se torna necessária uma metodologia para auxiliar na estimativa dos recursos e do tempo dos projetos. 11

12 1.2 Objetivos O objetivo deste trabalho é conceituar o uso e a importância de uma metodologia para auxiliar na estimativa dos recursos e do tempo em projetos de desenvolvimento de software, bem como servir de inspiração para novos trabalhos no tema. Desta forma, faz-se necessária a compreensão da inter-relação entre várias características medidas de um projeto de desenvolvimento de software, variando do modelo de projeto, tamanho e métricas usadas para a gestão do projeto. 1.3 Delimitação do estudo Para delimitação do estudo, faz-se necessário trazer à luz de forma clara o cerne do trabalho, assim, mesmo existindo uma vasta bibliografia sobre o tema, este trabalho será delimitado no estudo da metodologia COCOMO II, aplicada na indústria de software brasileira. 1.4 Organização do documento. Este trabalho está organizado em 4 capítulos incluindo a introdução, sendo os demais capítulos organizados como a seguir: 2. Fundamentação teórica. 3. Metodologia COCOMO e COCOMO II, será abordado a fundamentação da metodologia, seu princípios e aplicabilidade. 4. Conclusão. No embasamento teórico, vão ser abordados elementos de contextualização da proposição do estudo, tais como o gerenciamento de projeto de software, estimativa de software, Investigações metódicas de risco, estimar o esforço, prazo e custo, dentre outros. 12

13 2 FUNDAMENTAÇÃO TEÓRICA. 2.1 Gerenciamento de Projeto de Software. De acordo com Casey(2010), o gerenciamento de um projeto de software (GPS) é o processo de tomar decisões que envolvem o uso de recursos, tantos materiais como humanos, para coordenar, controlar e realizar atividades, temporárias, com o objetivo de fornecer um resultado. Assim, conforme Enami (2006) e Casey (2010), a integração desses recursos em um contexto específico de desenvolvimento de software não é uma tarefa fácil e exige uma gestão e esforço coordenado das pessoas envolvidas. Se faz necessário entender, portanto, que as análises dos dados do projeto devem ser realizadas antes de se utilizar qualquer um dos métodos disponíveis para calibrar os dados de forma significativa de acordo com os requisitos de cada método utilizado para estimar. (CASEY, 2010) De acordo com Enami (2006), o esforço estimado terá um impacto direto no sucesso ou no fracasso do projeto. Logo, as estimativas são críticas para todos os envolvidos no projeto, como o gerente de projeto. Assim, de acordo com o mesmo autor, a estimativa de esforço é uma parte da Engenharia de Software que descreve a coleção de técnicas aplicáveis a uma abordagem de engenharia para o desenvolvimento e suporte de software. As atividades de software incluem gerenciamento, cálculo de custos, planejamento, modelagem, análise, especificando, projetando, implementando, testando e mantendo. Portanto, técnicas de estimativa de esforço deve incluir os vários parâmetros para cada uma das atividades acima e a maioria dos parâmetros são intangíveis. Frente a essa afirmativa, se faz necessário o julgamento especializado, uma vez que este desempenha um papel importante na estimativa do esforço, conforme relata Casey (2010). Ainda segundo o mesmo autor, o trabalho de otimização do processo de estimativa e a pesquisa de estimativa futura devem se concentrar na melhoria dos processos de estimativa de esforço baseados em julgamento, e não em modelos formais de estimativa. Os métodos, de modo geral, usam o tamanho do software em termos de linha de código ou pontos de função. Daí o esforço da estimativa abaixo ou acima da estimativa porque as informações geralmente são incompletas e incertas. 13

14 A estimativa real do projeto é um objetivo importante da comunidade de engenharia de software. Muitos especialistas, tais como Casey (2010), sugerem que é apropriado usar um ou mais métodos ao estimar ou prever o esforço de desenvolvimento. Portanto, fazer estimativas de tempo e mão de obra para um projeto é um desafio tanto para equipes de projeto, quanto para os gerentes de processo. O GPS surgiu com base no gerenciamento de projeto (GP) de outras áreas já maduras, nas quais, técnicas foram adaptadas em uma sequência de estágios que envolvem os aspectos e questões do processo de desenvolvimento de um projeto de software, desde o estabelecimento inicial dos conceitos até o artefato de programação (ENAMI, 2006) Conforme afirma Fernandes (2008), alguns modelos são originais e outros são derivados e/ou evoluídos de outros modelos. O PMBoK, que é um guia reconhecido de gestão de projetos que descreve normas, métodos, processos e práticas estabelecidas para gerenciar projetos de qualquer natureza, foi utilizando no auxílio da exploração deste estudo. Os principais objetivos do PMBoK são as boas práticas da aplicação das ferramentas e técnicas para aumentar as chances de sucesso de um projeto e o vocabulário comum utilizado pelos profissionais da área de gerenciamento de projetos. Mesmo não sendo uma metodologia de gerenciamento de projetos, o PMBoK incorpora processos e atividades conforme tabela 2 e figura 1, que suprem as necessidades de todas as etapas ou fases do ciclo de vida de um projeto, sendo estas definidas por Keelling (2002) como conceituação, planejamento, implementação e conclusão. Dessa forma é plausível e beneplácito a adoção do PMBoK no planejamento dos recursos humanos, riscos e custos. 14

15 Tabela 2 - Grupo de Processos e Área de Conhecimento Fonte PMTECH,

16 Figura 1 Fluxo resumido de processos do gerenciamento de projetos Fonte: PMTECH, 2017 Outro fator que impulsionou a utilização deste corpo de conhecimento é sua característica genérica e aplicada a todos os tipos de projetos, inclusive projetos de desenvolvimento de software. 2.2 COCOMO II capacitações adquiridas pelo usuário De modo geral, conforme afirma Fernandes (2008), existem três tipos de estimativas. A primeira, geralmente é a estimativa que será de duas a três vezes a ordem de magnitude do valor real. Mesmo que estas estimativas estejam muito longe do valor real, elas são muito valiosas porque os resultados vão dar uma ideia de como está o andamento do projeto. Logo, faz-se os apontamentos concernentes à necessidade financeira, recursos e tempo. O segundo tipo de estimativa é geralmente chamado de estimativa aproximada e está possui a possibilidade quando se trabalha em um bem de observar e 16

17 compreender as necessidades quanto a familiarização com o domínio da tecnologia empregada. O terceiro tipo de estimativa conhecida como estimativa justa é a possibilidade da previsão temporal frente ao que precisa ser feito. É importante compreender, conforme afirma Fernandes (2008), que nenhuma técnica é a melhor para todas as situações, e que uma comparação cuidadosa dos resultados de várias abordagens é o melhor caminho para produzir a estimativa. Deste modo, partilhando da visão do mesmo autor, para o fornecimento de uma base para a melhoria dos métodos de estimativa de software e pesquisa, se faz necessário discutir os pontos fortes e fracos de várias estimativas de software. Assim, as organizações, de modo geral, buscam utilizar metodologias que atendem suas respectivas demandas. De acordo com Huzita et al. (2006), as estimativas de software com o COCOMOII, possui, em sua essência, sobre o gestor qualidades necessárias e capacitações adquiridas, tais como: estabelecer diferenças entre estimar, fazer um compromisso e estabelecer uma meta. Este último permite que o participante tome uma posição de alguém que usa a técnica para fornecer uma estimativa, em contraste com alguém que leva mais tempo e recursos. Na figura a seguir, pode-se observar a tela-base da área de trabalho do USC COCOMO II: Figura 2 - USC.COCOMO II Fonte: 17

18 É importante compreender, ainda de acordo Huzita et al. (2006), que o participante deve ser capaz de apresentar as opções e os cenários para escolher a melhor opção para os responsáveis por estabelecer metas ou assumir compromissos com base em uma base sólida e ferramentas de gerenciamento de conhecimento. Diferenciar uma estimativa direta e um modelo de estimativa paramétrica. Especificamente em relação a esses termos, uma vez que são discutidas as características entre eles com base em modelos determinísticos e aqueles baseados em modelos estocásticos. (HUZITA et al 2006) Transformar as faixas de tempo e esforço que podem ser otimistas, mais prováveis e pessimistas fornecidas por modelos estocásticos de estimativa ou pela estimativa direta em um determinado número de horas ou meses com relação à probabilidade. (HUZITA, et al. 2006) Diferenciar os três modelos que compõem o COCOMO II: Composição de Aplicações, Design Antecipado e Pós-Arquitetura; e selecionando o mais adequado de acordo com o nível de informação. (HUZITA et al. 2006) Interpretar os resultados do modelo em termos de quais atividades do estágio no ciclo de vida são incluídas nas estimativas geradas. O indivíduo também deve ser capaz de interpretar quais categorias de trabalho são consideradas nos resultados, e que pontos o modelo deve ser lido como uma referência de mercado e quais devem ser adaptados às condições locais onde serão aplicados. (HUZITA et al. 2006) De acordo com Keelling (2002), o usuário, portanto, deve ser capaz de: modificar as porcentagens de tempo e esforço de acordo com a fase de supervisão gerencial; escolher a métrica de melhor qualidade para avaliar e adaptar o modelo considerando suas características e métricas que são apropriadas para a política organizacional onde o modelo será usado; definir uma política local com a interpretação de aspectos subjetivos das diretrizes para avaliação qualitativa de fatores secundários, como custos de emprego, produto, plataforma e processo. 2.3 Cone da Incerteza Conforme afirma McConnell (1998) em função das incertezas que rodeiam os estimadores no processo inicial do projeto, a estimativa assertiva nesta etapa inicial é praticamente impossível. Desta forma, usa-se o cone da incerteza, está metodologia 18

19 traz a luz uma explanação em forma de espectro sobre a execução do projeto. Desta forma, a figura a seguir sintetiza a variação na estimativa do escopo do projeto. Figura 3 - Cone da Incerteza Fonte: McConnell (1998) Pode-se observar na figura 2 que a variação na estimativa de escopo do projeto (esforço, custo, características) são compostas por um conceito inicial, em seu plano temporal é perceptível notar os elementos que compõem o processo da estimativa, dentre eles: a definição de produto aprovada, o projeto de interface de usuário completo, o projeto detalhado completo, dentre outros. 2.4 Estimativa de tamanho do software A Análise de Ponto de Função -FPA foi originalmente desenvolvido por Allan Albrecht no final da década de 1970 na IBM, e foi desenvolvido pelo Grupo Internacional de Usuários de Pontos de Função (IFPUG). O FPA fornece um conjunto de regras para dimensionar funcionalmente o produto de trabalho de software. Este produto de trabalho é a saída de novos projetos de desenvolvimento e aprimoramento de softwares. (HUZITA et al 2006) De acordo com Keelling (2002), a análise de pontos de função é um método de medição de tamanho funcional. Ele avalia a funcionalidade fornecida aos usuários, com base na visão externa do usuário dos requisitos funcionais. Ele mede a visão 19

20 lógica de uma aplicação em comparação com a medição da visão implementada fisicamente ou da visão técnica interna. A FPA mede esses requisitos funcionais em termos de: Transações comerciais (Processos) (por exemplo, inquirir no registro do cliente) que o usuário pode executar usando o software. Dados de negócios (Grupos de dados) (por exemplo, arquivo do cliente) que o software pode armazenar e acessar (KEELLING, 2002). Conforme afirma Martins (2007), a atividade de executar a Análise de Pontos de Função é frequentemente chamada de 'Contagem de Pontos de Função' e envolve a identificação, classificação e ponderação de cada um desses componentes de Grupo de Dados e Processos. As ponderações são combinadas para fornecer o tamanho funcional como uma contagem de pontos de função não ajustada(ufp). Este é o tamanho funcional conforme definido pelo padrão ISO / IEC 20926, o IFPUG CPM 4.3 e ISO / IEC Ainda de acordo com Martins (2007), antes do IFPUG 4.3, a FPA incluiu uma etapa opcional adicional que envolve a avaliação dos recursos técnicos e de qualidade incorporados no produto de software e o ajuste do Tamanho Funcional de acordo. O resultado é referido como a Contagem de Pontos de Função Ajustada (AFP). A técnica de Análise de Pontos de Função é usada para avaliar a funcionalidade fornecida pelo software, um 'ponto de função não ajustado' (UFP) é a unidade de medida. (MARTINS, 2007) Conforme Sommerville (2007), depois de ter uma contagem de pontos de função, um usuário pode usar a medida resultante do produto de software, seja por conta própria ou combiná-la com outras medidas para desenvolver os seguintes indicadores de desempenho do projeto: O escopo do produto de desenvolvimento de software (por exemplo, unidades de software a serem entregues ou trabalhadas) Indicadores de qualidade (por exemplo, o número de defeitos por unidade de software) Produtividade (por exemplo, o custo por unidade de software) 20

21 Desempenho (por exemplo, recursos de pessoal por unidade de software) Logo, compreende-se que a métrica FPA mede o tamanho do software pela quantificação de sua funcionalidade externa, fundamentada no projeto lógico, abrangendo, portanto, a funcionalidade específica requerida pelo usuário (SOMMERVILLE, 2007). Essa métrica possibilita a medição do tempo e do custo de um projeto de software, bem como essa métrica possibilita quais os impactos que o projeto pode sofrer com o incremento de recursos novos, gerando, assim, uma otimização do gerenciamento do projeto pela organização, obtendo-se assertividade no processo. Contudo, apesar de a FPA ser a métrica de tamanho mais comum no mercado, muitos estudiosos fazem críticas a sua adequação à estimativa, tais como os projetos Orientados a Objetos (OO), uma vez que a FPA foi criada em 1979, com base nos conceitos das técnicas de análise e projetos estruturados, diferentes dos conceitos baseados na tecnologia OO (MARTINS, 2007). 2.5 Técnica de Estimativa de Software Planning Poker O Planning Poker basicamente se trata de uma obtenção da estimativa através de um jogo de cartas, que, conforme relata Alves (2012), deve possibilitar que todos os membros da equipe de desenvolvimento tenham sua participação, colocando a sua visão de complexidade, considerando o fator tempo e esforço para pontuar um cartão e após juntos chegar a um denominador comum por meio de uma conclusão em grupo. No Planning Poker cada membro tem um baralho de 13 cartas, numeradas em uma sequência similar a encontrada nos números de Fibonacci., havendo também uma carta com o símbolo de interrogação que é representada pelo estimador que não está mais apto a estimar, bem como tem a carta da xícara de café para sugerir a pausa. Durante o Planning Poker realiza-se rodadas visando obter a estimativa de um cartão que possui uma tarefa a desenvolver. O mediador poderá interferir nas diferenças que surgirem durante as rodadas. Já o Product Owner, é o responsável por explicar o que deverá ser desenvolvido. 21

22 Figura 4 - Cartas do Planning Poker Fonte: Pontos por Use Case e pontos por objeto É uma técnica de estimativa de software usada para prever o tamanho do software para projetos de desenvolvimento de software. O UCP (user case point) é usado quando as metodologias da Linguagem de Modelagem Unificada (UML) e do Rational Unified Process (RUP) estão sendo usadas para o design e desenvolvimento de software. O conceito de UCP é baseado nos requisitos para o sistema que está sendo escrito usando casos de uso, que fazem parte do conjunto de técnicas de modelagem da UML. O tamanho do software é calculado com base em elementos dos casos de uso do sistema com fatoração para considerar considerações técnicas e ambientais. O UCP para um projeto pode então ser usado para calcular o esforço estimado para um projeto. (MARTINS, 2007) Segundo SOMMERVILLE (2007) o método para determinar a estimativa de tamanho para desenvolver um software é baseado em um cálculo com os seguintes elementos: 22

23 UAW peso do ator não ajustado; o tamanho em pontos do software que representa o número e a complexidade dos atores. UUCW peso do caso de uso não ajustado; - o tamanho em pontos do software que considera o número e a complexidade dos casos de uso. TCF fator de complexidade técnica; fator usado para ajustar o tamanho com base em considerações técnicas. EFC fator de complexidade ambiental; fator que é usado para ajustar o tamanho com base em considerações ambientais. Uma vez que os quatro elementos anteriores foram calculados, a estimativa do tamanho final pode ser calculada. Esse número final é conhecido como Pontos de Caso de Uso ou UCP para um projeto de desenvolvimento de software. (TEIXEIRA et al 2007) Figura 5 - Pontos de casos de uso Fonte: Teixeira et al (2007) Cabe ressaltar que na métrica pontos por objeto é calculada com a utilização de uma contagem da quantidade de telas, relatórios e componentes que serão necessários para construir a aplicação. 23

24 Logo cada objeto é sistematizado em três níveis de complexidade: a porcentagem de reuso, a produtividade e o esforço que é estimado usando-se os pontos por objeto e a produtividade. E = NOP/PROD. (TEIXEIRA et al. 2007) 2.7 Investigações metódicas de risco, estimar o esforço, prazo e custo É sabido que cada gerente de projeto possui dever de realizar investigações metódicas de risco, a fim de evitar custos e comprometer os prazos. A palavra risco originado do termo italiano Risicare significa ousar. Desta forma, o risco, em seu conceito básico, é a possibilidade de perda ou dano. Para tentar eliminar o risco de um processo, é essencial que os riscos assumidos sejam os riscos certos. (TEIXEIRA, et al. 2007) Assim sendo, o tipo de riscos no desenvolvimento de software são riscos tecnológicos - risco de escolha, hardware e software e a obsolescência, riscos de pessoas, capacidade, habilidade, maturidade, dentre outros, bem como os riscos no ambiente de desenvolvimento, tais como as organizações de usuários, riscos de requisitos, estimativa de tamanho, esforço e cronograma do projeto. (TEIXEIRA, et al. 2007) Um dos processos fundamentais do gerenciamento de projetos de software é o planejamento, um conjunto de atividades que visam estimar tempo e recursos necessários ao projeto, definir tarefas e preparar uma estrutura para o gerenciamento [Humphrey, 1989]. Para que um projeto de software possa ser efetivamente planejado, estimativas de esforço, prazo e custos, deve ser realizada logo no início, através de um processo bem definido o processo de estimativa de custo de software [Paulk et. al., 1993]. Para estimar esforço e prazo, é preciso que seja selecionada uma abordagem para a obtenção de estimativas. 24

25 Tabela 3 Medição de Esforço, Prazo e Equipe Fonte: Mattar (2009) Importante compreender que o COCOMOII considera que o mês é equivalente a 152 horas de trabalho. 25

26 3 METODOLOGIA COCOMO E COCOMO II O Modelo de Custo Construtivo (COCOMO) é um modelo de estimativa de custo de software processual desenvolvido por Barry W. Boehm. 3.1 Origem do modelo. De acordo com Martins (2007), o modelo de custo construtivo foi desenvolvido por Barry W. Boehm no final dos anos 1970 e publicado no livro de 1981 de Boehm, Software Engineering Economics como um modelo para estimar esforço, custo e cronograma para projetos de software. Ele se baseou em um estudo de 63 projetos na TRW Aerospace, onde Boehm era diretor de pesquisa e tecnologia de software. O estudo examinou os projetos que variam em tamanho de 2000 a linhas de código, e linguagens de programação que variam de montagem para PL / I. Esses projetos foram baseados no modelo cascata de desenvolvimento de software, que foi o processo de desenvolvimento de software predominante em (MARTINS, 2007) Ainda de acordo com Martins (2007), as referências a este modelo geralmente o chamam de COCOMO 81. Em 1995, o COCOMO II foi desenvolvido e finalmente publicado em 2000 no livro Software Cost Estimation with COCOMO II. O COCOMO II é o sucessor do COCOMO 81 e é considerado mais adequado para estimar projetos modernos de desenvolvimento de software, fornecendo suporte para processos de desenvolvimento de software mais recentes e foi ajustado usando um banco de dados maior de 161 projetos. A necessidade do novo modelo surgiu na medida em que a tecnologia de desenvolvimento de software passava do processamento em lote de mainframe e de um dia para o outro para o desenvolvimento de desktops, a reutilização de código e o uso de componentes de software disponíveis no mercado. De acordo com Tait (2001), o COCOMO consiste em uma hierarquia de três formas cada vez mais detalhadas e precisas. O primeiro nível, COCOMO Básico, é bom para estimativas rápidas, precoces e de grande magnitude dos custos de software, mas sua precisão é limitada devido à falta de fatores para explicar a diferença nos atributos do projeto (Drivers de Custos). O COCOMO intermediário leva em consideração esses fatores de custo e o COCOMO detalhado também considera a influência das fases individuais do projeto. (TAIT, 2001) 26

27 3.2 COCOMO 81 Boewn em seu trabalho caracterizou os modos de desenvolvimento de software em Orgânico, Semi-Destacado e Embutido. Essa categorização será utilizada nos modelos Básico, Intermediário e Avançado. Orgânicos; equipes "pequenas" com experiência "boa" trabalhando com requisitos "menos rígidos", em ambiente conhecido e estável. Semi-Destacado; equipes "médias" com experiência mista trabalhando com um mix de requisitos rígidos e menos rígidos. Embutidos; desenvolvidos dentro de um conjunto de restrições "rigorosas". Ha também uma combinação de projetos orgânicos e semi-destacados (hardware, software, operacional) (TAIT, 2001) Modelo básico O COCOMO básico calcula o esforço de desenvolvimento de software e custo como uma função do tamanho do programa. O tamanho do programa é expresso em milhares de linhas de código fonte (TAIT, 2001) As equações básicas COCOMO assumem a forma: Esforço aplicado (E) = ab (KLOC) bb [homem-meses]; Tempo de Desenvolvimento (DA) = cb (Esforço Aplicado) db [meses]; Pessoas requeridas (P) = Esforço Aplicado / Tempo de Desenvolvimento; KLOC é o número estimado de linhas entregues (expressas em milhares) de código para o projeto. Os coeficientes Ab, Bb, Cb e Db são dados seguir na tabela 4. 27

28 Tabela 4 Coeficiente da equação básica COCOMO Modos de Desenvolvimento A b B b C b D b Orgânico ,5 0,38 Geminada 3,0 1,12 2,5 0,35 Embutido 3,6 1,2 2,5 0,32 Fonte: Tait, 2001 Assim, conforme afirma Tait (2001), o COCOMO básico é bom para estimativas rápidas de custos de software. No entanto, ele não leva em conta diferenças em restrições de hardware, qualidade e experiência de pessoal, uso de ferramentas e técnicas modernas e assim por diante Modelo intermediário O COCOMO intermediário computa o esforço de desenvolvimento de software como uma função do tamanho do programa e um conjunto de "direcionadores de custo" que incluem avaliação subjetiva de atributos de produto, hardware, pessoal e projeto. (MARTINS,2007) Essa extensão considera um conjunto de quatro "drivers de custo", cada um com vários atributos subsidiários: atributos do produto; extensão de confiabilidade necessária do software; tamanho do banco de dados do aplicativo; complexidade do produto; atributos de hardware; restrições de desempenho em tempo de execução; restrições de memória; volatilidade do ambiente de máquina virtual; tempo de reviravolta necessário; atributos pessoais; capacidade analista; capacidade de engenharia de software; experiência em aplicações; experiência de máquina virtual; experiência em Linguagem de Programação; atributos do projeto; uso de ferramentas de software; aplicação de métodos de engenharia de software e agenda de desenvolvimento obrigatória. (MARTINS, 2007) Cabe ressaltar que cada um dos 15 atributos recebe uma classificação em uma escala de seis pontos que varia de "muito baixa" a "extra alta" (em importância ou valor). Um multiplicador de esforço da tabela abaixo aplica-se à classificação. O 28

29 produto de todos os multiplicadores de esforço resulta em um fator de ajuste de esforço (EAF). Valores típicos para EAF variam de 0,9 a 1,66.( LEÃO, 2017 ) Tabela 5 Fatores de custo Fonte: LEÃO, 2017 A fórmula intermediária COCOMO agora assume a forma: E = ai (KLoC) (bi). (EAF) Onde E é o esforço aplicado em pessoas-meses, o KLoC é o número estimado de milhares de linhas de código entregues para o projeto, e o EAF é o fator calculado acima. O coeficiente ai e o expoente bi são dados na tabela a seguir. 29

30 Tabela 6 Modos de desenvolvimento de software Modos de ai bi Desenvolvimento Orgânico 3,2 1,05 Semi-Destacado 3,0 1,12 Embutido 2,8 1,20 Fonte: LEÃO, Modelo avançado De acordo com Martins (2007) O COCOMO avançado também conhecido como detalhado incorpora todas as características da versão intermediária com uma avaliação do impacto do direcionador de custo em cada etapa (análise, projeto, etc.) do processo de engenharia de software. O modelo detalhado usa diferentes multiplicadores de esforço para cada atributo do driver de custo. Esses multiplicadores de esforço sensíveis à fase são cada um para determinar a quantidade de esforço necessária para concluir cada fase. Em COCOMO avançado, todo o software é dividido em módulos diferentes e, em seguida, aplica-se o COCOMO em diferentes módulos para estimar o esforço e, então, somar o esforço.(martins, 2007) O esforço é calculado como uma função do tamanho do programa e um conjunto de direcionadores de custos é dado de acordo com cada fase do ciclo de vida do software.(sommerville, 2007) Um cronograma detalhado do projeto nunca é estático. As seis fases do COCOMO detalhado são: planejamento e requisitos; projeto de sistema; projeto detalhado; código do módulo e teste e integração e teste. 3.3 COCOMO II Quando os profissionais envolvidos no desenvolvimento, manutenção ou gerenciamento de software precisam fornecer uma estimativa técnica do tempo ou 30

31 esforço necessário para uma nova iniciativa, eles evitam fazer isso. Isso acontece quando há uma confusão sobre qual técnica, estimativa ou determinação de uma meta ou compromisso deve ser usada. Quando há uma resposta, o mais comum é oferecer um único ponto, uma data ou um número de horas. Respostas como aquelas baseadas em impressões, apenas aumentam a confusão entre termos como estimativa, meta ou comprometimento gerando sérios prejuízos no processo. (MARTINS, 2007) COCOMO II (Modelo de Custo Construtivo) é uma alternativa para incluir componentes de incerteza de acordo com o nível de informação disponível. É um modelo paramétrico que estabelece equações matemáticas que descrevem as relações entre o tamanho do software - fator de custo primário geralmente representado em termos de pontos de função - e outros fatores secundários que buscam identificar características de um produto, processo, pessoas e plataforma. (MARTINS, 2007) Esses fatores são conhecidos como drivers de custo. Alguns deles têm efeito proporcional e outros têm efeito exponencial. O modelo fornece uma estrutura completa para determinar os fatores locais de produtividade (constantes de produtividade) com base nos dados de tempo e esforço em projetos anteriores. Uma das principais vantagens do COCOMOII é fornecer estimativas de tempo e esforço e, a partir disso, sugerir o tamanho da equipe. (SOMMERVILLE, 2007) Boehm foi um dos primeiros pesquisadores que abordou sistematicamente o campo da produtividade de software. Seu modelo de estimativa de custo COCOMO - agora COCOMO II - é um conhecimento padrão de engenharia de software. Nesse modelo, ele define um conjunto de fatores que influenciam a produtividade, como a confiabilidade necessária ou a capacidade dos analistas. Esses fatores foram amplamente reutilizados em outras abordagens de produtividade semelhantes. O resto do modelo é baseado em pontos de função e, finalmente, em linhas de código de origem(loc). As limitações do LOC como medida de produtividade são bem conhecidas. (MARTINS, 2007) Assim como o seu antecessor é dividido em três modelos, o COCOMO II possui o Modelo Application Composition, o Modelo Early Desing e o Modelo Postarquiteture, conforme será explorado nos subtópicos a seguir. 31

32 3.3.1 Engenharia de Software Baseada em Valor Vários pesquisadores propuseram a engenharia de software orientada para a economia ou baseada em valor como um paradigma importante em pesquisas futuras de engenharia de software. Boehm e Huang ressaltam que não é importante apenas acompanhar os custos em um projeto de software, mas também o valor real ganho, ou seja, o valor para o cliente. Eles explicam que é importante criar o business case de software e mantê-lo atualizado. Em essência, a engenharia de software baseada em valor se concentra no valor do cliente, principalmente medido em unidades monetárias. (SOMMERVILLE, 2007) Fatores que Influenciam a Produtividade de Programação Provavelmente, há muitos fatores que influencia na produtividade de programação de indivíduos e equipes. Por exemplo, o processo de desenvolvimento de software usado provavelmente influencia a eficácia e a eficiência de uma equipe dos programadores de software influenciam os estilos de codificação usados que, por sua vez, influenciam a produtividade dos programadores Modelo Application Composition De acordo com Martins (2007) O setor de Composição de Aplicativos lida com aplicativos que são muito diversificados para serem manipulados por soluções préembaladas, mas que são suficientemente simples para serem compostas de componentes interpenetráveis. Componentes típicos serão construtores de interface de usuário gráfica (GUI), gerenciadores de objetos ou banco de dados, middleware para processamento ou transação distribuída processamento, manipuladores de hipermídia, localizadores de dados inteligentes e componentes específicos de domínio, como financeiros, médicos ou industriais. pacotes de controle de processo. A maioria das grandes empresas terá grupos para compor esses aplicativos, mas muitas empresas especializadas em software fornecerão aplicações compostas em contrato. Estas vão desde empresas grandes e versáteis, até pequenas especializando-se em áreas de especialidade como o apoio à decisão ou 32

33 processamento de transações, ou em domínios de finanças ou manufatura. (FLICK, 2002) O modelo Application Composition, projetado para estimar projetos desenvolvidos com o uso de ferramentas GUI modernas, baseando-se na contagem de Pontos de Objeto, o modelo Early Design, para estimativas preliminares de custo e duração de projetos, antes que a arquitetura completa do sistema tenha sido projetada, utilizando um pequeno conjunto de direcionadores de custo, e o modelo Post-Architecture, o modelo mais detalhado, para estimar projetos após a definição completa da arquitetura do sistema (JÚNIOR; SANCHES, 2000 p. 16) Pode-se observar, conforme relatam Júnior e Sanches (2000), o modelo Application Composition é um modelo desenvolvido para a estimativa de projetos que foram concebidos com a utilização de ferramentas novas que possuem seus elementos basilares na contagem de pontos de objeto Modelo Early Desing De acordo com Flick, (2002), o modelo Early Design envolve a exploração de arquiteturas de software / sistemas alternativos e conceitos de operação. Neste estágio, não é geralmente conhecido o suficiente para suportar a estimativa de custo de dados finos. Conforme relatam Júnior e Sanches (2000): O modelo Early Design permite que o tamanho da aplicação possa ser estimado em pontos de função não ajustados, posteriormente convertidos em linhas de código pelo modelo. Pontos de função podem ser utilizados como boas estimativas porque são baseados em informações que estão disponíveis logo no início do ciclo de vida do projeto. (JÚNIOR; SANCHES, 2000 p. 21) As principais variáveis de entrada para o modelo são: o tamanho estimado do sistema e os direcionadores de custo. Desta forma pode-se perceber, conforme o entendimento de Júnior e Sanches (2000), que o grau de detalhes que o modelo utiliza é consistente com o nível de informações disponíveis e com o nível de precisão necessário nessa fase. O modelo também utiliza a conversão de UFP pontos de 33

34 função não ajustados para LOC linhas de código que varia conforme linguagem utilizada no projeto, vide figura 6. Figura 6 Conversão UFP para LOC Fonte: PRESSMAN, 2005, p Modelo Post-arquiteture O modelo pós-arquitetura envolve o desenvolvimento e a manutenção reais de um produto de software. Esta etapa continua de maneira mais econômica se uma 34

35 arquitetura de ciclo de vida de software tiver sido desenvolvida; validado com relação à missão do sistema, conceito de operação e risco; e estabelecido como a estrutura para o produto. O modelo COCOMO II correspondente sobre a mesma granularidade dos modelos COCOMO e Ada COCOMO anteriores. Utiliza instruções de origem e / ou pontos de função para dimensionamento, com modificadores para reutilização e quebra de software; um conjunto de 17 direcionadores de custos multiplicativos; e um conjunto de 5 fatores que determinam o expoente de dimensionamento do projeto. Esses fatores substituem os modos de desenvolvimento. (MARTINS, 2007) É importante compreender que o COCOMO II fornece o modelo de pósarquitetura que deve ser considerado como hipóteses de trabalho atuais sobre as formas mais eficazes para o COCOMO II. Eles serão, portanto, sujeito a revisão com base na análise de dados subsequente. A análise de dados também deve permitir a calibração adicional dos relacionamentos entre pontos de objeto, pontos de função e linhas de código de origem para vários idiomas e sistemas de composição, permitindo flexibilidade na escolha de parâmetros de dimensionamento. Sintetizando: o COCOMO II fornece a seguinte série de modelos de três estágios para a estimação do Application Generator, Projetos de software de integração de sistemas e infraestrutura: 1. As fases iniciais ou ciclos de espiral geralmente envolvem prototipagem, usando o modelo de Composição de Aplicação capacidades. O modelo COCOMO II Application Composition suporta essas fases e quaisquer outras atividades de prototipagem ocorrendo mais tarde no ciclo de vida. 2. As próximas fases ou ciclos espirais geralmente envolverão exploração de alternativas arquitetônicas ou desenvolvimento incremental estratégias. Para apoiar essas atividades, o COCOMO II fornece um modelo de estimativa inicial chamado de modelo Early Design. O nível de detalhe deste modelo é consistente com o nível geral de informação disponível e com o nível geral de estimativa. 3. Uma vez que o projeto esteja pronto para desenvolver e sustentar um sistema em campo, ele deve ter uma arquitetura de ciclo de vida, que forneça o apoio necessário. 35

36 Conforme já mencionado no presente tópico, existem 17 direcionadores de custos (drive de custos) utilizados no modelo COCOMO II Post- Arquiteture, conforme pode-se observar na figura a seguir, esses multiplicadores podem ser divididos em subgrupos categorizando 4 partes Produto, Plataforma, Pessoal, Projeto. Tabela 7 Drive de Custo 36

37 3.3.6 Cálculos dos valores técnicos Para auxiliar na atribuição dos valores do fator, Symons (2001), propôs um agrupamento de regras, conforme o quadro a seguir: Tabela 8 Conjunto de regras atribuição de valor 0 SE O FATOR NÃO ESTÁ PRESENTE OU NÃO TEM INFLUÊNCIA SE PRESENTE 1 SE O FATOR TEM INFLUÊNCIA INSIGNIFICANTE 2 SE O FATOR TEM INFLUÊNCIA MODERADA 3 SE O FATOR TEM INFLUÊNCIA MÉDIA 4 SE O FATOR TEM INFLUÊNCIA SIGNIFICATIVA 5 SE O FATOR TEM FORTE INFLUÊNCIA Fonte: Symons (2001) 37

38 Conforme pode-se observar na tabela 8 os fatores estão dispostos em uma escala ordinal, desta forma, se faz necessária a ponderação sobre a atribuição de diferente escores para tais fatores em uma mesma circunstância Aplicando COCOMO II passo a passo. A seguir serão apresentados os passos a serem seguidos para utilização do método COCOMO II para se obter a estimativa do Custo, Esforço e Tempo para o projeto ou atividade a ser desenvolvida, o que, de acordo com a fase em que o projeto se encontra, utiliza-se o modelo adequado. Figura 7 Esquecia dos passos Fonte : LEÃO, Passo Calibrar o COCOMO II para a base histórica de projetos obtida, salvando os coeficientes em um modelo; - esta etapa é comum a todos os tipos de projeto e aos 3 modelos. 38

39 2 Passo Aplicar a fórmula para o cálculo do esforço de desenvolvimento, esta etapa é dependente do modelo de desenvolvimento que estiver sendo utilizado, e isto é definido de acordo com o tipo de projeto. Utilizando o modelo Application Composition Computar o número de Pontos de Objeto (OP Object Points) para o sistema inteiro; Estimar o percentual de reutilização de código e computar o número de Novos Pontos de Objeto (NOP New Object Points) requeridos; Determinar a taxa de produtividade (PROD), que é o número de novos pontos objetos por mês que a equipe de projeto pode produzir; Estimar o esforço através da equação E = NOP/PROD Utilizando o modelo Early Design Calcular pontos de função não ajustados (UFP) para o sistema; Converter os UFP para KLOC, usando o fator de ajuste específico do ambiente de desenvolvimento; Ajustar a estimativa inicial através do conjunto de drivers de custo; Vide tabela 7 RCPX - Complexidade e confiabilidade do Software, RUSE Reuso requerido PDIF - Dificuldade da plataforma, PREX - Experiência da equipe PERS - Capacidade da equipe, FCIL - Facilidades disponíveis, SCED - Cronograma Estimar o esforço E como: E = A x KSLOC^b X Π(drivers de custo) Utilizando o modelo Post-Architecture A fórmula de estimativa para este modelo é dada pela equação: E = a x A x KSLOC^b x Π (drivers de custo); O fator a é determinado pelo tipo de projeto; Tabela 4 Coluna Aa. O fator A determina o percentual de reutilização de código; e possui o valor de 2,94, conforme a calibração do COCOMO II O expoente b é derivado da soma dos 5(cinco) fatores de escala utilizando a fórmula: b = 1,01 + 0,01 x Wi, 39

40 Onde cada fator W possui um intervalo de valores entre 5 (baixo) e 0 (alto). Os fatores são: PREC - Precedência, FLEX - Flexibilidade de desenvolvimento, RESL - Resolução do risco/arquitetura, TEAM - Coesão da equipe, PMAT - Maturidade do processo. 3 Passo Aplicar o cálculo do tempo de desenvolvimento, e estimar o prazo. TDEV = C x {PM ^ F} Onde: C é uma constante multiplicativa para tempo de desenvolvimento. (C = 3.67 conforme calibragem do COCOMO II ) F = [D x (B )] D é uma constante multiplicativa para tempo de desenvolvimento. (D = 0.28 conforme calibragem do COCOMO II) B assume o mesmo valor da fórmula para cálculo de esforço Somatório dos Fatores de Escala PM é o esforço calculado TDEV é expresso em quantidade de meses. 4 Passo A Equipe Média é obtida através da divisão do Esforço pelo Prazo. O COCOMO II considera um mês de trabalho equivalentes a 152 horas de trabalho, excluídos finais de semana e feriados. Este valor pode ser alterado para um ambiente específico. P = PM/TDEV P é expresso em quantidade de homens 5 Passo Cálculo do custo. Com o prazo (TDEV) e Equipe Média (P) é possível estimar o custo do software, conhecendo, além dessas variáveis, o valor hora de cada integrante envolvido no projeto. 40

41 4 CONCLUSÃO O COCOMO II, suas extensões e novos modelos semelhantes ao COCOMO incorporam muitas inovações destinadas a acomodar uma variedade de abordagens modernas para sistemas intensivos em software. Este artigo visou olhar a breve história de como o modelo surgiu, bem como trouxe uma compreensão sobre as atuais edições computadorizadas que implementam o modelo por vários fornecedores. Em seguida, a ótica arquitetônica gerou uma discussão sobre os três principais modelos de classificação: modelo de composição de aplicativos, modelo de design inicial e modelo de pós-arquitetura. Eventualmente, passa-se a olhar para uma comparação detalhada entre o modelo de design inicial e o modelo de pós-arquitetura parecidos. Deste modo, o presente estudo analisou aspectos significativos do COCOMO II, que o tornaram o modelo mais popular de estimativa de custo de software. Conclui-se, portanto, que as práticas de estimativa de softwares aplicadas nas organizações, de modo geral, demonstram ser ferramentas com boa assertividade, uma vez que se possibilita uma menor exposição ao risco por parte do grupo de interesse. Desta forma, pode-se concluir que o uso das práticas de estimativa é de grande relevância para se lograr êxito em projetos de software 41

42 5 REFERÊNCIAS BIBLIOGRÁFICAS ABES, Mercado brasileiro de Software 2017, Panorama e tendências: disponível em: ABES-Publicacao-Mercado-2017.pdf, acessado em: 28/06/2018. BARCAUI, André et al. Gerenciamento do tempo em projetos. 2.ed. Rio de Janeiro: FGV, CASEY, V. Virtual software team project management. Journal of the Brazilian Computer Society,Publisher: Springer, v. 16, issue 2, p. 1-14, CHIN, M. M.; SPOWAGE, A. C.; YAP, E. H. Project Management Methodologies: A Comparative Analysis. Journal for the Advancement of Performance Information and Value, v. 4, n. 1, Kajang, p COSTA, Hélio Rodrigues. Apoio à Seleção de portfólio de projetos de software baseado na Moderna Teoria do Portfólio f. Tese (Doutorado em Engenharia de Sistemas e Comunicação) Universidade Federal do Rio de Janeiro, Rio de Janeiro. ENAMI, Lucia; TAIT, Tania F. C.; HUZITA, Elisa H M. A project management model to a distributed software engineering environment. In: ICEIS INTERNATIONAL CONFERENCE ON ENTERPRISE INFORMATION SYSTEMS, 2006, Papus. Anais do ICEIS 2006, FERNANDES, A. A.; ABREU, V. F. Implantando a governança de TI: da estratégia à gestão dos processos e serviços. 2. ed. Rio de Janeiro: Brasport, p. FLICK, Uwe. An introduction to qualitative research. 2nd ed. London: Sage, JÚNIOR, W,T; SANCHES, R Modelos de Estimativas de Custo de Software COCOMO & COCOMO II ISSN -Instituto de Ciências Matemáticas e de Computação RELATÓRIOS TÉCNICOS DO ICMC São Carlos ABRIL/

43 KAPLAN, R. S.; NORTON, D. P. The Balanced Scorecard: translating strategy into action. USA: Harvard Business School Publishing Corporation, Boston, KERZNER, H. Gestão de Projetos: as melhores práticas. Porto Alegre: Bookman, HUZITA, E. H. M.; TAIT, T. F. C. Gerência de projetos de software. Escola Regional de Informática. Bandeirantes - Paraná, KEELLING, R. Gestão de projetos: uma abordagem global. São Paulo: Saraiva, LEÃO, L. Medidas de Esforço de Desenvolvimento de software, Disponível: Acesso em: 05 jan LEME, L. H. R.; HUZITA, E. H. M.; TAIT, T. F. C. Strategy of risk management for a distributed software engineering environment. In: INTERNATIONAL CONFERENCE ON ENTERPRISE INFORMATION SYSTEMS - ICEIS 2007, 2007, Funchal - Portugal, LEWIS, J.P. Large Limits to Software Estimation, ACM Software Project Estimating Engineering Notes; Vol 26 No. 4P junho 2001 MARTINS, J. C. C. Técnicas para gerenciamento de projetos de software. Rio de Janeiro: Brasport, MATTAR, H USC CocomoII: Estimando Projetos e Estaabelecendo Trade-offs. Rio de janeiro: Brasport, 2009 MEREDITH, Jack R. & MANTEL, Samuel J. Project Management: a managerial approach. New York: John Willey & Sons Inc,

44 McCONNELL, S Software Project Survival Guide; Microsoft Press; 1998 PMI, Project Management Institute. Um Guia do Conhecimento em Gerenciamento de Projetos (Guia PMBOK). 5. ed. Newtown Square, PMI, PMTECH. Fluxo resumido de processos. Fluxo resumido de processos, Disponível em: Acesso em: 01/09/2018. PMTECH. PMTech capacitação em projetos. PMTech capacitação em projetos, Disponível em: Acesso em: 01/09/2018. PRESSMAN. R.S, Engenharia de Software. 6 ed. São Paulo: BookMan, PRINCE2. About PRINCE2. PRINCE2, Disponível em: Acesso em: 07/04/2018. REGO, Marcos. PMO e a estratégia da empresa. In BARCAUI, André Baptista. PMO: escritório de projetos, programas e portfólio na Prática. Rio de Janeiro: Brasport, p , SOMMERVILLE, I. Engenharia de software. 8. ed. São Paulo: Pearson Addison- Wesley, TAIT, Tania F. C.; PACHECO, R. C. S. Uma contribuição da área de sistemas de informação para a informática pública. In: CONGRESSO DA SOCIEDADE BRASILEIRA DE COMPUTAÇÃO, XXI Semish, XXVIII, 2001, Fortaleza - CE. Anais... Fortaleza: SBC, v. 1. p TEIXEIRA, C. A. N.; CUKIERMAN, H. L. Por que falham projetos de implantação de processos de software?. In: SIMPÓSIO BRASILEIRO DE QUALIDADE DE SOFTWARE/WOSES (Workshop Um Olhar Sociotécnico sobre a Engenharia de 44

45 Software), 2007, Porto de Galinhas PE. 3. WOSES. Rio de Janeiro: PESC/COPPE UFRJ, p VARGAS, Ricardo. Identificando e recuperando projetos problemáticos: como resgatar seu projeto do fracasso. MundoPM, n.10, p.42-49, ago./set VARGAS, Ricardo. Manual Prático do plano de projeto: utilizando o PMBOK guide. 5.ed. Rio de Janeiro: Editora Brasport, VERGARA, Silvia. Projetos e relatórios de pesquisa em administração. São Paulo: Atlas, Métodos de pesquisa em administração. São Paulo: Atlas, YIN, R.K. Estudo de caso: planejamento e métodos. 2.ed. Porto Alegre: Bookman 45

46 1