sexta-feira, 26 de março de 2010

JAD (Joint Application Design) - Técnica de levantamento interativo

No desenvolvimento de sistemas, uma das tarefas mais difíceis é conseguir extrair do cliente todos os requisitos necessários a fim de retratar fielmente o processo de negócio que será implementado por meio de um sistema informatizado.

Esta dificuldade tem várias causas possíveis: muitas vezes os requisitos não estão suficientemente claros para o próprio cliente do sistema; os processos de negócios passam por áreas e pessoas diferentes e nem sempre elas concordam sobre quais são os requisitos do sistema; outras vezes, o cliente aproveita a oportunidade de informatizar o processo de negócio para rever o próprio processo e essas duas atividades acabam se confundindo; o cliente pode mudar de ideia ao longo do tempo e um requisito definido no início da especificação pode estar diferente no final.

Para minimizar estes problemas, uma solução é reunir todos os envolvidos com a definição dos requisitos e fazer um esforço concentrado para levantar os requisitos do sistema no menor espaço de tempo possível.

Uma boa ferramenta para promover este tipo de dinâmica é o JAD (Joint Application Design). O JAD é uma técnica de levantamento interativo, criada por dois profissionais da IBM do Canadá na década de 1970 onde, em uma ou mais sessões, são reunidos todos os interessados no assunto para tomar as decisões sobre o mesmo. A técnica tem uma abordagem voltada para o trabalho em equipe e visa definir um modelo de solução de problemas baseado em CONSENSO.

A dinâmica do JAD:

São feitas reuniões participativas, chamadas de sessões, envolvendo representantes de todas as áreas relacionadas com os assuntos em discussão.

As regras da sessão:
  • Todos os participantes são iguais. Nas sessões JAD, a estrutura hierárquica e de poder são deixadas do lado de fora. Todas as posições tem o mesmo peso e serão avaliadas pelo grupo sem levar em conta qual é a origem da mesma.
  • Apenas uma pessoa fala de cada vez. Assim todos terão chance de expressar a sua opinião e de ouvir as opiniões do restante do grupo.
  • Todas as opiniões são válidas. É preciso não ter uma posição pré-concebida sobre as opiniões dadas.
  • Hora para começar, interromper e terminar. É necessário definir uma agenda para as sessões e cumpri-la à risca.
  • Celular desligado. Durante a sessão não devem acontecer interrupções externas.
  • Recursos visuais. Utilizar intensivamente recursos visuais para tornar o projeto do sistema mais palpável e permitir que ele seja entendido pelos diversos participantes. Uma fotografia é mais explicativa e rica em detalhes do que 1000 palavras para a descrição de um fato.
Os papeis na sessão:
  • Sponsor (Patrocinador). É o executivo responsável pelo projeto, o dono do sistema. Ele precisa ter autonomia para tomar decisões, definir estratégias e direcionar o trabalho.
  • Facilitador. É o responsável por conduzir a sessão. Ele não precisa ser um especialista no assunto que está sendo tratado. Ele deverá estar focado em organizar a dinâmica, dando a palavra a cada participante, obtendo o consenso sobre os assuntos tratados, organizando o registro das decisões e intermediando os conflitos.
  • Escriba. É a pessoa responsável por registrar todas as discussões e decisões em um local que todos possam visualizar, como um quadro ou flip-chart.
  • Documentador. É o responsável por registrar todas as decisões em um documento formal, como uma ata de reunião ou uma especificação de requisitos, que será assinado por todos ao final das sessões.
  • Especialistas. São as pessoas que tem conhecimento do assunto que está sendo discutido e que podem efetivamente contribuir para a discussão e na tomada de decisões.
  • Observadores. São pessoas que estão na sessão apenas para conhecer mais do assunto que está sendo tratado ou para assimilar a técnica da reunião. Os observadores não podem se manifestar durante a sessão.
Os fatores de sucesso:
  • A sessão precisa ter presente as pessoas que tem poder de decisão sobre o assunto tratado, pois, não adianta tomar decisões durante a reunião que poderão ser contestadas quando todos voltarem para o escritório.
  • As decisões precisam ser tomadas por consenso, pois, todos os participantes da sessão precisam sair de lá comprometidos com as definições registradas.
  • As sessões devem ocorrer fora do ambiente de trabalho dos participantes para evitar interrupções e prevenir que os participantes se vejam tentados a tratar de assuntos ligados a sua rotina diária.
  • Não deixar que os participantes imponham suas opiniões em função do seu nível hierárquico, para evitar que pessoas de nível hierárquico mais baixo fiquem constrangidas em debater ou discordar.
  • Definir claramente qual será o produto gerado no final das sessões.
