Contos Tecnológicos – Aplicação 174 – O Teste de Desempenho Final

Pessoal,



vejam mais um conto-jogo. Aqui você participa é o herói.



Abraços,
Leonardo Molinari
====================================
http://diariodaqualidade.blogspot.com/
====================================
Contos Tecnológicos – Aplicação 174 – O Teste de Desempenho Final

Aqui o conto é um jogo do qual você participa. Você é o herói ou vítima. Vamos às regras básicas:

1) Jogue dois dados e some seus pontos. Some 6 ao total. Ao final você terá um total que serão seus Pontos de Sobrevivência num Projeto (PSP);

Observações:

a) Quem não tiver dois dados pode usar o link a seguir para gerar 2 números aleatórios conforme dados. Cada vez que clicar no link, dois novos números são lançados. Acesse o link em .

b) Quem precisar de um dado apenas pode usar o link a seguir para gerar um número conforme um dado. Cada vez que clicar no link 1 novo número será lançado. Acesse o link em .

2) Se seus PSPs chegarem a zero ou a menos que zero, você estará eliminado do projeto;

3) Para cada capítulo você viverá a emoção de participar de um projeto e executar uma missão. Conforme as opções que você escolher e as regras de cada capítulo, você poderá saltar para um capítulo qualquer conforme a orientação dada;

4) Você poderá ganhar (ou perder) ao longo do conto-jogo pontos PSPs, do qual você é o herói. Faz parte de sua aventura;

5) Uma vez pulado para o capítulo desejado, conforme opções e ações, você não poderá retornar propositadamente, exceto se alguma opção lhe for dada pela lógica do jogo. Deve seguir em frente, observando as orientações;

6) Se ao longo do jogo você coletar algum objeto que lhe seja concedido, anote-o e faça uso quando lhe for pedido (caso você o tenha). Ex.: se lhe foi dado uma garrafa com água, guarde-a e use-a depois;

7) Qualquer dúvida, contate o autor do conto-jogo.

Vamos ao jogo:

(Capítulo 01)

Você é um estagiário experiente. Já tem 5 meses de empresa e sabe fazer um teste funcional como ninguém. Você não tem medo de testar.

Seu nome ninguém quer saber. Você não tem identidade na empresa. É apenas o “estagiário sobrevivente”. Seu gerente se reúne com você logo no primeiro dia do sexto mês e lhe coloca em um novo projeto. “Vai ser moleza”, pensou você. Ledo engano. Você está colocado num projeto de máxima urgência e que está pegando fogo. Você fará um teste de performance.

Você será testador de performance (sem nunca ter tido experiência neste tipo de teste) de transações especiais que precisam ser validados e se seu desempenho for bom neste novo desafio, ganhará outras atividades.

Os testes que você vai executar são automatizados. Precisa aprender a usar a ferramenta em poucas horas e aprender a fazer testes de performance. Você tem apenas 8 horas para fazer o teste. Precisará trabalhar de madrugada. O anlista responsável ficou doente e você é seu substituto. O problema é que começará a trabalhar agora e não poderá parar.

Como você é estagiário, pode ser requisitado para outras tarefas. Mas você tem uma missão e tem de cumpri-la, por mais específicos que sejam os testes. Por conta desta nova missão, você descobriu uma coisa que a muito tempo não sabia o que era: medo.

Se você desejar ir banheiro antes de iniciar suas tarefas vá para o capítulo 3.
Se você deseja jantar (são 17 horas) mesmo sendo cedo, vá para o capitulo 5.
Se você desejar iniciar as suas tarefas de imediato, vá para o capítulo 8.
Se você quer consultar algum material de testes de performance antes de iniciar tomar alguma decisão vá para o capitulo 7.

(Capítulo 02)

Você faz algo importante na hora errada. O analista que sabe o precisa ser testado fez você esperar 1 hora sentado até lhe dizer. Perdeu tempo.

Perca 5 pontos PSP.

Se você ainda tem PSP maior que zero. Vá para o Capítulo 15.
Se seus PSP forem menor ou igual a zero vá para o Capítulo 11.


(Capítulo 03)

Você entrou no banheiro. Fez as suas necessidades e resolveu escovar os dentes. Porém você demorou.

Perca 1 pontos PSP.

Você Resolve ir achar material de testes de performance que você precisa. Vá para capítulo 7.


(Capítulo 04)

Muito bem! Você é rápido e gasta 1 hora e sabe o que fazer lendo o material de testes. Nunca faça nada antes de saber direito o que deve fazer.

Ganhe 2 pontos PSP.

Se você optar em levantar os requisitos e objetivos de testes, vá para o capítulo 6. Senão vá para o capítulo 15.


(Capítulo 05)

Muito bem. O corpo precisa de alimento. Você resolve comer bem no jantar. Ganhe 1 ponto PSP.

Você dá sorte e escuta que colega seu no restaurante dizendo que ele teve problemas no último teste de performance porque não sabia fazer as coisas corretamente. Ganhe mais 1 ponto PSP.

