Selecionar segmento
Estude com questões de diferentes segmentos
Atenção: Isso limpará todos os campos já preenchidos no filtro!
Foram encontradas 1.558 questões
Resolva questões gratuitamente!
Junte-se a mais de 4 milhões de concurseiros!
Ano: 2014
Banca:
FCC
Órgão:
TRF - 3ª REGIÃO
Prova:
FCC - 2014 - TRF - 3ª REGIÃO - Analista Judiciário - Informática |
Q361016
Engenharia de Software
A figura abaixo mostra os quadrantes de testes ágeis.
Considere as definições dos quadrantes de testes ágeis:
I. Testes que focam no negócio e criticam o produto: são os testes de aceitação feitos na homologação do produto ou de suas partes, testes betas e testes exploratórios. São testes feitos não com o objetivo de dizer que o software funciona, mas de encontrar defeitos. Bons analistas de testes possuem técnicas para encontrar defeitos que poucos desenvolvedores conhecem.
II. Testes que focam na arquitetura e suportam o time: são os testes unitários e de componentes. Estes são realizados e são de responsabilidade dos próprios desenvolvedores. O papel do analista de testes nesse quadrante é o de apoiar, suportar e expandir conhecimentos entre os desenvolvedores sempre que necessário. De preferência isso é feito em par com o desenvolvedor no momento de elaborar os testes unitários automatizados.
III. Testes que focam na arquitetura e criticam o produto: são os testes de performance, de carga e de segurança. Esses são de responsabilidade dos analistas de testes e costumam ser feitos quando partes da aplicação já estão prontas e, especialmente, antes da entrada de um release em produção.
IV. Testes que focam no negócio e suportam o time: são testes funcionais diferenciados, que idealmente utilizam a técnica de Behavior-Driven Development e Acceptance Test-Driven Development. Isto é, são testes e cenários de exemplo realizados pelos testadores em conjunto com os clientes, usuários e analistas de negócio. Com base nesses exemplos e cenários os desenvolvedores terão melhores condições de desenvolver e entender os requisitos.O foco desses testes não é encontrar o maior número de defeitos e sim ajudar clientes e desenvolvedores a se entenderem melhor.
A associação correta entre as definições I, II, III e IV e os quadrantes Q1, Q2, Q3 e Q4 é apresentada em
Considere as definições dos quadrantes de testes ágeis:
I. Testes que focam no negócio e criticam o produto: são os testes de aceitação feitos na homologação do produto ou de suas partes, testes betas e testes exploratórios. São testes feitos não com o objetivo de dizer que o software funciona, mas de encontrar defeitos. Bons analistas de testes possuem técnicas para encontrar defeitos que poucos desenvolvedores conhecem.
II. Testes que focam na arquitetura e suportam o time: são os testes unitários e de componentes. Estes são realizados e são de responsabilidade dos próprios desenvolvedores. O papel do analista de testes nesse quadrante é o de apoiar, suportar e expandir conhecimentos entre os desenvolvedores sempre que necessário. De preferência isso é feito em par com o desenvolvedor no momento de elaborar os testes unitários automatizados.
III. Testes que focam na arquitetura e criticam o produto: são os testes de performance, de carga e de segurança. Esses são de responsabilidade dos analistas de testes e costumam ser feitos quando partes da aplicação já estão prontas e, especialmente, antes da entrada de um release em produção.
IV. Testes que focam no negócio e suportam o time: são testes funcionais diferenciados, que idealmente utilizam a técnica de Behavior-Driven Development e Acceptance Test-Driven Development. Isto é, são testes e cenários de exemplo realizados pelos testadores em conjunto com os clientes, usuários e analistas de negócio. Com base nesses exemplos e cenários os desenvolvedores terão melhores condições de desenvolver e entender os requisitos.O foco desses testes não é encontrar o maior número de defeitos e sim ajudar clientes e desenvolvedores a se entenderem melhor.
A associação correta entre as definições I, II, III e IV e os quadrantes Q1, Q2, Q3 e Q4 é apresentada em
Ano: 2014
Banca:
FCC
Órgão:
TRF - 3ª REGIÃO
Prova:
FCC - 2014 - TRF - 3ª REGIÃO - Analista Judiciário - Informática |
Q361012
Engenharia de Software
A figura abaixo mostra um diagrama com as atividades relativas ao levantamento de requisitos.
O diagrama e a lacuna da caixa em branco referem-se, respectivamente, aos diagramas UML de
O diagrama e a lacuna da caixa em branco referem-se, respectivamente, aos diagramas UML de
Ano: 2014
Banca:
FCC
Órgão:
TRF - 3ª REGIÃO
Prova:
FCC - 2014 - TRF - 3ª REGIÃO - Analista Judiciário - Informática |
Q361011
Engenharia de Software
A representação abaixo mostra como uma ferramenta de software realiza o controle de versões.
Considere a figura acima e analise as seguintes afirmativas sobre gerência de configuração e mudanças:
I. A figura sugere que cada vez que se modifica o projeto, a ferramenta registra o estado dos arquivos e armazena uma referência para essa captura. Se um dos arquivos não sofre alteração, seu estado não é alterado, apenas é criado um link para a versão anterior que já foi armazenada.
II. Um Sistema de Controle de Versões (SCV) combina procedimentos e ferramentas para gerir diferentes versões de objetos de configuração que são criados durante o processo de software. Um SCV implementa ou está ligado a um banco de dados de projeto (repositório) que guarda os objetos de configuração relevantes.
III. Um repositório de gestão de configuração de software é um conjunto de estruturas de dados que permite a uma equipe de software gerir as modificações de modo efetivo. Propicia funções que impedem que as informações sejam compartilhadas entre vários desenvolvedores para garantir a integridade dos dados, porém não consegue detectar diferenças entre arquivos binários.
Está correto o que consta APENAS em
Considere a figura acima e analise as seguintes afirmativas sobre gerência de configuração e mudanças:
I. A figura sugere que cada vez que se modifica o projeto, a ferramenta registra o estado dos arquivos e armazena uma referência para essa captura. Se um dos arquivos não sofre alteração, seu estado não é alterado, apenas é criado um link para a versão anterior que já foi armazenada.
II. Um Sistema de Controle de Versões (SCV) combina procedimentos e ferramentas para gerir diferentes versões de objetos de configuração que são criados durante o processo de software. Um SCV implementa ou está ligado a um banco de dados de projeto (repositório) que guarda os objetos de configuração relevantes.
III. Um repositório de gestão de configuração de software é um conjunto de estruturas de dados que permite a uma equipe de software gerir as modificações de modo efetivo. Propicia funções que impedem que as informações sejam compartilhadas entre vários desenvolvedores para garantir a integridade dos dados, porém não consegue detectar diferenças entre arquivos binários.
Está correto o que consta APENAS em
Ano: 2014
Banca:
FCC
Órgão:
TRF - 3ª REGIÃO
Prova:
FCC - 2014 - TRF - 3ª REGIÃO - Analista Judiciário - Informática |
Q361002
Engenharia de Software
Scrum é um modelo utilizado no desenvolvimento ágil de software. No Scrum um dos conceitos mais importantes é o sprint, que consiste em um ciclo de desenvolvimento que, em geral, vai de duas semanas a um mês.
No início de cada sprint é feito um
, no qual a equipe prioriza os elementos do 
a serem implementados e transfere esses elementos para o 
, ou seja, a lista de funcionalidades a serem implementadas no ciclo que se inicia.
A equipe se compromete a desenvolver as funcionalidades e o
se compromete a não trazer novas funcionalidades durante o mesmo sprint.
As lacunas I, II, III e IV são preenchidas, correta e respectivamente, por
No início de cada sprint é feito um
, no qual a equipe prioriza os elementos do a serem implementados e transfere esses elementos para o , ou seja, a lista de funcionalidades a serem implementadas no ciclo que se inicia. A equipe se compromete a desenvolver as funcionalidades e o
se compromete a não trazer novas funcionalidades durante o mesmo sprint. As lacunas I, II, III e IV são preenchidas, correta e respectivamente, por
Ano: 2014
Banca:
FCC
Órgão:
TRF - 3ª REGIÃO
Prova:
FCC - 2014 - TRF - 3ª REGIÃO - Analista Judiciário - Informática |
Q361000
Engenharia de Software
Considere as seguintes atividades:
1. Compreensão do domínio: os analistas devem desenvolver sua compreensão do domínio da aplicação.
2. Coleta de requisitos: processo de interagir com os stakeholders do sistema para descobrir seus requisitos.
3. Classificação: atividade que considera o conjunto não estruturado dos requisitos e os organiza em grupos coerentes.
4. Resolução de conflitos: Solucionar conflitos decorrentes do envolvimento de múltiplos stakeholders.
5. Definição das prioridades: envolve a interação com os stakeholders para a definição dos requisitos mais importantes.
6. Descarte de requisitos: atividade de descartar requisitos menos importantes, baseando-se nas indicações dos stakeholders.
7. Verificação de requisitos: os requisitos são verificados para descobrir se estão completos e consistentes e se estão em concordância com o que os stakeholders desejam do sistema.
8. Modelagem de requisitos: os requisitos são modelados utilizando-se o diagrama de casos de uso e de sequência da UML.
Faz parte do processo de levantamento e análise de requisitos o que consta em APENAS 1, 2,
1. Compreensão do domínio: os analistas devem desenvolver sua compreensão do domínio da aplicação.
2. Coleta de requisitos: processo de interagir com os stakeholders do sistema para descobrir seus requisitos.
3. Classificação: atividade que considera o conjunto não estruturado dos requisitos e os organiza em grupos coerentes.
4. Resolução de conflitos: Solucionar conflitos decorrentes do envolvimento de múltiplos stakeholders.
5. Definição das prioridades: envolve a interação com os stakeholders para a definição dos requisitos mais importantes.
6. Descarte de requisitos: atividade de descartar requisitos menos importantes, baseando-se nas indicações dos stakeholders.
7. Verificação de requisitos: os requisitos são verificados para descobrir se estão completos e consistentes e se estão em concordância com o que os stakeholders desejam do sistema.
8. Modelagem de requisitos: os requisitos são modelados utilizando-se o diagrama de casos de uso e de sequência da UML.
Faz parte do processo de levantamento e análise de requisitos o que consta em APENAS 1, 2,
Ano: 2014
Banca:
FCC
Órgão:
TRF - 3ª REGIÃO
Prova:
FCC - 2014 - TRF - 3ª REGIÃO - Analista Judiciário - Informática |
Q360999
Engenharia de Software
Os modelos ágeis de desenvolvimento de software têm menos ênfase nas definições de atividades e mais ênfase na pragmática e nos fatores humanos do desenvolvimento. Um destes modelos enfatiza o uso de orientação a objetos e possui apenas duas grandes fases: 1 - Concepção e Planejamento e 2 - Construção. A fase de Concepção e Planejamento possui três disciplinas (chamadas de processos): Desenvolver Modelo Abrangente, Construir Lista de Funcionalidades e Planejar por funcionalidade. Já a fase de Construção incorpora duas disciplinas (processos): Detalhar por Funcionalidade e Construir por Funcionalidade.
O texto acima apresenta a metodologia ágil conhecida como
O texto acima apresenta a metodologia ágil conhecida como
Ano: 2014
Banca:
FCC
Órgão:
TRF - 3ª REGIÃO
Prova:
FCC - 2014 - TRF - 3ª REGIÃO - Analista Judiciário - Informática |
Q360998
Engenharia de Software
Sabendo que a Análise de Pontos de Função (APF) permite medir o tamanho funcional do software, considere que no desenvolvimento de um software foram fornecidos os seguintes dados:
Ao se completar a tabela 4, o total de pontos de função das transações é
Ao se completar a tabela 4, o total de pontos de função das transações é
Ano: 2014
Banca:
FCC
Órgão:
TRF - 3ª REGIÃO
Prova:
FCC - 2014 - TRF - 3ª REGIÃO - Analista Judiciário - Informática |
Q360996
Engenharia de Software
Considere as classes criadas na linguagem Java.
O diagrama de classe que representa corretamente a relação entre ClasseB e ClasseC está representado em
O diagrama de classe que representa corretamente a relação entre ClasseB e ClasseC está representado em
Ano: 2014
Banca:
FCC
Órgão:
TRF - 3ª REGIÃO
Prova:
FCC - 2014 - TRF - 3ª REGIÃO - Analista Judiciário - Informática - Banco de Dados |
Q356032
Engenharia de Software
A utilização de ferramentas CASE para modelagem de dados é muito importante para a qualidade do modelo, bem como para garantir uma documentação atualizada e maior facilidade de manutenção de sistemas em produção. Existem no mercado várias ferramentas CASE para este propósito, entre comerciais e gratuitas como as citadas abaixo:
I. É uma ferramenta gratuita e de código aberto para modelagem de dados que trabalha com o modelo lógico, desenvolvida pela fabFORCE sob a licença GNU GPL. É um software multiplataforma (Windows e Linux) implementado em Delphi/Kylix. Além de permitir a modelagem, criação e manutenção de bancos de dados, esta ferramenta possibilita também a engenharia reversa, gerando o modelo de dados a partir de um banco existente, e ainda possibilita o sincronismo entre o modelo e o banco. Foi construída originalmente para oferecer suporte ao MySQL, porém também suporta outros SGBDs como Oracle, SQL Server, SQLite e outros que permitam acesso via ODBC.
II. É uma ferramenta desenvolvida pela empresa Popkin Software. Tem a vantagem de ser uma ferramenta flexível para a empresa que trabalha com a Análise Estruturada de Sistemas. Tem como característica importante o fato de ser uma ferramenta workgroup, ou seja, é possível compartilhar um mesmo projeto entre diversos analistas de desenvolvimento. Em um único repositório são colocadas todas as informações do projeto. Os projetos podem ser agrupados por sistemas e subsistemas; existe uma enciclopédia do SA correspondente a cada um deles. Essas enciclopédias ficam armazenadas na rede de acordo com as áreas de trabalho dos analistas.
III. É uma ferramenta CASE para modelagem de dados relacional e dimensional, que permite a construção de modelos de dados lógicos e modelos de dados físicos, comercializada pela CA (Computer Associates). Permite ao usuário trabalhar com três tipos de modelos de dados: somente lógico (Logical Only), somente físico (Physical Only) ou lógico e físico (Logical/Physical). Antes da versão 4, todo modelo de dados tinha, obrigatoriamente, o modelo lógico e o modelo físico juntos, ou seja, o modelo sempre era do tipo Logical/Physical. Em versão recente, foi incluído o recurso de derivação de modelos que permite gerar um modelo de dados a partir de outro. Também oferece o recurso de sincronização entre os modelos de dados (Sync with Model Source).
As ferramentas CASE I, II e III são, respectivamente:
I. É uma ferramenta gratuita e de código aberto para modelagem de dados que trabalha com o modelo lógico, desenvolvida pela fabFORCE sob a licença GNU GPL. É um software multiplataforma (Windows e Linux) implementado em Delphi/Kylix. Além de permitir a modelagem, criação e manutenção de bancos de dados, esta ferramenta possibilita também a engenharia reversa, gerando o modelo de dados a partir de um banco existente, e ainda possibilita o sincronismo entre o modelo e o banco. Foi construída originalmente para oferecer suporte ao MySQL, porém também suporta outros SGBDs como Oracle, SQL Server, SQLite e outros que permitam acesso via ODBC.
II. É uma ferramenta desenvolvida pela empresa Popkin Software. Tem a vantagem de ser uma ferramenta flexível para a empresa que trabalha com a Análise Estruturada de Sistemas. Tem como característica importante o fato de ser uma ferramenta workgroup, ou seja, é possível compartilhar um mesmo projeto entre diversos analistas de desenvolvimento. Em um único repositório são colocadas todas as informações do projeto. Os projetos podem ser agrupados por sistemas e subsistemas; existe uma enciclopédia do SA correspondente a cada um deles. Essas enciclopédias ficam armazenadas na rede de acordo com as áreas de trabalho dos analistas.
III. É uma ferramenta CASE para modelagem de dados relacional e dimensional, que permite a construção de modelos de dados lógicos e modelos de dados físicos, comercializada pela CA (Computer Associates). Permite ao usuário trabalhar com três tipos de modelos de dados: somente lógico (Logical Only), somente físico (Physical Only) ou lógico e físico (Logical/Physical). Antes da versão 4, todo modelo de dados tinha, obrigatoriamente, o modelo lógico e o modelo físico juntos, ou seja, o modelo sempre era do tipo Logical/Physical. Em versão recente, foi incluído o recurso de derivação de modelos que permite gerar um modelo de dados a partir de outro. Também oferece o recurso de sincronização entre os modelos de dados (Sync with Model Source).
As ferramentas CASE I, II e III são, respectivamente:
Q1205520
Engenharia de Software
O relatório técnico é um documento que descreve formalmente o progresso ou resultado de pesquisa científica e/ou técnica. A sua redação deve ser formada por pré-texto, texto e pós-texto. Entre os elementos que compõem um relatório são exemplos de um elemento obrigatório e um opcional, respectivamente,
Q841661
Engenharia de Software
Considere as seguintes premissas:
I. O código fonte não tem dono e ninguém precisa ter permissão concedida para poder modificar o mesmo. O objetivo com isto é fazer a equipe conhecer todas as partes do sistema.
II. Geralmente a dupla é criada com alguém sendo iniciado na linguagem e a outra pessoa funcionando como um instrutor. Como é apenas um computador, o novato é que fica à frente fazendo a codificação, e o instrutor acompanha ajudando a desenvolver suas habilidades. Dessa forma o programa sempre é revisto por duas pessoas, evitando e diminuindo assim a possibilidade de erros.
Fazem parte do modelo de desenvolvimento
Q841658
Engenharia de Software
No modelo de desenvolvimento ágil Scrum, o Sprint Review é efetuado no final do Sprint para inspecionar o incremento e
adaptar o backlog do produto, caso seja necessário. Alguns elementos são incluídos no Sprint Review, EXCETO:
Q841654
Engenharia de Software
A UML é composta por diversos diagramas, dentre eles, o diagrama de sequência,
Q807367
Engenharia de Software
A arquitetura de software de um sistema é a estrutura do sistema, que compreende os elementos, as relações entre eles, e as
propriedades desses elementos e relações que são visíveis externamente. A linguagem UML pode ser utilizada para modelar e
documentar arquiteturas de software por meio de diagramas. Dentre eles, os principais diagramas que permitem modelar os
aspectos físicos de um sistema orientado a objetos são diagramas de
Q807362
Engenharia de Software
Considere:
Caso 1:
Pedro foi contratado para realizar testes de software na empresa B. Realizava um conjunto de testes na interface do software
focados em exercitar os requisitos funcionais. Na bateria de testes que realizava, procurava encontrar funções incorretas ou
faltando, erros de interface, erros em estruturas de dados, erros em acesso a base de dados externas, erros de comportamento
e de desempenho e erros de inicialização e término.
Caso 2:
Paulo foi contratado para realizar testes de software na empresa C. Realizava testes nos caminhos lógicos do software e nas
colaborações entre componentes exercitando conjuntos específicos de condições e/ou ciclos. Testava todos os caminhos
independentes dos módulos pelo menos uma vez, exercitava as decisões lógicas nos seus estados verdadeiro ou falso e
exercitava estruturas internas para assegurar a sua validade.
Pedro realizava testes
Pedro realizava testes
Q807361
Engenharia de Software
Sobre os processos ágeis de desenvolvimento de software XP e Scrum, considere:
I. Emprega uma abordagem orientada a objetos como seu paradigma de desenvolvimento preferido e envolve um conjunto de regras e práticas constantes no contexto de quatro atividades metodológicas: planejamento, projeto, codificação e testes.
II. Seus princípios são usados para orientar as atividades de desenvolvimento dentro de um processo que incorpora as seguintes atividades estruturais: requisitos, análise, projeto, evolução e entrega. Em cada atividade metodológica ocorrem tarefas a realizar dentro de um padrão de processo chamado sprint.
III. Faz uso do teste de unidades como sua tática de testes primária. À medida que cada classe é desenvolvida, a equipe desenvolve um teste de unidade para exercitar cada operação de acordo com a sua funcionalidade especificada. À medida que um incremento é entregue a um cliente as histórias de usuários ou casos de uso implementados pelo incremento são usados como base para testes de aceitação.
IV. O jogo do planejamento se inicia com a atividade de ouvir (que constitui uma atividade de levantamento de requisitos). Essa atividade conduz à criação de um conjunto de histórias de usuários que descreve o resultado, as características e a funcionalidade requisitados para o software a ser construído.
A associação correta entre cada item e o respectivo processo ágil é
I. Emprega uma abordagem orientada a objetos como seu paradigma de desenvolvimento preferido e envolve um conjunto de regras e práticas constantes no contexto de quatro atividades metodológicas: planejamento, projeto, codificação e testes.
II. Seus princípios são usados para orientar as atividades de desenvolvimento dentro de um processo que incorpora as seguintes atividades estruturais: requisitos, análise, projeto, evolução e entrega. Em cada atividade metodológica ocorrem tarefas a realizar dentro de um padrão de processo chamado sprint.
III. Faz uso do teste de unidades como sua tática de testes primária. À medida que cada classe é desenvolvida, a equipe desenvolve um teste de unidade para exercitar cada operação de acordo com a sua funcionalidade especificada. À medida que um incremento é entregue a um cliente as histórias de usuários ou casos de uso implementados pelo incremento são usados como base para testes de aceitação.
IV. O jogo do planejamento se inicia com a atividade de ouvir (que constitui uma atividade de levantamento de requisitos). Essa atividade conduz à criação de um conjunto de histórias de usuários que descreve o resultado, as características e a funcionalidade requisitados para o software a ser construído.
A associação correta entre cada item e o respectivo processo ágil é
Q807360
Engenharia de Software
Uma estratégia de teste que é preferida por grande parte das equipes de software assume uma visão incremental do teste,
começando com o teste das unidades individuais do programa, passando para os testes destinados a facilitar a integração de
unidades e culminando com testes que usam o sistema concluído.
No Processo Unificado (PU), os testes de unidades e testes de integração são realizados na fase de
Q807359
Engenharia de Software
A equipe de TI da empresa A desenvolveu um software onde os requisitos iniciais foram razoavelmente bem definidos, porém,
devido ao escopo geral do trabalho de desenvolvimento, o uso de um processo de software puramente linear não pôde ser
utilizado, optando-se por combinar elementos dos fluxos de processos lineares e paralelos. Durante o processo de desenvolvimento
foi liberada uma série de versões que ofereciam, progressivamente, maior funcionalidade para o cliente à medida que
cada versão era entregue. A primeira versão entregue contemplava o atendimento aos requisitos básicos, porém, muitos recursos
complementares foram entregues em versões posteriores. Após a primeira versão ser entregue, usada e avaliada pelo cliente,
foi realizado um planejamento para que a entrega da versão seguinte já considerasse a modificação na versão essencial para
melhor se adequar às necessidades do cliente e a entrega de recursos e funcionalidades adicionais. Esse processo foi repetido
após a liberação de cada versão, ate que o software estivesse completo.
Nota-se no texto que o modelo de processo utilizado pela equipe de TI da empresa A teve seu foco voltado para a entrega de
um produto operacional em cada versão. As primeiras versões foram partes do produto final que realmente possuíam capacidade
para atender aos usuários e oferecer uma plataforma para a avaliação
O texto permite concluir que foi utilizado o modelo de processo
Q807358
Engenharia de Software
Para se desenvolver um software de qualidade normalmente utiliza-se uma ou mais metodologias para as atividades, ações e tarefas
necessárias. Essas metodologias podem ser consideradas processos de software. Sobre esses processos, é correto afirmar:
Q794187
Engenharia de Software
Uma classe define os atributos e os métodos de um conjunto de objetos. Todos os objetos desta classe (instâncias desta classe)
compartilham o mesmo comportamento e possuem o mesmo conjunto de atributos (cada objeto possui seu próprio conjunto).
Na UML,
Conheça nossos planos