segunda-feira, 30 de julho de 2007

ENQUETE - O QUE VOCÊS GOSTARIAM?

Pessoal,

em meu blog sai agora uma enquete (dentre várias que se complementarão), que visa colocar um tema (ou mais) em meu próximo livro. O que a enquete decidir, será colocado não importa o tema principal do livro (é segredo!!!!). Não posso dizer a data de lançamento do meu proximo livro, o que vocês decidirem estará lá (sem enrrolação em nível de consultoria!!!). Transparência 100% e com participação total.

Vejam ao lado a enquete!!!

Abraços e conto com todos,

Leonardo Molinari

domingo, 29 de julho de 2007

Frase da semana de 30 de julho a 03 de agosto

Amigos,

para todos nós refletirmos aqui vão duas frase ou pensamentos da semana:

"Nossas dúvidas são traidoras e nos fazem perder o bem que às vezes poderíamos ganhar pelo medo de tentar."
William Shakespeare...

"Existo, logo penso."
Friedrich Nietzsche...

Abraços

Leonardo Molinari

GERÊNCIA DE CONFIGURAÇÃO - APRENDENDO SOBRE SUBVERSION

Pessoal,

veja abaixo a ótima tríade de artigos sobre Subversion (do mesmo autor e sequência). Para quem pouco conhece desta ótima ferramenta de Gerência de Configuração, seria ótimo darem uma passada nestes links:

Parte 1: http://www.cmcrossroads.com/articles/cm-basics/introduction-to-subversion.html

Parte 2: http://www.cmcrossroads.com/articles/cm-basics/setting-up-subversion-environment.html

Parte 3: http://www.cmcrossroads.com/articles/cm-basics/part-3-%11-subversion-guided-tour.html

Literalmente vale a pena. Sem enrrolação.

Abraços, Leonardo Molinari

CONTOS TECNOLÓGICOS DE QUALIDADE - 04


TÍTULO: O PAPO DAS DLL´s CAIPIRAS


Duas dll´s caipiras (de respeito), mas amigas de longa data, resolveram sentar juntos pra conversar e matar saudades:

-DLL-A: Fala cumpadi, como vão as cosas ai na compilação do icripsi pra C-asxi?
-DLL-B: Nada bom cumpadi... os tal de analista de GCS desse sofiti novo de Gerencia de Configuração, não fizeram nada certo mano... Os cara só lê manual e quando digita algo só fais bistera... e olha que cumpadi programador que nos criou feis tudo certo... Num entendo??????
-DLL-A: Mas é simpri cumpadi... os cara tao fazendo dinheiro com essa tal sofiti de GCS. Quanto mais eles trabaia, mais ganha, e veja que já gainhó muito com a venda do sofiti... Mas comigo tá pior ainda...
-DLL-B: mas o que cumpadi? me conta...
-DLL-A: veja que o meu tal de girenti, meio metido a besta que tinha essa de mistrado, mibiai, e pos-sei-l-o-que disse que sabia imprantar o novo modelo de GCS e ao final disse isso e aquilo, e no final tá mais bagunçado ainda: saiu a GCS tradicional e entrou a GCS baseada em tarefas, gente.... mas que coisa doida. Aqui o uso de sofiti de GCS é coisa nova e em pouco tempo ele não radicalizou e mudou tudo... mas tá todo mundo doido...
-DLL-B: mas é facil de vê cumpadi: o teu girenti queria era aparecê... e o meus analista queria ganhã dinheiro facil mano...
-AMBOS JUNTOS: Eta vida besta meu Deus!...

Conclusões Obvias: Consultoria em GCS (gerência de configuração de software) é coisa séria que deve ser aplicada com experiência, ao implantar um modelo novo de GCS, digo, uma nova filosofia deve ser levado em conta a maturidade das organizações. Implantar, por exemplo, GCS baseada em tarefas numa organização com baixa maturidade é suicídio na certo, salvo quando bem acompanhada de consultoria.

Escrito por: Leonardo Molinari

Dilbert & Testes Automatizados de Software



Pessoal,


Vejam ao lado a charge do Dilbert, sobre Testes Automatizados de Software. Irônica, mas verdadeira. Vivi a pouco disto num Cliente.

Vejam agora mais outra:

Se cadastrem em dilbert.com , vale a pena. Mais que mero humor, é para você pensar!

Abraços,

Leonardo Molinari

sexta-feira, 27 de julho de 2007

Sessão Curiosidades Mensal de 07/2007



Pessoal,

a sessão curiosidades deste mês será voltada para literatura (romances).

Trataremos de um romance de Ellen Ullman, conhecida na comunidade internacional pelo seu primeiro livro Perto da Máquina (Close to the Machine) editado aqui no Brasil pela Editora Conrad. Este livro dela já tornou um cássico moderno.

O livro que estou falando agora é o seu último romance: THE BUG. Sem tradução ainda no Brasil. Bem, este livro trata do universo do BUGS DE SOFTWARE no qual é uma versão moderna de Frankstein, que trata de obsessão e solidão de um Analista de Testes que se não descobrir um BUG de software específico será certamente demitido...

É um suspense de respeito, principalmente para quem é da área. O final é mais surpreendente ainda no qual devemos todos refletir. Li o livro a cerca de uns 6 meses atras e valeu a pena!

Recomendo: leiam este livro pois é uma grande lição de vida.

Ellen Ullman é consultoria de informática e escritora. Torço para que saia a versão deste último em português.

Para quem quer conhecer mais de seu trabalho vejam os links:

Entrevista: http://www.acm.org/ubiquity/interviews/e_ullman_1.html
Review do Livro: http://www.mostlyfiction.com/contemp/ullman.htm

Abraços e Boa Leitura,

Leonardo Molinari

quarta-feira, 25 de julho de 2007

FREE BOOK: Livro de Testes de Software para Download



Pessoal,

segue abaixo o link para download free do livro Software Testing and Internalization. É um ótimo livro de testes, que está em inglês e é util para os que querem aprender um pouco. Na minha avaliação está em nível intermediário, não sendo um livro "básico" para quem deseja iniciar mas mesmo assim é uma ótima leitura e por ser free (isto mesmo!) não há problema.

Aqui a transparência é máxima e honesta. Veja o link mais abaixo:
http://www.automation.org.uk/downloads/documentation/galileo_computing-software_testing.pdf

Agora em contra-partida leiam o livro, que está em inglês, e me digam o que acharam dele. É uma via de mão dupla. O feedback de todos é importante.

Abraços e Boa Leitura,

Leonardo Molinari
===============
lm7k@yahoo.com.br

MERCADO DE QUALIDADE X OPENSOURCE: HP COMPRA EMPRESA DE SEGURANÇA




