TRIZ – Teoria da Resolução de Problemas Inventivos

Pessoal, hoje vou falar sobre essa metodologia que se propõe a ajudar em algo que é muito comum em nosso dia a dia, os problemas.

Os problemas em uma organização de TI, geralmente são os geradores de conflitos, que podem ser entendidos como situações de oposição, desacordo ou incompatibilidade entre pelo menos duas pessoas ou grupos.

E podemos ter duas visões a respeito dos conflitos:

  • Conservadora: Eles tendem a considerar os conflitos como indesejáveis. Sendo causados por pessoas problemáticas, que insistem em não ajustar-se e devem ser, sempre e assim que possível, suprimidos.
  • Progressista: Os conflitos são encarados como inevitáveis. Se geridos com habilidade, podem ser muito benéficos, contribuir para o desenvolvimento das pessoas e organizações e revelar questões importantes, como, por exemplo, as falhas que uma determinada solução que estava para ser adotada continha.

Na área de Teste de Software estamos sempre descobrindo problemas e ao relatar tais, podemos acabar gerando conflitos, devido a existência de pontos de vista diferentes, por exemplo: a equipe de Teste percebeu uma inconsistência e falta de padrão na maneira de validação dos campos, que hora é feita com caixa de mensagens (message box)  e hora utilizando rótulos (labels)  e decide reportar tal problema para a equipe de desenvolvimento, que por sua vez entende que isso não é um problema, pois a validação é feita de acordo com cada formulário, podendo portanto ser diferente. Surgi assim um impasse, entre a equipe de Teste e a de Desenvolvimento, que dependendo dos grupos, só poderá se resolvido com a ação do gestor do projeto.

Quanto a resolução de conflitos há cinco possíveis abordagens:

  1. Enfrentamento –  é o método mais utilizado pelos gestores de projeto. Envolve a cooperação franca no sentido de criar uma solução que satisfaça a todas as partes envolvidas (ganha-ganha).
  2. Compromisso – quando o enfrentamento não funciona, costuma-se tentar o compromisso, onde as partes conflitantes barganham até chegar a uma solução aceitável por todas. Pode ser adequado quando há um impasse, todas as partes precisam ganhar alguma coisa e não há tempo.
  3. Moderação – corresponde a acomodar ou favorecer. Busca-se desarmar o contexto emocional e focar no objetivo a ser atingido, mesmo que seja necessário uma das partes sacrificar suas próprias demandas para satisfazer as das outras partes.
  4. Imposição – é um estilo competitivo, controlador ou dominador de resolver os conflitos. Podendo ser legítima, quando a situação é crítica, há muito em jogo, princípios importantes estão em risco, a relação entre as partes não é muito importante e uma resolução rápida é necessária.
  5. Recuo – aqui tenta-se evitar completamente o conflito ou adiá-lo. Será uma solução temporária, porque o problema não é resolvido. Podendo ser uma opção quando não se poderia ganhar, acredita-se que o problema pode desaparecer por si só ou o atraso é, em si, um ganho.

Como vimos o método do enfrentamento é o mais utilizado e juntamente com ele podemos adotar a metodologia sistemática TRIZ (Teoria da Resolução de Problemas Inventivos), criada por G. S. Altshuller, um brilhante pensador de origem judaico-russa. Ela é orientada ao ser humano e baseada em conhecimento, para a resolução de problemas inventivos.

Pela TRIZ os conflitos são contradições, ou seja, declarações que afirmar coisas aparentemente incompatíveis ou opostas. Ela configura-se como a abstração, compilação e organização das melhores formas de resolver problemas na forma de estratégias e princípios. Isso aconteceu, primeiro, nas engenharias mais antigas (os primeiros estudos de Altshuller envolveram soluções da engenharia mecânica, civil, elétrica e química) e, atualmente, acontece em todas as áreas do conhecimento (publicidade, artes, pedagogia, administração, etc.).

O primeiro passo é a identificação das contradições, lembrando que quanto mais a contradição parecer impossível de resolver, melhor. Isso significa que o pano de fundo está posicionado para que não sejam facilmente aceitas as soluções de compromisso e, portanto, que cresce o potencial de chegar a solução verdadeiramente inventiva.