Pelo fato de você ter comido muito, pois você sempre comeu pouco, você pediu para o que sobrou seja colocado numa quentinha. Guarda “a quentinha” a leve consigo se você precisar.

Você tem não sabe o que fazer após terminar o jantar?
Se resolver iniciar suas tarefas vá para o capitulo 8.
Se resolver ainda sim achar o livro que precisa ou algo que lhe ajude, vá para o capítulo 7.

(Capítulo 06)

Você faz algo importante na hora certa. O analista que sabe o precisa ser testado lhe conta tudo em 5 minutos. Agora você sabe o que deve ser testado!

Perca 5 pontos PSP.

Vá preparar a massa de dados. Pule para o capítulo 15.

(Capítulo 07)

Você ir falar com o João Alfredo, o melhor analista de testes de performance da sua empresa. Ele tem muita experiência nisso, e você resolver falar com ele super rápido.

Ele te explica o que é de fato um teste de performance, te entrega um material muito útil, lhe entrega os CD´s com a ferramenta de automação, e lhe entrega um papel com uma série de links. E ainda ele diz: você tem tudo em suas mãos para fazer os testes. Sua explicação toda gasta 1 hora. Considere tudo como o seu “material de testes de performance”.

Ganhe 3 pontos PSP, pois deu muita sorte!!!

Se você optar por ir preparar ambiente de teste, vá para o capítulo 15.

Se você optar por ir levantar os requisitos e necessidades de testes de performance, vá para o capítulo 2.

Se você optar por ir estudar o material e tudo que você tem a mão antes de começar, vá para o capítulo 4.

Se você optar por conversar com seu chefe sobre a senha e o crachá que vai precisar pois sairá tarde, vá para o capítulo 10.

(Capítulo 08)

Você resolve iniciar as suas tarefas. Você descobre o mais obvio: Não sabe como deve fazer o teste de performance, e o que deve testar.

Perca 5 pontos PSP por não ter imaginado o que deveria fazer. Quando o prazo é apertado é não tomamos as decisões certas, tempo precioso é perdido.

Se você ainda tem PSP maior que zero. Vá para o Capítulo 15.
Se seus PSP forem menor ou igual a zero vá para o Capítulo 11.

(Capítulo 09)

Você ainda desconfia de algo. Nada substitui a intuição a observação atenta.

Ganhe 1 ponto PSP.

Se você ainda optar por analisar o throughput e o tempo de resposta das transações vá para o capitulo 19.

Se você resolver montar o relatório de testes, vá para o capítulo 21.

(Capítulo 10)

Novamente você comete um erro desnecessário. O seu chefe já tinha providenciado tudo para você mas somente depois de meia hora esperando, você descobre isso!!!

Perca 3 pontos PSP.

Se você ainda tem PSP maior que zero. Vá para o Capítulo 15.
Se seus PSP forem menor ou igual a zero vá para o Capítulo 11.

(Capítulo 11)

Você fica cansado e sem paciência para com o teste em questão pois não sabe o que fazer direito depois de tudo o que aconteceu. Você resolve desistir de tudo e pede para seu chefe que outro faça o seu serviço.

Você vai para casa pois amanhã é outro dia.

(Capítulo 12)

Agora você gravar os scripts de testes, mas antes tem de instalar a ferramenta.

Se você não tem o “material de testes de performance” entregue pelo João Alfredo, então perca 5 pontos PSP. Neste caso se você ainda tem PSP maior que zero, vá para o Capítulo 14.

Se você tem o material perca somente 1 ponto PSP pois difícil instalar a ferramenta sem os CD´s. Neste caso vá para capítulo 16.

Em qualquer hipótese acima, se seus PSP forem menor ou igual a zero vá para o Capítulo 11.

(Capítulo 13)

Muito bem. Sua atitude foi a mais correta. Ao analisar os logs você descobriu que durante o encerramento do usuários virtuais (ou quando as transações terminavam) ao final do teste, as transações davam erro. Isto indica um possível gargalo no servidor.

Guarde esta informação no “bloco de notas – anotação especial”que você ganhou de um colega de trabalho e ainda não usado. Pode ser útil mais adiante.

Ganhe 3 pontos PSP! Vá para a capítulo 9.

(Capítulo 14)

Perca 2 pontos PSP por ter de ficar meia procurando até achar o “material de testes de performance” que foi possível ser dado pelo João Alfredo, o que inclui os CD´s dos software de teste. Seja mais responsável da próxima vez.

Vá para o capítulo 16.

(Capítulo 15)

Você depois de 3 horas e meia de muito trabalho árduo, e muito se estressar, consegue preparar os dados e aplicação para teste.

Você está cansado. Se você tem a “quentinha” você pode usá-la para aliviar um pouco de sua fome. Se você não tem a “quentinha” perca 3 pontos PSP.

