Outro dia um empresário, dono de uma empresa de software de pequeno porte, me perguntou como poderia aplicar práticas de engenharia de software em sua empresa. Nos últimos anos seu negócio estava expandindo. No início era somente ele e a esposa. Ele era o analista, o programador e o controle de qualidade. Tinha somente um cliente.
Mas, ganhou experiência o bastante, o que resultou na busca de novas contas. Com o tempo, conseguiu uma boa carteira de clientes, que começaram a demandar mudanças no software. Foi necessário contratar mais analistas e programadores para atender à demanda e garantir a entrega sem perder a qualidade. E com eles vieram os problemas para gerenciar o ambiente de engenharia do software.
Essa é a história de muitos empresários do setor de software. A indústria de software é complexa e seu produto, intangível. Diferente da produção de bens duráveis, o software não é um produto final, não dá para "apalpar" o bem produzido.
Isso faz com que esse tipo de indústria seja mais exigente nos cuidados da produção. Mas, e então? Como ajudar nosso amigo empresário?
Vou usar uma analogia para explicar minha sugestão. Suponhamos que queiramos construir uma boa casa para morar com a família. Podemos simplesmente chamar um pedreiro e alguns ajudantes e pedir a eles que a construam. Mas como será o resultado?
Por mais habilidoso que seja nosso pedreiro, sem um planejamento adequado, sem técnicas de construção, sem dimensionamento apropriado, o resultado poderá ser uma casa com alto custo, muitos defeitos construtivos e, provavelmente, você terá que desmanchar algumas coisas para que no final fique da forma como queria.
É o barato que sai caro. Fato é que para alcançarmos um resultado melhor e com menos riscos, o caminho é buscar um arquiteto e um engenheiro. Eles vão aplicar o conhecimento técnico da Arquitetura e da Engenharia para planejar e construir a casa ao menor custo possivel, com as técnicas adequadas, garantindo que o que você pediu será entregue.
Bom, o mesmo podemos dizer sobre a construção de um software. Podemos até reunir alguns programadores e pedir a eles que construam o software que queremos. Porém, o resultado poderá ser desastroso se essa construção não for guiada pelos princípios da Engenharia de Software (ES). É a ES que reúne as disciplinas, as técnicas, os procedimentos e as melhores práticas para se construir um software com qualidade.
Então, como ajudar nosso amigo empresário? Não basta contratar "engenheiros" de software e colocá-los juntos. A ES é ampla e engloba um conjunto vasto de disciplinas. Não dá para usar tudo de uma vez.
É aqui que os modelos de maturidade de software podem ajudar. Esses modelos fatiam a Engenharia de Software em processos que podem ser aplicados gradativamente, fazendo com que o produtor do software incorpore seus benefícios gradativamente.
Os MMS mais conhecidos são o Capability Maturity Model Integration (CMMI) e o MPS.Br, que é uma melhoria de processos do software. O primeiro, mais conhecido, é usado internacionalmente e permite que a empresa vá "amadurecendo" no uso da Engenharia de Software em quatro degraus.
Já o segundo, é um modelo que adaptou o CMMI à realidade das empresas de software brasileiras. Nesse caso, a escada do "amadurecimento" tem sete degraus.
As exigências dos dois modelos são semelhantes e, na prática, o MPS.Br permite chegar ao mesmo lugar com passos menores. Afinal, se dividimos a distância em mais degraus, os degraus ficam menores e mais fáceis de serem conquistados.
E o nosso amigo empresário, como fica? Bem, recomendaria a ele que buscasse ajuda para implantar o MPS.Br em sua empresa. Esse MMS divide a ES em 19 processos que podem ser implementados de forma gradativa.
Ronan Maia é CTO do Grupo PC Sistemas, empresa de sistemas de gestão para o atacado distribuidor.