Buscar

PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE_SIMULADO

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes

Prévia do material em texto

  Tópico Anterior Próximo TópicoClique aqui e Col@bore para a melhoria de conteúdo desta tela. 
 
O que se deve fazer para aumentar as chances de sucesso no desenvolvimento de software?
Sobre o modelo iterativo e incremental, classifique cada sentença como sendo V(verdade) ou F(falsa). Em seguida, assinale a alternativa correta.
I. O modelo iterativo baseia-se na idéia do aumento da abrangencia do sistema.
II. O modelo incremental baseia-se na ideia de refinamentos sucessivos.
III. O modelo iterativo e incremental vale-se do modelo em cascata para sua realização.
IV. A cada iteração, ocorre a especificação, implementação, teste e implantação
Com base em sua analise assinale a opção que descreve a correta sequência de V e F é:
A confiabilidade especificada para um software aplicativo é:
Por que é importante a revisão da especificação dos requisitos? Assinale a INCORRETA.
De acordo com a teoria são produtos da fase de elaboração do RUP:
No processo de desenvolvimento de software, todo software passa pelas fases de análise e projeto, associadas, respectivamente, com o que deve ser feito e como deve ser feito. A partir dessa
informação, avalie a opções correta.
Qual alternativa abaixo melhor representa o requisito "Sistema deve oferecer opção para o usuário escrever observação nos documentos." ?
Em relação as atividades para análise de requisitos pra o estudo de viabilidade, qual alternativa abaixo melhor representa a frase:
"Visa atender os requisitos para a aceitação do produto ou problema apresentado. 
 Levantemanto deve ser relacionado com a aceitação da solução proposta, e como os agentes se sentirão em relação à ela. "
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
 CCT0746_A2_201903453241_V1 
Lupa Calc.
 
 
PPT
 
MP3
 
Aluno: ANDRÉ LUIZ DAMIÃO DA SILVA Matr.: 201903453241
Disc.: PROC. DES. SOFTWARE 2019.1 EAD (G) / EX
 
Prezado (a) Aluno(a),
 
Você fará agora seu TESTE DE CONHECIMENTO! Lembre-se que este exercício é opcional, mas não valerá ponto para sua avaliação. O mesmo será
composto de questões de múltipla escolha.
Após responde cada questão, você terá acesso ao gabarito comentado e/ou à explicação da mesma. Aproveite para se familiarizar com este modelo de
questões que será usado na sua AV e AVS.
 
1.
Adotar um processo de desenvolvimento.
Focar no prazo independente do atendimento das funcionalidades desejadas.
Atender os requisitos no momento em que forem solicitados independente de planejamento.
Obter muitos recursos financeiros.
Obter mão de obra especializada independente de processo.
 
 
 
Explicação:
Um processo de desenvolvimento de software, prevê planejamento, organização e controle das atividades inerentes ao desenvolvimento. Uma empresa
que não tem processo de desenvolvimento não terá gestão dos acontecimentos e fatalmente extrapolará o prazo (na verdade nem consegurá prever
com maior precisão), dos custos e a qualdiade fica comprometida
 
 
 
 
2.
I-F; II-F; III-V; IV-V
I-V; II-V; III-F; IV-V
I-F; II-F; III-V; IV-F
I-V; II-V; III-V; IV-F
I-V; II-V; III-V; IV-V
 
 
 
Explicação:
O Desenvolvimento Iterativo e Incremental é um dos clássicos modelos de processo de desenvolvimento de software criado em resposta às fraquezas do
modelo em cascata, o mais tradicional. Os dois padrões mais conhecidos de sistemas iterativos de desenvolvimento são o RUP (Processo Unificado da
Rational) e o Desenvolvimento ágil de software. Por isso o desenvolvimento iterativo e incremental é também uma parte essencial da Programação
Extrema e outros.
ASSIM APENAS AS AFIRMATIVAS III E IV SÃO VERDADEIRAS.
 
 
 
 
3.
um mecanismo de teste de estresse.
um requisito funcional.
um requisito não-funcional
um mecanismo de teste de desempenho.
uma restrição de escopo.
 
 
 
Explicação:
Por ser um atributo de software a confiabilidade é um requisito não-funcional.
 
Gabarito
 Coment.
 
 
 
