ENGENHARIA DE SOFTWARE Flashcards
1
Q
A principal evolução do PMBOK 7 está em focar na melhoria do resultado do projeto, deixar de lado processos que são prescritivos por natureza e focar no valor total das entregas.
A
CERTO
O PMBOK 7 evolui para um padrão baseado em princípios a fim de apoiar o gerenciamento de projetos de forma mais eficiente e desta forma focar mais nos resultados pretendidos, em vez de entregas
2
Q
O PMBOK 7 evolui para um padrão baseado em …………………. a fim de apoiar o gerenciamento de projetos de forma mais eficiente e desta forma focar mais nos resultados pretendidos, em vez de entregas
A
O PMBOK 7 evolui para um padrão baseado em princípios a fim de apoiar o gerenciamento de projetos de forma mais eficiente e desta forma focar mais nos resultados pretendidos, em vez de entregas
3
Q
O PMBOK 7 evolui para um padrão baseado em princípios a fim de apoiar o gerenciamento de projetos de forma mais eficiente e desta forma focar mais ……………………………………., em vez de …………………………………..
A
focar mais nos resultados pretendidos, em vez de entregas
4
Q
Projetos não existem apenas para gerar saídas (entregáveis), mas principalmente para ……………………. à organização e às partes interessadas.
A
agregar valor
5
Q
………………………. : Projetos, programas, subportfólios e operações gerenciadas em grupo para alcançar objetivos estratégicos.
A
Portfólio
6
Q
………………………..: Um grupo relacionado de projetos, subprogramas e atividades de programa gerenciados de forma coordenada para a obtenção de benefícios que não estariam disponíveis se eles fossem gerenciados individualmente.
A
Programa
7
Q
………………………..: Um esforço temporário empreendido para criar um produto, serviço ou resultado único.
A
Projeto
8
Q
………………………..: Um artefato produzido, quantificável e que pode ser um item final ou um item componente (intermediário).
A
Produto
9
Q
………………………..: A aplicação de conhecimentos, habilidades, ferramentas e técnicas às atividades do projeto para cumprir os requisitos definidos
A
Gerenciamento de projetos
10
Q
………………………..: Uma coleção de atividades estratégicas de negócios destinadas a construir, sustentar e/ou promover uma organização
A
Sistema de entrega de valor
11
Q
………………………..: Portfólios, programas, projetos, produtos e operações podem fazer parte do sistema de uma organização para entrega de valor.
A
Sistema de entrega de valor
12
Q
Defina Gerenciamento de Projetos
A
A aplicação de conhecimentos, habilidades, ferramentas e técnicas às atividades do projeto para cumprir os requisitos definidos
13
Q
Defina “Sistema de entrega de Valor”
A
Uma coleção de atividades estratégicas de negócios destinadas a construir, sustentar e/ou promover uma organização. Portfólios, programas, projetos, produtos e operações podem fazer parte do sistema de uma organização para entrega de valor.
14
Q
Ao final de um projeto, que é temporário, é gerado um ……………………. ou ……………… que se transforma em ……………………….. Uma vez que o ciclo de vida do produto é maior que o ciclo de vida do projeto, aquele é utilizado por muito tempo após encerramento do projeto da entrega do resultado.
A
é gerado um resultado ou produto que se transforma em operações contínuas e diárias.
15
Q
O ciclo de vida do ……………………… é maior que o ciclo de vida do projeto, aquele é utilizado por muito tempo após encerramento do projeto da entrega do resultado.
A
produto
16
Q
Os portfólios compartilham os resultados, benefícios e o valor desejados com programas e projetos. As entregas de programas e projetos são repassadas para as operações com as informações sobre suporte e manutenção das entregas.
A
CERTO
Os programas e os projetos fornecem informações sobre o desempenho e o progresso na obtenção dos resultados, benefícios e valor desejados para os portfólios.
17
Q
Os programas e os projetos fornecem informações sobre o desempenho e o progresso na obtenção dos resultados, benefícios e valor desejados para os portfólios. Os portfólios fornecem avaliações sobre o desempenho do portfólio para a ……………………
A
liderança sênior.
Além disso, as operações fornecem informações sobre em que nível de qualidade avança a estratégia da organização. as informações devem percorrer toda a cadeia, desde a alta administração até as operações diárias.
18
Q
Os projetos podem operar dentro de um programa ou portfólio ou como uma atividade independente.
A
CERTO
19
Q
Os projetos podem operar dentro de um programa ou portfólio, mas não como uma atividade independente.
A
ERRADO
pode ser atividade independente sim
20
Q
Cliente e usuário final nem sempre são sinônimos. Qual a diferença?
A
- Cliente: pessoa ou grupo que solicitou o projeto ou está provendo recursos financeiros para sua execução.
- Usuário final é a pessoa ou o grupo que experimentará o uso direto da entrega do projeto.
21
Q
…………………… é um artefato produzido, quantificável e que pode ser um item final em si ou um item componente (intermediário).
A
Um produto
O ciclo de vida do produto compõe uma série de fases que representam a evolução de um produto, de sua concepção ao crescimento, maturidade até sua descontinuação.
22
Q
Qual é maior, o ciclo de vida de um produto ou ciclo de vida de um projeto?
A
normalmente o ciclo de vida do produto e maior. Para o mesmo produto posso ter vários projetos que atuam em fases diferentes do produto como crescimento, maturidade e até mesmo a retirada do produto de circulação.
23
Q
O ciclo de vida do produto compõe uma série de fases que representam a evolução de um produto, de sua concepção ao crescimento, maturidade até sua descontinuação. Normalmente o ciclo de vida do produto coincide com o ciclo de vida do projeto.
A
ERRADO
Ciclo de vida do produto é diferente do ciclo de vida do projeto, normalmente o ciclo de vida do produto é maior. Por exemplo, para o mesmo produto posso ter vários projetos que atuam em fases diferentes do produto como crescimento, maturidade e até mesmo a retirada do produto de circulação
24
Q
Os princípios do gerenciamento de projetos são de natureza prescritiva. Pretendem apenas orientar o comportamento das pessoas envolvidas com projetos. Eles têm uma base ampla, então há muitas maneiras de as pessoas e as organizações manterem o alinhamento com os princípios.
A
ERRADO
não são prescritivos
24
Os princípios do gerenciamento de projetos não são de natureza prescritiva. Pretendem apenas orientar o comportamento das pessoas envolvidas com projetos. Eles têm uma base ampla, então há muitas maneiras de as pessoas e as organizações manterem o alinhamento com os princípios.
CERTO
25
Quais são os quatro valores do código de ética mais importantes do gerenciamento de projetos?
ERRHO
Equidade
Responsabilidade
Respeito
Honestidade
26
Um .................................... é um grupo de atividades relacionadas, que são críticas para a entrega eficaz dos resultados do projeto. São áreas de foco interativas, inter-relacionadas e interdependentes que trabalham em uníssono, ou seja, em harmonia, para alcançar os resultados desejados do projeto.
domínio de desempenho do projeto
Existem oito domínios de desempenho de projetos.
27
......................: uma coleção de atividades de projeto logicamente relacionadas que culmina na conclusão de uma ou mais entregas.
Fase do projeto
28
......................: uma série de fases pelas quais um projeto passa desde seu início até sua conclusão.
Ciclo de vida do projeto
29
Existem 3 tipos de abordagem de desenvolvimento de projeto:
Abordagem Preditiva (cascata)
Abordagem Adaptativa (iterativo e incremental)
Abordagem Híbrida (uniào)
30
Uma abordagem de desenvolvimento é 0 meio usado para criar e desenvolver o produto, serviço ou resultado durante o ciclo de vida do projeto. Existem diferentes abordagens de desenvolvimento, e diversos setores podem usar diferentes termos para essa abordagem. Três abordagens comumente usadas são: preditiva, hibrida e prescritiva
ERRADO
Abordagem Preditiva (cascata)
Abordagem Adaptativa (iterativo e incremental)
Abordagem Híbrida (uniào)
30
A cadência de entrega se refere ao tempo e a frequência das entregas do projeto. Os projetos podem ter uma única entrega, várias entregas ou entregas periódicas
CERTO
cadência é um ritmo de atividades realizadas ao longo do projeto. Elas podem ser de única entrega, entregas múltiplas, entregas periódicas ou entrega contínua
30
O que é Tailoring?
Tailoring é a adaptação deliberada da abordagem, da governança e dos processos do gerenciamento de projetos para torná-los mais adequados a determinado ambiente e ao trabalho a realizar.
30
Os aspectos do projeto que podem ser submetidos ao tailoring são:
-
- Processos
-
-
-
- Seleção do ciclo de vida e a abordagem de desenvolvimento,
- Processos,
- Engajamento,
- Ferramentas, e
- Métodos e artefatos.
30
...................... é a adaptação deliberada da abordagem, da governança e dos processos do gerenciamento de projetos para torná-los mais adequados a determinado ambiente e ao trabalho a realizar.
Tailoring
considera a abordagem de desenvolvimento, os processos, o ciclo de vida do projeto, as entregas e a escolha das pessoas com quem se engajar.
31
Cadência de entrega com time-boxes é característica da abordagem de desenvolvimento PREDITIVA.
ERRADO
Adaptativa (iterativo e incremental)
31
A Abordagem Preditiva de desenvolvimento é orientada a PLANOS, enquanto que a abordagem Adaptativa é orientada a VALOR.
CERTO
32
Os aspectos do projeto que podem ser submetidos ao tailoring são:
-
-
-
-
- Métodos e artefatos.
- Seleção do ciclo de vida e a abordagem de desenvolvimento,
- Processos,
- Engajamento,
- Ferramentas, e
- Métodos e artefatos.
33
Diga a sugestão de Tailoring para a situação comum abaixo:
Entregas de baixa qualidade
Adicione mais ciclos de verificação de feedback e etapas de garantia da qualidade.
34
Diga a sugestão de Tailoring para a situação comum abaixo:
Longos atrasos e espera de aprovações
Tente simplificar as decisões de aprovação, reduzindo o número de pessoas autorizadas a tomar decisões até determinados limites de valor.
34
Diga a sugestão de Tailoring para a situação comum abaixo:
Membros da equipe não sabem como prosseguir ou realizar o seu trabalho
Adicione mais etapas de orientação, treinamento e verificação.
34
Diga a sugestão de Tailoring para a situação comum abaixo:
Muitos trabalhos em andamento ou grande volume de descarte
Use técnicas como mapeamento da cadeia de valor e quadros Kanban para visualizar o trabalho, identificar questões e propor soluções.
35
Diga a sugestão de Tailoring para a situação comum abaixo:
Partes interessadas não estão envolvidas nem compartilham feedback negativo
Avalie se as informações compartilhadas com as partes interessadas são suficientes; se os ciclos de feedback foram adotados e estão funcionando. O engajamento mais profundo pode funcionar melhor do que a simples comunicação.
35
Diga a sugestão de Tailoring para a situação comum abaixo:
Falta de visibilidade e entendimento do andamento do projeto
Verifique se as medidas apropriadas estão sendo coletadas, analisadas, compartilhadas e discutidas durante as reuniões da equipe com as partes interessadas; valide as medidas acordadas entre a equipe e as partes interessadas.
35
Diga a sugestão de Tailoring para a situação comum abaixo:
Questões e/ou riscos para os quais a equipe não está preparada continuam a surgir, exigindo que a equipe resolva, em vez de continuar com o trabalho
Explore as causas raiz para saber se há falhas relativas aos processos ou as atividades do projeto.
36
Tailoring envolve a adaptação considerada para a abordagem, governança e os processos para torná-los mais adequados a determinado ambiente e ao projeto a realizar. Envolve a análise, o desenho e a modificação deliberada dos elementos pessoais, os processos aplicados e as ferramentas usadas.
CERTO
O processo de tailoring envolve quatro etapas:
Selecionar a abordagem inicial.
Realizar o tailoring da organização.
Realizar o tailoring do projeto.
Implementar melhorias continuas.
36
O processo de tailoring envolve quatro etapas:
-Selecionar a abordagem inicial.
-
-Realizar o tailoring do projeto.
-
-Selecionar a abordagem inicial.
-Realizar o tailoring da organização.
-Realizar o tailoring do projeto.
-Implementar melhorias continuas.
36
O processo de tailoring envolve quatro etapas:
-
-
-
-
-Selecionar a abordagem inicial.
-Realizar o tailoring da organização.
-Realizar o tailoring do projeto.
-Implementar melhorias continuas.
36
Uma das formas de medir o grau de eficiência com que a equipe do projeto está realizando o trabalho é avaliar o índice de desempenho de prazos, que consiste em uma medida de eficiência do cronograma expressa como a razão entre valor agregado e valor planejado.
CERTO
Índice de Desempenho de Prazo (IDP) é dado por uma divisão do valor agregado (VA) das entregas, em valor monetário, sobre o valor planejado (VP) das entregas.
36
Um dos princípios estipulados pelo PMBOK 7.ª edição é o enfoque no valor, segundo o qual valor é o indicador de sucesso definitivo do projeto; nesse sentido, as equipes podem, para apoiar a percepção de valor dos projetos, alterar o foco das entregas para os resultados pretendidos.
CERTO
A principal evolução do PMBOK está em focar na melhoria do resultado do projeto, deixar de lado processos que são prescritivos por natureza e focar no valor total das entregas.
36
O índice de desempenho de prazos, uma medida que determina o grau de eficiência do cronograma, é obtido pela razão entre o valor planejado (por meio do diagrama de rede) e a quantidade de folga total (por meio do método do caminho crítico).
ERRADO
Índice de Desempenho de Prazo (IDP) é dado por uma divisão do valor agregado (VA) das entregas, em valor monetário, sobre o valor planejado (VP) das entregas.
IDP = VA/VP
37
As partes interessadas afetadas na avaliação das necessidades podem ser classificadas com base em uma matriz de responsabilidade como o modelo RACI (responsável, aprovador, consultado, informado).
CERTO
O modelo RACI (Responsável, Aprovador, Consultado, Informado) é frequentemente utilizado em análise de negócios para definir papéis e responsabilidades das partes interessadas. Ele ajuda a esclarecer quem é responsável por quê em um determinado processo ou atividade.
37
Em uma organização, pode haver a sobreposição entre os princípios gerais de gerenciamento e os princípios de gerenciamento de projetos.
CERTO
37
riscos negativos =
riscos positivos =
riscos negativos = ameaças
riscos positivos = oportunidades.
37
O domínio de desempenho da incerteza permite que reservas de custo e cronograma sejam utilizados de forma mais adequada para manter o alinhamento com os objetivos do projeto.
CERTO
37
Um ciclo de vida de projetos consiste de fases que conectam a entrega de valor do início ao fim do projeto.
CERTO
37
Portfólios e programas são exemplos de componentes que devem ser utilizados individual ou coletivamente para criar valor.
CERTO
Existem vários componentes, como portfólios, programas, projetos, produtos e operações, que podem ser usados individual e/ou coletivamente para criar valor. Quando juntos, o trabalho desses componentes compõe um sistema de entrega de valor alinhado à estratégia da organização
37
Os vários componentes que entregam valor funcionam como um sistema e devem estar alinhados às estratégias da organização.
CERTO
38
Os requisitos, quanto ao nível de abstração, são divididos em...........
Requisitos de Usuário (alto nível de abstração)
Requisitos de Sistema (baixo nível)
39
A documentação de requisitos deve conter duas perspectivas: uma voltada para o cliente, em linguagem compreensível por ele, e outra voltada para o desenvolvedor, em uma linguagem técnica de modelagem.
CERTO
Perspectiva = Abstração
a questão trata respectivamente dos requisitos de usuário e dos requisitos de sistema
40
Os requisitos, quanto à qualidade, são divididos quais? Cite exemplos
1) Requisitos NORMAIS: comuns, corriqueiros. Ex: "o sistema deve cadastrar usuário"
2) Requisitos ESPERADOS: implícitos, porém óbvios. Ex: "o sistema deve ser fácil de integarir"
3) Requisitos FASCINANTES: vão além da expectativa. Ex "tecla multitoque e correio de voz visual"
41
Pesquisadores observaram que os requisitos não-funcionais também podiam ser agrupados por meio de suas características comuns. Para tanto, criou-se a subclassificação dos requisitos não-funcionais em (cite exemplos):
1)
2)
3)
1) Requisitos de Produto: desempenho, confiabilidade, portabilidade e usabilidade.
2) Requisitos Organizacionais: padrões, linguagens, documentação
3) Requisitos Externos: interoperabilidade, éticos
42
A Interoperabilidade é um requisito de Produto, Organizacional ou Externo?
ela é um Requisito Externo, porque depende de padronizações fora de seu controle.
43
Requisitos ambientais, operacionais e de desenvolvimento fazem parte da categoria de requisitos ............................ (qual subclassificação de requisitos não funcionais)
organizacionais
44
Quais as 9 fases do processo de gerenciamento de requisitos?
1) Estudo de Viabilidade (Relatório de Viabilidade)
2) Elicitação e Análise (Modelos de Sistema)
2.1) Obtenção de Requisitos
2.2) Classificação e organização de requisitos
2.3) Priorização e negociação de requisitos
2.4) Documentação de requisitos
3) Especificação (Requisitos de Usuário e de Sistema)
4) Validação (Documento de Requisitos)
5) Gestão/Gerenciamento
45
Qual fase/atividade do processo de gerenciamento de requisitos?
envolve a coleção de requisitos não estruturados, agrupa os requisitos relacionados e os organiza em conjuntos coerentes.
Corresponde à atividade "Classificação e organização de requisitos", inserida dentro da fase de "Elicitação e Análise de Requisitos"
46
Quais as 4 atividades do processo de Elicitação e Análise de Requisitos?
Obtenção de Requisitos
Classificação e organização de requisitos
Priorização e negociação de requisitos
Documentação de requisitos
47
Qual fase/atividade do processo de gerenciamento de requisitos?
busca-se priorizar os requisitos e resolver conflitos por meio da negociação.
Corresponde à atividade "Priorização e negociação de requisitos", inserida dentro da fase de "Elicitação e Análise de Requisitos"
48
Cite os 3 tipos da técnica de elicitação de requisitos ENTREVISTA. Qual a diferença?
1) Pirâmide: perguntas detalhadas > perguntas genéricas
2) Funil: perguntas genéricas > perguntas detalhadas
3) Diamante: mescla de ambas. perguntas detalhadas > genéricas > detalhadas
49
Requisitos não funcionais (de Produtos X Externos X Organizacionais)
Requisitos de Confiabilidade
Requisitos de Produtos
50
Requisitos não funcionais (de Produtos X Externos X Organizacionais)
Requisitos de Eficiência
Requisitos de Produtos
50
Requisitos não funcionais (de Produtos X Externos X Organizacionais)
Requisitos de Proteção
Requisitos de Produtos
50
Requisitos não funcionais (de Produtos X Externos X Organizacionais)
Requisitos de Armazenamento
Requisitos de Produtos
50
Requisitos não funcionais (de Produtos X Externos X Organizacionais)
Requisitos de Usabilidade
Requisitos de Produtos
51
Requisitos não funcionais (de Produtos X Externos X Organizacionais)
Requisitos de Desempenho
Requisitos de Produtos
52
Requisitos não funcionais (de Produtos X Externos X Organizacionais)
Requisitos Éticos
Requisitos Externos
52
Requisitos não funcionais (de Produtos X Externos X Organizacionais)
Requisitos de Segurança
Requisitos Externos
52
Requisitos não funcionais (de Produtos X Externos X Organizacionais)
Requisitos regulatórios
Requisitos Externos
53
Requisitos não funcionais (de Produtos X Externos X Organizacionais)
Requisitos Legais
Requisitos Externos
54
Requisitos não funcionais (de Produtos X Externos X Organizacionais)
Requisitos Ambientais
Organizacional
55
Requisitos não funcionais (de Produtos X Externos X Organizacionais)
Requisitos Operacionais
Organizacional
56
Requisitos não funcionais (de Produtos X Externos X Organizacionais)
Requisitos de Implementação
Organizacional
57
A construção do backlog do produto envolve os seguintes conceitos, nessa ordem de hierarquia:
1)
2) Features
3) Histórias de Usuários
4)
épico -> varias features
cada feature -> varias historias de usuario
cada historia de usuario -> varias tarefas
cada tarefa -> varias subtarefas
58
A construção do backlog do produto envolve os seguintes conceitos, nessa ordem de hierarquia:
1) Épicos
2)
3)
4) Tarefa
épico -> varias features
cada feature -> varias historias de usuario
cada historia de usuario -> varias tarefas
cada tarefa -> varias subtarefas
59
Na elicitação e no gerenciamento de requisitos de um software, a abordagem que tem o potencial de oferecer explicações prováveis para contextualizar ou explicar uma necessidade que se apresenta como uma afirmação desconfortável e que se contrapõe às crenças e aos entendimentos iniciais da equipe de desenvolvimento é a storytelling.
CERTO
60
O storytelling, ou contar histórias, é uma técnica que envolve criar narrativas ou cenários para explicar e contextualizar requisitos de uma forma mais envolvente. Isso pode ajudar a equipe a compreender melhor as necessidades do usuário, mesmo quando essas necessidades são inicialmente contra-intuitivas ou desafiadoras para a equipe de desenvolvimento.
CERTO
61
Storytelling é um método de construção de narrativas com o objetivo de gerar conexões emocionais com o público-alvo.
CERTO
62
No contexto de storytelling, é fundamental mitigar as possibilidades de navegação por meio das interfaces e impor à experiência do usuário o sequenciamento estrito das atividades que constituem a sua história.
ERRADO
Storytelling é fundamentado em uma história envolvente, ajudando as empresas a comunicar insights de maneira mais impactante e eficaz.
não mitiga e não impõe
63
Considerados uma técnica de elicitação de requisitos, os casos de uso identificam os atores envolvidos, assim como interações individuais entre o sistema e seus usuários ou, ainda, com outros sistemas.
CERTO
64
Para o CESPE, outro nome dado à fase de Análise de Requisitos é ......................
obs: inclui a criação de cenários de interação do usuário com o sistema e a modelagem das classes envolvidas. O objetivo é definir as funções, características e restrições do software de maneira mais detalhada.
ELABORAÇÃO
65
As atividades do gerenciamento de requisitos incluem a análise e a negociação, a qual visa garantir que todos os requisitos do sistema tenham sido declarados de modo não ambíguo, sem inconsistências, omissões e erros.
ERRADO
quem visa garantir que todos os requisitos tenham sido declarados de modo não ambíguo, sem inconsistências, omissões e erros, é a Validação de Requisitos. Então, está tudo errado!
66
Existem dois tipos de métricas no contexto de desenvolvimento de produtos de software: as métricas diretas, que são realizadas em termos de atributos observáveis e e as métricas indiretas ou derivadas, que podem ser obtidas através de outras métricas.
Cite exemplos de métricas diretas e indiretas.
Diretas: custo, esforço, quantidade de linhas de código, total de defeitos durante um tempo.
Indiretas: complexidade, qualidade, funcionalidade, produtividade
67
Cite 5 objetivos/benefícios da utilização de métricas de software.
- fazer inferências sobre a qualidade do software
- estimar o esforço de desenvolvimento dos requisitos;
- estimar o custo de sustentação;
- analisar a viabilidade do projeto em relação ao escopo, cronograma e orçamentos disponíveis;
- acompanhar o progresso do projeto (no cronograma, no orçamento, etc);
- rastrear riscos;
- embasar decisões de ajuste de fluxo de trabalho (recursos, produtividade, etc);
- medir desempenho da equipe para subsidiar decisão de desenvolvimento ou compra;
- prever número de erros de componentes ou de linhas de código;
- medir habilidades da equipe e identificar áreas problemáticas;
- subsidiar contratos de remuneração por resultado;
68
A métrica de qualidade de código que mede a complexidade estrutural de um programa computando o número de caminhos linearmente independentes ao longo do código-fonte é denominada ..............................................
complexidade ciclomática
Calculada a partir da análise de um grafo dirigido, representa os possíveis caminhos de execução do programa, e desvios incondicionais contribuem para o aumento de valor desse cálculo.
69
O Relatório de complexidade de .................... gera métricas de software que são calculadas estaticamente sem execução do programa. A complexidade de Halstead pode ser usada para comparar a complexidade entre dois programas ou dois aplicativos.
Halstead
70
Qual atributo de qualidade ISO 25010?
o software está operacional e disponível para uso, quando necessário.
Confiabilidade
71
Qual atributo de qualidade ISO 25010?
A capacidade do software de manter seu nível de desempenho sob condições estabelecidas por um período de tempo.
Confiabilidade
72
Qual atributo de qualidade ISO 25010?
72
Qual atributo de qualidade ISO 25010?
73
Qual atributo de qualidade ISO 25010?
74
Qual atributo de qualidade ISO 25010?
74
Qual atributo de qualidade ISO 25010?
75
Qual atributo de qualidade ISO 25010?
76
De acordo com a norma ISO 25010, o modelo de qualidade em uso aplicado ao software descreve as seguintes características: adequação funcional, eficiência de desempenho, compatibilidade, usabilidade, confiabilidade, segurança, facilidade de manutenção e portabilidade.
ERRADO
O modelo de QUALIDADE EM USO possui os 5 atributos:
- Efetividade
- Eficiência
- Satisfação
- Segurança
- Cobertura de contexto
76
A APF é um método de medição de tamanho funcional, tendo como base os requisitos FUNCIONAIS do usuário.
CERTO
utilizada na medição de projetos de diferentes linguagens de programação e independente da tecnologia
77
na APF, IFPUG classifica a contagem em projeto de:
1)
2)
3)
1) desenvolvimento
2) melhoria
3) aplicação
78
A métrica de contagem de pontos por função, disseminada pelo IFPUG (International Function Point User Group) e constituída na evolução das métricas de linhas de código (LOC), visa estimar recursos para projetos de softwares orientados a objetos a partir de documentos de visão e de casos de uso.
ERRADO
ele visa estimar o tamanho funcional de um software a partir do ponto de vista do usuário de forma independente de tecnologias, como o paradigma de programação orientado a objetos
79
A apf mede diretamente o esforço, produtividade ou custo de um software?
Não, mas é possível correlacionar essas variáveis à métrica de pontos de função.
80
a Análise de Pontos de Função não mede diretamente esforço, produtividade, custo, qualidade, ENTRE OUTROS. No entanto, ela pode ser usada em conjunto com outras grandezas e dados históricos da organização para medir essas variáveis.
CERTO
Por exemplo: determinado programador desenvolve uma funcionalidade específica em 10 Horas/PF.
81
Na APF, NESMA classifica a contagem em:
1)
2)
3)
1) detalhada
2) estimativa
3) indicativa
82
Na APF, NESMA classifica a contagem em:
1) detalhada
2) estimativa
3) indicativa
1) detalhada (contagem de funções, entradas, saídas e complexidade)
2) estimativa (alto nível - não analisa complexidade)
3) indicativa (estimativa de alto nível e utiliza apenas funções de dados)
83
A NESMA (Netherlands Software Metrics Users Association) tem objetivos e ações bem próximos aos do IFPUG; ambos apresentam abordagens semelhantes para a aplicação da análise de pontos de função em projetos de melhoria de software e na fase inicial do desenvolvimento do produto de software.
ERRADO
projetos de melhoria ocorre apenas na IFPUG
84
Na técnica de Nesma utilizada para calcular a estimativa do tamanho do software, realiza-se um detalhamento de cada elemento e de cada função, o que torna a técnica mais trabalhosa que outras.
ERRADO
a estimativa é de alto nível e não analisa complexidade
é utilizada nas fases iniciais do sistema
os elementos usados são ALI, AIE, EE, CE, SE
85
Na técnica de Nesma utilizada para calcular a estimativa do tamanho do software, realiza-se um detalhamento de cada elemento e de cada função, o que torna a técnica mais trabalhosa que outras.
ERRADO
as abordagem de ESTIMATIVA e INDICATIVA não são trabalhosas, são formas simples, utiizadas no início do projeto ou quando não se tem precisão grande.
ao contrário da abordagem DETALHADA, que considera as funções
86
A NESMA – Netherlands Software Metrics Association reconhece três tipos de contagem de pontos de função (PF): detalhada, estimada e indicativa. Na contagem estimada toda função do tipo ALI e AIE tem sua complexidade funcional avaliada como média.
ERRADO
estimativa → não analisa a complexidade
(funções de dados → baixa, funções transacionais → média)
87
A NESMA – Netherlands Software Metrics Association reconhece três tipos de contagem de pontos de função (PF): detalhada, estimada e indicativa. Na contagem estimada toda função do tipo ALI e AIE tem sua complexidade funcional avaliada como baixa.
CERTO
estimativa → não analisa a complexidade
(funções de dados → baixa, funções transacionais → média)
88
A NESMA – Netherlands Software Metrics Association reconhece três tipos de contagem de pontos de função (PF): detalhada, estimada e indicativa. Na contagem estimada toda função transacional EE, SE, CE é avaliada como de complexidade funcional baixa.
ERRADO
estimativa → não analisa a complexidade
(funções de dados → baixa, funções transacionais → média)
89
A NESMA – Netherlands Software Metrics Association reconhece três tipos de contagem de pontos de função (PF): detalhada, estimada e indicativa. Na contagem estimada toda função transacional EE, SE, CE é avaliada como de complexidade funcional média.
CERTO
estimativa → não analisa a complexidade
(funções de dados → baixa, funções transacionais → média)
90
A Nesma oferece uma abordagem alternativa que não diferencia projetos de desenvolvimento e de manutenção, tratando todos os esforços de software igualmente.
CERTO
A diferenciação ocorre na IFPUG (melhoria, desenvolvimento e aplicação).
91
O Netherlands Software Metrics Users Association (NESMA) é uma organização mais recente que promove uma outra abordagem de contagem de pontos de função. IFPUG e NESMA possuem abordagens praticamente idênticas para o cálculo em projetos de desenvolvimento e aplicação, no entanto é bem diferente para Projetos de Melhoria. Ela utiliza o conceito de ..........................., que são basicamente um artifício para reduzir distorções na contagem de projetos de melhoria.
deflatores
92
O Netherlands Software Metrics Users Association (NESMA) utiliza o conceito de deflatores, que são basicamente um artifício para reduzir ........................... na contagem de projetos de melhoria.
reduzir distorções
93
Na contagem INDICATIVA do NESMA, para cada Arquivo Lógico Interno (ALI) identificado, contam-se ........... Pontos de Função; e para cada Arquivo de Interface Externa (AIE), contam-se ......... Pontos de Função.
contam-se 35 Pontos de Função; e para cada Arquivo de Interface Externa (AIE), contam-se 15 Pontos de Função.
PFNA = 35 x ALI + 15 x AIE
94
A contagem INDICATIVA do NESMA se baseia na premissa de que, para cada ALI, existem .............................................; e para cada AIE, existem .........................
ALI = 3EE + 2SE + 1 CE
AIE = 1SE + 1 SE
95
A abordagem de contagem ............................ do NESMA é bastante útil na análise de viabilidade de um projeto.
INDICATIVA
96
EE x SE x CE
atualização em lote das vendas efetuadas por uma loja em um dia
ENTRADA EXTERNA
97
EE x SE x CE
consulta que calcula o valor de um boleto a ser pago com juros e multa por atraso
SAÍDA EXTERNA
98
EE x SE x CE
listagem dos nomes de todos os clientes de um estabelecimento comercial
CONSULTA EXTERNA
99
A partir dos resultados apresentados pela métrica ponto por função, é possível estimar a quantidade de erros que serão encontrados durante o teste.
CERTO
100
EE x SE x CE
Telas de Ajuda
Consulta Externa
100
EE x SE x CE
Quais alteram comportamento do sistema?
EE: PODE alterar
SE: SEMPRE altera
CE: NUNCA altera
100
EE x SE x CE
Relatórios estatísticos
Saída Externa
100
EE x SE x CE
Telas de Login
Consulta Externa
