Carreira

Ξ 5 comentários

Software – Engenharia, Moda ou Arte?

publicado por André Campos

Se você constrói software, então é engenheiro. Mas o engenheiro de software é um sujeito paradoxal, uma espécie de peixe voador, ou pássaro mergulhão. Nada contra estas espécies, mas o nome deles já é um contrassenso. Me lembra um pouco o engenheiro de software. A palavra “engenharia” nos remete a prédios, máquinas, aviões, navios e coisas assim, diria, um tanto ‘hard’. Mas o nosso engenheiro constrói ‘soft’.

É claro que, como engenheiro de software que sou, aprecio os benefícios possíveis a partir do exemplo das outras engenharias, como a medição de prazos e resultados, a capacidade de simulação e previsão, a gestão dos recursos, entre outros. Essas similaridades são interessantes e podem nos ajudar a avançar. Me preocupam mais, no entanto, as diferenças. Que diferenças? Ah, já vou dizendo.


Uma importante diferença tem a ver com as ferramentas que utilizamos. Neste aspecto a engenharia de software está mais para a Moda do que para a Engenharia. Engenheiros tendem a exigir elevadíssimo nível de confiabilidade de suas ferramentas e materiais, especialmente quando se trata de construções críticas. Já pensou como seria a construção de uma usina nuclear com uma ferramenta que o primo do engenheiro descobriu em uma viagem que fez à Tailândia, e que ele achou super legal? Ou a construção de um foguete com uma chapa metálica recém inventada, que é o maior sucesso na indústria de carros? Pode parecer absurda a ideia, mas muitas vezes é exatamente o que faz o engenheiro de software.

Ao passo que as outras engenharias utilizam ferramentas e materiais amplamente testados e aprovados em rigorosos e demorados testes, que as vezes duram anos, o engenheiro de software usa o Python porque é bom a beça. O Java porque todo mundo tá usando. O Asp.Net porque é sofisticado e dá status. O PHP porque é facilzinho. Ou seja, como eu disse, está mais para a moda do que para a engenharia. Não digo que estas tecnologias são ruins ou boas, digo que a decisão por uma delas é geralmente feita da maneira mais ametódica possível. Há ainda aqueles que tratam a tecnologia como religião (nasci nela e vou morrer nela) e outros como time de futebol (tô torcendo pra minha ser campeã).  E aí, pra esse último, vale tudo: camiseta, boné, xícara, tudo com o nome da tecnologia pela qual ele torce. Eu ficaria muito preocupado de contratar um engenheiro com esse comportamento, pois como saber se ele está escolhendo a tecnologia mais adequada ao meu projeto, ou se está escolhendo a sua “tecnologia do coração”?

Outra importante diferença está relacionada ao produto que o engenheiro de software entrega. Colocar um avião em produção ou uma ponte pra operar, sem os devidos testes, pode levar o engenheiro para a cadeia. Entre os testes estão as mais diversas técnicas, inclusive simulações, que não se deixam abalar pela sempre presente pressa do cliente. Já na área de software, é muito comum ver em produção um sistema que sequer passou por uma equipe de testes; foi testado pelo desenvolvedor mesmo (se é que foi). Alguns usuários já até se acostumam com os erros e inventam maneiras de conviver com eles. E o desenvolvedor geralmente fica irritando quando alguém reclama. As duas respostas mais comuns são: 1) Estranho… e 2) Na minha máquina tá funcionando.

O caro colega engenheiro de software, a esta altura, deve estar irritado. Calma, também sou engenheiro de software, e sei que nós não gostamos de ouvir críticas. Quando alguém fala mal de nossos métodos e sistemas, chegamos perto de perder o controle. Nossos sistemas são como filhos para nós, e não queremos ouvir ninguém falando mal deles. Neste caso estamos mais para o mundo das Artes do que da Engenharia. Somos artistas genais, os outros é que não conseguem entender nossa obra.

