Livro de APF – Respostas às questões de fixação

Voltar ao livro de Análise de Pontos de Função

Capítulo 1

Questão 1

Métrica é uma propriedade quantificável de um sistema.

Exemplo: número de defeitos.

Medida é o valor quantificado de uma métrica (o resultado de uma medição).

Exemplo: 100 horas, 5 PF.

Indicador, ou métrica secundária, é o resultado do inter-relacionamento de outras métricas.

Exemplo: PF / hora, R$ / PF.

Questão 2

Conseguir satisfazer o dilema de atender aos requisitos do usuário, que são voláteis e tendem à expansão; otimizando a utilização de recursos, limitados.

Questão 3

Enfoque de gerência de projetos, terceirização, melhorias de processos e uso intensivo de pacotes de software.

Questão 4

Com a APF é possível medir de forma objetiva as variações de escopo dos requisitos funcionais do projeto.

Questão 5

Com base na APF, é possível medir a funcionalidade solicitada e entregue. Os resultados da medição associados a análise de indicadores de produtividade ( PF / HM ), custo ( R$ / PF) e qualidade ( Defeitos / PF) obtidos internamente na própria organização, é possível extrapolar qual o esforço e custo para construir estas funcionalidades. Pode-se utilizar então esta extrapolação na comparação com o custo de aquisição de pacotes.

Questão 6

Na modalidade de preço global fixo, há o potencial de volatilidade e refinamento dos requisitos em relação às necessidades e aos requisitos disponíveis quando pouca informação ainda estava desenvolvida. Essa volatilidade potencializa atritos entre cliente e desenvolvedor em virtude do preço acordado ser fixo e quando não há um entendimento comum sobre os riscos transferidos do cliente para o desenvolvedor. Em caso da funcionalidade necessária ao atendimento das necessidades do cliente superar o estimado na pactuação do desenvolvimento, o prejuízo é do desenvolvedor ou este sacrifica a qualidade final do produto.
Na modalidade homem/hora, há o risco de acomodação da produtividade por parte do desenvolvedor. O cliente quase sempre tem que se envolver na gestão do serviço para garantir os níveis de serviço desejado.

Questão 7

A APF pode ajudar a diminuir o risco em contratos de desenvolvimento de software, pois permite que uma remuneração baseada em resultados. O fornecedor é pago pelas funcionalidades fornecidas pelo software desenvolvido e tem a responsabilidade de garantir a produtividade sob pena de prejuízo no contrato. Por outro lado, caso o cliente altere o escopo inicialmente acordado, pode-se medir de forma objetiva de quanto foi esta variação e remunerar justamente o fornecedor pelo trabalho adicional.

Questão 8

Estabelecimento de um padrão para a medição, em geral o Manual de Práticas de Contagem do IFPUG (especificando qual a versão utilizada).
Elaboração de um documento explicitando todas as premissas assumidas para o desenvolvimento do software e a perspectiva da organização quanto a algumas questões que possam ocasionar polêmica na contagem dos pontos de função.

Questão 9

A APF permite a geração de indicadores, que auxiliam na gestão dos contratos de desenvolvimento de software. E, no caso da modalidade de contratação por ponto de função, permite melhor distribuição de riscos entre cliente e fornecedor.

Questão 10

É justamente através das métricas que é possível avaliar objetivamente (com números!) se determinada iniciativa de melhoria de processo de software (SPI) está surtindo efeito ou não.

Questão 11

Devem ser medidas características, propriedades e eventos cuja quantificação seja relevante para responder aos objetivos definidos pela organização.

Questão 12

As medidas técnicas, como as baseadas em linhas de código (LOC) ou elementos do projeto, são dependentes da linguagem de programação; o que impossibilita a comparação entre projetos desenvolvidos com linguagens distintas.
Não existe um padrão definindo como deve ser a contagem das linhas de código.
LOC tem pouco (ou nenhum) significado para o usuário.

Capítulo 3

Questão 1

São objetivos da APF:

Medir a funcionalidade que o usuário solicita e recebe;
Medir o desenvolvimento e melhoria de software de forma independente da tecnologia utilizada para sua implementação.

Além disso, o processo de contagem deve ser:

Simples o suficiente para minimizar o trabalho adicional envolvido no processo de medição e;
Uma medida consistente entre vários projetos e organizações.

Questão 2

Fator normalizador na comparação de software e;
Suporte à análise de produtividade e qualidade

Questão 3

Os mesmos 1.232 PF, pois a funcionalidade fornecida continuará sendo a mesma.

Questão 4

A visão do usuário representa uma descrição formal das necessidades de negócio do usuário em sua própria linguagem. Os desenvolvedores traduzem as informações do usuário para terminologia da tecnologia da informação de forma a fornecer uma solução. Uma contagem de pontos de função é feita em uma linguagem que seja comum a ambos os usuários e desenvolvedores.

Questão 5

Documento de visão
Casos de Uso

Questão 6

Para que seja possível realizar o dimensionamento (ou medição) do tamanho de um software, é necessário que todos os seus requisitos estejam definidos e sejam analisados. Na estimativa do tamanho não é necessário que todos os requisitos estejam definidos, pode-se assumir algumas premissas a respeito das funcionalidades fornecidas pelo software.

Questão 7 (até a sexta edição)

Baseline (ou base instalada).

Questão 7 (a partir da sétima edição)