Se você ainda tem PSP maior que zero. Vá para o Capítulo 12.
Se seus PSP forem menor ou igual a zero vá para o Capítulo 11.

(Capítulo 16)

Você finalmente grava e executar os scripts de testes aos trancos e barrancos, você se dá conta que gastou 1 hora e meia. Foi fez o mínimo desejado.

Ganhe 1 ponto PSP, por ter “sobrevivido”.

Você sabe o que deve fazer agora?

Se você optar por analisar os logs de testes, vá para o capítulo 13.

Se você optar por analisar o throughput e o tempo de resposta das transações vá para o capitulo 19.

Se você resolver montar o relatório de testes, vá para o capítulo 21.

(Capítulo 17)

Você tem uma decisão a tomar. Ficou sabendo naquele instante que precisa montar uma apresentação com o sumário dos testes.

Você tem 15 minutos para fazê-la. Se decidir fazer vá para o capítulo 22.

Se não decidir fazer para o capítulo 23.

(Capítulo 18)

Você finalmete está cara a cara com seu chefe mostrando os resultados dos testes. Ele lhe pergunta: Encontrou algum gargalo na aplicação?

Você resolver verificar o “bloco de notas – anotação especial”. Se você tem este bloco de notas guardado, vá para o capítulo 24.

Se você não tiver o tal bloco vá para o capítulo 20.

(Capítulo 19)

Você gasta um tempo enorme analisando o tempo de resposta de resposta, e o throughput. O primeiro está aceitável porém o segundo está ainda muito abaixo do que se esperava, mas ainda sim não está ruim. Você pensou fez a coisa certa. Mas não era.

Perca 3 pontos PSP por ter perdido tempo.

Se você ainda tem PSP maior que zero. Vá para o Capítulo 21.
Se seus PSP forem menor ou igual a zero vá para o Capítulo 11.

(Capítulo 20)

Você mostra o relatório de testes que não possui nenhuma informação de gargalo.

Ele fica furioso e manda você sair da sala dele, e ele lhe afirma que o ele pedirá para um outro analista de testes fazer o trabalho novamente, pois ele sabe que existem problemas no ambiente, mas não sabe onde. A imagem da empresa perante o cliente ficará arranhada.

Vá para o capítulo 11.

(Capítulo 21)

Você tem 30 minutos para montar o seu relaório de testes. Você usa um padrão existente, e coloca todas as informações que você achou.

Você faz o relatório na metade do tempo.

Se você tem alguma anotação especial no seu “bloco de notas – anotação especial”, use-a para melhorar o seu relatório se tiver e ganhe 1 ponto PSP.

Se não tiver a anotação acima, perca 1 ponto PSP. Ë ruim não ter dectado nenhum gargalo.

Se você ainda tem PSP maior que zero em qualquer acima. Vá para o Capítulo 17.
Se seus PSP forem menor ou igual a zero vá para o Capítulo 11.

(Capítulo 22)

Fez a coisa certa. Colocou 5 slides com o essencial dos testes.
Ganhe 1 ponto PSP.
Vá para 18.

(Capítulo 23)

Você eprdeu tempo pensando e fez a escolha errada e lhe avisaram que isto era necessário para apresentar para seu chefe.

Perca 5 pontos PSP. Errou novamente.

Se você ainda tem PSP maior que zero em qualquer acima. Vá para o Capítulo 18.
Se seus PSP forem menor ou igual a zero vá para o Capítulo 11.

(Capítulo 24)

Parabens!!!

Você mostra onde está o gargalo e surpreende o seu chefe que lhe dá grandes elogios.

Você consegiu e é o heroi!!! Sua análise ajudou a resolver os problemas da aplicação antes que aplicação entrasse em produção. A imagem da empresa foi salva!!!

Amanhã é outro dia porém este foi um grande sucesso!!!

AGRADECIMENTOS QUENTES E IMPACTO

Pessoal,


agradeço a todos vocês que ajudaram a fazer deste meu livro "Testes Funcionais de Software" um impacto na área Editorial, na Qualidade do País e mais ainda: graças a ele, criou-se uma "onda" de cursos, busca por literatura, artigos e muitos em Testes Funcionais. E mais: a maioria das ementas destes cursos/seminários tem seguido a linha do meu livro, seja em estrutura, seja em conteúdo. Sabem o que é isso tudo? A software testing revolution! Sim pessoal, essa era a verdadeira revolução positiva, de divisão e disseminação de conhecimento que procurei fazer quando meu livro foi publicado.

Agradeço a todos vocês! Muito obrigado de coração.

E mais: a inscrição para o meu seminário de testes funcionais no RJ, tem sido um sucesso, o que me leva concluir que a demanda por aprendrer de verdade como se faz testes funcionais, se torna imperativo. Quem não se inscreveu, ainda há tempo para ter se increver com desconto até dia 30/10/2008.

Veja o post com as informações da palestra clicando Aqui.


Abraços e muito obrigado!


Leonardo Molinari
===============================
http://diariodaqualidade.blogspot.com/

