Fase 1: Fundamentos e Processos de Software (Capítulos 1 e 2)

A Engenharia de Software não é apenas "fazer código". É uma disciplina da

engenharia que se ocupa de todos os aspetos práticos relacionados com a
produção e entrega de software útil e fiável. Uma das grandes premissas que tens
de fixar é que os custos de software dominam, sendo que os custos associados à
manutenção do software superam frequentemente os custos do seu
desenvolvimento inicial. Isto é especialmente crítico em sistemas com um longo
tempo de vida, onde os custos de evolução são várias vezes superiores.

1. Tipos de Software (🔥 Foco de Exame do Professor)

O processo de desenvolvimento muda radicalmente dependendo de para quem
estamos a construir o sistema. Existem duas grandes categorias:

●​ Software Genérico: São sistemas stand-alone desenvolvidos por uma

organização e vendidos a qualquer cliente no mercado aberto (ex: aplicações
móveis, folhas de cálculo). Neste cenário, o cliente final não participa na
especificação dos requisitos; a empresa que cria o software dita o que ele
faz.
●​ Software Personalizado (à medida): São sistemas encomendados e
desenvolvidos exclusivamente para um determinado cliente (ex: sistemas de
controlo de tráfego aéreo, sistemas de controlo industrial). Aqui, é o cliente
que controla a especificação dos requisitos e o software tem de se adaptar
100% ao seu negócio.

Nota de Exame: O professor costuma perguntar o impacto prático disto. Na prática,

no software genérico, o utilizador tem de adaptar a sua forma de trabalhar ao
programa. No software personalizado, o programa adapta-se aos processos do
utilizador, sendo mais eficaz, mas muito mais caro.

2. Os 4 Atributos do Bom Software

Não basta funcionar. Para o software ter qualidade profissional, precisa de cumprir
quatro atributos essenciais:

1.​ Manutenibilidade (Maintainability): O software tem de ser escrito de forma

a poder evoluir e satisfazer as mudanças do negócio. Como a mudança é
inevitável, este é um atributo crítico.
2.​ Fiabilidade e Segurança (Dependability and security): O software não
pode causar danos físicos ou económicos em caso de falha, e tem de impedir
o acesso de utilizadores maliciosos.
3.​ Eficiência (Efficiency): O software não deve desperdiçar recursos do
sistema, como memória ou processamento. Inclui o tempo de resposta e de
processamento.
4.​ Aceitabilidade (Acceptability): O software tem de ser compreensível,
usável e compatível com os outros sistemas que os utilizadores já utilizam.
2.1 A Importância Crítica da Confiabilidade ( 🔥 Pergunta de Exame)
De todos os atributos, a confiabilidade (fiabilidade) do software é frequentemente o
mais crítico, por 6 razões fundamentais:

1.​ Custos de falha: Sistemas em baixo geram perdas financeiras imediatas (ex:
banco offline).
2.​ Segurança de vida: Falhas em sistemas críticos (como aviação ou hospitais)
podem ser fatais.
3.​ Reputação: Falhas frequentes destroem a confiança do cliente e mancham a
imagem da marca.
4.​ Dependência social: A sociedade moderna colapsaria sem os sistemas que
gerem serviços básicos (água, luz, comunicações).
5.​ Integridade dos dados: Defeitos podem corromper bases de dados inteiras,
causando perdas irrecuperáveis.
6.​ Custos de manutenção: Corrigir erros depois do software ser lançado é
muitíssimo mais caro do que prevenir os erros na fase de projeto.

3. Atividades Fundamentais do Processo

Independentemente da metodologia que uses, existem 4 atividades que acontecem
sempre na engenharia de software:

●​ 1. Especificação do software: Definir os requisitos (o que o sistema vai fazer)

e as suas restrições operacionais.
●​ 2. Desenvolvimento: A fase de projeto (design) e a programação (codificação)
do sistema.
●​ 3. Validação: Verificar se o software cumpre com os requisitos pedidos pelo
cliente.
●​ 4. Evolução: Modificar o software para dar resposta a alterações de requisitos
motivadas pelo mercado ou pelo cliente.

4. Modelos de Processo ( 🔥 Garantia de Exame)

Os modelos de processo são representações abstratas e simplificadas de como
organizamos o ciclo de vida do software. Tens de dominar três:

A. Modelo em Cascata (Waterfall):

●​ Como funciona: É um modelo sequencial e orientado para o planeamento.