Pessoal,


a alguns dias atrás a HP, que já havia comprado a Mercury ano passado e apenas alguns dias depois que a IBM anuncio a compra de outra empresa na mesmo setor, anunciou a compra da empresa SPI Dynamics, especializada em soluções e produtos para Testes de Segurança em aplicações WEB. Foi literalmente uma reação rápida da HP devido ao movimento da IBM no mesm segmento. Como a HP possui a Mercury, detentora mundial de ótimas soluções em testes de software, principalmente em segmento Web, agora reforça o seu espectro de soluções no ambiente Web.

As ações e reações da IBM e da HP não são novidade, pois o Gartner já Group havia detectado uma demanda do mercado Web por parte dos clientes que andavam reclamando que a parte de segurança Web estava falha, ou era dada pouca atenção. Empresas como Microsoft e outras já vem se movimentando forte neste setor devido as "ameaças virtuais" cada vez maiores.

No caso da HP o reforço da compra da SPI vem a indicar o maior desejo da HP: continuar na liderança do Mercado de Qualidade de Software (leia-se aí "testes") , que já era liderado por ela com a compra da Mercury.

Por mais que sejam movimentos "de gigantes" o mercado continua na direção das acomodações (leia-se compra e venda e grandes empresas nesta área). A própria Microsoft tem desenvolvido soluções de Testes para testes de Aplicações de seus produtos, mas que ainda estão distantes das mais maduras do mercado. Não me espantaria se ela comprasse algum "grande player de testes" que ainda esteja disponóvel no mercado com a Empirix ou outra.

O fato é que parte destes movimentos é causado pela força do movimento Opensource (nao se espante). Estas empresas perderam muitos clientes (ou aumento de novas receitas) que pagavam "caro" para o maior concorrente de Todos: soluções Opensource de Testes.

Você pode ser contra ou fazer propaganda contra, ou não gostar mas não tem como evitar: as ferramentas Opensource de testes estão amadurecendo cada vez mais e estão um tomando espaço que lhe é de direito. Não tem como evitar a verdade e ficar na defensiva malhando as ferramentas "cuidado com Opensource, eles não estão ainda bons, são ruins, não tem suporte, não tem isso, não tem aquilo". Seja realista: o Opensource de Testes está tornando cada vez mais acessível a automação a quem antes não podia ou não queria. E existem algumas ferramentas opensource que estão aí que nem preciso falar como RTH, Testlink, OpenSta, JUnit, JMeter, JCoverage, etc...

O fato é quem está na defensiva não vê que está perdendo mercado naquilo que atrai mais cliente: transparência e ousadia com Qualidade e experiência, transformação positiva com inovação. Tem lugar ao sol para todos, mas não adianta garantir o querendo ser anti-ético.

A verdade está lá fora... :)

Vejam link abaixo com uma reportagem no Gartner Group:
http://www.gartner.com/resources/149700/149777/hps_spi_dynamics_buy_sets_tr_149777.pdf

Abraços,

Leonardo Molinari

segunda-feira, 23 de julho de 2007

VIDEO: DIFERENÇA ENTRE DEFEITOS E FALHAS

Olá pessoal,

este é mais um video meu no YouTube, agora explicando a diferença entre defeitos e falhas na área de Testes.

AVISO: Algumas pessoas questionaram o fato de haver uma apresentação minha prévia no vídeo (já nasce polêmico e isto é ótimo). Mas esta apresentação prévia está com cerca de 35 segundos. O vídeo foi projetado (isto mesmo!) para ser o mais genérico possível e que permita que a pessoa que venha do YouTube acesse o Blog também, conhecendo outros assuntos publicados aqui. Por uma questão de educação eu me apresento e faço referência a este Blog, não tem como evitar dado o sucesso do mesmo. O enfoque é ser didático, pois certos conceitos são melhores explicados "ao vivo" do que meramente através de texto. Isto não quer dizer que os próximos videos no YouTube não venham a ser melhorados e otimizados, afinal a transformação é constante!!! Muito obrigado a todos pelo retorno constante. Lembrando: não apenas reclamem de braços cruzados, mas também ajudem na transformação contribuindo de forma positiva, e que os textos aqui ajudem a todos a trilhar o caminho do sol...

Abraços Sinceros a Todos....

Leonardo Molinari

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

Veja abaixo o vídeo:



QUALITY DIARY SUCCESS ALL AROUND THE WORLD


Pessoal,

vejam uma amostra honesta do sucesso do Diário da Qualidade ao redor do Mundo, através de uma amostra (dentre várias) significativa dos visitantes a este BLOG. Para quem não sabe meus livros e artigos são conhecidos não somente no Brasil, mas na America Latina (do México ao Chile) como um todo e na Europa. Transparência é assim pessoal... :)

Bem-vindos!!! Wellcome!!! Bienvenidos !!!

Leonardo Molinari

Para pensar HOJE!!!



Amigos,

para todos nós refletirmos aqui vai um pensamento especial para o dia de hoje:

"Do optimization all around, including you, transformer yourself!!!"
Do autor aqui em questão em 2007 numa palestra...

Abraços

Leonardo Molinari

ps: Vejam uma nova série de artigo sobre Otimização de Sistemas aqui no Blog!!!

domingo, 22 de julho de 2007

Otimização Sistemas - Parte 01 - Visão MAcro



Artigo: Otimização Sistemas - Parte 01 - Visão Macro

Autor: Leonardo Molinari


Pessoal,

estarei publicando em várias partes ao longo das proximas semanas, uma série de fast-issues (artigos rápidos) que tratam da otimização de sistemas que suportam e apoiam o negócio. Digo isto pois estaremos estudando e vendo um conceito pouco conhecido no Brasil como BTO (Business Tecnology Optimzation). Sim, caro leitor: OTIMIZAÇÃO. Isto passa por tudo que apoia e suporta o negócio da empresa: processos, programação, gerencia de configuração, testes, requisitos, performance de aplicativos, VOCÊ inclusive, etc. Veremos como otimizar cada área e torná-la mais agil em novos patamares.

Antes de começar vou traduzir o que quero dizer de forma mais simples adequada ao foco dos artigos:


OTIMIZAÇÃO = COMO FAZER MELHOR O QUE FAÇO


Então veremos tudo mais detalhado a seguir...

De vêm o termo BTO?

Em 2002 o Gartner Group um novo quadrante tecnologico, dentre vários que ele vive detectando nas tendências de negócio, que se resume no seguinte: antes de comprar ou usar uma nova tecnologia avalie e use o que você já tem em mãos. Otimize-a o máximo possível. Não gaste dinheiro a toa somente por gastar. Veja se o negócio realmente precisa. Umas das razões desta tendência é o fato dos custo em TI terem crescido vertiginosamente. Qualquer erro em TI, e lá vai milhares ou milhões de dolares pelo ralo.