Após formular a contradição, necessitamos resolvê-la. A solução envolve quatro possibilidades, apontadas pelos princípios de separação: no espaço, no tempo, no sistema e conforme  a condição.

Para entender melhor, vamos utilizar essa metodologia para solucionar o seguinte problema:

A fábrica de software TXY é reconhecida por entregar os projetos no tempo hábil, porém há um projeto que está com atraso e a gerência de projeto já está preocupada com tal atraso e para tentar evitá-lo, foi decidido o encerramento dos testes prematuramente. No entanto a equipe de Testes está relutante a essa decisão e se justifica dizendo que o encerramento prematuro dos testes trará como  conseqüência uma maior necessidade de manutenção do sistema o que custará muito mais caro para a empresa, portanto percebeu-se que o encerramento dos testes prematuramente resultará em mais custos no futuro.

No exemplo acima, encontramos a seguinte contradição: Precisamos garantir a qualidade do software, mas não temos tempo hábil para isso. Formulada a contradição vamos tentar utilizar os princípios de separação em busca de idéias:

  • Separação no espaço
    • Aumentar a equipe de desenvolvimento, em busca de uma aceleração do desenvolvimento para que haja um maior tempo para os testes.
  • Separação no tempo
    • Expandir a capacidade no tempo: trabalhar até mais tarde e se necessário trabalho durante o final de semana.
  • Separação conforme a condição
    • Negociar com cliente um maior prazo, justificando com a garantia de maior qualidade do software.
  • Separação no sistema
    • Alguns recursos do desenvolvimento executarão testes em paralelo com a equipe Testes.

Como podemos perceber existem diversas possibilidades de solucionar os problemas sem que o projeto precise ser atrasado e sem encerrar a etapa de testes prematuramente. E as idéias de solução que não sejam imediatamente viáveis podem ser novamente analisadas com o uso do método de separação, até que alternativas “ganha-ganha” sejam encontradas.

Concluirmos que a utilização da metodologia TRIZ é capaz de gerar idéias inventivas em um curto espaço de tempo, a fim de encontrar a melhor maneira para solucionar os problemas. E percebemos que a resolução dos problemas muitas vezes, depende apenas de boa vontade das partes e da capacidade de pensar em conjunto, tendo como foco o bem para todos e não o de um único ser.

Fique por dentro das novidades, assine o feed do QualidadeBR.

Fonte:

De Carvalho, M. A. Resolvendo Conflitos na Gestão de Projetos através da metodologia TRIZ. Revista Mundo Project Management (Mundo PM), Rio de Janeiro, Ano4, nº20, p. 18-22, Abr/Mai 2008.

http://www.decarvalho.eng.br/triz.html

Anúncios

MPS.BR

Pessoal, participei nessa semana de uma palestra sobre MPS.BR, ministrada por Sarah Kohan e David Yoshida, duas pessoas que participam ativamente na difusão do MPS.BR no Brasil. Abaixo explico um pouco sobre esse novo programa para Melhoria de Processo do Software Brasileiro.

O que é o MPS.BR?

Ele é um programa para Melhoria de Processo do Software Brasileira, criado em dezembro de 2003, voltado especialmente para pequenas e médias empresas, com o objetivo de definir e aprimorar um modelo de melhoria e avaliação de processo de software.

O MPS.BR tem algum apoio?

O MPS.BR conta com apoio do Ministério da Ciência e Tecnologia (MCT), da Financiadora de Estudos  e Projetos (FINEP) e do Banco Interamericano de Desenvolvimento (BID). Sendo coordenado pela Associação para Promoção da Excelência do Software Brasileiro (SOFTEX).

O MPS.BR é baseado em algum modelo ou norma?

