Seções iMasters
Desenvolvimento + Gerência de TI + Software

Desenvolvendo software de qualidade

Desenvolver software de qualidade é um desafio e tanto, temos muitas variáveis para considerar como custo, tempo, qualidade e organização. Hoje, eu vou mostrar para vocês algumas dicas de como podemos melhorar a forma de criarmos sistemas. Vamos lá!

Aplicando uma metodologia de desenvolvimento

Muitas vezes deixamos de aplicar essa etapa em nossos softwares, principalmente quando fazemos projetos freelancer ou trabalhamos em empresas que ainda não tenham essa maturidade. Mas vale ressaltar que é de extrema importância escolhermos uma metodologia de desenvolvimento.

Não existe uma metodologia única para todos os problemas, cada sistema exige um tipo de abordagem diferente ou pelo menos uma flexível o suficiente para poder sofrer algumas mudanças. Atualmente a nova moda são as metodologias ágeis (SCRUM, XP, Crystal Family). Realmente elas são muito boas, mas não resolvem tudo. Para determinados tipos de sistemas, equipes ou empresas, os processos clássicos como o RUP, podem se encaixar melhor.

Organização

Vamos criar um exemplo para entendermos melhor:

Temos um pequeno sistema para desenvolver; ele deverá somente controlar os clientes, fornecedores, funcionários e as contas a pagar e receber da empresa. Nosso cliente tem disponibilidade para interagir conosco uma vez por semana e precisa desse sistema em 40 dias. Nós temos uma pequena equipe de desenvolvimento: dois programadores e um engenheiro de software. Qual a melhor metodologia a aplicar?

Nesse caso, acredito que o SCRUM se encaixaria muito bem, pois temos uma pequena equipe e nosso cliente pode interagir conosco pelo menos uma vez por semana.

Teremos reuniões diárias de quinze minutos para sabermos sobre o andamento do projeto e uma reunião mais prolongada a cada entrega.

Cronograma

Vamos criar quatro releases (entregas) de dez dias (duas semanas úteis) para esse projeto:

  • 1 release: Entrega do cadastro de clientes;
  • 2 release: Entrega do cadastro de funcionários;
  • 3 release: Entrega do cadastro de fornecedores;
  • 4 release: Entrega do cadastro de contas a pagar e receber.

Pronto! Já montamos nosso cronograma de entregas. Definimos quais serão os requisitos que devem ser entregues ao nosso cliente e em quais datas isso será feito. Note que não estamos seguindo o SCRUM puro, nós estamos adaptando para nossa empresa. Esse é o grande segredo das metodologias, eles não podem engessar o seu projeto.

Com o nosso backlog (requisitos do sistema) montado, podemos partir para uma próxima etapa, as interações.

Agora precisamos botar ordem na casa. Vamos definir as tarefas que serão realizadas em cada interação – essas tarefas podem variar de empresa para empresa, dependendo muito da forma como ela é organizada.

  • Fazer análise e projeto dos requisitos;
  • Desenvolver requisitos;
  • Testar requisitos;
  • Integrar requisitos.

Dividimos nossas sprints (entregas) em quatro etapas que deverão ser executadas em todas as entregas.

Análise do projeto

Nessa etapa nós vamos conversar com o cliente para saber exatamente como aquele incremento do sistema deve ficar. Vamos escrever users stories para cada caso do nosso cliente, dessa forma evitamos ter que refazer os requisitos caso ele não goste. Também iremos projetar esses requisitos para o nosso sistema, se for o caso podemos até fazer alguns diagramas de classe e de dados para ajudar na arquitetura.

Artefatos: User stories, diagrama de classes e modelo de dados.

Desenvolvimento

Agora nós podemos por a mão na massa. Com os documentos feitos, os desenvolvedores irão codificar os requisitos daquele incremento. Normalmente esse é a fase mais demorada da sprint, uma vez que ela precisa ser bem feita.

Já que estamos nessa etapa, devo ressaltar alguns pontos:

  • Aplique um padrão de codificação para sua equipe: Essa é a melhor forma de deixar um código conciso e organizado. Existem muitas polêmicas sobre documentar e não documentar código, mas quando um código está bem organizado, ele fala por si só. Com um padrão podemos trocar os colaboradores da equipe e eles irão entender o que está codificado ali, sem precisar de uma curva de aprendizado tão lenta.
  • Implante um controle de versões: A utilização de um controle de versões para um projeto é um dos primeiros passos a serem tomandos quando iniciamos a etapa de desenvolvimento. A grande recomendação aqui é para utilizar o CVS que você mais se adpta – cada um tem suas particularidades. Pessoalmente gosto muito do GIT, mas fique a vontade para escolher o seu.
  • Um bom clima na equipe nunca é demais: Não adianta nada ter vários documentos, códigos organizados e diversas outras coisas quando sua equipe não está em sintonia, para isso de motivação para ela, nas reuniões diárias de quinze minutos anime sua equipe e tenha momentos de descontração, dessa forma a pressão para entrega pode ser minimizado.

