Podcast sobre Qualidade e Ética em Engenharia de Software

Přepis

Carmen: A maioria das pessoas pensa que engenharia de software é só pra gênios que escrevem código na velocidade da luz, trancados num porão.

Hugo: Totalmente. Mas a verdade é que escrever o código é só uma pequena, pequeníssima parte do quebra-cabeça. A verdadeira engenharia de software é muito mais que isso.

Carmen: Sério? Então, o que é exatamente? Eu achava que tudo se resumia a digitar sem parar.

Hugo: Que nada. Imagina construir um arranha-céu. Você não só coloca tijolos um em cima do outro, né? Precisa de plantas, uma equipe, materiais de qualidade e um processo pra não cair.

Carmen: Claro, seria um desastre se não.

Hugo: Então, com o software é igual. A engenharia de software é a disciplina que se encarrega de todo o processo de produção de software. Desde a ideia inicial até a entrega e a manutenção, buscando sempre a máxima qualidade.

Carmen: Entendi. Ou seja, é a diferença entre fazer uma cabana com galhos e construir uma casa sólida. Você está ouvindo Studyfi Podcast, onde a gente destrincha os temas dos seus exames.

Hugo: Exato. Qualquer um pode escrever um programa que funcione mais ou menos, mas um verdadeiro engenheiro de software cria um produto de qualidade, que é robusto, eficiente e fácil de manter.

Carmen: Você mencionou a palavra "software" várias vezes. Sei que parece óbvio, mas o que exatamente esse termo inclui? Só os aplicativos do meu celular?

Hugo: Boa pergunta. O software não são só os programas de computador ou os apps. Também inclui toda a documentação associada: manuais de usuário, especificações técnicas, tudo o que ajuda a entender e usar.

Carmen: Ah, a letra miúda que a gente nunca lê!

Hugo: Essa mesma! E esses produtos de software podem ser divididos em duas grandes categorias: genéricos e personalizados.

Carmen: Deixa eu ver, me explica isso. Tipo roupa de loja de departamento versus um terno feito sob medida?

Hugo: Analogia perfeita! Os produtos genéricos são como a roupa da loja. São desenvolvidos para um mercado geral. Pensa num processador de textos ou num app de edição de fotos. Milhões de pessoas usam a mesma versão.

Carmen: Faz sentido. E os personalizados?

Hugo: Esses são o terno sob medida. São desenvolvidos para um cliente específico, com necessidades bem particulares. Por exemplo, o sistema que controla o tráfego aéreo ou o software que gerencia a logística de uma grande empresa.

Carmen: Ah, entendi. Nos genéricos, a empresa que faz decide como funciona. Nos personalizados, o cliente é quem manda e diz exatamente o que precisa.

Hugo: Precisamente. Embora hoje em dia essa linha seja um pouco borrada. Muitas empresas pegam um produto genérico e o adaptam para um cliente. O melhor exemplo são os sistemas de planejamento de recursos empresariais, como SAP.

Carmen: Fascinante. É como comprar um terno na loja e depois levar num alfaiate pra ficar perfeito em você.

Hugo: E em ambos os casos, seja genérico ou personalizado, tem uma palavra-chave que une tudo: qualidade.

Carmen: Por que é tão importante? Se o programa faz o que tem que fazer, não é suficiente?

Hugo: É que aí está o truque. Não basta que funcione hoje. Precisa ser confiável, seguro e fácil de modificar no futuro. A ideia de controle de qualidade não é nova, na verdade, vem da Revolução Industrial.

Carmen: Das fábricas?

Hugo: Sim. No começo, na produção em massa, a qualidade se baseava na inspeção. Um supervisor olhava o produto final e decidia se estava bom ou ruim. Era como revisar os deveres no final e só dar uma nota.

Carmen: Parece um pouco ineficiente. Se algo estava errado, já era tarde.

Hugo: Exato. Depois, a coisa evoluiu. Começaram a prestar mais atenção ao processo, à forma de fazer o trabalho. E o grande salto chegou nos anos 30 com o Dr. Shewhart e seu controle de qualidade estatístico.

