❧ Introdução à Engenharia de Software ❧

Introdução2.1

Hoje, dificilmente conseguimos imaginar nossas vidas sem softwares complexos. Eles deixaram de ser apenas ferramentas de cálculo para se tornarem a espinha dorsal de infraestruturas críticas, telecomunicações, internet e até da exploração espacial. À medida que nossas demandas evoluem, exigimos sistemas cada vez maiores e com capacidades que antes eram consideradas impossíveis. O problema central que enfrentamos é que os métodos antigos de desenvolvimento já não conseguem lidar com essa complexidade, exigindo novas técnicas de engenharia para atender a essas demandas com segurança e eficiência.

Existe uma percepção equivocada, e perigosa, de que escrever programas é fácil. Isso ocorre porque é relativamente simples escrever pequenos programas pessoais sem usar engenharia. No entanto, muitas empresas acabam caindo na armadilha de desenvolver sistemas maiores sem usar métodos adequados, simplesmente porque seus produtos evoluíram organicamente e elas não adotaram práticas de engenharia no dia a dia. A consequência direta disso é que o software se torna mais caro e muito menos confiável do que deveria ser. É para solucionar esses problemas de escala, custo e confiabilidade que a Engenharia de Software se torna indispensável.

Desenvolvimento Profissional de Software2.1.1

Você deve diferenciar claramente o que é programação pessoal do que é desenvolvimento profissional. Muitas pessoas escrevem códigos: cientistas processando dados experimentais, hobbistas criando projetos pessoais ou profissionais de negócios automatizando planilhas. Nesses casos, se o código funciona para o autor, o objetivo foi cumprido.

Por outro lado, o desenvolvimento de software profissional tem um propósito comercial ou de negócio específico e, crucialmente, é usado por outras pessoas além de quem o desenvolveu. Esses sistemas geralmente são criados por equipes, e não por indivíduos isolados. Eles são mantidos e alterados ao longo de muitos anos. A engenharia de software foca exatamente aqui: ela fornece as técnicas para especificação, projeto e evolução que não são necessárias quando você escreve um programa apenas para si mesmo.

É vital compreender que software não é apenas o programa de computador (o código em si). Quando falamos profissionalmente, software inclui toda a documentação associada, bibliotecas, arquivos de configuração necessários para operação, manuais de usuário e até sites para download de atualizações. Se você cria algo para uso próprio, não precisa se preocupar com manuais; mas se outros engenheiros precisarão manter seu código no futuro, a documentação é tão importante quanto o código.

Os produtos de software que os engenheiros desenvolvem podem ser divididos em duas categorias principais:

1. Produtos Genéricos: São sistemas stand-alone produzidos por uma organização e vendidos no mercado aberto para qualquer cliente interessado. Exemplos incluem bancos de dados, processadores de texto, ferramentas gráficas e aplicações verticais como sistemas de bibliotecas. Aqui, a organização que desenvolve o software controla a especificação.
2. Produtos sob Encomenda: São sistemas encomendados por um cliente específico para resolver um problema particular. Exemplos incluem controle de tráfego aéreo, sistemas de controle de dispositivos eletrônicos ou processos de negócio específicos. Nesse caso, a especificação é controlada pela empresa que está comprando o software, e os desenvolvedores trabalham para atendê-la.

Atualmente, essa distinção está ficando menos clara (obscura), pois muitos sistemas encomendados são construídos adaptando produtos genéricos (como sistemas ERP - Enterprise Resource Planning, a exemplo do SAP) para as regras de negócio de um cliente específico.

O Que é Engenharia de Software?2.2

Para consolidar seu entendimento, vamos responder às perguntas mais frequentes sobre a área, transformando conceitos técnicos em definições práticas que você levará para a carreira.