Que tal nos aproximarmos das engenharias tradicionais, mais velhas e mais sábias? A academia tem grandes estudos, muito experimentos, que podem ser uma pista do caminho a tomar. Há métodos de testagem disponíveis, que devem melhorar significativamente a qualidade do produto que entregamos. E por fim, vamos ouvir mais e falar menos. Afinal, temos dois ouvidos, apenas uma boca, e o cliente sempre tem razão.

  •  
  •  
  •  
  •  
  •  
  •  
  •  

Autor

Doutor em Engenharia de Sistemas e Computação pela COPPE/UFRJ, Mestre em Informática pelo NCE/UFRJ, é também especialista em Gestão Estratégica de TI (UFRJ), Gestão Industrial (UFRJ) e em Segurança da Informação (UNESA). Com mais de 25 anos de atuação em Tecnologia da Informação, em suas diversas áreas, possui certificações Microsoft, ITIL, Auditor Líder BS 7799, e Security Officer (MCSO). É autor dos livros "Modelagem de Processos com BPMN" e "Sistema de Segurança da Informação - Controlando os Riscos". Nos últimos 10 anos concentra-se na relação da TI com o Negócio, em áreas como Governança e Gestão em TI, Engenharia de Software, e Segurança da Informação. Ainda, publicou o livro "Segurança da Informação - Controlando os Riscos".

André Campos

Comentários

