Introdução à Engenharia de Software
Autor: Edson Leite | Publicado: 2012-03-28T01:07:00-03:00


Objetivos: Apresentar a evolução, principais conceitos e abordagens, características, atributos, aplicações, desafios, mitos, referências e ferramentas relacionadas ao Software e a Engenharia de Software.



Evolução do Software:







Engenharia de Software



A Engenharia de Software, segundo Sommerville que é um dos papas dessa área, é uma disciplina da engenharia que se ocupa de todos os aspectos da produção de software. Isso vai desde os estágios iniciais de especificação de um Sistema, até propriamente a Manutenção para que esse mesmo Sistema sobreviva ao longo do tempo.

A construção de software é uma das atividades mais complexas e vitais para o pleno sucesso de um Sistema informatizado. A Engenharia de Software justamente tenta através dos princípios básicos de outras engenharias trazer um pouco mais de luz para essa atividade complexa.



A “cobrança” hoje das áreas de Informática e de T.I. (Tecnologia da Informação) é o desenvolvimento de Sistemas de forma rápida, com qualidade, e com custos cada vez menores.



Somente através tecnologias adequadas, e com as melhores práticas, podemos atender a esses novos desafios.



A Engenharia de Software é constituído de Metodologias, Métodos e Ferramentas que permitem ao profissional especificar, projetar, implementar e manter Sistemas, avaliando e garantindo as qualidades especificadas pelos usuários.



A Engenharia de Software basicamente tenta apresentar processos, ferramentas e métodos que permitam desenvolver de forma racional e controlável um Sistema Computacional. Todo o foco é a Qualidade, utilizando um método eficaz e o uso de ferramentas adequadas.



Engenharia de Sistemas



A Engenharia de Sistemas é mais genérica e mais abrangente do que a Engenharia de Software. Na verdade, a segunda faz parte da primeira. A Engenharia de Sistemas é mais antiga do que a de Software. Enquanto a primeira está mais envolvida com o Sistema como um todo e seus detalhes, a Engenharia de Software é mais específica no que tange aos componentes do sistema, em especial ao hardware e software.



Método de Engenharia de Software



Sommerville afirma que um método de Engenharia de Software é uma “abordagem estruturada” para o desenvolvimento de software. Podemos definir como “abordagem estruturada” a estratégia de desenvolver algo com uma estrutura previamente estudada, ou baseada nas melhores práticas. O objetivo maior de tudo isso é facilitar a produção, em curto espaço de tempo, de software de alta qualidade, apresentando uma relação custo-benefício interessante.



Um ponto importante a observar é que não existe, repito, não existe um método ideal. As possibilidades e os ambientes de desenvolvimento são tão complexos, que dependendo de cada situação e momento, existe um método que possa explorar mais alguns tópicos, mas deixará outros em aberto.



Outro ponto a ressaltar é que existem vários métodos na Engenharia de Software, mas poucas Metodologias. Podemos entender Metodologia tanto pelas palavras de Maddison, como sendo um conjunto recomendado de filosofias, fases, procedimentos, técnicas, regras, ferramentas, documentação, gerenciamento e treinamento para o desenvolvimento de um sistema de informação, como também o estudo de um ou mais métodos.



No início da computação poucos programadores seguiam algum tipo de metodologia baseando-se, em sua maioria, na própria experiência. Na Engenharia de Software existem basicamente duas grandes metodologias. Uma originária da década de 70, chamada de Metodologia Estruturada, é a mais recente intitulada de Metodologia Orientada a Objetos.



Diferenças das Metodologias



Tanto a abordagem estruturada quanto a orientada a objetos promovem soluções práticas. A diferença entre as duas metodologias é a vida útil e facilidade de manutenção de projetos. A possível reutilização de um código estruturado não é comum, enquanto que um código orientado a objetos por possuir embutido em sua própria filosofia as facilidades de reutilização e de descrição, utilizando UML (Unified Modeling Language), aumenta naturalmente a vida útil dos códigos.



