Introdução
Grande parte das atividades contemporâneas depende de software: operações bancárias, comunicação, comércio, serviços públicos, gestão de empresas, controle de equipamentos e inúmeras tarefas realizadas em computadores e dispositivos móveis. Entretanto, desenvolver software profissionalmente não significa apenas escrever instruções em uma linguagem de programação. Antes que o código produza resultados úteis, é necessário compreender o problema a ser resolvido, identificar necessidades, definir o funcionamento esperado do sistema, organizar o trabalho, projetar soluções, implementar, verificar sua qualidade e acompanhar sua manutenção e evolução.
Nesse contexto, a Engenharia de Software reúne princípios, métodos e práticas que permitem conduzir o desenvolvimento de sistemas de maneira estruturada. O software passa a ser compreendido não apenas como resultado da programação, mas como produto de um processo que envolve planejamento, análise, projeto, implementação, testes, documentação, implantação e manutenção. Essas atividades estão relacionadas e contribuem para que as soluções desenvolvidas atendam às necessidades identificadas e possam ser modificadas ao longo do tempo.
Esta apostila apresenta uma visão introdutória da Engenharia de Software, abordando sua origem, seus principais conceitos e sua importância para o desenvolvimento de sistemas. Ao longo do conteúdo, serão discutidas características próprias do software, como sua complexidade lógica, a necessidade de colaboração entre diferentes profissionais, a importância da organização e da documentação e sua constante necessidade de manutenção e evolução.
Da programação artesanal à Engenharia de Software
Os primeiros programas de computador eram produzidos em um contexto muito diferente do atual. Os sistemas eram menores, o acesso aos computadores era restrito e o desenvolvimento podia concentrar-se em poucas pessoas. À medida que o uso da computação se ampliou, as aplicações passaram a atender mais usuários, manipular mais dados, integrar diferentes recursos e assumir funções cada vez mais críticas. O aumento de escala e de complexidade tornou insuficiente a ideia de que desenvolver software consistiria apenas em programar e corrigir erros conforme eles aparecessem.
Freitas (2015) apresenta a consolidação da expressão Engenharia de Software no final da década de 1960, quando se fortaleceu a proposta de aplicar princípios de engenharia à produção de sistemas computacionais. O sentido central dessa mudança é estabelecer uma abordagem disciplinada para construir software com qualidade, confiabilidade e eficiência, considerando não somente a programação, mas também a especificação, o projeto, a verificação, o gerenciamento e a manutenção.
Essa perspectiva aparece de modo semelhante em Gonçalves e Cortés (2015), que destacam que o desenvolvimento de software deixou de ser visto como uma atividade artesanal e passou a incorporar técnicas de engenharia para que o produto final possa atender expectativas de custo, prazo e qualidade. A Engenharia de Software, portanto, não é uma técnica isolada. Ela constitui um campo que organiza conhecimentos, métodos e ferramentas destinados a tornar o desenvolvimento mais controlável e repetível.
Processo de software e Engenharia de Software
Um processo de software organiza o trabalho necessário para produzir e modificar um sistema. Nos materiais consultados, o processo é descrito como uma estrutura de atividades ou fases. Essas atividades podem variar em nomenclatura e ordem conforme a abordagem adotada, mas normalmente abrangem a compreensão de requisitos, análise, projeto, implementação, testes, implantação e atividades posteriores de manutenção e evolução.
Freitas (2015) diferencia o processo da própria Engenharia de Software: o processo descreve a organização do trabalho, enquanto a Engenharia de Software acrescenta métodos técnicos, ferramentas e práticas que apoiam a execução desse processo. Gonçalves e Cortés (2015) complementam essa visão ao explicar que cada fase pode possuir entradas, saídas, tarefas e papéis associados. Em outras palavras, o processo ajuda a responder não apenas o que fazer, mas também em que momento, com quais informações, para produzir quais resultados e com a participação de quem.
Isso não significa que exista uma única sequência obrigatória para todos os projetos. Calazans (s.d.) ressalta que não há um processo perfeito aplicável indistintamente a qualquer sistema. As abordagens evoluem e podem ser adaptadas segundo características do produto, da tecnologia, da organização e das pessoas envolvidas. Modelos sequenciais, prototipação, desenvolvimento iterativo e incremental, processos orientados a objetos e métodos ágeis representam formas diferentes de organizar atividades que, em essência, procuram controlar a construção de um produto de software.
A natureza do software: produto, serviço e sistema lógico
Para compreender por que o desenvolvimento de software requer uma engenharia própria, é necessário observar a natureza do que está sendo construído. Em produtos físicos, grande parte do custo está associada à fabricação de unidades materiais. No software, a situação é diferente: o principal esforço concentra-se em compreender, projetar, construir, testar e evoluir uma estrutura lógica. Depois que um programa foi criado, reproduzir seus arquivos não corresponde ao mesmo processo industrial de fabricar novamente uma máquina, uma peça ou um edifício.
Freitas (2015), apoiando-se na literatura clássica da área, destaca três características: o software é desenvolvido, e não manufaturado; não sofre desgaste físico pelo uso; e frequentemente é construído ou adaptado em função de necessidades específicas dos usuários. Essas características não tornam o software simples. Ao contrário, deslocam o problema para a organização lógica do sistema, para a consistência das regras, para as interfaces entre seus componentes e para sua capacidade de continuar útil em ambientes que mudam.
Software como produto
Como produto, o software disponibiliza capacidades computacionais. Ele recebe, transforma, armazena, apresenta ou transmite informações e permite que dispositivos realizem tarefas de interesse do usuário. Um aplicativo de biblioteca, por exemplo, pode registrar livros, controlar empréstimos e reservas, manter dados de usuários e produzir consultas. O conjunto formado pelos programas, configurações e documentação associada compõe um produto que precisa atender necessidades definidas e possuir condições adequadas de funcionamento.
Freitas (2015) também chama atenção para o papel do software como meio de entrega de outras capacidades: sistemas operacionais controlam recursos computacionais; softwares de comunicação permitem a troca de informações; ferramentas de desenvolvimento apoiam a criação de novos programas. Isso mostra que o valor do software não está apenas no código como objeto, mas na função que esse código torna possível.
Software como serviço
Em muitos contextos profissionais, o software é disponibilizado ao usuário como um serviço contínuo, acessado por uma rede ou integrado a outros sistemas. Nessa forma de entrega, o usuário não percebe apenas uma versão instalada do produto: ele depende de disponibilidade, processamento, armazenamento, atualizações, suporte e integração mantidos ao longo do tempo. A diferença está principalmente na forma de oferta e operação; os fundamentos de engenharia permanecem necessários, pois o serviço também precisa ter requisitos, arquitetura, código, testes, documentação, implantação, monitoramento e evolução.
Essa distinção ajuda a perceber que produto e serviço não são categorias totalmente separadas. Um mesmo sistema pode ser tecnicamente um produto de software e, ao mesmo tempo, sustentar a prestação contínua de um serviço. Para a Engenharia de Software, o ponto central é compreender as responsabilidades que essa forma de uso cria. Quanto maior a dependência do usuário em relação ao sistema, maior a importância de características como confiabilidade, segurança, desempenho, disponibilidade e capacidade de mudança.
| Dimensão | Software tratado como produto | Software disponibilizado como serviço |
|---|---|---|
| Entrega | Uma versão ou conjunto de componentes é disponibilizado para uso. | A funcionalidade permanece acessível por uma infraestrutura operada continuamente. |
| Relação com o usuário | O usuário utiliza as capacidades da versão entregue e recebe novas versões quando necessário. | O usuário depende também da operação, disponibilidade e atualização do serviço. |
| Implicação para a engenharia | É necessário especificar, projetar, implementar, testar, documentar e manter o produto. | Além dessas atividades, a continuidade operacional e a evolução frequente tornam-se parte central da entrega de valor. |
Desenvolvimento profissional de sistemas
O desenvolvimento profissional procura substituir a improvisação por um trabalho tecnicamente organizado. Isso não significa eliminar criatividade nem exigir que todos os projetos utilizem o mesmo método. Significa estabelecer uma lógica de produção em que decisões importantes sejam tomadas com base em informações, responsabilidades sejam conhecidas e os resultados de uma atividade possam sustentar as atividades seguintes.
Gonçalves e Cortés (2015) apresentam um encadeamento formado por levantamento de requisitos, análise, projeto, desenvolvimento, teste, validação e implantação. Freitas (2015) descreve estrutura semelhante ao tratar do ciclo de vida do software. Já Calazans (s.d.) observa que essas atividades podem ser agrupadas e executadas em ordens diferentes conforme a metodologia adotada. A sequência abaixo deve, portanto, ser entendida como uma visão conceitual do trabalho, e não como uma regra de que todo projeto precise avançar uma única vez e sem retornos.
Da necessidade ao requisito
O trabalho começa antes do código. É necessário compreender o contexto em que o sistema será utilizado e transformar necessidades em informações suficientemente claras para orientar o desenvolvimento. Calazans (s.d.) e Gonçalves e Cortés (2015) destacam técnicas como entrevistas, análise de documentos, observação, oficinas, questionários e prototipação. O objetivo não é apenas registrar pedidos, mas construir entendimento compartilhado entre pessoas que conhecem o negócio e pessoas que irão construir a solução.
Essa etapa reduz um risco central: desenvolver corretamente uma solução para um problema entendido de maneira incorreta. Um programa pode estar tecnicamente bem escrito e ainda assim fracassar se suas funções não correspondem às necessidades dos usuários. Por isso, requisitos e validação são elementos estruturantes da Engenharia de Software.
Da análise ao projeto
A análise procura organizar o entendimento do problema e representar o que o sistema deverá fazer, quais informações manipulará e como deverá se comportar. O projeto aprofunda esse entendimento e estabelece decisões sobre como a solução será construída. Gonçalves e Cortés (2015) usam a comparação com projetos de construção civil para mostrar por que representações antecipadas são úteis: um modelo permite discutir características antes que a implementação esteja pronta e torna mais barato identificar inconsistências em fases iniciais.
Modelos e diagramas não substituem o sistema real. Eles reduzem a complexidade ao oferecer visões específicas do sistema. Em projetos orientados a objetos, por exemplo, a UML pode representar estrutura, comportamento e interação por diferentes diagramas. O princípio mais importante nesta introdução é que modelar significa selecionar aspectos relevantes da realidade para raciocinar sobre eles antes ou durante a implementação.
Implementação, verificação e entrega
Na implementação, decisões de análise e projeto são convertidas em código e demais componentes executáveis. O desenvolvimento profissional, contudo, não considera a existência do código como prova suficiente de que o sistema está pronto. Testes verificam se unidades e integrações produzem resultados compatíveis com as especificações; a validação procura confirmar se o produto efetivamente atende às necessidades acordadas; e a implantação disponibiliza o sistema no ambiente real de operação.
Essa relação entre etapas mostra por que a Engenharia de Software trabalha com rastreabilidade. Gonçalves e Cortés (2015) explicam que requisitos originam artefatos posteriores, como casos de uso, diagramas, código e testes. Manter relações compreensíveis entre esses elementos ajuda a descobrir o impacto de uma mudança e a verificar se aquilo que foi solicitado está representado na solução construída.
Complexidade, trabalho em equipe e comunicação
Software é constituído por componentes lógicos que se relacionam. À medida que crescem as funcionalidades, regras de negócio, integrações, volumes de dados, perfis de usuário e restrições técnicas, aumenta também o número de relações que precisam permanecer coerentes. A complexidade não depende apenas da quantidade de linhas de código: um sistema relativamente pequeno pode ser difícil de construir quando contém muitas regras interdependentes, integrações delicadas ou exigências rigorosas de desempenho e segurança.
Freitas (2015) associa o surgimento da Engenharia de Software justamente ao desafio de construir sistemas complexos compostos por estruturas de dados, algoritmos e unidades interconectadas. A engenharia procura tornar essa complexidade administrável por meio da decomposição do problema, da separação de responsabilidades, do uso de modelos, da definição de interfaces, de processos de trabalho e de mecanismos de verificação.
Por que o desenvolvimento é coletivo
Em um projeto profissional, diferentes pessoas possuem conhecimentos diferentes. Usuários e gestores conhecem necessidades do negócio; profissionais de análise ajudam a estruturar requisitos e modelos; desenvolvedores transformam decisões em software executável; profissionais de teste verificam comportamentos; responsáveis pela infraestrutura e operação conhecem condições do ambiente em que o sistema será executado. Dependendo do porte e do processo adotado, uma mesma pessoa pode acumular várias dessas responsabilidades, mas as responsabilidades continuam existindo.
Gonçalves e Cortés (2015) observam que cada atividade de um processo possui papéis associados. Calazans (s.d.) reforça a dimensão colaborativa ao tratar de entrevistas e workshops de requisitos, nos quais desenvolvedores e stakeholders precisam chegar a entendimentos suficientemente claros sobre o problema. O desenvolvimento profissional é, assim, tanto uma atividade técnica quanto uma atividade de comunicação.
Essa comunicação precisa vencer diferenças de linguagem. O usuário geralmente descreve situações do domínio profissional; a equipe técnica pensa em dados, regras, componentes e restrições computacionais. Modelos, protótipos, documentos e critérios de aceitação funcionam como meios de tradução entre essas perspectivas. Quanto maior o projeto, mais importante se torna criar formas de registrar decisões e reduzir interpretações contraditórias.
Planejamento, documentação e controle da construção
Planejar software não significa tentar prever com absoluta precisão tudo o que acontecerá no projeto. Significa organizar objetivos, escopo, entregas, prioridades, recursos, responsabilidades e critérios de acompanhamento de forma compatível com as incertezas existentes. Em um processo sequencial, o planejamento pode enfatizar a conclusão de fases. Em processos iterativos e incrementais, o trabalho pode ser organizado em ciclos e entregas parciais que adicionam funcionalidades progressivamente.
Calazans (s.d.) caracteriza o desenvolvimento iterativo como uma estratégia em que se definem entregas das partes do sistema e o desenvolvimento incremental como uma organização em estágios na qual versões sucessivas incorporam novas funcionalidades. Essa lógica permite transformar um produto grande em partes mais administráveis, obter retorno mais cedo e ajustar decisões com base no que foi aprendido durante o próprio desenvolvimento.
Planejamento e adaptação, portanto, não são opostos. A Engenharia de Software precisa de direção, mas também precisa reconhecer que requisitos podem ser refinados, tecnologias podem impor limitações e necessidades do usuário podem mudar. O processo escolhido estabelece como essas mudanças serão tratadas sem perder a visão do produto como um todo.
Documentação como memória e instrumento de comunicação
Calazans (s.d.) apresenta uma definição de software que inclui programas e documentação associada. Essa associação é importante porque um sistema profissional não existe apenas no momento em que seu código é escrito. Ele precisa ser compreendido por pessoas que irão validar, testar, operar, corrigir ou ampliar suas funcionalidades posteriormente.
Documentar não significa produzir registros sem finalidade. A documentação pode assumir diferentes formas, como requisitos, modelos, diagramas, descrições de interfaces, decisões de arquitetura, critérios de teste, instruções de implantação e informações operacionais. O nível de detalhe varia conforme o contexto, mas a finalidade permanece: preservar informação necessária para que o trabalho possa ser compreendido e continuado.
Os materiais consultados dão especial ênfase à documentação de requisitos e à modelagem. Gonçalves e Cortés (2015) descrevem os requisitos como base para artefatos posteriores e ressaltam a necessidade de rastreabilidade. Calazans (s.d.) afirma que a modelagem é uma forma de documentação e relaciona sua importância à manutenção: sistemas mudam por solicitações dos clientes, pressões do mercado, alterações legais ou correções de falhas, e uma documentação adequada ajuda a realizar essas mudanças com menor risco de introduzir novos erros.
| Elemento de controle | Função no desenvolvimento | Risco reduzido |
|---|---|---|
| Planejamento | Organiza entregas, prioridades, responsabilidades e critérios para acompanhar o trabalho. | Improvisação, atrasos invisíveis e esforço concentrado em itens de baixo valor. |
| Requisitos | Registram necessidades, funções e restrições que orientam análise, projeto, implementação e validação. | Construção de funcionalidades diferentes daquelas realmente necessárias. |
| Modelos e decisões de projeto | Permitem raciocinar sobre estrutura e comportamento antes ou durante a implementação. | Inconsistências arquiteturais e decisões técnicas difíceis de explicar ou revisar. |
| Testes e critérios de validação | Estabelecem formas verificáveis de confrontar o sistema com comportamentos esperados. | Aceitação baseada apenas em impressão subjetiva ou ausência aparente de erros. |
| Rastreabilidade | Relaciona requisitos aos artefatos derivados e ajuda a localizar impactos de mudanças. | Alterações incompletas, esquecimentos e perda da origem das decisões. |
Manutenção e evolução do software
Quando um produto físico é utilizado continuamente, peças podem sofrer desgaste e precisar de substituição. O software não se desgasta dessa maneira. Freitas (2015) ressalta que seus componentes lógicos não se deterioram fisicamente pelo uso. Ainda assim, um sistema pode deixar de atender adequadamente seus usuários. Isso ocorre porque o ambiente ao redor dele muda: surgem novas necessidades, regras de negócio são alteradas, tecnologias são atualizadas, integrações mudam, vulnerabilidades são descobertas e falhas precisam ser corrigidas.
Por essa razão, a entrega inicial não encerra necessariamente o trabalho de engenharia. A fase de operação expõe o sistema ao uso real e produz novas informações sobre seu comportamento. Algumas modificações corrigem defeitos; outras adaptam o sistema a novas condições; outras ampliam capacidades ou melhoram características existentes. Independentemente da motivação, cada mudança pode afetar componentes já construídos e precisa ser analisada de maneira controlada.
Calazans (s.d.) observa que clientes solicitam melhorias, o mercado impõe mudanças, leis são modificadas e sistemas apresentam falhas. Gonçalves e Cortés (2015) acrescentam que, quando o software evolui, os requisitos constituem uma referência importante para compreender a origem das mudanças. Assim, manutenção e evolução estão diretamente ligadas à qualidade da análise, da documentação e da arquitetura produzidas desde as fases iniciais.
Evolução como parte do ciclo de vida
O conceito de ciclo de vida ajuda a compreender que software não é apenas construído e entregue. Freitas (2015) apresenta etapas que incluem análise, projeto, codificação, teste e uso, destacando que o software pode sofrer modificações para continuar atendendo aos usuários. Em processos modernos, essas etapas não precisam ocorrer uma única vez. Um sistema pode passar repetidamente por identificação de necessidades, implementação, testes e implantação de novas versões.
Esse caráter evolutivo muda a forma de avaliar a qualidade de um projeto. Uma solução não deve apenas funcionar hoje; precisa também ser compreensível o suficiente para ser corrigida e modificada amanhã. Decisões que aceleram uma entrega imediata, mas tornam o código, os modelos ou as interfaces difíceis de alterar, podem aumentar o custo das próximas mudanças. A Engenharia de Software procura equilibrar entrega de valor no presente com capacidade de continuidade.
Por isso, manutenção não deve ser tratada como um trabalho totalmente separado do desenvolvimento. Ela é uma consequência natural de manter o software útil em um contexto que se transforma. Requisitos bem compreendidos, responsabilidades claras, modelos adequados, código organizado, testes e documentação coerente reduzem a dependência da memória individual e fornecem uma base mais segura para a evolução do sistema.
Síntese
A Engenharia de Software surgiu da necessidade de tratar o desenvolvimento de sistemas como uma atividade organizada de engenharia, capaz de lidar com produtos lógicos cada vez mais complexos. Seu alcance é maior do que a programação: envolve processos, métodos, ferramentas e decisões que percorrem a compreensão de necessidades, a análise, o projeto, a implementação, os testes, a validação, a implantação e a evolução.
O software possui características próprias. Ele é desenvolvido, e não fabricado em série como um objeto físico; não sofre desgaste material pelo uso; e frequentemente precisa ser adaptado às necessidades de seus usuários. Pode ser entregue como produto ou sustentar um serviço contínuo, mas em ambos os casos depende de qualidade técnica, clareza de requisitos e capacidade de mudança.
O desenvolvimento profissional transforma complexidade em trabalho administrável. Para isso, divide problemas, atribui responsabilidades, promove comunicação entre diferentes participantes, utiliza modelos e documentação e organiza entregas segundo um processo adequado ao contexto. Planejamento não elimina mudanças; cria uma estrutura para que elas possam ser percebidas e incorporadas de forma controlada.
Por fim, a vida útil do software continua após sua primeira implantação. Correções, adaptações e novas necessidades fazem parte de sua evolução. A qualidade do trabalho realizado desde o início influencia diretamente a facilidade com que o sistema poderá ser compreendido, mantido e ampliado. Essa visão integrada constitui a base para estudar, nas etapas seguintes da disciplina, Engenharia de Requisitos, metodologias de desenvolvimento, análise e projeto de sistemas.
Referências
- BAHIA. Secretaria da Educação. Superintendência da Educação Profissional e Tecnológica. Ementa - Técnico em Informática - PROSUB. Salvador: SUPROT, [s.d.].
- CALAZANS, Angélica Toffano Sedel. Análise e Projeto de Sistemas. Curso Técnico em Informática. Brasília: Instituto Federal de Brasília, [s.d.].
- FREITAS, Romualdo Rubens de. Análise e Projeto de Software. Cuiabá, MT: Rede e-Tec Brasil/UFMT, 2015.
- GONÇALVES, Enyo José Tavares; CORTÉS, Mariela Inés. Análise e Projeto de Sistemas. 3. ed. Fortaleza: EdUECE, 2015.