Confesso, que muita coisa que vi no seminário me surpreendeu e que teve coisas que eu não tinha me dado conta que poderiam ser feitas, pois o conhecimento  – errado – que tinha era de que os testes, eram a última coisa a ser feita no processo de desenvolvimento de software ! Lembro que na minha graduação, aprendi os modelos de ciclos de vida de software. Na época, os professores deixaram bem claro que o modelo mais utilizado e o mais eficaz era o “ciclo de vida em cascata“. Nesse modelo, a fase de testes é a última ! Apesar de ter aprendido isso, com o passar do tempo, que esse modelo não era mais o ideal nos tempos atuais, não tinha percebido que os testes também deveriam mudar de “fase”.

Conheci os testes unitários, que auxiliam tanto o desenvolvedor quanto o testador e que são falcimente aplicados nos projetos. Com estes testes, sendo projetados já na fase de levantamento de requisitos, o desenvolvedor consegue entender melhor o objetivo da funcionalidade/requisito e assim desenvolver as funcionalidades para que gerem o resultado esperado, aumentando o entendimento do “problema”.

Pra mim, um dos maiores motivos para o fracasso de um projeto de software é o fato dos requisitos não estarem claros o suficiente. É bem como o palestrante Marcelo Lima colocou, que um problema que passa sem seu devido entendimento pelo responsável pelos requisitos, aumenta seu tamanho na fase de design e aumenta mais ainda na fase de programação. Ou seja, muitas vezes a falta de entendimento de um requisito é o responsável por fazer com que o cliente não fique satisfeito com o resultado (produto). Deixe ver se consigo reproduzir o exemplo (quando tiver as apresentações, disponibilizo aqui):

Os requisitos:

Fazer um brinquedo para crianças; que tenha curvas acentuadas; tenha 4 rodas; funcione em alta velocidade; proporcione segurança para quem brincar.

Com estes requisitos, “bem escritos”, o que poderia sair errado ? Com esses requisitos, você saberia o que fazer ? Veja o que o clienque queria/esperava que fosse feito:

[singlepic=41,320,240,,center]

Agora, veja o que foi desenvolvido, baseando-se nos requisitos. Veja que todos os requisitos foram atendidos !

[singlepic=40,320,240,,center]

E então, o que está errado ? Você concorda que os requisitos precisam ser bem escritos, para que não exista dúvidas e mais de uma interpretação ?

Outra coisa que entrou em discussão também foram os modelos (metodologias) de desenvolvimento de softwares. Foram apresentados alguns modelos, porém o modelo ágil tenha sido o que mais me convenceu. Quando comecei a atuar como programador, sempre achei que o modelo de ciclo de vida era o que deveria ser seguido. Porém, com o passar do tempo, vi que na maioria dos casos, esse modelo não serve. Quando não for possível determinar no início de um projeto, tudo o que o cliente quer que o sistema faça para ele – requisitos -, o sistema for muito grande e o período para o desenvolvimento seja grande, seu uso não é aconselhável. Essa metodologia não aceita mudanças (de requisitos) durante a sua execução. E hoje, uma das coisas que mais se vê, são mudanças. Os sistemas (softwares) precisam mudar, porque os processos e as necessidades mudam ! E então, como fazer com que as mudanças não sejam um problema para analistas, desenvolvedores e testadores ? Utilize metodologias ágeis ! Mas preste atenção: “Não adianta mudar a metodologia, se não for seguida. Só dizer que está usando uma determinada metodologia não garante sucesso. É preciso segui-la à risca”.

Queria registrar aqui que o pessoal da organização do evento estão de parabéns, pois foi um excelente evento, com um bom conteúdo e ótimos palestrantes ! Esperamos pelo próximo !

Mais informações sobre desenvolvimento de sistemas.

]]> http://ale-sistemas.com/wp/2008/09/20/resumo-do-1%c2%ba-seminario-catarinense-de-qualidade-e-teste-de-software/feed/ 1