ENGENHARIA DE SOFTWARE

Ficha de Avaliação 1
Curso: Licenciatura em Engenharia Informática; 3.º Ano – 1.º Semestre

Parte I
1. Coloque V de Verdadeiro ou F de Falso à frente de cada afirmação. (1 valor cada,
total de 10 valores)

a) Um dos objetivos da Engenharia de Software é o de avaliar e garantir a qualidade de um

sistema de software. V

b) As atividades associadas à Engenharia de Software podem ser agrupadas em três

grandes fases: conceção, implementação e manutenção. V

c) É mais barato (custo menor) manter o mesmo software do que desenvolvê-lo de raiz. F

d) A validação é uma verificação se o software desenvolvido está de acordo com o

pretendido pelo cliente, ou seja, se obedece aos requisitos V

e) Os requisitos podem ser encarados como uma descrição ou especificação do problema na

ótica da equipa de desenvolvimento. F

f) A análise pode ser encarada com uma descrição do problema na ótica dos clientes. F

g) As metodologias ágeis não têm desvantagens em relação às metodologias tradicionais. F

h) Os requisitos de desenvolvimento precisam ser obedecidos para suprir as necessidades

do cliente. V

i) SRS é um documento formal usado para comunicar os requisitos aos clientes e a todos os

intervenientes no processo de desenvolvimento. V

j) O plano do projeto tem de identificar o tempo, custo e os recursos necessários para

entregar o âmbito e qualidade definidos para o projeto. V

Rui Pascoal 1
 ENGENHARIA DE SOFTWARE

Parte II

2. Explique o que são requisitos não funcionais explique como podem estar
relacionados com os requisitos funcionais. De seguida descreva pelos menos 3
exemplos. (2 valores)
Os requisitos não funcionais referem-se às características do sistema que não estão
diretamente ligadas a uma funcionalidade específica, mas sim à qualidade global do sistema.
Eles descrevem as propriedades que afetam a forma como o sistema opera, em vez de suas
funcionalidades específicas. Esses requisitos são muitas vezes críticos para o sucesso do
sistema, pois influenciam a usabilidade, desempenho, segurança, entre outros aspectos.
Os requisitos não funcionais estão intrinsecamente ligados aos requisitos funcionais, pois
ambos são essenciais para o desenvolvimento de um sistema eficaz. Enquanto os requisitos
funcionais definem o que o sistema deve fazer, os requisitos não funcionais definem como o
sistema deve realizar essas funções.

Exemplos de Requisitos Não Funcionais:

Performance:
Exemplo: O sistema deve ser capaz de processar 1000 transações por segundo para atender
à demanda esperada.

Manutenção:
Exemplo: A interface do usuário deve ser intuitiva e fácil de usar, permitindo que novos
usuários aprendam a utilizar o sistema em menos de 30 minutos.

Segurança:
Exemplo: O sistema deve implementar medidas de segurança, como criptografia de dados e
autenticação de dois fatores, para proteger as informações sensíveis dos usuários.

Rui Pascoal 2
 ENGENHARIA DE SOFTWARE

3. Explique a diferença entre âmbito do projeto e âmbito do produto e como está

relacionado com a etapa dos requisitos. (2 valores)
O âmbito do Projeto refere-se ao trabalho que precisa ser realizado para entregar o produto.
Isso inclui todas as atividades, processos, e tarefas necessárias para completar o projeto
com sucesso. O âmbito do projeto abrange desde a concepção até a entrega final e pode
incluir aspectos como gerenciamento de projetos, recursos humanos, comunicação, riscos,
cronograma, etc. Enquanto o âmbito do Produto, diz respeito às características e
funcionalidades que o produto final deve ter. É sobre o que o produto em si deve realizar,
suas especificações e características. O âmbito do produto é muitas vezes derivado dos
requisitos do cliente e stakeholders e é a base para o desenvolvimento do produto.

A etapa dos requisitos está diretamente relacionada à definição tanto do âmbito do projeto
quanto do âmbito do produto. Durante a fase de levantamento de requisitos, a equipe
identifica e documenta o que é necessário para o produto e também o que é necessário para
gerenciar e entregar esse produto como parte do projeto.
Durante a análise de requisitos, a equipe identifica as funcionalidades e características
essenciais que o produto deve ter para atender às expectativas dos clientes e stakeholders.
Esses requisitos funcionais e não funcionais contribuem para definir o âmbito do produto.
Além dos requisitos relacionados diretamente ao produto, a equipe de projeto também
identifica requisitos relacionados à gestão do projeto, como cronogramas, orçamentos,
recursos humanos e riscos. Esses requisitos contribuem para definir o âmbito do projeto.

Rui Pascoal 3
 ENGENHARIA DE SOFTWARE

4. Descreva as características das metodologias ágeis e o que têm em comum em

comparação com as metodologias tradicionais estilo waterfall, dê um exemplo (2
valores)
1. Iterativo e Incremental:
As metodologias ágeis dividem o desenvolvimento em iterações pequenas e incrementais.
Cada iteração resulta em uma versão funcional do software.

2. Colaboração e Comunicação:
Foco na comunicação e colaboração constante entre membros da equipe de
desenvolvimento, clientes e stakeholders.

3. Flexibilidade e Adaptabilidade:
Capacidade de se adaptar a mudanças nos requisitos do cliente, mesmo durante as fases
tardias do desenvolvimento.

4. Entrega Contínua de Valor ao Cliente:

Prioridade na entrega de funcionalidades de alto valor para o cliente em curtos períodos de
tempo.

