Cobertura CInTeQ 2010 – Dia 2 (parte 1)

Agora irei falar sobre como foram as palestras da parte da manhã, que ocorreram no segundo e último dia do CInTeQ 2010, um dos principais eventos de Teste e Qualidade de Software, patrocinado nesta edição por Microsoft, RSI, Iterasys, IBM, Governo do Brasil e Caixa Econômica Federal e com o apoio do BSTQB. Se você quiser saber como foram as palestras do primeiro dia, pode acessar esse post e esse.

Mauro Spínola – Qualidade e Produtividade em Sistemas e Software: Um Desafio Brasileiro

No segundo dia também cheguei um pouco atrasado, e perdi o início da palestra do Mauro, quando cheguei ele estava falando sobre produtividade.

O Mauro Spínola é Doutor e Livre-docente em engenharia pela Poli-USP e atua como consultor na área de TI e Qualidade de Software, ele também realiza treinamentos e assessoria através da Fundação Vanzolin.

A palestra teve como foco apresentar e discutir as exigências que as empresas enfrentam atualmente, assim como falar sobre a potencial contribuição que os modelos e normas podem ter nelas, quando as mesmas buscam a qualidade de sistemas e software.

Ao falar sobre produtividade o Mauro levantou a questão sobre o que é produtividade, que seria a relação entre o que a gente produz, com o quanto que a gente gasta para produzir.

Medir produtividade não é fácil, e medir produtividade em software é bem mais difícil, por isso precisamos saber qual tipo de produtividade nos interessa. Mas antes, precisamos ter a coragem de medir a produtividade.

Como obter maior produtividade?

O Mauro disse que as técnicas não são muito diferentes das usadas para obter qualidade, sendo elas:

  • Arquitetura definida;
  • Processo definido;
  • Padrões;
  • Ferramentas, automação;
  • Reuso/componentização.

Logo após, o palestrante falou um pouco sobre qualidade, primeiro a de produto e depois de processo, citando as características que podemos avaliar no software (Norma NBR 13596):

Do ponto de vista de produto podemos avaliar o seguinte (Norma NBR 13596 [que hoje é a NBR ISO/IEC 9126]):

  • Funcionalidade;
  • Confiabilidade;
  • Usabilidade;
  • Eficiência;
  • Manutenibilidade;
  • Portabilidade.

Agora para falar sobre qualidade de processo o Mauro, citou vários modelos e normas que ajudam a obter um bom padrão, sendo alguns deles:

  • ISO9000-2000/ISO90003;
  • ISO12207;
  • ISO15288;
  • ISO1550;
  • CMMI;
  • MPT.BR.

Sobre CMMI e MPS.BR o Mauro citou alguns números interessantes:

  • CMMI
    • Já foram feitas quase 5000 avaliações, boa parte das avaliações são feitas fora dos EUA, muitas empresas passaram para o nível gerenciado e definido;
    • O Brasil se encontra 117 avaliações no Brasil e 9 são de nível 5.
  • MPS.BR
    • 205 avaliações MPS.BR foram realizadas até agora.

Alguns pontos interessantes levantados pelo Mauro foram:

  • Uma empresa que não tem um padrão, dificilmente irá obter bons resultados mesmo com gênios;
  • Só consegue avaliar a qualidade tendo claro as características que definem um bom software;
  • Testes e codificação são atividades de menor cognição, quando comparadas com atividades de requisitos por exemplo.

O Mauro falou sobre pessoas, fazendo uma analogia onde disse, que uma alfaiataria é diferente de uma fábrica de ternos, e nas faculdades estamos formando bons alfaiates, que não estão preparados para atuar numa fábrica de ternos. Ele ainda enfatizou a necessidade de uma boa formação, para que o profissional possa lidar com as mudanças, afinal na área de tecnologia, mudanças ocorrem de forma constante, sempre precisamos nos manter atualizados.

Ainda foram citados alguns desafios que as empresas enfrentam:

  • Manterem-se atualizadas;
  • Investir em seus funcionários;
  • Desenvolver processos maduros.

Por fim, o Mauro falou que as fábricas de software tendem a industrialização do software, e a “modularização” das atividades é necessária, pois não há sentido em continuar no desenvolvimento vertical.

Impressões da palestra

O Mauro falou sobre um assunto que realmente é um desafio, e na minha opinião a qualidade será cada vez mais um diferencial entre as empresas. E a necessidade da produtividade é inerente ao panorama atual, no qual o que é desenvolvido hoje, passa a ser ultrapassado, cada vez mais cedo.

