1.

Defina os seguintes termos: software, sistema de software e engenharia de

software
Software:

O termo "software" refere-se a um conjunto de programas, instruções e dados que

controlam o funcionamento de um sistema computacional. É uma entidade intangível que
permite que os dispositivos de hardware executem tarefas específicas. O software pode ser
categorizado em dois tipos principais: software de sistema e software de aplicação. O
software de sistema inclui sistemas operacionais, drivers e utilitários que gerenciam o
hardware e fornecem uma interface entre o usuário e o hardware. O software de aplicação
consiste em programas destinados a realizar tarefas específicas, como processamento de
texto, planilhas, navegação na web, entre outros.

Sistema de Software:
Um "sistema de software" refere-se a um conjunto interconectado e interdependente de
componentes de software que trabalham juntos para realizar funções específicas em um
sistema maior. Esses componentes podem incluir software de sistema, software de
middleware e software de aplicação. O objetivo de um sistema de software é fornecer
serviços e funcionalidades que atendam às necessidades dos usuários ou de um sistema
maior. Isso pode incluir a coordenação de recursos de hardware, a comunicação entre
diferentes aplicativos ou a execução de tarefas complexas.

Engenharia de Software:
A "engenharia de software" é uma disciplina que se concentra na aplicação de princípios e
práticas sistemáticas para o desenvolvimento, manutenção e gestão de software de alta
qualidade. Envolve a aplicação de métodos, técnicas e ferramentas para planejar, projetar,
codificar, testar e manter software de forma eficiente e confiável. A engenharia de software
também aborda questões relacionadas à qualidade do software, gerenciamento de projetos,
documentação, segurança e garantia de que o software atenda aos requisitos do usuário
final. É uma disciplina essencial para lidar com a complexidade crescente dos sistemas de
software modernos e garantir a entrega de soluções confiáveis e eficazes.
2. Defina projeto (project) no contexto de gerenciamento de projetos.

No contexto de gerenciamento de projetos, um projeto é um esforço temporário, feito para

criar um produto, serviço ou resultado único. É temporário porque tem um início e um fim
definidos, e éf único porque é diferente de qualquer outro esforço que já foi feito antes.
Os projetos podem ser de qualquer tamanho ou escala, desde o desenvolvimento de um
novo software até a construção de uma ponte. Eles podem ser realizados por indivíduos,
equipes ou organizações.
O gerenciamento de projetos é o processo de planejar, organizar, executar, monitorar e
controlar um projeto para garantir que ele seja concluído com sucesso.
Aqui estão algumas características que definem um projeto:
Temporário: Um projeto tem um início e um fim definidos.
Único: Um projeto é diferente de qualquer outro esforço que já foi feito antes.
Resultado definido: Um projeto tem um produto, serviço ou resultado final definido.
Recursos limitados: Um projeto tem recursos limitados, como tempo, dinheiro e pessoas.
Alguns exemplos de projetos incluem:
Desenvolvimento de um novo produto
Construção de um edifício
Lancamento de um novo serviço
Organização de um evento
Implementação de um novo sistema
O gerenciamento de projetos é uma disciplina que ajuda a garantir que os projetos sejam
concluídos com sucesso. Ele fornece um conjunto de ferramentas e técnicas que podem ser
usadas para planejar, organizar, executar, monitorar e controlar um projeto.
3- Defina ciclo de vida de projeto e descreva propósitos de fases nesse ciclo.

O ciclo de vida de um projeto é um modelo que divide o projeto em fases distintas, cada
uma com seus próprios objetivos e atividades. O ciclo de vida é um guia para o
gerenciamento do projeto e ajuda a garantir que o projeto seja concluído com sucesso.

As fases do ciclo de vida de um projeto são geralmente as seguintes:

Início: Nesta fase, o projeto é definido e aprovado. Os objetivos do projeto são

estabelecidos, os recursos são alocados e a equipe é formada.
Planejamento: Nesta fase, o projeto é planejado em detalhes. O escopo do projeto é
definido, o cronograma é criado, o orçamento é aprovado e o plano de gerenciamento de
riscos é desenvolvido.
Execução: Nesta fase, o projeto é executado de acordo com o plano. As atividades do
projeto são realizadas e os recursos são usados.
Monitoramento e controle: Nesta fase, o projeto é monitorado para garantir que ele esteja
no caminho certo. Os riscos são identificados e mitigados, e as mudanças são gerenciadas.
Encerramento: Nesta fase, o projeto é concluído. Os resultados do projeto são entregues e
os recursos são liberados.
4. Descreva o modelo de gerenciamento iterativo e incremental, defina iteração e
incremento
O modelo de gerenciamento iterativo e incremental é um modelo de desenvolvimento de
software que divide o projeto em ciclos curtos, chamados de iterações. Cada iteração é um
processo completo de desenvolvimento de software, desde a análise dos requisitos até a
entrega do produto.

O modelo iterativo e incremental tem duas características principais:

Iteratividade: O projeto é desenvolvido em ciclos curtos, chamados de iterações. Cada

iteração é um processo completo de desenvolvimento de software, desde a análise dos
requisitos até a entrega do produto.
Incrementalidade: O produto é entregue em incrementos, ou seja, partes funcionais do
produto. Cada incremento é um produto completo e funcional.
Iteração é um ciclo curto de desenvolvimento de software. Cada iteração é composta das
seguintes etapas:

Planejamento: Nesta etapa, os objetivos da iteração são definidos e o cronograma é

elaborado.
Desenvolvimento: Nesta etapa, as funcionalidades da iteração são desenvolvidas.
Testes: Nesta etapa, as funcionalidades da iteração são testadas.
Entrega: Nesta etapa, as funcionalidades da iteração são entregues ao cliente.
Incremento é uma parte funcional do produto. Cada incremento é um produto completo e
funcional.

O modelo iterativo e incremental oferece os seguintes benefícios:

Melhora a qualidade do produto: O produto é desenvolvido em ciclos curtos, o que permite

que os erros sejam identificados e corrigidos mais rapidamente.
Reduz o risco do projeto: O produto é entregue em incrementos, o que permite que o cliente
avalie o produto ao longo do desenvolvimento.
É flexível: O modelo permite que o projeto seja adaptado às mudanças de requisitos.
O modelo iterativo e incremental é um modelo de desenvolvimento de software eficaz para
projetos de software complexos ou com requisitos não bem definidos.
5. Defina marco (milestone) no contexto de projeto de software.
No contexto de projetos de software, um "marco" (milestone) é um ponto significativo no
cronograma do projeto que marca a conclusão de uma fase importante ou a realização de
um objetivo-chave. Os marcos são usados para medir e avaliar o progresso do projeto e são
geralmente associados a eventos ou entregas específicas que demonstram o avanço do
trabalho. Aqui estão algumas características e finalidades comuns dos marcos em projetos
de software:

Conclusão de Fases: Os marcos são frequentemente usados para indicar o término de

fases específicas do projeto, como o término da fase de planejamento, a conclusão do
desenvolvimento de um módulo importante ou a finalização dos testes.

Entregas Importantes: Um marco pode estar associado a entregas significativas, como a

primeira versão funcional do software, a documentação completa do sistema ou a
realização de testes de aceitação bem-sucedidos.

Avaliação de Progresso: Os marcos servem como pontos de referência para avaliar o

progresso do projeto em relação ao cronograma previsto. Eles ajudam a determinar se o
projeto está adiantado, atrasado ou dentro das expectativas.

Tomada de Decisões: Marcar o término de uma fase ou a conclusão de uma entrega

permite que a equipe de gerenciamento e as partes interessadas tomem decisões
informadas sobre o próximo passo no projeto. Isso pode incluir a alocação de recursos
adicionais, a resolução de problemas ou a revisão da estratégia.

Comunicação: Os marcos são ferramentas importantes para a comunicação eficaz entre a

equipe do projeto e as partes interessadas. Eles ajudam a manter todas as partes
informadas sobre o progresso e o status do projeto.

Controle de Qualidade: Marcar a conclusão de uma fase ou entrega também pode ser um
momento para realizar verificações de qualidade. Isso garante que os padrões e requisitos
de qualidade sejam atendidos antes de avançar para a próxima fase.

Exemplos comuns de marcos em projetos de software incluem a conclusão do

planejamento de requisitos, a finalização do design de interface do usuário, a
implementação de funcionalidades-chave, a realização de testes de unidade bem-sucedidos
e a entrega da versão beta do software. Cada um desses marcos representa um ponto
crítico no projeto, e seu cumprimento é fundamental para o sucesso geral do projeto de
software.

6. Defina métrica e relacione cinco métricas relevantes no gerenciamento de projeto.

Uma "métrica" é uma medida quantitativa ou qualitativa que é usada para avaliar o
desempenho, a qualidade, o progresso ou qualquer aspecto mensurável de um projeto,
processo ou sistema. Métricas são usadas para coletar dados objetivos e avaliar o quão
bem um projeto está progredindo em direção aos seus objetivos ou como um sistema está
funcionando em relação a determinados padrões. Aqui estão cinco métricas relevantes no
gerenciamento de projetos:

Custo Total do Projeto (CTP):

Definição: O Custo Total do Projeto é a métrica que avalia o custo global de um projeto,
incluindo despesas diretas e indiretas. Isso abrange custos de mão de obra, materiais,
equipamentos, infraestrutura, despesas gerais e administrativas, entre outros.
Relevância: Monitorar o CTP ajuda a garantir que o projeto permaneça dentro do orçamento
estabelecido e permite a identificação de desvios financeiros que exigem ação corretiva.
Tempo para Conclusão (Schedule Performance):

Definição: O Tempo para Conclusão é a métrica que avalia o quão bem o projeto está
progredindo em relação ao cronograma planejado. Isso envolve comparar o progresso real
com o progresso esperado no momento atual.
Relevância: O acompanhamento do tempo para conclusão ajuda a garantir que o projeto
seja concluído dentro do prazo e permite a identificação precoce de atrasos que precisam
ser tratados.
Qualidade do Produto:

Definição: A Qualidade do Produto avalia o nível de excelência do produto ou do resultado

do projeto. Isso inclui a conformidade com os requisitos, a ausência de defeitos, a
usabilidade e a satisfação do cliente.
Relevância: Monitorar a qualidade do produto ajuda a garantir que o produto final atenda
aos padrões de qualidade estabelecidos e às expectativas do cliente.
Risco do Projeto (Project Risk):
Definição: O Risco do Projeto avalia a probabilidade e o impacto de eventos ou problemas
que podem afetar negativamente o projeto. Isso inclui identificar e classificar riscos
potenciais.
Relevância: Gerenciar o risco do projeto é crucial para antecipar e mitigar ameaças,
garantindo que o projeto seja concluído com sucesso.
Satisfação do Cliente (Customer Satisfaction):

Definição: A Satisfação do Cliente mede o grau de satisfação do cliente em relação ao

