1) O software não se deteriora

da mesma forma que o

hardware, mas pode sofrer
deterioração devido a várias
razões, incluindo:

Mudanças de ambiente: À
medida que o ambiente de
execução do software muda
(atualizações no sistema
operacional, bibliotecas,
hardware), o software pode não
funcionar corretamente,
resultando em deterioração.

Mudanças nos requisitos: À

medida que os requisitos do
software evoluem, se o software
não for atualizado para atender a
esses novos requisitos, ele pode
se tornar obsoleto e menos
eficaz.

Erros acumulados: Com o

tempo, podem ocorrer erros
acumulados à medida que mais
partes do software são
modificadas.
Esses erros não corrigidos
podem levar a uma deterioração
no desempenho e na
confiabilidade do software.

Tecnologia ultrapassada: À
medida que as tecnologias
avançam, o software
desenvolvido com base em
tecnologias mais antigas pode se
tornar incompatível e não
funcional em sistemas
modernos.

Segurança: A falta de
atualizações de segurança pode
tornar o software vulnerável a
ataques, resultando em
deterioração de sua integridade
e confiabilidade.

Para evitar a deterioração do

software, é importante manter a
manutenção adequada,
atualizações regulares e
correções de bugs ao longo do
tempo.
2) Softwares legados são
programas de computador ou
sistemas que foram
desenvolvidos em tecnologias
mais antigas e que, com o
tempo, se tornaram obsoletos ou
descontinuados, mas ainda são
utilizados em ambientes
empresariais ou em sistemas
críticos. Esses softwares
geralmente são considerados
"legado" porque foram
substituídos por sistemas mais
modernos, mas ainda são
mantidos por razões práticas ou
históricas.

Características dos softwares

legados incluem:
Tecnologia obsoleta
Falta de documentação
Dificuldade de manutenção
Risco de segurança
Custos de migração elevados

Apesar dos desafios, muitas

organizações
continuam a usar softwares
legados devido a restrições
financeiras, dependência crítica
de sistemas antigos ou
simplesmente porque a migração
é um processo complexo. A
gestão adequada de softwares
legados envolve medidas como
manutenção cuidadosa,
isolamento de sistemas,
atualizações de segurança e
eventual planejamento de
migração para tecnologias mais
modernas.

3) O surgimento da engenharia
de software foi impulsionado por
uma série de fatores que
destacaram a necessidade de
abordar o desenvolvimento de
software de forma mais
sistemática e profissional. Alguns
dos principais motivos incluem:

Complexidade crescente:
Conforme os sistemas de
software se tornaram mais
complexos, tornou-se evidente
que
abordagens informais e ad hoc
não eram suficientes para
garantir a qualidade e a
confiabilidade dos softwares
produzidos.

Crescimento da demanda: À
medida que a dependência de
software em várias indústrias
aumentava, havia uma
necessidade crescente de
desenvolver software de maneira
eficiente e confiável para atender
às demandas do mercado.

Problemas de qualidade: O
desenvolvimento de software
frequentemente resultava em
produtos com muitos defeitos e
problemas. Isso levou à perda de
tempo, recursos e dinheiro,
incentivando a busca por
melhores práticas.

Custos e atrasos: Projetos de

software frequentemente
excediam seus prazos e
orçamentos, causando
insatisfação entre clientes e
gerentes. A engenharia de
software visa melhorar a
estimativa de custos e prazos.

Reutilização de código: A
necessidade de reutilizar código
para economizar tempo e
recursos levou ao
desenvolvimento de métodos e
técnicas para criar bibliotecas de
software reutilizáveis.

Padronização: Para melhorar a

colaboração e a
interoperabilidade entre
sistemas, foram necessárias
normas e padrões na criação de
software.

Pesquisa e educação: O
reconhecimento da importância
do treinamento formal e
pesquisa em métodos de
desenvolvimento de software
contribuiu para o surgimento da
engenharia de software como
disciplina acadêmica.

Riscos de negócios: Empresas

perceberam que o software era
um ativo valioso e, portanto,
precisavam de abordagens mais
profissionais para gerenciar
riscos associados ao
desenvolvimento e manutenção
de software.

No final da década de 1960 e

início da década de 1970, o
termo "engenharia de software"
foi cunhado e se tornou uma
disciplina formal, com o objetivo
de aplicar princípios da
engenharia tradicional ao
desenvolvimento de software.
Isso levou ao desenvolvimento
de metodologias, padrões e boas
práticas que continuam a evoluir
para atender às necessidades
em constante mudança da
indústria de software.
4) A "crise do software" foi um
termo cunhado na década de
1960 para descrever os desafios
e problemas significativos
enfrentados pela indústria de
software naquela época. Essa
crise foi caracterizada por uma
série de problemas que incluíam
atrasos significativos, estouro de
orçamento, qualidade
insatisfatória e dificuldades no
desenvolvimento de software.
Alguns dos principais problemas
que levaram à crise do software
incluíam:

Complexidade crescente: Os
sistemas de software estavam se
tornando cada vez mais
complexos, tornando difícil a
compreensão e o gerenciamento
eficaz de projetos.

Falta de métodos e processos: A

indústria de software estava
operando sem
metodologias sólidas e
processos de desenvolvimento
estabelecidos, o que resultava
em abordagens ad hoc e falta de
consistência.

Mão de obra insuficiente e