Abordando o software sob um ponto de vista puramente estruturado, define-se os dados do sistema em uma posterior sequência de eventos que acarretará na transformação do estado do sistema.



Por outro lado, numa abordagem focada em orientação a objetos, definem-se estruturas abstratas, denominadas classes, que serão responsáveis por partes da solução do problema.



Cada classe incorporará dados (forma) e métodos (comportamentos). Projetos orientados a objetos utilizam da linguagem de modelagem UML (Unified Modeling Language). Esta linguagem é fruto dos esforços, em conjunto, dos autores Booch, Rumbaugh e Jacobson.



Teoria e Interdependência de Sistemas



Um Sistema é uma coleção significativa de componentes inter-relacionados, que trabalham em conjunto para atingir alguns objetivos (Sommerville). É organizado para executar certo método, procedimento ou controle ao processar informações. Automatiza ou apoia a realização de atividades humanas através do processamento de informações.



As complexas relações entre os componentes de um sistema significam que o sistema em si é maior do que simplesmente a soma de suas partes.



As Arquiteturas de Sistema são normalmente descritas com o uso de Diagramas de Blocos, mostrando os subsistemas principais e suas relações. Veja a figura abaixo como um exemplo desse conceito:







Nós encontramos, nessa imagem, os elementos de ENTRADA e de SAÍDA do SISTEMA. E na parte interna do SISTEMA a composição da inter-relação de várias ENTIDADES. Na parte inferior do SISTEMA temos um importante conceito de feedback chamado de CONTROLE do SISTEMA.



Inicia-se esse controle com um PADRÃO de comparação. Através de um SENSOR que mensura periodicamente as alterações do SISTEMA, compara-se com o PADRÃO. Uma vez o SISTEMA sofrendo alterações em relação ao PADRÃO, o ATIVADOR irá passar parâmetros para o SISTEMA se autocorrigir.



Um bom exemplo prático deste conceito é imaginarmos o ar condicionado. Parte-se inicialmente da base de uma temperatura estabelecida por nós (PADRÃO). O sensor mensura as variações de temperatura. E o ATIVADOR irá deixar o ar condicionado ativado até novamente o SENSOR verificar que a temperatura está no PADRÃO desejado.



Atributos de Software



Os atributos de um bom software refletem seu comportamento quando em funcionamento, a estrutura e a organização do programa fonte, e também a documentação associada (Sommerville). Como exemplos temos o tempo de resposta do software à consulta de um usuário e a facilidade de compreensão do código do programa. Esses mesmos exemplos também podem ser chamados de atributos não funcionais.



Resumidamente o software deve proporcionar ao usuário a funcionalidade e o desempenho requeridos e deve ser passível de manutenção, confiável, eficiente e de fácil uso (veja mais detalhes no quadro abaixo).







Crise do Software e o Início da Engenharia de Software



A crise do software, termo usado nos anos 70, se referia as dificuldades do desenvolvimento de software na época. Por haver um rápido crescimento da demanda por software, imaginava-se que com toda a complexidade no desenvolvimento, haveria uma forte crise.



Com a inexistência da Engenharia de Software nessa época, não havia técnicas estabelecidas para o desenvolvimento de sistemas que funcionassem adequadamente ou que pudessem ser validadas.







Já em 1988, AMBLER afirmava: “Desenvolver software não é somente modelar e escrever código. É criar aplicações que resolvam os problemas dos usuários. É fazer isto dentro do prazo, de forma precisa e com alta qualidade”. Logo, com a crise de software, os desafios para a criação da disciplina de Engenharia de Software eram muito grandes.



Alguns dos típicos problemas que essa nova disciplina enfrentou foram:


Identificar adequadamente os requisitos do Sistema, ou seja, saber o que o software deve fazer;
Que ferramentas, linguagem, sistema operacional usar;
Como diminuir os tempos e custos de desenvolvimento;
Prever falhas antes da entrega final;
Como fazer manutenção e controlar versões;
Dificuldades de prever o progresso durante o desenvolvimento;
Inexistência de histórico, ou documentação, no desenvolvimento de Sistemas;
Comunicação com os usuários precária;
Conceitos quantitativos inexistentes tais como confiabilidade, qualidade e reusabilidade;
Manutenção, no software existente, com difícil execução.