Não concordo com alguns pontos levantados pelo Mauro, principalmente sobre testes e codificação serem atividades menos cognitivas do que atividades de requisitos, isso me remete a visão de um gerente fora da realidade, que pensa que codificar é igual montar peças de Lego e que testar é só inserir dados num formulário. Além disso, não acredito na tendência da industrialização do software, pelo menos não da maneira que deu a entender, onde o desenvolvimento de software estaria cada vez mais próximo de uma montadora de automóveis. Ainda sou da opinião de que desenvolver software é um processo muito mais artesanal do que industrial.

Neli E.Duarte – Test Mirror: a test strategy using Scrum in an outsourcing project

A Neli, Engenheira de Software na IBM, iniciou a sua palestra falando sobre as características do projeto, no qual eles usavam Scrum, FDD (Feature Driven Development) e outsourcing.

Como no FDD o desenvolvimento é dirigido a features (funcionalidades), havia o feature leader, que era o responsável pelo desenvolvimento da feature do começo ao fim.

E neste contexto, surgiu a necessidade de criar um papel para fazer interface com o feature leader, e aí “nasceu” o test mirror, que é justamente um  espelho do feature leader, só que voltado para os testes.

A Neli detalhou como era o relacionamento entre o feature leader e o test mirror:

  • Na Sprint Planning a interação entre o test mirror e o feature leader ocorria o tempo todo;
  • O feature leader precisava manter o test mirrors ciente de todas modificações feitas na features. Com essas informações o test mirror modelava os testes;
  • Os desenvolvedores davam todo o feedback do que ocorreu, inclusive dando dicas de onde seria necessário fazer testes, e entre eles (feature leaders) também haviam troca de informações
  • Na Sprint Review quem atua é o test leader, baseado nos reports levantados pelo test mirror, ele criando um relatório de qualidade (era o output do processo de teste) e o feature leader apresentava as funcionalidades. Ou seja, o test mirror agia apenas como um suporte ao test leader, durante a Sprint Review.

Também foram citadas alguns características do processo:

  • O output da Sprint Planning era o plano geral dos testes;
  • A primeira tarefa do tet mirror era a modelagem dos testes;
  • Tudo era de acordo com a feature, então no mesmo sprint poderiam ocorrer várias fases em paralelo;
  • Haviam reuniões semanais, onde participam o time Scrum e os core members das outras equipes, onde todos davam um panorama de como estavam as atividades da sprint;
  • Haviam builds semanais;
  • Os test mirrors eram os responsáveis por executar o teste de sanidade que ocorria no mesmo dia da liberação do build;
  • Uma das funções do teste de sanidade era dá informações para o planejamento dos testes (ex.: se o teste de sms não funcionou, não tem como fazer o teste de envio
  • do sms concatenado).

Depois ela falou sobre a interação com o outsourcing (4 empresas trabalhando no mesmo produto 3 de desenvolvimento e 1 de teste[não que uma só fazia testes e a outra as outras só desenvolviam]):

  • Uma equipe entregava o cenário e a outra equipe criava os outros testes;
  • Haviam troca de informações entre as equipes;
  • O test mirror solicitava a execução dos testes, feitas pelo recurso externo, e esse enviava o report da execução dos testes;
  • O test mirror validava todos os bugs reportados pela equipe da outra empresa, fazendo assim um filtro dos bugs;
  • O test mirror era capaz de fazer a filtragem de bugs, pois tinha ciência da funcionalidade, já que estava sempre interagindo com o feature leader.

Por fim, a Neli mostrou os resultados obtidos utilizando essa dinâmica:

  • A comunicação melhorou muito (esse  é geralmente um dos primeiros sintomas, quando iniciamos o Scrum);
  • Melhorou a rastreabilidade dos incidentes;
  • Pacotes entregáveis mensalmente;
  • Aplicação foi entrega no tempo e sem bugs críticos;
  • Uma dinâmica muito intensa durante a sprint, um planejamento bem feito, sendo realizado duas vezes – o planejamento em si e o refinamento;
  • Testes mais esperto!

Impressões da palestra

Sabe aquela palestra que você balança com a cabeça todo o tempo, afirmando o que foi dito? Foi esse o comportamento que tive durante a palestra da Neli.