inexperiente: Havia uma
carência de profissionais de
software qualificados e
experientes para atender à
crescente demanda por
desenvolvimento de software.

Mudanças de requisitos
frequentes: Os clientes muitas
vezes mudavam os requisitos do
software durante o
desenvolvimento, o que causava
atrasos e aumento nos custos.

Falta de reutilização de código: A

reutilização de código não era
uma prática comum, levando a
redundâncias e esforços
duplicados.
Para enfrentar a crise do
software, várias soluções foram
propostas e implementadas ao
longo do tempo:

Desenvolvimento de
metodologias: Surgiram diversas
metodologias de
desenvolvimento de software,
como o modelo em cascata e,
mais tarde, abordagens ágeis,
que visavam trazer ordem e
estrutura ao processo de
desenvolvimento.

Padronização e normas: A
criação de padrões e normas
para o desenvolvimento de
software ajudou a estabelecer
práticas comuns e melhorar a
qualidade.

Melhoria na educação: Foram

criados programas educacionais
para formar mais profissionais de
software qualificados.
Ferramentas de
desenvolvimento: O
desenvolvimento de ferramentas
de software, como ambientes de
desenvolvimento integrado
(IDEs), auxiliou no
desenvolvimento mais eficiente e
na detecção de erros.

Ênfase na comunicação:
Abordagens ágeis, como Scrum,
enfatizaram a comunicação
próxima com os clientes para
compreender melhor os
requisitos em constante
mudança.

Essas soluções contribuíram

para melhorar a indústria de
software e abordar muitos dos
problemas que levaram à crise.
No entanto, a complexidade do
software moderno continua a ser
um desafio, e a indústria
continua a evoluir em busca de
melhores práticas e abordagens.
5) O mito de que "o único
produto passível de entrega é o
programa em funcionamento"
não reflete a realidade da
engenharia de software de forma
abrangente. Embora o software
funcional seja um componente
crucial no desenvolvimento de
software, ele é apenas uma
parte do processo e da entrega.
A realidade é que a engenharia
de software envolve uma série
de entregas e produtos além do
programa em funcionamento.
Alguns desses produtos e
entregas incluem:

Documentação
Testes
Código-fonte
Protótipos e maquetes
Planos e cronogramas
Artefatos de design
Relatórios de status

Portanto, a engenharia de
software envolve a entrega de
uma variedade de produtos e
informações além do programa
em funcionamento para garantir
o sucesso do projeto, a
compreensão adequada e a
manutenção eficiente do
software. O programa em
funcionamento é apenas uma
parte do quadro completo.

6) Um artefato, no contexto da
engenharia de software e de
muitas outras disciplinas, é um
termo geralmente usado para se
referir a qualquer item,
documento, objeto ou resultado
tangível que é produzido ou
gerado como parte de um
processo ou atividade. Artefatos
são criados para servir a
diferentes propósitos em um
projeto ou em uma disciplina
específica.
Na engenharia de software, por
exemplo, alguns exemplos de
artefatos incluem:

Diagramas de fluxo de dados

Documentação de código
Casos de teste
Diagramas de arquitetura
Protótipos de interface de
usuário
Relatórios de projeto
Código-fonte

Em resumo, artefatos são

produtos tangíveis ou
informações geradas durante o
desenvolvimento ou execução
de um projeto, processo ou
atividade, e eles desempenham
um papel fundamental na
comunicação, documentação e
garantia da qualidade em várias
disciplinas, incluindo a
engenharia de software.

7) Gerenciar projetos de
software é uma
tarefa complexa e influenciada
por vários fatores. Aqui estão
três fatores importantes que
afetam a forma de gerenciar
projetos de software:

1. Complexidade do Software: A
complexidade do software a ser
desenvolvido é um fator crítico.
Projetos de software complexos
exigem abordagens de
gerenciamento mais detalhadas
e planejamento cuidadoso. Isso
pode incluir o uso de
metodologias específicas,
equipes multidisciplinares e uma
análise mais profunda de
requisitos e riscos.
2. Tamanho e Escopo do Projeto:
O tamanho e o escopo do
projeto têm um impacto
significativo na gestão. Projetos
de grande escala geralmente
envolvem mais recursos,
orçamento e tempo.
Portanto, é importante
dimensionar a equipe
corretamente, planejar de forma
eficiente e acompanhar o
progresso de maneira rigorosa.

3. Tecnologia e Inovação: As
tecnologias e ferramentas
usadas no desenvolvimento de
software estão em constante
evolução. Gerenciar projetos de
software significa acompanhar
as últimas tendências
tecnológicas e garantir que a
equipe esteja atualizada. A
introdução de novas tecnologias
pode afetar a velocidade de
desenvolvimento, os requisitos
de treinamento e a viabilidade
técnica do projeto.

Esses fatores, entre outros, têm

um impacto significativo na
forma como os projetos de
software são gerenciados. Os
gerentes de projeto devem
avaliar
cuidadosamente essas variáveis
e ajustar suas estratégias de
gerenciamento para atender às
necessidades específicas de
cada projeto.

8) A chamada "tripla restrição" é

um conceito fundamental na
gerência de projetos, e é
representada pelos três
elementos interdependentes que
podem influenciar um projeto:
escopo, tempo e custo. Esse
conceito é também conhecido
como o "triângulo de ferro" ou
"triângulo de projeto", e a ideia
central é que esses três
elementos estão intrinsecamente
relacionados de uma maneira
que qualquer alteração em um
deles afeta os outros dois. Aqui
está o conceito por trás da tripla
restrição:

1. Escopo: O escopo se refere

ao que o projeto deve alcançar,
ou seja, as
funcionalidades, características e
objetivos específicos que o
projeto visa entregar. Alterar o
escopo do projeto afetará tanto o
tempo quanto o custo. Por
exemplo, adicionar novos
recursos ao escopo geralmente
aumentará o tempo necessário
para concluir o projeto e os
custos associados a ele.

2. Tempo: O tempo é o prazo ou

a duração estimada para concluir
o projeto. Qualquer mudança no
tempo pode impactar o escopo
e/ou o custo. Se você tentar
acelerar um projeto para
encurtar o tempo, pode ser
necessário adicionar mais
recursos (custo adicional) ou
reduzir o escopo para atender ao
novo prazo.

3. Custo: O custo se refere ao

orçamento estimado ou aos
recursos financeiros necessários
para concluir o projeto.
Qualquer alteração nos custos
pode influenciar o escopo e/ou o
tempo. Reduzir os custos pode
exigir a redução do escopo do
projeto ou um cronograma mais
longo, enquanto aumentar os
custos pode permitir um escopo
expandido ou um projeto mais
rápido.

A gestão eficaz de projetos

envolve o equilíbrio dessas três
restrições. O objetivo é alcançar
os objetivos do projeto mantendo
esse equilíbrio e fazendo ajustes
de acordo com as mudanças nas
prioridades do projeto ou nas
circunstâncias. É importante
para os gerentes de projeto
entenderem que fazer alterações
em uma parte do triângulo de
ferro geralmente resultará em
compromissos em outras áreas
para manter o equilíbrio global
do projeto.
9) No gerenciamento de
projetos, várias atividades são
fundamentais para planejar,
executar e controlar o projeto de
forma eficaz. Aqui estão três
atividades essenciais:

1. Definição de Objetivos e
Escopo: Esta atividade envolve a
definição clara dos objetivos do
projeto e o escopo do trabalho
que deve ser realizado para
alcançar esses objetivos. É
fundamental estabelecer o que o
projeto deve entregar e o que
está excluído do escopo. A
definição adequada do escopo é
a base para o planejamento e o
sucesso do projeto.
2. Planejamento do Projeto: O
planejamento é uma atividade
abrangente que inclui a criação
de um cronograma, alocação de
recursos, orçamento,
identificação de riscos,
desenvolvimento de um plano de
comunicação e estabelecimento
de métricas de desempenho. O
plano do projeto serve como um
guia para toda a equipe,
definindo como o projeto será
executado, monitorado e
controlado.

3. Acompanhamento e Controle:
Esta atividade envolve a
monitorização contínua do
progresso do projeto em relação
ao plano. Os gerentes de projeto
devem acompanhar o
andamento, identificar desvios
em relação ao plano original e
tomar medidas corretivas
quando necessário. Isso inclui a
gestão de riscos, a resolução de
problemas, a comunicação com
as partes interessadas e a
garantia de que o projeto
permaneça alinhado com os
objetivos.
Essas atividades são essenciais
em qualquer projeto,
independentemente de seu
tamanho ou complexidade. Elas
ajudam a garantir que o projeto
seja bem definido, planejado e
executado de acordo com as
metas estabelecidas,
minimizando riscos e problemas
ao longo do caminho.

10) As três categorias principais

de riscos em um contexto de
gerenciamento de projetos são:

1. Riscos Conhecidos (ou Riscos

Identificados): Esses são riscos
que a equipe do projeto
identificou, analisou e
documentou durante o
planejamento do projeto. Eles
são chamados de "conhecidos"
porque a equipe está ciente de
sua existência, probabilidade e
impacto. O objetivo é
desenvolver estratégias para
mitigar ou gerenciar
esses riscos, de modo que, se
ocorrerem, o impacto seja
minimizado. Exemplos de riscos
conhecidos incluem requisitos
mal definidos, escassez de
recursos e conflitos de agenda.

2. Riscos Desconhecidos (ou

Riscos Não Identificados): Estes
são riscos que não foram
previstos ou identificados
durante o planejamento do
projeto. Eles são inesperados e
podem surgir à medida que o
projeto avança. A gestão de
riscos desconhecidos envolve a
capacidade de adaptar-se a
situações imprevistas, muitas
vezes por meio de planos de
contingência. Exemplos de
riscos desconhecidos podem
incluir problemas inesperados
com fornecedores, mudanças
repentinas nos requisitos do
cliente ou eventos naturais
inesperados.
3. Riscos de Oportunidade:
Embora os riscos geralmente
sejam vistos de forma negativa,
os riscos de oportunidade
representam situações em que
eventos positivos podem ocorrer,
impactando positivamente o
projeto. Essas são situações em
que algo inesperadamente bom
acontece, como uma economia
de custos inesperada ou uma
oportunidade de mercado
favorável. A gestão de riscos de
oportunidade envolve identificar
e maximizar essas
oportunidades quando elas
surgem.

A gestão de riscos é uma parte

crítica do gerenciamento de
projetos, pois ajuda a equipe do
projeto a estar preparada para
os desafios e oportunidades que
podem surgir durante a
execução do projeto. Isso inclui
não apenas identificar e
documentar riscos, mas também
desenvolver planos
para gerenciá-los de forma
eficaz, minimizando ameaças e
aproveitando oportunidades.