produto ou ao resultado final do projeto. Isso pode ser obtido por meio de pesquisas de
feedback ou avaliações diretas.
Relevância: Avaliar a satisfação do cliente é importante para determinar se o projeto
atendeu às expectativas do cliente e se os objetivos foram alcançados com sucesso.
Essas métricas desempenham um papel fundamental no gerenciamento de projetos,
permitindo que os gerentes acompanhem e avaliem o desempenho do projeto em relação a
objetivos, custos, qualidade, riscos e satisfação do cliente. Eles ajudam a orientar as
decisões e ações necessárias para garantir o sucesso do projeto.

7. Defina risco e relacione três categorias de risco em desenvolvimento de software.

Risco é a probabilidade de ocorrência de um evento incerto que pode afetar negativamente
os objetivos de um projeto. Em outras palavras, o risco é a possibilidade de que algo
inesperado aconteça e tenha um impacto indesejado em um projeto, como atrasos, custos
adicionais, diminuição da qualidade ou falha na entrega. No contexto do desenvolvimento
de software, os riscos são eventos ou condições que podem ameaçar o sucesso do projeto.
Aqui estão três categorias de risco comuns em desenvolvimento de software:

Riscos Técnicos:

Definição: Riscos técnicos estão relacionados a desafios técnicos e tecnológicos que

podem surgir durante o desenvolvimento de software. Isso inclui problemas de
compatibilidade, integração de sistemas, escolha de tecnologias inadequadas,
escalabilidade insuficiente, desempenho insatisfatório e dificuldades na implementação de
recursos complexos.
Exemplo: Uma equipe de desenvolvimento escolhe uma linguagem de programação
inadequada para um projeto, o que resulta em baixa eficiência e desempenho insatisfatório.
Riscos de Escopo e Requisitos:
Definição: Riscos de escopo e requisitos estão relacionados a problemas na definição,
documentação e gestão dos requisitos do projeto. Isso inclui requisitos mal compreendidos,
alterações frequentes de escopo, requisitos conflitantes ou não documentados
adequadamente.
Exemplo: Durante o desenvolvimento, o cliente solicita uma série de alterações
significativas no escopo do projeto sem considerar o impacto no cronograma e nos recursos
disponíveis.
Riscos de Recursos Humanos e Gerenciamento:

Definição: Riscos de recursos humanos e gerenciamento estão relacionados a questões

relacionadas às pessoas envolvidas no projeto e às práticas de gerenciamento. Isso inclui a
falta de habilidades ou experiência da equipe, problemas de comunicação, má gestão de
tempo, conflitos de equipe e falhas na liderança.
Exemplo: Um membro-chave da equipe de desenvolvimento renuncia abruptamente durante
a fase crítica do projeto, causando atrasos significativos e a necessidade de treinamento de
substituição.
É importante destacar que essas categorias de risco não são mutuamente exclusivas, e os
projetos de desenvolvimento de software podem enfrentar uma combinação de riscos de
diferentes categorias. O gerenciamento de riscos é uma parte essencial do gerenciamento
de projetos de software e envolve a identificação, avaliação, mitigação e monitoramento
contínuo de riscos para minimizar seu impacto negativo e aumentar a probabilidade de
sucesso do projeto.

8. Relacione artefatos e atividades típicas de processo de gerenciamento de riscos.

O gerenciamento de riscos é um processo contínuo que ocorre ao longo do ciclo de vida do
projeto. O objetivo do gerenciamento de riscos é identificar, avaliar e mitigar os riscos que
podem afetar o sucesso do projeto.

Os artefatos e atividades típicos do processo de gerenciamento de riscos são:

Artefatos:

Plano de gerenciamento de riscos: Este plano define o processo de gerenciamento de

riscos para o projeto.
Lista de riscos: Esta lista identifica todos os riscos potenciais que podem afetar o projeto.
Análise de riscos: Esta análise avalia a probabilidade e o impacto de cada risco.
Plano de resposta a riscos: Este plano define as ações que serão tomadas para mitigar
cada risco.
Relatório de monitoramento de riscos: Este relatório monitora os riscos ao longo do projeto.
Atividades:

Identificação de riscos: Nesta atividade, os riscos potenciais são identificados.

Avaliação de riscos: Nesta atividade, a probabilidade e o impacto de cada risco são
avaliados.
Mitigation de riscos: Nesta atividade, as ações são tomadas para reduzir a probabilidade ou
o impacto de cada risco.
Monitoramento de riscos: Nesta atividade, os riscos são monitorados ao longo do projeto
para garantir que as medidas de mitigação estão funcionando.
Aqui estão alguns exemplos de como artefatos e atividades podem ser relacionados:

O plano de gerenciamento de riscos é usado para orientar as atividades de identificação,

avaliação, mitigação e monitoramento de riscos.
A lista de riscos é usada para documentar os riscos identificados.
A análise de riscos é usada para avaliar a probabilidade e o impacto de cada risco.
O plano de resposta a riscos é usado para definir as ações que serão tomadas para mitigar
cada risco.
O relatório de monitoramento de riscos é usado para acompanhar os riscos ao longo do
projeto.
Ao seguir esses artefatos e atividades, os gerentes de projetos podem ajudar a garantir que
o gerenciamento de riscos seja eficaz.

9. Defina versão (version) e descreva recursos típicos de sistema de gerenciamento

de versões.
Versão é uma instância de um produto ou serviço que foi alterada de alguma forma. No
contexto de desenvolvimento de software, uma versão é uma versão específica do
software que foi lançada.

Recursos típicos de sistema de gerenciamento de versões:

● Controle de acesso: O sistema deve permitir que os usuários acessem apenas

as versões às quais têm permissão.
 ● Versionamento: O sistema deve permitir que os usuários atribuam números de
versão às suas alterações.
● Comparacão de versões: O sistema deve permitir que os usuários comparem
diferentes versões do software.
● Reversão: O sistema deve permitir que os usuários revertam para uma versão
anterior do software.
● Colaboração: O sistema deve permitir que os usuários trabalhem em conjunto
em diferentes versões do software.

Além desses recursos, os sistemas de gerenciamento de versões podem oferecer

recursos adicionais, como:

● Análise de código: O sistema pode fornecer informações sobre o código, como o

tamanho, a complexidade e a cobertura de testes.
● Gerenciamento de dependências: O sistema pode rastrear as dependências
entre diferentes versões do software.
● Gerenciamento de patches: O sistema pode rastrear e aplicar patches para o
software.
● Gerenciamento de lançamentos: O sistema pode ajudar a gerenciar o
lançamento de novas versões do software.

Os sistemas de gerenciamento de versões são uma ferramenta importante para o

desenvolvimento de software. Eles ajudam os desenvolvedores a rastrear mudanças no
software, comparar diferentes versões do software e reverter para versões anteriores do
software.

Aqui estão alguns exemplos de como os sistemas de gerenciamento de versões podem

ser usados:

● Um desenvolvedor pode usar um sistema de gerenciamento de versões para

rastrear as alterações que ele fez em um código-fonte.
● Uma equipe de desenvolvimento pode usar um sistema de gerenciamento de
versões para comparar diferentes versões de um software.
● Uma empresa de software pode usar um sistema de gerenciamento de versões
para reverter para uma versão anterior do software em caso de problemas.
Ao usar um sistema de gerenciamento de versões, os desenvolvedores podem ajudar a
garantir que o software seja desenvolvido e mantido de forma eficaz.

10. Relacione elementos típicos de plano de gestão de configuração de software

(SCMP).
O plano de gestão de configuração de software (SCMP) é um documento que define
como o gerenciamento de configuração de software será realizado em um projeto. O
SCMP deve incluir os seguintes elementos típicos:

● Definição de configuração: O SCMP deve definir o que é considerado uma

configuração de software. Isso pode incluir o código-fonte, os artefatos de
desenvolvimento, a documentação e os dados.
● Identificação de itens de configuração: O SCMP deve identificar todos os itens de
configuração que serão gerenciados. Isso pode incluir componentes de software,
ambientes de teste e dados de teste.
● Controle de mudanças: O SCMP deve definir como as mudanças serão
controladas. Isso pode incluir um processo de revisão e aprovação para todas as
mudanças.
● Revisão de configuração: O SCMP deve definir como a configuração será
revisada para garantir que ela esteja correta e atualizada.
● Restauração de configuração: O SCMP deve definir como a configuração será
restaurada em caso de perda ou dano.
● Relatórios: O SCMP deve definir como a configuração será relatada.

Além desses elementos típicos, o SCMP pode incluir outros elementos, como:

● Gerenciamento de licenças: O SCMP pode definir como as licenças de software

serão gerenciadas.
● Gerenciamento de dependências: O SCMP pode definir como as dependências
entre diferentes itens de configuração serão gerenciadas.
● Gerenciamento de segurança: O SCMP pode definir como a segurança da
configuração será gerenciada.

O SCMP é um documento importante para o desenvolvimento e a manutenção de

software. Ele ajuda a garantir que a configuração do software seja gerenciada de forma
eficaz e que o software seja produzido e mantido de forma consistente.
Aqui estão alguns exemplos de como os elementos do SCMP podem ser usados:

● A definição de configuração pode ser usada para garantir que todos os membros
da equipe de desenvolvimento estejam na mesma página sobre o que constitui
uma configuração de software.
● A identificação de itens de configuração pode ser usada para garantir que todos
os componentes importantes do software sejam gerenciados.
● O controle de mudanças pode ser usado para garantir que todas as mudanças
na configuração sejam rastreadas e aprovadas.
● A revisão de configuração pode ser usada para garantir que a configuração seja
correta e atualizada.
● A restauração de configuração pode ser usada para restaurar o software para
um estado conhecido em caso de problemas.
● Os relatórios podem ser usados para acompanhar o status da configuração.

Ao usar um SCMP, os gerentes de projetos podem ajudar a garantir que o software seja
desenvolvido e mantido de forma eficaz.

11. Descreva as propriedades de completude, consistência e corretude no contexto

de modelos.
No contexto de modelos, a completude, a consistência e a corretude são propriedades
que descrevem a qualidade do modelo.

Completude é a propriedade de um modelo que representa todos os aspectos

relevantes do sistema que ele representa. Um modelo incompleto pode omitir
informações importantes que podem levar a erros ou mal-entendidos.

Consistência é a propriedade de um modelo que não contém contradições. Um modelo

inconsistente pode gerar resultados que são contraditórios ou inválidos.

Corretude é a propriedade de um modelo que representa o sistema de forma precisa e

precisa. Um modelo incorreto pode gerar resultados que são imprecisos ou inválidos.

Aqui estão alguns exemplos de como essas propriedades podem ser aplicadas a
modelos:
 ● Um modelo de sistema de software é completo se representar todos os
requisitos do sistema.
● Um modelo de banco de dados é consistente se não conter contradições, como
dois registros que têm o mesmo valor para uma chave primária.
● Um modelo de previsão meteorológica é correto se gerar previsões que sejam
precisas e consistentes com os dados históricos.

A avaliação da completude, da consistência e da corretude de um modelo pode ser um

processo complexo. No entanto, essas propriedades são importantes para garantir que
os modelos sejam úteis e confiáveis.

Aqui estão algumas dicas para melhorar a completude, a consistência e a corretude de

modelos:

● Envolve todas as partes interessadas no processo de modelagem.

● Use uma metodologia de modelagem bem definida.
● Documente o modelo com cuidado.
● Faça revisões periódicas do modelo.