Ele tem como base técnica três fontes, sendo elas:

  • ISO/IEC 12207 – A norma ISO/IEC 12207 e suas emendas 1 e 2 estabelecem uma arquitetura comum para o ciclo de vida de processos de software com uma terminologia bem definida. Contém processos, atividades e tarefas a serem aplicadas durante o fornecimento, aquisição, desenvolvimento, operação e manutenção de produtos de software e serviços correlatos.
  • ISO/IEC 15504 – A ISO/IEC 15504 presta-se à realização de avaliações de processos de software com dois objetivos: a melhoria de processos e a determinação da capacidade de processos de uma unidade organizacional.
  • CMMI – O CMMI (Capability Maturity Model Integration) é um modelo de maturidade para o desenvolvimento de software. Sendo um conjunto de boas práticas para o desenvolvimento de projetos, produtos, serviços e integração de processos.

Como o MPS.BR está organizado?

Assim como o CMMI, o MPS.BR é organizado em níveis de maturidade, nos quais a melhoria continua do processo e o cumprimento de novos atributos se faz necessário para alcançar o nível acima.

Os 7 níveis de maturidade

O MPS.BR define sete  níveis  de  maturidade, que podem ser comparados ao níveis do CMMI como na figura abaixo:

7 níveis de maturidade (retirado do site da empresa Pentagrama)

A escala de maturidade se inicia no nível G e progride até o nível A. Para cada um destes sete níveis de maturidade é atribuído um perfil de processos que indicam onde a organização deve colocar o esforço de melhoria. O progresso e o alcance de um determinado nível de maturidade do MPS.BR se obtém quando são atendidos os propósitos e todos os resultados esperados dos respectivos processos e dos atributos de processo estabelecidos para aquele nível. A divisão em estágios, embora baseada nos níveis de maturidade do CMMI tem uma graduação diferente, com o objetivo de possibilitar uma implementação e avaliação mais adequada às micros, pequenas e médias empresas. A possibilidade de se realizar avaliações considerando mais níveis também permite uma visibilidade dos resultados de melhoria de processos em prazos mais curtos.

Como ele é implementado e avaliado?

A implementação e avaliação do MPS.BR é dividida em seis etapas:

  • O que é requerido?
    • Definição do nível de maturidade desejado
    • Definição da área/unidade da empresa que será preparada para a avaliação MPS.BR
  • Como está o processo?
    • Realização de diagnóstico do processo, para que se possa saber como estão os processos atuais da empresa.
    • Conhecer a prática da empresa para o nível requerido.
  • Plano de adequação
    • Com base nos resultados do diagnóstico é elaborado um plano do projeto de implementação do MPS.BR na empresa
  • Implementar processos adequados
    • Treinamento das pessoas da empresa que serão responsáveis pela implementação do MPS.BR, geralmente duas pessoas: um que será o coordenador e o outro será o assistente.
    • Assessoramento a empresa, realização de reuniões podendo ser remotas ou presenciais.
    • Avaliação de atendimento às metas realizadas, sendo realizada duas avaliações: a de 50% feita após 6 meses do início do programa e a de 100% feita após 12 meses.
  • Avaliação preliminar dos processos
    • Antes da avaliação final é realizada uma avaliação de atendimento à meta de 100%, com intuito de verificar o nível de prontidão da empresa em relação ao nível de maturidade desejado.
  • Avaliação oficial
    • Atendendo à meta de 100%, avaliada anteriormente, inicia-se contatos com a Instituição Avaliadora que realizará a avaliação oficial, que atribuirá o nível de maturidade encontrado.
    • A Instituição Avaliadora não pode ser a Instituição que implementou o MPS.BR na empresa.

Qual é o custo da MPS.BR?

O custo para o nível G, o primeiro nível, está em torno de R$ 70.000,00. Já para o nível F estima-se R$ 104.000,00. Sendo que esses preços podem ser negociados e parcelados de acordo com a necessidade da empresa.

Quanto tempo demora a implantação do MPS.BR?

O tempo do projeto dura em média 15 meses, podendo variar de acordo com o grau de comprometimento das pessoas envolvidas.

Conclusão