QUENTE - SEMINARIO DE TESTES FUNCIONAIS NO RJ

Pessoal

seria insensato não divulgar "quente" aqui no Blog. Ministrarei um seminário no Rio de Janeiro em parceria com a MZP Software Testing. Tema/Título (já diz tudo):

"Testes Funcionais de Software".

Vejam as Informações mais abaixo. As vagas são limitadas e quem fizer inscrição antes terá desconto.

Para grupos, desconto. Como é algo que está sendo divulgado em todo Brasil, estarei dando este seminário que foi um sucesso em SP.

Para quem foi em SP, veja a análise do seminário (em três partes) no portal TestExpert, feita por Robson Agapito, :

-Parte-1
-Parte-2
-Parte-3

Abraços a Todos,

Leonardo Molinari
==================================
http://diariodaqualidade.blogspot.com/
==================================

O b j e t i v o:
----------------

O objetivo do curso é transmitir ao aluno o conhecimento completo sobre as melhores práticas de testes funcionais, sejam manuais ou automatizados, dentro das melhores práticas de gestão de qualidade de software.

C o n t e ú d o P r o g r a m á t i c o
----------------------------------------

Nova Visão de Qualidade de Software
Atualizando Testes de Software
Planejamento de Testes
Como Escrever Requisitos & Casos de Testes
Técnicas Específicas de Testes Funcionais
Caso de Estudo
Entendendo teste de Má Qualidade
Melhorando a Qualidade e desempenho dos testes


I n v e s t i m e n t o
-----------------------

R$ 350,00 por participante
Desconto de 20% para inscrições e pagamento até 30/10/2008
Desconto especial para grupos de mesma empresa
Incluso coffee Break – material de apoio.

L o c a l e D a t a
---------------------

08/11/2008 das 9:00 às 17:00 horas
BQ – Business Quality
Rua São José, 40 - Centro
Rio de Janeiro - RJ

===> GARANTA JÁ SUA INSCRIÇÃO (vagas limitadas)

I n s c r i ç õ e s
-------------------

Para inscrições em São Paulo : 11 3129-8760 eventos@mzpsoft.com.br
Para Inscrições no Rio de Janeiro: 21 8899-1562 cristina@mzpsoft.com.br

===> Sorteio de vários livros no final do evento

R e a l i z a ç â o
------------------------------
MZP SOFTWARE TESTING
www.mzpsoft.com.br
------------------------------

POLÊMICA - PRECONCEITO CLARO PARA COM A ENTREVISTA DE CLAUDIA HAZAN

Pessoal,

a entrevista de "Claudia Hazan" está causando polêmica antes mesmo de ser "divulgada".

Ela foi vítima de preconceito e assédio, inclusive sexual, no que diz respeito a sua tese. Sim senhores... Ela, ficou abalada emocionalmente na época em que o problema com sua tese ocorreu.

E nada aqui foi publicado sem concentimento dela, e ela, ela mesmo fez questão de publicar a sua entrevista para que a verdade viesse a tona de modo que outras pessoas também vítimas fossem ajudadas (isso mesmo, existem outras pessoas com casos semelhantes). Resolveram atacar o blog, de forma a desmoralizar o conteúdo aqui colocado.

Atacaram o conteúdo do blog, dos meus livros, os quais tem sido sucesso e super-aceito pela comunidade de testes (inclusive outros consultores e autores me escrevam elogiando, o qual fiquei feliz e emocionado, meu último livro já é referência nacional em testes funcionais, inclusive uma palestra que dei recentemente em SP foi hiper-elogiada, merecedora de analise em três partes). Atacaram todo o que coloquei aqui. Pela característica foi o mesmo personagem, ou pessoa, que nunca se identifica, o qual chamei de: O Palhaço da Qualidade.

Vou replicar um pedaço do comentário do Palhaço da Qualidade: "... inovaçao x evoluçao? acabaram seus livros...". Acabei de publicar um livro que é um sucesso. Será que ele sabia ? Eu nem sabia e descobri outro dia desses: meus livros são usados já como base de teses de conclusão de curso e em cursos de especialização. Resolvi nõa publicar os comentários dele, por respeito a todos.

O que a pessoa se esqueçeu é que avisei o IP iria ser monitorado está sendo enviado as autoridades. Bem senhores... eu desconfiei que o Palhaço da Qualidade iria atacar. Simples: fiquei acordado a noite e a manhã toda, monitorando os IP's que acessavam meu blog... E lá estava ele. Com seu post de baixo moral e calão. Me custou uma noite de sono, mas justiça será feita. O IP dele foi registrado e enviado as autoridades. As consequencias... Somente sei que justiça será feita. É uma atitude de um profissional inexperiente e que ao invés de focar em fazer o bem, resolver fazer o mal, e que acredito que participe de outras comunidades e blogs. Não sei se é autor.