Os requisitos do software são fundamentais para a APF, pois o processo de medição é baseado exclusivamente neles. O insumo básico da medição são os requisitos do sistema. Convém destacar que a APF mede apenas uma parte dos requisitos do usuário para o sistema: os requisitos funcionais. Os requisitos não funcionais não são medidos pela APF de maneira direta. Porém num modelo de estimativa de custo baseado em PF ( custo = tamanho x $ / PF ), ambos os tipos de requisitos (funcionais e não funcionais) são considerados: o primeiro irá afetar o tamanho funcional e o segundo afetará o custo unitário ( $ /PF ).

Devido a esta importância dos requisitos para a APF, quanto melhor a qualidade dos requisitos, mais fácil e ágil torna-se o processo de medição, e mais preciso é o resultado. Requisitos de qualidade ruim afetam negativamente todo o desenvolvimento de software, inclusive a atividade de medição. Porém um efeito colateral benéfico do processo de medição é justamente evidenciar falhas nos requisitos. Quanto mais cedo no projeto estas falhas forem identificadas, menor o custo de as corrigir e maior a chance de sucesso do desenvolvimento.

A partir do momento em que a visão do usuário é interpretada e complementada com a visão do desenvolvedor, os requisitos de software começam a adquirir outras características:

Mais específicos e sem ambiguidades;
Fornecem descrição integrada de todas as necessidades do usuário, inclusive com a normalização das necessidades de vários usuários;
Suas terminologias podem ser entendidas por ambos;
Tendência à estabilidade.

Vale destacar, que o termo requisito não se limita às representações em documentos das características e condições do software, mas também inclui as necessidades, que motivaram o seu desenvolvimento, e propriedades do software como um produto.

Questão 8

Tipos de contagem de pontos de função:

Aplicação: mede a funcionalidade oferecida atualmente pela aplicação;
Projeto de desenvolvimento: mede a funcionalidade do software quando da sua primeira instalação e qualquer eventual funcionalidade de conversão de dados.
Projeto de melhoria: mede as funcionalidades incluídas, alteradas, excluídas de uma aplicação e (eventualmente) as de conversão de dados.

Questão 9

O escopo da contagem delimita um subconjunto da funcionalidade do software que será medido.

A fronteira da aplicação é a referência para todo o processo de contagem, auxiliando na determinação das funções tipo transação e tipo dado. Observe, que todos os componentes na medição são internos ou externos e; portanto, algum limite para essa classificação é necessária de maneiras intrínseca. Se algo é interno, é interno em relação a algum compartimento. Se algo é externo, idem.

O escopo varia conforme o caso de desenvolvimento e pode incluir várias aplicações, enquanto a fronteira da aplicação é mais estável apenas mudando em caso de uma mudança estrutural no ambiente em que o software está inserido (a organização).

Questão 10 (até a sexta edição)

As funcionalidades presentes na primeira instalação do software e mais a eventual conversão de dados.

Questão 10 (a partir da sétima edição)

Manutenção Adaptativa: Inclui modificações para atender novos requisitos de negócio, requisitos de negócio em processo de mudança, ou para adicionar funcionalidade não presente em uma versão anterior. Pode também incluir modificações necessárias ao atendimento de requisitos técnicos. É iniciada por solicitações de negócio para adicionar, modificar e/ou excluir funcionalidades de negócio. É sinônimo do conceito de uma “melhoria” como definido pelo IFPUG.
Manutenção Corretiva: Inclui as modificações referentes ao reparo de defeitos. Não envolve mudanças às funcionalidades do negócio, mas garante que a funcionalidade previamente entregue execute como solicitado. O esforço associado com esta atividade deveria ser atribuído ao projeto de desenvolvimento ou de melhoria original que foi responsável pela introdução do defeito.
Manutenção Perfectiva (ou Preventiva): Mudanças no hardware ou software executadas para prevenir defeitos futuros ou falhas. Por exemplo, reestruturar programas ou dados para aumentar a facilidade de manutenção e para prevenir defeitos. Podem incluir modificações para atualização de plataforma de suporte ou software de sistema, otimização de performance e outras atividades afins à manutenção de acordos de nível de serviço. Não existem modificações na funcionalidade de negócio associada com este trabalho. Apesar da análise de pontos de função não ser útil para estimar estas atividades, as características gerais de sistema podem ser afetadas e deveriam ser revisadas quanto a mudanças.

A APF mede apenas as manutenções que alteraram requisitos funcionais do usuário, no caso, as manutenções adaptativas.

Questão 11 (até a sexta edição)

As funcionalidades incluídas, excluídas, alteradas e conversão de dados compreendida pelo projeto.

Ele afeta o tamanho da aplicação pois as funcionalidades incluídas aumentam seu tamanho, as funcionalidades excluídas o diminuem, e as funcionalidades alteradas PODEM aumentar ou diminuir este tamanho, dependendo de uma mudança para cima ou para baixo em sua contribuição à medição conforme mudanças na avaliação de sua complexidade funcional.

Questão 11 (a partir da sétima edição)

Sim, desde que ele interaja ou comunique com o outro sistema. Basta verificar a definição de usuário.

Questão 12

Nos estágios iniciais de uma nova equipe em acomodação a um novo sistema certamente a relação entre a quantidade de pontos de função produzidos e o tempo necessário para tal é menor do que o que será medido após a acomodação.

Neste cenário o esforço envolvido com o “diagnóstico” necessário à manutenção diminui em muito a produtividade deste tipo de projeto quando comparado ao desenvolvimento de novos módulos ou mesmo funcionalidades.