Ao seguir essas dicas, os modeladores podem ajudar a garantir que seus modelos
sejam de alta qualidade.

12. Descreva três princípios que devem ser observadados em processo de

modelagem.
A modelagem é um processo essencial em muitos domínios, incluindo engenharia, ciência
da computação, negócios e muito mais. Ao realizar a modelagem, é importante seguir
princípios que ajudam a criar modelos eficazes e úteis. Aqui estão três princípios-chave a
serem observados no processo de modelagem:

Simplificação (Princípio da Simplicidade):

O princípio da simplificação enfatiza a importância de manter os modelos o mais simples

possível, sem comprometer a precisão ou a utilidade. Isso significa que os modelos devem
evitar a inclusão de detalhes desnecessários ou complexos que não contribuam
significativamente para os objetivos da modelagem.
A simplificação ajuda a melhorar a compreensão do modelo, facilita a comunicação com
outras partes interessadas e torna o modelo mais gerenciável. Modelos excessivamente
complexos podem ser difíceis de manter, interpretar e usar para tomar decisões.

Abstração (Princípio da Abstração):

O princípio da abstração envolve a representação de um sistema ou conceito complexo por

meio de uma simplificação deliberada, destacando apenas os aspectos mais relevantes e
significativos. Abstrair significa ignorar detalhes menores e se concentrar nas características
essenciais.

A abstração é crucial para criar modelos que sejam mais fáceis de entender e manipular.
Ela permite que os modeladores concentrem-se nos conceitos-chave e nas relações
importantes, reduzindo o ruído da informação não essencial.

Validação (Princípio da Validação):

O princípio da validação enfatiza a importância de verificar e validar continuamente os

modelos em relação à realidade que estão representando. Isso envolve a comparação dos
resultados do modelo com observações reais ou dados reais para garantir que o modelo
esteja produzindo resultados precisos e confiáveis.

A validação é essencial para garantir que o modelo seja útil e confiável. Modelos não
validados podem levar a decisões incorretas e ações inadequadas. A validação ajuda a
identificar e corrigir erros ou inconsistências no modelo.

Esses princípios são aplicáveis a uma variedade de contextos de modelagem e são

fundamentais para criar modelos que sejam úteis, compreensíveis e confiáveis. Eles ajudam
a equilibrar a simplificação com a precisão, a destacar o que é mais importante e a verificar
continuamente a qualidade do modelo.

13. Defina classes e objetos na modelagem orientada a objetos.

Na modelagem orientada a objetos, "classes" e "objetos" são conceitos fundamentais que
são usados para criar modelos de sistemas e representar o mundo real de forma
estruturada e modular. Aqui estão definições para ambos os conceitos:
Classe:

Uma classe é uma estrutura ou um modelo que define as características (atributos) e

comportamentos (métodos) comuns a um conjunto de objetos relacionados. Ela atua como
um plano ou um molde para criar objetos. Em outras palavras, uma classe é uma abstração
que descreve um tipo de objeto.

As características de uma classe são representadas por variáveis ou atributos que

armazenam dados específicos da classe, enquanto os comportamentos são definidos por
métodos, que são funções ou procedimentos que podem ser executados pelos objetos
dessa classe.

Por exemplo, em um sistema de gerenciamento de biblioteca, pode haver uma classe

"Livro" que define os atributos comuns de todos os livros, como título, autor e número de
páginas, e os métodos que permitem realizar operações em livros, como emprestar,
devolver e consultar informações.

Objeto:

Um objeto é uma instância concreta de uma classe. É uma entidade real que possui seus
próprios dados (atributos) e pode realizar ações (métodos) específicas com base na
definição da classe à qual pertence.

Cada objeto criado a partir de uma classe é uma entidade única, com seus próprios valores
de atributos, mas compartilha a mesma estrutura de comportamento definida pela classe.

Continuando o exemplo anterior, se você criar um objeto "MeuLivro" a partir da classe

"Livro", esse objeto representará um livro específico da biblioteca, com um título, autor e
número de páginas específicos. Você pode realizar ações como emprestar ou consultar
informações sobre esse livro.

Em resumo, as classes definem estruturalmente o que um tipo de objeto é capaz de fazer,

enquanto os objetos representam instâncias individuais desse tipo, com dados específicos e
a capacidade de executar as ações definidas pela classe. A modelagem orientada a objetos
utiliza esses conceitos para organizar e representar sistemas de software de forma modular,
permitindo a criação de componentes reutilizáveis e o mapeamento mais próximo do mundo
real.
14. Constraste os relacionamentos entre classes: associação, agregação,
composição e herança.
Na modelagem orientada a objetos, os relacionamentos entre classes são usados para
representar como as classes estão conectadas e interagem umas com as outras. Existem
quatro tipos principais de relacionamentos entre classes: associação, agregação,
composição e herança. Aqui está um contraste entre esses relacionamentos:

Associação:

Definição: A associação é um relacionamento básico que indica uma conexão entre duas
classes. Ela representa que uma classe está de alguma forma relacionada a outra classe,
mas não implica propriedade ou dependência forte.

Natureza: A associação pode ser bidirecional ou unidirecional, e não impõe uma relação
específica entre as classes, apenas indica que elas estão de alguma forma conectadas.

Exemplo: Uma classe "Estudante" está associada a uma classe "Curso". Isso indica que os
estudantes estão inscritos em cursos, mas não implica que um estudante possui um curso
ou vice-versa.

Agregação:

Definição: A agregação é um relacionamento que indica uma relação de "todo-parte" entre

classes. Uma classe "todo" (agregador) contém ou é composta de objetos de outra classe
"parte".

Natureza: A agregação é uma forma mais forte de associação e implica uma relação
hierárquica. A parte pode existir independentemente do todo e pode estar associada a
outros "todos".

Exemplo: Uma classe "Carro" pode ter uma agregação com uma classe "Roda". Um carro
tem rodas como parte de sua estrutura, mas as rodas podem existir independentemente e
serem usadas em diferentes carros.

Composição:
Definição: A composição é uma forma mais restritiva de agregação em que a parte só pode
pertencer a um único todo. Ela implica uma relação de dependência forte, onde a parte é
criada e destruída junto com o todo.

Natureza: Na composição, a vida da parte está vinculada à vida do todo. Quando o todo é
destruído, todas as partes também são destruídas.

Exemplo: Um carro tem uma composição com um motor. O motor é uma parte intrínseca
do carro, e quando o carro é desmontado ou destruído, o motor também é afetado.

Herança:

Definição: A herança é um relacionamento que permite que uma classe (subclasse ou

classe derivada) herde atributos e métodos de outra classe (superclasse ou classe base).

Natureza: A herança é usada para estabelecer uma relação "é-um", onde a subclasse é um
tipo específico da superclasse. A subclasse pode estender ou substituir o comportamento
da superclasse.

Exemplo: Uma classe "Gato" pode herdar características de uma classe "Animal". O "Gato"
é um tipo específico de "Animal" e pode ter atributos e métodos adicionais que são
específicos para gatos.

Em resumo, esses relacionamentos entre classes fornecem maneiras diferentes de modelar

a estrutura e o comportamento de um sistema orientado a objetos. A escolha do
relacionamento adequado depende das necessidades específicas do sistema e das
relações que existem entre as classes.

15. Defina e exemplifique ciclo de vida de desenvolvimento de software.

O ciclo de vida de desenvolvimento de software (SDLC) é um modelo que descreve as
fases e atividades envolvidas no desenvolvimento de um software. Ele é usado para
garantir que o software seja desenvolvido de forma eficaz e eficiente.

O SDLC geralmente é dividido em quatro fases principais:

 ● Requisitos: Nesta fase, os requisitos do software são coletados e analisados.
● Projeto: Nesta fase, o software é projetado.
● Implementação: Nesta fase, o software é codificado e testado.
● Operação e manutenção: Nesta fase, o software é implantado e mantido.

Além dessas quatro fases principais, o SDLC pode incluir outras fases, como:

● Plano: Nesta fase, um plano para o desenvolvimento do software é criado.

● Validação: Nesta fase, o software é validado para garantir que atenda aos
requisitos.
● Documentação: Nesta fase, a documentação do software é criada.

Exemplo:

Imagine que uma empresa deseja desenvolver um novo aplicativo de e-commerce. O

SDLC para esse projeto pode ser o seguinte:

● Requisitos: A empresa entrevista usuários e stakeholders para coletar requisitos

para o aplicativo.
● Projeto: Os arquitetos de software projetam o aplicativo, incluindo a arquitetura, o
design da interface do usuário e o design da base de dados.
● Implementação: Os desenvolvedores codificam o aplicativo e realizam testes
unitários.
● Validação: Os testes de aceitação são realizados para garantir que o aplicativo
atenda aos requisitos.
● Documentação: A documentação do aplicativo é criada para ajudar os usuários a
usar o aplicativo.
● Operação e manutenção: O aplicativo é implantado e mantido após o
lançamento.

O SDLC é uma ferramenta importante para o desenvolvimento de software. Ele ajuda a

garantir que o software seja desenvolvido de forma eficaz e eficiente, e que atenda às
necessidades dos usuários

16. Defina e exemplifique ciclo de vida de produto de software.

O ciclo de vida de um produto de software é um conceito que se refere às diferentes
fases e atividades que um produto de software passa desde a sua concepção até a sua
aposentadoria. Essas fases compreendem o desenvolvimento, a entrega, a operação, a
manutenção e, finalmente, o desligamento do produto. Vou definir e exemplificar as
principais fases do ciclo de vida de um produto de software:

Concepção:

Definição: A fase de concepção é o ponto de partida do ciclo de vida do produto de

software. Nesta fase, a ideia inicial para o software é concebida, e os objetivos,
requisitos iniciais e o escopo são definidos.

Exemplo: Imagine uma equipe de desenvolvimento de software que identifica a

necessidade de um novo sistema de gerenciamento de projetos para melhorar a
eficiência do trabalho em equipe. A fase de concepção envolve a definição das metas do
sistema, dos recursos necessários e da visão geral do projeto.

Desenvolvimento:

Definição: A fase de desenvolvimento é onde o software é projetado, codificado e

testado. É a etapa principal na criação do produto.

Exemplo: Durante a fase de desenvolvimento, a equipe de software cria o código-fonte,

implementa os recursos e funcionalidades de acordo com os requisitos estabelecidos na
fase de concepção. Isso envolve a criação de protótipos, design de interface do usuário,
codificação, testes unitários e integração de componentes.

Entrega e Implantação:

Definição: Nesta fase, o software desenvolvido é entregue aos usuários finais e

implantado em um ambiente de produção.

Exemplo: Após concluir o desenvolvimento e os testes, o sistema de gerenciamento de

projetos é implantado na infraestrutura da empresa. Os usuários começam a utilizá-lo
para gerenciar suas tarefas e projetos.

Operação e Manutenção:
Definição: Após a implantação, o software entra na fase de operação e manutenção.
Nesta fase, o software é usado continuamente pelos usuários e requer manutenção,
correções de erros e atualizações.

Exemplo: Durante a operação e manutenção, a equipe de suporte de TI monitora o