Somente concluo uma coisa: é um profissional que precisa olhar pra dentro de si mesmo e se rever enquanto pessoa. Antes de criticar, veja e pergunte. Existe preconceito intelectual, da mesma forma que existe preconceito de sexo, cor e religião. Para isso aqui no Brasil, existem leis.

Este post é publicado de modo que vejam, que existe preconceito para com que é honesto e procura fazer um bom trabalho. A entrevista com Claudia Hazan é um exemplo de luta contra . A entrevista dela é uma entrevista honesta e um depoimento.

Caro Leitor, existem momentos que não adianta falar de tecnologia. Devemos falar de atitude. Devemos entender o ser-humano e saber que ser inovador é saber ir além e acreditar em algo.

O "inventor" da lampâda criou "n" protótipos e testou "n" vezes até que uma lampada desse certo e funcionasse. Ninguém acreditou nele. Isso que ele fez foi inovação. Ele foi além. Aqui o Blog, é antes de tudo um Blog inovador e em busca constante de inovação. Hoje usamos lampadas em todos os lares do país... Sonhar não custa nada. Ter atitude é o primeiro passo para realização de sonho.

Um abraço a todos,

Leonardo Molinari
===============================
http://diariodaqualidade.blogspot.com/
===============================

ENTREVISTA EXCLUSIVA SOBRE MÉTRICAS COM CLAUDIA HAZAN

Pessoal,


hoje temos um convidado especial nesta entrevista: Claudia Hazan.



Vejam no último post deste blog uma palestra dela num evento nos EUA - vejam a foto dela abaixo deste mesmo evento.





Ela é Mestre em Sistemas e COmputação e especialista em Qualidade e Métricas. Dispensa qualquer apresentação. A carreira dela fala por ela. Vejam a maravilhosa entrevista desta inovadora para nosso blog (esta entrevista é uma das muitas entrevistas que estão sendo publicadas neste blog - muitas outras virão):

=============================

MOLINARI: Claudia, é um prazer enorme tê-la como entrevistada em meu aqui em meu Blog. Para quem não sabe Claudia Hazan escreveu o prefácio de meu ultimo livro, Gerência de Configuração, que tem tido uma grande receptividade na área de Qualidade. Muito obrigado pelo belo prefácio. A intenção aqui é batermos um papo bem vontade sobre Métricas e sua importância nos projetos, que é uma de suas especialidades. Antes de começarmos, conte-nos um pouco de sua trajetória profissional até chegarmos hoje: uma profissional que possui métricas no "Código Genético", falando de uma maneira bem simples.


CLAUDIA HAZAN:
Leo, inicialmente muito obrigado pelo convite. É uma honra está sendo entrevistada no seu Blog, do qual sou fã. Adoro seus artigos, livros.... Respondendo a pergunta, conheci a Análise de Pontos de Função em 1995, era estagiária de desenvolvimento de software e assisti uma palestra sobre o assunto na empresa. Como estagiária, estava aprendendo a desenvolver software e tinha demanda de desenvolver um módulo de um sistema. Meu gerente sempre me perguntava, “ Claudinha, quanto tempo você estima terminar de desenvolver a função XPTO”. Eu não sabia responder, não conhecia o processo de desenvolvimento de software, a linguagem de programação, a aplicação... Estava aprendendo Análise Estruturada, Banco de Dados estudando apostilas do meu chefe, ainda não tinha aprendido na faculdade. E então, qual resposta... quanto tempo? Minha resposta foi a seguinte: “Qual é o tempo que os outros estagiários sem conhecimento de desenvolvimento de software têm levado para desenvolver uma função similar a esta”. Eu não conhecia a área de estimativa, mas a minha resposta intuitiva foi baseada em Banco de Dados histórico de aplicações, documentação de lições aprendidas. Na palestra de Pontos de Função, observei uma maneira de poder estimar o desenvolvimento de software. E decidi pesquisar sobre o assunto na Universidade. Em 1996, meu projeto final de graduação foi sobre......??? Análise de Pontos de Função, é claro. Então, decidi continuar os estudos no Mestrado em Qualidade de Software, me interessei pelos indicadores. Em 1999 defendi minha Tese de Mestrado no Instituto Militar de Engenharia (IME) sobre Indicadores de Software. Em 1998 comecei a trabalhar com Análise de Pontos de Função no SERPRO. Em 2001 obtive minha primeira Certificação de Especialista em Pontos de Função – CFPS (Certified Function Point Specialist). Assim, posso dizer que comecei a pesquisar medições de software em 1995 após a palestra e a trabalhar com medições de software em 1998. E adoro minha profissão de Consultora de Métricas de Software do SERPRO.

MOLINARI: Você terminou sua tese de Doutorado,
certo? Fale um pouco sobre ela, e onde pode ser aplicada e
qual sua correlação com a área de Métricas.

