Lista de Exercícios 3

Prévia do material em texto

Respostas
2.1 -
Um sistema para controlar o antibloqueio de frenagem de um carro. Por ser um
sistema de segurança crítico que exige inúmeras análises antes de sua
implementação, o sistema em cascata seria o ideal.
Um sistema de realidade virtual para dar apoio à manutenção de software. Por
se tratar de um sistema rico em interfaces visuais e com chances de possuir
inúmeras mudanças de requerimento um sistema incremental pode ser usado com
prototipação das interfaces gráficas, um processo de desenvolvimento ágil também
pode ser usado.
Um sistema de contabilidade para uma universidade, que substitua um
sistema já existente. Este é um sistema com os requisitos francamente
conhecidos, como já existem outros sistemas que possivelmente se enquadrem
neste tipo de sistema uma abordagem baseada em reuso pode ser aplicada.
Um sistema interativo de planejamento de viagens que ajude os usuários a
planejar viagens com menor impacto ambiental. Um sistema com interface de
usuário complexa que precisa ser estável e útil. Uma abordagem incremental é a
mais apropriada conforme os requerimentos de sistema mudam conforme o usuário
ganha experiência.
2.2 -
Porque em software de negócios dificilmente a equipe de desenvolvimento irá
possuir o domínio completo do problema a ser solucionado, o que exige uma
abordagem incremental, em sistemas de tempo real geralmente os requisitos são
bem conhecidos e há um foco maior em segurança o que exige maior exatidão no
desenvolvimento, não podendo haver falhas, portanto o modelo incremental não
seria nada ideal para este tipo de sistema.
2.3 -
Em um modelo de processo baseado em reuso você precisa de duas atividades
porque é essencial adaptar os requerimentos de sistema de acordo com as
capacidades do sistema/componente a ser reutilizado. Estas atividades são:
1. Uma atividade inicial onde você compreende a função do sistema e seus
requerimentos. Estes devem ser expressos com detalhes suficientes para que
possam ser usados como base para o sistema/componente que satisfazem os
requerimentos e podem ser reusados.
2. Quando os sistemas/componentes forem selecionados, você precisa que os
requisitos de engenharia sejam mais detalhados para checar se estas
características do software reusado satisfazem as necessidades do negócio e para
identificar mudanças e adições que sejam necessárias.
2.4 -
Porque os requisitos do usuário são requisitos fracos, generalistas, que descrevem
o que o sistema se propõe a fazer, enquanto os requisitos de sistema envolvem
mais a parte técnica e de arquitetura (como o sistema irá fazer) sendo portanto
requisitos fortes que envolvem um nível de descrição próprio para a equipe de
desenvolvimento e longe da linguagem leiga do usuário.
2.5 -
1- Especificação de software ou engenharia de requisitos é o processo de
compreensão e definição dos serviços requisitados do sistema e identificação de
restrições relativas à operação e ao desenvolvimento do sistema.
2- Desenvolvimento de software é o processo de conversão de uma especificação
do sistema em um sistema executável. Sempre envolve processos de projeto e
programação de software, mas, se for usada uma abordagem incremental para o
desenvolvimento, também pode envolver o refinamento da especificação do
software.
3- Validação de software ou, mais genericamente, verificação e validação (V&V),
tem a intenção de mostrar que um software se adequa a suas especificações ao
mesmo tempo que satisfaz as especificações do cliente do sistema. Teste de
programa, em que o sistema é executado com dados de testes simulados, é a
principal técnica de validação. A validação também pode envolver processos de
verificação, como inspeções e revisões, em cada estágio do processo de software,
desde a definição dos requisitos de usuários até o desenvolvimento do programa.
Devido à predominância dos testes, a maior parte dos custos de validação incorrem
durante e após a implementação.
4- A flexibilidade dos sistemas de software é uma das principais razões pelas quais
os softwares vêm sendo, cada vez mais, incorporados em sistemas grandes e
complexos. Uma vez que a decisão pela fabricação do hardware foi tomada, é muito
caro fazer alterações em seu projeto. Entretanto, as mudanças no software podem
ser feitas a qualquer momento durante ou após o desenvolvimento do sistema.
Mesmo grandes mudanças são muito mais baratas do que as correspondentes
alterações no hardware do sistema.
2.6 -
Os sistemas devem mudar porque são instalados em um ambiente que se adapta e
naturalmente gera novos/diferentes requerimentos de sistema, um exemplo seria a
refatoração de código que melhora a qualidade do código e o torna mais ameno a
mudanças.