sistema de gerenciamento de projetos em busca de problemas, aplica patches de
segurança, fornece suporte aos usuários e realiza melhorias incrementais com base no
feedback dos usuários.

Desligamento:

Definição: No final do ciclo de vida do produto, chega o momento de desligar o

software. Isso pode ocorrer devido a obsolescência, mudanças nas necessidades dos
usuários ou devido ao lançamento de uma nova versão.

Exemplo: Após anos de uso, a empresa decide desligar o sistema de gerenciamento de

projetos, pois a equipe migrou para uma nova ferramenta mais avançada que atende
melhor às suas necessidades. O software mais antigo é descontinuado e retirado de
uso.

É importante notar que o ciclo de vida de um produto de software é um processo

contínuo e iterativo. À medida que as necessidades dos usuários evoluem e as
tecnologias mudam, o software pode passar por várias iterações desse ciclo, desde a
concepção até o desligamento. Cada fase requer planejamento, recursos e
gerenciamento adequados para garantir o sucesso do produto ao longo de sua vida útil.

17. Descreva uma categorização para processos de software (primários,

organizacionais etc.).

Os processos de software podem ser categorizados de várias maneiras, dependendo do

objetivo da categorização. Uma categorização comum é baseada no foco do processo:

Processos primários: são aqueles que estão diretamente envolvidos no desenvolvimento,

teste e implantação do software. Eles incluem processos como análise de requisitos,
projeto, implementação, teste e implantação.
Processos de apoio: são aqueles que fornecem suporte aos processos primários. Eles
incluem processos como gerenciamento de configuração, gerenciamento de qualidade,
gerenciamento de risco e gerenciamento de mudanças.
Processos organizacionais: são aqueles que se aplicam a toda a organização de
desenvolvimento de software. Eles incluem processos como gerenciamento de projetos,
gerenciamento de portfólios e gerenciamento de pessoas.

18. Descreva o modelo de desenvolvimento em cascata e relacione

vantagens/desvantagens.
O modelo de desenvolvimento em cascata é um modelo de desenvolvimento de
software sequencial, no qual cada fase do processo deve ser concluída antes que a
próxima fase possa começar. O modelo é dividido em seis fases principais:

● Requisitos: Nesta fase, os requisitos do software são coletados e analisados.

● Projeto: Nesta fase, o software é projetado.
● Implementação: Nesta fase, o software é codificado.
● Teste: Nesta fase, o software é testado para garantir que atenda aos requisitos.
● Implantação: Nesta fase, o software é implantado em produção.
● Manutenção: Nesta fase, o software é mantido e atualizado.

Vantagens:

● Fácil de entender e implementar.

● Pode ser usado em projetos de qualquer tamanho ou complexidade.
● É adequado para projetos com requisitos bem definidos e estáveis.

Desvantagens:

● É rígida e não permite mudanças.

● Pode ser difícil gerenciar projetos complexos.
● É difícil incorporar feedback do usuário durante o desenvolvimento.

19. Descreva o modelo de desenvolvimento evolucionário e relacione

vantagens/desvantagens.
O modelo de desenvolvimento evolucionário é uma abordagem de desenvolvimento de
software que reconhece a natureza mutável e iterativa dos requisitos de um projeto.
Diferentemente do modelo em cascata, que segue uma abordagem sequencial e linear,
o modelo evolucionário permite que o software seja desenvolvido e aprimorado por meio
de múltiplas iterações ou versões, incorporando feedback contínuo dos usuários e
partes interessadas

O modelo de desenvolvimento evolucionário é dividido em duas fases principais:

● Evolução: Nesta fase, o software é desenvolvido em iterações.

● Estabilização: Nesta fase, o software é estabilizado e entregue aos usuários.

Vantagens:

● É flexível e permite mudanças.

● É fácil incorporar feedback do usuário durante o desenvolvimento.
● É adequado para projetos com requisitos mutáveis.

Desvantagens:

● Pode ser mais complexo de gerenciar do que o modelo em cascata.

● Pode ser mais caro do que o modelo em cascata.

O modelo de desenvolvimento evolucionário é um modelo moderno de desenvolvimento

de software que é frequentemente usado em projetos de médio e pequeno porte com
requisitos mutáveis. O modelo é flexível e permite mudanças, o que é importante em
projetos com requisitos que podem mudar ao longo do tempo.

Em geral, o modelo de desenvolvimento evolucionário é uma boa opção para projetos

com requisitos mutáveis. No entanto, é importante considerar as vantagens e
desvantagens do modelo antes de decidir se ele é adequado para um projeto específico.

20. Descreva o modelo baseado em entregas incrementais e relacione

vantagens/desvantagens.
O modelo baseado em entregas incrementais é um modelo de desenvolvimento de
software iterativo e incremental, no qual o software é entregue em pequenos
incrementos, chamados de entregas. Cada entrega é composta de uma parte do
software que é funcional e pode ser usada pelos usuários.

O modelo baseado em entregas incrementais é dividido em duas fases principais:

● Planejamento: Nesta fase, o projeto é planejado e as entregas são definidas.

● Execução: Nesta fase, as entregas são executadas e o software é desenvolvido.

Vantagens:

● É flexível e permite mudanças.

● É fácil incorporar feedback do usuário durante o desenvolvimento.
● É adequado para projetos com requisitos mutáveis.
● Permite que o software seja entregue aos usuários mais cedo.

Desvantagens:

● Pode ser mais complexo de gerenciar do que o modelo em cascata.

● Pode ser mais caro do que o modelo em cascata.
● Pode ser difícil gerenciar o backlog de requisitos.

O modelo baseado em entregas incrementais é um modelo moderno de

desenvolvimento de software que é frequentemente usado em projetos de qualquer
tamanho ou complexidade. O modelo é flexível e permite mudanças, o que é iDiferenças
entre o modelo baseado em entregas incrementais e o modelo evolucionário:

O modelo baseado em entregas incrementais é semelhante ao modelo evolucionário,

pois ambos são iterativos e incrementais. No entanto, existem algumas diferenças
importantes entre os dois modelos:

● No modelo baseado em entregas incrementais, o software é entregue em

incrementos claramente definidos, chamados de entregas. No modelo
evolucionário, o software é desenvolvido em iterações, que podem ser grandes
ou pequenas.
 ● No modelo baseado em entregas incrementais, o planejamento é feito para cada
entrega. No modelo evolucionário, o planejamento é feito para o projeto como
um todo.
● No modelo baseado em entregas incrementais, o feedback do usuário é coletado
após cada entrega. No modelo evolucionário, o feedback do usuário é coletado
ao longo do desenvolvimento.

Em geral, o modelo baseado em entregas incrementais é mais adequado para projetos

que precisam ser entregues em um prazo específico ou que precisam ser testados e
validados com os usuários regularmente. O modelo evolucionário é mais adequado para
projetos que precisam ser desenvolvidos rapidamente ou que precisam ser adaptados
às necessidades dos usuários.

21. Descreva o modelo de desenvolvimento em espiral e relacione

vantagens/desvantagens.
O modelo de desenvolvimento em espiral é um modelo de processo de software que
combina elementos de modelos lineares com elementos de modelos iterativos. Ele é
representado por uma espiral, com cada volta na espiral representando uma iteração do
processo.

O modelo em espiral é dividido em quatro fases principais:

● Planejamento: Nesta fase, são definidos os objetivos do projeto, os requisitos do

sistema, o escopo do projeto e o cronograma.
● Análise de riscos: Nesta fase, são identificados e avaliados os riscos do projeto.
● Desenvolvimento: Nesta fase, é desenvolvido um protótipo ou uma versão inicial
do sistema.
● Validação: Nesta fase, o protótipo ou a versão inicial do sistema é validado com
os usuários.
● Após a conclusão de cada iteração, o projeto é avaliado e, se necessário, são
feitas alterações no plano do projeto. Este processo é repetido até que o sistema
esteja completo e satisfaça os requisitos dos usuários.

Vantagens do modelo de desenvolvimento em espiral:

 ● Redução de riscos: O modelo em espiral permite que os riscos do projeto sejam
identificados e avaliados precocemente, o que pode levar a uma redução nos
custos e no tempo de desenvolvimento.
● Adaptabilidade: O modelo em espiral é adaptável a mudanças nos requisitos do
sistema ou no ambiente de desenvolvimento.
● Qualidade: O modelo em espiral promove a qualidade do software, pois permite
que os requisitos e o design sejam validados com os usuários em cada iteração.

Desvantagens do modelo de desenvolvimento em espiral:

● Complexidade: O modelo em espiral pode ser complexo de implementar e

gerenciar.
● Custo: O modelo em espiral pode ser mais caro do que os modelos lineares.
● Tempo: O modelo em espiral pode levar mais tempo para ser concluído do que
os modelos lineares.

O modelo de desenvolvimento em espiral é uma boa opção para projetos complexos ou

que apresentam riscos elevados. Ele é também uma boa opção para projetos que
precisam ser adaptáveis a mudanças.

22. Contraste o desenvolvimento exploratório com a prototipação throw-away.

O desenvolvimento exploratório e a prototipação throw-away são duas abordagens de
desenvolvimento de software que compartilham algumas semelhanças, mas diferem em
seus objetivos, processos e resultados. Vamos contrastar essas duas abordagens:

Desenvolvimento Exploratório:

Objetivo: O desenvolvimento exploratório é usado quando os requisitos do sistema não

estão bem definidos ou são altamente voláteis. O objetivo principal é explorar e entender os
requisitos à medida que o projeto avança.

Processo: O desenvolvimento exploratório é altamente iterativo e flexível. Não há um plano

rígido definido no início do projeto. Em vez disso, o desenvolvimento começa com uma ideia
geral e evolui à medida que novas informações e requisitos emergem.
Protótipos: Protótipos são frequentemente desenvolvidos, mas eles podem evoluir à
medida que os requisitos mudam. Os protótipos não são necessariamente descartados
após a fase de exploração; eles podem se tornar a base para o sistema final.

Cliente Envolvido: O cliente ou usuário final está fortemente envolvido durante todo o
processo de desenvolvimento, fornecendo feedback contínuo para ajudar a refinar os
requisitos.

Prototipação Throw-Away:

Objetivo: A prototipação throw-away é usada para criar protótipos descartáveis ou

temporários com o objetivo de explorar conceitos de design, demonstrar funcionalidades
específicas ou validar requisitos sem a intenção de incorporá-los ao produto final.

Processo: O foco principal é na rápida criação de um protótipo funcional, muitas vezes

negligenciando a qualidade do código ou a robustez do sistema, uma vez que não será
usado no produto final.

Protótipos: Os protótipos criados na prototipação throw-away são deliberadamente

descartados após seu propósito ser alcançado. Eles não são destinados a serem parte
integrante do produto final.

Cliente Envolvido: O cliente pode estar envolvido na revisão dos protótipos, mas o
principal objetivo é obter feedback sobre conceitos e funcionalidades, não para coletar
feedback sobre o código ou a estrutura do sistema.

Em resumo, a principal diferença entre o desenvolvimento exploratório e a prototipação