CLAUDIA HAZAN:
Leo, defendi minha Tese sim, em um meio de ofensas para mim e para todos os profissionais competentes da indústria software, como: “Pontos de Função não é válido” e “A indústria implanta qualquer coisa”. Respondendo: Professor, com todo o respeito as suas palavras, os profissionais que trabalham na indústria de software não implantam qualquer coisa. Eles são cobrados por resultados, são avaliados. E quanto a validade da métrica Pontos de Função. A ISO reconheceu o PF Não Ajustado como métrica de Tamanho Funcional. E ainda, ressalto, que a métrica Pontos por Casos de Uso, um tanto subjetiva, não foi reconhecida pela ISO.
Leo, você e várias pessoas me enviaram e-mails e me telefonaram me parabenizando e pedindo minha Tese. Peço desculpas a você e a todos por não enviar minha Tese. De fato, a PUC divulgou na Internet que minha Tese estava publicada na Biblioteca do Departamento de Informática, mandou o resumo de minha Tese para o Banco de Teses da CAPES, sendo este disponibilizado na Internet. No entanto, estou processando a PUC Judicialmente, envolvendo minha Tese. Infelizmente, não posso divulgar minha Tese enquanto esse problema não se resolver na Justiça. Mas, posso falar sobre a Tese e minhas pesquisas. Desenvolvi um método de estimativas de tamanho de projetos de software em Pontos de Função, denominado CEPF (Contagem Estimativa de Pontos de Função). Tenho utilizado este no SERPRO e ensinado ele para os meus alunos. O método permite a estimativa dos Pontos de Função na primeira reunião com o cliente, com uma excelente acurácia, os experimentos mostraram erros menores que 10%. Mas, essa não é a única contribuição de minha Tese, o método permite identificar defeitos em requisitos, durante a estimativa. Imagine uma inspeção de requisitos sem custos, realizada durante a estimativa. A literatura apresenta diversos métodos de inspeção de requisitos, mas são muito custosos. O meu método não tem custo e os resultados dos experimentos foram muito bons. A indústria, de um modo geral, precisa investir na melhoria da qualidade dos documentos de requisitos. O documento de requisitos é a base para a construção do software, para o acordo entre cliente e fornecedor e para a Contagem de Pontos de Função. Por isso, meu interesse na Engenharia de Requisitos, como consultora de requisitos, sou usuária de documentos de requisitos. E ainda, o resultado do meu trabalho de estimadora, depende da qualidade dos documentos de requisitos, por isso preciso garantir a qualidade destes.

MOLINARI: As pessoas confundem muito estimativa com
métrica. Seria possível explicar-nos melhor?

CLAUDIA HAZAN:
As métricas são usadas para apoiar os processos de estimativas. Eu utilizo a métrica Pontos de Função para estimar o tamanho funcional de projetos de software. A métrica HH (Homem Hora) é usada para estimar o esforço dos projetos. A métrica Ponto de Função não é uma estimativa de esforço. O tamanho funcional de um projeto em Pontos de Função e os requisitos não funcionais do projeto são usados para estimar esforço.

MOLINARI: Quais são os "papas" nesta
área? Quais as grandes diferenças de visões de cada um?

CLAUDIA HAZAN:
Meu guru na área de métricas é o Capers Jones, sou fã dos livros e artigos dele. Ele foi o Keynote Speaker no Conferência Anual de Métricas promovida pelo IFPUG – ISMA (International Software Measurement & Analysis). Existem muitos outros excelentes profissionais na área de métricas, prefiro não citar nomes. Ao assistir as palestras no ISMA, onde fui também palestrante, pude observar que a visão dos profissionais de métricas está alinhada. Aonde vai existir divergências é na visão de algumas pessoas do meio acadêmico “especialistas” em Análise de Pontos de Função e os especialistas de fato que trabalham como Consultores de Métricas na indústria. Eu já li algumas “pérolas” em artigos publicados em Congressos Acadêmicos, contrariando os conceitos e fórmulas do manual de Práticas de Contagem de Pontos de Função (CPM) e o pior que as “pérolas” referenciavam o CPM. Fico preocupada com essa disseminação de conceitos errados. Atualmente, existem muitos contratos de software, baseados em Contagem de Pontos de Função. É importante para a indústria contar Pontos de Função corretamente, seguindo as regras de contagem do CPM.

MOLINARI: Quais os maiores problemas para quem usa
diariamente métricas?

CLAUDIA HAZAN:
Atualmente, o maior problema são muitas demandas, sobrecarga de trabalho. Será que isso é problema? Na minha opinião, isso não é problema para quem gosta do seu trabalho. Algumas situações estressantes são as discussões de Contagem de Pontos de Função. A função X conta, não conta.....
A habilidade de comunicação oral e escrita faz parte do conjunto de competências que um Consultor de Métricas deve ter.

MOLINARI: Quais os maiores problemas para quem quer
aprender a usar métricas? Algumas dicas?

