texto-me-ead-aula7-corrigido

Prof. Horacio Ribeiro

Disciplina: PE- medidas do esforço no desenvolvimento de softwareAula 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 Rayleigh-Nortem. 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


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 incluindo-se 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 que seja aplicável a aplicações convencionais.

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.

3- A partir do modelo de análise determinar o número de classes-chave.Texto experimental: e-mail pelo site WWW.espacodoprofessor.com


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 MultiplicadorNão IGI 2,0Interface com o usuário baseado em texto 2,25IGI 2,5IGU complexa 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



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 Nº de organizações Percentual (%)Linhas de código ( LOC ) 25 5,6

Pontos por função ( Function Point ) 43 9,6Outras métricas 26 5,8

Não utiliza 363 81,4Base 446 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 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.

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

Para isto vamos usar APF para:

1. estimativa do tamanho funcional da aplicação2. 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 )


http://www.inf.ufes.br/~falbo/download/aulas/es-g/2005-1/APF.pdf


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 DadosTipos 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 Média Alta

Arquivo Lógico Interno - ALI 7 PF 10

PF 15 PF



Arquivo de Interface Externa - AIE

5 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.

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 PFDeterminaçã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

< 5 5 - 15 > 15

< 2 Baixa Baixa Média 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 1 7

- Alterar EE 1 7

- Excluir EE 1 7

- Listar SE 1

10 (*)

- Consultar CE

1 8

(*) - 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

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

Cadastro de Clientes

- Incluir

EE Baixa

3

- Alterar

EE Baixa

3

- Excluir

EE Baixa

3

- Listar

SE Baixa

4

- Consultar

CE Baixa

3

Total dos Pontos de função para as funções de tipo transação da aplicação: 16 PF

O total geral dos 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 para o envio ou recebimento de dados e informações de controles utilizados pela aplicação;

2. PROCESSAMENTO DISTRIBUÍDO: Quando a aplicação prevê a distribuição de dados ou de processamento entre várias CPUs da instalação;

3. 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;

4. 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;

5. VOLUME DE TRANSAÇÕES: Avalia o impacto no desenho da aplicação do volume de transações previsto para ela;

6. ENTRADA DE DADOS "ON-LINE": Avalia o volume de transações que são entradas de dados interativas;

7. EFICIÊNCIA DO USUÁRIO FINAL: Analisa as funções "on-line" desenhadas e disponibilizadas voltadas para a eficiência do usuário final;

8. 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;

9. PROCESSAMENTO COMPLEXO: Considera o impacto, sobre o desenho da aplicação, causado pelo tipo de complexidade do processamento;

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 - Nenhum Influência1 - Influência Mínima2 - Influência Moderada3 - Influência Média4 - Influência Significativa5 - 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,65Onde:Σ - é o somatório dos níveis de influência para as 14 característicasNI - 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 02 0 9 23 0 10 04 3 11 45 0 12 36 0 13 07 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:

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 50.000 linhas é prejudicado ao se analisar outro projeto com 60.000 linhas feitas sem método e estruturação.


texto-me-ead-aula7-corrigido

Documents

Transcript of texto-me-ead-aula7-corrigido