throw-away é a intenção em relação aos protótipos. No desenvolvimento exploratório, os
protótipos podem evoluir e se tornar parte do produto final, enquanto na prototipação
throw-away, os protótipos são criados com a intenção de serem descartados depois de
atingirem seus objetivos específicos. Ambas as abordagens são úteis em contextos
diferentes, dependendo das necessidades do projeto e dos requisitos do cliente.

23. Descreva as responsabilidades de cada fase no Processo Unificado (Unified

Process).
O Processo Unificado (PU) é um processo de desenvolvimento de software iterativo e
incremental que é dividido em quatro fases principais: concepção, elaboração,
construção e transição. Cada fase tem um conjunto de responsabilidades específicas
que são atribuídas a diferentes membros da equipe de desenvolvimento.

Fase de concepção

A fase de concepção é responsável por definir o escopo do projeto, os requisitos do

sistema e o plano de projeto. As responsabilidades dessa fase incluem:

● Analisar os requisitos dos usuários: Os requisitos dos usuários são coletados e

analisados para garantir que o sistema atenda às necessidades dos usuários.
● Definir o escopo do projeto: O escopo do projeto é definido para garantir que o
projeto seja concluído dentro do prazo e do orçamento.
● Desenvolver o plano de projeto: O plano de projeto é desenvolvido para definir
as atividades, os recursos e o cronograma do projeto.

Fase de elaboração

A fase de elaboração é responsável por refinar os requisitos do sistema e desenvolver

um design detalhado. As responsabilidades dessa fase incluem:

● Refinar os requisitos do sistema: Os requisitos do sistema são refinados para

garantir que sejam completos, consistentes e verificáveis.
● Desenvolver um design detalhado: Um design detalhado é desenvolvido para
descrever como o sistema será implementado.
● Desenvolver um protótipo: Um protótipo pode ser desenvolvido para validar o
design do sistema.

Fase de construção

A fase de construção é responsável por implementar o sistema de acordo com o design

detalhado. As responsabilidades dessa fase incluem:

● Implementar o sistema: O sistema é implementado de acordo com o design

detalhado.
● Testar o sistema: O sistema é testado para garantir que atenda aos requisitos.
● Documentar o sistema: O sistema é documentado para facilitar o uso e a
manutenção.
Fase de transição

A fase de transição é responsável por entregar o sistema aos usuários e garantir que
esteja em conformidade com seus requisitos. As responsabilidades dessa fase incluem:

● Instalar o sistema: O sistema é instalado no ambiente de produção.

● Treinar os usuários: Os usuários são treinados no uso do sistema.
● Suportar o sistema: O sistema é suportado para garantir que esteja em
operação.

Responsabilidades por fase

A tabela a seguir resume as responsabilidades por fase no Processo Unificado:

Fase Responsabilidades Membros da equipe

Conce Definir o escopo do projeto, os Analista de

pção requisitos do sistema e o plano negócios, arquiteto
de projeto. de software, gerente
de projeto

Elabor Refinar os requisitos do Analista de

ação sistema e desenvolver um negócios, arquiteto
design detalhado. de software,
engenheiro de
software

Constr Implementar o sistema de Engenheiro de

ução acordo com o design software, tester
detalhado.

Transiç Entregar o sistema aos Gerente de projeto,

ão usuários e garantir que esteja usuário, tester
em conformidade com seus
requisitos.
Notas:

● As responsabilidades podem variar de acordo com o tamanho e a complexidade

do projeto.
● Em projetos pequenos, as responsabilidades podem ser assumidas por uma
única pessoa.
● Em projetos grandes, as responsabilidades podem ser divididas em equipes
menores.

24. Defina fluxo de atividades (workflow) no Processo Unificado e apresente um

exemplo.
No Processo Unificado, o fluxo de atividades (workflow) é uma sequência de atividades
que são realizadas para desenvolver um sistema de software. Esse fluxo é iterativo e
incremental, o que significa que o sistema é desenvolvido em pequenas etapas, cada
uma das quais é validada antes de prosseguir para a próxima etapa.

O fluxo de atividades do Processo Unificado é dividido em quatro fases principais:

concepção, elaboração, construção e transição. Cada fase tem um conjunto de
atividades específicas que são atribuídas a diferentes membros da equipe de
desenvolvimento.

Exemplo de fluxo de atividades no Processo Unificado

Considere o desenvolvimento de um novo sistema de gerenciamento de clientes para

uma empresa. O fluxo de atividades para esse projeto pode ser o seguinte:

Fase de concepção:

● Análise dos requisitos dos usuários: Os requisitos dos usuários são coletados e
analisados para garantir que o sistema atenda às necessidades dos usuários.
● Definição do escopo do projeto: O escopo do projeto é definido para garantir que
o projeto seja concluído dentro do prazo e do orçamento.
● Desenvolvimento do plano de projeto: O plano de projeto é desenvolvido para
definir as atividades, os recursos e o cronograma do projeto.

Fase de elaboração:
 ● Refinamento dos requisitos do sistema: Os requisitos do sistema são refinados
para garantir que sejam completos, consistentes e verificáveis.
● Desenvolvimento de um design detalhado: Um design detalhado é desenvolvido
para descrever como o sistema será implementado.
● Desenvolvimento de um protótipo: Um protótipo pode ser desenvolvido para
validar o design do sistema.

Fase de construção:

● Implementação do sistema: O sistema é implementado de acordo com o design

detalhado.
● Teste do sistema: O sistema é testado para garantir que atenda aos requisitos.
● Documentação do sistema: O sistema é documentado para facilitar o uso e a
manutenção.

Fase de transição:

● Instalação do sistema: O sistema é instalado no ambiente de produção.

● Treinamento dos usuários: Os usuários são treinados no uso do sistema.
● Suporte ao sistema: O sistema é suportado para garantir que esteja em
operação.

Este é apenas um exemplo de fluxo de atividades no Processo Unificado. O fluxo de

atividades específico para um projeto dependerá de uma série de fatores, incluindo o
tamanho e a complexidade do projeto, os requisitos do sistema e as preferências da
equipe de desenvolvimento.

O fluxo de atividades é uma ferramenta importante para gerenciar o desenvolvimento de

um sistema de software. Ele ajuda a garantir que o projeto seja concluído de forma
eficiente e eficaz, e que o sistema atenda aos requisitos dos usuários.

25. Relacione requisitos relevantes ao sucesso de projeto de software aberto.

Os requisitos relevantes ao sucesso de projeto de software aberto são aqueles que
contribuem para a criação de um produto de alta qualidade, que atenda às
necessidades dos usuários e que seja sustentável no longo prazo.
Alguns dos requisitos mais importantes incluem:

● Um bom design: O software deve ser bem projetado, com uma arquitetura
flexível e escalável.
● Documentação clara e concisa: A documentação deve ser clara e concisa, de
modo que os desenvolvedores possam entender como o software funciona e
como modificá-lo.
● Testes abrangentes: O software deve ser testado extensivamente para garantir
que funcione corretamente.
● Um processo de desenvolvimento bem definido: O processo de desenvolvimento
deve ser claro e transparente, para que os contribuidores saibam como
participar.
● Uma comunidade ativa: Uma comunidade ativa de desenvolvedores e usuários é
essencial para o sucesso de um projeto de software aberto.

Além desses requisitos, existem alguns outros fatores que podem contribuir para o
sucesso de um projeto de software aberto, como:

● Um produto com uma boa proposta de valor: O produto deve oferecer algo de
valor aos usuários, de modo que eles estejam motivados a contribuir.
● Uma marca forte: O projeto deve ter uma marca forte e consistente, para que
seja facilmente identificável.
● Uma estratégia de marketing e divulgação eficaz: O projeto deve ser promovido
de forma eficaz para alcançar o público-alvo.

A seguir, são apresentados alguns exemplos de como esses requisitos podem ser
aplicados a um projeto de software aberto:

● Um bom design: O software deve ser bem projetado para atender às

necessidades dos usuários. Isso pode ser feito por meio de pesquisas com
usuários, análise de dados e colaboração com especialistas.
● Documentação clara e concisa: A documentação deve ser clara e concisa para
que os desenvolvedores possam entender como o software funciona e como
modificá-lo. Isso pode ser feito por meio da criação de documentação técnica,
tutoriais e exemplos.
 ● Testes abrangentes: O software deve ser testado extensivamente para garantir
que funcione corretamente. Isso pode ser feito por meio de testes automatizados
e testes manuais.
● Um processo de desenvolvimento bem definido: O processo de desenvolvimento
deve ser claro e transparente para que os contribuidores saibam como participar.
Isso pode ser feito por meio da criação de uma documentação de processo e da
realização de reuniões regulares para discutir o progresso do projeto.
● Uma comunidade ativa: Uma comunidade ativa de desenvolvedores e usuários é
essencial para o sucesso de um projeto de software aberto. Isso pode ser
incentivado por meio da criação de fóruns de discussão, chats e outros canais de
comunicação.

Ao atender a esses requisitos, os projetos de software aberto têm uma chance maior de
ser bem-sucedidos.

26. Descreva a abordagem de desenvolvimento bug driven development.

A abordagem de desenvolvimento bug driven development (BDD) é uma abordagem de
desenvolvimento de software que se concentra na identificação e correção de bugs.
Essa abordagem é baseada na ideia de que os bugs são uma oportunidade para
melhorar o software, tornando-o mais robusto e confiável.

No BDD, os bugs são tratados como requisitos negativos. Isso significa que eles são
descritos como o que não deve acontecer. Por exemplo, um bug pode ser descrito como
"o sistema deve não travar quando o usuário tenta inserir um valor inválido".

O BDD é um processo iterativo e incremental. Isso significa que os bugs são corrigidos
em pequenas etapas, cada uma das quais é validada antes de prosseguir para a
próxima etapa.

O BDD é uma abordagem que pode ser eficaz para melhorar a qualidade do software.
No entanto, é importante notar que o BDD não é uma solução para todos os problemas
de desenvolvimento de software. O BDD é mais adequado para projetos em que a
qualidade é uma prioridade e em que os requisitos são claros e bem definidos.

Vantagens do BDD
 ● Melhora a qualidade do software: O BDD ajuda a identificar e corrigir bugs, o que
pode melhorar a qualidade do software.
● Reduz os custos de manutenção: Ao corrigir os bugs no início do processo de
desenvolvimento, é possível reduzir os custos de manutenção no futuro.
● Melhora a compreensão do código: O BDD pode ajudar a melhorar a
compreensão do código, pois os bugs são descritos como requisitos negativos.

Desvantagens do BDD

● Pode ser lento: O BDD é um processo iterativo e incremental, o que pode levar
mais tempo para concluir o desenvolvimento do software.
● Pode ser difícil de implementar: O BDD pode ser difícil de implementar em
projetos com requisitos complexos ou em constante mudança.

27. Relacione canais de comunicação entre desenvolvedores típicos de projeto de

software aberto.
Os canais de comunicação entre desenvolvedores típicos de projeto de software aberto
são essenciais para o sucesso do projeto. Eles permitem que os desenvolvedores
compartilhem ideias, colaborem no código e resolvam problemas.

Alguns dos canais de comunicação mais comuns entre desenvolvedores de projetos de