Até comentei no twitter, que a melhor palestra “coadjuvante” do CInTeQ  foi a da Neli. E essa impressão deve-se aos seguintes fatores:

  • Foi a palestra que mais se aproximou da minha realidade;
  • A Neli apresentou um conceito novo, o Test Mirror;
  • Mesmo com pouco tempo (meia hora de palestra apenas) a Neli conseguiu passar muito bem o conteúdo da apresentação.

Além disso, a palestra da Neli, na qual ela contou uma experiência de um projeto, mostrou que é possível aplicar práticas ágeis até mesmo na IBM (essa foi para os “ateus” em metodologias ágeis rs). 🙂

Adalberto Nobiato Crespo – Teste de Software no Contexto do Software Público Brasileiro

A palestra do Adalberto, Doutor em Engenharia Elétrica e membro da equipe técnica do CTI –  Centro de Tecnologia da Informação Renato Archer – Campinas, foi mais a título informativo sobre o Portal do Software Público Brasileiro, falando mais sobre o 5CQualiBr.

Ele começou falando sobre o que o a atuação do CTI e depois explicou sobre i que é o Software Público Brasileiro, que é um conjunto de soluções de tecnologia da informação e comunicação (TIC), disponibilizado para uso público, por meio de um portal Web.

Dentro desse ambiente existe um outro portal, chamado 5CQualiBR, no qual é tratado a qualidade do Software Público Brasileiro, que possui 6 vetores:

  • Ecossistema;
  • Qualidade de produto;
  • Desenvolvedores de software;
  • Prestadores de serviços;
  • Interoperabilidade;
  • Teste de Software.

O propósito é construir e disponibilizar no Portal do SPB uma Estrutura Tecnológica de Teste de Software, para os diversos usuários do SPB, além de tentar diminuir a distância que hoje existe entre a teoria e a prática.

Durante a sua apresentação o Adalberto enfatizou bastante o desenvolvimento junto com a comunidade do portal, pois quem faz ele é justamente as pessoas que tem experiência na área de Teste de Software.

Impressões da palestra

A palestra cumpriu a sua proposta de divulgação do SPB e do portal 5CQualiBr, eu já tinha visto ambos antes, e tinha achado interessante a ideia. Sem dúvidas o SPB e seus portais são excelentes fontes de conhecimentos, agora se ele realmente se tornará um portal da comunidade, só o tempo dirá.

Erik van Veenendaal – Test Maturity Model

Erik Van Veenendaal, uma das maiores referências da nossa área, apresentou sobre o TMMi (Test Maturity Model integration), que como a própria sigla já deixa claro, é um modelo de maturidade voltado para a área de Teste de Software.

O Erik começou falando que existimos para prevenir que defeitos vão para o mercado e estamos sempre enfrentando desafios e eles estão sempre crescendo, alguns números a respeito disso:

  • O número de software dobram a cada 2 anos na Philips, temos mais softwares para testar;
  • O número de requisitos para celulares dobram a cada 6 meses, segundo a Nokia;
  • Defeitos dificilmente reduzem.

E tendo ciência desses desafios fica claro a necessidade de fazer testes de forma mais eficaz e profissional. Ou seja, precisamos de testadores de classe A, e visando essa necessidade foi criado o TMMi.

Mas antes de falar sobre o TMMi, o Erik disse que há três direções que podemos falar sobre teste:

  • Pessoas;
  • Infra-estrutura;
  • O processo de teste.

Um dos comentários mais legais que feitos pelo Erik foi quando ele disse que para melhorar os testes é necessário buscar uma melhoria nesses três pilares, não adianta apenas focar em um dos pilares. Ou seja, ele mesmo assumi que o TMMi em si, não é a solução definitiva, o que demostra o profissionalismo e preocupação com a qualidade do Erik, e ainda complementa dizendo que melhoria não é apenas processo é também pessoas e infra-estrutura.

A respeito de pessoas, há pelo menos quatro área de habilidades necessárias para um testador:

  • Conhecimento em Teste de Software;
  • Conhecimento em TI (estamos nos aproximando dos desenvolvedores);
  • Conhecimento sobre domínio;
  • Habilidades não técnicas: comunicação, pensamento crítico e apresentação.

Já sobre infra-estrutura, o Erik citou algumas práticas fundamentais:

  • Requisitos bem documentados e gerenciados;
  • Existência de um planejamento do projetos;
  • Gerenciamento de configuração.

Alguns pontos interessantes levantados pelo Erik:

  • Você precisa de um orçamento para fazer a melhoria do processo;
  • O gerenciamento precisa de suporte de bons testes, lembre-se que qualidade é fundamental;
  • É preciso compreender o porquê que você está fazendo a melhoria;
  • Testar é dar informações sobre riscos.