Os benefícios esperados em relação aos métodos tradicionais:
  • Maior produtividade. Estudos relatam aumentos de 20 a 60% na produtividade, em relação aos métodos tradicionais.
  • Maior qualidade. Usuários e analistas de sistemas costumam citar “projeto de softwares de alta qualidade” como sendo o maior benefício do método.
  • Trabalho em equipe.  Promove o espírito de cooperação, entendimento e trabalho em equipe.
  • Custos mais baixos. O projeto de alta qualidade, obtido através do JAD, possibilita uma grande economia de tempo e dinheiro mesmo após a entrega do sistema.

quarta-feira, 10 de março de 2010

MPT.BR - Modelo de maturidade em teste de software

Assim como existem modelos para medir a maturidade de uma empresa no desenvolvimento de software, tais como MPS.BR e CMMI, existem também modelos para medir a maturidade da organização no processo de teste do software.

Aqui no Brasil está sendo desenvolvido o modelo MPT.BR - Melhoria de Processo de Teste de Software Brasileiro.

Duas entidades trabalham em conjunto no seu desenvolvimento:

  • ALATS – Associação Latino Americana de Teste de Software
  • RIOSOFT – Sociedade Núcleo de Apoio à Produção e a Exportação de Software

O conceito do modelo de maturidade no teste é o mesmo do modelo de maturidade no desenvolvimento de software. Ambos procuram determinar em que estágio de maturidade a organização se encontra naquele assunto e classifica os diversos estágios em diferentes graus de maturidade.

Segundo a ALATS, o MPT.BR foi criado com o objetivo de manter a compatibilidade com o MPS.BR e com o CMMI e permitir que empresas que implementaram um dos dois na sua área de desenvolvimento, possam, com um pequeno esforço adicional, aumentar o nível de maturidade da sua área de teste de software. Entende-se que a melhoria da área de desenvolvimento, por si só, é insuficiente para que os resultados melhorem substancialmente. Acredita-se que seja necessária uma melhoria de maturidade também da área de teste de software.

O MPT.BR é leve e passível de ser adotado por áreas de teste de software para apurar o seu nível de maturidade, sem com isso onerar os seus processos anteriormente implementados. O objetivo principal será garantir que áreas de teste de software de tamanho reduzido possam ser avaliadas e estimuladas a alcançarem níveis maiores de maturidade, sem que para isso tenham que incorrer em altos custos operacionais.

Os critérios usados pelas duas entidades na estruturação do modelo foram:

  • Definir critérios que garantam a qualidade do processo de teste de software
  • Não criar nada novo, logo a base é um modelo de melhoria do processo de desenvolvimento de software, no caso o MPS.BR (ou CMMI), já existente no mercado
  • Poder ser usado por áreas de teste de software de empresas pequenas, médias e grandes
  • Permitir a evolução das áreas de testes atingindo níveis mais altos de maturidade e, conseqüentemente, níveis mais altos de qualidade

Os níveis de maturidade definidos no modelo são:

  • Nível 1 Gerência de Projetos de Teste - GPT
  • Nível 2 Gerência de Requisitos de Teste - GRT
  • Nível 3 Aquisição – AQU (opcional); Gerência de Configuração – GCO; Garantia da Qualidade - GQA; Medição - MED
  • Nível 4 Gerência de Recursos Humanos - GRH; Gerência de Reutilização - GRU (opcional)
  • Nível 5 Desenvolvimento de Requisitos - DRE; Integração do Produto - ITP; Validação - VAL (opcional); Verificação
  • Nível 6 Análise de Decisão e Resolução - ADR; Desenvolvimento para Reutilização - DRU (opcional); Gerência de Riscos - GRI
  • Nível 7 Análise de Causas e Resolução de Problemas

Abaixo, estão listados alguns outros modelos de maturidade de teste existentes no mercado:

  • Testability Suport Model (TSM)
  • Testing Maturity Model (TMM)
  • Test Process Improvement (TPI)
  • Test Organization Maturity (TOMtm)
  • Testing Assessement Program (TAP)
  • Testing Improvement Model (TIM)
  • Outros (Ex.: MMT)

Porém, os diversos modelos existentes apresentam alguns problemas que acabaram por levar à definição do modelo MPT.BR:

  • Não existe uma entidade no Brasil responsável pela manutenção dos modelos
  • Foram elaborados por entidades privadas
  • Não são fáceis e nem baratos de serem implementados

Comparação entre os níveis de maturidade do CMMI, MPS.BR e MPT.BR:

  • MPT: Nível 1 - MPS: Sem correspondência - CMMI: Sem correspondência
  • MPT: Nível 2 - MPS: Nível G - CMMI: Sem correspondência
  • MPT: Nível 3 - MPS: Nível F - CMMI: Level 2
  • MPT: Nível 4 - MPS: Nível E - CMMI: Sem correspondência
  • MPT: Nível 5 - MPS: Nível D - CMMI: Sem correspondência
  • MPT: Nível 6 - MPS: Nível C - CMMI: Level 3
  • MPT: Nível 7 - MPS: Nível A - CMMI: Level 4, 5