Modelos, Métodos e Técnicas de Engenharia de Software

UNA – Cristiano Machado (Centerminas)

Kaique Bolonezi - 323133467

Questionário

1) Qual a importância de um Processo de Desenvolvimento de Software e quais são as

fases genéricas? Cite quatro processos prescritivos.
R: É fundamental para o sucesso de qualquer projeto de software. Ele fornece um
roteiro estruturado e organizado para as equipes seguirem, garantindo que o
software seja desenvolvido de forma eficiente, eficaz e com alta qualidade. Veja
abaixo as fases genéricas:

Planejamento: Nesta fase, são definidas as metas do projeto, os requisitos do software e o

plano de desenvolvimento.
2. Análise: Nesta fase, são coletados e analisados os requisitos do software para entender
as necessidades dos usuários.
3. Design: Nesta fase, é projetada a arquitetura do software e as interfaces de usuário.
4. Implementação: Nesta fase, o software é codificado e implementado de acordo com o
design.
5. Testes: Nesta fase, o software é testado para garantir que atende aos requisitos e esteja
livre de erros.
6. Manutenção: Nesta fase, o software é corrigido e atualizado para garantir que continue
funcionando corretamente e atendendo às necessidades dos usuários.

Processos Prescritivos:

Cascata: Este é o processo mais tradicional, onde cada fase é concluída antes de passar
para a próxima.

Espiral: Este processo combina elementos do modelo cascata com iteração, permitindo que
o software seja desenvolvido em incrementos.

Evolutivo: Este processo foca no desenvolvimento rápido de um protótipo funcional, que é

posteriormente refinado e aprimorado.

Unificado: Este processo combina as melhores práticas de vários modelos de processo,

como cascata, espiral e evolutivo.

2) Por que os Processos Prescritivos recebem essa denominação?

R: Os Processos Prescritivos recebem essa denominação porque, assim como uma receita
médica, eles "prescrevem" um conjunto de etapas e atividades a serem seguidas no
desenvolvimento de software. São algumas etapas: Definição de um roteiro, Padronização
de controle, Minimização de riscos e Facilidade de replicação.

3) Qual foi o motivador para o surgimento da Engenharia de Software?

R: O principal motivador para o surgimento da Engenharia de Software foi a crise do
software que ocorreu na década de 1960. Naquela época, o desenvolvimento de software
era um processo caótico e desorganizado, sem métodos ou ferramentas formais. Isso levou
a diversos problemas, como: Problemas de qualidade, crescimento de demanda por
software, custo e cronograma de desenvolvimento e custos exuberantes.

Para solucionar esses problemas, a comunidade científica e a indústria de software se

uniram para criar uma nova disciplina que aplicasse os princípios da engenharia ao
desenvolvimento de software. Essa disciplina foi chamada de Engenharia de Software.
A Engenharia de Software introduziu uma série de métodos e ferramentas formais para o
desenvolvimento de software, como: Processos e desenvolvimentos estruturados,
linguagens de programação de alto nível, ferramentas de análise e design e técnicas de
teste.

4) Trace um paralelo da Engenharia de Software como Engenharia Civil e como Arte.

R: Engenharia Civil diferenças:
Materiais e Ferramentas: A Engenharia Civil utiliza materiais físicos como concreto, aço e
madeira, enquanto a Engenharia de Software utiliza linguagens de programação,
frameworks e ferramentas digitais.
Tangibilidade: Edifícios são produtos tangíveis que podem ser vistos e tocados, enquanto
softwares são produtos intangíveis que só podem ser interagidos por meio de interfaces
digitais.
Impacto Ambiental: A Engenharia Civil pode ter um impacto ambiental significativo,
enquanto a Engenharia de Software tem um impacto ambiental menor.

Arte diferenças:
Função e Propósito: A Engenharia de Software tem um foco mais funcional, enquanto a
Arte tem um foco mais expressivo.
Objetividade e Subjetividade: A Engenharia de Software busca soluções objetivas para
problemas específicos, enquanto a Arte é mais subjetiva e aberta à interpretação.
Processo de Criação: O processo de criação de software é geralmente mais linear e
estruturado, enquanto o processo de criação artística é mais intuitivo e fluido.

5) Cite e comente seis princípios de comunicação das práticas de Engenharia de