Planeiam-se todas as atividades antes de começar a desenvolver. As fases
são: Definição de Requisitos, Projeto de Sistema/Software, Implementação e
Teste Modular, Integração/Teste do Sistema, e finalmente Operação e
Manutenção.
●​ A Regra: Uma fase não se deve iniciar sem que a anterior (e a sua respetiva
documentação) esteja totalmente concluída e aprovada.
 ●​ Quando usar: Em sistemas críticos ou de grande dimensão onde os
requisitos são bem compreendidos e pouco propensos a mudar.

B. Modelo Incremental:

●​ Como funciona: Em vez de separar tudo rigidamente, as atividades de

especificação, desenvolvimento e validação são intercaladas. Desenvolve-se
uma versão inicial, recolhe-se feedback dos utilizadores, e o sistema evolui
através de várias versões iterativas.
●​ Vantagens: É mais fácil e barato adaptar o software a mudanças de
requisitos. O cliente obtém valor mais cedo, pois são-lhe entregues versões
preliminares funcionais.
●​ Problemas: Com adições sucessivas (incrementos), a estrutura do código
tende a degradar-se, tornando-se confuso se não for reestruturado
regularmente.

C. Integração e Configuração (Reutilização):

●​ Como funciona: Assenta na reutilização de código. Em vez de criar do zero,

a equipa descobre componentes de software ou sistemas prontos a usar e
avalia se cumprem os requisitos.
●​ Vantagens: Reduz drasticamente a quantidade de software a desenvolver,
diminui custos e garante uma entrega mais rápida.
●​ Problemas: Exige inevitáveis compromissos: como usas blocos pré-feitos, o
sistema final pode não satisfazer 100% das necessidades reais do cliente, e
perdes parte do controlo sobre atualizações futuras dos componentes que
não te pertencem.

5. Lidar com a Mudança e a Iteratividade ( 🔥 Pergunta de Exame)

A mudança em projetos de software de grande dimensão é inevitável devido a
alterações de mercado, legislação ou novas tecnologias. O teu professor foca muito
na razão pela qual o planeamento é iterativo: Como é praticamente impossível
produzir um conjunto estável de requisitos logo ao início, o processo deve abraçar a
mudança através de:

●​ Prototipagem: Desenvolvimento rápido de partes do sistema para verificar e

clarificar requisitos com o cliente antes de gastar recursos no
desenvolvimento final.
●​ Entrega Incremental: Permite congelar requisitos apenas para o pequeno
incremento atual, mantendo os restantes requisitos abertos a evolução.

6. A Necessidade do Planeamento Iterativo ( 🔥 Pergunta de Exame) O

planeamento de software tem de ser iterativo e continuamente revisto (em vez de ter
um plano fixo do início ao fim) devido aos seguintes fatores:
 ●​ Ambiente de Incerteza: As empresas operam com mudanças rápidas
(tecnologia, leis, concorrentes), sendo impossível produzir requisitos 100%
estáveis logo no início.
●​ Risco de Obsolescência: Se o plano fosse rígido e estático, a equipa
arriscava-se a passar meses a desenvolver software que já estaria obsoleto
no momento da entrega.
●​ Adaptação e Valor Real: Rever o plano em ciclos iterativos permite adaptar
às mudanças, incorporar feedback do cliente e ajustar prioridades, garantindo
que o software resolve os problemas atuais.

A resposta a esta incerteza faz-se através de Prototipagem e Entrega Incremental.

7. Melhoria Contínua e o CMM

Para finalizar, é imperativo avaliar como as empresas gerem a sua qualidade de
processos. O ciclo de melhoria assenta em três passos: Medir (recolher dados
quantitativos sobre tempo, esforço e defeitos), Analisar (identificar pontos fracos) e
Alterar (introduzir melhorias e avaliar).

O professor cobrou nos exames o Capability Maturity Model (CMM), que avalia o
nível de maturidade da engenharia da empresa de 1 a 5:

●​ Nível 1 (Initial)
●​ Nível 2 (Managed)
●​ Nível 3 (Defined)
●​ Nível 4 (Quantitatively managed)
●​ Nível 5 (Optimizing)

Atenção à pergunta de exame: A vantagem desta abordagem é a previsibilidade

(níveis mais altos garantem qualidade e prazos). A desvantagem é a enorme
burocracia e os custos avultados que o processo de certificação exige às empresas.

8. O Impacto da Dimensão na Gestão de Projetos ( 🔥

Pergunta de Exame) A
escolha do modelo de desenvolvimento depende fortemente de dois fatores
dimensionais:

●​ Tamanho da Empresa: Pequenas empresas têm uma estrutura simples que