TMMi

O Erik começou a sua explicação sobre TMMi Foundation, dizendo que ela é uma organização sem fins lucrativos. O TMMi é baseado no CMM e considera toda as práticas já existentes, suas origens são: CMMI, ISTQB, TMM, IEEE e TPI.

Assim como o CMMI, o TMMi é dividido em 5 níveis, lembrando que o primeiro é onde todas empresas estão no nível 1 (Inicial).

Os Cincos Níveis do TMMi (fonte)

O Erik acredita que o nível 2 é bom para todas organizações e necessário para lidar com os projetos atuais, sendo que para chegar nele, geralmente leva 2 anos, pois é o nível que provoca mais mudanças. Já para ir para o nível 3, costuma levar 1 ano.

Para se certificar é necessário pedir uma avaliação formal. No processo de implementação e avaliação temos dois papéis principais, o Lead Assessor e o Assessor, sendo que dentro dos conhecimentos para ser um Lead Assessor e um Assessor estão:

  • Lead Assessor
    • 5 anos de experiência e ISTQB avançada;
  • Assessor
    • 3 anos de experiência e ISTQB fundamental.

Na sequência o Erik falou mais especificamente do nível 2 e nível 3.

O TMMi nível 2 leva a redução de tempo e atingi mais a parte funcional. Estando no nível 2 você está de acordo com o que pedido pelo CMMI nas áreas de Verificação e Validação.

Já o nível 3 atingi mais a parte organizacional, e significa um envolvimento mais cedo dos testes no desenvolvimento do software.

As seguintes melhorias no testes, na perspectiva e engenharia, foram citadas:

  • Teste mais profissional;
  • Responsabilidades claras;
  • Planejamento de testes;
  • Teste baseado em riscos;
  • Testes parte do ciclo de vida do desenvolvimento;
  • Envolvimento cedo;
  • Uso de técnicas de modelagem de testes;
  • Controle sobre o processo de Teste de Software.

Alguns dos resultados que podem ser reportados pela área de teste são:

  • Detecção dos defeitos;
  • Tempo do lançamentos das versões;
  • Desvio entre o tempo do gasto X planejado;
  • Satisfação do funcionários.

Depois o palestrante falou sobre como podemos começar a implantação do TMMi, dizendo que:

  1. Defina uma política de testes e obtenha aprovação da gerência.
  2. Tenha ciência que melhoria é um projeto e calcule a porcentagem de recursos e esforço;
  3. Implante a maturidade do desenvolvimento na organização.

Algumas dicas dadas pelo Erik sobre como ter implantar o TMMi:

  • Faça pequenos ciclos;
  • Você não vai mudar só pela mudança;
  • Não responsabilidade as tarefas de melhoria para um consultor, pois ele irá embora, deixe isso para alguém da sua organização, a sua organização deve ser o impulso não a consultoria;
  • “Institualize” as melhorias;
  • Tudo tem haver com mudar a gerência;
  • Revise os objetivos (política), de forma contínua;
  • A sua melhoria tem que ser visando o negócio.

O Erik também apresentou o Manifesto da melhoria do testes:

  • Flexibilidade, sob detalhados processos;
  • Melhores práticas, sob templates;
  • Orientado ao deployment, sob orientado a processo;
  • Revisões, sob departamentos de QA;
  • Guiado pelo negócio, acima do guiado pelo modelo;
  • O melhor não é o melhor do mundo é o melhor no seu contexto;
  • Definir processo é fácil, difícil é instituir esse processo para as pessoas.

Por fim o Erik finalizou dizendo que o TMMi é ótimo quando feito da forma certa, sempre dirigido ao negócio.

Impressões da palestra

O Erik é uma palestrante muito bom, conseguiu passar bem as informações, descontrair a plateia com algumas brincadeiras e atingir a proposta da sua palestra. Eu já tinha uma noção do TMMi, mas com a palestra ficou muito mais claro a sua proposta, seus níveis e os resultados que podem ser obtidos com a sua aplicação. Uma pena que ainda não existem Lead Assessors e Assessors no Brasil, o que dificulta a popularização dele no Brasil (enquanto isso podemos acessar o material disponibilizado no site do TMMi).

Encerro aqui a primeira parte do segundo dia do CInTeQ, até a segunda parte, onde estarei terminando a cobertura das palestras do CInTeQ.

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

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.