A melhoria do processo de software é uma necessidade cada vez maior nas empresas de TI. Além do mais, muitas delas ainda sequer possuem processos definidos. Diante dessa realidade, o MPS.BR é uma forma de alcançar a maturação dos processos que vem crescendo a cada ano, com novas empresas adquirindo a certificação ou melhorando o seu nível. Sendo muito bem aceita no mercado nacional (no mercado internacional ela ainda não é reconhecida). Portanto, a MPS.BR é mais recomendada para empresas que tem sua cartela de clientes localizados no Brasil. Para as demais, ela se apresenta como um primeiro passo antes do CMMI, já que a sua adequação é mais simples e seu custo é menor comparado ao CMMI.

E devemos ter sempre em mente que os modelos, normas e etc, existem para auxiliar na melhoria do processo da nossa empresa e credibilizá-la perante aos clientes. E só são possíveis de serem conquistados com o envolvimento das pessoas e por isso devemos estar atento não só a melhoria dos processos, mas também a de nossa equipe. Afinal, como já dizia Carl Gustav JungNão é o diploma médico, mas a qualidade humana, o decisivo.

Fique por dentro das novidades, assine o feed do QualidadeBR.

Fonte:

http://www.softex.br/mpsBr

SOFTEX. MPS.BR Guia Geral (Versão 1.2), Junho de 2007.

Revistas sobre Teste e Qualidade de Software

Abaixo apresento 5 revistas que trazem interessantes artigos sobre Teste e Qualidade de Software, todas elas podem ser obtidas de forma gratuita em seus respectivos sites:

Engenharia de Software Magazine: O grupo DevMedia lançou em Março deste ano a revista Engenharia de Software Magazine (ES Magazine), cujo foco é preencher  uma  lacuna que  existe  no mercado  editorial  brasileiro  –  Engenharia  de  Software Aplicada. O seu objetivo é  levar ao mercado brasileiro de desenvolvimento de software conceitos e práticas associadas ao uso da engenharia de software. A primeira edição da ES Magazine, que pode ser baixada gratuitamente no site, traz em sua capa “Qualidade de Software”, abordando o tema de forma muito clara e didática. (download)

Professional Tester: Embora a sua publicação tenha sido encerrada, em Março de 2006, o site da revista ainda opção de download das edições 14 à 18 e dos artigos da edições 21 e 22. Ela foi umas das primeiras revistas a ter como foco a área de Testes de Software. (download)

Software Test & Performance: Lançada em 2004, pela BZ Media LLC (que também produz a SD Times e a Systems Administration News), a Software Test & Performance traz mensalmente excelentes artigos sobre o que há de mais atual na área de Qualidade e Teste de Software. (download)

TE – Testing Experience: A TE – Testing Experience teve o seu lançamento em Março de 2008, reunindo artigos de profissionais experientes e bem conhecidos da Europa. Ela aborda de uma maneira bem abrangente a área de Qualidade e Teste de Software. E está em sua segunda edição e já atingiu mais de 75.000 leitores pelo mundo todo, sendo produzida por uma comunidade de autores, que está sempre aberta a novos profissionais, do mundo todo, que queiram contribuir com novos artigos. (download)

What Is Testing Magazine: What Is Testing é a primeira revista sobre Testes de Software da Índia, um dos maiores pólos de TI do mundo. Seu lançamento foi realizado em Abril deste ano, com a proposta de trazer artigos de autores do mundo todo. (download)

Fique por dentro das novidades, assine o feed do QualidadeBR.

Fonte:

DevMedia. Editorial. Engenharia de Software Magazine, Brasil, Ano 1 – 1ª Edição  2007.

http://www.professionaltester.com/

http://www.stpmag.com/

http://www.testingexperience.com

http://www.whatistesting.com

Certificação Brasileira de Teste de Software (CBTS)

Pessoal, após ter conseguido a CBTS elaborei um breve FAQ para a empresa onde trabalho a respeito da certificação. Agora disponibilizo à vocês o mesmo, lembrando que a próxima prova tem data prevista para o dia 29 de Novembro de 2008. Boa sorte a todos!

O que visa a CBTS?