CLAUDIA HAZAN:
A área de métricas está em expansão, tenho recebido várias oportunidades de trabalho.... Assim, é uma excelente área para se ingressar. Um Consultor de Métricas tem que ter o perfil de pesquisador e estar sempre buscando novos conhecimentos. A área de métricas apoia a implantação da Qualidade de Software, assim o profissional deve conhecer os modelos de qualidade de software. Para quem quer trabalhar com contagem de Pontos de Função é fundamental a especialização em requisitos. No momento, além de métricas, estimativas, estou pesquisando a Governança de TI, Planos Estratégicos de TI. Um Consultor de Métricas não pode parar no tempo. No ano que vem, tem versão nova do Manual – a publicação do CPM 4.3 está prevista para o ano que vem.

MOLINARI: Tirar conclusões de métricas, ou de um histórico de métricas, é "um bicho de sete cabeças"? já passou pro algum caso complicado?

CLAUDIA HAZAN:
Leo, infelizmente analisar dados históricos tem sido complicado sim. Algumas empresas estão contando Pontos de Função de maneira errada, convertendo horas para PF, convertendo Pontos por Casos de Uso para PF ... Assim, muitas vezes, os dados históricos não são úteis. Eu tenho preconizado o seguinte “Não conte Pontos de Função. Conte Pontos de Função corretamente”.

MOLINARI: Um executivo de TI, por exemplo, pode ter que tipo de métricas a sua disposição para que suas decisões possam se apoiar?

CLAUDIA HAZAN:
Existem muitos indicadores importantes. Mas, um executivo, precisa de um “painel de bordo”, ou seja um conjunto mínimo de indicadores para apoiá-lo nas decisões de investimentos. Na área de processo de software, considero importante, indicadores de produtividade, qualidade e custo. É importante também buscar dados de Referenciais de Excelência via Benchmarking.

MOLINARI: Existem boas ferramentas de software de apoio nesta área?

CLAUDIA HAZAN:
Existem sim. No ISMA conheci uma ferramenta de estimativas, denominada SLiM. É uma excelente ferramenta. Essa ferramenta estima prazo, custo, esforço, apoia na análise de riscos. Na área de Pontos de Função, conheço a ferramenta Function Point Workbench. Na área de definição de indicadores, temos o PSM Insigh.

MOLINARI: Até que ponto métricas podem ser usadas
para controlar um Projeto de Software?

CLAUDIA HAZAN:
Podemos definir indicadores para acompanhar o progresso do projeto, a evolução de requisitos. O modelo PSM (Practical Software Measurement) tem sido utilizado para a definição de indicadores e implantação de processo de medições. De fato, a área de medições e análise está contida no nível 2 do CMMI, demonstrando o reconhecimento da implantação de um processo de medições logo no início da jornada em busca da Qualidade Total.

MOLINARI: Quais as novas tendências na área métricas?

CLAUDIA HAZAN:
Um dos Comitês do IFPUG está definindo um método para avaliar tamanho de requisitos não funcionais. Isso é muito importante no cenário atual da indústria de software brasileira, que está estabelecendo contratos baseados em preço/Ponto de Função. É importante definir preço variável para o Ponto de Função porque o esforço e consequentemente o custo para implementar um Ponto de Função é variável, devido aos requisitos não funcionais. Mas, como avaliar de maneira objetiva essa variação? Eu penso que uma métrica que trate tamanho de requisitos não funcionais pode ajudar. Outro tema importante para a pesquisa é a utilização das medições no apoio à Governança de TI.

MOLINARI: Pra terminar: dá para nos dar algumas
dicas boas de livros para quem quer aprender e se atualizar?
Sites, artigos que devemos ler com todo atenção?

CLAUDIA HAZAN:
A área de métricas possui muitos temas para pesquisa. O primeiro passo é conhecer a Análise de Pontos de Função. Assim, vou indicar a biblia Counting Practices Manual (CPM), o site do IFPUG (International Fucntion Point Users Group): www.ifpug.org, o site do BFPUG (Brazilian Function Point Users Group): www.bfpug.com.br. Depois, pode-se estudar a área de processos de medições, onde indico o site do PSM (www.psmsc.com). O livro do PSM indicado no site é excelente. Também tem a área de estimativas, modelo COCOMO II e outras literaturas específicas. A área de Qualidade de Software, modelo CMMI. A área de Gerência de Projetos, PMBoK. A área de métricas é aplicada em várias áreas. Por isso, que eu coloquei que o Consultor de Métricas tem que ter perfil de pesquisador.

MOLINARI: Muito obrigado!!!

CLAUDIA HAZAN:
Obrigado pelo convite Leo. Aproveito a oportunidade para compartilhar minha Palestra de Contratos de Pontos de Função, publicada na Conferência de Métricas ISMA, traduzida a pedido dos colegas.

=============================

Espero que tenham gostado da entrevista dela. Vejam abaixo, uma foto dela comigo em 2007, no dia lançamento de meu livro "Gerência de Configuração" na livraria Saraiva Mega Store no Centro da cidade do Rio de Janeiro.



Um abraços a todos,