Ou seja, a produtividade seria menor em um projeto de melhoria do que em um projeto de desenvolvimento.

Outro aspecto relevante é o mix entre a quantidade de novas funcionalidades, funcionalidades alteradas e funcionalidades excluídas. Dependendo dessa relação pode não haver de fato nenhuma diferença significativa na produtividade entre um projeto de desenvolvimento e um de melhoria.

Por outro lado imagine o esforço para desenvolver uma transação para inclusão de clientes (entrada externa). Compare com o esforço necessário para incluir mais um campo nesta transação, já classificada como de complexidade alta. Certamente o esforço será maior no primeiro caso. No entanto, os tamanhos em pontos de função para desenvolver (primeiro caso) e para alterar (segundo caso) esta transação são iguais! Neste caso, a produtividade do projeto de melhoria seria muito superior à do projeto de desenvolvimento.

Questão 13 (até a sexta edição)

Estimativa de custos e prazos;
Fornecer subsídio para avaliar a melhor opção entre desenvolver um software internamente à organização ou adquirir no mercado.

Questão 13 (a partir da sétima edição)

Requisito Funcional: Representam o desenho da solução para as necessidades de negócio (o problema) em termos de quais atividades devem ter práticas e procedimentos operacionais transferidos em algum grau para o software. Eles excluem requisitos de qualidade ou qualquer requisito técnico.

Requisito não Funcional: Descreve condições que não se relacionam diretamente com a funcionalidade do software, mas ao invés disso, descreve condições ambientais sob as quais a solução deve se manter efetiva ou qualidades que o software deve possuir. Eles são também conhecidos como requisitos de qualidade ou requisitos suplementares. Podem incluir aspectos relacionados (mas não limitados) a:

Qualidade

usabilidade, confiabilidade, eficiência e portabilidade);

Organização

locais de operação, hardware alvo e conformidade com normas);

Ambientais

interoperabilidade, segurança, privacidade e segurança);

Implementação

linguagem de desenvolvimento, sistema operacional).

A APF mede apenas os requisitos funcionais do usuário.

Questão 14

Delimita o que é o software do mundo exterior.
Age como uma “membrana” pela qual os dados processados pelas transações (EEs, SEs e CEs) entram e saem da aplicação.
Compreende os grupos lógicos de dados mantidos pela aplicação (ALIs)
Apoia na identificação de grupos lógicos de dados referenciados, mas não mantidos dentro da respectiva aplicação (AIEs).

Questão 15

Como consequência da fusão ou cisão de departamentos de uma organização (ou até entre organizações) as aplicações podem ter que ser adaptadas à nova realidade e, portanto suas fronteiras podem expandir ou contrair. Se a fronteira é definida com base no ponto de vista de negócio, nada mais razoável rever a perspectiva de fronteira se o negócio mudar.

Capítulo 4

Questão 1

Ambos representam requisitos de armazenamento do usuário. Contudo o ALI deve obrigatoriamente ser mantido por um ou mais processos elementares da aplicação. O AIE é somente lido pela aplicação.

Questão 2

A quantidade de tipos de registro e a quantidade de tipos de dados.

Questão 3

Não.

Desde que um mesmo ALI seja mantido por processos elementares compreendidos por diferentes fronteiras de aplicação, ele será contado como tal para cada uma destas aplicações.

Questão 4

Porque não representa um requisito de armazenamento. Ele atua como uma entrada de dados feita por um processo que atualizará um ou mais ALIs da aplicação (estes sim representam o requisito de armazenamento do usuário). Falando em termos da análise estruturada, um arquivo de movimento é um fluxo de dados e não um repositório de dados.

Questão 5

Em geral uma nota fiscal é composta pelos dados de seu cabeçalho e o corpo com os itens que foram faturados. Todos os processos que operam sobre as notas fiscais tratam os itens como campos de várias ocorrências na nota. Apesar deste fato, por motivos técnicos (normalização), este arquivo foi implementado como duas tabelas: uma para manter os dados do cabeçalho e outro para manter os itens. Este arquivo deve ser contado como apenas um ALI.

Questão 6

Neste exercício, o ALI em questão após o projeto de melhoria passa a ser classificado como de complexidade média e consequentemente contribui com 10 PF tanto para o projeto de melhoria quanto para a aplicação. Note que antes o ALI era de complexidade baixa e contribuía com 7 PF para a aplicação. Logo houve um incremento de 3 PF no tamanho da aplicação.

Questão 7

Está sendo incluído um novo AIE com dois tipos de dados e no máximo dois tipos de registro, portanto classificado como de complexidade baixa e contribuindo com 5 pontos de função.

Questão 8

São 03 tipos de registro e 49 tipos de dados, sendo classificado como de complexidade média e contribuindo com 10 PF.

Em todos os tipos de registros existe um campo para identificar o compromisso, ou seja dos 51 campos, um se repete três vezes, conforme as regras de contagem de tipos de dados deve-se contá-lo apenas uma vez.

Questão 9 (até a sexta edição)

São 16 tipos de registro, embora seja relevante saber apenas que são mais de cinco.

São 06 tipos de dados no único tipo de registro obrigatório.

Quanto aos opcionais, no mínimo eles vão ter um tipo de dados, sendo então contados mais 15 tipos de dados.