Artefatos: Incremento da aplicação não testado.

Testes

Uma das partes mais importantes do desenvolvimento, muitas vezes esquecidas pela maioria dos desenvolvedores. Nessa etapa, nós vamos testar tudo o que foi produzido no desenvolvimento. Nesse caso, não estamos trabalhando com o padrão TDD (Test Driven Development), nós vamos produzir código e depois testá-lo.

Vamos fazer dois tipos de teste:

  • Unitários
  • Aceitação

Unitários: Os testes unitários normalmente são bons para testarmos todas as modalidades do sistema; a desvantagem é que é um processo que exige bastante tempo da equipe, então veja se ele realmente é necessário para o seu projeto. Esse teste deve ser automatizado, então depois de escrito os testes tudo fica mais fácil.

Aceitação: Nesse teste iremos verificar se o que o cliente especificou está de acordo com o que foi produzido. Vamos nos reunir com o cliente para ele verificar se está tudo da maneira correta. Nós podemos elaborar roteiros de fluxo para o cliente seguir, mas para esse caso prefiro deixar o usuário mais a vontade.

Artefatos: Incremento da aplicação testado, documento de testes.

Integração

No final de cada iteração nós temos um código pronto e testado, mas ainda falta integrarmos ao sistema final. Para isso podemos alocar nossa equipe para realizar essa etapa e logo em seguida testá-la. Após estar tudo correto, podemos fazer o deploy da aplicação.

Artefatos: Sistema testado.

Finalizando

Seguindo um processo de desenvolvimento, podemos diminuir significativamente as possibilidades de erros em nossas aplicações. As chances de nosso cliente ficar mais satisfeito com o produto também aumenta. Então, se tiverem a oportunidade, apliquem um processo de desenvolvimento e tentem segui-lo sempre que possível.

Bem pessoal, espero ter ajudado quem ainda não tinha essa visão de organização. Minha intenção não é falar pra você como é a forma correta de criar um sistema, mas sim mostrar outras opções de como se organizar. Se você conhece formas de melhorar o desenvolvimento de uma aplicação, compartilhe conosco.

Abraços, galera!

Mensagem do anunciante:

Torne-se um Parceiro de Software Intel®. Filie-se ao Intel® Developer Zone. Intel®Developer Zone

Comente também

7 Comentários

Gustavo Furtado

Gostei do artigo. Muito bom! Uma coisa que acho interessante nesse processo de desenvolvimento de softwares é já nas primeiras entregas do projeto, entregar software funcionando pro cliente, que já agregue algum valor. Um software que já possa ser utilizado, que já tenha serventia para o cliente, preferencialmente cumprindo sua principal função.

abraço,

Gustavo – http://www.dicasdeprogramacao.com.br/

    Ítalo Lelis de Vietro

    Verdade Gustavo e o SCRUM facilita essas entregas, separando tudo em sprints com entregas funcionais. Ótima observação. Abraços

Jeremias Araujo

Bom post,

Mas para que o desenvolvimento tenha realmente uma boa qualidade falta mais ênfase nos testes.

Não é adequado aplicar os testes apenas após o desenvolvimento.

Os Testes devem participar do processo de desenvolvimento desde a concepção do sistema, a levantamento de requisitos e criação de Casos de uso. Pois esses serão artefatos de entrada para criação do Plano de Teste e Plano de Casos de Testes.

Também vejo a necessidade de abranger mais estratégias na fase de testes, nao apenas os Testes de Aceite e Unitário, como Testes Funcionais (Regressão, Integração, Usabilidade…) e Testes Não-Funcionais (Performance, Carga, Stress). Podendo agilizar esses com automação desses testes.

    Ítalo Lelis de Vietro

    Tem toda a razão Jeremias, os testes devem receber uma grande ênfase, sempre que você tiver essa liberdade em sua empresa vele a pena aplicar.
    Obrigado pela dica

Marcelo

Gostei do artigo. Porém, ele não ressalta que Scrum é uma metodologia de gerenciamento de projeto e RUP é um processo de desenvolvimento de software. E que Engenheiro de Software e Programador são quase sinônimos nesse contexto… aliás programação é apenas uma atividade das inúmeras que devem ser praticadas para se desenvolver um sistema, assim como análise e testes.

Fernando

Muito bom o artigo!
Como a conjunção entre tempo e dinheiro é um momento raro… podemos dizer que esse seria o processo perfeito (ou normal) que hoje se aplica para poucos casos.

Abraço

paulochaves

Muito legal o artigo, me ajudou a ter uma visão mais completa de como uma empresa de desenvolvimento consegue se organizar. Parabéns.

Qual a sua opinião?