O termo Engenharia de Software como é conhecido foi cunhado e usado pela primeira vez pelo professor Friedrich Ludwig Bauer em 1968 na primeira conferência dedicada ao assunto patrocinada pelo NATO Science Committee (NAUR & RANDELL, 1969). Seu surgimento decorreu da análise feita na época sobre as condições da indústria de software que estava entrando em um período crítico de colapso que ficou conhecido pela alcunha de crise do software que teve seu início em meados da década de 1960, quando os programas existentes tornaram-se difíceis de serem mantidos, estendendo-se até o final da década de 1970 (PRESSMAN, 1995, p. 6).

A crise de software foi uma decorrência da imaturidade do mercado e dos profissionais da computação da época, pois vinha de um período onde o desenvolvimento do software não exigia requisitos e configurações complexas, sua utilização era, em média, limitada ao ambiente em que era desenvolvido. De fato, em meados de 1965 o termo crise de software não havia sido usado, isto ocorreu durante a década de 1970 quando as dificuldades relacionadas ao desenvolvimento do software começaram a ser mais graves, principalmente no aumento das demandas e da complexidade que o software passava a ter que executar, frente a inexistência de técnicas adequadas para resolver tais desafios (ENGHOLM JR, 2010, p. 32-33). Foi a partir desta lacuna que os princípios da Engenharia de Software tomaram forma e passou-se a considerar o que apregoava Bauer, o software passou a partir de então a ser visto como um produto e como tal necessita ser desenvolvido a partir de critérios de produção acentuados na busca de sua qualidade, custo adequado e entregue dentro dos prazos prometidos (PRESSMAN, 1995).

A Engenharia de Software foca sua preocupação em manter o controle sobre todas as fases do processo de desenvolvimento do software por meio de métricas voltadas ao controle produtivo dessas aplicações. Esse controle é calcado sob a ótica de uso de diversos paradigmas (modelos metodológicos) de controle e acompanhamento. Cada paradigma, em particular, possui características relacionadas ao tipo de software desenvolvido ou ao tamanho que certa aplicação deverá possuir para atender as necessidades de seus clientes. Essas preocupações começaram a levar os analistas de sistemas de simples gerentes de projetos que pensavam e olhavam apenas a aplicação das regras computacionais em seus projetos para que o software atendesse o mínimo da necessidade dos clientes a um nível superior de ordem onde se soma as preocupações tradicionais outras como o custo da produção do software e a qualidade efetiva, além de ter que se preocupar com os métodos de desenvolvimento e suas ferramentas de aplicação. Frente a isso a definição sobre Engenharia de Software apregoada por Bauer toma força como mostra Pressman (1995, p. 31):

O estabelecimento e uso de sólidos princípios de engenharia para que se possa obter economicamente um software que seja confiável e que funcione eficientemente em máquina reais.

Os paradigmas das metodologias de desenvolvimento de software são segundo Pressman (2006, p. 37) “propostos para colocar ordem no caos do desenvolvimento do software”, são processos metodológicos que podem acomodar atividades genéricas entre eles, mas guardam a particularidade que cada método necessita para controlar o projeto a que é submetido (PRESSMAN, 2006, p. 38). O objetivo principal do uso de tais métodos é garantir uma melhor qualidade no processo de desenvolvimento do software, devido a esta característica operacional presume-se serem esses métodos ferramentas que auxiliam a obtenção da qualidade final no processo de desenvolvimento, pois é melhor uma ferramenta simples que garanta um mínimo de mensuração da qualidade do que não ter absolutamente nada com que medir e acompanhar.

Pressman (2006, p. 38-51) comenta sobre o uso de alguns métodos de acompanhamento ao desenvolvimento de software podendo-se destacar resumidamente:

Modelo em cascata

proposta de acompanhamento sequencial e linear no processo de desenvolvimento sendo útil quando os requisitos do sistema são estáveis e bem definidos, usados em projetos de pequeno porte com baixa margem de manutenção;

Modelo incremental

proposta de produção de software a partir de diversas versões e incrementos, sendo adequado para a produção de projetos maiores em espaço de tempo limitado;

Modelo evolucionário

proposta usada para acomodar modificações que sejam constantes na fase de desenvolvimento do projeto, sendo esta que melhor usa a natureza iterativa da maioria dos projetos de engenharia de software adequada para projetos maiores;

Modelo baseado em componentes

proposta baseada na reutilização de componentes prontos de outros projetos, desde que possam ser conectados ao projeto em desenvolvimento, adequado para projetos maiores;

Processo unificado