5. Envolvimento do Cliente:
Os clientes são considerados membros da equipe e são envolvidos de perto durante o
desenvolvimento para garantir que suas expectativas sejam atendidas.
Metodologias Tradicionais (Waterfall):

1. Sequencial e Linear:
As metodologias tradicionais seguem uma abordagem sequencial e linear, onde cada fase
deve ser concluída antes de passar para a próxima.

2. Planejamento Detalhado:
O planejamento é extensivo e detalhado no início do projeto, com uma ênfase na definição
clara de requisitos.

Rui Pascoal 4
 ENGENHARIA DE SOFTWARE

3. Mudanças Difíceis:
Mudanças nos requisitos são difíceis de serem incorporadas após o início do
desenvolvimento.

4. Entrega Final ao Fim do Projeto:

O produto é entregue ao final do ciclo de vida do projeto, após todas as fases terem sido
concluídas.

5. Pouco Envolvimento do Cliente durante o Desenvolvimento:

O cliente geralmente é envolvido no início e no final do projeto, com pouca participação
durante o desenvolvimento.

O que Têm em Comum:

Ambas as abordagens buscam alcançar os objetivos finais do projeto, que incluem entregar
um produto de qualidade no prazo e dentro do orçamento. No entanto, o que têm em comum
é o foco na entrega de valor ao cliente, embora o façam de maneiras distintas.

Exemplos:
Metodologia Ágil - Scrum:
O Scrum é uma metodologia ágil que se baseia em iterações curtas chamadas "sprints" para
entregar incrementos de software. As equipes de desenvolvimento colaboram de perto com
os clientes para priorizar as funcionalidades mais importantes e garantir que as necessidades
do cliente sejam atendidas de maneira flexível.

Metodologia Tradicional - Waterfall:

O modelo Waterfall segue uma abordagem linear, onde as fases do projeto (requisitos,
design, implementação, testes, manutenção) são executadas sequencialmente. Por exemplo,
se um projeto de construção de software segue o modelo Waterfall, a equipe só começará a
codificar após a conclusão total da fase de design, e assim por diante.

Rui Pascoal 5
 ENGENHARIA DE SOFTWARE

5. Explique que tipos de protótipos existem e para que servem. (2 valores)

Protótipo de Papel (Paper Prototype):

Consiste em esboços manuais ou impressos das interfaces do usuário, permitindo uma

representação visual rápida e econômica das ideias. É útil para explorar conceitos de design
antes de investir tempo e recursos em desenvolvimento.

Protótipo de Alcance Limitado (Low-Fidelity Prototype):

Utiliza ferramentas simples, como wireframes ou mockups digitais, para representar
visualmente o layout e a estrutura do sistema. Esses protótipos são valiosos para testar a
usabilidade e a navegação.

Protótipo de Alta Fidelidade (High-Fidelity Prototype):

Envolvem detalhes mais refinados, utilizando ferramentas avançadas para criar
representações mais realistas e interativas do produto final. São usados para avaliar a
aparência visual e o comportamento do sistema.

Protótipo Funcional (Functional Prototype):

Inclui funcionalidades interativas e operacionais do sistema. Esses protótipos vão além da
representação visual, permitindo que os usuários experimentem a funcionalidade básica do
produto.

Protótipo Descartável:
Desenvolvido rapidamente para fornecer uma visão geral do design e da funcionalidade, mas
não é destinado a ser incorporado ao produto final. É descartado após cumprir seu propósito.
Protótipo Evolutivo:

É construído, testado e aprimorado ao longo do tempo à medida que novas iterações são
desenvolvidas. Esse tipo de protótipo é ajustado com base no feedback contínuo e nas
mudanças nos requisitos.

Rui Pascoal 6
 ENGENHARIA DE SOFTWARE

6. Descreva e explique as sub-etapas da etapa dos requisitos e qual o seu objetivo. (2

valores)

A etapa dos requisitos é uma parte fundamental do ciclo de vida do desenvolvimento de

software, sendo responsável por entender, documentar e gerenciar as necessidades e
expectativas dos stakeholders para o sistema a ser desenvolvido. Esta etapa é crucial para o
sucesso do projeto, pois fornece a base para todo o trabalho subsequente de design,
implementação e teste. As sub-etapas típicas da etapa dos requisitos incluem:

Levantamento de requisitos – coletar informações do sistema por meio de técnicas

como entrevistas e observação.

Análise e negociação dos Requisitos – Organizar q refinar requisitos, identificando

inconsistências e priorizando-os.

Documentação dos requisitos – Documentar requisitos de forma clara, usando

linguagem compreensível a todas as partes envolvidas.

Verificação dos requisitos – Garantir alinhamento com as necessidades do negócio.

Validação dos requisitos – Garantir que os requisitos sejam completos, consistentes

e atendam às expectativas dos stakeholders.

Objetivos Gerais da Etapa dos Requisitos:

Compreender as Necessidades dos Stakeholders: Garantir uma compreensão abrangente

das necessidades e expectativas dos usuários, clientes e outros stakeholders.

Minimizar Ambiguidades e Conflitos: Identificar e resolver ambiguidades, conflitos e

inconsistências nos requisitos para evitar problemas durante o desenvolvimento.

Fornecer uma Base Sólida para o Desenvolvimento: Criar uma documentação clara e precisa
que sirva como guia para as fases subsequentes do desenvolvimento, garantindo a entrega
de um sistema que atenda aos requisitos estabelecidos.

Rui Pascoal 7