O que é OTIMIZAÇÃO ?

Otimização é um termo oriundo da engenharia, sendo uma área desta, que trata da melhoria do desempenho de um sistema qualquer ou estrutura ou processos de negócios envolvidos. Otimização faz uso de alguns pontos:

-Uso de computação para a solução de alguns problemas;
-Aplicação de mátemática na análise e solução de problemas;
-Uso de regras e modelos de modo a respeitar tempo, custo e risco;
-Uso de computação da alto desempenho no apoio a sistemas e para sobrevivência dos mesmo, pois existem sistemas que necessitam de um alto desempenho;
-Melhoria dos resultados e soluções obtidos para qualquer sistema;

Quais as grandes área que compõe BTO?

BTO se compõe das principais grandes áreas:

-Reengenharia de Processos;
-Melhoria da Qualidade;
-Engenharia de Otimização;
-Performance Tunning;

Qual a aplicabilidade de BTO em Sistema de Informações?

É aplicável nas áreas:

-Gerência de Projetos;
-Gerência de Requisitos;
-Modelagem de Sistemas;
-Programação de Software;
-Projeto de Hardware;
-Gerência de Defeitos;
-Gerência de Configuração;
-Gerência de Testes;
-Melhoria de Desempenho de Sistemas;

Livros de Refência?

Um dos meus livros publicados trata exclusivamente deste tema:




Fontes


  • MOLINARI, Leonardo. Gerência de Configuração - Técnicas e Práticas no Desenvolvimento do Software, Editora Visual Books, 2007, Florianópolis, 85-7502-210-5.


  • ___________. Gerência de Projetos - Técnicas e Práticas com Ênfase em Web, Editora Érica, 2004, São Paulo, 85-7194-0050.


  • ___________. BTO - Otimização da Tecnologia de Negócio, Editora Érica, 2003, São Paulo, 85-7194-9506.


  • ___________. Testes de Software - Produzindo Sistemas Melhores e Mais Confiáveis, Editora Érica, 2006, 3a Edição, São Paulo, 85-7194-959X.



  • STICKYMINDS. Endereço: http://www.stickyminds.com/. Acesso em julho de 2007.

Frase da semana de 23 a 27 de julho

Amigos,

para todos nós refletirmos aqui vai uma frase ou um pensamento da semana:

"Toda visão depende de um ponto de vista, e se você tiver olho para vê-la."
Do autor aqui em questão em 2003 numa palestra...

Abraços

Leonardo Molinari

quinta-feira, 19 de julho de 2007

MAIS UMA PROVA: Retorno do Sucesso do Diario da Qualidade



Pessoal,


dentre vários posts e retornos do ótimo sucesso do DIÁRIO DA QUALIDADE, estou colocando um em destaque devido a ajuda que este Blog tem dado. É uma amostra que reflete uma simples verdade. Obrigado a todos que passam por aqui. Vejam inclusive os comentários de outros posts!!!


Não deixem de passar, de vez em quando no meu site outro site pessoal, com menos atualização, mas com artigos e palestras uteis a todos: http://geocities.yahoo.com.br/lm7k/testes.html


Vejam abaixo o comentário (postado com a devida autorização)!!!


Abraços a todos vocês!!!


Leonardo Molinari


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


Assunto: Parabéns e Obrigado
Data:
Thu, 19 Jul 2007 09:38:06 -0300

Bom dia Leonardo
Gostaria de parabeniza-lo pelo seu blog "Diario da Qualidade". Ele possue vários artigos interessantes e estão ajudando muito os meus estudos sobre essa área de testes e qualidade.
Agradeço desde já essa sua iniciativa
[]´s
José Antonio Vella Junior

Auditeste Consultoria - Líder de Testes


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


Pessoal: transparência é assim!!!

UMA LIÇÃO DE TESTES: VOO 3054 DA TAM


Artigo: UMA LIÇÃO DE TESTES: VÔO 3054 DA TAM (O Artigo que nâo queria escrever)
Autor: Leonardo Molinari

Texto:

1 - A lição

Este é um dos piores artigos que escrevo. Não pelo conteúdo, mas pelo fato de que ninguém gosta de falar de tragédias mas as vezes temos de encarar os fatos. Meu sentimento pelo acidente do vôo 3054 da TAM, ocorrido em 17 de julho de 2007 às 18h50min é o mesmo que o da maioria: surpresa e indignação, preocupação e fé, consciência e paciência.

Se, imaginando apenas, que o vôo 3054 fosse um sistema de informações a ser entregue, um sistema Web que seria disponibilizado ao público, o que poderiamos aprender de fato? Quais as essênciais lições que precisamos aprender? Não vou aqui discutir em detalhes. Vou apenas de forma simples listar que era para ser feito e não foi feito. O que deveria e que ao "não ser feito" aumentou o risco de acontecer algo. Aumentou a probabilidade do risco. Equivale a você não querer pegar um resfriado, andando sem camisa numa manhã de 5 ºC. Neste caso qual o risco de você apanhar uma simples gripe? Muita...

O sistema web imaginário batizado de 3054 aqui, não obedeceu a alguns procedimentos importantes:

  • As máquinas Web onde estão os servidores estão funcionando perfeitamente? Estão preparadas para receber o "pouso" do sistema Web?
  • Os servidores (o "aeroporto") estão sobrecarregados antes mesmo do sistema Web entrar no ar?
  • O firewall ("torre de controle") que protege os dados e outras partes do sistemas está devidamente configurados que evitar "intrusos"?
  • Os servidores possuem espaço em disco e em memória suficientes?
  • Os requisitos de instalação ("normas intercancionais") do sistema web confere com o que foi disponibilizado (real) para instalação do sistema em produção?
  • O sistema Web foi testado (o mais proximo possivel) em termos de performance (teste de desempenho) no ambiente que espelhasse a realidade?
  • Todos os requisitos funcionais e não funcionais foram testados antes do sistema entrar em produção?
  • Ao entrar em produção em produção o sistema Web foi testado de forma minima para verificar se o mesmo consegue "entrar no ar"?
  • As contingências ("segurança") para o sistema foram definidas e testadas de modo a ter certeza que se algo falhar socorrer ("bombeiros e ambulância")?
  • A segurança das informações dos usuários ou do negócio envolvido, está garantido com o sistema no ar ou não?
  • Todos os funcionários, consultores, analistas envolvidos estão capacitados e cientes de tudo que existe e deve ser feito ?
  • O sistema recebe manutenções periódicas de modo a acompanhar seu desempenho (ser pró-ativo)?