4.
A fim de garantir que a codificação seja feita de forma correta e sem erros.
A fim de melhorar a qualidade do documento de requisitos do sistema
Para ratificar os itens descritos, eliminar inconsistências e contradições no texto e até identificar novos requisitos (ou complementos destes) que
foram esquecidos.
A fim de melhorar a qualidade do software entregue ao cliente, uma vez que se os requisitos estiverem corretos, os erros que poderão chegar ao
cliente serão apenas de programação e não de especificação
Para corrigir erros e omissões no documento de requisitos, uma vez que erros de requisitos se propagam pelas demais etapas de
desenvolvimento
 
 
 
Explicação:
As tarefas de engenharia de requisitos ajudam a levar a um entendimento de qual será o impacto do software sobre o negócio, quais são as
necessidades do cliente e como os usuários finais irão interagir com o software.
Normalmente a engenharia de requisitos é realizada por analistas de sistemas juntamente com gerentes, clientes, usuários finais e outros que possam
ter interesse no software.
A engenharia de requisitos é muito importante, pois nos ajuda a projetar e construir um programa de computador que possa resolver o problema do
cliente. Por isso a importância de entender primeiramente o que o cliente quer antes de começarmos a projetar e construir um sistema. De forma mais
especifica a engenharia de requisitos consiste de um amplo espectro de tarefas e técnicas que levam a um entendimento dos requisitos.
Dessa forma, a engenharia de requisitos permite que examinemos o contexto do trabalho de software a ser realizado, as necessidades específicas que o
projeto e a construção devem atender, as prioridades que orientam a ordem que o trabalho deve ser completado e as informações, funções e os
comportamentos que terão um impacto profundo no projeto resultante.
Existem algumas etapas na engenharia de requisitos, são elas: concepção, levantamento, elaboração, negociação, especificação, validação e gestão. A
concepção é a primeira etapa da engenharia de requisitos e nessa etapa procura-se definir o escopo e a natureza do problema que estamos tentando
resolver para o cliente; A segunda etapa é a de levantamento em que se procura ajudar os interessados a definir o que é necessário; A terceira etapa é a
de elaboração em que os requisitos básicos são refinados e modificados; A quarta etapa é a de negociação onde se definem quais são as prioridades, o
que é essencial e quando é necessário; Na quinta etapa especifica-se o problema e então, na sexta etapa de Validação é realizada uma revisão e
validação para garantir que o entendimento dos problemas coincidem com o que os interessados haviam explicado. Essa parte é realizada com os
interessados; Por fim, ainda temos uma sétima etapa que é a Gestão dos requisitos em que se controlam os requisitos.
Desta forma fica evidente que não faz parte da engenharia de requisitos garantir que a codificação seja feita de forma correta e sem erros.
 
 
 
 
5.
Lista de riscos revisada e base de dados operacionais convertidas.
Documento de visão e produto de software integrado.
Descrição da arquitetura do software e lista de riscos revisada.
Manual do usuário e base de dados operacionais convertidas.
Produto de software integrado e descrição da arquitetura do software.
 
 
 
Explicação:
Segundo o RUP, o propósito da fase de elaboração é analisar o domínio do problema, estabelecer uma base sólida de arquitetura, coletar os requisitos,
desenvolver um plano para o projeto e eliminar os elementos de maior risco do projeto, resolvendo questões como "O plano do projeto é confiável?" e
"Os custos são admissíveis", em outras palavras, esta fase tem por finalidade eliminar os principais riscos e definir uma arquitetura estável, que atenda
os requisitos definidos para o projeto (ou seja, a arquitetura, os requisitos e os planos são considerados estáveis o suficiente). Assim, será possível
determinar os custos e o cronograma do projeto com maior precisão.
 
 
 
 
6.
O objetivo do projeto arquitetural é desenvolver uma estrutura de programa e representar os diversosfluxos de dados entre os módulos.
Na fase de projeto, dois níveis de projeto devem ser considerados: o projeto detalhado, que se preocupa com uma transformação dos requisitos em um projeto de dados e arquitetural; e
o projeto preliminar, que se preocupa em aprimorar o projeto detalhado para que a implementação possa ser realizada em seguida.
Na fase de análise, três modelos que devem ser considerados são: do domínio da informação, o funcional e o comportamental.
O projeto arquitetural independe do paradigma de desenvolvimento.
Para lidar com a complexidade do software, pode-se aplicar o princípio do particionamento, quebrando o problema em problemas menores. Esse princípio não é aplicado nas outras
fases de desenvolvimento e ele não causa impacto nos custos de desenvolvimento.
 
 
 
