option
My Daypo

USCS - Qualidade de Software

COMMENTS STADISTICS RECORDS
TAKE THE TEST
Title of test:
USCS - Qualidade de Software

Description:
Atividade de Reforço - 2º semestre 2014

Author:
AVATAR
Prof. Fabricio Perrella
(Other tests from this author)


Creation Date:
04/10/2013

Category:
Computers

Number of questions: 16
Share the Test:
Facebook
Twitter
Whatsapp
Share the Test:
Facebook
Twitter
Whatsapp
Last comments
No comments about this test.
Content:
São consideradas métricas diretas de software, os seguintes itens abaixo com a EXCEÇÃO de: Produtividade do desenvolvedor Tamanho em LOC Quantidade de tabelas no BD Esforço em horas para desenvolvimento Quantidade de Casos de Uso.
Relacione as colunas. (há somente um item correspondente à direita para os itens à esquerda) Ciclo PDCA - Shewhart Controle Estatístico de Processos - Deming Planejamento/Contole/Melhoria - Juran Do it right at first time - Crosby.
Entre vários componentes do custo da qualidade, pode-se dizer que há um custo para a falha interna e outro para falha externa. Isto inclui: (selecione todas as opções relacionadas a estes dois tipos de custo) correções no produto dentro do período de garantia retrabalho no projeto por conta de defeitos encontrados durante os testes treinamentos necessários para a equipe do projeto testes e inspeções necessárias sobre o produto aquisição de ferramentas para testes.
Associe as métricas listadas à esquerda conforme a sua categoria de classificação, à direita: (observação: o relacionamento é de muitos para um) quantidade de horas para execução de uma tarefa quantidade de Casos de Uso número de defeitos encontrados em testes integrados quantidade de LOCs (linhas de código) esforço em homens / mês (FTE).
São consideradas ferramentas da qualidade aplicáveis a projetos de desenvolvimento e/ou manutenção de software, as seguintes opções: (marque todas que julgar apropriadas) Benchmarking de melhores práticas e métricas Diagrama de Ishikawa (espinha de peixe) para análise de causa-raiz Análise de custo X benefício Fluxogramas Ensaios sobre protótipos de produtos.
Segundo McCall são considerados fatores de qualidade todas as opções abaixo, com a EXCEÇÃO de: manutenibilidade usabilidade portabilidade testabilidade rastreabilidade.
Os requisitos de um software podem ser classificados em 3 níveis de abstração: requisitos de negócio; requisitos funcionais e não funcionais; requisitos detalhados requisitos de negócio; requisitos funcionais; requisitos técnicos requisitos em alto nível; requisitos detalhados; requisitos técnicos requisitos em alto nível; requisitos funcionais; requisitos detalhados requisitos de negócio; requisitos técnicos; requisitos funcionais e não funcionais.
São considerados requisitos não funcionais, os seguintes exemplos abaixo: (assinale todos os que julgar apropriados) desempenho do software, como por exemplo: capacidade de processamento na CPU, memória RAM ocupada e ocupação em disco disponibilidade da aplicação, se precisa estar online dentro do horário comercial, 24 x 7 ou qualquer outro período processos de negócio suportados, como por exemplo: cadastrar clientes, emitir nota fiscal, calcular o valor total do pedido, etc. necessidade de segurança da aplicação, seja através de mecanismos de prevenção ou de proteção a dados classificados.
Relacione as colunas acerca dos Processos de Gestão de Requisitos: (há exatamente uma descrição à direita para cada item à esquerda) Elicitação Análise Validação Gerenciamento Documentação.
A técnica mais apropriada para elicitação de requisitos quando há diversos usuários que podem colaborar no desenho e construção dos artefatos da aplicação é: brainstorming reuniões entrevistas walktrough JAD - Joint Application Design.
Complete a sentença abaixo: A técnica mais apropriada para elicitação de requisitos de um software cujas funcionalidades e requisitos não são pré-estabelecidos e/ou seus usuários não estão acessíveis é conhecida como ___________ .
São formas de priorização de requisitos de um software a ser desevolvido, os seguintes itens: (marque todos os que julgar apropriados) método MoSCoW, onde os requisitos qualificados como M são os que são fundamentais para o funcionamento básico da aplicação análise de stakeholders, a partir de critérios como: criticidade ao negócio, complexidade e riscos de desenvolvimento pontuação das funcionalidades, como por exemplo a partir de avaliação de esforço, nos moldes do poquer do planejamento da metodologia Scrum custo e prazo estimados para o seu desenvolvimento.
Com relação ao método de estimativa COCOMO é correto afirmar que: é um método baseado em uma estratégia Bottom-Up de contagem, em que a partir do tamanho em linhas de código estimadas calcula-se o esforço em horas-homem, e, em função do esforço calcula-se o prazo do projeto. é um método baseado em uma estratégia Top-Down de contagem, em que a partir do tamanho em Pontos de Função estimados calcula-se o esforço em horas-homem, e, em função do esforço calcula-se o prazo do projeto. é um método baseado em uma estratégia Bottom-Up de contagem, em que a partir do tamanho em linhas de código estimadas calcula-se o prazo do projeto, e, em função do prazo calcula-se o esforço em horas-homem. é um método baseado em uma estratégia Top-Down de contagem, em que a partir do tamanho em Pontos de Função estimados calcula-se o prazo do projeto, e, em função do prazo calcula-se o esforço em horas-homem.
O método de contagem de Pontos de Função contempla as seguintes práticas: (assinale todas que julgar apropriadas) A complexidade das Funções de Dados (Arquivos Lógicos de Dados e Arquivos de Interfaces Externas) é calculada baseada na quantidade de elementos de dados versus a quantidade de tipos de registros (formas de agrupar os dados). A diferença entre uma Consulta Externa e uma Saída Externa é o fato de não ocorrer transformações de dados nem cálculos complexos nas transações de Saída. Os pontos de função ajustados são baseados em 14 critérios de ajustamento que podem aumentar ou diminuir os pontos de função brutos em até 35%. As funções de transação (Entradas Externas, Saídas Externas e Consultas Externas) são calculadas somente em função da quantidade de elementos de dados envolvidos.
Sobre o método de contagem conhecido como NESMA associe as colunas abaixo Contagem Indicativa Contagem Estimada Contagem Detalhada.
Na contagem dos Pontos de Casos de Uso (UCPs) é incorreto afirmar que: Há dois conjuntos de critérios de ajustamento para a contagem: Fatores Ambientais do Projeto e Fatores Técnicos do Produto. Nos baseamos em todos os componentes da aplicação, a saber: a complexidade dos Atores, a quantidade de Classes de Dados, o número de passos dos Casos de Uso e a Quantidade de Bases de Dados envolvidas. A complexidade de um ator é determinada pelo tipo de interface representada pelo ator, como por exemplo, se é um outro sistema, um usuário ou uma API. O esforço médio para a confecção de um ponto de caso de uso é de cerca de 15 a 30 horas-homem.
Report abuse Terms of use
HOME
CREATE TEST
COMMENTS
STADISTICS
RECORDS
Author's Tests