11) O gerenciamento de riscos

em projetos envolve várias
etapas para identificar, avaliar,
responder e monitorar os riscos
ao longo do ciclo de vida do
projeto. Aqui estão as principais
etapas do gerenciamento de
riscos:

1. Identificação de Riscos:
- Identificar e documentar
todos os possíveis riscos que
podem afetar o projeto. Isso
pode ser feito por meio de
reuniões, revisão de
documentos, consulta a
especialistas e análise de lições
aprendidas de projetos
anteriores.

2. Análise de Riscos:
- Avaliar a probabilidade de
ocorrência e
o impacto de cada risco
identificado. Isso ajuda a
priorizar os riscos com base em
sua gravidade e probabilidade,
muitas vezes utilizando uma
matriz de probabilidade-impacto.

3. Planejamento de Resposta a
Riscos:
- Desenvolver estratégias para
lidar com os riscos identificados.
Existem quatro estratégias
principais:
- Mitigação: Implementar
ações para reduzir a
probabilidade ou o impacto do
risco.
- Transferência: Transferir o
risco para terceiros, como
seguradoras ou fornecedores.
- Aceitação: Aceitar o risco,
quando seu impacto é
considerado aceitável ou os
custos de mitigação são
proibitivos.
- Evitação: Evitar o risco,
alterando o plano do projeto para
eliminar a
possibilidade de ocorrência.

4. Implementação de Resposta a
Riscos:
- Colocar em prática as
estratégias de resposta ao risco
definidas. Isso pode envolver a
execução de atividades de
mitigação, a compra de seguros,
a alocação de recursos
adicionais, entre outras ações.

5. Monitoramento e Controle de
Riscos:
- Acompanhar continuamente
os riscos ao longo do projeto
para verificar se eles evoluem
conforme o planejado. Isso inclui
a revisão e atualização regular
do registro de riscos, bem como
a execução das respostas
definidas.

6. Comunicação de Riscos:
- Manter as partes
interessadas informadas sobre o
status dos riscos e
das ações de resposta. A
comunicação eficaz é essencial
para garantir que todos estejam
cientes dos riscos e das medidas
tomadas para mitigá-los.

7. Revisão e Aprendizado:
- Após a conclusão do projeto,
realizar uma revisão final dos
riscos e avaliar o desempenho
do gerenciamento de riscos.
Documentar lições aprendidas
para aplicar em projetos futuros.

Essas etapas formam um ciclo

contínuo de gerenciamento de
riscos que ajuda a equipe do
projeto a identificar, avaliar e
gerenciar os riscos ao longo do
tempo, garantindo que o projeto
esteja preparado para enfrentar
desafios e oportunidades à
medida que eles surgem.

12) A matriz de risco é uma

ferramenta
comumente usada no
gerenciamento de riscos para
avaliar e visualizar os riscos
identificados em um projeto. Ela
é especialmente útil para
entender a gravidade e a
probabilidade de ocorrência de
cada risco. Aqui estão suas
características e utilização:

Características da Matriz de
Risco:

1. Eixos de Probabilidade e
Impacto: A matriz de risco
geralmente tem dois eixos: um
que representa a probabilidade
de ocorrência de um risco (por
exemplo, baixa, média, alta) e
outro que representa o impacto
desse risco no projeto (por
exemplo, baixo, médio, alto).
Esses eixos são escalas que
ajudam a classificar os riscos.

2. Categorias de Risco: Com

base nos
valores de probabilidade e
impacto, os riscos podem ser
categorizados em diferentes
níveis de severidade. Por
exemplo, riscos com alta
probabilidade e alto impacto são
considerados de maior
gravidade, enquanto riscos com
baixa probabilidade e baixo
impacto são menos críticos.

3. Cores ou Classificações: As
células da matriz podem ser
preenchidas com cores ou
classificações para indicar a
gravidade relativa de cada risco.
Isso cria uma representação
visual que ajuda a equipe do
projeto a identificar os riscos
mais críticos.

Utilização da Matriz de Risco:

1. Priorização de Riscos: A
matriz de risco ajuda a equipe do
projeto a priorizar os
riscos, concentrando-se nos que
têm maior probabilidade de
impacto negativo significativo no
projeto. Isso permite que a
equipe concentre seus esforços
de gerenciamento de riscos nos
itens mais críticos.

2. Tomada de Decisões: Ao
visualizar os riscos em uma
matriz, os gerentes de projeto
podem tomar decisões
informadas sobre quais riscos
exigem ações imediatas, como
desenvolver estratégias de
mitigação ou planejar respostas.

3. Comunicação: A matriz de
risco é uma ferramenta eficaz
para comunicar o perfil de risco
do projeto para as partes
interessadas. Ela oferece uma
visão clara dos principais
desafios e oportunidades
relacionados aos riscos.
4. Avaliação Contínua: Durante o
ciclo de vida do projeto, a matriz
de risco pode ser atualizada à
medida que novas informações
se tornam disponíveis ou à
medida que os riscos se
materializam. Isso ajuda a
manter o gerenciamento de
riscos atualizado e adaptado às
circunstâncias do projeto.

Em resumo, a matriz de risco é

uma ferramenta valiosa para
avaliar e comunicar riscos em
um projeto de forma visual e
sistemática. Ela permite que a
equipe do projeto tome decisões
informadas e priorize suas
atividades de gerenciamento de
riscos para garantir o sucesso do
projeto.