A CBTS visa atender a uma exigência do mercado brasileiro que sempre demandou um processo de certificação e qualificação de profissionais em teste de software. A CBTS busca estabelecer padrões para uma avaliação da qualificação dos profissionais de TI com funções na área de Testes.

Qual o seu público alvo?

O exame CTBS se destina aos profissionais de TI da área de Desenvolvimento de Sistemas e em especial aqueles que atuam na área de Teste de Software, que tenham interesse em obter um certificado de reconhecimento técnico válido para o mercado brasileiro.

Qual a importância desta certificação para o profissional?

Adquirir o certificado CBTS para o profissional da área de Teste é um grande diferencial, pois indica que o mesmo possui um excelente nível de competência profissional nos princípios e nas práticas de Teste/Qualidade de Software, dentre os demais profissionais de TI. Tornar-se um certificado CBTS, significa tornar-se membro de um grupo seleto de profissionais reconhecidos na área de teste de software, e receber este reconhecimento de sua competência, é conseguir uma ascensão potencialmente mais rápida em sua carreira, e uma maior aceitação no mercado de TI.

Quais os benefícios para empresa ter um profissional certificado?

São através das certificações, que os profissionais podem atestar seu nível de domínio e conhecimento de seu serviço, assim como as empresas podem demonstrar que possuem um quadro capacitado para atender as demandas com qualidade e profissionalismo. Resultando para a empresa na melhoria de seus processos e ampliação da qualidade e produtividade de seus serviços.

Quantos profissionais atualmente possuem a CBTS?

São atualmente 201 profissionais certificados na CBTS em todo o Brasil.

Quem é o responsável pela CBTS?

A ALATS (Associação Latino-Americana de Testes de Software)  é a responsável pela CBTS. Fundada em 2002, com a missão de tornar-se uma instituição que representasse de forma mais isenta e imparcial possível, todas as empresas e profissionais que possuam vínculo e interesse com os rumos do mercado de testes e qualidade de software no Brasil. Desde sua fundação, um dos principais objetivos da ALATS era estabelecer uma certificação que avaliasse o nível de conhecimento dos profissionais sobre as disciplinas de testes e qualidade de software, forçando um processo de amadurecimento e profissionalização da área de testes. Objetivo esse que deu origem a CBTS.

A ALATS é uma organização sem fins lucrativos, não possuindo nenhum vínculo direto ou indireto com instituições privadas. Todos os trabalhos são feitos de forma voluntária, inexistindo qualquer tipo de remuneração dos membros diretores ou participantes dos projetos de inovação.

Qual é o custo desta certificação?

O valor é de R$ 300,00, para a realização do exame de certificação. Serve para bancar os custos relativos de viagens, hospedagens, materiais de treinamento, divulgação dos trabalhos e despesas administrativas de divulgação da CBTS. Para a realização do exame, não é necessário participar de nenhum treinamento formalmente estabelecido.

Qual é o critério de aprovação?

O candidato deverá obter 75% de acertos na prova para ser aprovado. Sendo a prova constituída de 100 (cem) questões com respostas de múltipla escolha. Cada questão proposta apresenta 4 (quatro) alternativas de resposta, sendo apenas uma delas a correta.

A certificação possui uma validade?

A certificação CBTS terá validade de 3 (três) anos, que são contados a partir do ano seguinte ao da realização e aprovação no exame.

Faz-se necessário uma re-certificação até o término da data de validade de 3 (três) anos para que o profissional permaneça certificado.

Fique por dentro das novidades, assine o feed do QualidadeBR.

Fonte:

ALATS

Artigo do Alexandre Bartie

Testar X Debugar

Testar e debugar parecem sinônimos no dicionário de TI e somente nele, pois o verbo “debugar” não existe na língua Portuguesa. Muitos diriam que testar e debugar é a mesma coisa. Mas na verdade não são, pois cada um tem uma proposta diferente:

  • Proposta de testar: é mostrar que o programa tem bugs.
  • Proposta de debugar: é achar a falha ou o erro que conduziu o programa a falhar e planejar e executar as mudanças necessárias para a correção do erro.

