BOLETIM INFORMATIVO DA FATTO CONSULTORIA E SISTEMAS - DEZEMBRO DE 2004
EVENTOS E NOTÍCIAS
1. CALENDÁRIO DE CURSOS DA FATTO
Consulte na página principal do site da FATTO o calendário
dos cursos programados para o ano de 2005.
Breve serão acrescentadas novas turmas e novos cursos!
Os cursos programados são:
- Capacitação em APF:
Vitória, 22 e 29 de janeiro;
- Capacitação em APF:
São Paulo, 12 e 19 de março;
- Capacitação em APF:
Brasília, 14 e 15 março;
- Capacitação em APF: Porto Alegre, 21 e 22 de março.
- Capacitação em APF: Porto Alegre, 27 e 28 de junho.
Detalhes em
http://www.fattoCS.com.br/.
RECURSOS
1. MAPA MENTAL INTERATIVO DA ANÁLISE DE PONTOS DE FUNÇÃO
O Mind Mapping é uma técnica de estruturação não-lienar de idéias,
surgida na década de 70 e cujo propósito principal é a rápida
compreensão de um determinado assunto e a eficiência em sua
memorização, pela organização das informações no mesmo formato em que
são processadas pelo cérebro.
Está disponível no site da FATTO uma nova versão do mapa mental sobre a
técnica da análise de pontos de função, que permite a navegação entre
os conceitos e as etapas do processo de contagem de forma mais
agradável e interativa. Para executá-lo é necessária a instalação da
JRE 1.4.2.
Acesse:
http://www.fattocs.com.br/freemind/apf.html.
2. MEASUREMENT: KEY CONCEPTS AND PRACTICES - CHAPTER 1
Toda organização desenvolvedora de software bem sucedida utiliza
processos de medição como parte de suas atividades técnicas e
gerenciais diárias. Este é o capítulo exemplo do livro "PRACTICAL
SOFTWARE MEASUREMENT: OBJECTIVE INFORMATION FOR DECISION MAKERS" que
discorre sobre a importância das práticas de medição.
Acesse:
http://www.aw-bc.com/samplechapter/0201715163.pdf.
3. SOFTWARE QUALITY METRICS OVERVIEW - CHAPTER 4
Este é um capítulo exemplo do livro "METRICS AND MODELS IN SOFTWARE
QUALITY ENGINEERING", que discute várias métricas de qualidade de sofrware,
distribuídas em três grupos: qualidade do produto, qualidade
do processo e qualidade da manutenção. Também são descritas as
principais métricas utilizadas pela maioria dos desenvolvedores de
software.
Acesse:
http://www.aw-bc.com/samplechapter/0201729156.pdf.
PERGUNTA E RESPOSTA
* Questão adaptada do Function Point FAQ editado pela Total Metrics
e disponível em
http://www.totalmetrics.com/cms/servlet/main2?Subject=Content&ID=184.
P.: Funcionalidades de backup e recuperação de dados devem ser contadas
como requerimentos de negócio do usuário?
R.: Antes de mais nada, vamos exemplificar essa questão com um cenário
típico.
O setor de pagamentos de uma organização armazena todos os seus livros
de registro em uma sala protegida. Como o ambiente é considerado
seguro, os livros estão a salvo e não são necessárias cópias
adicionais.
Por outro lado, sistemas computadorizados não são confiáveis como os
processos manuais e para garantir a segurança dos dados do negócio,
quase sempre fornecem recursos de backup e recuperação de dados. O
backup cria uma cópia exata dos dados do negócio do usuário e a
armazena em um arquivo físico separado. A restauração dos dados
originais envolve a utilização dos dados do backup para a recriação
dos arquivos lógicos de dados.
Nesse cenário, na perspectiva do usuário, nem os processos de backup
e recuperação de dados são eventos de negócio, nem os dados copiados
são grupos lógicos diferentes dos originais. Tanto os processos
quanto os dados são considerados uma característica qualitativa da
aplicação que garante a confiabilidade dos dados.
Dependendo da aplicação o backup dos dados de negócio do usuário pode
ou não ser considerado um requerimento do negócio. Na maioria das vezes
não é.
Existem casos onde o backup é uma responsabilidade do usuário, muitas
vezes por questões legais. O processo manual também teria os mesmos
requerimentos. Nesses casos, as funções que acessam os dados copiados
geralmente são tratadas como transações do negócio e os dados como
Arquivos Lógicos Internos.
Se o backup é um requerimento do negócio, deve-se tentar determinar
como será a contribuição para a contagem funcional em termos de
transações lógicas e arquivos, sem se deixar influenciar pelo projeto
físico e questões técnicas.
Normalmente, questões de backup e recuperação são tratadas durante a
avaliação das Características Gerais de Sistema.
PRÁTICAS DE CONTAGEM
P.: Em um projeto de melhoria pode haver o caso da "transformação" de
funções; ou seja uma CE virar SE ou um AIE virar ALI e vice versa.
Como realizar a contagem nesta situação?
R.: Vamos exemplificar esta situação. Uma aplicação pode ter um
relatório, identificado até então como uma CE e que sofrerá a
inclusão de um campo totalizador pelo projeto. Portanto este relatório
agora deverá ser identificado como uma SE.
Ou também pode ser o caso de um AIE da aplicação que passará a ter
um campo atualizável por um processo incluído ou alterado pelo projeto.
Nesta situação o arquivo deve ser contado não mais como um AIE e sim
um ALI.
Existem duas abordagens para contar estes casos e que terão resultados
bem diferentes para o tamanho do projeto de melhoria. O manual do IFPUG
não aborda explícitamente esta situação.
A primeira abordagem, a qual não recomendamos, seria contar uma
funcionalidade excluída (CE) e uma nova funcionalidade incluída (SE).
Neste caso o projeto de melhoria terá a contribuição de duas funções.
Aplicando esta situação na fórmula do projeto de melhoria e assumindo
o fator de ajuste igual a 1 e as funções de complexidade baixa, tem-se
EFP = [(ADD + CHGA + CFP) * VAFA] + (DEL * VAFB), onde:
ADD = 4 (nova SE)
CHGA = 0
CFP = 0 (não há conversão de dados)
VAFA = 1
DEL = 3 (CE excluída)
VAFB = 1
Logo o projeto de melhoria teria 7 pontos de função.
Na segunda abordagem, a qual recomendamos e que melhor apresenta uma
relação entre o tamanho e o esforço, consiste em contar a função
"transformada" como uma funcionalidade alterada pelo projeto de melhoria.
Assim, assumindo as mesmas premissas anteriores, temos pela fórmula:
EFP = [(ADD + CHGA + CFP) * VAFA] + (DEL * VAFB), onde:
ADD = 0
CHGA = 4 (CE de complexidade baixa que virou SE de complexidade baixa)
CFP = 0 (não há conversão de dados)
VAFA = 1
DEL = 0
VAFB = 1
Logo o projeto de melhoria teria 4 pontos de função.
Em ambas abordagens o tamanho da aplicação após o projeto de melhoria
fornecerá o mesmo resultado.
________
Este informativo pode ser lido também através do link
http://www.fattocs.com.br/bif2004-12.asp
|
Para que possamos ter uma comunicação mais direcionada, convidamos para que complete/atualize o seu cadastro em http://www.fattocs.com.br/cadastro_boletim.asp. |
