O que de fato garante a qualidade de um software?
Alguma vez você já ouviu que A qualidade do processo determina a qualidade do produto?
Definição da wikipedia:
Apesar dos modelos aplicados na garantia da qualidade de software atuarem principalmente no processo, o principal objetivo é garantir um produto final que satisfaça às expectativas do cliente, dentro daquilo que foi acordado inicialmente.
Acordado inicialmente? Ou seja, implementou o que tinha sido combinado meses atrás o software tem qualidade. Claro que não! Os requisitos mudam, as pessoas erram e podem levantar requisitos incorretos, qualidade é resolver o problema do usuário. Estar em conformidade com o que foi levantado inicialmente é mole, resolver o problema do cliente é bem mais difícil. Se você vai fazer um software, ainda que seu cliente não saiba te falar o que ele quer, seu papel e descobrir o que ele precisar e construir um software para isso. Se ter qualidade fosse estar conforme o acordado inicialmente para que precisaríamos de processos iterativos?
Alguma vez você já ouviu que O software é mais um artefato dentro do processo de desenvolvimento?
Qual é mesmo a verdadeira função de uma empresa que desenvolve software? Documentar um Software? Ter um processo formal (lindo) e bem definido que possa ser repetido? Ter certificações de qualidade? pra mim tudo isso é secundário. Uma empresa que desenvolve software tem basicamente três funções:
- Desenvolver um software que resolva (de verdade) o problema do seu cliente, para isso precisa produzir um software de qualidade com o menor custo e menor prazo;
- Gerar o máximo de lucro para empresa;
- Deixar seus funcionários felizes por trabalhar lá;
Existem dezenas de forma de atingir esses objetivos e certamente ter um processo bem definido, documentar o software e ter um certificação de qualidade podem ajudar muito a se atingir essas metas, porém esta não é a única forma e essa forma pode também não ser a mais eficiente.
Quer ver uma coisa interessante? pense nos software que você conhece e que julga serem software de qualidade, depois pense nos software que você conhece que são um lixo. Alguém vai ler isso aqui e falar… mas sob qual ponto de vista? você está falando de qualidade em relação a conformidade? você quer que eu analise usabilidade, manutenibilidade, xxxxxxidade…? Não, tudo isso também é útil mas a forma melhor de saber se um software é bom e perguntar para o usuário dele o que ele acha, se ele falar que é ótimo, pronto! se ele falar que é um lixo! é um lixo e acabou. Não serve de absolutamente nada um software é perfeito conforme seus casos de teste e seus casos de uso se os requisitos tiverem sido mal levantados, aliás um software perfeito segundo sua especificação e que não atende o cliente serve para duas coisas: a empresa ganhar grana e deixar o cliente ‘chateado’. Existem sim alguns requisitos não funcionais que o usuário não saberia responder se sob esse ponto de vista o software tem qualidade, um exemplo seria manutenibilidade.
Voltando aos software que você conhece e julga bons x ruins, faça a lista e tente saber se eles usaram um processo formal e bem definido ou se suas equipes preferem práticas ágeis, menos formais. Tente fazer a sua lista, depois entre no google e pesquise sobre a metodologia de desenvolvimento da empresa dele.
Só para não ficar sem exemplos compare os software lançados nos últimos 5 anos pelo Google e pela Microsoft. Na minha opinião, o Google lançou software bem superiores aos da Microsoft, conseguiu entregar versões de seus produtos em um tempo bem mais curto e o principal detalhe, com equipes bem menores e custos bem menores. Se tiver duvidando pesquise no próprio Google que você acha esses dados. Outro exemplo é a Apple, enquanto a Microsoft fez o Windows Vista a Apple faz 4 versões do seu sistema operacional e como se vê em toda a imprensa o custo é ridiculamente inferior e a qualidade todos sabem. Nós temos muitos exemplos de software desenvolvido no Brasil que podem ser avaliados, pense nos que você já fez. Você já pensou nos software que usam nos S.A.C. Serviço de atendimento ao Cliente, os famosos 0800 que todos os dias nos falam “O sistema vai esta fora do ar, o senhor pode estar ligando mais tarde?”
Será que o Google tem um processo formal bem definido? Será que eles tem CMM(i) lá? Será que eles escrevem casos de uso dessa forma que estamos acostumados? Será que eles usam RUP? Será que eles usam XP? Será que eles pagam alguns milhares dólares pelo Rose? A resposta é não, não, não, não, não, não e não.
A empresa tem seus princípios e cada equipe define seu conjunto de práticas úteis. Por que eu não posso dividir meu projeto em fases e iterações (UP), fazer programação em pares(XP), ter uma sala de guerra (Scrum), remover funcionalidades menos relevantes (Getting Real) e desenvolver orientado a testes(XP)? Nosso objetivo é fazer software de qualidade e não processo bonitinho! Segundos as definições de processos não tem problema nenhum em você combinar essas práticas.
Agora que você tá querendo me dar aquela resposta vou colocar referências de nomes bem conhecidos na Engenharia de Software que falaram recentemente sobre processos de desenvolvimento, antes de dar aquela resposta é bom você olhar esses links. O último link é o mais interessante.
Father of the Unified Process says “Enough of Processes”
Enough of Processes: Let’s Do Practices Part I
Enough of Processes: Let’s Do Practices Part II
Dave Thomas: EssUP Embraces Agility
The Essential Unified Process: New Life for the Unified Process
O problema de CMM é a imposição dos clientes (licitações), que querem o software apenas de empresas certificadas, daí corre-se atrás dela de qualquer jeito, algum gerente grita “temos que ter a certificação, não sei como funciona, mas temos!”, e o cliente engole um software caro mas “certificado”, é claro isso só acontece com empresas grandes, as empresas pequenas vão preferir as metologias XP e Getting Real, que é o meu caso =D, raramente surgem exceções de grandes como o Google, mas o erro não está nos processos do CMM, estes processos tem sua hora e lugar para uso e deve ser o mais enxuto possível, o problema está nas pessoas em achar que deve usar tudo o que a cartilha do CMM prega, se apegam como se fosse a salvação, como se ali fosse dito “como conseguir e manter o cliente”, CMM nunca disse isso. Ver os criadores do processo RUP a esta altura recuarem e falarem “peraí gente, não é assim”, já é um grande começo.
[...] O que de fato garante a qualidade de um software? [...]
Definir qualidade pro cliente é simples, o quão bem o sistema resolve o problema dele? O quanto ele está gastando menos por estar com o sistema implantado no seu negócio? O quanto ele está ganhando a mais por estar utilizando o sistema?
E eu fico muito triste de ver o Jacobson querendo dar uma “pós-vida” ao RUP com uma “nova” roupagem e escrevendo textos cheios de frases de efeito (como o artigo da DDJ impressa desse mês). Tudo o que ele escreveu ali é o que os “ágeis” estão falando a pelo menos uns 12 anos, mas ele fala como se fosse tudo novidade, como se ELE não tivesse o seu próprio nome lá no Agile Alliance.
Acabou, o RUP não cola mais, vamos pelo menos deixar o defunto morrer em paz
Concordo com o Maurício… Também acho que o Jacobson está criticando no artigo “Enough of Processes…” algo que ele também está fazendo, só que mais “disfarçado” pra vender o Essup. Acho que ele fala mta coisa boa ali, só se enrola na hora de dar a solução… Quer dizer que a solução agora é todo mundo comprar o “processo” dele? Hehehe…
Bom texto “autor”
P.S: Óia nóis aqui…
Bom texto macabro! Mandou bem!
Acho que o soo*** está fazendo vc refletir bastante sobre o que é qualidade hein? hehehe.
A moral da história é que todo mundo quer moleza e o que esses “papas” da engenharia de software tentam fazer são cartilhas que, se seguidas à risca, levarão ao sucesso.
Todos esses processos, em sua essência, seguem nada mais do que boas práticas de engenharia de software e, principalmente, bom senso.
Abraços