5 Comments

  • Como um engenheiro de software pode misturar galhos com bugalhos?

    O engenheiro de software entrega uma especificação altamente detalhada e não exatamente um produto final, esse é resultado de outras etapas do trabalho, sendo que o engenheiro é o responsável pela “construção”.

    É um equívoco misturar os papeis e materiais. Sugerir a aproximação com as engenharias tradicionais atesta tal erronidade, pois o “soft” já possui processos e ferramentas que não deixam nada a desejar para o “hard”.

  • Rodrigo, em primeiro lugar quero agradecer por seu comentário. Acho que a comunicação é a primeira diretriz para a produção do conhecimento e da inovação.

    No entanto, não ficou claro para mim o ponto que você queria destacar. Me parece que você não concorda com o conceito de aproximação da Engenharia de Software às outras Engenharias. Sobre isso, quero antes explicar que não era essa a tônica do post, uma vez que a ideia desta aproximação está defendida e definida desde a década de 1960, quando Friedrich primeiro apresentou Engenharia de Software como uma Engenharia, ou seja, que busca aplicar os princípios de engenharia para gerar software de maneira eficiente, confiável e que opere em máquinas reais. É a partir dessa época que passamos a chamar a produção estruturada de software de Engenharia de Software.

    É claro que podemos concordar ou não com este conceito, mas partindo da premissa que todos concordamos (desde 1960), escrevi o post fazendo comparações entre a Engenharia de Software, mais nova e inexperiente, com suas irmãs mais velhas, as demais Engenharias.

    Obrigado, e espero que participe dos próximos posts também. Um abraço.

  • Prezado André, bom o artigo mas permita-me discordar da sua última afirmação. Nem sempre o cliente tem razão!
    Principalmente quanto estamos tratando de serviços altamente especialidos e que exigem alta disponibilidade, escalabilidade e uma grande preocupação com a segurança.
    Nesse caso cabe a nós, profissionais de TI, mostrar ao cliente que nem sempre a solução que ele procura está na ferramenta que ele utiliza ou que (não) está disposto a pagar por ela.

  • Hernando, obrigado por sua participação. Você está certíssimo: cabe ao profissional de TI orientar o cliente nesta especialidade (a TI), assim como fazem os demais profissionais em suas especialidades. Quando digo que o cliente tem razão quero enfatizar exatamente isso: nós orientamos, mas quem decide é o cliente. Nós, profissionais de TI, como tantos outros, somos prestadores de serviço. Na prestação de serviços o cliente é o elemento central, pois sem cliente não há demanda, e sem demanda não há serviço. O cliente não sabe tudo, e precisa de nós para complementar os conhecimentos que suportarão suas decisões. Assim, ele sempre terá razão.

    Continue participando. Abraço.

  • Há muita controvérsia sobre esta “nova” Engenharia cunhada Engenharia de Software já em meados de 1968. A Inglaterra já disponibilizava um curso de Engenharia de Software em 1987, com duração de 3 anos. Os EUA só iniciou seu primeiro curso em 1996 e foi aceito como uma Engenharia em 2003, com duração de 4 anos. Aqui no Brasil, e seu tremendo “lag”, fez com que apenas nos inícios de 2009 se criasse o primeiro curso de ES, que no início foi uma verdadeira confusão! e que logo se estabeleceu em 4 anos. Antes deste curso, somente tínhamos a Análise de sistemas e até a Ciência da Computação “quebrando o galho”. Engenharia da computação não a cito, porque não tem nada a ver com software, sendo até a sua contrária. No meu ver, cientistas da computação tem outra orientação e não pode ser considerados engenheiros de software, eles estão mais para a P&D e no descobrimento de novas maneiras e não trabalham realmente no “lifecicle” do software em si, todavia, a ES se vale destes cientistas e suas pesquisas. A Análise de Sistemas pode ser considerada a Engenharia de Software “antiga”. Hoje em dia chamam de Análise e Desenvolvimento de Sistemas. Ora, todo profissional de TI sabe que o âmago de um software é sua análise e seu projeto, no entanto, para ser considerado um Engenheiro de software, faz-se necessário conhecer além destas fases. Para isto está/estava a Pós-graduação de Engenharia de Software, quer era o único recurso até pouco tempo atrás para se ter uma engenharia sólida em software. Na minha opinião e depois de ter lido e investigado em demasia o que é a Engenharia de software (principalmente em inglês e logo em português), chego na conclusão de que ela existe e não há nenhum equívoco em ser considerada Engenharia, (à diferença do que falou Dijkstra há 40 anos atrás). Há de se comparar às outras Engenharias, já que precisa-se de muito conhecimento técnico-científico para se construir software de qualidade, econômico e que atinga seus objetivos. Entretanto, creio eu que somente podem ser considerados Engenheiros de Software os que realizam o curso de ES e os de ADS+PósES (já que no Brasil pouquíssimas universidades oferecem o curso de ES, sendo apenas 6, 2 em GO, 1 no PA, e as restantes, -não me lembro bem-, no nordeste), que, na minha concepção, seriam os verdadeiros profissionais do software e que conhecem o ciclo de vida em sua plenitude. Logicamente que o engenheiro pode assumir diferente papéis neste ciclo, tais como de engenheiro de requisitos, arquiteto de software, programador, tester, etc. No entanto, há de se esclarecer uma diferença com ser programador. Todo engenheiro de software é programador, mas sua recíproca não é verdadeira. As competências para que realmente uma pessoa seja considerada um engenheiro de software deveriam ser, na minha opinião, um forte embasamento em matemáticas (Lógica matemática, Matemática Discreta, Probabilidade & Estatística, e porque não Álgebra Linear) , inglês, programação (Estruturas de Dados e algoritmos, fundamentalmente baseada em linguagem C/C++ e logo em Java, programação concorrente, móvel, Web, tanto cliente quanto servidor), Gestão de projetos (PMBOK), conhecimentos profundos de processos de desenvolvimento, normas, modelos, ferramentas e frameworks (CMMI, Six Sigma, CoBIT, Val IT, SPICE, ISO 12207, etc), conhecimentos de computação (Arquitetura de computadores, Redes, SO ). Enfim, o SWEBOK detalha o que é ser engenheiro de software e declara que existe sim. Ela é um engenharia relativamente nova comparada às outras, mas de que ela se tornará uma das engenharias mais importantes, isso não há a menor dúvida.

You must be logged in to post a comment.

Busca

Patrocínio

Publicidade



Siga-nos!

Newsletter: Inscreva-se

Para se inscrever em nossa newsletter preencha o formulário.