facilita a comunicação informal, sendo ideais para métodos Ágeis (embora
possam ter menos recursos financeiros). Organizações grandes enfrentam
desafios complexos de comunicação global, exigindo burocracia,
documentação extensa e métodos mais formais de gestão para manter tudo
alinhado.
●​ Tamanho do Software: Aplicações pequenas são fáceis de planear e ideais
para prototipagem rápida. Sistemas grandes (ou críticos) envolvem milhões
de linhas de código e exigem abordagens orientadas a planos (Cascata), com
arquiteturas muito robustas e controlo rigoroso de qualidade.
 Fase 2: Desenvolvimento Ágil de Software (Capítulo 3)

O desenvolvimento ágil surgiu no final da década de 1990 como uma resposta direta
à insatisfação com os modelos orientados a planos (como o modelo em Cascata),
que eram demasiado longos e rígidos. Como as organizações operam num contexto
de mudança muito rápida, tornou-se praticamente impossível produzir um conjunto
estável de requisitos no início de um projeto. O grande objetivo do Ágil é reduzir
radicalmente o tempo de entrega de sistemas de software funcionais.

1. Princípios dos Métodos Ágeis ( 🔥 Foco de Exame)

O professor já perguntou num exame anterior quais eram os princípios dos métodos
ágeis e como contribuíam para a aceleração do desenvolvimento. No Ágil, a
especificação, conceção e implementação estão interligadas, a documentação é
reduzida ao mínimo e o foco passa a ser a codificação.

Os cinco princípios fundamentais que tens de dominar são:

●​ Envolvimento do Cliente (Customer involvement): O cliente deve estar

intimamente envolvido em todo o processo, sendo responsável por fornecer e
priorizar requisitos, bem como avaliar as iterações do sistema.
●​ Entrega Incremental (Incremental delivery): O software é desenvolvido em
pequenos incrementos, definindo o cliente o que deve ser incluído em cada
um.
●​ Pessoas e não Processos (People not process): As competências da
equipa devem ser valorizadas, permitindo que criem as suas próprias formas
de trabalhar, sem processos prescritivos e rígidos.
●​ Abraçar a Mudança (Embrace change): A equipa deve assumir e esperar
que os requisitos mudem, desenhando o sistema para acomodar essas
alterações facilmente.
●​ Manter a Simplicidade (Maintain simplicity): Foco ativo na eliminação da
complexidade, tanto no software desenvolvido como no próprio processo.

Porquê escolher o Ágil (Vantagens face à Cascata)? O Ágil é considerado melhor

em ambientes de incerteza e rápida mudança porque:

●​ Reduz o time-to-market: O cliente recebe software funcional muito mais

cedo.
●​ Reduz custos de erros: Ao fazer entregas em ciclos curtos, os erros são
detetados e corrigidos logo no início, evitando reescrever grandes blocos de
código no fim.
●​ Garante o valor real: Como o cliente dá feedback contínuo, a equipa
constrói exatamente o que o negócio precisa no momento, e não o que foi
planeado há um ano atrás e que já pode estar obsoleto.
2. Extreme Programming (XP)

O XP foi a primeira metodologia a introduzir técnicas "extremas" de

desenvolvimento ágil. Nos exames, deves focar-te nas seguintes práticas
operacionais de programação que o XP instituiu:

●​ Desenvolvimento orientado para testes (Test-first development): Exige

que os testes automatizados (usando frameworks como o JUnit) sejam
escritos antes do próprio código da funcionalidade. Isto garante que os
problemas são descobertos durante o próprio processo de desenvolvimento.
●​ Reestruturação (Refactoring): Como as mudanças tendem a degradar a
estrutura do software, os programadores devem reestruturar o código
continuamente. Isto mantém o código simples, legível e passível de
manutenção, prevenindo a deterioração estrutural.
●​ Programação em Pares (Pair programming): Dois programadores
trabalham no mesmo computador. Funciona como um processo informal de
revisão de código contínua. É mais barato que as inspeções formais de
código e potencia a partilha de conhecimento (propriedade coletiva) na
equipa.

3. A Framework SCRUM ( 🔥 Garantia de Exame)

Ao contrário do XP (que dita como programar), o SCRUM é uma framework focada
especificamente na gestão ágil de projetos e do desenvolvimento iterativo. Toda a
sua terminologia tem de estar na ponta da língua:

●​ Sprint: É o ciclo de desenvolvimento (iteração) de tamanho fixo, que dura