Software.
R: Clareza e Precisão: A comunicação deve ser clara, concisa e precisa, evitando jargões
técnicos e ambiguidades. Utilize uma linguagem simples e direta, adequada ao público-alvo.

Transparência e Abertura: Mantenha todos os envolvidos informados sobre o progresso do

projeto, compartilhando informações relevantes de maneira transparente e aberta. Isso
ajuda a evitar mal-entendidos e construir confiança.
Comunicação Bidirecional: A comunicação deve ser um processo bidirecional, com todos
os envolvidos tendo a oportunidade de expressar suas ideias e opiniões. Incentive o
feedback e a participação ativa de todos.

Documentação Clara e Completa: Documente todas as decisões importantes, requisitos,

especificações e planos de projeto de forma clara e completa. Isso garante que todos os
envolvidos estejam na mesma página e facilita o acesso às informações.

Canal de Comunicação Adequado: Utilize o canal de comunicação mais adequado para

cada situação, como e-mail, reuniões, ferramentas de comunicação online, etc.

Comunicação Frequente e Regular: Mantenha uma comunicação frequente e regular com

todos os envolvidos no projeto, fornecendo atualizações sobre o progresso, novos
desenvolvimentos e desafios.

6) Diferencie o teste da Caixa Branca do teste da Caixa Preta.

R: Teste da Caixa Branca:

Foco: Estrutura interna do software, código-fonte, lógica de implementação, algoritmos e

estruturas de dados.
Objetivo: Encontrar erros e falhas no código, como lógica incorreta, condições de limite não
testadas, código ineficiente ou redundante.
Técnicas:
Análise de código estático: Examina o código-fonte sem executá-lo, buscando por erros
de sintaxe, lógica incorreta e código morto.
Teste de Caminho: Executa o código-fonte, rastreando os caminhos percorridos e
garantindo que todos os caminhos sejam testados.
Teste de cobertura de código: Mede a porcentagem do código-fonte que foi executada
pelos testes.

Teste da Caixa Preta:

Foco: Funcionalidade externa do software, interface do usuário, entradas e saídas,

comportamento geral.
Objetivo: Encontrar erros e falhas na funcionalidade do software, como comportamento
inesperado, falhas de interface, inconsistências nos resultados e violações de requisitos.
Técnicas:
Teste de Equivalência de Classes: Divide as entradas em classes de equivalência e testa
um representante de cada classe.
Análise de Valor Limite: Testa os valores limites das entradas e saídas.
Teste de Partição de Equivalência: Divide as entradas em partições de equivalência e
testa cada partição.
Tabela de Decisão: Cria uma tabela que mapeia as entradas e condições do software com
as saídas esperadas.
7) Explique o que é refatorar o código.
R:
Refatorar o código significa revisar e modificar o código-fonte de um software para melhorar
sua estrutura interna, sem alterar o seu comportamento externo. O objetivo da refatoração é
tornar o código mais limpo, legível, eficiente e fácil de manter. A refatoração é um processo
importante para manter a qualidade do código de software. Ao refatorar o código, você pode
melhorar sua legibilidade, eficiência, modularidade e estabilidade, o que pode levar a um
software de melhor qualidade e mais fácil de manter.

8) Qual a importância dos testes de software?

R: Os testes de software são um processo crucial para garantir a qualidade, confiabilidade e
segurança do software. Eles identificam e previnem falhas, garantindo que o software
atenda aos requisitos e funcione conforme o esperado. Seu principal foco é: Detecção de
falhas, prevenção de falhas, garantia de qualidade, aumento de confiabilidade, melhoria de
segurança, redução de custos e satisfação do cliente.

9) O que são testes unitários e testes de aceitação?

R: Testes Unitários:

Os testes unitários são realizados no nível mais baixo de granularidade, geralmente nas
unidades individuais de código, como funções, métodos ou classes.
O objetivo dos testes unitários é verificar se cada unidade de código (como uma função ou
método) funciona conforme o esperado, isoladamente das outras partes do sistema.
Eles são escritos e executados pelos desenvolvedores durante o processo de
desenvolvimento para validar o comportamento esperado de unidades de código
específicas. São frequentemente automatizados e executados com frequência, garantindo
que as mudanças de código não introduzem regressões ou defeitos nas unidades testadas.