software aberto incluem:

● Fóruns de discussão: Os fóruns de discussão são uma ótima maneira para os

desenvolvedores compartilharem ideias e discutir problemas. Eles geralmente
são organizados por tópico, o que facilita a localização de informações
específicas.
● Chats: Os chats são uma ótima maneira para os desenvolvedores se
comunicarem em tempo real. Eles são úteis para discussões rápidas ou para
obter ajuda imediata.
● Repositorios de código: Os repositórios de código são onde o código do projeto é
armazenado. Eles geralmente têm um sistema de rastreamento de problemas,
que os desenvolvedores podem usar para relatar problemas e acompanhar o
progresso das correções.
 ● Documentação: A documentação do projeto é uma fonte importante de
informações para os desenvolvedores. Ela pode incluir informações sobre o
código, a arquitetura do sistema e as melhores práticas.

Além desses canais de comunicação comuns, os projetos de software aberto também

podem usar ferramentas e serviços específicos para melhorar a comunicação entre os
desenvolvedores. Alguns exemplos incluem:

● Gerenciadores de projetos: Os gerenciadores de projetos podem ajudar os

desenvolvedores a organizar o trabalho e acompanhar o progresso do projeto.
● Sistemas de controle de versão: Os sistemas de controle de versão permitem
que os desenvolvedores rastreiem as alterações no código.
● Testes automatizados: Os testes automatizados podem ajudar os
desenvolvedores a garantir a qualidade do código.

O uso de canais de comunicação eficazes é essencial para o sucesso de qualquer

projeto de software aberto. Eles permitem que os desenvolvedores colaborem de forma
eficiente e eficaz, o que pode levar a um produto de melhor qualidade.

28. Contraste a gestão de projeto de software aberto centralizada com a embasada

em mérito.

Característica Gestão de projeto de software Gestão de projeto de software

aberto centralizada aberto embasada em mérito

Responsabili Um pequeno grupo de Qualquer pessoa

dade mantenedores

Tomadas de Centralizadas Descentralizadas

decisão

Métricas de Entrega de um produto de alta Atratividade para a comunidade

sucesso qualidade
 Vantagens Pode ser eficaz para projetos Pode ser eficaz para projetos
grandes ou complexos pequenos ou simples

Desvantage Pode ser descentralizada Pode ser demorada

ns

29. Relacione cinco princípios integrantes do manifesto ágil (agile manifesto).

O Manifesto Ágil é um documento que define os valores e princípios que orientam os
métodos ágeis de desenvolvimento de software. Foi publicado em 2001 por um grupo de
17 desenvolvedores e especialistas em software.

Os cinco princípios integrantes do Manifesto Ágil são:

● Indivíduos e interações sobre processos e ferramentas: Os desenvolvedores e

suas interações são mais importantes do que os processos e ferramentas.
● Software funcionando sobre documentação abrangente: Software funcionando é
mais importante do que documentação abrangente.
● Colaboração com o cliente sobre negociação de contratos: Colaboração com o
cliente é mais importante do que negociação de contratos.
● Responder a mudanças sobre seguir um plano: Responder a mudanças é mais
importante do que seguir um plano.
● Software em funcionamento entregue frequentemente: Software em
funcionamento deve ser entregue frequentemente, de preferência semanas ou
até mesmo dias.

Esses princípios refletem a crença de que os métodos ágeis são mais eficazes para o
desenvolvimento de software do que os métodos tradicionais. Os métodos ágeis
enfatizam a colaboração, a flexibilidade e a entrega de valor ao cliente.

30. Descreva a prática da programação em pares no XP e apresente

vantagens/desvantagens.
A programação em pares é uma prática de desenvolvimento de software em que dois
desenvolvedores trabalham juntos no mesmo computador, revezando-se na escrita de
código. É uma das práticas mais importantes do Extreme Programming (XP), um
método ágil de desenvolvimento de software.
Vantagens da programação em pares:

● Melhor qualidade do código: A programação em pares ajuda a identificar e

corrigir bugs mais rapidamente.
● Maior produtividade: A programação em pares pode aumentar a produtividade
dos desenvolvedores, pois eles podem ajudar uns aos outros a resolver
problemas.
● Melhor comunicação: A programação em pares ajuda a melhorar a comunicação
entre os desenvolvedores.
● Maior aprendizado: A programação em pares é uma ótima maneira de aprender
novas habilidades e técnicas.

Desvantagens da programação em pares:

● Pode ser mais lenta: A programação em pares pode levar mais tempo do que a
programação individual.
● Exige um esforço extra: A programação em pares requer que os
desenvolvedores estejam dispostos a trabalhar juntos e a compartilhar ideias.
● Pode ser desconfortável: A programação em pares pode ser desconfortável para
alguns desenvolvedores, especialmente aqueles que são introvertidos ou que
preferem trabalhar sozinhos.

31. Descreva a prática Test Driven Design (TDD) no XP.

O Test Driven Design (TDD) é uma prática de desenvolvimento de software em que os
testes são escritos antes do código. É uma das práticas mais importantes do Extreme
Programming (XP), um método ágil de desenvolvimento de software.

No TDD, o processo de desenvolvimento ocorre em ciclos curtos, chamados de

iterações. Em cada iteração, os desenvolvedores seguem as seguintes etapas:

1. Escrever um teste: O primeiro passo é escrever um teste que falha. O teste deve
descrever o comportamento esperado do código.
2. Faça o código passar no teste: O próximo passo é escrever o código necessário
para fazer o teste passar.
3. Refatorar o código: O código pode ser refatorado para melhorar sua qualidade e
legibilidade.
O TDD tem várias vantagens, incluindo:

● Melhor qualidade do código: O TDD ajuda a garantir que o código esteja correto
e funcional.
● Maior produtividade: O TDD pode aumentar a produtividade dos
desenvolvedores, pois eles podem identificar e corrigir bugs mais rapidamente.
● Menor custo de manutenção: O TDD pode ajudar a reduzir o custo de
manutenção do software, pois o código é mais fácil de entender e modificar.

No XP, o TDD é usado para garantir a qualidade do código e para facilitar a manutenção
do software. O TDD também é usado para melhorar a comunicação entre os
desenvolvedores, pois eles precisam trabalhar juntos para escrever os testes.

32. Defina e exemplifique história de usuário (user story) e explique como são usadas
no XP.
Uma história de usuário (user story) é uma descrição informal de uma funcionalidade ou
requisito de um sistema de software, escrita da perspectiva do usuário. É uma das
práticas mais importantes do Extreme Programming (XP), um método ágil de
desenvolvimento de software.

Uma história de usuário típica tem a seguinte estrutura:

Como [perfil de usuário],

Eu quero [ação],
Para que [resultado].

Por exemplo, uma história de usuário para um sistema de e-commerce pode ser:

Como um cliente,
Eu quero adicionar um produto ao meu carrinho de compras,
Para que eu possa comprar o produto.

As histórias de usuário são usadas no XP para comunicar os requisitos do software aos

desenvolvedores. Elas são escritas em linguagem natural, o que as torna fáceis de
entender para todos os envolvidos no projeto.
As histórias de usuário são usadas no XP de várias maneiras, incluindo:

● Planejamento: As histórias de usuário são usadas para definir o escopo do

projeto e para priorizar as funcionalidades que serão desenvolvidas.
● Desenvolvimento: As histórias de usuário são usadas para orientar o
desenvolvimento do software.
● Testes: As histórias de usuário são usadas para definir os testes que serão
realizados para validar o software.

Vantagens das histórias de usuário:

● Facilidade de compreensão: As histórias de usuário são escritas em linguagem

natural, o que as torna fáceis de entender para todos os envolvidos no projeto.
● Foco no usuário: As histórias de usuário são escritas da perspectiva do usuário,
o que ajuda a garantir que o software atenda às necessidades dos usuários.
● Flexibilidade: As histórias de usuário podem ser alteradas ou priorizadas
conforme necessário.

Desvantagens das histórias de usuário:

● Podem ser imprecisas: As histórias de usuário são escritas de forma informal, o

que pode levar a imprecisões.
● Podem ser incompletas: As histórias de usuário podem não incluir todas as
informações necessárias para o desenvolvimento do software.

Conclusão:

As histórias de usuário são uma ferramenta eficaz para o desenvolvimento de software

ágil. Elas ajudam a garantir que o software atenda às necessidades dos usuários e que
seja desenvolvido de forma eficaz e eficiente.

33. Defina Sprint, Sprint Planning, Daily Scrum, Sprint Review e Sprint Retrospective
no SCRUM.
Sprint

Um Sprint é um período de tempo fixo, geralmente de duas semanas, durante o qual um

time Scrum trabalha para entregar um incremento de produto funcional. Os Sprints são
usados para dividir o trabalho em partes menores e mais gerenciáveis, e para garantir
que o produto esteja sendo desenvolvido de forma iterativa e incremental.

Sprint Planning

O Sprint Planning é uma reunião realizada no início de cada Sprint para definir o escopo
do Sprint e planejar o trabalho. A reunião é realizada com a participação do time Scrum,
do Product Owner e do Scrum Master.

Daily Scrum

O Daily Scrum é uma reunião diária realizada pelo time Scrum para discutir o progresso
do Sprint, identificar quaisquer impedimentos e planejar o trabalho para o dia seguinte. A
reunião é geralmente de curta duração, geralmente de 15 minutos.

Sprint Review

A Sprint Review é uma reunião realizada no final de cada Sprint para demonstrar o
incremento de produto desenvolvido e obter feedback do Product Owner e dos
stakeholders. A reunião é usada para garantir que o produto esteja atendendo às
necessidades dos usuários e que o time Scrum esteja no caminho certo para entregar o
produto final.

Sprint Retrospective

A Sprint Retrospective é uma reunião realizada após a Sprint Review para identificar o
que foi bem, o que pode ser melhorado e planejar ações para o próximo Sprint. A
reunião é usada para ajudar o time Scrum a aprender e melhorar com o tempo.

Como os eventos do Scrum se relacionam

Os eventos do Scrum são projetados para funcionar juntos para ajudar o time Scrum a
entregar um produto de alta qualidade de forma iterativa e incremental.

O Sprint Planning é usado para definir o escopo do Sprint e planejar o trabalho. O Daily
Scrum é usado para acompanhar o progresso do Sprint e identificar quaisquer
impedimentos. A Sprint Review é usada para demonstrar o incremento de produto
desenvolvido e obter feedback do Product Owner e dos stakeholders. A Sprint
Retrospective é usada para identificar o que foi bem, o que pode ser melhorado e
planejar ações para o próximo Sprint.

Exemplo

Um time Scrum está desenvolvendo um novo sistema de gerenciamento de clientes. O

time decide usar Sprints de duas semanas.

No início de cada Sprint, o time Scrum realiza uma reunião de Sprint Planning. Na
reunião, o time discute os requisitos do Sprint com o Product Owner e prioriza o
trabalho. O time também cria um plano de Sprint, que descreve como o trabalho será
realizado.

Durante o Sprint, o time Scrum realiza uma reunião diária de Daily Scrum. Na reunião, o
time discute o progresso do Sprint, identifica quaisquer impedimentos e planeja o
trabalho para o dia seguinte.