Carmen: Estatístico? Parece muita matemática.

Hugo: Um pouco, sim. Ele criou os gráficos de controle para monitorar o processo de produção em tempo real. A ideia era detectar problemas enquanto aconteciam, não no final. Assim você podia corrigir o rumo antes que virasse um desastre.

Carmen: E suponho que essa mesma ideia se aplica ao software. Melhorar o processo de criação para garantir um bom produto final.

Hugo: Você acertou em cheio! A gente não espera o programa falhar com milhares de usuários. Implementamos técnicas e métodos durante todo o desenvolvimento para garantir a qualidade desde o começo.

Carmen: Então, o software é um produto de engenharia, mas me dá a sensação de que é... diferente. Não é como construir uma ponte ou um carro.

Hugo: É muito, muito diferente. E essas diferenças são chave. Primeiro, o software não se deteriora com o tempo como o hardware. Um chip pode queimar, um HD pode falhar, mas o código não se "gasta".

Carmen: Mas às vezes meus apps param de funcionar bem com as atualizações...

Hugo: Ah! Isso não é deterioração, isso é obsolescência ou a introdução de novos erros. O código original continua intacto. O problema é que a manutenção do software é muito mais complexa que a do hardware.

Carmen: Mais complexo que trocar o motor de um carro?

Hugo: Muito mais. Porque o software é em grande parte artesanal. Cada peça está interconectada de formas complexas e às vezes invisíveis. Mudar uma coisa pode ter efeitos inesperados em outra parte do sistema.

Carmen: O famoso efeito borboleta, mas com código.

Hugo: Totalmente! E isso nos leva a outra característica perigosa: é enganosamente fácil fazer mudanças no software. Parece que é só apagar e escrever umas linhas.

Carmen: Sim, parece mais fácil que trocar uma viga num prédio.

Hugo: Exato. Mas é uma armadilha. Essa pequena mudança pode introduzir uma falha catastrófica. É como se um arquiteto te dissesse que pode tirar uma coluna de suporte "facilmente". Aham, claro.

Carmen: Com essa complexidade, e sabendo que o software controla desde os aviões até as finanças, suponho que os engenheiros de software têm uma grande responsabilidade.

Hugo: Uma responsabilidade imensa. Pensa nisso: quase todos os países e todas as indústrias dependem de sistemas de informática. O software está em todo lugar.

Carmen: Dá um pouco de vertigem.

Hugo: Por isso existe um código de ética para a engenharia de software. Não é só um conjunto de regras chatas; é um guia para garantir que o poder que eles têm seja usado para fazer o bem.

Carmen: Tipo um juramento hipocrático para programadores?

Hugo: Algo assim. Tem oito princípios chave, mas o primeiro é o mais importante: agir sempre em consonância com o interesse público.

Carmen: O que isso significa na prática?

Hugo: Significa que sua lealdade principal não é só com seu chefe ou seu cliente, mas com a sociedade. Se te pedem pra desenvolver um software que você sabe que é inseguro ou que poderia prejudicar as pessoas, sua ética te obriga a se opor.

Carmen: Nossa, isso é potente. Coloca a segurança e o bem-estar das pessoas acima de tudo.

Hugo: Exato. Outro princípio é o de "Produto". Você deve garantir que o que você cria cumpre os mais altos padrões profissionais. Não vale um "bom, funciona". Tem que ser excelente.

Carmen: E também tem um sobre os colegas, né? Ser imparcial e apoiá-los.

Hugo: Sim, porque a engenharia de software é um trabalho em equipe. A cultura de culpar os outros ou de não compartilhar conhecimento é tóxica e leva a produtos de má qualidade. É sobre se ajudar mutuamente para crescer e construir coisas melhores juntos.

Carmen: Ou seja, ser um bom engenheiro de software não é só saber de código, mas também ser ético, responsável e um bom companheiro de equipe.

Hugo: Não poderia ter dito melhor. É uma profissão com um impacto enorme no mundo, e isso exige um compromisso igualmente grande.

