Engenharia de Software é, por definição, a aplicação de técnicas, conhecimentos e ferramentas à construção de software de qualidade. A função do engenheiro de software é produzir aplicações que atendam às necessidades dos clientes dentro do prazo e orçamento disponíveis.
Software é construído através do processo de programação. Embora o processo de desenvolvimento envolva outros passos anteriores à codificação, o software não fica pronto sem programação.
(Imagem: freepik)
Programação é o processo de criar e descrever um conjunto de instruções que informem a um computador o que fazer para resolver um dado problema. Para programar, é necessário entender a lógica básica de programação (algoritmos) e alguma linguagem de programação que possa ser “entendida” pelo computador.
Diante da importância da programação no desenvolvimento de software, cursos e discussões na área tendem a focar fortemente em desenvolver habilidades técnicas voltadas para essa atividade. De fato, basta olhar a grade de qualquer curso de engenharia de software ou computação e veremos disciplinas voltadas para programação em praticamente todos os blocos.
Com essa informação, parece que todo engenheiro de software precisa ser, acima de tudo, um programador. Mas será mesmo verdade?
Programação é uma habilidade complexa. É também uma atividade complexa e longa.
Programar envolve criar algoritmos. A base para a criação de qualquer programa é a definição da sequência de instruções que serão realizadas para resolver o problema do cliente. Esse conjunto de instruções é conhecido como algoritmo.
Criar algoritmos exige conhecimento das estruturas de comando e de lógica matemática, bem como a capacidade de visualizar e organizar a solução para problemas.
Além disso, programar exige o domínio de uma linguagem de programação. Linguagens de Programação são sistemas de notação que podem ser compreendidos pelo computador. Computadores não entendem o que chamamos de linguagens naturais (as que falamos no dia a dia, como o português). Por isso, é necessária uma linguagem que possa ser entendida tanto pelo programador quanto pelo computador. Diversas dessas linguagens existem no mercado, é cada software é desenvolvida em uma linguagem.
(Imagem: freepik)
Por esses motivos, nem todos desejam dedicar tempo ou esforço para a atividade de programação. Algumas pessoas não se interessam por aprender as habilidades necessárias. Outras, mesmo sabendo programar, não demonstram interesse pelo dia a dia da atividade.
Ainda assim, várias dessas pessoas se interessam pelo poder de inovação e solução de problemas que a área de engenharia de software pode trazer. Existem espaços para aqueles que não desejam ou não conseguem programar dentro do universo da produção de software.
Desenvolver software envolve programar, mas essa não é a única atividade envolvida na Engenharia de Software. Entender as necessidades, projetar as interfaces, controlar as equipes, acompanhar os usuários e muitas outras atividades são necessárias para a criação e manutenção de softwares em qualquer ambiente.
Essas atividades são melhor exercidas por pessoas com expertise na área de Engenharia de Software, mas não exigem habilidades de programação propriamente ditas. São atividades voltadas para o gerenciamento da equipe, para o contato com o cliente ou para a operação cotidiana do software.
Seguem alguns dos principais trabalhos que um engenheiro de software pode fazer sem precisar escrever código.
Geralmente o cliente de uma equipe de desenvolvimento de software não é um profissional da área. Clientes são, em última análise, usuários finais. Assim, eles não entendem o linguajar e os métodos envolvidos no desenvolvimento de software. Isso pode dificultar a comunicação entre as partes envolvidas.
Entra em cena o Product Owner, profissional responsável pela comunicação entre a equipe e o cliente. Mais que a comunicação, o P.O. funciona como um representante do cliente junto à equipe.
(Imagem: freepik)
A função do Product Owner é garantir que o software atenda as necessidades dos clientes. O P.O. precisa entender não apenas o que o cliente afirma querer, mas o que ele efetivamente precisa para resolver seus problemas. Um bom P.O. consegue visualizar o produto de forma estratégica para direcionar o trabalho da equipe.
O trabalho cotidiano do Product Owner consiste em especificaras funcionalidades do software a serem desenvolvidas, tirar dúvidas da equipe sobre as necessidades do cliente, atribuir prioridades diferentes para cada funcionalidade e avaliar as funcionalidades entregues.
O desenvolvimento de um software se encaixa perfeitamente na definição tradicional de um projeto (“Um esforço finito com o objetivo de produzir um produto ou serviço novo”). Por isso está sujeito às mesmas restrições que qualquer projeto: Prazo, custo e escopo. Está, também, sujeito a riscos e a restrições de pessoal. Alguém precisa controlar essas restrições e riscos.
Essa função cabe ao Gerente de Projetos. Ele é o responsável final pelo sucesso do esforço de desenvolvimento. Cabe ao gerente planejar e estimar o projeto, bem como se preparar para riscos e controlar e facilitar o trabalho da equipe.
As atividades do dia a dia de um gerente de projeto são estimar o prazo e o custo do processo de desenvolvimento, estabelecer o cronograma de desenvolvimento, montar a equipe do projeto, identificar e criar planos de contingência para possíveis riscos e controlar e liderar a equipe de software.
Por controlar e liderar a equipe de software entende-se acompanhar o trabalho, garantindo que o mesmo cumpra o cronograma estabelecido, e ajudar a equipe a manter o ritmo, tanto motivando a equipe como removendo eventuais obstáculos que a equipe encontre, mas não tenha autoridade para remover.
O nível de autonomia e de poder que gerentes de projeto possuem variam entre organizações, mas de forma geral eles operam como líderes e chefes de equipes. Bons gerentes de projeto devem ter capacidades de liderança, negociação e resolução de conflitos.,
Um produto de software não existe no vácuo. Ele tem a função de resolver um problema enquanto é usado pelo usuário, bem como de existir no ecossistema de T.I. da empresa. Em resumo, um sistema oferece um conjunto de experiências ao usuário.
Essa lógica não se aplica somente a software. Qualquer produto existe, ao fim e ao cabo, para oferecer um conjunto de experiências ao usuário. Mesmo produtos simples, como uma roupa, existem em função do que eles oferecem quando usados.
Produtos podem, e devem, ser projetados a partir de suas funcionalidades, mas podem, também, ser projetados com a experiência do usuário em mente. Todo o produto pode ser pensado de forma a otimizar a forma como o usuário se sente e como ele interage com o produto.
(Imagem: freepik)
A título de exemplo, olhemos o caso do Iphone. Smartphones já existiam antes dele, como o Blackberry ou o Sidekick. O que a Apple fez com o primeiro Iphone foi visualizar uma experiência mais agradável, com o touchscreen, a aparência mais bonita e a tela com cores mais vivas. Perceba-se que as funções básicas de um smartphone já eram atendidas pelos antecessores, mas a experiência oferecida pelo Iphone era diferente. Por isso, o produto revolucionou o mercado.
Essa mesma lógica se aplica ao desenvolvimento de software. Produtos de software podem ser pensados com foco na experiência que o usuário final terá ao utilizá-lo. Esse é o trabalho do User Experience Designer (Designer de Experiência do Usuário, em uma tradução livre), ou UX Designer.
Bons UX Designers deve ter a capacidade de se colocar no lugar do usuário, foco na satisfação e boa comunicação. Precisam também ter a capacidade de enxergar o produto como um todo. Conhecimento de técnicas de design de soluções também pode ser um diferencial.
É comum confundir UX Design e UI Design. Enquanto o UX Designer foca na experiência como um todo, o UI Designer foca especificamente na maneira como o usuário vai interagir com o sistema. O termo UI significa User Interface, ou Interface de Usuário.
O UI Designer tem um trabalho mais técnico, projetando e desenhando as interfaces que o usuário visualizará ao lidar com um sistema. Ele vai se preocupar com telas, ergonomia, organização da informação, cores e coisas similares.
O trabalho do designer de interfaces exige capacidade de organização visual e capacidade de entender seus usuários. O bom UI Designer consegue entender a diferente facilidade ou dificuldade de cada grupo de usuários com cada tipo de interface.
Vale ressaltar que muitas equipes de software colocam o trabalho de UI Designer sob a mesma tutela do UX Designer, para minimizar a quantidade de membros. Embora isso seja comum, não significa que sejam a mesma coisa. UX Designer foca na experiência do usuário e UI Designer foca exclusivamente nas telas.
O projeto de software é o processo de tomar decisões acerca de como o software será feito. Geralmente pode ser entendido em vários níveis de detalhamento diferente. Desde o projeto extremamente detalhado descrevendo estruturas de dados, algoritmos ou classes, até o mais amplo, que descreve tecnologias e partes básicas do sistema.
Esse último tipo de projeto, considerado um projeto de alto nível (pois mais distante da implementação propriamente dita), é conhecido como arquitetura do software. A arquitetura do software vai descrever a pilha tecnológica usada, quais as partes do sistema e como essas partes falarão entre si.
Um projeto de arquitetura pode, por exemplo, especificar em quantos componentes o sistema será dividido, em que linguagem cada componente será implementado, quais frameworks de desenvolvimento serão utilizados, onde e como serão hospedados os componentes e como cada componente se comunicará com os outros.
(Foto: Denise Nascimento)
Para citar um exemplo mais prático: Uma arquitetura bastante comum hoje em dia é criar o sistema com três componentes. Um banco de dados em algum sistema gerenciado de bancos de dados moderno (sistema de armazenamento de dados), um “backend” em Java utilizando framework Springboot e hospedado através de um servidor de aplicações Wildfly e um “frontend” em TypeScript, utilizando plataforma Angular e hospedado em um servidor Node.js. O frontend se comunica com o backend via HTTP resdtfull (tecnologia para comunicação simples via WEB) e o backend se comunica com o sistema gerenciador de bancos de dados utilizando JDBC (tecnologia própria para a comunicação entre aplicações Java e sistemas gerenciadores de bancos de dados).
O trabalho de criar, manter e comunicar esses projetos de arquitetura é responsabilidade do arquiteto de software. Esse profissional se dedica a, com o auxílio da equipe, decidir quais serão os componentes, quais funcionalidades serão implementadas em cada componente e como cada componente será implementado.
Bons arquitetos de software devem conhecer linguagens de modelagem, entender as tecnologias e tendências do mercado, ter noção básica de vantagens e desvantagens de tecnologias e linguagens de programação, além de ter capacidade de resolução de problemas, organização e priorização.
Um clichê comum sobre a tecnologia da informação é que os dados serão o próximo petróleo. A frase significa que as novas fortunas surgirão de empresas que manipulam e extraem informação. Embora clichês tendam a ser frases sem sentido, esse tem mais que um pé na realidade.
Parte importante das necessidades dos clientes atuais é entender os dados é transformá-los em informações. Dados são fatos individuais enquanto informação é a organização e interpretação desses fatos.
Um dos profissionais responsáveis por interpretar dados e extrair informações e conhecimento deles é o analista de informação. Analistas de informação utilizam ferramentas de dados e de análise para interpretar os dados de diversas fontes e encontrar padrões e narrativas a partir das informações.
É o analista de informação que vai utilizar os dados para entender o comportamento de clientes, prever tendências a auxiliar na tomada de decisões.
Para realizar o trabalho, um profissional da área precisa ter capacidade de comunicação e de previsão, além de conhecimento razoável de estatística e, preferencialmente, álgebra linear.
Se analistas de informação e cientistas de dados vão acessar dados de diversas fontes diferentes para executar suas funções, alguém precisa organizar esses dados. Essa função pertence ao engenheiro de dados.
Engenheiros de Dados tem a responsabilidade de gerenciar fontes de dados tanto estruturadas (como bancos de dados) como não estruturadas (como textos ou bancos de imagens) e organizar ferramentas que permitam cientistas ou analistas trabalhar com esses dados.
Um engenheiro de dados deve ter conhecimento de bancos de dados e outras arquiteturas de dados. Ele precisa, também, conhecer ferramentas de big data e de conversão de dados. Além disso, é interessante que o engenheiro apresente habilidades de colaboração e criatividade. Por fim, conhecimento básico das áreas de ciência de dados ou análise de informação, conforme a área em que se trabalha, pode ajudar.
Sistemas gerenciadores de bancos de dados são a ferramenta número um para armazenamento de dados no mercado moderno de T.I. Esses sistemas são ferramentas que permitem, com relativa facilidade, armazenar, recuperar e manipular dados de forma concorrente e segura.
As estruturas de dados armazenadas dentro de um banco de dados precisam ser criadas, otimizadas e mantidas. Criadas para que se possam armazenar os dados dentro delas, otimizadas para garantir que a recuperação dos dados se dê da forma mais eficiente possível e mantidas para garantir que as estruturas de dados atendam às eventuais mudanças do software.
Os administradores de bancos de dados (e seus auxiliares, os operadores de bancos de dados) são os responsáveis por essas tarefas. Eles vão operar e manter os bancos de dados da empresa, bem como tomar decisões sobre a organização das estruturas de dados.
Em muitas organizações o administrador de bancos de dados acumula as funções do engenheiro de dados ou até do analista de informações, mas essas são funções tecnicamente diferentes.
(Imagem: freepik)
Dado o tema desse artigo, é preciso ressaltar que essa não é uma função 100% livre de codificação. É comum se usar linguagens de consultas, como SQL, para realizar as funções do administrador. Decidimos incluir essa função no artigo por dois motivos. Primeiro pois as ferramentas modernas de administração de bancos de dados permitem realizar quase todas as operações sem necessidade de codificação e segundo porque linguagens de consulta são formas bastante simplificadas e domínio bastante restrito de linguagens de programação.
Além de conhecimento de bancos de dados e das ferramentas de bancos dados, um bom administrado de bancos dados precisa ter capacidade de organização e visão analítica dos problemas.
Uma vez desenvolvido o software, ele vai ser colocado para funcionar (ou em produção, como se diz no jargão de T.I.) e ser operado no dia a dia pelos usuários finais. Esses usuários podem vir a precisa de ajudas ou pequenas operações administrativas no sistema, como correção de erros ou cadastro de usuários. Além disso, operações administrativas de menor porte, como backups e restauração de sistemas podem ser necessárias.
Os responsáveis por todas essas operações é o analista de suporte e sua equipe. Esse é um profissional de perfil técnico, que tomará as decisões referentes ao suporte ao usuário, as regras e padrões desse suporte, o hardware e os softwares auxiliares instalados na organização e a forma como se farão as operações administrativas.
Vale ressaltar que o analista de suporte não é, necessariamente, a pessoa que vai realizar as operações de suporte ou administração, mas o responsável por discutir e implementar regras e políticas para essas operações. Em geral., ele terá em sua equipe pessoas responsáveis pela implementação manual ou pela automatização dessas tarefas.
Por ser uma das funções com maior número de atividades, é também uma das que requer maior número de habilidades técnicas. Conhecimento de softwares e hardwares existentes no mercado, conhecimento dos softwares a que se dá suporte e de ferramentas e metodologias de suporte são essenciais para esse profissional. Além disso, ele deve ser focado no cliente, ter boa capacidade de comunicação e de gerenciar relacionamentos, bem como resposta rápida aos problemas.
Como se pode ver, existem diversas funções que podem ser exercidas por engenheiros de software sem necessidade de programação. Essas funções permitem a engenheiros de software continuar participando do processo inovativo sem necessidade de se dedicar ao trabalho de codificação.
Vale ressaltar que, embora esses trabalhos normalmente não exijam programação propriamente dita, um conhecimento básico de lógica de programação e das tecnologias de programação podem auxiliar na comunicação com a equipe e na capacidade de avaliar o software.
Rua Dr. José Auto de Abreu, 2929 - Morada do Sol - 64055-260 - Teresina-PI
Telefone: (86) 3133-7070 - E-mail: contato.icev@somosicev.com
Deixe um comentário
Seja o Primeiro a Comentar!