No final do Sprint, o time Scrum realiza uma reunião de Sprint Review. Na reunião, o
time demonstra o incremento de produto desenvolvido ao Product Owner e aos
stakeholders. O time também coleta feedback sobre o incremento.

Após a Sprint Review, o time Scrum realiza uma reunião de Sprint Retrospective. Na
reunião, o time discute o que foi bem no Sprint, o que pode ser melhorado e planeja
ações para o próximo Sprint.

O time Scrum repete esse processo a cada Sprint até que o produto final esteja
concluído.

34. Descreva o método Kanban atentando para elementos que o integram.

O Kanban é um método de gerenciamento de fluxo de trabalho que se concentra na
visualização do trabalho, na restrição do trabalho em andamento e na melhoria
contínua. Ele é baseado em três princípios básicos:

● Visibilidade: O trabalho deve ser visualizado de forma clara e concisa para que
todos possam entender o seu status.
 ● Limitação do trabalho em andamento: O trabalho em andamento deve ser
limitado para evitar sobrecarga e garantir que o trabalho seja concluído de forma
eficiente.
● Melhoria contínua: O processo deve ser continuamente avaliado e melhorado
para aumentar a eficiência e a produtividade.

Elementos do Kanban

O Kanban é um método flexível que pode ser adaptado a uma ampla gama de projetos
e equipes. No entanto, existem alguns elementos comuns que são frequentemente
usados:

● Kanban board: Um kanban board é uma ferramenta visual que ajuda a visualizar
o trabalho. Ele geralmente consiste em um quadro com três ou mais colunas,
representando as diferentes etapas do fluxo de trabalho.
● Cartões de trabalho: Os cartões de trabalho representam unidades de trabalho
individuais. Eles geralmente incluem informações como o título do trabalho, a
descrição do trabalho, a prioridade do trabalho e o estado do trabalho.
● Regras de fluxo: As regras de fluxo definem como o trabalho é movido pelo
kanban board. Elas geralmente incluem regras para adicionar trabalho, mover
trabalho e remover trabalho do kanban board.

Vantagens do Kanban

O Kanban oferece uma série de vantagens, incluindo:

● Visibilidade: O Kanban torna o trabalho mais visível, o que ajuda a evitar

gargalos e atrasos.
● Eficiência: O Kanban ajuda a limitar o trabalho em andamento, o que pode
aumentar a eficiência e a produtividade.
● Melhoria contínua: O Kanban incentiva a melhoria contínua, o que pode ajudar a
melhorar o processo de desenvolvimento.

Desvantagens do Kanban

O Kanban também apresenta algumas desvantagens, incluindo:

 ● Pode ser difícil de implementar: O Kanban pode ser difícil de implementar em
equipes que não estão acostumadas a trabalhar de forma ágil.
● Pode não ser adequado para todos os projetos: O Kanban pode não ser
adequado para projetos que requerem um alto nível de previsibilidade.

35. Descreva elementos de um processo para gerenciamento de projeto pessoal (PXP,

PSP etc.).
Um processo de gerenciamento de projeto pessoal (PXP, PSP etc.) é um conjunto de
etapas e atividades que podem ser usadas para gerenciar projetos pessoais. Ele pode
ajudar a garantir que os projetos pessoais sejam concluídos com sucesso, dentro do
prazo e do orçamento.

Os elementos de um processo de PXP incluem:

● Definição do projeto: O primeiro passo é definir o projeto. Isso inclui definir o

objetivo do projeto, os requisitos do projeto e o escopo do projeto.
● Planejamento do projeto: O próximo passo é planejar o projeto. Isso inclui criar
um cronograma, um orçamento e um plano de comunicação.
● Execução do projeto: O terceiro passo é executar o projeto. Isso inclui realizar o
trabalho, acompanhar o progresso e gerenciar mudanças.
● Monitoramento e controle do projeto: O quarto passo é monitorar e controlar o
projeto. Isso inclui acompanhar o progresso, identificar quaisquer problemas e
tomar medidas corretivas.
● Encerramento do projeto: O último passo é encerrar o projeto. Isso inclui
documentar o projeto, revisar o projeto e celebrar o sucesso.

Além desses elementos básicos, um processo de PXP também pode incluir as seguintes
atividades:

● Gerenciamento de riscos: O gerenciamento de riscos envolve identificar e mitigar

os riscos que podem afetar o projeto.
● Gerenciamento de qualidade: O gerenciamento de qualidade envolve garantir
que o projeto atenda aos requisitos de qualidade.
● Gerenciamento de mudanças: O gerenciamento de mudanças envolve
documentar e gerenciar as mudanças que ocorrem durante o projeto.
O processo de PXP pode ser adaptado às necessidades específicas do projeto pessoal.
No entanto, seguir um processo estruturado pode ajudar a aumentar as chances de
sucesso do projeto.

Aqui estão algumas dicas para criar um processo de PXP eficaz:

● Seja realista: Ao definir o escopo do projeto, seja realista sobre o que você pode
realizar.
● Seja flexível: Esteja preparado para fazer alterações no projeto conforme
necessário.
● Comunique-se regularmente: Mantenha as partes interessadas informadas sobre
o progresso do projeto.
● Comemore as conquistas: Reconheça as conquistas ao longo do caminho.

Ao seguir essas dicas, você pode criar um processo de PXP que o ajudará a gerenciar
seus projetos pessoais com sucesso.

36. Defina protótipo throw-away e apresente exemplo de uso do mesmo.

Um protótipo throw-away é um protótipo que é descartado após o seu uso. Ele é usado
para validar um conceito ou ideia, mas não é destinado a ser um produto final.

Um exemplo de uso de um protótipo throw-away é a criação de um protótipo de um novo

produto de software. O protótipo pode ser usado para validar a funcionalidade do
produto e para obter feedback dos usuários. Após o recebimento do feedback, o
protótipo pode ser descartado e o desenvolvimento do produto pode ser continuado

37. Contraste e exemplifique requisito funcional com requisito não funcional.

Os requisitos funcionais e não funcionais são dois tipos de requisitos que são usados
para descrever um sistema de software. Os requisitos funcionais descrevem o que o
sistema deve fazer, enquanto os requisitos não funcionais descrevem como o sistema
deve funcionar.

Requisitos funcionais

Os requisitos funcionais definem o que o sistema deve fazer. Eles descrevem as

funcionalidades que o sistema deve fornecer aos usuários. Os requisitos funcionais são
geralmente expressos em linguagem natural, mas podem também ser expressos em
forma de diagramas ou especificações técnicas.

Exemplos de requisitos funcionais incluem:

● Um sistema de e-commerce deve permitir que os usuários comprem produtos

online.
● Um sistema de gerenciamento de banco de dados deve permitir que os usuários
consultem, atualizem e excluam dados.
● Um sistema de controle de tráfego aéreo deve permitir que os controladores
aéreos monitorem e controlem o tráfego aéreo.

Requisitos não funcionais

Os requisitos não funcionais definem como o sistema deve funcionar. Eles descrevem
as características ou qualidades do sistema, como desempenho, segurança, usabilidade
e confiabilidade. Os requisitos não funcionais são geralmente expressos em termos de
objetivos ou metas.

Exemplos de requisitos não funcionais incluem:

● O sistema deve ser capaz de processar 1000 transações por minuto.

● O sistema deve ser seguro contra ataques cibernéticos.
● O sistema deve ser fácil de usar.
● O sistema deve ser confiável e disponível 24 horas por dia, 7 dias por semana.

Contraste

Os requisitos funcionais e não funcionais podem ser contrastados da seguinte forma:

Caracterí Requisitos funcionais Requisitos não

stica funcionais

Descriçã O que o sistema deve fazer Como o sistema deve

o funcionar
 Expressã Linguagem natural, Objetivos ou metas
o diagramas ou
especificações técnicas

Exemplo Um sistema de e-commerce O sistema deve ser

s deve permitir que os capaz de processar
usuários comprem produtos 1000 transações por
online. minuto.

38. Contraste e exemplifique requisito de usuário com requisito de sistema.

Requisitos de usuário e requisitos de sistema são dois tipos de requisitos que são
usados para descrever um sistema de software. Os requisitos de usuário descrevem as
necessidades dos usuários, enquanto os requisitos de sistema descrevem como o
sistema deve ser implementado para atender às necessidades dos usuários.

Requisitos de usuário

Os requisitos de usuário descrevem o que os usuários precisam ou querem que o

sistema faça. Eles são escritos da perspectiva do usuário e são geralmente expressos
em linguagem natural. Os requisitos de usuário podem ser divididos em dois tipos:

● Requisitos de domínio: descrevem as necessidades dos usuários em termos do

domínio do problema que o sistema está sendo desenvolvido para resolver.
● Requisitos de interação: descrevem como os usuários interagem com o sistema.

Exemplos de requisitos de usuário incluem:

● Um usuário deve ser capaz de criar uma conta no sistema.

● Um usuário deve ser capaz de pesquisar produtos no sistema.
● Um usuário deve ser capaz de comprar produtos no sistema.

Requisitos de sistema

Os requisitos de sistema descrevem como o sistema deve ser implementado para

atender às necessidades dos usuários. Eles são escritos da perspectiva do
desenvolvedor e são geralmente expressos em linguagem técnica. Os requisitos de
sistema podem ser divididos em dois tipos:

● Requisitos funcionais: descrevem o que o sistema deve fazer.

● Requisitos não funcionais: descrevem como o sistema deve funcionar.

Exemplos de requisitos de sistema incluem:

● O sistema deve ser capaz de processar 1000 transações por minuto.

● O sistema deve ser seguro contra ataques cibernéticos.
● O sistema deve ser fácil de usar.
● O sistema deve ser confiável e disponível 24 horas por dia, 7 dias por semana.

Contraste

Os requisitos de usuário e os requisitos de sistema podem ser contrastados da seguinte

forma:

Caracterí Requisitos de usuário Requisitos de sistema

stica

Descriçã As necessidades dos Como o sistema deve ser

o usuários implementado

Expressã Linguagem natural Linguagem técnica

o

Ponto de Usuário Desenvolvedor

vista

Exemplos Um usuário deve ser O sistema deve ser capaz

capaz de criar uma de processar 1000
conta no sistema. transações por minuto.

Importância
Os requisitos de usuário e os requisitos de sistema são ambos importantes para o
desenvolvimento de um sistema de software. Os requisitos de usuário são necessários
para garantir que o sistema atenda às necessidades dos usuários, enquanto os
requisitos de sistema são necessários para garantir que o sistema possa ser
implementado de forma eficaz e eficiente.

Exemplos

Considere um sistema de e-commerce. Um requisito de usuário para este sistema pode

ser:

Um usuário deve ser capaz de criar uma conta no sistema.

Este requisito é escrito da perspectiva do usuário e é expresso em linguagem natural.

Ele descreve uma necessidade que o usuário tem, que é a capacidade de criar uma
conta no sistema.

O requisito de sistema correspondente para este requisito de usuário pode ser:

O sistema deve fornecer uma funcionalidade para criar uma conta.

Este requisito é escrito da perspectiva do desenvolvedor e é expresso em linguagem