Pessoal, por mais que alguns tópicos acima não tenham a ver com testes de forma direta, mas devemos verificar de modo que o sistema web 3054 não falhe.

Um exemplo real foi o site da Xuxa que na época a alguns atras ao entrar no ar "travou" pois a sua performance não foi testada devidamente e os equipamentos não suportaram a demanda de usuários. Foram feitos ajustes e tudo foi resolvido na época.

O problema que algumas falhas custam caro, e outras não tem preço como a vida de 186 passageiros. Por isso é de grande importância que histórico de falhas e defeitos seja sempre acompanhado para evitar desastres no futuro...

2 - Fontes

  • MOLINARI, Leonardo. Gerência de Configuração - Técnicas e Práticas no Desenvolvimento do Software, Editora Visual Books, 2007, Florianópolis, 85-7502-210-5.

  • ___________. Gerência de Projetos - Técnicas e Práticas com Ênfase em Web, Editora Érica, 2004, São Paulo, 85-7194-0050.

  • ___________. Testes de Software - Produzindo Sistemas Melhores e Mais Confiáveis, Editora Érica, 2006, 3a Edição, São Paulo, 85-7194-959X.

  • STICKYMINDS. Site: http://www.stickyminds.com/. Acesso em 15 de julho de 2007.

  • O GLOBO. Site: http://oglobo.globo.com/rio/ancelmo/reporterdecrime/. Acesso em 19 de julho de 2007.

Gerência de Configuração - Next Generation Tools


Pessoal,

a idéia agora é colocar quais as tendências da próxima geração de ferramentas de Gerência de Configuração (G.C).

O centro da nova tendência está no reforço do Planejamento dentro da G.C., iniciando com objetivos ambiciosos e agressivos. Isto mesmo: agressivos! Não perca tempo. Indo mais fundo vejamos o que você deve ficar de olho antes de você implantar ou escolhar a sua solução de G.C:

  • Automação: automatize o que pode ser automatizdo, não deixe para depois;
  • Trabalhar com multiplos-sítios de desenvolvimento: a descentralização será cada vez maior;
  • Administração Zero: administre cada vez menos (zero) no dia-à-dia. Prepare tudo e deixe seu processo fluir. Definie seus pontos de controle.
  • Tire o máximo de recursos que solução automatizada pode lhe dar;
  • Acompanhamento e Treinamento: nenhum treinamento é ideal, mas tire o máximo ao aprender algo novo, e peça acompanhamento depois. Uma experiência boa sempre é positiva;
  • Processos Cutomizáveis e Capacidade de Melhoria: se a solução automatizada não permitir isso ou se seu processo não for possível melhorar, então você já começou fechado. Nada é imutável e não existe solução perfeita, digo, panacéia;
  • Adequação a padrões de G.C.: se a ferramenta não permitir adequação aos padrões, pule fora! Nao a use! Sempre tem algo melhor;
  • Integridade e Segurança: depois do 11 de setembro nem é preciso tocar nisso;
  • Permitir o On-Demand: se alguma necessidade rápida, sob demanda não puder ser atendida, então pense nas consequências desta "inflexiblidade".

Se desejar mais detalhes, para entender de G.C., vá em meu livro novo,


e busque algumas boas referências no site abaixo:

http://www.cmcrossroads.com/w/cm-wiki.html

Não tenha medo de arriscar e você, Caro Leitor, de trocar ideias aqui. Pergunte.

"Quem não arrisca não petisca"...

Abraços,

Leonardo Molinari

domingo, 15 de julho de 2007

CONTOS TECNOLÓGICOS DE QUALIDADE - 03

TÍTULO: Um Pequeno Conto de Qualidade


Havia um grupo de amigos que trabalhavam numa empresa de desenvolvimento de software juntos a muitos anos.

Muitas vezes eles saiam juntos, em geral para um barzinho de toda sexta feira. O grupo era em sua maioria o mesmo, com ora um ora outro faltando. Ora um com a namorada, ora outro com a esposa. Falavam de besteiras, futilidades, futebol, a fofoca da semana. Era sempre assim.

Naquele dia foi diferente, pois havia um novo funcionário. E todos queriam conhecê-lo. Mas o fato é que neste dia nenhuma esposa ou namorada estava presente. Eram somente todos os amigos e pronto. Estavam de certa forma mais a vontade e mais curiosos ao mesmo tempo.

-E aí rapaz, você fica calado? Fala alguma coisa. Perguntaram para o novo do grupo.
-Tô escutando...
-Faz alguma pergunta então?
-Está bom! Mas cada um responde a pergunta e eu respondo por ultimo. OK.
-OK! (todos falaram em conjunto)

(ai veio aquela pausa sepulcral por alguns segundos)

-O que cada um pensa sobre Qualidade? Rapidinho. Vapt e Vupt!

(como ninguém se propos a iniciar, Carlos, o lider natural de todos ali, iniciou)

-Usuário sorrindo!
-Entrega no prazo!
-O chefe gastando menos!
-Código bonito e eficiente!
-Tudo testado!
-Tudo documentado!
-Meu emprego novo e com salário maior!

(todos olharam para o Arnaldo espantados pois isto era uma novidade para todos...)

-Como falei eis a minha definição: felicidade!

(todos ficaram maravilhados com a resposta simples e profunda)

-Eu acho que todas as respostas estão certas, salvando-se uma ou outra... Afirmou Carlos.

Naquele dia todos interrogaram o Arnaldo sobre o tal emprego novo. E comemoram sua "quase certa" ida para o novo "job", pois ele estava em fase de entrevista.

-Barbada! Dizia ele.

Mas a vida é assim pois as coisas sempre mudam. Não se sabe como ou através de quem, mas o "chefe" ficou sabendo do tal "quase emprego novo". E em uma semana Arnaldo foi demitido. Todos ficaram surpresos.

Ao mesmo tempo o novo funcionário, o da resposta simples e profunda, iniciava uma carreira nova e meteórica naquele instante.

Epílogo: O fato é que depois daquela reunião de sexta-feira, nada mais foi igual entre os "amigos". Sabem porque? Eles eram "quase-amigos", ou mehor, eram na verdade apenas colegas que fingiam ser amigos. Somente mais os sinceros e éticos entre si se tornaram realmente amigos. A Qualidade sempre será uma divisora, e transformadora, de águas...

Escrito por: Leonardo Molinari

Frase da semana de 16 a 20 de julho

Amigos,

para todos nós refletirmos aqui vai uma frase ou um pensamento da semana:

"Existem muitas hipóteses em ciência que estão erradas. Isso é perfeitamente aceitável, eles são a abertura para achar as que estão certas."
Carl Sagan, astrofísico...

Abraços

Leonardo Molinari

Mannnhêêê que qui é QA




















(imagem baseada em livro da Editora
John Wiley & Sons, Inc.)


Artigo: Mannnhêêê que qui é QA?

Autor: Leonardo Molinari

Texto:

1 - O porque

O título deste artigo pode parecer uma frase de criança, mas é, salvando-se as devidas proporções, uma das mais obvias questões que ninguém tem paciência de explicar. Vindo de uma criança podemos até rir, mas vindo de um adulto com anos de experiência temos que perceber que algo está errado. Vindo de um gerente com anos de experiência, temos que ficar muito preocupado. Em alguns casos não se pede que se entenda a fundo, mas alguns conceitos básicos são importantes. Quando falo de QA, digo "Quality Assurance" ou garantia da qualidade.

2 - O que não é QA

Quando falo puramente de QA podemos dizer que:

-Testes são QA? Não. Testes controlam a Qualidade mas não garantem a Qualidade. Controlar a Qualidade é na visão mais simplista é aceitar ou rejeitar algo. Passou ou não passou. Sim ou Não. Controlar a Qualidade é algo que está ao final do processo de construção ou controle de algo. Controle está no "depois". QA é ir muito mais além.

-Revisões Técnicas são QA? Não. Revisões são algo que acontecem antes do processo de construção ou controle de algo acontecer. Repito: Revisões são o "antes". QA é ir muito mais além.

3 - Afinal o que é QA

QA esta no "antes", "durante" e no "depois". QA abrange todo o ciclo de desenvolvimento. QA ocorre durante funcionamento do processo de construção (e entrega) ou controle de algo. QA abrange:

-Conformidade com padrões;
-Definição de práticas consistentes;
-Garantia que os padrões e processos são usados;
-Garantia das expectativas;
-Aprendizado constante dos acertos e dos erros, incluindo aí defeitos e falhas.
-Aplicar o que é aprendido de fato no processo.
-Testes (isso mesmo!!!)
-E revisões técnicas (isso mesmo!!!)

QA é aprender e evoluir enquanto andamos. Porém Testes tem se tornado tao importante que quase podemos distigui-lo de QA. Em geral a maioria dos autores trata mais QA como estando "mais para conformidade " e Testes "mais como controle".

4 - Moral

Se QA é caminhar de mente aberta em constante evolução. Então, a organização onde QA é praticada será um reflexo das pessoas que praticam QA. Será um organização em constante aprendizado. O lado bom de um Gerente que quer saber de QA é o fato dele estar aberto aprender. O lado ruim é se o mesmo não evoluir. Aí neste não é aprendizado. É falso aprendizado. Nenhuma organização é perfeita, mas ao pratixar QA ela evolui em busca de sua própria maturidade. Muitas organizações tem somente Testes, ou uma ótima estrutura de Testes, mas possuem uma fraca estrutura (ou nenhuma) de Testes.

5 - Fontes

  • MOLINARI, Leonardo. Gerência de Configuração - Técnicas e Práticas no Desenvolvimento do Software, Editora Visual Books, 2007, Florianópolis, 85-7502-210-5.

  • ___________. Gerência de Projetos - Técnicas e Práticas com Ênfase em Web, Editora Érica, 2004, São Paulo, 85-7194-0050.

  • ___________. Testes de Software - Produzindo Sistemas Melhores e Mais Confiáveis, Editora Érica, 2006, 3a Edição, São Paulo, 85-7194-959X.

  • STICKYMINDS. Site: http://www.stickyminds.com/. Acesso em 15 de julho de 2007.

  • QUALITY TECHNIQUES NEWSLETTER. Site: http://www.soft.com/News/TTN-Online/. Acesso em 15 de julho de 2007.

segunda-feira, 9 de julho de 2007

Frase da semana de 9 a 13 de julho de 2007

Amigos,

para todos nós refletirmos aqui vai uma frase ou um pensamento da semana:

"Acredito que aprendemos e avançamos sempre. Somos sempre postos à prova."
Ayrton Senna (1955-1994), piloto campeão brasileiro de F1...

Abraços

Leonardo Molinari

URGENTE: Dimenões de Testes X Certificações















Artigo: URGENTE - Dimensões de Testes X Certificações

Autor: Leonardo Molinari

Texto:

1- Qual a real a motivação de escrever este artigo?

Pessoal,

muitos autores não fazem isto, mas por ser por demais polêminco este artigo, resolvi tratar
de justificar-me antes para todos poderem entender a essência da realidade.

Todos temos qualidades e defeitos, enquanto ser humano. Para cada um realizar seus sonhos o
verdadeiro céu é o limite. Tudo depende de esforço, foco e saber criar e aproveitar as
oportunidades. Papo de motivação? Sim e não, pois muitas coisas que são verdadeiras são
frutos de alguns atributos da persolnalidade humana: coragem, simplicidade e fé. Existem
outros atributos e destaco esses três acima.

No meu caso quando falo de coragem é porque ao longo dos anos fui cercado de observações e
troca de idéias devido a minha ousadia em escrever artigos, livros e dar palestras de uma
forma aberta, afinal a melhor informação na minha visão não é aquela escondida mas aquela
melhor repartida e divida. Existem autores que finjem que escrevem, para deixar o
conhecimento para um curso. Todos querem seu lugar ao sol, mas a ética para alguns fica em
segundo plano. Não é meu caso.

Quando falo de fé, é em acreditar que não podemos desistir, devemos acreditar que com
esforço podemos ir mais além. Tanto a derrota como a vitória começa dentro de nós.

Quando falo de simplicidade, digo que ninguém é melhor que ninguém e que, na minha visão, cada um de nós tem um papel para contribuir fazendo parte de uma engrenagem maior. Podemos criar conhecimento através de duas visões tomando como base um elemento qualquer: ou esse conhecimento pode ser simples de modo a captar verdadeira essência do que quer representar, ou podemos criar algo complexo colocando conhecimentos diversos para gerar algo que mesmo sendo elementar é complexo e dífícil de se entender. Tenho observado que quando a essência é simples podemos construir novos conhecimentos mais complexos a partir destes, tal qual uma criança brinca com brinquedos/tijolos de encaixe, tipo "lego", de tal forma pode montar novos "brinquedos" a partir das pequenas peças.

Em julho deste ano vi um filme lindo para crianças mas que possui muita complexidade adulta:
Ratatouille, uma animação da Pixar/Disney. Não vou entrar em detalhes do filme, mas o fato é
que a história gira em torno de um ratinho que tem habilidades para cozinhar e que desejava
ser chef de cozinha.