Testes de Aceitação:

Os testes de aceitação, por outro lado, são realizados para validar se o sistema como um
todo atende aos requisitos e expectativas do cliente ou usuário final.
Eles são realizados em um nível mais alto de granularidade, geralmente testando cenários
de uso do sistema, fluxos de trabalho ou requisitos funcionais.
Os testes de aceitação são tipicamente escritos para simular o comportamento do usuário
final e garantir que o software atenda aos critérios de aceitação definidos pelo cliente.
Eles podem incluir testes de interface do usuário, testes de integração entre diferentes
partes do sistema e testes de funcionalidade em larga escala. São frequentemente
realizados em colaboração com os stakeholders do projeto para garantir que o software
entregue atenda às necessidades e expectativas do cliente.

10) Trace as semelhanças e diferenças entre o modelo Cascata e o modelo

Incremental.
R: Natureza do ciclo de vida:

O modelo cascata é caracterizado por um ciclo de vida linear, onde cada fase é concluída
antes de avançar para a próxima. Não há retorno para fases anteriores após sua conclusão.
O modelo incremental envolve múltiplas iterações do ciclo de desenvolvimento, onde o
sistema é construído e entregue ao cliente em incrementos ou partes funcionais,
adicionando novas funcionalidades em cada iteração.

Flexibilidade e adaptabilidade:

O modelo cascata é menos flexível em lidar com mudanças de requisitos, uma vez que as
fases são executadas de forma sequencial e as mudanças podem ser difíceis e caras de
serem incorporadas após o início do desenvolvimento.
O modelo incremental é mais flexível e adaptável a mudanças, pois permite que as novas
funcionalidades sejam adicionadas em iterações posteriores, possibilitando uma resposta
mais rápida às mudanças nos requisitos do cliente.

Riscos e feedback:

No modelo cascata, os riscos são identificados e tratados em fases específicas do ciclo de

vida, o que pode levar a descobertas tardias de problemas significativos durante o
desenvolvimento.
No modelo incremental, o feedback do cliente é incorporado em cada iteração, permitindo
uma abordagem mais ágil para mitigar riscos e garantir que o produto final atenda às
necessidades do cliente de maneira mais eficaz.

Entrega de software:

No modelo cascata, o software é entregue ao cliente somente após a conclusão de todas as

fases do processo de desenvolvimento, o que pode resultar em um longo tempo de espera
antes que o cliente veja uma versão funcional do software.
No modelo incremental, o software é entregue em incrementos, permitindo que o cliente
tenha acesso a versões funcionais do software mais cedo no processo de desenvolvimento,
facilitando a validação e a identificação de requisitos adicionais.

11) Qual a função do modelo RAD?

R: O Modelo de Desenvolvimento Rápido de Aplicações (RAD - Rapid Application
Development) é uma abordagem de desenvolvimento de software que visa acelerar o
processo de desenvolvimento, enfatizando iterações rápidas e a entrega rápida de software
funcional. A função principal do modelo RAD é permitir que equipes de desenvolvimento
entregam software de alta qualidade em um período de tempo mais curto do que os
métodos tradicionais de desenvolvimento de software. Algumas das funções específicas do
modelo RAD incluem: entrega rápida, colaboração intensiva, prototipagem rápida,
reutilização de componentes, mudanças flexíveis de requisitos e foco na qualidade.

12) Por que os modelos evolucionários recebem essa denominação?

R: Os modelos evolucionários recebem essa denominação porque são caracterizados por
um processo de desenvolvimento que ocorre de forma iterativa e incremental, com o
software evoluindo ao longo do tempo em resposta a mudanças nos requisitos, feedback do
cliente e descobertas durante o desenvolvimento. Esses modelos são chamados de
"revolucionários" porque o software é desenvolvido e refinado ao longo de várias iterações,
permitindo que ele evolua gradualmente para atender às necessidades em constante
mudança do cliente e do ambiente.

13) Cite as vantagens e desvantagens da Prototipagem.

R: Vantagens da Prototipagem:
Feedback precoce dos usuários: Os protótipos permitem que os usuários experimentem e
forneçam feedback sobre o software em estágios iniciais do desenvolvimento, o que ajuda a
garantir que o produto final atenda às suas necessidades e expectativas.