Estes 15 tipos de dados somados aos outros 06 tipos de dados, tem-se 21 tipos de dados, e o arquivo passa a ser classificado como de complexidade Alta e contribuindo com 15 PF.

Questão 9 (a partir da sétima edição)

Basicamente são duas abordagens complementares:

Avaliar como os processos elementares atuam sobre os dados. Se forem as mesmas transações que incluem, excluem e consultam os dados, há uma indicação muito forte de que na visão do usuário as duas entidades são um único grupo de dados. Se forem transações distintas que efetuam estas mesmas operações sobre os dados de forma separada, é por que do ponto de vista do usuário estes dados constituem-se grupos de dados distintos.
Avaliar a relação de dependência entre as entidades. Se for um relacionamento entre uma entidade independente e outra dependente, conta-se um único arquivo lógico com dois tipos de registro. Se for um relacionamento entre duas entidades independentes; são dois arquivos lógicos distintos.

Questão 10 (a partir da sétima edição)

Dados de Negócio: podem também ser chamado de core user data ou objetos de negócio. Este tipo de dados reflete a informação cujo armazenamento e recuperação pela área funcional que a aplicação atende é necessário. Geralmente representam um percentual significativo das entidades identificadas.

Características lógicas incluem:

Obrigatório para a operação da área funcional do usuário
Identificável pelo usuário (normalmente por um usuário do negócio)
Mantido pelo usuário (normalmente por um usuário do negócio)
Armazena Dados Centrais do Usuário do usuário para auxiliar as transações do negócio
Muito dinâmico – operações normais do negócio fazem com que eles sejam
regularmente referenciados, incluídos, alterados e excluídos rotineiramente.
Reportável

Características físicas incluem:

Têm campos chave e normalmente muitos atributos
Podem ter de zero a infinitos registros

Dados de Referência: Dados deste tipo são armazenados para suportar regras de negócio para a manutenção de Dados de Negócio. Por exemplo, em uma aplicação de folha de pagamento ele seria o dado armazenado sobre as alíquotas de imposto do governo para cada faixa salarial e a data em que vigoram. Geralmente representam um pequeno percentual das entidades identificadas.

Características lógicas incluem:

Obrigatório para a operação da área funcional do usuário;
Identificável pelo usuário (normalmente por um usuário do negócio);
Normalmente mantido pelo usuário (normalmente por um usuário administrativo);
Normalmente criado quando a aplicação é instalada pela primeira vez e mantido intermitentemente;
Armazena os dados para auxiliar nas atividades centrais do usuário;
Pouco dinâmico – ocasionalmente altera em resposta a mudanças no ambiente das áreas funcionais, processos funcionais externos e/ou regras de negócio;
Transações processando Dados de Negócio frequentemente necessitam acessar os Dados de Referência.

Características físicas incluem:

Têm campos chave e poucos atributos
Normalmente pelo menos um registro ou um número limitado de registros

Dados de Código: Também chamados de dados de lista ou dados de tradução. O usuário nem sempre os especifica diretamente. Em outros casos, são identificados pelo desenvolvedor em resposta a um ou mais requisitos técnicos do usuário. Proveem uma lista de valores válidos que um atributo descritivo pode assumir. Tipicamente seus atributos são código, descrição e/ou outros atributos “padrão” descrevendo o código; por exemplo, abreviação padrão, data de início e término de vigência, dados de auditoria, etc.

A diferença chave entre Dados de Código e Dados de Referência é:

Com Dados de Código, você pode substituir um pelo outro sem alteração do significado dos Dados do Negócio. Ex.: Código do Aeroporto X Nome do Aeroporto, Código da Cor X Descrição da Cor.
Com Dados de Referência você não pode substituir (Ex.: Código do Imposto com a Alíquota do Imposto).

Características lógicas incluem:

Dados são obrigatórios para a área funcional, mas armazenado opcionalmente como um arquivo de dados;
Geralmente não identificado como parte dos requisitos funcionais; ele é normalmente identificado como parte do projeto para satisfazer requisitos técnicos;
Às vezes, mantidos pelo usuário (normalmente por um usuário do suporte);
Armazena dados para padronizar e facilitar atividades do negócio e transações do negócio;
Essencialmente estático – apenas alterado em resposta a mudanças na maneira que o negócio é operado;
Transações do negócio acessam Dados de Código para melhorar casos de entradas de dados, melhorar a consistência de dados, garantir integridade de dados, etc.

Quando reconhecido pelo usuário:

Ás vezes é considerado como um grupo do mesmo conjunto de dados
Pode ser mantido utilizando a mesma lógica de processamento

Características físicas incluem:

Possui campos chave e normalmente um ou dois atributos apenas;
Tipicamente tem um número estável de registros;
Às vezes não normalizado e armazenado em uma tabela física com outros Dados de Código;
Pode ser implementado de diferentes formas (ex.: em uma aplicação separada, dicionário de dados ou hard-coded dentro de um software)

Questão 11 (a partir da sétima edição)

Um ALI de complexidade Alta para A (15 PF) e um ALI de complexidade Média para B (10 PF).

Questão 12 (a partir da sétima edição)

Fornecedor-Contato com 7 PF (DET=6 RET=2) e Produto com 7 PF (DET=3 RET=1). A entidade Fornecedor-Produto não é contada como um arquivo lógico pois é apenas uma entidade de ligação (key-to-key)
Questão 13 (a partir da sétima edição)
As entidades 1 e 2 pois a única função delas é decodificar um campo.