A Engenharia de Software é uma disciplina da engenharia preocupada com todos os aspectos da produção de software. Isso significa que ela não foca apenas no código ou nos processos técnicos, mas vai desde a especificação inicial do sistema, passando pelo gerenciamento de projeto, até a manutenção após o uso. Como disciplina de engenharia, ela busca fazer as coisas funcionarem aplicando teorias, métodos e ferramentas seletivamente, sempre respeitando restrições financeiras e organizacionais. Engenheiros não buscam a perfeição a qualquer custo; eles buscam soluções funcionais dentro do prazo e orçamento.

É importante distinguir a área de suas disciplinas irmãs:

• Diferente da Ciência da Computação: A Ciência foca na teoria e nos fundamentos (como algoritmos e complexidade). A Engenharia de Software preocupa-se com os problemas práticos de desenvolver e entregar software útil. O conhecimento científico é essencial para o engenheiro, assim como a física é para o engenheiro elétrico, mas a teoria pura nem sempre resolve problemas complexos de larga escala.
• Diferente da Engenharia de Sistemas: A Engenharia de Sistemas lida com todo o sistema computacional, incluindo o desenvolvimento de hardware, políticas, processos e implantação. A engenharia de software é uma parte específica desse processo mais genérico.

Os principais desafios que você enfrentará na área incluem a heterogeneidade (sistemas distribuídos em redes e dispositivos móveis variados), a mudança corporativa e social (demandas por prazos de entrega cada vez menores) e a segurança e confiança (garantir que softwares vitais não sejam atacados ou falhem).

O Processo de Software2.2.1

Embora cada tipo de sistema exija ferramentas diferentes, existem quatro atividades fundamentais que são comuns a todos os processos de software. A abordagem sistemática usada na engenharia é chamada de processo de software:

1. Especificação de software: Onde clientes e engenheiros definem o software a ser produzido e as restrições de sua operação.
2. Desenvolvimento de software: A etapa onde o software é projetado e programado.
3. Validação de software: A verificação para garantir que o sistema é o que o cliente quer.
4. Evolução de software: A modificação do sistema para refletir a mudança de requisitos do cliente e do mercado.

Atributos de um Bom Software2.2.2

A qualidade de um software profissional não se resume ao que ele faz (funcionalidade), mas também a como ele se comporta (atributos não funcionais). Um bom software deve possuir as seguintes características essenciais:

• Manutenibilidade: O software deve ser escrito de forma que possa evoluir para atender às necessidades dos clientes. Esse é um atributo crítico, pois a mudança é inevitável no ambiente de negócios.
• Confiança e Proteção: Isso inclui confiabilidade, segurança e proteção. O software não deve causar prejuízos físicos ou econômicos em caso de falha, e deve impedir o acesso de usuários maliciosos.
• Eficiência: O sistema não deve desperdiçar recursos como memória e ciclos do processador. Isso se traduz em capacidade de resposta e tempos de processamento adequados.
• Aceitabilidade: O software deve ser aceitável para o tipo de usuário para o qual foi projetado. Isso significa ser compreensível, usável e compatível com outros sistemas.

Diversidade na Engenharia de Software2.3

Não existe uma "bala de prata" ou um método universal na engenharia de software. O método certo depende drasticamente do tipo de aplicação que você está desenvolvendo. Um jogo para celular tem restrições completamente diferentes de um sistema de controle de voo, e tentar usar o mesmo processo para ambos resultaria em fracasso.

Podemos categorizar as aplicações em diversos tipos, cada um exigindo abordagens específicas:

1. Aplicações Stand-alone: Rodam em um computador local (como um PC) e possuem toda a funcionalidade necessária internamente, sem precisar de rede constante (ex: softwares de escritório, CAD, manipulação de fotos).
2. Aplicações Interativas Baseadas em Transações: Executam remotamente e são acessadas por terminais ou PCs. Isso inclui desde e-commerce até sistemas corporativos em nuvem e e-mail.
3. Sistemas de Controle Embutidos: Controlam e gerenciam dispositivos de hardware. Provavelmente são o tipo mais numeroso, presentes em celulares, micro-ondas e sistemas de freios antitravamento.
4. Sistemas de Processamento de Lotes: Projetados para processar grandes volumes de dados (inputs) e gerar saídas correspondentes, como sistemas de folha de pagamento ou cobrança telefônica.
5. Sistemas de Entretenimento: Jogos e multimídia, onde a qualidade da interação com o usuário é o requisito mais crítico.
6. Sistemas para Modelagem e Simulação: Desenvolvidos para cientistas e engenheiros modelarem processos físicos. Requerem alto desempenho computacional e execução paralela.
7. Sistemas de Coleta de Dados: Coletam informações de sensores em ambientes (muitas vezes hostis) e as enviam para processamento.
8. Sistemas de Sistemas: Compostos por uma série de outros sistemas de software operando em conjunto, muitas vezes integrando produtos genéricos.

Apesar dessa diversidade, existem fundamentos universais: processo gerenciado, confiabilidade, entendimento de requisitos e reúso eficiente de recursos.

Engenharia de Software e a Internet2.3.1

A evolução da Internet mudou radicalmente a engenharia de software. Inicialmente, a web era apenas um repositório de informações, mas evoluiu para uma plataforma de aplicações ricas. Isso permitiu que o software deixasse de ser instalado e gerenciado em cada computador local para ser implantado em servidores e acessado via navegadores.

Essa mudança reduziu custos de instalação e manutenção, levando ao conceito de Web Services (componentes acessados via internet) e Computação em Nuvem (Cloud Computing). Hoje, vivemos a era do "Software como Serviço" (SaaS), onde você não compra o software, mas paga pelo uso.

Isso impôs mudanças profundas na forma como construímos sistemas:

• Reúso Massivo: O reúso tornou-se a abordagem dominante. Sistemas web são montados integrando componentes preexistentes.
• Desenvolvimento Incremental: Aceita-se que é impraticável especificar todos os requisitos antecipadamente; os sistemas devem ser entregues e evoluídos incrementalmente.
• Interfaces de Usuário: Embora tecnologias como AJAX permitam interfaces ricas, elas ainda são limitadas pelas capacidades dos navegadores em comparação a softwares nativos de PC.

Ética na Engenharia de Software2.4

Como engenheiro de software, suas responsabilidades vão muito além do aspecto técnico. Você opera dentro de um framework legal e social, e deve se comportar de maneira ética para ser respeitado como profissional. Padrões de honestidade e integridade são inegociáveis.

Existem áreas onde a responsabilidade profissional é crítica, mesmo que a lei não seja explícita:

• Confidencialidade: Você deve respeitar os segredos do empregador ou cliente, independentemente de ter assinado um acordo formal.
• Competência: Você não deve deturpar seu nível de competência nem aceitar trabalhos para os quais não está preparado.
• Propriedade Intelectual: Deve conhecer e proteger leis de patentes e copyright de empregadores e clientes.
• Mau Uso de Computadores: Não deve usar suas habilidades para prejudicar outros, espalhar vírus ou usar recursos da empresa para fins pessoais indevidos.

Organizações profissionais como a ACM e o IEEE cooperaram para produzir um Código de Ética e Práticas Profissionais. Ao se tornar membro, você se compromete a segui-lo.

Dilemas Éticos2.4.0.1

Na prática, você enfrentará situações onde princípios entram em conflito. Imagine que seu empregador, pressionado por prazos, decida lançar um sistema de segurança crítica sem completar todos os testes de validação, falsificando os registros. Qual é a sua responsabilidade? Manter a confidencialidade do empregador ou alertar o cliente/público sobre o risco?

Não há uma resposta absoluta fácil. O sistema pode ser seguro mesmo sem o teste, ou pode falhar catastroficamente. Divulgar o problema pode destruir a empresa e empregos; não divulgar pode custar vidas. Em casos extremos de perigo, a divulgação pública pode ser justificável, mas você deve sempre tentar resolver o problema internamente primeiro.