13) Vamos definir cada um

desses tipos de requisitos e
fornecer exemplos para cada
um:
a) Requisitos de Usuário: Esses
requisitos descrevem as
funcionalidades e características
do sistema do ponto de vista dos
usuários finais. Eles se
concentram nas necessidades e
expectativas dos usuários e são
frequentemente expressos em
linguagem não técnica. Exemplo:
"O sistema deve permitir que os
usuários façam login usando
suas credenciais de e-mail e
senha."

b) Requisitos de Sistema: Esses

requisitos descrevem as
características e funcionalidades
do sistema como um todo,
incluindo seus componentes e
interações. Eles geralmente são
mais técnicos e detalhados do
que os requisitos de usuário.
Exemplo: "O sistema deve ser
capaz de processar pelo menos
1000
transações por segundo."

c) Requisitos Funcionais: Esses

requisitos especificam as
funções e comportamentos
específicos que o sistema deve
realizar. Eles descrevem o que o
sistema deve fazer em termos de
entradas, processamento e
saídas. Exemplo: "O sistema
deve permitir que os usuários
adicionem produtos ao carrinho
de compras e façam o
checkout."

d) Requisitos Não Funcionais:

Esses requisitos definem as
características que não se
relacionam diretamente com as
funcionalidades específicas, mas
com aspectos gerais do sistema,
como desempenho, segurança,
usabilidade e escalabilidade.
Exemplo: "O sistema deve
responder a todas as
solicitações do usuário em
menos de 2 segundos."
e) Requisito de Produto: Estes
são requisitos que se relacionam
com as características
específicas do produto final a ser
entregue. Exemplo: "O aplicativo
móvel deve ser compatível com
dispositivos iOS e Android."

f) Requisito Organizacional:
Esses requisitos são definidos
pela organização que está
desenvolvendo o sistema e
podem incluir políticas, padrões
e diretrizes que devem ser
seguidos durante o
desenvolvimento. Exemplo: "O
sistema deve seguir os padrões
de codificação da empresa."
g) Requisito Externo: Esses
requisitos são impostos por
fontes externas à organização,
como regulamentos
governamentais, normas da
indústria ou
contratos com clientes. Exemplo:
"O sistema deve cumprir as
regulamentações de privacidade
de dados do país X."

h) Requisitos Inversos: Também

conhecidos como "requisitos
negativos", esses requisitos
descrevem o que o sistema não
deve fazer. Exemplo: "O sistema
não deve permitir que usuários
não autorizados acessem dados
confidenciais."

i) Requisitos Voláteis: São

requisitos que têm uma alta
probabilidade de mudar ao longo
do tempo devido a mudanças
nas necessidades dos usuários
ou nas condições do ambiente.
Exemplo: "Os requisitos de
relatórios podem mudar a cada
trimestre com base nas métricas
de desempenho."
j) Requisitos Estáveis: São
requisitos que são menos
propensos a mudanças e
permanecem relativamente
consistentes ao longo do tempo.
Exemplo: "Os requisitos de
autenticação de usuários
permanecerão inalterados
durante o ciclo de vida do
projeto."

Esses são exemplos dos tipos

de requisitos comuns em
projetos de desenvolvimento de
software, e cada um
desempenha um papel
importante na definição e no
sucesso do projeto.
14) A elicitação é um processo
fundamental no desenvolvimento
de software e no gerenciamento
de projetos, que envolve a coleta
de requisitos e informações
relevantes de várias fontes,
partes interessadas e usuários
para entender e definir com
precisão o que o
sistema ou projeto deve realizar.
É uma etapa crítica, pois
requisitos mal coletados ou mal
compreendidos podem levar a
problemas sérios durante a
implementação e o uso do
software.

Existem várias técnicas que

podem ser usadas durante o
processo de elicitação de
requisitos, dependendo das
circunstâncias e das
necessidades do projeto. Aqui
estão algumas técnicas comuns
de elicitação:

1. Entrevistas: Realizar
entrevistas diretas com partes
interessadas, usuários finais e
especialistas para obter
informações detalhadas sobre
seus requisitos, expectativas e
necessidades.

2. Grupos de Foco (Focus

Groups): Reunir um grupo de
usuários ou partes
interessadas para discussões
em grupo moderadas, permitindo
a troca de ideias e a
identificação de requisitos
comuns.

3. Observação: Observar os
usuários em seu ambiente de
trabalho para entender como
eles interagem com sistemas
existentes ou identificar
necessidades não expressas
verbalmente.

4. Questionários e Pesquisas:
Criar questionários estruturados
para coletar informações de um
grande número de pessoas.
Essa técnica é útil para coletar
dados quantitativos.

5. Prototipagem Rápida:
Construir protótipos interativos
do software para que os usuários
possam visualizar e
experimentar as funcionalidades
propostas, proporcionando
feedback
direto.

6. Workshops de Requisitos:
Realizar sessões de trabalho
colaborativas com partes
interessadas para identificar,
priorizar e validar requisitos.

7. Análise de Documentação
Existente: Rever documentos,
manuais, relatórios e outros
materiais relacionados ao
sistema ou ao projeto para
extrair informações relevantes.

8. Brainstorming: Realizar
sessões de brainstorming com
partes interessadas para gerar
ideias e identificar requisitos de
forma criativa.