Capítulo 5

Questão 1

O primeiro passo é a identificação dos processos elementares. As duas regras se originam da própria definição de processo elementar: é a menor unidade de atividade significativa para o usuário final no negócio, que deve ser completa em si mesma e deixar a aplicação sendo contada em um estado consistente.

Questão 2

Entrada Externa: Manter um ou mais ALI e/ou alterar o comportamento do sistema.
Saída Externa: Apresentar dados ao usuário através de outra lógica de processamento que não apenas a simples recuperação de dados ou informações de controle de um arquivo lógico.
Consulta Externa: Apresentar informação ao usuário através da simples recuperação de dados ou informações de controle de um ALI ou AIE.

Questão 3

O clique do botão OK na caixa de confirmação. Outro exemplo: em uma loja de comércio eletrônico, a operação de compra possui uma informação de controle – forma de pagamento – que determina como o processo ocorrerá (se irá emitir um boleto, se fará débito na conta, se irá usar cartão de crédito). Cada forma de pagamento possui um tratamento diferenciado.

Questão 4 (até a sexta edição)

Sim, desde que ele interaja ou comunique com o outro sistema. Basta verificar a definição de usuário.

Questão 4 (a partir da sétima edição)

Conjunto de tipos de dados distintos e/ou;
Conjunto de arquivos referenciados distintos e/ou;
Lógicas de processamentos distintas.

Questão 5

Uma transação de saque seria classificada como uma Entrada Externa, pois a principal intenção do processo elementar é atualizar o saldo do cliente em um ALI do sistema. Apesar de termos a retirada de dinheiro, isso não caracteriza uma saída ou consulta externa, pois não se trata de fluxo de dados ou informações de controle atravessando a fronteira, mas sim de um fluxo de material. Um exemplo análogo seria a retirada de um produto do estoque de um estabelecimento.

Com relação à quantidade de funções identificadas seriam duas, pois o procedimento de saque no autoatendimento é totalmente diferente (provavelmente com campos distintos e certamente lógica de processamento distinta) do procedimento efetuado na boca do caixa. Vale ressaltar que esta análise seria necessária somente se identificássemos que há uma única fronteira envolvendo o autoatendimento e o caixa. Caso fossem duas aplicações distintas (com duas fronteiras próprias), esta análise sequer seria necessária, cada aplicação teria a sua função.

Questão 6

Uma transação de depósito seria classificada como uma Entrada Externa, pois a principal intenção do processo elementar é atualizar o saldo do cliente em um ALI do sistema.

Com relação à quantidade de funções identificadas seriam três, pois os três procedimentos são totalmente diferentes. Enquanto no autoatendimento é feito com envelope e impressão de comprovante, na boca do caixa é feito com autenticação mecânica. Já o processamento de cheques, assim como nos outros dois casos, caracteriza dados diferentes atravessando a fronteira da aplicação.

Questão 7

Funções tipo dado:

– 1 ALI com 19 TDs e 1 TR – Complexidade baixa = 7 PF

Funções tipo transação:

– Inclusão (EE): 1 AR, 20 TDs (19 campos – data da última alteração + comando + mensagem)

Complexidade média = 4 PF

– Alteração (EE): 1 AR, 20 TDs (19 campos – data da última alteração + comando + mensagem)

Complexidade média = 4 PF

– Exclusão (EE): 1 AR, 3 TDs (código do cliente + comando + mensagem)

Complexidade baixa = 3 PF

– Consulta (CE): 1 AR, 21 TDs (19 campos + comando + mensagem)

Complexidade média = 4 PF

A configuração em questão tem (4+4+3+4+7) = 22 PF.

Questão 8

Função tipo transação: 12 TDs (10 campos + comando + mensagem).

Função tipo dado: 11 TDs (10 campos + imagem anterior).

Questão 9

Seria uma SE com 9 TDs (8 campos de detalhe + total de registros) para o sistema XSA e uma EE para o sistema BCT.

A Saída Externa é justificada pelo cálculo realizado para obter a quantidade de registros no trailler (rodapé).

Questão 10

Saída Externa, porque o processo elementar tem como principal intenção enviar dados para fora da fronteira da aplicação (impressão do cheque) e adicionalmente mantém um ALI.

Questão 11

Deve-se analisar a tabela de complexidade de entrada externa. Tente imaginar por exemplo quantos campos em média tem uma tela de inclusão/alteração. Se mais que 15, a EE pode ser estimada como média ou alta. Se ainda por cima houver referência a 2 ou mais arquivos, certamente será de complexidade alta.

Questão 12 (até a sexta edição)

Se a lógica de processamento contém fórmulas matemáticas ou cálculo, cria dados derivados, mantém um ou mais ALIs e/ou altera o comportamento do sistema.

Questão 12 (a partir da sétima edição)

O processo elementar é uma entrada externa pois a principal intenção da tela de registro de vendas de produtos é atualizar o ALI Vendas.

DET: 12 (código cliente, nome cliente, mês, saldo, item, descrição, quantidade, unitário, total, total geral, comando=ok ou F12 ou enter, mensagem).

Obs.: apesar do saldo ser apresentado para cada mês, deve se contar apenas um DET para mês e um DET para saldo.

FTR: 03 (vendas, produtos, clientes).

Portanto uma EE com 12 DET e 03 FTR é de complexidade alta, contribuindo com 06 PFs.

Questão 13