habitualmente entre 2 a 4 semanas. O resultado de cada Sprint deve ser um
incremento de software "potencialmente entregável" (shippable).
●​ Product Backlog: É a lista dinâmica de afazeres (to do) do projeto. Contém
funcionalidades, requisitos técnicos ou histórias de utilizadores a desenvolver.
●​ Product Owner: A pessoa responsável por identificar, priorizar os requisitos
do Product Backlog e garantir que o projeto atende às necessidades críticas
do negócio.
●​ ScrumMaster: Cuidado com as rasteiras! O ScrumMaster não é o gestor de
projeto clássico. A sua missão é ser o facilitador que garante que a
metodologia SCRUM é seguida, removendo as interferências externas e os
obstáculos (blockers) que possam atrasar os programadores.
●​ Reunião Diária (Scrum): Uma reunião curta diária (idealmente presencial),
onde a equipa revê o progresso e prioriza o trabalho a realizar nesse dia.

4. O Desafio do Ágil em Grande Escala ( 🔥 Pergunta Clássica do Professor)

Os métodos ágeis foram originalmente desenhados para equipas pequenas (até 7
pessoas) e co-localizadas (na mesma sala).
A grande questão de exame: Como escalar métodos ágeis para grandes
sistemas (sistemas de sistemas) e com equipas distribuídas geograficamente?

●​ A Rasteira: O formalismo e a informalidade colidem. Em projetos gigantes ou

com requisitos regulamentares apertados, a falta ou ausência de
documentação do Ágil clássico torna-se um problema grave. O modelo tem
de ser adaptado.
●​ A Solução (Escalabilidade e Formalismo): Os métodos ágeis foram
concebidos para pequenas equipas na mesma sala, onde a comunicação é
direta e informal. Quando expandimos o modelo para grande escala, com
equipas distribuídas pelo mundo e em fusos horários distintos, a
comunicação presencial perde viabilidade e a informalidade deixa de ser
suficiente. Por isso, passa a ser crucial e obrigatório reintroduzir métodos
formais e documentação rigorosa, nomeadamente a importância de se
realizar um projeto prévio e formal da arquitetura geral do sistema para
alinhar todas as equipas. Para dar suporte a esta estrutura, adotam-se
dinâmicas como o "Scrum de Scrums" (reuniões diárias entre representantes
de cada equipa) e frameworks de disciplina (como o IBM Agile Scaling
Model). Só com esta governança adequada e documentação central é
possível garantir que as várias peças de software desenvolvidas por equipas
diferentes se integram e compatibilizam corretamente no final do processo.

5. Como tornar o Software Resistente à Mudança (Pergunta de Exame) Para

além da Prototipagem e Entrega Incremental, existem três atividades chave:

●​ Refactoring: Limpeza e simplificação da estrutura interna do código sem

alterar o comportamento externo, facilitando futuras alterações.
●​ Testes de Regressão Automatizados: Garantem que novas modificações
não introduzem defeitos no que já funcionava.
●​ Desenvolvimento Baseado em Componentes: Arquitetura modular e
desacoplada, que isola o impacto de uma alteração a apenas um módulo
específico.

Fase 3: Engenharia de Requisitos e Modelação do Sistema

(Capítulos 4 e 5)
Antes de escrever qualquer linha de código, é preciso compreender e definir os
serviços que o sistema deve fornecer e as suas restrições operacionais. A este
processo chamamos Engenharia de Requisitos. É uma fase tão crítica que a
correção tardia de erros nos requisitos pode custar até 100 vezes mais do que se
fossem corrigidos nas fases de projeto ou implementação.

1. Níveis de Requisitos
Os requisitos devem ser redigidos para diferentes públicos:
 ●​ Requisitos de Utilizador: São descrições de alto nível, muitas vezes
escritas em linguagem natural e com esquemas simples, compreensíveis
para clientes sem formação técnica.
●​ Requisitos de Sistema: São documentos muito mais estruturados e
detalhados sobre as funções, que servem de ponto de partida para os
programadores e podem até fazer parte do contrato legal.

2. Funcionais vs. Não-Funcionais ( 🔥 Foco de Exame)

Tens de saber distinguir estas duas categorias de olhos fechados:

●​ Requisitos Funcionais: É a declaração dos serviços que o sistema tem de