Leonardo Molinari
==============================
http://diariodaqualidade.blogspot.com/
==============================

PALESTRA ESPECIAL - CLAUDIA HAZAN - Armadilhas em Contratos

Pessoal,

hoje temos um palestrante convidado no blog Diário da Qualidade: Claudia Hazan, Mestre e especialista em qualidade, métricas e em pontos de função. A sua apresentação dispensa detalhamento. Ela é um "monstro" quando se trata de qualidade e especialmente em métricas.

A palestra dela abaixo, cedida e enviada ao blog (e que pode ser vista e baixada por todos), é de altíssimo nível. Fala das Armadilhas em Contratos de Fábricas de Software. Bem... Vejam e baixem.

Boa Leitura

===================
Pessoal

Finalmente, decidi submeter um artigo para a Conferência do IFPUG – 3rd Annual International Software Metrics & Analysis Conference (ISMA). Um dia, ao abrir meu e-mail, recebi a grande notícia da aprovação do meu trabalho para apresentação no ISMA. O evento ocorreu em Setembro (14/09 a 19/09) em Washington. Estive lá apresentando meu trabalho e assistindo as palestras. Tive a oportunidade de assistir uma palestra do meu guru Capers Jones – Keynote Speaker do ISMA. Adorei a Conferência, todas as palestras foram excelentes, obtive novos conhecimentos. E fiquei feliz por compartilhar minha experiência profissional de mais de dez anos de atuação como Consultora de Métricas de Software e acadêmica, tenho realizando pesquisas na área de métricas desde 1995.

No Brasil, muitas empresas públicas e privadas têm utilizado a métrica Pontos de Função em seus contratos de prestação de serviços de desenvolvimento e de manutenção de software. O meu artigo fala de problemas nesta modalidade de contratação, iniciando pelos principais erros em contagem de Pontos de Função que tenho observado em minhas revisões e auditorias de contagem de Pontos de Função em projetos com contratos baseados em preço por Pontos de Função. Também, apresento recomendações para solucionar os problemas.
Uma mensagem: “Acredite em seus sonhos e eles se tornarão realidade”. O meu sonho de ser palestrante ou speaker em um Congresso do IFPUG se tornou real.
Segue minha apresentação traduzida para o Português, a pedidos dos colegas.

Abraços
Claudinha
==================

Palestra - Claudia Hazan na Isma - Armadilhas em Contratos de Fábrica de Software

View SlideShare presentation or Upload your own. (tags: serpro fpa;)

Link para Baixar - Clique Aqui.


Um abraço a todos e fiquem a vontade para sugerir. O espaço é aberto, e o que é bom e inovador sempre será bem vindo.


Leonardo Molinari
================================
http://diariodaqualidade.blogspot.com/
================================

Falando Sério de Qualidade: Inovação X Evolução

Pessoal,



fico triste quando falamos e usamos o termo Inovação como sendo Evolução.



Vou falar abertamente sem rodeios: Inovação é fazer algo novo ou de forma diferente, criando ou refazendo ou de forma que mudo e transforme de fato o ambiente, a empresa, ou a sociedade. Este termo é adequada a área de engenharia e administração. Evolução é uma continuação melhoria, seja de um individuo, de uma sociedade, ou de um software.

Criar um software ou uma feature num software que faça algo realmente novo é, por exemplo, inovaçao. Melhorar algo que ja existe num software é evolução. Melhorar um processo é Evolução. Criar um procedimento inédito ou um processo novo, é inovação.

Em testes de software se você criar um ferramenta, ou um processo novo, é inovação em testes de software. Se você apenas melhorou o seu teste, fazendo melhor o que já faz hoje, ou resolvendo dificuldade ou problemas é uma evolução. O ser humano evoluiu ao longo de milhões de anos. Um ser humano inovou ao criar um machado para ser usado como ferramenta.

Vemos autores, consultores e palestrantes falarem erroneamente.

Um dos maiores gurus da atualidade em inovação é Gary Hamel. O seu livro "Liderando a Evolução" da Ed. Campus é um exemplo vivo disso. Vamos a um exemplo recente: a Google. Ela tem por caracteristica ter núcleos de inovação. Ela cria o seu software, de forma inovadora, e coloca para ser usado em versão beta pela comidade. Em outras palavras. Se o software "pega", os testes e reclamações dos usuários são incorporados a mesma. Por isso muitos softwares da Google ficam sendo usados em versão beta por muito tempo. Pode ser que ela não esteja viva daqui a muitos anos, mas hoje é uma emrpesa que tem por marca a inovaçao. Isto esta fazendo com que muitas empresas passem pensar e repensar que nada substitui o potencial de criação e inovação humano.


Eu me considero, um inovador por qualidade e testes, pois sempre em busca de quebrar paradigmas e inovar. Trazer um diferencial para esta área que cercsce a cada dia...


Um abraço a todos,



Leonardo Molinari
======================================
http://diariodaqualidade.blogspot.com