Ela não é um processo elementar, sua existência sozinha não faz sentido para o usuário. É contada em conjunto com o processo que gera o relatório.

Questão 14 (até a sexta edição)

Alguns estudos observaram que há uma relação entre os cinco tipos de função. Daí apregoa-se que é possível estimar o tamanho total baseado na identificação de apenas um dos tipos de função. É também uma técnica que pode ser empregada para se validar a contagem de pontos de função realizada por outra pessoa.

Questão 14 (a partir da sétima edição)

No primeiro caso continua sendo considerado um único processo elementar pois a implementação não afeta a contagem de pontos de função. No segundo caso o cenário é diferente, se há usuários distintos especificando requisitos para cada parte do processo, é um sinal de que há dois processos elementares.

Questão 15 (até a sexta edição)

Capítulo 6

Questão 1

Comunicação de Dados, Processamento Distribuído, Performance, Configuração Altamente Utilizada, Taxa de Transações, Entrada de Dados On-Line, Eficiência do Usuário Final, Atualização On-Line, Processamento Complexo, Reutilização, Facilidade de Instalação, Facilidade de Operação, Múltiplos Locais e Modificações Facilitadas.

Questão 2

VAF = ( TDI x 0,01 ) + 0,65.

Questão 3

Afeta em +/- 35% os pontos de função não ajustados.

Questão 4

VAF = (TDI x 0,01) + 0,65 = (41 x 0,01) + 0,65 = 1,06.

Questão 5

Menor 0,65 e Maior 1,35.

Capítulo 7

Questão 1

Não. Basta observar a fórmula do projeto de melhoria.

Questão 2

Porque pode haver uma compensação entre as funções adicionadas, alteradas e excluídas. Exemplo: se as funções adicionadas contribuírem com a mesma quantidade de pontos de função que as excluídas, ao final do projeto de melhoria a aplicação ficará com o mesmo tamanho. Ou ainda, as funções alteradas podem não sofrer mudança em sua complexidade.

Questão 3 (até a sexta edição)

03 ALI de complexidade baixa = 3 x 7 PF = 21 PF.
12 EE de complexidade alta = 12 x 6 PF = 72 PF.
04 CE de complexidade baixa = 4 x 3 PF = 12 PF.
02 SE de complexidade alta = 2 x 7 PF = 14 PF.
AFP = ADD x VAF = (21 + 72 + 12 + 14) x 0,88 = 119 x 0,88 = 104, 72 PF

Questão 3 (a partir da sétima edição)

03 ALI de complexidade baixa = 3 x 7 PF = 21 PF.
12 EE de complexidade alta = 12 x 6 PF = 72 PF.
04 CE de complexidade baixa = 4 x 3 PF = 12 PF.
02 SE de complexidade alta = 2 x 7 PF = 14 PF.
AFP = ADD = (21 + 72 + 12 + 14) = 119 PF

Questão 4 (até a sexta edição)

Fórmula do projeto de melhoria:

EFP = [(ADD + CHGA + CFP) x VAFA] + (DEL x VAFB) onde,

ADD = 1 SE de complexidade média + 1 CE de complexidade alta = 5 + 6 = 11 PF.

CHGA = 1 CE complexidade alta + 3 ALI complexidade baixa = 6 + 21 = 27 PF.

DEL = 2 EE de complexidade alta = 2 x 6 = 12 PF.

VAFB = 0,88.

VAFA = 0,95.

Então:

EFP = [(11 + 27 + 0) x 0,95] + (12 x 0,88) = 38 X 0,95 + 10,56 = 46,66 PF.

Questão 4 (a partir da sétima edição)

Fórmula do projeto de melhoria:

EFP = ADD + CHGA + CFP + DEL, onde:

ADD = 1 SE de complexidade média + 1 CE de complexidade alta = 5 + 6 = 11 PF.

CHGA = 1 CE complexidade alta + 3 ALI complexidade baixa = 6 + 21 = 27 PF.

DEL = 2 EE de complexidade alta = 2 x 6 = 12 PF.

Então:

EFP = 11 + 27 + 0 + 12 = 50 PF.

Questão 5 (até a sexta edição)

Fórmula da aplicação após o projeto de melhoria:

AFP = [(UFPB + ADD + CHGA) – (CHGB + DEL)] x VAFA onde:

UFPB = 119 PF.

ADD = 11 PF.

CHGA = 27 PF.

CHGB = 1 CE complexidade baixa + 3 ALI complexidade baixa = 3 + 21 = 24 PF.

DEL = 12 PF.

VAFA = 0,95.

Então:

AFP = [(119 + 11 + 27) – (24 + 12)] x 0,95 = 121 x 0,95 = 114,95 PF.

Questão 5 (a partir da sétima edição)

Fórmula da aplicação após o projeto de melhoria:

AFP = [(AFPB + ADD + CHGA) – (CHGB + DEL)], onde:

AFPB = 119 PF.

ADD = 11 PF.

CHGA = 27 PF.

CHGB = 1 CE complexidade baixa + 3 ALI complexidade baixa = 3 + 21 = 24 PF.

DEL = 12 PF.

Então:

AFP = [(119 + 11 + 27) – (24 + 12)] = 147 – 36 = 111 PF.

Capítulo 9

Questão 1