fornecer, ou seja, o que o sistema faz. (Ex: O sistema deve gerar relatórios
mensais).
●​ Requisitos Não-Funcionais: São restrições relativas aos serviços, ou seja,
como o sistema se comporta. Exemplos incluem desempenho, segurança,
fiabilidade, utilização de memória e usabilidade.
○​ Nota Crítica: Geralmente, os requisitos não-funcionais são mais
críticos do que os funcionais. Aplicam-se ao sistema como um todo.
Se um sistema não cumprir um requisito de fiabilidade ou de
performance (ex: ser demasiado lento), pode inviabilizar
completamente a sua utilização, mesmo que tenha todas as
funcionalidades pedidas.

3. Conflito de Requisitos Não-Funcionais ( 🔥 Pergunta Clássica)

Os requisitos não-funcionais são frequentemente contraditórios entre si. O teu
professor colocou esta questão no exame de recurso de 2022/2023.

●​ A justificação: A arquitetura de software é um jogo de compensações

(trade-offs), sendo impossível maximizar todos os atributos simultaneamente.
A otimização de um pode degradar o outro.
●​ Exemplo (Segurança vs. Performance): Implementar múltiplas camadas de
criptografia torna o sistema muito seguro, mas exige processamento adicional
que aumenta a latência e diminui a performance.
●​ Exemplo (Segurança vs. Usabilidade): Exigir que o utilizador troque a
password regularmente e use autenticação de dois fatores aumenta a
segurança, mas prejudica a rapidez de acesso e a experiência do utilizador.

4. Rastreabilidade (🔥 Pergunta do Professor)

Na lista de perguntas importantes do teu professor, ele questiona por que razão se
deve manter o registo das relações entre requisitos (rastreabilidade).

●​ A resposta: As políticas de rastreabilidade definem as relações entre cada

requisito e o projeto. Manter este registo é essencial no processo de gestão
de alterações. Quando surge uma proposta de mudança, a rastreabilidade
permite avaliar rapidamente o impacto e calcular o custo dessa alteração em
 todo o sistema, prevenindo que a alteração de um requisito funcional quebre
inadvertidamente um requisito não-funcional (ou vice-versa).

5. Modelação de Sistemas com UML (Capítulo 5)

Depois de recolher os requisitos, passamos à modelação. A modelação é o
processo de desenvolvimento de modelos abstratos (representações gráficas) do
sistema, geralmente utilizando notações da Unified Modeling Language (UML).
Estes modelos ajudam o analista a compreender a funcionalidade e facilitam a
discussão com os clientes.

Existem três grandes perspetivas de modelação:

●​ Perspetiva de Interação: Modela as interações entre o sistema e o exterior,

ou entre os seus componentes.
●​ Perspetiva Estrutural: Modela a organização e a estrutura de dados.
●​ Perspetiva Comportamental: Modela o comportamento dinâmico e a
resposta a eventos.

6. Os 5 Diagramas UML Essenciais

Tens de saber associar cada diagrama ao seu propósito prático:

Perspetiva de Interação (O exterior):

1.​ Diagramas de Casos de Uso (Use Cases): Mostram as interações entre o

sistema e o seu ambiente (atores/utilizadores). Ajudam a modelar cenários
práticos de utilização.
2.​ Diagramas de Classes: É o modelo estrutural base. Identificam as classes
(entidades, coisas, papéis), os seus atributos, os seus métodos (operações) e
as associações entre elas.

Perspetiva Estrutural (A espinha dorsal):

3.​ Diagramas de Sequência: Mostram a interação num fluxo de eventos de um
objeto para outro em função do tempo. São muito úteis para modelar o
comportamento num caso de uso específico.

Perspetiva Comportamental (O dinamismo):

4.​ Diagramas de Atividades: Mostram as atividades e decisões passo-a-passo
envolvidas num processo ou no processamento de dados.
5.​ Diagramas de Estados: Mostram a perspetiva comportamental. Indicam
como o sistema (ou uma classe específica) reage a eventos internos e
externos (estímulos) e como transita de um estado para o outro ao longo da
sua execução.

⚠️ Nota de Exame (Limitações do UML): Os casos de uso são subjetivos

(dependem do autor) e são inadequados para requisitos não-funcionais e
insuficientes para sistemas críticos.
Fase 4: Projeto de Arquitetura e Implementação (Capítulos 6 e 7)
O projeto de arquitetura é o primeiro passo do processo de conceção de software e
serve como a ligação crítica entre a engenharia de requisitos e o projeto do sistema.
O output desta fase é um modelo de representação de alto nível da estrutura do
sistema.

1. A Arquitetura e a "Rasteira" Ágil (🔥 Foco de Exame)

Existe um conflito clássico entre a conceção da arquitetura e as metodologias ágeis:

●​ O Problema: Os métodos ágeis defendem que o software deve ser