9. Técnicas de Storytelling:
Encorajar partes interessadas a
contar histórias sobre como o
sistema deveria funcionar
em cenários específicos,
ajudando a identificar requisitos
implícitos.

10. Casos de Uso: Desenvolver

casos de uso que descrevem
interações entre usuários e o
sistema, ajudando a identificar
requisitos funcionais.

11. Mapeamento de Processos:

Documentar e analisar os
processos de negócios
existentes para entender como o
sistema se encaixará e onde
melhorias são necessárias.

A escolha das técnicas de

elicitação depende da natureza
do projeto, das partes
interessadas envolvidas e das
informações necessárias para
definir os requisitos. Muitas
vezes, é necessário usar várias
técnicas em conjunto para obter
uma visão completa e precisa
dos
requisitos do projeto.

15) O Estudo de Viabilidade é

uma etapa crítica no início de
qualquer projeto, seja de
desenvolvimento de software,
construção civil, investimento
empresarial ou qualquer outro
empreendimento. Sua principal
utilidade é avaliar se o projeto é
viável e se faz sentido seguir em
frente com o investimento de
recursos, tempo e esforço. Aqui
estão algumas das utilidades do
Estudo de Viabilidade:

1. Avaliação Financeira: O
estudo de viabilidade examina as
implicações financeiras do
projeto. Isso inclui a análise de
custos, orçamento necessário e
projeções de receitas. Ele ajuda
a determinar se o projeto é
financeiramente viável e se o
retorno esperado justifica o
investimento.
2. Análise de Mercado: O estudo
considera a demanda de
mercado, a concorrência, as
tendências e as oportunidades
existentes. Ele ajuda a identificar
se há um mercado adequado
para o produto ou serviço que o
projeto visa entregar.

3. Análise Técnica: Avalia a

viabilidade técnica do projeto,
considerando os recursos
necessários, a tecnologia
envolvida e a disponibilidade de
conhecimento e expertise para
executar o projeto com sucesso.

4. Análise de Riscos: Identifica e

avalia os riscos potenciais
associados ao projeto. Isso inclui
riscos financeiros, técnicos,
legais, de mercado e outros. A
análise de riscos ajuda a tomar
medidas para mitigar ou
gerenciar esses riscos.
5. Tomada de Decisão
Informada: Com base nos
resultados do estudo de
viabilidade, as partes
interessadas podem tomar
decisões informadas sobre se
devem prosseguir, ajustar ou
cancelar o projeto. Isso
economiza recursos valiosos que
poderiam ser desperdiçados em
projetos inviáveis.

6. Planejamento Inicial: O estudo

de viabilidade fornece uma base
sólida para o planejamento inicial
do projeto. Isso inclui o
estabelecimento de metas,
escopo, cronograma e alocação
de recursos.

7. Comunicação com
Investidores e Stakeholders:
Quando o projeto envolve
investidores, acionistas ou partes
interessadas externas, o estudo
de viabilidade serve como um
meio eficaz de
comunicar os detalhes do
projeto, seus riscos e
oportunidades.

8. Conformidade Regulatória:
Em muitos casos, projetos estão
sujeitos a regulamentações e
normas específicas. O estudo de
viabilidade ajuda a garantir que o
projeto esteja em conformidade
com essas exigências.

Em resumo, o Estudo de
Viabilidade é uma ferramenta
essencial para avaliar se um
projeto é praticável, lucrativo e
alinhado com os objetivos
estratégicos da organização. Ele
fornece uma base sólida para a
tomada de decisões e o
planejamento adequado,
minimizando o risco de investir
em projetos que não têm
potencial de sucesso.

16) Stakeholders são indivíduos,

grupos,
organizações ou entidades que
têm interesse direto ou indireto
em um projeto, empreendimento
ou organização e que podem ser
afetados por suas atividades,
decisões ou resultados. Os
stakeholders desempenham
papéis cruciais em muitos
contextos, incluindo projetos de
desenvolvimento de software,
negócios, governos e
organizações sem fins lucrativos.

Os stakeholders podem ser

classificados em várias
categorias, dependendo de seu
nível de envolvimento e
interesse no projeto. Algumas
categorias comuns de
stakeholders incluem:

1. Clientes: Os clientes são os

destinatários finais do produto ou
serviço resultante do projeto.
Eles têm um interesse direto no
produto final e
frequentemente influenciam os
requisitos e as expectativas.

2. Patrocinadores: Os
patrocinadores são normalmente
as partes que fornecem recursos
financeiros para o projeto e têm
um interesse direto em seu
sucesso. Eles podem ser
indivíduos, departamentos ou
organizações.

3. Equipe do Projeto: A equipe

do projeto inclui membros que
trabalham ativamente no
planejamento, execução e
entrega do projeto. Eles têm um
interesse direto no andamento e
no resultado do projeto.
4. Gerentes de Projeto: Os
gerentes de projeto são
responsáveis por liderar e
coordenar as atividades do
projeto. Eles estão intimamente
envolvidos no gerenciamento de
stakeholders e na
comunicação com todas as
partes interessadas.

5. Fornecedores e Parceiros:
Fornecedores e parceiros
fornecem recursos, materiais ou
serviços que são essenciais para
o projeto. Eles têm interesse na
execução bem-sucedida do
projeto.