Outro dilema comum envolve a participação em sistemas militares e nucleares. Alguns engenheiros recusam-se a trabalhar com armas por princípios; outros veem a segurança nacional como um princípio ético válido. O importante é que empregadores e empregados sejam transparentes sobre suas visões antes da contratação, evitando pressões futuras.

Estudos de Caso2.5

Para ilustrar a diversidade da engenharia de software e mostrar que não existe técnica única, o livro texto utiliza três estudos de caso recorrentes ao longo do material que também iremos utilizar ao decorrer da disciplina. Veremos, em alto nível, os três sistemas para termos uma noção do que será trabalhado posteriormente.

Sistema de Controle de Bomba de Insulina2.5.1

Tipo: Sistema Embutido | Foco: Segurança Crítica

Este sistema médico simula o pâncreas humano. O software coleta dados de um sensor de glicose (que mede a condutividade do sangue) e controla uma bomba miniaturizada para injetar a dose correta de insulina. O hardware, ilustrado na figura abaixo, inclui sensor, controlador, bomba, alarme, displays e fonte de energia.

Enquanto isso, o software do sistema da bomba irá transformar a leitura do sensor em comandos de pulso para que a bomba possa injetar a dose correta no paciente. A figura abaixo é um modelo de atividade UML (linguagem de modelagem unificada, do inglês unified modeling language), que ilustra como o software transforma uma entrada de nível de açúcar no sangue em uma sequência de comandos que operam a bomba de insulina.

Requisitos Críticos:

• Disponibilidade: O sistema deve estar sempre disponível para fornecer insulina quando necessário.
• Confiabilidade: Deve calcular e entregar a dose exata. Uma falha (dose excessiva ou insuficiente) pode levar o usuário ao coma ou à morte. Por isso, é gravado em memória ROM e sua alteração é cara e complexa.

MHC-PMS: Sistema de Informação de Saúde Mental2.5.2

Tipo: Sistema de Informação | Foco: Privacidade e Hibridismo

O MHC-PMS (Mental Health Care-Patient Management System) gerencia dados de pacientes em clínicas de saúde mental. Diferente de um sistema hospitalar comum, ele precisa lidar com pacientes que podem ser desorganizados ou perigosos. A Figura abaixo ilustra a organização do MHC-PMS.

O sistema é híbrido: funciona conectado a um banco de dados central, mas também deve rodar em PCs locais desconectados (baixando registros), pois algumas clínicas não têm rede segura. Requisitos Críticos:

• Privacidade: Informações sobre condições mentais são extremamente sensíveis.
• Segurança: O sistema deve alertar a equipe médica se um paciente for potencialmente perigoso para si ou para outros, facilitando inclusive internações compulsórias (sujeitas a rigorosa legislação).

Estação Meteorológica no Deserto2.5.3

Tipo: Sistema de Coleta de Dados | Foco: Autonomia e Ambiente Hostil

Parte de um sistema maior de monitoramento climático, estas estações são instaladas em áreas remotas de deserto. Elas coletam dados (vento, temperatura, chuva) e os transmitem via satélite para um sistema central.

As estações meteorológicas no deserto são parte de um sistema maior, veja a figura abaixo, um sistema de informações meteorológicas que coleta dados a partir das estações meteorológicas e os disponibiliza para serem processados por outros sistemas.

Foram utilizados os símbolo de pacote da UML para indicar que cada sistema é uma coleção de componentes, de forma que foram identificados como sistemas separados, usando o estereótipo <<sistema>> da UML. As associações entre os pacotes indicam que há uma troca de informações, que nesse estágio aina não é necessário que abordemos. Abaixo é fornecido uma explicação melhor sobre cada sistema.

• Sistema da estação meteorológica. Responsável por coletar dados meteorológicos, efetuar algum processamento inicial de dados e transmiti-los para o sistema de gerenciamento de dados.
• Sistema de gerenciamento e arquivamento de dados. Esse sistema coleta os dados de todas as estações meteorológicas, executa o processamento e a análise dos dados e os arquiva de forma que possam ser obtidos por outros sistemas, como sistemas de previsões de tempo.
• Sistema de manutenção da estação. Esse sistema pode se comunicar via satélite com todas as estações meteorológicas no deserto para monitorar as condições desses sistemas e fornecer relatórios sobre os problemas. Ele também pode atualizar o software embutido nesses sistemas. Em caso de problema com o sistema ele pode, ainda, ser usado para controlar remotamente um sistema meteorológico no deserto.