construído aos poucos (incrementalmente). No entanto, o desenvolvimento
incremental de arquiteturas não costuma ser bem sucedido.
●​ A Justificação: Mudar a fundação (arquitetura) de um sistema a meio do
projeto é incrivelmente dispendioso, pois pode obrigar a modificar a maioria
dos componentes já desenvolvidos.
●​ A Solução: Mesmo num processo ágil, uma fase inicial deve centrar-se na
conceção de uma arquitetura global do sistema para servir de base sólida.

2. Trade-offs Arquiteturais e Requisitos Não-Funcionais

Lembras-te do conflito entre requisitos não-funcionais que falámos na Fase 3? A
arquitetura dita como resolvemos isso. A forma como estruturas o sistema afeta
diretamente as suas características:

●​ Performance: Melhora se utilizares componentes de grande dimensão e

minimizares as comunicações entre eles.
●​ Manutibilidade: Melhora se utilizares componentes pequenos, específicos e
facilmente substituíveis.
●​ Conflito: Se o cliente pedir alta performance e alta manutibilidade ao mesmo
tempo, terás de encontrar uma relação de compromisso (usar diferentes
modelos arquiteturais em partes distintas do sistema).
●​ Segurança (Security):
○ Segurança (Security): Proteção de dados confidenciais e controlo
de acessos.
○ Segurança Física/Operacional (Safety): Garantia de que falhas de
software não causam danos físicos ou prejuízos catastróficos a humanos ou
ao ecossistema envolvente.
Exige uma arquitetura em camadas, colocando os ativos mais críticos nas camadas
mais interiores.
●​ Disponibilidade: Obriga à inclusão de componentes redundantes e
mecanismos de tolerância a falhas

3. Padrões de Arquitetura (Modelos Prontos a Usar)

Não é preciso inventar a roda. Os arquitetos de software usam padrões testados
para resolver problemas comuns. Tens de conhecer os principais:
 ●​ MVC (Model-View-Controller): Separa a apresentação dos dados da
interação com o utilizador. É muito usado em aplicações web, permitindo que
a mesma informação seja apresentada de várias formas sem alterar os dados
base.
●​ Arquitetura em Camadas (Layered): Organiza o sistema em níveis, onde
cada camada fornece serviços à camada superior. Permite substituir uma
camada inteira desde que a interface se mantenha, mas pode prejudicar a
performance devido aos múltiplos níveis de interpretação.
●​ Repositório: Todos os dados do sistema são geridos numa base de dados
central, acessível a todos os componentes. Os componentes não interagem
diretamente entre si, apenas através do repositório (ex: IDEs onde várias
ferramentas acedem ao mesmo código fonte).
●​ Cliente-Servidor: O sistema é organizado em serviços fornecidos por
servidores separados, e clientes que os acedem (normalmente via
rede/internet).
●​ Pipes and Filters (Tubos e Filtros): Foco em transformações. Os dados
fluem de um componente para outro, sendo processados em fases
sucessivas (muito usado em compiladores de linguagens e processamento
de dados).

4. Questões de Implementação: Reutilização (Capítulo 7)

Hoje em dia, muito poucos sistemas são desenvolvidos do zero. A reutilização é a
norma e pode acontecer a vários níveis (abstração, objetos, componentes ou
sistemas completos - COTS).

●​ Vantagens da Reutilização: Já vimos noutro exame que acelera o

desenvolvimento, reduz custos e garante maior fiabilidade porque o código já
foi previamente testado.
●​ Custos Ocultos: Contudo, tens de considerar o tempo gasto a procurar,
avaliar, configurar e, acima de tudo, o custo de integração e compatibilização
desses elementos com o teu código novo.
●​ A Importância do Tempo de Vida Previsto: É um fator crítico no
planeamento da reutilização (tema de exame!). Se um software tiver um ciclo
de vida muito curto, o tempo e o custo inicial de procurar e adaptar
componentes reutilizáveis pode não compensar. Porém, se o sistema for
desenhado para durar muitos anos, a reutilização compensa largamente, mas
obriga a escolher componentes que tenham garantias de suporte e
atualização a longo prazo.

5. Open-Source e Licenciamentos ( 🔥 Atenção Redobrada)

Ao reutilizar código da Internet, podes recorrer a componentes open-source (código
aberto). A grande rasteira de exame é achar que código aberto significa "fazes o
que quiseres". Legalmente, o código pertence a quem o criou. Tens de dominar as
licenças:
 ●​ GPL (GNU General Public License): É uma licença recíproca. Se utilizares