Carmen: E justamente isso que você menciona sobre a organização dos projetos me leva a outra pergunta, Hugo. Como a gente sabe se um software é realmente bom? Quer dizer, o que é a "qualidade do software"?

Hugo: Essa é a pergunta de um milhão de dólares, Carmen. E é muito mais profundo do que a gente pensa. Pra começar, a gente tem que diferenciar entre duas coisas: a qualidade do produto e a qualidade do processo.

Carmen: Dois tipos de qualidade? Eu pensava que qualidade era... bom, qualidade. Ou você tem ou não tem.

Hugo: Não é tão simples. Pensa na qualidade do produto como o aplicativo que você usa no seu celular. Funciona bem? É rápido? Mas aí tem a qualidade do processo... como esse software foi projetado e construído.

Carmen: Ah, claro. Tipo a diferença entre um carro bonito e como ele foi fabricado na linha de montagem.

Hugo: Exatamente! E aqui está o truque: a qualidade do produto depende quase por completo da qualidade do processo. Você não consegue um bom software se seu processo de desenvolvimento é um caos. É quase impossível.

Carmen: Faz sentido. Uma planta de construção ruim raramente resulta numa casa sólida.

Hugo: Exato. Um bom processo estabelece os objetivos de qualidade desde o começo. Mas o software tem umas características muito, muito particulares que o diferenciam de qualquer outro produto industrial.

Carmen: O que você quer dizer com que é diferente? No final das contas é um produto que se vende, né?

Hugo: Sim, mas não se fabrica como um carro. Primeiro, o software é um produto mental. É intangível, nasce da criatividade e da lógica dos engenheiros.

Carmen: Ou seja, não tem uma matéria-prima que você possa tocar, como o aço ou o plástico.

Hugo: Correto. É desenvolvido, não fabricado numa linha de montagem. Por isso quase todo o custo está na engenharia, nas horas de pensar, projetar e programar.

Carmen: E suponho que isso o torna mais propenso a erros humanos.

Hugo: Totalmente. Além disso, a engenharia de software como disciplina é muito jovem comparada com, sei lá, a engenharia civil. A gente ainda está aperfeiçoando nossas técnicas!

Carmen: Ou seja, a gente ainda está construindo pontes que às vezes caem.

Hugo: Uma excelente analogia. E aqui vem o mais curioso: um software com erros não é rejeitado. Se você compra um carro e os freios não funcionam, você o devolve. Se um app fecha de vez em quando... você reinicia e segue em frente.

Carmen: É verdade. A gente normalizou as falhas no software. E imagino que essa qualidade tem que ser monitorada desde o começo, não só no final.

Hugo: Claro! Você não pode esperar o prédio estar terminado pra perceber que os alicerces estão errados. Revisar a qualidade em cada fase —especificações, design, código— é fundamental. Consertar um problema no final é caríssimo, se é que dá.

Carmen: Então, se é tão importante, por que parece que tem tanto software de má qualidade por aí? Qual é a problemática real?

Hugo: É uma tempestade perfeita de vários fatores. Primeiro, o software é cada vez maior e mais complexo. E além disso, nunca está "terminado".

Carmen: O que você quer dizer? Sempre tem atualizações, né?

Hugo: Exato. É um produto dinâmico. Evolui de uma versão para outra. E cada mudança pode introduzir novos problemas! É como se trocassem o motor do seu carro enquanto você está dirigindo.

Carmen: Que medo! Parece que é impossível conseguir um produto perfeito.

Hugo: É. Conseguir um programa totalmente depurado é uma utopia. Sempre vai ter algum erro escondido em algum canto. Por isso se investe tantíssimo dinheiro em manutenção.

Carmen: E por isso os projetos atrasam e estouram o orçamento com tanta frequência, né?

Hugo: Exato. Não se cumprem prazos, nem custos, nem às vezes o que o cliente pediu no começo. Os custos de desenvolvimento sobem, a produtividade é baixa... é um ciclo complicado.

Carmen: E você mencionou algo sobre processos artesanais. Não se supõe que isso é alta tecnologia?

Hugo: Supõe-se. Mas muitas vezes, o desenvolvimento é mais uma arte do que uma ciência. Faltam ferramentas, faltam processos padronizados... e isso nos leva ao cerne do problema.