Validação de requisitos: A criação de protótipos ajuda a esclarecer e validar os requisitos

do sistema, identificando rapidamente possíveis lacunas, inconsistências ou requisitos mal
compreendidos.

Redução de riscos: A prototipagem permite identificar e mitigar riscos técnicos e funcionais

antes da implementação completa do sistema, reduzindo a probabilidade de problemas
significativos durante as fases posteriores do desenvolvimento.

Facilidade de comunicação: Protótipos visuais e interativos facilitam a comunicação entre

as equipes de desenvolvimento e os stakeholders do projeto, ajudando a garantir um
entendimento comum dos requisitos e expectativas.

Desvantagens da Prototipagem:
Foco excessivo na interface do usuário: Os protótipos podem se concentrar
principalmente na interface do usuário, negligenciando aspectos importantes da arquitetura,
desempenho e segurança do sistema.

Custos adicionais: O desenvolvimento de protótipos pode aumentar os custos do projeto,

especialmente se forem necessários recursos adicionais para criar protótipos detalhados e
precisos.

Possíveis expectativas irreais: Os usuários podem formar expectativas irreais com base
em protótipos que não refletem completamente a complexidade ou funcionalidade do
sistema final, levando a desapontamento quando o produto final for entregue.

Dificuldade em manter o foco: Se não for cuidadosamente gerenciado, o processo de

prototipagem pode levar a mudanças contínuas de requisitos e escopo, dificultando o
estabelecimento de metas claras e a conclusão do projeto dentro do prazo e do orçamento.

14) Em que momento a Prototipagem pode ser utilizada no modelo Espiral?

R: Fase de planejamento, fase de engenharia, fase de análise de riscos e fase de avaliação
do cliente.

15) Qual a diferença entre protótipo evolutivo e protótipo descartável?

R: Protótipo Evolutivo:
Permite a validação e o refinamento contínuos do produto.
Reduz o risco de desenvolver um produto que não atenda às necessidades do cliente.
Facilita a comunicação entre a equipe de desenvolvimento e o cliente.
Permite um processo de desenvolvimento mais ágil e adaptável
Protótipo Descartável:
Permite uma rápida visualização e teste de ideias.
É mais rápido e barato de desenvolver do que o protótipo evolutivo.
Não exige uma equipe com experiência em desenvolvimento de software.

16) Quais as vantagens em usar o modelo Espiral com relação ao modelo Cascata?
R: Maior flexibilidade e adaptabilidade:

O modelo Espiral permite revisões e adaptações em cada ciclo, possibilitando lidar com
mudanças nos requisitos e prioridades ao longo do projeto.
A análise de riscos em cada ciclo ajuda a identificar e mitigar potenciais problemas de forma
proativa, reduzindo o impacto de falhas e retrabalho.
Melhor gerenciamento de riscos:

O modelo Espiral incorpora a análise de riscos em cada ciclo, permitindo uma avaliação e
mitigação contínua dos riscos técnicos, de mercado e de negócio.
A prototipagem em cada ciclo facilita a visualização e o teste de funcionalidades críticas,
ajudando a identificar e resolver problemas de usabilidade e design.
Maior qualidade do software:

A validação e o refinamento contínuos do software em cada ciclo do modelo Espiral

contribuem para a entrega de um produto final com maior qualidade e menor quantidade de
bugs.
O feedback constante do cliente garante que o software atenda às suas necessidades e
expectativas.

17) Caracterize o Processo Unificado.

R: O Processo Unificado (UP) é um framework de desenvolvimento de software iterativo e
incremental que combina os melhores elementos de diferentes metodologias, como o
modelo Cascata e a prototipagem. O objetivo do UP é fornecer um guia flexível e adaptável
para o desenvolvimento de software de alta qualidade, atendendo às necessidades dos
clientes e stakeholders.

18) Qual a relação entre o Processo Unificado e a UML?

R: O UP utiliza a UML como linguagem de modelagem para documentar os artefatos do
processo de desenvolvimento. Diagramas de casos de uso, diagramas de classes,
diagramas de sequência, diagramas de estado e outros tipos de diagramas UML são
utilizados para representar os requisitos, a arquitetura e o design do software.