6. Governo e Órgãos
Reguladores: Em muitos casos,
projetos estão sujeitos a
regulamentações
governamentais e normas
específicas. Agências
governamentais e órgãos
reguladores são stakeholders
que podem influenciar o projeto.

7. Comunidade e Sociedade:
Dependendo da natureza do
projeto, a comunidade local ou a
sociedade em geral podem ser
afetadas por suas atividades.
Suas
preocupações e interesses
devem ser considerados.

8. Concorrentes: Em alguns
casos, concorrentes da
organização podem ser
stakeholders indiretos,
especialmente em setores
altamente competitivos.

9. Funcionários: Os funcionários
da organização que estão
envolvidos no projeto ou que
podem ser afetados por suas
implicações são considerados
stakeholders internos.

10. Meio Ambiente: Projetos que

envolvem questões ambientais
têm o meio ambiente como um
stakeholder crítico.

É importante identificar,
compreender e gerenciar os
stakeholders de forma adequada
ao longo do ciclo de vida do
projeto. Isso envolve a
comunicação eficaz, o
atendimento às suas
necessidades e preocupações, e
a criação de relacionamentos
positivos para garantir o sucesso
do projeto e o apoio das partes
interessadas.

17) O Documento de Requisitos

é um documento central no
processo de desenvolvimento de
software. Ele descreve de forma
detalhada as necessidades,
funcionalidades e características
do sistema de software que está
sendo desenvolvido. O objetivo
principal do Documento de
Requisitos é servir como um
contrato ou especificação oficial
entre os desenvolvedores e os
stakeholders do projeto,
garantindo que todos tenham
uma compreensão comum e
precisa do que o sistema deve
realizar.
O Documento de Requisitos
geralmente inclui as seguintes
informações:

1. Introdução: Uma breve visão

geral do projeto, seu propósito e
contexto.

2. Escopo: Uma descrição

detalhada do escopo do sistema,
indicando o que está incluído e o
que está excluído do projeto.

3. Objetivos: Declarações claras

e mensuráveis dos objetivos que
o sistema deve alcançar.

4. Requisitos Funcionais:
Descrições detalhadas das
funções e características
específicas do sistema, incluindo
os requisitos funcionais que
descrevem como o sistema deve
se comportar em resposta a
entradas específicas.
5. Requisitos Não Funcionais:
Requisitos que especificam
critérios de desempenho,
segurança, usabilidade,
confiabilidade e outros atributos
do sistema que não estão
relacionados diretamente com
funcionalidades específicas.

6. Requisitos de Interface:
Descrições das interfaces do
sistema com outros sistemas ou
componentes, incluindo
requisitos de integração.

7. Restrições: Limitações ou
restrições que devem ser
consideradas no
desenvolvimento do sistema,
como restrições de hardware,
software ou regulamentações
externas.

8. Casos de Uso: Cenários que

descrevem interações
específicas entre usuários e o
sistema, muitas vezes
complementando
os requisitos funcionais.

9. Diagramas e Modelos:
Representações visuais, como
diagramas de fluxo de dados,
diagramas de classe ou
diagramas de sequência, que
ajudam a ilustrar a estrutura e o
comportamento do sistema.

10. Rastreabilidade: Uma matriz

de rastreabilidade que vincula
requisitos a casos de teste, para
garantir que todos os requisitos
sejam testados.

11. Aprovação: Assinaturas ou

aprovações dos principais
stakeholders, indicando que eles
concordam com o conteúdo do
documento.

O Documento de Requisitos é
uma peça fundamental na
gestão de projetos de software,
pois fornece uma base sólida
para o planejamento,
implementação, teste e
validação do sistema. Ele
também atua como um ponto de
referência para resolver disputas
ou ambiguidades durante o
desenvolvimento do projeto,
ajudando a garantir que o
sistema entregue atenda às
expectativas dos stakeholders.

18) A UML (Unified Modeling

Language) é uma linguagem de
modelagem gráfica que tem
como finalidade principal
fornecer uma maneira
padronizada e eficaz de
visualizar, projetar, especificar e
documentar sistemas
complexos, especialmente
sistemas de software. A UML é
amplamente utilizada na
engenharia de software e em
disciplinas relacionadas para
auxiliar na compreensão e
comunicação de sistemas e
processos. Suas principais
finalidades
são:

1. Visualização: A UML oferece

uma variedade de diagramas
gráficos que permitem
representar diferentes aspectos
de um sistema de forma visual e
intuitiva. Esses diagramas
incluem diagramas de classes,
diagramas de sequência,
diagramas de atividade,
diagramas de componentes,
entre outros. Cada tipo de
diagrama destaca aspectos
específicos do sistema, tornando
mais fácil para os envolvidos no
projeto entenderem como o
sistema funciona.
2. Projeto: A UML é usada para
modelar a estrutura e o
comportamento de sistemas
antes de sua implementação. Os
diagramas UML permitem que os
projetistas definam a arquitetura
do sistema, as relações entre os
componentes, a interação entre
os diferentes elementos e outras
características essenciais. Isso
ajuda a planejar a estrutura do
sistema de maneira eficiente
antes de iniciar o
desenvolvimento.

3. Especificação: A UML fornece

uma linguagem comum para
especificar requisitos e
comportamentos de sistemas de
software. Ela ajuda a traduzir
requisitos e conceitos abstratos
em modelos concretos e
visualmente compreensíveis, o
que é útil para garantir que todas
as partes interessadas tenham
uma compreensão clara do que
está sendo desenvolvido.

