MODELOS DE ESTIMATIVAS DE SOFTWARE BASEADOS EM DADOS HISTÓRICOS
modelos de estimativas de software baseados em dados históricos modelos de estimativas de software baseados em dados históricos
288. Processamento Distribuído;9. Utilização de Equipamento;10. Entrada de Dados "on-line";11. Atualização "on-line";12. Reutilização de Código;13. Facilidade Operacional;14. Facilidade de Mudanças.Vazquez et al (2003) afirma que o IFPUG fornece diretrizes que ajudama diminuir a subjetividade na determinação do nível de influência. O IFPUG diz quedeterminados os níveis de influência dos 14 CGS, o fator de ajuste é calculado daseguinte forma: VAF = (TDI x 0,01) + 0,65. Em que TDI (total degree of influence) é osomatório dos níveis de influência das características gerais. O fator de ajuste ajustao número de pontos por função não-ajustados em no máximo + ou – 35%.3.9 Pontos de Função AjustadosCada tipo de contagem (projeto de desenvolvimento, projeto demelhoria e aplicação) possui uma formula específica para a determinação dospontos de função ajustados.Segundo Hazan (2001), uma vez calculados os PF não ajustados e ofator de ajuste, é possível calcular os PFs ajustados. Esse cálculo é feito de formasdiferentes para cada tipo de contagem (projeto de desenvolvimento, projeto demanutenção ou aplicações instaladas). Para projetos de desenvolvimento, o cálculoé dado por:PF = PFNA * VFAonde PFNA = Número de PFs não ajustados eVFA = valor do fator de ajuste
294 ESTIMATIVADesde a década de 80, várias abordagens têm sido propostas eaperfeiçoadas com o objetivo de estimar funcionalmente o tamanho de um software,entre elas destaca-se a Análise por Pontos de Função - APF, proposta em 1979 eatualmente na versão 4.2 (IFPUG, 2004).Ao identificar a necessidade de desenvolvimento, manutenção oumesmo aquisição e customização de um software para atender a novas demandasde uma organização, dois questionamentos sempre presentes são os seguintes:1. Quanto tempo será necessário para concluir o projeto?2. Quanto o projeto vai custar para a empresa?As particularidades dos requisitos de um projeto de software, bemcomo da equipe responsável e da tecnologia empregada, são fatores que dificultama obtenção de respostas confiáveis a estas perguntas. Tais dificuldades podem serevidenciadas ao tentar analisar questões como:- os requisitos traduzem com fidelidade as necessidades do negócio dosusuários? Já se encontram suficientemente estabilizados? Refletemcaracterísticas de software transacionais de baixa complexidade oupossuem atributos que exigem conhecimentos específicos, tais como altaperformance, matemática complexa, processamento distribuído, etc.?- a equipe de desenvolvimento possui conhecimento na área de negócioque será atendida pelo projeto de software? Possui experiência nautilização das ferramentas necessárias à conclusão do projeto? Possuitodos os perfis necessários impostos pelas características do projeto?Existem conflitos internos à equipe que precisam ser solucionados? Épossível identificar uma liderança entre os integrantes da equipe? Qual ograu de motivação da equipe mediante o projeto?- a tecnologia já faz parte da cultura da organização? Pode ser facilmenteabsorvida por novos integrantes da equipe de projeto? Existe material deapoio suficiente para o aprendizado da tecnologia? Sua aplicação exigepessoal com algum tipo de especificação? Suporta a implementação detodas as características do software? Atende aos requisitos não-funcionaisdo projeto?Mesmo quando tais questionamentos são realizados na área deengenharia civil, na produção de algo bem mais tangível que um software, comouma casa ou uma ponte, características específicas que diferenciam um novoprojeto dos anteriores adicionam um certo grau de incerteza às respostas.
- Page 1 and 2: FERNANDO DE MATOS MÔRAMODELOS DE E
- Page 3 and 4: 3MODELOS DE ESTIMATIVAS DE SOFTWARE
- Page 5 and 6: 5EPÍGRAFEagir [...]”“[...] Par
- Page 7 and 8: 7ABSTRACTThis work will approach on
- Page 9 and 10: 95. ESTIMATIVAS DE SOFTWARE BASEADO
- Page 11 and 12: 111.2.2 Objetivos EspecíficosDesej
- Page 13 and 14: 132 POR QUE MEDIR SOFTWARE?2.1 Moti
- Page 15 and 16: 15- quais produtos devem ser desenv
- Page 17 and 18: 17- a desconsideração de delimita
- Page 19 and 20: 19- qual o tamanho da lista de pedi
- Page 21 and 22: 21tamanho e um dos primeiros passos
- Page 23 and 24: 233.2 Conceito de usuárioUsuário
- Page 25 and 26: 253.6 Funções do Tipo Transação
- Page 27: 27- Que enviam dados ou informaçõ
- Page 31 and 32: 31pontos de função, essa distorç
- Page 33 and 34: 33Externa (AIE) e Arquivos Lógicos
- Page 35 and 36: 35Além disso, as variações encon
- Page 37 and 38: 37essas duas dimensões. Dentre as
- Page 39 and 40: 395 ESTIMATIVAS DE SOFTWARE BASEADO
- Page 41 and 42: 41II - a aptidão para traduzir a e
- Page 43 and 44: 43Para estimativas de FP, a decompo
- Page 45 and 46: 456 ESTUDO DE CASODurante um mês f
- Page 47 and 48: 47ContagemProcesso Elementar ouGrup
- Page 49 and 50: 49Emissão de Relatório deProdutos
- Page 51 and 52: 517 CONCLUSÃOMedição resulta em
- Page 53 and 54: 53Consulta na Internet:AZEVEDO, Dou
294 ESTIMATIVADesde a década de 80, várias abordagens têm sido propostas eaperfeiçoadas com o objetivo de estimar funcionalmente o tamanho de um software,entre elas destaca-se a Análise por Pontos de Função - APF, proposta em 1979 eatualmente na versão 4.2 (IFPUG, 2004).Ao identificar a necessidade de desenvolvimento, manutenção oumesmo aquisição e customização de um software para atender a novas demandasde uma organização, dois questionamentos sempre presentes são os seguintes:1. Quanto tempo será necessário para concluir o projeto?2. Quanto o projeto vai custar para a empresa?As particularidades dos requisitos de um projeto de software, bemcomo da equipe responsável e da tecnologia empregada, são fatores que dificultama obtenção de respostas confiáveis a estas perguntas. Tais dificuldades podem serevidenciadas ao tentar analisar questões como:- os requisitos traduzem com fidelidade as necessidades do negócio dosusuários? Já se encontram suficientemente estabilizados? Refletemcaracterísticas de software transacionais de baixa complexidade oupossuem atributos que exigem conhecimentos específicos, tais como altaperformance, matemática complexa, processamento distribuído, etc.?- a equipe de desenvolvimento possui conhecimento na área de negócioque será atendida pelo projeto de software? Possui experiência nautilização das ferramentas necessárias à conclusão do projeto? Possuitodos os perfis necessários impostos pelas características do projeto?Existem conflitos internos à equipe que precisam ser solucionados? Épossível identificar uma liderança entre os integrantes da equipe? Qual ograu de motivação da equipe mediante o projeto?- a tecnologia já faz parte da cultura da organização? Pode ser facilmenteabsorvida por novos integrantes da equipe de projeto? Existe material deapoio suficiente para o aprendizado da tecnologia? Sua aplicação exigepessoal com algum tipo de especificação? Suporta a implementação detodas as características do software? Atende aos requisitos não-funcionaisdo projeto?Mesmo quando tais questionamentos são realizados na área deengenharia civil, na produção de algo bem mais tangível que um software, comouma casa ou uma ponte, características específicas que diferenciam um novoprojeto dos anteriores adicionam um certo grau de incerteza às respostas.
Change language