O fato é que coragem, simplicidade e fé foram os atributos destacados pelo pequeno heroi no
filme acima. È importante fazer lembrar, que alguns gerentes e executivos usam o processo de
cozinhar em suas casa como um lazer, usando isto como um processo de revisão e aprendizado. Cozinhar é para cada prato um "mini-projeto". Seleção e levantamento dos ingredientes. Fazem parte de cozinhar: organização, gerenciamento do desenvolvimento e entrega, é claro, do prato, colocando-o em produção, ou melhor, na mesa para devida degustação. O fato é que isto faz lembrar algo mais importante: simplicidade. Quando lidamos com coisas básicas tendemos a olhar as coisas e rever as coisas na ótica da simplicidade. Muitas coisas maravilhosas são simples.

A essência do meu "META-MODELO DAS DIMENSÕES DE TESTES", ou modelo de dimensões de testes (ou apenas DIMENSÕES DE TESTES) é a SIMPLICIDADE. É um modelo que permite criar modelos e entender os tipos de testes, técnicas (e que se confundem com tipos de testes), testes de uma maneira mais simples. Mais a frente você o entenderá de uma maneira simples.

Aqui a minha coragem de escrever este artigo é porque o mesmo modelo está em todos os meus 3 primeiros livros (TESTES DE SOFTWARE, BTO, GERENCIA DE PROJETOS) da Ed. Érica. O meu livro de Testes é usado como livro base em certificação aqui no BRASIL. Ao mesmo tempo meu modelo é muito similar a um outro modelo exposto em outro livro que coincidentemente usa apenas "uma dimensão a menos" (ou sem uma das dimensões de meu modelo original), e no caso nenhuma fonte de fato é citada na página de exposição. Pode ser coincidência, pode ser algo novo, mas meu livro veio antes e é citado nas referências ao fim do livro usado livro principal da certificação. Tudo bem, o leitor ganha ao ver diversos pontos de vistas e maneiras de pensar, mas como se trata de uma certificação, pode haver dualidade. Então eu proponho algo simples que já deve estar sendo posto na prática: usem o modelo do outro livro que tem maior peso para quem quer tentar se certificar, porém usem o meu modelo se quiserem criar e montar modelos e usar testes na prática. Não há problema nenhum e é saudável.

Um outro ponto importante, é que para QUALQUER um que deseje contra-argumentar o meu artigo aqui, peço que o faça aqui de modo a não sobrecarregar outros foruns. Eu mesmo não
responderei questões e duvidas deste artigo se as mesmas não forem colocadas aqui no meu blog. Objetivo: Transparencia.

Caro Leitor, sem as considerações acima, principalmento no que se refere a "simplicidade"
você não entenderia a essência "simples" do META-MODELO DAS DIMENSÕES DE TESTES.

2- Para que serve o META-MODELO???

O META-MODELO DAS DIMENSÕES DE TESTES é aberto. Você ou qualquer um pode usá-lo para criar novos modelos e metodologias de testes.

Ele é um modelo que serve para avaliar e criar (principalmente) novos modelos. Você pode até "pegar" uma metodologia ou um modelo atual e "jogá-lo" no META-MODELO e verá que todos os modelos existentes podem ser derivados destes. Estaria fazendo neste caso uma engenharia reversa.

3- Antes: Qual o maior problema em todas as literaturas de testes?

O maior problema é definição dos tipos de testes, técnicas. Todos os autores "literalmente"
batem cabeça quando se trata de definir algo pois um muitos casos diversos autores criam e recriam conceitos confundindo mais ainda a cabeça das pessoas. Estou errado? No Brasil por mais que tenhamos a ABNT, e ela possui em seus autos definições de diversos tipos de testes, não é levada a sério em alguns casos. Diferênças básicas como "o que é um defeito e o que é um bug (ou falha)?" não são explicadas corretamente. Em meu livro de Testes coloco com glossário o que a ABNT define em termos "oficiais" explicando em detalhes. Tento ensinar.

4- Como O META-MODELO resolve o maior problema das literaturas de testes?

Simples: tudo são testes. Tudo são tipos de testes que possuem cada uma categoria. Isto mostra
que podemos realizar mais de um tipo de teste ao mesmo tempo. SIMPLICIDADE É SUA ESSÊNCIA.

REPITO: TUDO SÃO TIPOS TESTES... E é verdade. Por exemplo, podemos fazer um teste funcional com um unitário ao mesmo tempo. Podemos fazer um caixa-branca com funcional ao mesmo tempo.

Calma... Não se questione tanto. ABRA SUA MENTE. A simplicidade é a essência aqui. Percebi
os tipos de testes que tem algo em comum e agrupei-os de forma natural.

Mas e a técnica? Você está louco?? Não Caro Leitor. Memso quando estivermos tratando de
"técnicas de testes" mais complexas elas são também testes.

5- Quais as dimensões ou grupos do META-MODELO???

No meu livro de Testes de Software na pagina 58, topico "Dimensões de Testes", agrupo os
tipos de teses em 4 dimensões:

a) META: tipos de testes que lidam com objetivos. Teste Funcional, Performance, Carga,
Aceitação de USuário, etc;

b) MOMENTO: é tipo de teste que está ligado ao momento de teste (em termos do clico de vida
do objeto a ser testado), ou profundidade. Testes unitário, integração, sistemicos,
pós-produção, etc.

c) TÉCNICA: tipo de teste ligado mais ao "como se testa" do que ao "precisamos testar". Teste de Caixa-Branca, Caixa-Preta, Caixa-Cinza, etc.

D) AMBIENTE: tipo de teste que está mais ligado ao ambiente físico, ou imaginário, de teste.
Teste WEB, Teste MainFrame, etc.

6- Como vou usar o meta-modelo???

Se você tem dúvidas quanto aos tipos de teste, aqui você vê que claramente que podemos distinguir um tipo de teste de outro tipo.
Um exemplo clássico de confusão é entre Teste Funcional e Teste de Caixa-Preta. No primeiro
você tem objetivo de testar as funcionalidades do sistema ou do objeto-alvo de teste, no
segundo você trata o objeto de teste como uma caixa-preta, testando suas combinações de
saidas e entradas. O problema é que muitos não querem explicar.

Se você quer criar um modelo de testes, pense da seguinte forma: O ideal seria você testar
todos tipos de testes e em todas as dimensões. Mas na prática usamos duas dimensões no
máximo ou usamos poucos tipos de testes por dimensão. Se colocar num gráfico simples, você
verá sub-conjunto maiores.

Ele pode ser usado para medir o nível qualidade.

7- E os processos e atividade que compõe uma metodologia???