proposta de projeto baseada na orientação de casos de uso centrado na arquitetura incremental e iterativa, adequado para projetos maiores.

Na Engenharia de Software há a consideração de que não é possível gerenciar aquilo que não pode ser medido (PRESSMAN, 1995, p. 55-61). Isto somente é possível de ser executado com o uso de ferramentas adequadas ao acompanhamento das etapas do trabalho planejado. Fazer uso de técnicas de planejamento consiste em determinar antecipadamente o que deve ser feito e como será feito, considerando sempre as metas a serem atingidas (SILVA, 1997, p. 24). Além das atividades de planejamento que visualiza o que será realizado, como será realizado e por quem será realizado, o engenheiro de software necessita adotar critérios de gerenciamento do processo de desenvolvimento de software, uma vez que precisa medir constantemente as atividades de desenvolvimento e evolução, não importando o modelo de acompanhamento de projeto escolhido para determinado projeto. Não obstante, as atividades de planejamento e gerenciamento do processo de produção do software estão, na prática, interligadas e não podem ser vistas separadamente, pois é por meio dessas atividades que se iniciou a partir da crise do software uma preocupação maior com a qualidade do desenvolvimento do software e dos profissionais dessa área.

Cabe uma observação, mesmo que empírica e crítica, sobre a Engenharia de Software, pois a partir do dito por Bauer acaba-se dando foco aos princípios de controle do planejamento e do processo de desenvolvimento apenas sob a ótica da engenharia, deixando-se de lado o fato que não é apenas a área de engenharia a fazer uso dos princípios indicados por Bauer, pois muitos desses princípios são encontrados na área da administração de empresas. É necessário considerar que o perfil do profissional de engenharia de software deve ir além das técnicas computacionais e de gerenciamento e controle que ele aprende na escola, que sem sombra de dúvida são necessários aos exercícios de suas funções, mas este profissional necessita de uma visão coadjuvante da área fim que os produtos da computação que vai gerenciar serão direcionados. Se o engenheiro de software direcionar seus esforços em atender empresas do ramo comercial precisará ter treinamento para entender as particularidades do setor e a real necessidade de seus profissionais, o mesmo deve ser considerado para outros setores produtivos da sociedade, não deve apenas ter uma visão técnica do processo de desenvolvimento de software.

Mais recentemente vem surgindo cursos de graduação na área de Engenharia de Software reconhecidos pelo Ministério da Educação brasileiro. Mas, parece este esforço estar muito distante do aceite da profissão pelo Conselho Regional de Engenharia e Agronomia (CREA) representante das carreiras de engenharia. No entanto, nem mesmo outras atividades da produção de software executadas por programadores e analistas de sistemas são reconhecidas (TEBALDI, 2013, p. 28), apesar das discussões já efetuadas no Congresso Nacional como mostra o Projeto de Lei 1561 de 2003, proposto pelo Sr. Ronaldo Vasconsellos que teve seu despacho registrado em 21 de outubro de 2004 (CÂMARA DOS DEPUTADOS, 2003) e se encontra arquivado desde então, pelo menos até setembro de 2015.

Outro ponto de conflito em relação ao exercício das atividades como engenheiro de software é o uso das ferramentas computacionais voltadas para o setor, enquanto a engenharia civil possui ferramentas sofisticadas que podem ser usadas em computadores auxiliares ao seu exercício o setor de produção de software não tem tanta sorte. Parece que foi mais fácil produzir ferramentas computacionais para outras áreas da engenharia do que para o uso da própria produção de software, como diz o dito “em casa de ferreiro o espeto é de pau”. Apesar de existirem ferramentas para uso da Engenharia de Software parece que elas são um tanto distantes e não tão bem elaboradas como as usadas pelas outras engenharias.

Pressman (1995) compara a evolução das engenharias civil, mecânica e elétrica que em 1995 utilizavam livros, tabelas, réguas de cálculo e calculadoras mecânicas e começaram a partir de 1965 experimentar uma engenharia baseada em computadores e que a partir de 1975 começaram a usar ferramentas que possuíam tudo o que precisavam embutidos em diversos programas de computador. Atualmente vê-se tudo isso na palma das mãos por meio do uso de smartphones e tablets. Esse grupo de engenheiros possui atualmente uma interface humano-computador bastante vantajosa aos seus serviços. Pressman aponta que as ferramentas chamadas de CASE (Computer Aided Software Engineering), ou seja, a Engenharia de Software Assistida por Computador estava por volta de 1995 onde estavam as demais engenharias no uso de ferramentas computacionais em 1975 e parece que não houve grandes avanços neste sentido se olhar as ferramentas existentes na época e as atuais, que são basicamente as mesmas com pequenas ou poucas melhorias.