Carmen: E qual é esse cerne? Parece que tem muitas causas.

Hugo: Podem ser resumidas em várias ausências chave. Ausência de especificações claras por parte do cliente. Ausência de métodos de engenharia aplicados de forma sistemática. E escassez de pessoal com formação nas novas técnicas.

Carmen: Ou seja, um problema de comunicação e de método, no fundo.

Hugo: Bingo! E a solução para um problema de comunicação é... criar uma linguagem comum. Em engenharia de software, a gente chama isso de normalização.

Carmen: Normalização? Tipo criar normas ou regras?

Hugo: Exato. A normalização é o processo de criar guias, normas e convenções para que todos os que trabalham num projeto falem a mesma língua. Define que documentos criar, o que devem conter e que passos seguir.

Carmen: Entendi. É como dar a todos o mesmo manual de instruções para que cada um não construa do seu jeito.

Hugo: Exatamente. As normas são a solução para a maior necessidade da indústria do software: uma comunicação precisa e sem ambiguidades entre os profissionais. Reduz custos, aumenta a produtividade e, claro, melhora a qualidade.

Carmen: Mas criar essas normas deve ser um desafio enorme. Quem decide o que é uma norma e o que não é?

Hugo: Ah, é um processo fascinante! Vamos pegar como exemplo o IEEE, que é um dos organismos mais importantes. Tudo começa com uma ideia.

Carmen: Qualquer um pode propor uma?

Hugo: Sim, um membro pode sugerir. Essa ideia se torna uma Solicitação de Autorização de Projeto, ou PAP. É enviada a todos os comitês para que ninguém esteja trabalhando na mesma coisa.

Carmen: Pra não inventar a roda duas vezes.

Hugo: Correto. Depois, é criado um grupo de trabalho. O interessante é que qualquer um pode se juntar. Busca-se que participem profissionais de distintos níveis e empresas para que a norma seja o mais rica e útil possível.

Carmen: E suponho que se reúnem, discutem, e... pronto?

Hugo: Tomara que fosse tão rápido! O grupo trabalha num rascunho. Esse rascunho passa por muitíssimas revisões e um processo de votação bem rigoroso.

Carmen: Quão rigoroso?

Hugo: Pra você ter uma ideia, tem que votar pelo menos 75% dos especialistas do grupo de votação, e desses, 75% tem que dar o aval. Todo esse processo, desde a ideia inicial até a aprovação da norma... pode levar uns três anos.

Carmen: Três anos! Uau. E uma vez aprovada, o que acontece?

Hugo: É publicada e as empresas começam a usar. Mas o ciclo não termina aí. Os usuários dão seu feedback, sugerem melhorias... e depois de cinco anos, a norma é revisada por completo. Decide-se se ela se mantém, se modifica ou se é eliminada porque já tem algo melhor.

Carmen: Tá, então a gente tem normas pra melhorar o processo. Mas voltando ao começo, como a gente mede a qualidade do produto final? Como a gente coloca um número em algo como a "usabilidade"?

Hugo: Muito boa pergunta. Pra isso existem os modelos de qualidade. Pensa neles como uma hierarquia, uma pirâmide.

Carmen: De acordo, sou toda ouvidos.

Hugo: No topo estão os "fatores de qualidade". Isso é o que o usuário vê: confiabilidade, eficiência, usabilidade... os atributos externos.

Carmen: O que pra mim, como usuária, importa.

Hugo: Isso. Mas pra conseguir esses fatores, a gente precisa descer um nível na pirâmide para os "critérios de qualidade". Esses são atributos técnicos, internos, do próprio software. Coisas que contribuem para a confiabilidade, por exemplo.

Carmen: Tá, o que os desenvolvedores veem.

Hugo: E na base da pirâmide, o fundamento de tudo, estão as "métricas". Essas são as medidas quantitativas. Números. Por exemplo, "o tempo de resposta a uma ação deve ser inferior a 0.5 segundos".