Fazendo uma analogia com o mundo da Fórmula 1: o piloto após dá algumas voltas no circuito, retorna ao boxes e fala para o seu engenheiro que o carro está saindo muito de traseira, o engenheiro solicita a equipe de mecânicos a investigação e concerto do problema. Neste caso, o piloto testou o carro é achou um problema e a equipe de mecânicos irá “debugar” o carro em busca da causa e solução do problema.

Debugar normalmente é associado a testar, mas eles se diferem nos objetivos, metodologias e o mais importante na psicologia:

  • O teste inicia com condições conhecidas, uso de procedimentos predefinidos e tem resultados previstos; somente se o programa falhar que o teste será imprevisível. Já a debugação (debug) parte de circunstâncias possivelmente desconhecidas e o fim não pode ser previsto, exceto estatisticamente.
  • O teste pode e deve ser planejado, projetado e programado. Já a maneira e o tempo para debugar não podem ser tão controlados;
  • Testar é uma demonstração de que o programa possui falhas ou aparentemente não. Debugar é um processo dedutivo;
  • Testar prova que o programador cometeu um erro. Debugar é a oportunidade do programador arrumar o erro cometido;
  • O teste é algo previsível, maçante, rígido e às vezes até desumano. A debugação demanda de intuição, experimentação e de liberdade;
  • Muitos testes podem ser feitos sem um conhecimento prévio do projeto. É impossível debugar sem um conhecimento aprofundado do projeto;
  • Os testes podem ser feitos por outras empresas. A debugação deve ser feita na própria empresa desenvolvedora;
  • Apesar de haver uma sólida teoria de teste, na qual é estabelecido os limites teóricos para os testes, o que pode ser feito e o que não pode. A debugação apenas recentemente vem sendo estudada por teóricos, alcançando resultados ainda rudimentares;
  • Muitos dos testes podem ser automatizados. Automatizar a debugação ainda é um sonho.

Fique por dentro das novidades, assine o feed do QualidadeBR.

Fonte:

Beizer, B. Software Testing Techniques, Second Edition. Pennsylvania, The Coriolis Group, 1990.

Quando os testes devem parar?

Essa é uma das perguntas mais difíceis de ser respondida quando estamos testando um software. Se formos perguntar para um gerente de teste, ele provavelmente vai responder que os testes deverão parar quando o prazo para eles se esgotar. Porém, nem sempre esse é momento certo para encerrar a etapa de testes, pois os testes podem ter sido interrompidos muito antes do tempo necessário para a sua completa cobertura.

Uma das maneiras de saber quando devemos dá por encerrado a etapa de testes é verificar os seguintes pontos:

  • O número de bugs achados que estão fechados é maior do que o número de bugs que se esperava achar;
  • Todos os testes foram executados;
  • A porcentagem de cobertura da aplicação pelos testes já é o suficiente;
  • Todas as funcionalidades funcionam corretamente;
  • O software tornou-se confiável;
  • A estabilidade alcançada atingiu o esperado;
  • O sistema atende as métricas de confiabilidade, disponibilidade e durabilidade definidas no Plano de Teste;
  • O número e severidade dos bugs caíram a um nível satisfatório;
  • O tempo médio entre defeitos encontrados é muito alto.

Logicamente, trabalharmos sempre buscando 100% do software, mas para que isso seja possível, geralmente, o prazo para os testes deverá ser muito alto, o que em muitos projetos é inviável. Assim sendo, uma outra maneira de saber o momento de finalizar os testes é avaliar os riscos envolvidos com a liberação da aplicação para a produção, comparando tais riscos com os da não-liberação. Pois, podemos chegar num momento em que o custo das falhas que possam vir a ocorrer no ambiente de produção não compensa o gasto adicional de dinheiro para tentar evitá-las.

Fique por dentro das novidades, assine o feed do QualidadeBR.

Fonte:

Bastos, A.; Rios, E.; Cristalli, R. & Moreira, T. Base de conhecimento em teste de software. São Paulo, Martins Fontes, 2007.

Farrell-Vinay, P. Manage Software Testing. New York, Auerbach Publications, 2008.