Se as ferramentas computacionais para a Engenharia de Software estão um tanto estagnadas, já os método e técnicas de gerenciamento apresentaram um nível de evolução mais acentuados como o surgimento das técnicas de desenvolvimento ágil como o Extreme Programming (XP) que surgiu no final da década de 1990 nos Estados Unidos e foca o processo de desenvolvimento do código do software (TELES[1], 2014) voltado a grupo de desenvolvedores pequenos e médios (BECK, 2008, p. xi), além da metodologia Scrum voltado para gestão e planejamento de projetos (TELES[2], 2014). Esses métodos mais recentes parecem indicar algumas respostas as perguntas apontadas por Pressman (1995, p. 9):

• Por que demora tanto tempo para que os programas sejam concluídos?
• Por que os custos são tão elevados?
• Por que não são descobertos todos os erros antes do software ser entregue ao cliente?
• Por que as dificuldades em medir o progresso do software enquanto está sendo desenvolvido?

As metodologias XP e Scrum podem ajudar a Engenharia de Software a desenvolver softwares de melhor qualidade, produzidos em menos tempo e com custo menor (TELES[1], 2014), pois permitem a participação do usuário. Segundo Heuser (2009, p. 29) o “envolvimento do usuário na especificação do software aumenta a qualidade do software produzido” quando menciona a prática da Engenharia de Software. Essas técnicas se mostram voltadas a projetos de pequeno e médio portes. Projetos maiores podem enfrentar outros tipos de problemas, necessitando de outras técnicas de gerenciamento, neste sentido, pode-se fazer uso de ferramentas como PERT (Programa Evaluation and Review Technique) usado na década de 1970 pelo governo norte-americano para a construção da série de submarinos atômicos Polaris e o CPM (Critical Payh Method), da mesma época, desenvolvido pela empresa Du Pont para controlar projetos de engenharia (PRADO, 2004, p. 15). As ferramentas PERT/CPM foram desenvolvidas para o gerenciamento de grandes projetos e podem ser facilmente usadas na produção de software e possuem no mercado ferramentas consagradas baseadas nesta dinâmica, sendo o MS-Project da Microsoft (menos robusto com custo baixo de aquisição) e o Primavera Project Management da Oracle (mais robusto com custo mais alto de aquisição, se comparado ao Project da Microsoft).

Cabe considerar que a Engenharia de Software propõe levar em consideração o desenvolvimento de software de maneira mais profissional e séria. Nos incentiva a deixar de lado métodos empíricos e pessoais e adotar outras medidas de trabalho, buscando o desenvolvimento de aplicações que venham a atender a necessidade dos clientes e que estejam dentro de um custo e tempo de desenvolvimento aceitáveis.

Bibliografia

1. Beck, K. Programação Extrema aplicada. Porto Alegre: Bookman, 2008.
2. Câmara dos Deputados. Projetos de Leis e Outras Proposições: PL 1561/2003. Brasília: Palácio do Congresso Nacional, 2003. Disponível em: http://www.camara.gov.br/proposicoesWeb/fichadetramitacao?idProposicao=126039. Acesso em: 23 de fev 2014.
3. Engholm Jr, H. Engenharia de Software na Prática. São Paulo: Novatec, 2010.
4. Heuser, C. A. Projeto de banco de dados. 6. ed. Porto Alegre: Bookman, 2009.
5. Naur p. & Randell, B. Software Engineering: A Report on a Conference Sponsored by de NATO Science Committee. Garmisch, Germany: NATO, 1969. Disponível em: http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDF. Acesso em: 22 de fev. 2014.
6. Prado, D. PERT/COM. 4. ed. Belo Horizonte: INDG, 2004.
7. Pressman, P. Engenharia de Software. 6. ed. São Paulo: McGraw-Hill, 2006.
8. Prado, D.. Engenharia de Software. São Paulo: Makron Books, 1995.
9. Silva, A. de T. Administração e Controle. 10. ed. São Paulo: Atlas, 1997.
10. Tebaldi, J. Z. F. Direito e Ética: Legislação Aplicada. Batatais: Claretiano, 2013.
11. Teles [1], V. M. Extreme Programming. DesenvolvimentoAgil.com.br, 2014. Disponível em: http://desenvolvimentoagil.com.br/xp/. Acesso em: 23 de fev. 2014.
12. Teles [2], V. M. Scrum. DesenvolvimentoAgil.com.br, 2014. Disponível em: http://desenvolvimentoagil.com.br/scrum. Acesso em: 23 de fev. 2014.