4. Documentação: A UML é
usada para criar documentação
técnica detalhada de sistemas.
Os diagramas UML servem
como uma forma de documentar
a estrutura, o comportamento, as
interfaces e outros aspectos do
sistema, facilitando a
manutenção e o entendimento
contínuos.

5. Comunicação: A UML atua

como uma linguagem comum
que permite que
desenvolvedores, designers,
gerentes de projeto, clientes e
outras partes interessadas
comuniquem ideias, requisitos e
decisões de design de maneira
eficaz. Isso ajuda a evitar mal-
entendidos e garante que todos
estejam alinhados com os
objetivos do projeto.
Em resumo, a UML desempenha
um papel fundamental no
desenvolvimento de software e
na engenharia de sistemas,
fornecendo uma maneira
padronizada e eficiente de
modelar, projetar, especificar e
documentar sistemas
complexos. Ela
promove uma comunicação clara
e eficaz entre todas as partes
envolvidas no ciclo de vida de
um projeto, contribuindo para o
sucesso e a qualidade dos
sistemas desenvolvidos.

19) Casos de uso são uma

técnica de modelagem
amplamente utilizada na UML
(Unified Modeling Language)
para descrever as interações
funcionais entre um sistema de
software e seus usuários (ou
"atores"). Eles são uma
representação visual que ajuda a
entender como o sistema se
comporta em resposta a
diferentes ações dos atores. Aqui
está uma definição mais
detalhada de casos de uso:

- Ator: Um ator é uma entidade

externa ao sistema de software
que interage com o sistema de
alguma forma. Os atores
podem ser pessoas, outros
sistemas, dispositivos ou
qualquer entidade que
desempenhe um papel na
interação com o sistema.

- Caso de Uso: Um caso de uso

é uma representação de uma
interação específica entre um
ator e o sistema. Ele descreve
um cenário em que o ator realiza
uma ou mais ações para
alcançar um objetivo dentro do
sistema.

- Diagrama de Casos de Uso:

Um diagrama de casos de uso é
uma representação gráfica que
mostra os atores, os casos de
uso e as relações entre eles. Os
atores são geralmente
representados por ícones de
stick figures, enquanto os casos
de uso são representados por
elipses. As linhas de ligação
indicam as interações entre
atores e casos de uso.
Aqui estão alguns elementos-
chave dos casos de uso:

1. Nome do Caso de Uso: Cada

caso de uso é identificado por
um nome descritivo que reflete a
ação ou o objetivo que está
sendo realizado.

2. Ator Principal: Indica qual ator

está envolvido no caso de uso e
desempenha o papel principal na
interação.

3. Descrição do Caso de Uso:

Uma breve descrição textual do
que acontece no caso de uso,
geralmente destacando o fluxo
principal de eventos.

4. Fluxo de Eventos: Uma

sequência detalhada de ações e
interações entre o ator e o
sistema que descrevem como o
caso de uso se desenrola. Isso
inclui o início, as etapas
intermediárias e a conclusão.

5. Exceções: Descreve eventos

ou situações excepcionais que
podem ocorrer durante o caso de
uso e como lidar com elas.

6. Pré-condições: Condições que

devem ser verdadeiras antes
que o caso de uso possa ser
executado.

7. Pós-condições: Condições
que devem ser verdadeiras após
a conclusão bem-sucedida do
caso de uso.
Os casos de uso são valiosos
para capturar e documentar os
requisitos funcionais de um
sistema de forma clara e
compreensível. Eles ajudam os
desenvolvedores e as partes
interessadas a entender como o
sistema será usado na prática e
a identificar os principais
cenários de interação entre
usuários e sistema.

20) Em casos de uso, os objetos

comumente utilizados são:

1. Ator: Representa um papel ou

entidade que interage com o
sistema. Os atores podem ser
pessoas, sistemas externos ou
outros sistemas dentro do
sistema em questão.

2. Caso de Uso: Descreve uma

função ou recurso específico que
o sistema fornece aos atores. Os
casos de uso capturam as
interações entre atores e o
sistema.

3. Classe: Representa uma

estrutura de
dados no sistema e é usado para
modelar objetos do mundo real
ou conceitos dentro do sistema.

4. Objeto: São instâncias de

classes que representam
entidades específicas dentro do
sistema.

5. Relações: As relações comuns

entre esses objetos incluem:

- Associação: Uma ligação

entre um ator e um caso de uso,
indicando que o ator interage
com o caso de uso.
- Generalização/Herança: Uma
classe pode herdar
características de outra classe.
Isso é útil para modelar relações
hierárquicas entre objetos.

- Agregação: Representa uma

relação
todo-parte entre classes. Por
exemplo, uma classe "Carro"
pode ter uma agregação com a
classe "Motor" para mostrar que
um carro é composto por um
motor.

- Composição: É uma forma

mais forte de agregação,
indicando que a existência de
uma classe depende da outra.
Por exemplo, um "Motor" em um
"Carro" só existe enquanto o
carro existir.

- Dependência: Indica que uma

classe ou caso de uso depende
de outro para funcionar. Por
exemplo, um caso de uso de
"Reserva de Quarto" pode
depender de uma classe
"Cliente" para obter informações
do cliente.

Estas são as relações e objetos

comuns utilizados em diagramas
de casos de uso
para modelar a interação entre
atores e funcionalidades em um
sistema de software.