Esse início difícil da Engenharia de Software, com tantos desafios, gerou vários paradigmas e modelos de desenvolvimento.



Desafios da Engenharia de Software



Atualmente os principais desafios da Engenharia de Software, segundo Sommerville, são:







Características do Software


É desenvolvido/projetado por engenharia, não é fabricado;
Não se “desgasta”, mas deteriora! Veja a figura abaixo o comparativo entre a taxa de falhas do hardware com as de software;
Ainda hoje a maioria é feita sob encomenda em vez de ser montada a partir de componentes.









Aplicações do Software


Tempo real;
Software básico;
Sistema de informação;
Embutido;
Técnicos e científicos;
Especialistas;
Apoio à decisão;
Jogos;
Apoio (processador de textos).





Mitos do Software


“Já temos um manual repleto de padrões e procedimentos para a construção de software. Isso já é suficiente para o pessoal do desenvolvimento”.
“Meu pessoal tem ferramentas de última geração, afinal de contas compramos os mais novos computadores”.
“Se nós estamos atrasados nos prazos, podemos adicionar mais programadores e tirar o atraso”.
“Uma declaração geral dos objetivos é suficiente para se começar a escrever programas, podemos preencher os detalhes mais tarde”.
“Os requisitos de projeto modificam-se continuamente, mas as mudanças podem ser facilmente acomodadas, porque o software é flexível”.
“Assim que escrevermos o programa e o colocarmos em funcionamento, nosso trabalho estará completo”.
“Enquanto não tiver o programa funcionando, eu não terei realmente nenhuma maneira de avaliar sua qualidade”.
“A única coisa a ser entregue em um projeto bem-sucedido é o programa funcionando”.





SWEBOK



O SWEBOK (Guide to the Software Engineering Body of Knowledge) é o documento técnico desenvolvido com o apoio do IEEE (Instituto de Engenheiros Elétricos e Eletrônicos, também popularmente chamado de I3E). Esse documento estabelece uma classificação hierárquica dos tópicos tratados pela Engenharia de Software, onde o nível mais alto são as Áreas do Conhecimento.



As dez Áreas do Conhecimento tratadas pelo SWEBOK são:


Requisitos de Software;
Projeto de Software;
Construção de Software;
Teste de Software;
Manutenção de Software;
Gerência de Configuração de Software;
Gerência da Engenharia de Software;
Processo de Engenharia de Software;
Ferramentas e Métodos da Engenharia de Software;
Qualidade de Software.





É importante ressaltar as diferenças entre o SWEBOK e o PMBOK. Enquanto o SWEBOK é dirigido especificamente para a Engenharia de Software, o PMBOK é mais generalizado quanto a Gerenciamento de Projetos como um todo.



Ferramenta CASE



Uma ferramenta CASE (Computer-Aided Software Engineering) significa Engenharia de Software com o auxílio de computador. Ela possibilita apoiar as atividades de processo de software, como a análise de requisitos, a modelagem de sistema, a depuração e os testes. Ferramentas CASE são constituídas com uma ampla gama de diferentes tipos de programas.



As ferramentas CASE podem também incluir um gerador de códigos que, automaticamente, origina o código-fonte a partir da modelagem do Sistema. Adicionalmente pode ter alguma orientação de processo, ao fornecer conselhos ao engenheiro de software sobre o que fazer em seguida.



Uma diferenciação que pode existir nas ferramentas CASE é a denominação Upper-CASE e Lower-CASE. As primeiras têm como utilidade de dar apoio à análise e ao projeto, ou seja, apoiar as fases iniciais do processo de software. As ferramentas Lower-CASE, por outro lado, são projetadas para dar apoio à implementação e aos testes, como depuradores, sistemas de análise de programa, geradores de casos de testes e editores de programas.