A manutenção de uma base de dados históricos estimados e realizados dos projetos traz como benefício para a organização a possibilidade de geração de indicadores de produtividade e qualidade que traduzem as particularidades do seu próprio contexto e que são essenciais no processo de estimativa de futuros projetos de software. Os fornecedores se beneficiam daqueles indicadores relacionados ao gerenciamento dos projetos e de seus riscos. Para as organizações contratantes, são mais relevantes aqueles indicadores utilizados no gerenciamento do relacionamento com os fornecedores e dos custos envolvidos no processo de produção de software.

Questão 2

A primeira atividade a ser realizada é a coleta de requisitos. O nível de detalhamento necessário para os requisitos deve ser estabelecido pelo propósito da aplicação do processo de estimativa em determinado projeto e pelo grau de precisão que se deseja obter com sua aplicação.

Questão 3

O principal propósito de um processo de estimativa é fornecer informações que beneficiem o planejamento e o controle de um projeto de software o mais cedo possível durante seu ciclo de vida.

Questão 4

Um dos fatores que causam a contraindicação do uso de LOC para a estimativa de tamanho dos projetos é a dependência da linguagem de programação utilizada no desenvolvimento do software, exigindo que se esteja em um adiantado estado da fase de projeto do software para estimar com um mínimo de precisão o seu tamanho. Outro fator é a inviabilidade de análises conjuntas de produtividade de projetos desenvolvidos em linguagens distintas quando a estimativa de tamanho é realizada em LOC.

Questão 5

Os métodos diretos são aqueles baseados na opinião de especialistas, que fornecem uma suposição direta da estimativa, baseando-se principalmente em suas intuições e experiências passadas. Como exemplos dessa categoria de métodos, encontram-se a analogia simples e a técnica Delphi.

Questão 6

Os métodos derivados fornecem algoritmos de transformação que produzem uma estimativa em função de variáveis que se relacionam com alguns atributos de software. As contagens dedutiva e estimativa do tamanho funcional são exemplos desses métodos.

Questão 7

As diferenças nos resultados são devidas à falsa consideração de que existe uma relação linear entre o tamanho funcional e o tamanho físico do software. Além disso, as variações encontradas nos próprios fatores de conversão publicados no mercado chegam a apresentar variações em ordem de grandeza.

Questão 8

As vantagens são relacionadas ao pequeno esforço e ao baixo custo necessários para a geração das estimativas, que podem ser satisfatórias dependendo da margem de erro que é aceitável para atingir o propósito da contagem.

Questão 9

O indicador do fator de crescimento contribui para a melhoria do processo de estimativa utilizado na organização, e também auxilia na identificação dos fatores que contribuem para esse aumento de tamanho.

Questão 10

Inicialmente, a medida de tamanho pode ser utilizada na análise dos dados históricos dos projetos da organização para a obtenção de outro indicador, a produtividade. A estimativa de esforço de um projeto pode, então, ser obtida utilizando-se a estimativa de tamanho do projeto e o indicador de produtividade calculado a partir da base histórica.

Questão 11

Utilizando-se uma simplificação, pode ser adotada uma relação linear entre a estimativa de trabalho envolvido no projeto e os recursos disponíveis (tamanho da equipe) para sua execução.

Questão 12

A relação linear entre prazo e quantidade de recursos em geral é falsa pois, para viabilizar a diminuição do prazo, também é adicionado novo esforço ao projeto a fim de suprir necessidades de comunicação, integração e sequenciamento geradas pela maior distribuição das tarefas.

No entanto, é possível para pequenas variações no tamanho da equipe assumir uma relação linear com o intuito de simplificar o processo sem que haja grande distorção no resultado final.

Questão 13

Porque eles refletem uma realidade que não necessariamente é a da sua organização. Além do que deve-se ao utilizar estes dados conhecer as premissas sob as quais foram gerados.

Por exemplo, a metodologia de coleta de horas de esforço é a mesma utilizada na sua organização, como foi feita a apropriação de custos ao projeto, etc?

Questão 14

Nem sempre pode-se assumir que todos os indicadores são adequados para todas as organizações. Em geral, as organizações consumidoras de software e que possuem atividade fim distinta da área de software podem ter como principal preocupação o seu custo, daí um indicador como R$ / PF passa a ter maior importância.

Em organizações produtoras de pacotes de software, em geral, a definição do preço do pacote pouco tem a haver com o custo do seu desenvolvimento (o único requisito é que este custo seja compensado – com lucro – pela projeção de vendas). Além disto, a dinâmica e exigência do mercado é muito alta; daí enfocar tempo de resposta (produtividade) e qualidade passa a ter mais importância. Logo os indicadores de PF / hora e Defeitos / PF podem ter um peso maior.

Questão 15 (a partir da sétima edição)

Capítulo 10

Questão 1

Na modalidade de contratação homem/hora a organização contrata do fornecedor, profissionais para desenvolvimento (em geral internamente) do software. A remuneração é feita através da definição de um valor/hora por profissional e a apuração do total de horas trabalhadas no período (em geral um mês).

Questão 2

Sob o ponto de vista do contratante, o modelo de contratação homem-hora tem como vantagens a facilidade de administração e supervisão dos trabalhos, com pouco esforço na negociação da alocação de recursos de acordo com a necessidade. Como desvantagens, esse modelo exige que o controle da produtividade dos contratados fique a cargo do contratante, sendo uma tarefa crítica quando o serviço é realizado por equipes mistas de várias empresas, o que também implica na dificuldade de identificar a responsabilidade e a garantia do nível de serviço exigido.

Questão 3