A UML fornece uma notação gráfica para representar os conceitos do UP, facilitando a
comunicação entre os membros da equipe de desenvolvimento e stakeholders.

O UP define um conjunto de atividades para cada fase do processo de desenvolvimento,

enquanto a UML fornece ferramentas para realizar essas atividades.

19) Cite e caracterize as fases do RUP (Processo Unificado da Rational).

R: O Processo Unificado da Rational (RUP) é um framework de desenvolvimento de
software iterativo e incremental que divide o processo em quatro fases principais:
1. Iniciação:

Objetivo: Definir o escopo do projeto, os objetivos e os principais stakeholders.

Atividades:
Definir a visão do produto.
Identificar os stakeholders.
Analisar o ambiente de negócios.
Definir os riscos do projeto.
Criar o plano de projeto.

2. Elaboração:

Objetivo: Detalhar os requisitos do sistema e definir a arquitetura do sistema.

Atividades:
Elicitar e documentar os requisitos do sistema.
Analisar os requisitos do sistema.
Definir a arquitetura do sistema.
Criar o protótipo do sistema.

3. Construção:

Objetivo: Desenvolver e testar o software.

Atividades:
Desenvolver o código do software.
Realizar testes unitários.
Realizar testes de integração.
Realizar testes de sistema.

4. Transição:

Objetivo: Implantar o software e treinar os usuários.

Atividades:
Instalar o software.
Configurar o software.
Treinar os usuários.
Fornecer suporte ao usuário.

20) O que são Artefatos? Qual a relação com o RUP?

R: Artefatos no contexto do desenvolvimento de software são produtos tangíveis que
documentam o processo de desenvolvimento. Eles podem ser documentos, modelos,
código-fonte, scripts de teste, etc.

Relação entre Artefatos e RUP:

O Processo Unificado da Rational (RUP) define um conjunto de artefatos específicos que

devem ser criados em cada fase do processo. Estes artefatos servem para:
Documentar o processo de desenvolvimento: Os artefatos registram as decisões
tomadas, os requisitos do sistema, a arquitetura do sistema, o design do software e os
resultados dos testes.
Facilitar a comunicação: Os artefatos fornecem uma linguagem comum para a equipe de
desenvolvimento e stakeholders.
Garantir a qualidade do software: Os artefatos permitem que o processo de
desenvolvimento seja monitorado e avaliado.

21) Em que fase do RUP é feita a maior parte da codificação e os testes?

R: No RUP (Rational Unified Process), a maior parte da codificação e dos testes é realizada
na fase de Construção.

22) Qual a importância da fase de Iniciação no RUP.

R: A fase de Iniciação no Rational Unified Process (RUP) desempenha um papel
fundamental no sucesso do projeto de desenvolvimento de software. Essa fase é o ponto de
partida do ciclo de vida do projeto e estabelece as bases para o trabalho futuro. A
importância da fase de Iniciação no RUP pode ser destacada pelos seguintes pontos:
Entendimento do contexto do projeto, Análise de viabilidade, Definição de requisitos iniciais,
Estabelecimento de estrutura do projeto, Definição da visão e dos objetivos do projeto e
planejamento inicial.

23) Diferencie versão alfa de versão beta de um produto de software.

R: Versão Alfa:

Estágio de desenvolvimento: Fase inicial, com foco na implementação das

funcionalidades básicas do software.
Estabilidade: Menos estável, com maior probabilidade de bugs e falhas.
Público-alvo: Desenvolvedores e testadores experientes que podem fornecer feedback
técnico detalhado.
Objetivo: Obter feedback sobre a funcionalidade básica do software e identificar problemas
críticos.
Distribuição: Limitada, geralmente para um grupo restrito de usuários.

Versão Beta:

Estágio de desenvolvimento: Fase mais avançada, com a maioria das funcionalidades

implementadas e foco em refinamento e correções.
Estabilidade: Mais estável que a versão alfa, com menor probabilidade de bugs e falhas.
Público-alvo: Público em geral ou um grupo maior de usuários beta para testar a
usabilidade e a experiência do usuário.
Objetivo: Obter feedback sobre a usabilidade, a experiência do usuário e identificar bugs
que podem ter passado despercebidos.
Distribuição: Mais ampla, podendo ser disponibilizada para download público.