um componente GPL no teu sistema, ficas obrigado a partilhar e publicar o
código fonte de todo o teu sistema criado.
●​ LGPL (Lesser GPL): Menos restritiva, não te obriga a publicar o código fonte
dos componentes que criares, desde que não alteres o modelo de licença do
componente original.
●​ BSD (Berkeley Standard Distribution): É uma licença não-recíproca.
Permite que uses o código para criares novos componentes que podem ser
totalmente proprietários (fechados) e até vendidos.

Fase 5: Garantia da Qualidade, Testes e Evolução (Capítulos 8 e 9)

Construir o software é apenas metade do caminho. A outra metade consiste em
garantir que o sistema funciona como pretendido, detetar defeitos antes que
cheguem ao cliente e manter o produto ao longo de todo o seu ciclo de vida.

Atributos de Qualidade do Produto (Norma ISO/IEC 25010)

A norma divide a qualidade do produto de software em 8 atributos fundamentais

principais:
1. Adequação Funcional: O grau em que as funções do software
satisfazem as necessidades declaradas e implícitas do utilizador.
2. Eficiência de Desempenho: Relação entre o desempenho do software e
a quantidade de recursos (memória, CPU, rede) utilizados sob
determinadas condições.
3. Compatibilidade: Capacidade de partilhar informação ou executar em
paralelo com outros sistemas no mesmo ambiente.
4. Usabilidade: Facilidade com que o utilizador aprende a interagir e operar
o sistema com eficácia e satisfação.
5. Fiabilidade: Capacidade do sistema desempenhar as suas funções sob
condições normais durante um determinado período.
6. Segurança: Grau em que o software protege dados e recursos contra
acessos não autorizados.
7. Manutibilidade: Eficiência com que o software pode ser modificado,
corrigido ou melhorado pelos programadores.
8. Portabilidade: Facilidade com que o software pode ser transferido de um
ambiente de hardware, software ou rede para outro.

Atividades para Alcançar a Qualidade

Para atingir os níveis pretendidos de qualidade, as organizações dividem os seus

esforços em quatro vertentes operacionais:
● Métodos de Engenharia de Software: Práticas rigorosas de
desenvolvimento adotadas pelos programadores (revisão de código, TDD,
modelação correta).
 ● Técnicas de Gestão de Projetos: Planeamento, controlo de prazos,
alocação correta de recursos e gestão de riscos pela liderança.
● Controlo de Qualidade (Quality Control - QC): Atividades focadas em
detetar defeitos no produto final através de testes operacionais (testes
unitários, testes de integração, testes funcionais).
Garantia da Qualidade (Software Quality Assurance - SQA): Atividades focadas
nos processos de desenvolvimento, garantindo que as metodologias e padrões
corretos estão a ser seguidos por todos para prevenir a ocorrência de defeitos.

1. Diferença entre Teste, Inspeção e Revisão ( 🔥 Foco do Professor)

●​ Teste (Dinâmico): Exige a execução do programa com dados (reais ou
fictícios). O objetivo é demonstrar que cumpre os requisitos e revelar
defeitos/falhas de execução.
●​ Inspeção (Estático e Formal): Análise manual muito minuciosa. Uma equipa
(pares) analisa o código-fonte linha a linha ou os modelos UML à procura de
anomalias, violações de standards de programação ou erros lógicos, sem
executar o código.
●​ Revisão (Estático e Abrangente): Pode ser mais informal ou técnica. Serve
para avaliar produtos de trabalho de forma mais global, como analisar se a
especificação de requisitos está consistente e se a qualidade geral do projeto
está a ser garantida antes de avançar para a fase seguinte.

2. Os Tipos e Estágios de Teste

Os testes dividem-se em diferentes estágios e responsabilidades:

●​ Testes de Desenvolvimento: Realizados pela própria equipa de

programação. Incluem os testes de unidades (foco em funções/métodos
isolados) e testes de integração de componentes.
●​ Testes de Lançamento (Release): Realizados por uma equipa separada
para demonstrar que o sistema cumpre os requisitos (normalmente black-box
testing). Incluem Testes de Stress, que verificam o comportamento do
sistema perante sobrecarga extrema até ao ponto de falha.
●​ Testes de Utilizador/Cliente: Testes feitos pelos próprios utilizadores num
ambiente real (Alfa, Beta e Aceitação) para validar a adequação do sistema.

3. TDD e Testes de Regressão ( 🔥 Pergunta de Exame)

Dois conceitos técnicos altamente cobrados:

●​ Desenvolvimento Orientado para os Testes (TDD): Uma prática ágil onde

se escrevem os testes automáticos antes de escrever o código da
funcionalidade.
●​ Testes de Regressão: Quando se corrige um bug ou se adiciona uma nova
funcionalidade, é necessário testar novamente o sistema para garantir que a
alteração não introduziu novos defeitos nem "partiu" o que já funcionava.
 ○​ Ligação ao Exame: Num exame de recurso, foi pedido para explicar
como automatizar isto. Resposta: A utilização de sistemas de testes
automatizados estruturados (como o JUnit) simplifica os testes de
regressão porque permite uma execução instantânea de centenas de
testes, eliminando o erro humano e garantindo consistência técnica em
cada nova versão do código.

4. O Elevado Custo da Evolução e dos Defeitos ( 🔥

Foco do Professor)
O professor questiona: "Porque é que a evolução de um software pode ser
considerada inerentemente dispendiosa?".

●​ Amplificação e Propagação: Um erro inserido no início do projeto (ex: na

definição de requisitos) que não seja detetado, propaga-se e amplifica-se nas
fases seguintes (design e código).
●​ O Custo Exponencial: O custo de encontrar e corrigir um defeito aumenta
exponencialmente com o decurso do processo. Corrigir uma falha externa
(após a entrega) envolve não só o esforço de programação, mas também
custos reputacionais, de suporte e de reestruturação do sistema.
●​ Degradação Estrutural: Alterações regulares feitas ao longo do tempo
(evolução) degradam a estrutura do software, gerando um código confuso, o
que torna cada alteração subsequente progressivamente mais difícil e cara.

5. Os Três Tipos de Manutenção ( 🔥

Garantia de Exame)
É impossível ir a este exame sem dominar os três tipos de intervenção num
software pós-lançamento:

1.​ Manutenção Corretiva: Correção de erros ou falhas (bugs) identificados

após o software estar a funcionar.
2.​ Manutenção Evolutiva: Modificações feitas para adicionar novas
funcionalidades e responder a novas necessidades do cliente.
3.​ Manutenção Adaptativa: Alterações exigidas para que o software continue a
funcionar perante mudanças no ambiente externo (ex: novos sistemas
operativos, novas regras legais).
○​ A Dificuldade: Muitas vezes é difícil distingui-las porque uma única
intervenção pode englobar mais do que uma categoria (ex: uma
adaptação de segurança pode parecer uma nova funcionalidade aos
olhos do utilizador).

O Risco da Obsolescência Tecnológica: Um avanço na tecnologia base (novo

hardware, lançamento de um novo sistema operativo ou novos protocolos de
segurança) exige aplicação imediata de manutenção adaptativa. Se o software
produzido não for atualizado para estes novos padrões, deixa de conseguir
comunicar com os novos ambientes, torna-se inseguro ou incompatível e,
consequentemente, passa a ser completamente inútil e inviável para o utilizador, por
muito bem que as suas funções originais tivessem sido programadas.
Porque é que o planeamento deve ser iterativo e revisto continuamente? As
organizações operam num ambiente de rápida mudança (novas tecnologias,
concorrentes, leis). Se o plano fosse fixo do início ao fim (Cascata), o software
entregue estaria obsoleto. O planeamento iterativo permite que o plano seja
continuamente revisto em pequenos ciclos (como os Sprints), reavaliando
prioridades para garantir que o que a equipa está a desenvolver acrescenta sempre
o máximo valor real ao negócio no momento presente.

6. Maturidade de Processos: O CMM e o Nível 5 ( 🔥 Pergunta Clássica)

CMM (Capability Maturity Model), desenvolvido pelo SEI, é um modelo de
avaliação da maturidade dos processos de desenvolvimento de software de uma
organização. Funciona como uma escala de qualidade (de 1 a 5) que ajuda uma
empresa a perceber o seu nível atual e dá-lhe um roteiro para evoluir de um
ambiente caótico (ad-hoc) para um ambiente perfeitamente controlado. A
abordagem consagrada no Nível 5 (Optimizing) foca-se na melhoria contínua dos
processos com base em feedback quantitativo e estatístico.

●​ Vantagens: Previsibilidade total (prazos, custos e qualidade exatos) e uma

cultura de prevenção de defeitos onde a empresa aprende e melhora a cada
projeto.
●​ Desvantagens: Excesso de burocracia documental (que retira agilidade) e o
investimento massivo de tempo e dinheiro necessário para a empresa
alcançar e manter este nível, sendo inviável para pequenas empresas.