técnica. Ele descreve como o sistema deve ser implementado para atender à
necessidade do usuário de criar uma conta.

É importante que os requisitos de usuário e os requisitos de sistema sejam alinhados.

Isso significa que os requisitos de sistema devem ser projetados para atender às
necessidades dos usuários.

39. Relacione elementos típicos do documento visão e escopo (vision and scope).
O documento de visão e escopo (vision and scope) é um documento que descreve a
visão do produto e o escopo do projeto. Ele é usado para comunicar a visão do produto
para as partes interessadas e para garantir que todos estejam alinhados sobre o que
será desenvolvido.
Os elementos típicos do documento de visão e escopo incluem:

● Visão do produto: Uma descrição concisa da visão do produto, incluindo seus

objetivos, benefícios e público-alvo.
● Escopo do projeto: Uma descrição detalhada do que será incluído no projeto,
incluindo os recursos, funcionalidades e requisitos.
● Escopo do produto: Uma descrição detalhada do que será incluído no produto,
incluindo os recursos, funcionalidades e requisitos.
● Critérios de aceitação: Uma descrição dos critérios que serão usados para
determinar se o produto atende às expectativas das partes interessadas.
● Plano de comunicação: Um plano para comunicar a visão e o escopo do produto
para as partes interessadas.

Explicação de cada elemento:

● Visão do produto: A visão do produto é uma descrição concisa da visão do

produto, incluindo seus objetivos, benefícios e público-alvo. Ela deve ser clara e
concisa, e deve ser fácil de entender para as partes interessadas.
● Escopo do projeto: O escopo do projeto é uma descrição detalhada do que será
incluído no projeto, incluindo os recursos, funcionalidades e requisitos. Ele deve
ser preciso e completo, e deve ser acordado por todas as partes interessadas.
● Escopo do produto: O escopo do produto é uma descrição detalhada do que será
incluído no produto, incluindo os recursos, funcionalidades e requisitos. Ele deve
ser baseado no escopo do projeto, mas pode ser ajustado ao longo do
desenvolvimento do produto.
● Critérios de aceitação: Os critérios de aceitação são uma descrição dos critérios
que serão usados para determinar se o produto atende às expectativas das
partes interessadas. Eles devem ser claros e objetivos, e devem ser acordados
por todas as partes interessadas.
● Plano de comunicação: O plano de comunicação é um plano para comunicar a
visão e o escopo do produto para as partes interessadas. Ele deve descrever
como a comunicação será realizada, quem será contatado e quando a
comunicação será realizada.

40. Relacione elementos típicos do documento especificação de requisitos de

software (SRS).
A especificação de requisitos de software (SRS) é um documento que descreve os
requisitos de um sistema de software. Ele é usado para comunicar os requisitos do
sistema para as partes interessadas e para garantir que todos estejam alinhados sobre
o que o sistema deve fazer.

Os elementos típicos de um SRS incluem:

● Introdução: Uma introdução que fornece uma visão geral do SRS e seus
objetivos.
● Visão geral do sistema: Uma descrição geral do sistema, incluindo seus
objetivos, funções e usuários.
● Requisitos funcionais: Uma descrição dos requisitos funcionais do sistema, ou
seja, o que o sistema deve fazer.
● Requisitos não funcionais: Uma descrição dos requisitos não funcionais do
sistema, ou seja, como o sistema deve funcionar.
● Definições e siglas: Uma lista de definições e siglas usadas no SRS.
● Anexos: Anexos que fornecem informações adicionais sobre o SRS, como
diagramas, especificações técnicas ou formulários.

Explicação de cada elemento:

● Introdução: A introdução fornece uma visão geral do SRS e seus objetivos. Ela
deve incluir informações como o propósito do SRS, o público-alvo e o escopo do
SRS.
● Visão geral do sistema: A visão geral do sistema fornece uma descrição geral do
sistema, incluindo seus objetivos, funções e usuários. Ela deve fornecer uma
visão geral do sistema para as partes interessadas, sem entrar em detalhes
sobre os requisitos.
● Requisitos funcionais: Os requisitos funcionais descrevem o que o sistema deve
fazer. Eles devem ser claros, concisos e completos.
● Requisitos não funcionais: Os requisitos não funcionais descrevem como o
sistema deve funcionar. Eles incluem requisitos como desempenho, segurança,
usabilidade e confiabilidade.
● Definições e siglas: As definições e siglas são usadas para fornecer clareza e
precisão ao SRS.
● Anexos: Os anexos fornecem informações adicionais sobre o SRS, como
diagramas, especificações técnicas ou formulários.
41. Defina e exemplifique regra de negócio.
Uma regra de negócio é uma declaração que define ou restringe alguma atividade,
processo ou operação dentro de uma organização ou sistema de software. Essas regras
são estabelecidas para orientar e controlar o comportamento de uma empresa, sistema ou
processo, a fim de alcançar seus objetivos e cumprir requisitos legais ou regulatórios. As
regras de negócio podem ser aplicadas em diversos contextos, desde o funcionamento de
uma empresa até o desenvolvimento de software. Aqui está uma definição acompanhada
de um exemplo:

Definição de Regra de Negócio:

Uma regra de negócio é uma diretriz ou restrição que define como uma organização opera,
toma decisões ou executa tarefas específicas, com o objetivo de atingir seus objetivos
comerciais, legais ou regulatórios.

Exemplo de Regra de Negócio:

Imagine uma loja online que vende produtos eletrônicos. Uma regra de negócio para essa
loja poderia ser:

Regra de Negócio: "Os clientes menores de 18 anos não podem fazer compras de
produtos restritos a maiores de idade."

Nesse exemplo, a regra de negócio estabelece uma restrição que impede que clientes com
menos de 18 anos comprem produtos que são restritos a maiores de idade, como produtos
de classificação etária para adultos. Essa regra é implementada para cumprir
regulamentações legais e para garantir que a loja esteja em conformidade com as leis de
venda de produtos restritos. Ela também orienta o desenvolvimento de sistemas de
gerenciamento de pedidos e carrinhos de compras online para verificar a idade dos clientes
antes de permitir que eles comprem esses produtos.

As regras de negócio são importantes porque ajudam a manter a consistência e a

integridade das operações de negócios e sistemas de software, garantindo que eles
funcionem de acordo com as políticas e regulamentos da empresa. Elas também servem
como base para o design e desenvolvimento de sistemas de software que automatizam ou
suportam essas regras, garantindo que sejam aplicadas de forma consistente e precisa.

42. Relacione artefatos e atividades típicas de processo de levantamento de

requisitos.
O processo de levantamento de requisitos é uma atividade essencial para o
desenvolvimento de um sistema de software de sucesso. Ele é responsável por coletar e
documentar os requisitos do sistema, que são as necessidades que o sistema deve
atender.

Os artefatos e as atividades típicas de um processo de levantamento de requisitos

podem ser relacionados da seguinte forma:

Artefato Atividade

Plano de levantamento de Definir escopo do levantamento

requisitos

Requisitos de usuário Identificar e documentar as necessidades

dos usuários

Requisitos de negócio Identificar e documentar as necessidades

do negócio

Requisitos funcionais Descrever o que o sistema deve fazer

Requisitos não funcionais Descrever como o sistema deve

funcionar

Prototipos Visualizar e validar os requisitos

Validação de requisitos Obter feedback das partes interessadas

43. Relacione artefatos e atividades típicas de processo de análise de requisitos.

O processo de análise de requisitos é uma atividade essencial para o desenvolvimento
de um sistema de software de sucesso. Ele é responsável por analisar os requisitos
coletados no processo de levantamento de requisitos para garantir que sejam
completos, precisos e consistentes.
Os artefatos e as atividades típicas de um processo de análise de requisitos podem ser
relacionados da seguinte forma:

Artefato Atividade

Plano de análise de Definir escopo da análise

requisitos

Requisitos Verificar a completude, precisão e

documentados consistência dos requisitos

Validação de requisitos Obter feedback das partes interessadas

Modelos de análise de Criar modelos para visualizar e entender os

requisitos requisitos

Prototipos Visualizar e validar os requisitos

44. Relacione artefatos e atividades típicas de processo de gerenciamento de

requisitos.
O gerenciamento de requisitos é um processo que envolve a identificação, coleta,
análise, documentação, rastreamento, validação e gerenciamento de mudanças dos
requisitos de um sistema de software.

Os artefatos e as atividades típicas de um processo de gerenciamento de requisitos

podem ser relacionados da seguinte forma:

Artefato Atividade

Plano de gerenciamento de Definir escopo do gerenciamento de

requisitos requisitos
 Requisitos documentados Documentar os requisitos do sistema

Validação de requisitos Obter feedback das partes

interessadas

Gerenciamento de mudanças Gerenciar as mudanças nos

de requisitos requisitos

Rastreamento de requisitos Rastrear o status dos requisitos

Comunicação de requisitos Comunicar os requisitos para as

partes interessadas

45. Descreva elementos de modelo de casos de uso

Os elementos de um modelo de casos de uso são os componentes que descrevem as

interações entre os usuários e o sistema. Eles são usados para documentar os
requisitos funcionais do sistema.

Os elementos principais de um modelo de casos de uso são:

● Atores: Representam os usuários ou sistemas que interagem com o sistema.

● Casos de uso: Representam as interações entre um ator e o sistema.
● Premissas e pós-condições: Definem as condições que devem ser atendidas
antes e depois de um caso de uso ser executado.
● Fluxos de eventos: Descrevem a sequência de eventos que ocorrem quando um
caso de uso é executado.
● Extensões e exceções: Descrevem os comportamentos alternativos que podem
ocorrer durante a execução de um caso de uso.

Atores

Os atores são os usuários ou sistemas que interagem com o sistema. Eles podem ser
pessoas, organizações ou sistemas externos.
Os atores são representados por um símbolo de um homem ou mulher, com o nome do
ator abaixo do símbolo.

Casos de uso

Os casos de uso são as interações entre um ator e o sistema. Eles descrevem o que o
ator faz para alcançar um objetivo.

Os casos de uso são representados por um símbolo de um oval, com o nome do caso
de uso dentro do oval.

Premissas e pós-condições

As premissas são as condições que devem ser atendidas antes de um caso de uso ser
executado. As pós-condições são as condições que devem ser atendidas depois de um
caso de uso ser executado.

As premissas e pós-condições são descritas como texto dentro do caso de uso.

Fluxos de eventos

Os fluxos de eventos descrevem a sequência de eventos que ocorrem quando um caso

de uso é executado. Eles são divididos em fluxo principal e fluxos alternativos.

O fluxo principal é a sequência de eventos que ocorre normalmente. Os fluxos

alternativos são os comportamentos alternativos que podem ocorrer durante a execução
do caso de uso.

Os fluxos de eventos são descritos como texto dentro do caso de uso.

Extensões e exceções

As extensões são os comportamentos alternativos que podem ocorrer durante a

execução do fluxo principal. As exceções são os comportamentos que ocorrem quando
uma condição inesperada ocorre durante a execução do caso de uso.
As extensões e exceções são representadas por símbolos de seta que apontam para o
fluxo de eventos principal.