texto-me-ead-aula7-corrigido

Prof. Horacio Ribeiro

Disciplina: PE- medidas do esforço no desenvolvimento de software Aula 07 estimativas Putnam e métodos voltado para ponto função

(aula 7 ) ESTIMATIVAS – outros modelos e uso de PF

Este modelo é um modelo dinâmico de múltiplas variáveis que pressupõem a distribuição do esforço ao longo da existência de um projeto de desenvolvimento. Foi construído analisando-se grandes projetos.

O esforço em grandes projetos é caracterizado como mostrado na figura abaixo, reproduzida do professor Pressmam.

Esta figura mostra curvas clássicas que foram apresentadas por Lorde Rayleigh e forma compilados por Norden, por este motivo a curva é chamada de curva RayleighNortem. Esta curva pode é usada para derivar a equação do software que relaciona linhas de código fonte ao tempo e esforço do desenvolvimento:

Texto experimental: e-mail pelo site WWW.espacodoprofessor.com

Prof. Horacio Ribeiro

Onde Ck é uma constante do estado da tecnologia e reflete restrições que impedem o progresso do programador. Tipicamente pode ser: CK =2000 em ambiente para desenvolvimento de software (sem metodologia, documentação revisões precárias. Execução batch) Ck =8000 desenvolvimento de software bom (boa metodologia, documentação, execução interativa Ck=11000 ambiente ótimo com uso de ferramenta case.

A constante CK pode ser determinada para as condições de uma empresa compilando-se dados históricos de desenvolvimentos passados. Trabalhando-se a equação pode-se chegar à expressão para o desenvolvimento K, onde K é o esforço despendido em pessoas-ano ao longo do ciclo de vida para o desenvolvimento em anos.

Td é o tempo de desenvolvimento em anos. A equação para o esforço de desenvolvimento pode ser relacionada com o custo de desenvolvimento incluindose o fator de mão de obra (R$/ano) L é o numero de linhas.

Estimativas de projetos orientado a objetos

(Pressman) O software orientado a objetos deve ter outra abordagem: 1- Desenvolver estimativas usando decomposição de esforço e análise FP aplicável a aplicações convencionais.

que seja

2- Desenvolver o diagrama de casos usos com o seu respectivo dicionário e determine a contagem do número de funcionalidades identificadas.

Reconhecer que o número de casos e uso podem modificar à medida que se desenvolve o projeto.

Texto experimental: e-mail pelo site WWW.espacodoprofessor.com

Prof. Horacio Ribeiro

3- A partir do modelo de análise determinar o número de classes-chave.

4- Categorizar o tipo de interface para aplicação para as classes de apoio.

Multiplicar o número de classes chaves pelo multiplicador para obter uma estimativa para o número de classes de apoio.

Tabela Tipo de interface Não IGI Interface com o usuário baseado em texto IGI IGU complexa

Multiplicador 2,0 2,25 2,5 3,0

5 – Multiplicar o número total de classes (chave e apoio) pelo número médio de unidades de trabalho por classes. Autores como Lorenz sugerem entre 15 a 29 pessoas dia por classe 6 – Fazer a verificação cruzada em estimativas baseadas em classes multiplicando o número médio de unidades por caso e uso

Estimativas com métodos ágeis Um projeto usando um processo de desenvolvimento ágil e feito como um conjunto de cenários de usuários. É possível desenvolver uma estimativa com razoável significado com os seguintes passos: 1. Cada cenário de usuário é considerado separadamente para a estimativa.

2. O cenário é composto de um conjunto de funções e tarefas de engenharia. de software.

3 a. Cada tarefa é estimada separadamente.

3 b. O tamanho do cenário pode ser estimado em LOC, PF ou alguma outra medida orientada a volume 4.a As estimativas de cada tarefa são somadas para criar uma estimativa de cenário 4.b O volume de esforço é estimado para o cenário criado e depois é quantificado para o esforço necessário, a partir de dados históricos referentes a outros projetos 5. As estimativas de esforço para todos os cenários que devem implementar um incremento de software são somadas para definir a estimativa para o incremento.

Normalmente a duração do desenvolvimento de um incremento é da ordem de 3-6 semanas, a estimativa serve para garantir que o número de cenários a ser incluído no incremento esta de acordo com os recursos disponíveis.

Estimativa usando Caso e USO Texto experimental: e-mail pelo site WWW.espacodoprofessor.com

Prof. Horacio Ribeiro

PCU – Pontos por Caso de Uso – Foram criados por Gustav Karner em 1993 como uma adaptação específica dos Pontos de Função para medir o tamanho de projetos de software orientados a objeto. Explora o modelo e descrição do caso de uso, substituindo algumas características técnicas proposta pelos Pontos de Função. É um método simples e de fácil utilização, entretanto, mas ainda esta em fase de pesquisas e não existem regras de contagem padronizadas. Têm se estudado a aplicação em conjunto da PCU e APF tentando explorar a relação entre elas existente(EDMÉIA,2004)

Estimativas usando ponto função A estimativa de tamanho de um projeto de software é uma atividade crítica pois tem um impacto tanto na solução técnica apresentada como no gerenciamento do projeto de software devendo ser efetuada não somente no início do projeto mas durante o ciclo de vida do projeto.

Uma pesquisa realizada pela Secretaria de Política de Informática – SEPIN, em 2001, indicou que a utilização da APF vem crescendo no Brasil, conforme mostra a tabela 2.1: Tabela 2.1: Métricas primitivas utilizadas para medir a qualidade dos processos de software.

Categorias Linhas de código ( LOC ) Pontos por função ( Function Point ) Outras métricas Não utiliza Base

Nº de organizações 25 43 26 363 446

Percentual (%) 5,6 9,6 5,8 81,4 100

Fonte: SEPIN , 2005 Considerando que a APF é uma das técnicas funcionais mais antigas, que possui um dos grupos de usuários mais bem estruturados e atuantes e que a partir de 2002 passou a condição de padrão internacional através da norma ISO/IEC 20926. A técnica pode ser considerada como uma das melhores alternativas de medição de tamanho do projeto de software.

APF serve como um instrumento para acompanhar estimativas de custo e recursos requeridos para o desenvolvimento e manutenção de software.

Exemplo de estimativas com APF: Sistema de Manutenção de Clientes Descrição do sistema: - Em um sistema de manutenção de clientes um usuário (funcionário de empresa) registra as entradas, alterações, exclusões e saídas (relatório) dos dados relativos a um cliente da empresa

Texto experimental: e-mail pelo site WWW.espacodoprofessor.com

Prof. Horacio Ribeiro no sistema. Qualquer usuário da empresa poderá acessar o sistema e efetuar o cadastramento.

(Não haverá controle de acesso no sistema). Será emitido um relatório de todos os clientes cadastrados e dos dados de um determinado cliente.

Características do sistema: - O sistema irá permitir o acesso sem restrições para qualquer usuário da empresa, não havendo portanto, controle de acesso.

- Não existe qualquer interface com outros sistemas existentes - Deverão ser cadastrados os seguintes dados de um cliente: Nome, endereço, Cidade , Cep , Telefone , Email e Observações.

- O nome do cliente, endereço, cidade, cep e email são obrigatórios e deverão ser sempre informados Lista de ator(es): •

Usuário (funcionário da empresa)

Casos de uso identificados

1. Exibir Clientes Cadastrados 2. Efetuar Manutenção de clientes Diagrama de caso de uso simplificado:

Para determinar um custo “Justo” para o software devem-se realizar estimativas de tamanho, custo, esforço e qualidade de software.

Normalmente as estimativas são feitas com base em um histórico de informações durante o ciclo de desenvolvimento do projeto e que servem de base para a tomada de decisão.

Usando–se Análise de Pontos de Função, que tem sido cada vez mais utilizada para estimativas de tamanho, esforço e prazo, de um sistema de software com base na funcionalidade fornecida ao usuário. Vamos estimar o preço e prazo para desenvolver o sistema de manutenção de clientes.

Texto experimental: e-mail pelo site WWW.espacodoprofessor.com

Prof. Horacio Ribeiro Suponha que precisamos dar um orçamento para desenvolver o sistema.

Para isto vamos usar APF para: 1. estimativa do tamanho funcional da aplicação 2. estimativa do custo e esforço para desenvolvimento

1. Determinar o tamanho funcional do sistema de manutenção Entidades e funções do processo de manutenção de clientes 1- Usuário (funcionário) 2-

Gestão do cadastro de clientes

3-

Cadastros

4-

Clientes

A tecnologia usada no sistema para manutenção de cliente será de implementação em um site (processamento nas nuvens) usando a linguagem PHP (com suporte a objetos) envolvendo 3 camadas : camada de dados , camada de aplicação e camada de apresentação.

Para estimar o tamanho será feita uma contagem estimativa segundo o modelo que estudamos nas aulas anteriores - IFPUG. Vamos usar o processo de contagem conforme preconiza o manual do IFPUG para determinar o número de pontos por função de um projeto de software.

Vamos usar as etapas do processo de contagem da APF conforme a figura abaixo:

A figura etapas da contagem da APF.(gráfico retirado de http://www.inf.ufes.br/~falbo/download/aulas/es-g/2005-1/APF.pdf )

Texto experimental: e-mail pelo site WWW.espacodoprofessor.com

Prof. Horacio Ribeiro Determinar Funções do tipo dado – etapa 3 da figura O sistema usa o banco de dados Cadastro.mdb e a tabela Clientes que possui a seguinte estrutura: Para determinar se a tabela Clientes é um ALI devemos fazer duas perguntas: É um grupo lógico de dados identificável pelo usuário ? Sim. É mantido por um processo elementar dentro da fronteira da aplicação ? Sim. A aplicação possui somente um ALI.

Após identificar os ALI e AIE devemos classificar a função de acordo com sua complexidade funcional. Para alcançar este objetivo devemos determinar:

1. Número de Tipos de Dados (TD) - é um campo único, reconhecido pelo usuário, não repetido.

2. Número de Tipos de Registros (TR) - é um subgrupo de tipo de dados, reconhecido pelo usuário, componente de um ALI ou AIE. Após determinar as quantidades de tipos de dados e tipos de registros, devemos classificar a complexidade de acordo com a seguinte tabela: Tipos de Dados Tipos de Registros

< 20

20 50

-

> 50

1

Baixa

Baixa

Média

2-5

Baixa

Média

Alta

>5

Média

Alta

Alta

Após determinar a complexidade dos arquivos , devemos calcular sua contribuição conforme a seguinte tabela: Tipo de Função

Baixa

Arquivo Lógico Interno - ALI

7 PF

Arquivo de Interface Externa - AIE

5 PF

Média

Alta

10

15 PF

PF

7 PF

10 PF

Determinação dos ALI ALI - Arquivo Lógico Interno - é um grupo de dados logicamente relacionados ou de informações de controle identificáveis pelo usuário e mantido dentro das fronteiras da aplicação.

Texto experimental: e-mail pelo site WWW.espacodoprofessor.com

Prof. Horacio Ribeiro No projeto,o cliente visualiza portanto o conjunto de informação como um registro lógico. A aplicação apresenta então somente 1 Registro Lógico.

Como todos os campos da tabela serão usados pelo usuário, com exceção do CodigoCliente que será atribuição do sistema, a aplicação apresenta 7 tipos de dados (basta contar em clientes:tabela).

Chegamos à conclusão pela tabela ( 1 <--> 7 ) que nossa aplicação possui a definição de complexidade Baixa.

Pela tabela a contribuição será de 7 PF. O total de pontos por função para as

funções do tipo dado para a aplicação é igual a 7

PF Determinação dos AIE AIE - Arquivo de interface externa - é um grupo de dados logicamente relacionados que é usado pela aplicação entrtanto sofre manutenção a partir de outra aplicação.

A aplicação não tem nenhum AIE. Com contribuição de 0 PF. 4- Determinar as funções do tipo Transação As funções do tipo transação representam a funcionalidade fornecida ao usuário para atender os requisitos da aplicação. São classificadas como:

1. Entradas Externas - EE - Processa as informações e/ou dados recebidos de fora da fronteira da aplicação

2. Saídas Externas - SE - Envia dados ou informações para fora da fronteira da aplicação 3. Consultas Externas - CE - Envia dados ou informações de controle para fora da fronteira da aplicação.

Cada função do tipo transação deve ser classificada com relação a sua complexidade funcional em:

1. Número de Arquivos Referenciados - AR - Um ALI lido ou mantido pela função do tipo transação ou um AIE lido pela função do tipo transação.

2. Número de Tipos de Dado - TD - Um campo único, reconhecido pelo usuário, não repetido.

Após determinar a quantidade de AR e TD da aplicação podemos definir a sua complexidade de acordo com as seguintes tabelas: Tabela de complexidade para Entradas Externas:

Tipos de Dados Arquivos Referenciados <2

<5

5 - 15

> 15

Baixa

Baixa

Média

Texto experimental: e-mail pelo site WWW.espacodoprofessor.com

Prof. Horacio Ribeiro 2

Baixa

Média

Alta

>2

Média

Alta

Alta

Tabela de complexidade para Saídas Externas e Consultas Externas:

Tipos de Dados Arquivos Referenciados

<6

6 - 19

> 19

<2

Baixa

Baixa

Média

2-3

Baixa

Média

Alta

>3

Média

Alta

Alta

Determinando a quantidade de AR e TD da aplicação Vamos criar uma tabela para indicar as funções do tipo transação identificada e para cada uma delas a quantidade de AR e TD. Função

Tipo

AR

TD

Cadastro de Clientes - Incluir

EE

- Alterar

EE

- Excluir

EE

- Listar

SE

Consultar

CE

7

1

7

1

7

1

10 1

(*) 8

1

(*) - além dos campos de dados estamos estimando ou contando os comandos ( botão e mensagem ao usuário) Após determinar a complexidade das funções de transação podemos calcular sua contribuição de acordo com a tabela abaixo: Tipo de Função

Baixa

Média

Alta

Entrada Externa EE

-

3 PF

4 PF

6 PF

Saída Externa SE

-

4 PF

5 PF

7 PF

Texto experimental: e-mail pelo site WWW.espacodoprofessor.com

Prof. Horacio Ribeiro Consulta Externa CE

3 PF

4 PF

6 PF

Determinando a contribuição em PF para as funções de transação da aplicação Abaixo temos a tabela que exibe as funções do tipo Transação para a aplicação manutenção de clientes.

Função

Tipo

Complexidade

PF

- Incluir

EE

Baixa

3

- Alterar

EE

Baixa

3

- Excluir

EE

Baixa

3

- Listar

SE

Baixa

4

CE

Baixa

3

Cadastro de Clientes

Consultar

Total dos Pontos de função para as O total geral dos

funções de tipo transação da aplicação: 16 PF

pontos de função não ajustados

para a aplicação é de

23 PF ( 16

+7) Cálculo do fator de ajuste O valor do fator de ajuste (VFA) é baseado em 14 características gerais de sistema listadas abaixo:

1. COMUNICAÇÃO DE DADOS: Quando são utilizados recursos de Comunicação de Dados 2.

3.

4.

5.

6.

7.

8.

9.

para o envio ou recebimento de dados e informações de controles utilizados pela aplicação; PROCESSAMENTO DISTRIBUÍDO: Quando a aplicação prevê a distribuição de dados ou de processamento entre várias CPUs da instalação; PERFORMANCE: Esta característica identifica os objetivos de performance da aplicação, estabelecidos e aprovados pelo usuário, que influenciaram (ou irão influenciar) o desenho, desenvolvimento, implantação e suporte da aplicação; UTILIZAÇÃO DO EQUIPAMENTO: Representa a necessidade de se fazer considerações especiais no desenho dos sistemas para que a configuração do equipamento não sofra degradação; VOLUME DE TRANSAÇÕES: Avalia o impacto no desenho da aplicação do volume de transações previsto para ela; ENTRADA DE DADOS "ON-LINE": Avalia o volume de transações que são entradas de dados interativas; EFICIÊNCIA DO USUÁRIO FINAL: Analisa as funções "on-line" desenhadas e disponibilizadas voltadas para a eficiência do usuário final; ATUALIZAÇÃO "ON-LINE": Verifica o volume de arquivos lógicos internos que sofrem manutenção "on-line" e o impacto do processo de recuperação de seus dados; PROCESSAMENTO COMPLEXO: Considera o impacto, sobre o desenho da aplicação, causado pelo tipo de complexidade do processamento;

Texto experimental: e-mail pelo site WWW.espacodoprofessor.com

Prof. Horacio Ribeiro 10. REUTILIZAÇÃO DE CÓDIGO: Avalia se a aplicação e seu código foram especificamente projetados e desenvolvidos para serem reutilizados em outras aplicações; 11. FACILIDADES DE IMPLANTAÇÃO: Considera o esforço gasto para o atendimento dos requerimentos de conversão de dados para a implantação da aplicação; 12. FACILIDADE OPERACIONAL: Avalia o desenho da aplicação quanto aos requisitos estabelecidos para inicialização, "backup" e recuperação voltados à minimização da intervenção manual do operador; 13. MÚLTIPLOS LOCAIS: Quando a aplicação for especificamente projetada e desenvolvida para ser instalada em múltiplos locais ou para múltiplas organizações; 14. FACILIDADES DE MUDANÇAS: Quando os requisitos da aplicação prevêem o projeto e desenvolvimento de mecanismos que facilitem mudanças operacionais, tais como: capacidade de emissão de relatórios genéricos, de consultas flexíveis ou de alterações nos dados de controle do negócio (parametrização).

Cada uma destas características possui um nível de influência sobre a aplicação que pode variar em um intervalo de zero a cinco (0 a 5):

0 1 2 3 4 5

-

Nenhum Influência Influência Mínima Influência Moderada Influência Média Influência Significativa Grande Influência

Após determinar os níveis de influência das 14 características gerais o fator de ajuste é calculado com a seguinte fórmula:

VFA = (Σ NI x 0,01) + 0,65 Onde:

Σ - é o somatório dos níveis de influência para as 14 características NI - NI é nível de influência

Uma equipe de profissionais respondeu e deu nota para os 14 características: As notas dadas para os itens foram: Característica

Influência

Característica

Influência

1

4

8

0

2

0

9

2

3

0

10

0

4

3

11

4

5

0

12

3

6

0

13

0

7

0

14

4

Valor Total =>

20

Chegamos portanto a um nível de influência igual a 20.

Calculando o fator de ajuste pela fórmula

VFA = ( ΣNI x 0,01) + 0,65 temos:

Texto experimental: e-mail pelo site WWW.espacodoprofessor.com

Prof. Horacio Ribeiro VFA = (20 x 00,1 ) + 0,65 = 0,85 O valor do fator de ajuste é igual a

0,85.

Portanto o número de pontos de função para o projeto é obtido da seguinte forma: NPF = PFNA * VFA

onde temos

NPF = 27 * 0,85 = 22,95

Onde : NPF - número de pontos de função Finalmente conseguimos obter uma medida para o tamanho da nossa aplicação. O seu tamanho é igual a

22,95 PF.

Neste ponto para se fazer a estimativa temos de ter informações de projetos anteriores para basearmos nossa estimativa, por experiências passadas podemos trabalhar por analogia. Já foi considerado os aspectos de complexidade e de característica do software quando colocamos o valor de ajuste..

Quanto mais informações você puder obter melhor será a sua estimativa , ou seja, menos erro ela terá. O prazo correto, como em qualquer projeto, só será obtido com 100% de acerto só será obtido no fim do projeto O ambiente de desenvolvimento , a experiência da equipe no projeto , os métodos usados no processo de software , etc. todos estes fatores influenciam na medida de estimativa a ser obtida.

Como estamos usando as regras do manual de contagem, que também são usadas por outras empresas . Isto nos facilita, pois se não tivermos uma base histórica podemos buscar informações em outras empresas a fim de subsidiar sua estimativa.

O esforço em horas pode-se obter pela formula

Esforço Total (horas ) = PF * índice de produtividade e os índices de produtividade podem ser expressos em Horas/PF ou PF/mês .

Para a aplicação em questão que possui 22,95 PF , se o índice de produtividade da empresa ou equipe for de 10 horas/PF o esforço demando seria algo em torno de 229,5 horas.

Assim o projeto demandará 229 horas para ser desenvolvido.

Com base na informação de 229 horas e sabendo-se o custo da equipe por hora podemos definir o preço Com base nisto , sabendo o valor pago pela empresa o custo seria de fácil obtenção.

Na próxima aula vamos abordar o uso de dados estatísticos e estabelecimentos de padrões de gestão e estimativa usando PF.

Conclusão: O uso de PF é mais uniforme, e nos leva a resultados mais consistentes. Assim uma boa base de informações em relação ao PF nos leva a resultados mais consistentes. Trabalhar com LOC é muito impreciso, pois depende da linguagem que pode não estar escolhida. Também o fato que esta medida não favorece a boa estruturação de um projeto. Um projeto bem estruturado com

Texto experimental: e-mail pelo site WWW.espacodoprofessor.com

Prof. Horacio Ribeiro 50.000 linhas é prejudicado ao se analisar outro projeto com 60.000 linhas feitas sem método e estruturação.

Texto experimental: e-mail pelo site WWW.espacodoprofessor.com