E o processo ??? E as atividades??? Não são aqui. Quando você os define os tipos de testes
e sua amplitude, temos um "meta-modelo". Quando começarmos colocar os papeis, atividades,
etc, veremos que isto são "instaâncias" ou particularidades de cada ambiente. Aí é a
implementação de um processo típico qualquer: Papeis, atividades, dependências, etc. Neste ponto vemos nascer um modelo ou uma metdologia

8- Existe prova concreta de uso do META-MODELO?

Sim. Desde 2002 tenho usado ele em diversas empresas, treinamentos, palestras e
principalmente em consultorias especiais. Cito o caso de um Banco na Venezuela que usei o
META-MODELO para reorganizar o processo de testes. Montei em minutos o modelo, e com isto pude derivar um novo modelo corrigido. Detectou-se problemas com o modelo real anteriormente usado que foi corrigido em pouco tempo com o novo modelo derivado do META-MODELO.

9- Posso criar coisas novos com o META-MODELO???

Sim!!! Você pode e deve fazê-lo. Eu por exemplo percebi a existencia de outros dois tipos de
testes que pertenciam a mais de uma dimensão. E nao era uma terceira dimensão. Era OUTROS
TESTES. Ambos foram expostos no Congresso da ALATS no Rio de Janeiro. Já falei destes outros artigos e breve estarei trazendo-os novamente.

ISTO MESMO: criei, ou melhor, percebi novos tipos de testes!!!!

10- Qual o meu grande desafio para com o META-MODELO???

O meu grande desafio é provar que eu não posso derivar um modelo ou metodologia deste. O grande desafio é encontrar uma "bug" no modelo que o derrube, ou o que reorganize. Pois até agora, todos os modelos conhecidos podem ser derivados do META-MODELO DAS DIMENSÕES DE TESTE. Sabe porque? A simplicidade permite que ele possa ser genérico de fato.

Caro Leitor, você aceita o desafio?... Um exemplo "clássico de derivação" aqui seria que o
famoso modelo "V" é um mero Sub-Conjunto do META-MODELO. Caracterizando que podemos derivar um modelo "V" do Meta-Modelo... Veja imagem acima.

Lembre-se: o META-MODELO É UM MODELO PARA CONSTRUIR MODELOS.

Em outro artigo aqui no BLOG estarei entrando em detalhe passo-a-passo de como criar modelos usando o META-MODELOS.

Veja no inicio deste artigo a imagem e tenha noção macro de como criar modelos.

11 - Fontes

  • MOLINARI, Leonardo. Gerência de Configuração - Técnicas e Práticas no Desenvolvimento do Software, Editora Visual Books, 2007, Florianópolis, 85-7502-210-5.

  • ___________. Gerência de Projetos - Técnicas e Práticas com Ênfase em Web, Editora Érica, 2004, São Paulo, 85-7194-0050.

  • ___________. Testes de Software - Produzindo Sistemas Melhores e Mais Confiáveis, Editora Érica, 2006, 3a Edição, São Paulo, 85-7194-959X.

quinta-feira, 5 de julho de 2007

MAMÃE EU QUERO MEU ROI !!!












Artigo: Mamãe Eu Quero Meu ROI
Autor: Leonardo Molinari

Texto:

1 - A canção

"Me dá meu ROI, me dá meu ROI, me dá meu ROI que eu quero mamá"... esta frase lembra nitidamente uma antiga marchinha de carnaval, onde na letra o ROI era a "chupeta". Mas o que isto tem a ver com Testes e Qualidade ? Tudo. Todos os gerentes, diretores, analistas, desenvolvedores, seja de forma direta ou indireta estão atrás de sua "chupeta". Em geral, estão sempre brigando, chorando, e em muitos casos até sorrindo pois quem não quer ter uma ótimo ROI, ou melhor, "chupeta"? E o uso de uso de Testes de software, de forma consciente e fazendo uso da automação, com certeza haverá um ROI claro onde todos ganharão. Vamos analisar alguns aspectos positivos do ROI em testes de software.

Antes porém: ROI => return on investiment (retorno sobre o investivemento em algo, numa tradução livre), também conhecido como popularmente como "custo/benefício".

2 - Sobrevivência

A forma como muitas empresas usam Testes de Softwares, muitas merecedoras de grandes elogios, é para apenas sobreviver. Mas onde está o ganho afinal ? O ganho está na utilização otimizada de Testes. Quando uma nova implementação chega em produção o que vem com ela? Upgrades, novas features, alterações, manutenções programadas, de tudo e um pouco o que você pode imaginar. Mas se o Teste for feito de forma extensa, planejada e adiantada, poderemos acrescer além dos testes das novas funções (ou das funções alteradas) testes de regressão de todas as outras funções. Porém hoje em dia somente com automação dos Testes podemos realizar um grande número de Testes em pouco tempo. Quando falamos de Testes, temos que ter em mente temos um prazo a cumprir e um nível de Qualidade a ser atingido.

3 - Transformação

Para conseguirmos a transformação otimizada com o uso de Testes, devemos observar:

  • Histórico de defeitos e problemas => cada um destes vira um Teste.
  • Criar previamente "Testes" moldes => estes são usados e reutilizados seja no planejamento seja na execução automatizada dos Testes.
  • Otimizar o processo de Testes atraves da revisão do processo de desenvolvimento de forma constante => tudo que é otimizado no desenvolvimento tem impacto nos Testes, nem que seja a redução de tempo que permitiria sobrar mais tempo para realizar mais Testes.
  • Adoção de forma rápida da novas funções => implica que se depois dos testes, tivermos um processo de validação pelos usuários teremos mais tempo, dado um mesmo cronograma para testar.
  • Criar confiança => permitir a participação do usuario (até onde for possível) no Planejamento ou validação dos Testes. Isto cria um clima de confiança e transparência único.
  • Não tenha MEDO => não tenha medo de escutar todos os envolvidos de modo claro, pois teoricamente todos querem o bem da empresa.
4 - Eu quero meu ROI

Se aplicarmos as orientações acima (IMPORTANTE), independente de fórmulas matemáticas, teremos nitidamente um ROI. Todos ficarão felizes.

5 - Eu quero mais ROI

Se assim mesmo você precisar de números na prática (eu vivi isto), e isto pode ser visto em diversos artigos, podemos ter a grosso modo pelo menos 1/3 de ganho de tempo. Reduzindo tempo pouparemos gastos. Está aí o seu "ROI"!... Se mesmo assim te pedirem fórmulas matemáticas, veja o artigo do ARIELI citado nas fontes. Este propõe uma formula matematica que demosntra o quanto o quanto o quanto o quanto o quanto (não é erro de digitação leitor pois a intenção da frase é esta mesmo!) ganharemos em detalhe. Quanto mais repetirmos os Testes (e repetirmos!!!) mais pouparemos e maior será o ROI, isto é, a "chupeta".