Complexidade:

• Autonomia: A estação deve ser autossuficiente em energia (solar/eólica) e gerenciar seu consumo.
• Resiliência: O software deve lidar com falhas de componentes e comunicação instável (satélite lento). Se a conexão falhar, os dados devem ser guardados localmente.
• Manutenção Remota: O software deve permitir reconfiguração e atualização via satélite, pois visitas físicas são raras e caras.

Questões2.6

1. O texto destaca uma distinção clara entre "programação pessoal" e "desenvolvimento profissional". Explique por que um programa que funciona perfeitamente para seu autor pode ser considerado inadequado ou incompleto sob a ótica da Engenharia de Software profissional. Qual o papel da documentação nesse contexto?

2. Compare os produtos de software genéricos com os produtos sob encomenda. De quem é a responsabilidade de controlar a especificação em cada caso? Discuta como sistemas ERP (como SAP) tornaram essa distinção "menos clara" ou obscura atualmente.

3. É comum confundir Engenharia de Software com Ciência da Computação e Engenharia de Sistemas. Defina a Engenharia de Software e explique como ela difere dessas outras duas disciplinas, focando na distinção entre "teoria vs. prática" e "software vs. sistema completo".

4. O texto lista quatro atributos essenciais para um bom software: Manutenibilidade, Confiança/Proteção, Eficiência e Aceitabilidade. Explique por que a falha em atendê-los pode resultar em prejuízo econômico ou rejeição do produto pelo usuário.

5. "Não existe uma bala de prata na engenharia de software". Utilize os exemplos de Sistemas de Controle Embutidos (como a bomba de insulina) e Sistemas de Entretenimento para justificar por que o mesmo processo de desenvolvimento não pode ser aplicado universalmente a todos os tipos de software.

6. A evolução da web de um repositório de informações para uma plataforma de aplicações alterou profundamente a engenharia de software. Explique como o conceito de "Software como Serviço" (SaaS) impactou a forma como os sistemas são especificados e a importância do reúso de componentes.

7. Um engenheiro de software é convidado a desenvolver um sistema de controle nuclear, mas sua especialidade é apenas em interfaces web (front-end). Baseado nos princípios de responsabilidade profissional citados no texto (especificamente Competência), como ele deve proceder? Além disso, explique a regra de Confidencialidade mesmo na ausência de um contrato formal.

8. Considere o cenário hipotético apresentado no texto: seu empregador decide lançar um sistema de segurança crítica sem completar todos os testes para cumprir um prazo, falsificando registros. Discuta o conflito entre "Interesse do Cliente/Empregador" e "Interesse Público" (conforme o código da ACM/IEEE) e as dificuldades de tomar uma decisão nesse cenário.

9. Analise o sistema de controle de bomba de insulina descrito no estudo de caso. Por que a "Confiabilidade" é o requisito mais crítico deste sistema e como isso influencia a decisão de gravar o software em memória ROM, tornando sua alteração difícil?

10. No sistema de estação meteorológica no deserto, o software precisa lidar com um ambiente hostil e isolado. Explique como os requisitos de "Autonomia" e "Manutenção Remota" diferenciam este projeto de um sistema de gestão corporativo comum (como o MHC-PMS).

Próximos Passos2.7

No próximo capítulo, Modelos de Processo de Software, exploraremos os principais processos de Software. Veremos como as atividades fundamentais (especificação, desenvolvimento, validação e evolução) são organizadas em diferentes modelos de processo, como cascata, incremental e ágil, e como escolher o modelo mais adequado para cada um dos cenários que vimos nos estudos de caso.