Como vejo que muitas pessoas querem saber o “significado de engenharia de software“, decidi escrever este artigo para responder esta dúvida tão frequênte.

Primeiramente deixo claro, que existem muitas discursões sobre qual área está dentro da outra, mas assumo que engenharia de software é uma sub área de Sistemas de Informação.

Engenharia de software é a disciplina que estuda os métodos e processos para desenvolver software.

Desta definição pode-se definir a pergunta: Software não é apenas um programa que executa e pronto, para que estudá-los?

Primeiramente deve-se ter em mente a diferença entre software e programa:

• Programa é um algoritmo executável que é utilizado para resolver problemas; e
• Software é toda a documentação envolvida, incluindo o programa.

Para definir programa, utilizo a palavra algoritmo, para quem não sabe, segue a definição:

• Algoritmo é uma sequência de passos lógicos para se resolver determinado problema.

Um programa é constituído de sub-programas e também pode interagir com outros programas diferentes dele.

O papel do engenheiro é analisar a necessidade de um software. Saber conversar com as pessoas que necessitam (cliente), de forma a extrair a origem do problema ou problemas e propor um software para resolvê-los.

O papel do engenheiro não é fácil, pois deve ser um élo entre o cliente e a equipe de desenvolvimento.

Basicamente as equipes de desenvolvimentos são dividas da seguinte forma:

1. Analista de Sistemas (Engenheiro de Software);
2. Projetistas;
3. Desenvolvedores (Programadores); e
4. Suporte.

Sendo que normalmente o “nível” 1 conversa com o 2, o  2 com o 3 e o 3 com o 4 e vice-versa.

Nota-se que não é proibído a conversa entre estes “níveis”, por exemplo uma pessoa do suporte pode muito bem conversar com o analista.

A maior questão está no ambiente em que vivem em contato, por exemplo: se o programador fossem conversar com o cliente, provavelmente não haveria entendimento. Como o grande foco é ter entendimento entre a equipe e o cliente, logo surge o papel do Analista.

Durante uma conversar, o analista deve ser capaz de entender o que o cliente deseja, mesmo quando este ainda não sabe o que quer, e visualizar a viabilidade de produzir um software para a necessidade. A maior questão é que o analista deve ser capaz de responder a simples pergunto para o cliente:

“É possível de se fazer?”

E o analista deve ter uma das respostas:

1. Sim, é possível;
2. Não, não é possível; e
3. Sim, mas pode ficar caro.

Um fator muito importante é que o processo de entendimento e definição do problema pode exigir muitas reuniões. Neste momento o entendimento é crucial, pois um erro nesta etapa custa muito caro de se corrigir depois.

Após o acordo o analista conversa com o projetista de modo a fazer desenhos utilizando determinadas tecnologias por exemplo: UML, DFD, DER, MER, Fluxograma, etc.  Durante este processo muitas coisas são levadas em consideração, pois a modelagem bem feita possibilita as muito prováveis modificações.  Neste ponto é necessário um bom conhecimento de Padrões de Projeto, pois adotar a melhor solução para um problema é sempre bom e evita mudanças no futuro.

Após tudo isso definido, estes materiais são passados para a equipe de programação que realmente irá codificar o programa em uma determinada linguagem de programação, por exemplo: Java, Nice, C, C++, Ruby, PHP, Python, C#, Basic, Pascal, ADA, Cobol, Fortran, etc.

Um programador deve conhecer muito de tecnologias por isso a dificuldade de conversar sobre problemas reais, pois enquanto conversar, normalmente está pensando em como codificá-lo o que prejudica o entendimento.

Imagine o programador como um poliglota em linguagens de computador.

Após o sistema ter sido completamente codificado ele é testado, implantado e finalmente o cliente começa a usá-lo. No decorrer do uso, provavelmente irão surgir problemas, desta forma o cliente contata a equipe de suporte.

Seguir estas etapas consecutivamente é chamado de Processo em Cascata, entretanto pela demora em cada etapa, muitas vezes pessoas ficam paradas esperando as outras terminarem seu trabalho.

Normalmente no processo em cascata, o cliente pensa que a equipe não está trabalhando, pois a demora para se obter resultados “palpáveis” é grande.

Para resolver este problema existem vários outros processos, cada qual com vantagens e disvantagens, onde o Analista de Sistemas (Engenheiro de Software) deve saber decidir qual utilizar para que o cliente tenha os resultados esperados, desta forma é definida a grande responsabilidade do analista de sistemas.

Este artigo é apenas uma pequena demostração da grande complexidade que é todo o processo, mas espero que tenha sido possível entender um pouco da importância do Analista de Sistemas.