Carmen: Ah! Finalmente algo concreto que dá pra medir. Então, você mede as métricas, que te ajudam a cumprir os critérios, e esses critérios, em conjunto, te dão os fatores de qualidade que o usuário percebe.

Hugo: Você acertou em cheio. É assim que um modelo de qualidade nos permite definir, medir e planejar algo tão abstrato como a qualidade. E nos ajuda a entender como uma pequena decisão técnica pode afetar a experiência final do usuário. É fascinante como tudo está conectado.

Carmen: E faz sentido que essa produção em massa tenha mudado tudo. Mas, onde fica a qualidade nessa equação?

Hugo: Essa é a pergunta de um milhão de dólares, Carmen! E é que o conceito de "qualidade" teve uma jornada fascinante. Não é algo que a gente inventou com a tecnologia.

Carmen: Ah, não? Como eram as coisas antes?

Hugo: Pensa assim: antes das fábricas, você tinha artesãos. O objetivo deles era simples: fazer as coisas bem. Perfeitas. Sem importar o custo ou o tempo que levasse. Era uma questão de orgulho e de criar algo único.

Carmen: Claro, a auto-satisfação de um trabalho bem feito. Mas isso não é muito escalável, né?

Hugo: Que nada. E por isso chegou a Revolução Industrial e virou tudo de cabeça pra baixo. De repente, o objetivo mudou drasticamente.

Carmen: Deixa eu ver... fazer muitas coisas, muito rápido, sem importar se eram boas?

Hugo: Exato! A meta era satisfazer uma demanda enorme e, claro, obter lucros. A produção em série era a nova definição de qualidade. Se você podia fabricar mil, era melhor que fabricar um perfeito.

Carmen: Parece um pouco deprimente. O que fez a gente voltar a se preocupar em fazer as coisas direito?

Hugo: Uma guerra mundial. Durante a Segunda Guerra Mundial, a mentalidade mudou de novo. Não bastava mais ter mil tanques.

Carmen: Precisava de mil tanques que... você sabe, funcionassem.

Hugo: Precisamente. A prioridade era garantir a eficácia do armamento. Não importava o custo, mas sim que funcionasse e que estivesse pronto a tempo. De repente, a qualidade era eficácia mais prazo de entrega.

Carmen: E depois da guerra, todo mundo tentava se reconstruir. Essa mesma ideia continuou?

Hugo: Não exatamente. Aqui é onde a história fica interessante. Enquanto o resto do mundo se concentrava em produzir massivamente para satisfazer a demanda, os japoneses pegaram um caminho diferente.

Carmen: O que eles fizeram?

Hugo: Eles se obcecaram com a qualidade. Caras como Deming e Juran visitaram o Japão e suas ideias causaram uma revolução. Começaram a aplicar um conceito radical: fazer as coisas direito de primeira.

Carmen: Ou seja, em vez de inspecionar no final pra ver o que estava quebrado, eles garantiam que não quebravam desde o começo.

Hugo: Você acertou em cheio! A ideia era minimizar custos melhorando a qualidade. Prevenir erros em vez de corrigi-los. Isso permitiu que eles satisfizessem o cliente e fossem incrivelmente competitivos.

Carmen: Então, a gente passou do artesão pro soldado e depois pro inovador japonês. É toda uma evolução. Como a gente define a qualidade hoje em dia?

Hugo: É uma mistura de tudo isso, mas centrada numa coisa: o cliente. Grandes mentes e consultorias como Feigenbaum ou Arthur Andersen nos deram definições, mas todas giram em torno da mesma coisa.

Carmen: Deixa eu ver se adivinho... satisfazer as expectativas do cliente?

Hugo: Satisfazê-las e superá-las. E não só do cliente que compra o produto, mas também do cliente interno, ou seja, seus próprios funcionários. A qualidade total é um processo de melhoria contínua para ser competitivo e manter todo mundo contente.

Carmen: Parece que é um trabalho que nunca termina.

Hugo: E não termina. É sobre planejar a qualidade que você quer, fabricar com essa qualidade em mente e, finalmente, vender a qualidade que o cliente deseja. É um ciclo constante. E esse ciclo nos leva às ferramentas que usamos para gerenciar tudo...