Para esse modelo de contratação, a aplicação da técnica da análise de pontos de função traz benefícios quando utilizada como instrumento de controle da produtividade da equipe e, em conjunto com outros indicadores como o número de defeitos, por exemplo, medir o nível de serviço sendo prestado.

Questão 4

A modalidade de contratação a preço global fixo consiste em combinar um preço pelos serviços necessários para o desenvolvimento de um projeto fechado, ou seja, com escopo previamente definido. A remuneração do fornecedor ocorre mediante o término de determinadas fases do projeto ou ao atingir seus marcos de controle de entrega de resultados.

Questão 5

Os maiores problemas ocorrem com a identificação de que os requisitos para o projeto não foram devidamente identificados ou comunicados. Se os requisitos forem nebulosos ou o fornecedor subestimar o custo do projeto, haverá um desgaste em renegociações contratuais.

Questão 6

A análise de pontos de função pode ser utilizada na modalidade de contratação a preço global fixo como um fator de normalização de preço. A empresa pode dimensionar o projeto originalmente contratado e, com base no resultado da contagem dos pontos de função, pode calcular o valor unitário cobrado pela empresa contratada. Esse então deverá ser o valor base para o cálculo de novas propostas para a execução de serviços adicionais, também medidos em pontos de função.

Questão 7

Nessa modalidade a remuneração é realizada de acordo com elementos entregues do projeto. Esse elemento pode assumir várias formas: tela, relatório, caso de uso, linha de código, ponto de função, etc.

Questão 8

Nesse modelo de contratação, o controle da produtividade passa a ser responsabilidade do fornecedor, pois há o risco de prejuízo caso haja atraso na produção dos elementos objeto da remuneração. Por outro lado, no caso de um aumento de escopo dos requisitos, mais elementos deverão ser construídos para o projeto e o fornecedor será remunerado por isso.

Questão 9

O grande desafio da modalidade de contratação a preço unitário é encontrar um elemento que possa ser reconhecido de maneira inequívoca, uniforme e consistente por ambos, cliente e fornecedor e que também possua uma natureza não excessivamente técnica. A análise de pontos de função responde perfeitamente bem esse desafio pois, além de ser um método padrão, consistente e uniforme para medir a funcionalidade de um software, seu vocabulário utiliza uma terminologia e define objetos de contagem que independem da tecnologia utilizada para o desenvolvimento do software, facilitando a comunicação entre as partes.

Questão 10

Capacitação. Conhecer corretamente a técnica é fundamental. É surpreendente o número de casos em que a APF é aplicada incorretamente, e que invariavelmente terminam em insucesso. A referência oficial da técnica é o manual do IFPUG – o CPM (Counting Practices Manual) versão 4.3.1.
Estabelecer objetivos iniciais modestos. Começar com um projeto piloto em um sistema simples. Avaliar os resultados, efetuar as correções necessárias, revisar os objetivos e prosseguir em frente.
Elaboração de um documento estabelecendo a perspectiva da organização quanto a algumas questões que possam ocasionar polêmica na contagem dos pontos de função.
Uso de um mediador das contagens de pontos de função.

Questão 11

Estratificando o ponto de função – associando o percentual de esforço em cada fase do projeto ao ponto de função.

Questão 12

Para projetos já concluídos uma informação certamente disponível é o quanto se pagou ou se cobrou por cada projeto e quais atividades estavam compreendidas. Provavelmente não estará disponível o tamanho funcional deste projeto. Porém ele pode ser obtido, com pouco custo, a partir de uma contagem ou estimativa dos pontos de função. Tendo o preço do projeto e o seu tamanho em pontos de função, obtém-se o seu preço por ponto de função.

Questão 13

Uma comparação muito comum de ponto de função é com o metro quadrado da construção civil. Ao se perguntar o preço do metro quadrado a um corretor de imóveis, certamente ele fornecerá não um, mas vários preços: de acordo com a região, tipo de acabamento, infraestrutura adicional do imóvel, etc.

Com ponto de função a situação é bem parecida. O preço irá variar de acordo com o trabalho requerido para a construção de um ponto de função e dos subprodutos a serem também entregues.

Exemplo: ao se contratar uma empresa apenas para o trabalho de codificação e testes de unidade de um sistema espera-se que o preço do ponto de função seja inferior ao caso da contratação da mesma empresa para a realização de todo o ciclo de desenvolvimento do sistema.

Ou ainda, o preço do ponto de função para a entrega apenas do software certamente é inferior ao preço do ponto de função onde, além do software, devem ser entregues vários documentos (subprodutos) como: modelo UML, manual de usuário, ajuda on-line, etc.
É também bastante comum no mercado a diferenciação do preço do ponto de função de acordo com a plataforma tecnológica (mainframe, internet, cliente-servidor, etc). Deve-se destacar também que pode haver diferenciação de preço do ponto de função em projetos de melhoria para funcionalidades novas, alteradas e excluídas.

Em resumo, não existe um preço único para ponto de função. Deve-se avaliar o conjunto de atividades relativas à entrega das funcionalidades medidas em pontos de função, o modelo de contrato que ditará a remuneração de um ponto de função e também os aspectos não funcionais que são desconsiderados na medição dos pontos de função.

Questão 14

O Fator de Crescimento, derivado a partir do histórico de projetos passados, ajuda na calibragem da estimativa de tamanho inicial do projeto, dando uma dimensão do quanto os requisitos funcionais podem crescer a partir da especificação inicial.