Explicação:
Na engenharia de software, a engenharia de requisitos compreende 7 passos:
concepção,
levantamento,
elaboração,
negociação,
especificação,
validação 
gestão.
Dentro do ciclo de vida de processo de software, a engenharia de requisitos é iniciada na atividade de comunição e continuada até a atividade
de modelagem ( Lembrando que o ciclo de vida do software compreende 5 atividades: comunição, projeto, modelagem, construção e implantação).
Durante a fase da concepção, é realizado um entendimento básico do sistema e é definido o escopo. Durante a fase do levantamento o cliente define as
necessidades básicas do sistema. Na fase da elaboração é produzido o modelo de análise que define o domínio do problema informacional,
funcional e comportamental; o relacionamento e colaboração entre classes são identificados e vários diagramas UML são produzidos. É nessa fase que
são refinados os modelos de caso de uso. Na fase de negociação os requisitos são negociados, ou seja, o cliente, o usuário e outros interessados
ordenam requisitos e discutem prioridades, utilizando abordagem iterativa. Na fase de especificação a função, desempenho e restrição do sistema são
discutidos, gerando o produto final dos requisitos. Durante a fase de validação, a qualidade da especificação é avaliada, utilizando revisão técnica formal.
Na fase de gestão ocorre a identificação e controle das mudanças em requisitos, ocorrendo de maneira formal apenas em projetos grandes. É criada uma
tabela de rastreamento relacionando requisitos identificados a um ou mais aspectos do sistema.
Na fase de levantamento é utilizada uma técnica chamada Implantação da Função de Qualidade (IFQ), que traduz as necessidades do cliente para
requisitos técnicos do software. São 3 tipos de requisitos: normais (objetivos e metas do sistema), esperados (implícitos e fundamentais) e excitantes
(além das espectativas do cliente). Essa técnica utiliza entrevistas com os clientes, observação e levantamento de dados históricos.
 
 
 
 
7.
Requisito de usuário.
Requisito funcional.
Requisito não funcional.
Requisito externo.
Requisito do sistema.
 
 
 
Explicação:
REQUISITOS FUNCIONAIS - Descrevem as funcionalidades do sistema. Ou seja, representam os comportamentos que um programa ou sistema deve
apresentar diante de certas ações de seus usuários.
 Exemplos:
[RF 0023] Usuário não pode acessar o Banco de Dados financeiro.
[RF 0059] Sistema deve oferecer opção para o usuário escrever observação nos documentos.
[RF0060} Sistema deve permitir inclusão e exclusão.
Conclusão:
A frase "Sistema deve oferecer opção para o usuário escrever observação nos documentos.", trata-se de um Requisito funcional.
 
 
 
 
8.
Técnica.
Operacional.
Cronograma.
Custo benefício.
Econômica.
 
 
 
Explicação:
Em nossa aula nós abordamos quatro tipos de atividades para análise de requisitos(viabilidade): Técnica, Operacional, Cronograma e Econômica.
A viabilidade operacional está relacionada com a importância do software contribuir para os objetivos da organização e , consequentemente,ter um bom
aceite pela empresa.
Conclusão:
Com base no conceito dessas atividades, a frase "Visa atender os requisitos para a aceitação do produto ou problema apresentado. 
 Levantemanto deve ser relacionado com a aceitação da solução proposta, e como os agentes se sentirão em relação à ela. "
está relacionada com a atividade operacional.
 
 
 
 
 
 
 
Legenda: Questão não respondida Questão não gravada Questão gravada
 
 
Exercício inciado em 13/06/2019 22:37:41. 
 
 
 
 

javascript:voltar();
javascript:voltar();
javascript:duvidas('55458','7170','1','3307367','1');
javascript:duvidas('54909','7170','2','3307367','2');
javascript:duvidas('19874','7170','3','3307367','3');
javascript:duvidas('610216','7170','4','3307367','4');
javascript:duvidas('95320','7170','5','3307367','5');
javascript:duvidas('95476','7170','6','3307367','6');
javascript:duvidas('2963772','7170','7','3307367','7');
javascript:duvidas('2969962','7170','8','3307367','8');
javascript:diminui();
javascript:aumenta();
javascript:calculadora_on();
javascript:abre_frame('2','2','','G8HCJQTWH3FL54O34A99','');
javascript:abre_frame('3','2','','G8HCJQTWH3FL54O34A99','');
javascript:abre_colabore('35649','156566546','3208962074');
4ndr3lds
Destacar
4ndr3lds
Destacar
4ndr3lds
Destacar
4ndr3lds
Destacar
4ndr3lds
Destacar
4ndr3lds
Destacar