Análise de sistemas

Resumo do 1º Seminário Catarinense de Qualidade e Teste de Software

2

Ontem, 19 de setembro de 2008, aconteceu o 1º Seminário Catarinense de Qualidade e Teste de Software. O seminário serviu para esclarecer algumas coisas e para enfatizar uma coisa importante – muitas vezes esquecida – que são os testes. Digo esquecida, pois muitas vezes não se dá a devida importância a “fase” de testes. No seminário os testadores (em grande maioria mulheres) foram muito bem representados pelos palestrantes que conseguiram expressar a importância dos testes em todas as etapas do processo de desenvolvimento de software. Cada palestrante enfatizou, ao seu modo, a importância do teste do software e deram dicas de como fazer isso e como introduzir os testes em todas as fases do desenvolvimento.

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.

Ferramenta CASE para modelagem UML

2

Se você procura uma ferramenta CASE (software) que possibilite você fazer a modelagem e documentar o seu sistema, utilizando a metodologia da UML eu recomendo Visual Paradigm. Eu utilizei essa ferramenta para fazer a modelagem do sistema que desenvolvi em meu TCC. Na época (dez/2005) a ferramenta não tinha tantas funcionalidades quanto tem hoje e já foi uma maravilha !!

Atualmente a ferramenta, permite fazer a modelagem utilizando o padrão UML 2.1, gera código em mais de 10 linguagens de programação (inclusive PHP), modelagem do banco de dados, levantamento de requisitos, cartões CRC entre outras. Claro que, como tudo tem um custo … esse não seria diferente. Existem diversas edições dessa ferramenta, inclusive uma para estudante (Community), que é totalmente gratuita !!

O sistema é muito bom (um pouco pesado), mas vale a pena. Eles disponibilizam alguns demos (vídeos) de como o software funciona, para quem quiser conferir.

Go to Top