Carmen: Entendi. Mas agora, vamos sair desses sistemas gigantes e sob medida. O que acontece com o software que a gente leva no bolso, nos nossos celulares?

Hugo: Boa pergunta! Aí a gente entra num mundo completamente distinto. O do software móvel ou, como também é chamado, software de produto genérico.

Carmen: Parece mais simples, né? Simplesmente... um app.

Hugo: De certo modo, sim. A ideia chave é que são sistemas isolados. Uma organização os desenvolve com a intenção de vendê-los no mercado aberto pra qualquer um que queira comprar.

Carmen: Ou seja, não são feitos para um cliente em particular, mas para... todo mundo?

Hugo: Exatamente! É como assar milhares de biscoitos idênticos pra vender numa loja, em vez de fazer um bolo de casamento personalizado para um só casal.

Carmen: Gostei dessa analogia! E agora quero um biscoito. Então, a empresa desenvolvedora basicamente adivinha o que o mercado precisa.

Hugo: Isso mesmo. Eles definem as características, constroem e lançam, esperando que as pessoas gostem e comprem.

Carmen: Tá, faz todo o sentido. Você me dá exemplos que a gente usa no dia a dia?

Hugo: Claro! Pensa nos apps mais comuns. Processadores de texto, planilhas eletrônicas, seu app de agenda ou calendário... todos são exemplos perfeitos.

Carmen: Ah, entendi. Também os apps pra desenhar num tablet ou até as ferramentas pra gerenciar projetos pessoais, né?

Hugo: Exatamente essas. Qualquer software que você possa baixar de uma loja de aplicativos e que não foi feito especificamente pra você, entra aqui.

Carmen: Perfeito, ficou claríssimo. Então, é software "pronto pra usar". Mas isso me faz pensar... e o software que se integra em outros produtos, tipo num carro?

Carmen: E falando em grandes mudanças, a gente não pode fechar o episódio sem tocar na Revolução Industrial. Como isso transformou o trabalho pra sempre?

Hugo: Excelente ponto pra terminar, Carmen! Foi uma mudança brutal. As oficinas de artesãos, onde uma pessoa fazia um produto completo, começaram a desaparecer.

Carmen: E suponho que esses artesãos se tornaram os trabalhadores das novas fábricas, né?

Hugo: Exato. Passaram a fazer parte de organizações enormes. Mas claro, gerenciar centenas de pessoas era um desafio totalmente novo.

Carmen: E como resolveram? Colocaram mais artesãos no comando?

Hugo: Tomara que fosse tão poético! Não, aqui entra um personagem chave: Frederick Taylor e sua "gestão científica do trabalho".

Carmen: Gestão científica? Parece... estrito. Tipo seguir uma receita de cozinha sem poder mudar nem uma pitada de sal?

Hugo: É uma analogia perfeita! O objetivo era criar normas super detalhadas para que os trabalhadores as cumprissem à risca. Isso instaurou a divisão do trabalho.

Carmen: Ou seja, que o pensamento criativo ficava fora da fábrica.

Hugo: Totalmente. Você não fazia mais uma cadeira inteira. Talvez só se dedicasse a lixar uma das pernas... o dia todo.

Carmen: Que loucura! Mas se cada um só faz uma pequena parte, quem garante que todas as pernas terminem na cadeira certa?

Hugo: Aí está a chave! Esse sistema provocou a necessidade de uma nova figura: o supervisor. Funcionários dedicados só a coordenar e vigiar para que o processo funcionasse.

Carmen: Então, pra resumir, a divisão do trabalho nos trouxe também os chefes. Uma coisa levou à outra.

Hugo: Basicamente. Desde as primeiras civilizações até os supervisores de fábrica, a gente viu que organizar o trabalho sempre foi fundamental.

Carmen: Uma jornada fascinante pela história. Muitíssimo obrigada, Hugo, por nos iluminar mais uma vez. E a todos os nossos ouvintes, obrigado por nos acompanhar no Studyfi Podcast!

Hugo: Um prazer, Carmen. Até a próxima!