Preferi nesta versão deste artigo que o leitor vá nas refererências originais. Porém existem várias formulas, com mais ou menos as mesmas variáveis que podem ser usadas para demonstrar um ROI.

Go ahead, do not be afraid!!!
6 - Grande Conclusão
O ROI em Testes se dá através de, além do fato de encontrar Falhas e Defeitos, em poupar tempo em outras atividades ao redor e no fato de poder testar cada vez mais em menos tempo, ou na pior hipótese testar mais no mesmo tempo.

7 - Fontes

  • MOLINARI, Leonardo. Gerência de Configuração - Técnicas e Práticas no Desenvolvimento do Software, Editora Visual Books, 2007, Florianópolis, 85-7502-210-5.

  • ___________. Gerência de Projetos - Técnicas e Práticas com Ênfase em Web, Editora Érica, 2004, São Paulo, 85-7194-0050.

  • ___________. Testes de Software - Produzindo Sistemas Melhores e Mais Confiáveis, Editora Érica, 2006, 3a Edição, São Paulo, 85-7194-959X.

  • HAYES, Linda. Testing, Ka-Ching. Site: http://www.stickyminds.com/.

  • ARIELI, Guy. Simple ROI model for Testing Automation projects. Site: http://www.stickyminds.com/

domingo, 1 de julho de 2007

Frase da semana de 2 a 6 de julho de 2007

Amigos,

para todos nós refletirmos aqui vai uma frase ou um pensamento da semana:

"A verdade será sempre a verdade, mesmo por falta de compreensão, descrença ou ignorância."
W. Clement Stone (autor americano)...

Abraços Leonardo Molinari

Falando de Requisitos


Pessoal,

Vamos aos poucos entender de Requisitos.
Veja antes acima a figura exemplo de construção de um balanço em uma árvore – Processo de Entendimento.
Muitas vezes o usuário desejava algo simples, porém a descrição e o entendimento devem ser claros e detalhados e simples. Vejamos o dialogo abaixo para podermos ilustrar melhor:
  • Usuário: “Eu preciso de uma Pedra”.

  • Vendedor: (depois de muito procurar) “Está aqui a sua Pedra. Ela é bem grande, como pode-se ver”.

  • Usuário: “O que eu precisava era de uma Pedra pequena”

  • Vendedor: (depois de novamente procurar) “Aqui está a sua Pedra bem pequena”

  • Usuário: “O que na verdade eu precisava era de uma pedra pequena, mas não tão pequena, e de cor azul”.

  • Vendedor: (depois de muito procurar) “Aqui está”.

  • Usuário: “Era isso que eu queria”.
O que o usuário queria na verdade era uma simples pedra pequena de cor azul. A razão da necessidade aqui não importa, mas em muitos casos existem justificativas e entendimentos que se tornam Requisitos.

Para entender de Requisitos devemos ver uma importante diferença na área da Tecnologia da Informação:


  • Engenharia de Software: área da Engenharia voltada para construção do Software em todas as suas etapas, fazendo uso diversas técnicas, práticas e de áreas especificas da Tecnologia da Informação;

  • Qualidade de Software: área voltada para Garantia da Qualidade do Processo e do Produto relacionado a Software, fazendo uso de técnicas, práticas, métodos e de áreas especificas da Tecnologia da Informação.

A Gerência de Requisitos está nas duas áreas, é tão importante que existe toda uma linha de soluções, técnicas e estratégias no mundo, mas que é somente nos últimos passou a ser explorada no Brasil.


É importante que se perceba que a evolução de novas tecnologias e metodologias acabam marcando toda uma historia. É o caso aqui em Requisitos, pois os 3 primeiros marcos abaixo são fundamentais para o que hoje conhecemos como Gerência Requisitos:



  • 1977 – Primeiros artigos publicados sobre como tratar Requisitos de usuários e de afinidades léxicas na extração de requisitos. Destaque para o artigo de M.W Alford: “A Requirements Engineering Methodology for Realtime Processing Requirements,” IEEE Transactions on Software Engineering.

  • Anos 1980 – se começa a falar e a difundir os Requisitos de Usuários, em função das necessidades no Processo de Análise e Levantamento de Sistemas.

  • 1993 – Torna-se efetivamente uma disciplina efetiva dentro de Engenharia de Software a partir do “I International Symposium on Requirements Engineering” (Primeiro Simpósio Internacional de Engenharia de Requisitos). Este é um grande marco quando falamos de Requisitos.

  • Entre 1993 e 1996 – Surgimento das primeiras ferramentas de Gerência de Requisitos, tais como Doors da Telelogic e outras.

  • Final dos anos 1990 e inicio dos anos 2000 – pressão do mercado sobre qualidade (CMM e ISSO) alavanca Requisitos; acirramento da concorrência entre ferramentas de requisitos.

  • Início dos anos 2000 – explosão de metodologias ágeis e “leves” voltadas para Requisitos.

  • 2005 – surgimento das primeiras ferramentas Opensource de Gerência de Requisitos.

  • 2006 – surgimento das primeiras ferramentas de Requisitos que tratam do problema da dispersão geográfica entre usuários que manuseiam Requisitos.

Bem... falar de requisito vai muito mais além. Vamos agora o que é terminar este artigo, com o que é Requisito (por mais que existam várias definições):



O Requisito é algo que um produto ou sistema qualquer precisa
fazer ou precisa ter.


Abraços,

Leonardo Molinari

Sessão Curiosidades Mensal de 06/2007

Inicio agora um tópico mensal de curiosidades sobre coisas mostram que Qualidade pode ir onde nunca imaginamos.

Você sabia que existe um super-herói que possui poderes baseados em Testes???...

Sim!!! É o super-heroi chamado Karnak, dos Inumanos, que já confrontaram o Quarteto Fantástico, na linha da Editora americana MARVEL. O lider dos Inumanos é famoso Raio-Negro...

Um dos principais poderes de Karnak (talvez o principal) é descobrir o ponto de stress num objeto sólido e atingi-lo através de um golpe simples. Com isto ele pode derrubar paredes, pessoas, placas de aço puro... Em outras palavras: ele descobre a falha no objeto e o atinge...
Na verdade os poderes dele são baseados em Testes em Materiais. Existe uma cadeira em Engenharia chamada de Resistencia de Materiais usada muito em construção civil. Isso mostra o quanto Testes podem servir de poder. Lembrando que o mestre "Stan Lee" foi o seu criador.

Abraços,

Leonardo Molinari