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:
TRT - 2ª REGIÃO (SP)
Prova:
FCC - 2014 - TRT - 2ª REGIÃO (SP) - Analista Judiciário - Tecnologia da Informação |
Q472301
Engenharia de Software
Há diversos processos e práticas ágeis de desenvolvimento de software. Considere:
I. Seu objetivo é criar um “código limpo que funcione”. Trabalha com a estratégia Red - Green - Refactor:
- Codifique o teste;
- Faça-o compilar e executar. O teste não deve passar (Red).
- Implemente o requisito e faça o teste passar (Green).
- Refatore o código (Refactor).
II. Suas práticas, regras e valores garantem um agradável ambiente de desenvolvimento de software para os seus seguidores, que são conduzidos pelos princípios básicos:
- Comunicação - manter o melhor relacionamento possível entre clientes e desenvolvedores, preferindo conversas pessoais a outros meios de comunicação;
- Simplicidade - implementar apenas requisitos atuais, evitando adicionar funcionalidades que podem ser importantes somente no futuro;
- Feedback - o desenvolvedor terá informações constantes do cliente e do código, em que testes constantes indicam os erros tanto individuais quanto do software integrado;
- Coragem - encorajar as pessoas que não possuem facilidade de comunicação e bom relacionamento interpessoal, encorajar a equipe a experimentar e buscar novas soluções, além de encorajar a obtenção de feedback do cliente.
III. Objetiva capturar os critérios de aceitação para as funcionalidades em desenvolvimento. Trabalha com as seguintes etapas:
- Discutir (Discuss): discussão colaborativa com a equipe visando elicitar os critérios de aceitação.
- Refinar (Distill): refinamento dos critérios de aceitação em um conjunto concreto de cenários/exemplos de uso descrevendo o comportamento esperado da aplicação em uma linguagem comum a todos os membros da equipe.
- Desenvolver (Develop): transformação dos testes de aceitação (descrevendo o comportamento esperado do software) em testes/especificação automatizados.
IV. Suas práticas incluem:
- Envolver as partes interessadas no processo através de Outside-in Development.
- Usar exemplos para descrever o comportamento de uma aplicação ou unidades de código.
- Automatizar os exemplos para prover um feedback rápido e testes de regressão.
- Usar o verbo deve (should) ao descrever o comportamento de software para ajudar a esclarecer responsabilidades e permitir que funcionalidades sejam questionadas.
- Usar dublês de teste (mocks, stubs, fakes, dummies, spies) para auxiliar na colaboração entre módulos e códigos que ainda não foram escritos.
Os processos ágeis I, II, III e IV são, correta e respectivamente, denominados:
I. Seu objetivo é criar um “código limpo que funcione”. Trabalha com a estratégia Red - Green - Refactor:
- Codifique o teste;
- Faça-o compilar e executar. O teste não deve passar (Red).
- Implemente o requisito e faça o teste passar (Green).
- Refatore o código (Refactor).
II. Suas práticas, regras e valores garantem um agradável ambiente de desenvolvimento de software para os seus seguidores, que são conduzidos pelos princípios básicos:
- Comunicação - manter o melhor relacionamento possível entre clientes e desenvolvedores, preferindo conversas pessoais a outros meios de comunicação;
- Simplicidade - implementar apenas requisitos atuais, evitando adicionar funcionalidades que podem ser importantes somente no futuro;
- Feedback - o desenvolvedor terá informações constantes do cliente e do código, em que testes constantes indicam os erros tanto individuais quanto do software integrado;
- Coragem - encorajar as pessoas que não possuem facilidade de comunicação e bom relacionamento interpessoal, encorajar a equipe a experimentar e buscar novas soluções, além de encorajar a obtenção de feedback do cliente.
III. Objetiva capturar os critérios de aceitação para as funcionalidades em desenvolvimento. Trabalha com as seguintes etapas:
- Discutir (Discuss): discussão colaborativa com a equipe visando elicitar os critérios de aceitação.
- Refinar (Distill): refinamento dos critérios de aceitação em um conjunto concreto de cenários/exemplos de uso descrevendo o comportamento esperado da aplicação em uma linguagem comum a todos os membros da equipe.
- Desenvolver (Develop): transformação dos testes de aceitação (descrevendo o comportamento esperado do software) em testes/especificação automatizados.
IV. Suas práticas incluem:
- Envolver as partes interessadas no processo através de Outside-in Development.
- Usar exemplos para descrever o comportamento de uma aplicação ou unidades de código.
- Automatizar os exemplos para prover um feedback rápido e testes de regressão.
- Usar o verbo deve (should) ao descrever o comportamento de software para ajudar a esclarecer responsabilidades e permitir que funcionalidades sejam questionadas.
- Usar dublês de teste (mocks, stubs, fakes, dummies, spies) para auxiliar na colaboração entre módulos e códigos que ainda não foram escritos.
Os processos ágeis I, II, III e IV são, correta e respectivamente, denominados:
Ano: 2014
Banca:
FCC
Órgão:
TJ-AP
Prova:
FCC - 2014 - TJ-AP - Analista Judiciário - Área Apoio Especializado - Tecnologia da Informação - Desenvolvimento de Sistemas |
Q467795
Engenharia de Software
Texto associado
Considere o processo de negócio e o diagrama abaixo.
É correto afirmar:
Ano: 2014
Banca:
FCC
Órgão:
TJ-AP
Prova:
FCC - 2014 - TJ-AP - Analista Judiciário - Área Apoio Especializado - Tecnologia da Informação - Desenvolvimento de Sistemas |
Q467792
Engenharia de Software
Na Análise de Pontos de Função, são contados diversos componentes, dentre os quais NÃO se encontra(m):
Ano: 2014
Banca:
FCC
Órgão:
TJ-AP
Prova:
FCC - 2014 - TJ-AP - Analista Judiciário - Área Apoio Especializado - Tecnologia da Informação - Desenvolvimento de Sistemas |
Q467791
Engenharia de Software
Um analista judiciário está participando de um debate sobre metodologias ágeis a serem utilizadas no Tribunal de Justiça do Amapá. Ele afirma corretamente que
Ano: 2014
Banca:
FCC
Órgão:
TJ-AP
Prova:
FCC - 2014 - TJ-AP - Analista Judiciário - Área Apoio Especializado - Tecnologia da Informação - Desenvolvimento de Sistemas |
Q467790
Engenharia de Software
O Scrum é um framework ágil para suportar o desenvolvimento e manutenção de produtos complexos. Nesta abordagem,
Ano: 2014
Banca:
FCC
Órgão:
TJ-AP
Prova:
FCC - 2014 - TJ-AP - Analista Judiciário - Área Apoio Especializado - Tecnologia da Informação - Desenvolvimento de Sistemas |
Q467789
Engenharia de Software
No Tribunal de Justiça do Estado do Amapá, um software está passando por um teste no qual são verificadas as suas funcionalidades sem preocupação com os detalhes de implementação. Nesse processo de teste estão sendo realizadas a identificação das funcionalidades que o software deve realizar e a criação dos casos de testes capazes de checar se essas funcionalidades estão sendo realizadas adequadamente. Trata-se do teste
Ano: 2014
Banca:
FCC
Órgão:
TJ-AP
Prova:
FCC - 2014 - TJ-AP - Analista Judiciário - Área Apoio Especializado - Tecnologia da Informação - Desenvolvimento de Sistemas |
Q467788
Engenharia de Software
Um analista judiciário do Tribunal de Justiça do Amapá precisa utilizar um diagrama que permite adaptar o metamodelo UML para diversas plataformas como Java EE ou .NET ou para diferentes domínios como aplicações em tempo real e modelagem de processos de negócio. Este diagrama precisa permitir a definição de estereótipos customizados e restrições. Dentre os diagramas da UML 2.5, o que melhor atende estas necessidades é o Diagrama de
Ano: 2014
Banca:
FCC
Órgão:
Câmara Municipal de São Paulo - SP
Prova:
FCC - 2014 - Câmara Municipal de São Paulo - SP - Consultor Técnico Legislativo - Informática |
Q464052
Engenharia de Software
A UML é uma linguagem que descreve um conjunto de diagramas para a modelagem de sistemas orientados a objetos. Dentre estes diagramas estão os diagramas de estados que são
Ano: 2014
Banca:
FCC
Órgão:
Câmara Municipal de São Paulo - SP
Prova:
FCC - 2014 - Câmara Municipal de São Paulo - SP - Consultor Técnico Legislativo - Informática |
Q464050
Engenharia de Software
A declaração do escopo do projeto é um documento-base que deve expressar a concordância entre o cliente e o gerente de projeto para que, a partir dele, o projeto como um todo possa ser planejado. A declaração do escopo do projeto, normalmente,
Ano: 2014
Banca:
FCC
Órgão:
Câmara Municipal de São Paulo - SP
Prova:
FCC - 2014 - Câmara Municipal de São Paulo - SP - Consultor Técnico Legislativo - Informática |
Q464049
Engenharia de Software
O gerenciamento de requisitos em grandes sistemas envolve o processamento de grandes volumes de informações sobre requisitos, o que exige o uso de apoio automatizado. As ferramentas de software para esse gerenciamento devem ser escolhidas durante a fase de planejamento de gerenciamento de requisitos. As ferramentas de apoio são usadas, principalmente, para
Ano: 2014
Banca:
FCC
Órgão:
Câmara Municipal de São Paulo - SP
Prova:
FCC - 2014 - Câmara Municipal de São Paulo - SP - Consultor Técnico Legislativo - Informática |
Q464048
Engenharia de Software
O desenvolvimento de uma solução para um sistema de informação baseia-se no processo de resolução de problemas. Esse processo pode ser descrito em quatro passos:
1. Definição e entendimento do problema.
2. Desenvolvimento de soluções alternativas.
3. Escolha da melhor solução.
4. Implementação da solução.
A seguir são descritas três atividades que ocorrem neste processo:
I. Define cuidadosamente os objetivos do sistema modificado ou do novo sistema e desenvolve uma descrição detalhada das funções que um novo sistema deve desempenhar.
II. Define se cada alternativa de solução é um bom investimento, se a tecnologia necessária para o sistema está disponível e pode ser administrada pela equipe designada da empresa, e se a organização é capaz de acomodar as mudanças introduzidas pelo sistema.
III. É a “planta” ou modelo para a solução de um sistema de informação e consiste em todas as especificações que executarão as funções identificadas durante a análise de sistemas. Essas especificações devem abordar todos os componentes organizacionais, tecnológicos e humanos da solução.
A associação correta das atividades I, II e III aos passos ao qual pertencem no processo de resolução de problemas está, correta e respectivamente, apresentada em
1. Definição e entendimento do problema.
2. Desenvolvimento de soluções alternativas.
3. Escolha da melhor solução.
4. Implementação da solução.
A seguir são descritas três atividades que ocorrem neste processo:
I. Define cuidadosamente os objetivos do sistema modificado ou do novo sistema e desenvolve uma descrição detalhada das funções que um novo sistema deve desempenhar.
II. Define se cada alternativa de solução é um bom investimento, se a tecnologia necessária para o sistema está disponível e pode ser administrada pela equipe designada da empresa, e se a organização é capaz de acomodar as mudanças introduzidas pelo sistema.
III. É a “planta” ou modelo para a solução de um sistema de informação e consiste em todas as especificações que executarão as funções identificadas durante a análise de sistemas. Essas especificações devem abordar todos os componentes organizacionais, tecnológicos e humanos da solução.
A associação correta das atividades I, II e III aos passos ao qual pertencem no processo de resolução de problemas está, correta e respectivamente, apresentada em
Ano: 2014
Banca:
FCC
Órgão:
TRT - 1ª REGIÃO (RJ)
Prova:
FCC - 2014 - TRT - 1ª REGIÃO (RJ) - Técnico Judiciário - Tecnologia da Informação |
Q463762
Engenharia de Software
Considerando o gerenciamento de mudanças de software, há um marco que define que quando uma especificação ou produto é formalmente revisto e aprovado. Esses artefatos só podem ser posteriormente modificados por intermédio de procedimentos formais de controle de modificações. Tal conceito recebe a denominação de marco
Ano: 2014
Banca:
FCC
Órgão:
TRT - 1ª REGIÃO (RJ)
Prova:
FCC - 2014 - TRT - 1ª REGIÃO (RJ) - Técnico Judiciário - Tecnologia da Informação |
Q463755
Engenharia de Software
Na programação orientada a objetos utiliza-se o conceito de encapsulamento, segundo o qual
Ano: 2014
Banca:
FCC
Órgão:
TRT - 13ª Região (PB)
Prova:
FCC - 2014 - TRT - 13ª Região (PB) - Analista Judiciário - Tecnologia da Informação |
Q455287
Engenharia de Software
Considere:
I. Para cada processo aberto deve ser emitido um aviso eletrônico para o juizado correspondente.
II. Os tempos de resposta do sistema não podem exceder a 20 milissegundos, em qualquer hipótese.
III. A disponibilidade da rede de dados deve ser 24 × 7.
IV. Cada juiz deve ser capaz de realizar uma busca de processos, tanto pelo número quanto pela data ou pelo responsável.
V. Toda modificação realizada nos programas do sistema devem seguir os padrões estabelecidos na Gestão de Mudanças.
É exemplo de requisito não funcional o que consta APENAS em
I. Para cada processo aberto deve ser emitido um aviso eletrônico para o juizado correspondente.
II. Os tempos de resposta do sistema não podem exceder a 20 milissegundos, em qualquer hipótese.
III. A disponibilidade da rede de dados deve ser 24 × 7.
IV. Cada juiz deve ser capaz de realizar uma busca de processos, tanto pelo número quanto pela data ou pelo responsável.
V. Toda modificação realizada nos programas do sistema devem seguir os padrões estabelecidos na Gestão de Mudanças.
É exemplo de requisito não funcional o que consta APENAS em
Ano: 2014
Banca:
FCC
Órgão:
TRT - 13ª Região (PB)
Prova:
FCC - 2014 - TRT - 13ª Região (PB) - Analista Judiciário - Tecnologia da Informação |
Q455286
Engenharia de Software
Considere o seguinte caso:
Observando o trâmite de processos no tribunal, Marta percebeu que tanto advogados quanto juízes realizavam análises nos diversos pareceres constantes dos processos. Com sua experiência como analista ela deduziu que uma possível informatização dos processos poderia contemplar uma classe chamada Advogado e outra chamada Juiz, tendo como base uma classe comum chamada Pessoa, com um método chamado AnalisarParecer. Este método (definido na classe comum) se comportaria de maneira diferente para as chamadas feitas a partir de uma instância de Advogado e para as chamadas feitas a partir de uma instância de Juiz, em razão deles terem responsabilidades diferentes em sua forma de analisar e opinar sobre os pareceres.
Pela observação do método e seu comportamento, o princípio da orientação a objetos aplicável no caso, fundamentalmente, é
Observando o trâmite de processos no tribunal, Marta percebeu que tanto advogados quanto juízes realizavam análises nos diversos pareceres constantes dos processos. Com sua experiência como analista ela deduziu que uma possível informatização dos processos poderia contemplar uma classe chamada Advogado e outra chamada Juiz, tendo como base uma classe comum chamada Pessoa, com um método chamado AnalisarParecer. Este método (definido na classe comum) se comportaria de maneira diferente para as chamadas feitas a partir de uma instância de Advogado e para as chamadas feitas a partir de uma instância de Juiz, em razão deles terem responsabilidades diferentes em sua forma de analisar e opinar sobre os pareceres.
Pela observação do método e seu comportamento, o princípio da orientação a objetos aplicável no caso, fundamentalmente, é
Ano: 2014
Banca:
FCC
Órgão:
TRT - 13ª Região (PB)
Prova:
FCC - 2014 - TRT - 13ª Região (PB) - Analista Judiciário - Tecnologia da Informação |
Q455285
Engenharia de Software
Considere:
I. Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas.
II. Pessoas relacionadas a negócios e desenvolvedores devem trabalhar separadamente durante todo o curso do projeto.
III. O método mais eficiente e eficaz de transmitir informações para e por dentro de um time de desenvolvimento, é por meio do correio eletrônico.
IV. A maior prioridade é satisfazer o cliente através da entrega adiantada e contínua de software de valor.
É coerente com os princípios que embasam o manifesto ágil (desenvolvimento ágil de software) o que consta APENAS em
I. Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas.
II. Pessoas relacionadas a negócios e desenvolvedores devem trabalhar separadamente durante todo o curso do projeto.
III. O método mais eficiente e eficaz de transmitir informações para e por dentro de um time de desenvolvimento, é por meio do correio eletrônico.
IV. A maior prioridade é satisfazer o cliente através da entrega adiantada e contínua de software de valor.
É coerente com os princípios que embasam o manifesto ágil (desenvolvimento ágil de software) o que consta APENAS em
Ano: 2014
Banca:
FCC
Órgão:
TRT - 13ª Região (PB)
Prova:
FCC - 2014 - TRT - 13ª Região (PB) - Analista Judiciário - Tecnologia da Informação |
Q455284
Engenharia de Software
No Scrum, um projeto se inicia com uma visão simples do produto que será desenvolvido. A visão pode ser vaga a princípio e ir tornando-se clara aos poucos. O 
então, transforma essa visão em uma lista de requisitos funcionais e não-funcionais para que, quando forem desenvolvidos, reflitam essa visão. Essa lista, chamada de 
, é priorizada pelo 
de forma que os itens que gerem maior valor ao produto tenham maior prioridade.
Completa, correta e respectivamente, as lacunas I, II e III:
então, transforma essa visão em uma lista de requisitos funcionais e não-funcionais para que, quando forem desenvolvidos, reflitam essa visão. Essa lista, chamada de , é priorizada pelo de forma que os itens que gerem maior valor ao produto tenham maior prioridade. Completa, correta e respectivamente, as lacunas I, II e III:
Ano: 2014
Banca:
FCC
Órgão:
TRT - 13ª Região (PB)
Prova:
FCC - 2014 - TRT - 13ª Região (PB) - Analista Judiciário - Tecnologia da Informação |
Q455280
Engenharia de Software
Observando os processos em trâmite no Tribunal, João observou que as situações pelas quais os processos passavam poderiam ser classificadas em: "abrindo", "aberto", "em trâmite", "encerrando" e "arquivado". Do ponto de vista da orientação a objetos ele percebeu que poderia modelar mais adequadamente as condições ou situações da vida do objeto processo utilizando, para representá-las, o diagrama UML denominado
Ano: 2014
Banca:
FCC
Órgão:
TRT - 13ª Região (PB)
Prova:
FCC - 2014 - TRT - 13ª Região (PB) - Analista Judiciário - Tecnologia da Informação |
Q455277
Engenharia de Software
Texto associado
Analise o modelo em espiral do processo de software de Boehm representado abaixo:
Os itens I, II e III correspondem, respectivamente, a
Ano: 2014
Banca:
FCC
Órgão:
TRT - 13ª Região (PB)
Prova:
FCC - 2014 - TRT - 13ª Região (PB) - Analista Judiciário - Tecnologia da Informação |
Q455276
Engenharia de Software
O desenvolvimento evolucionário baseia-se na ideia de desenvolvimento de uma implementação inicial, expondo o resultado aos comentários do usuário e refinando-o em novas versões até que seja desenvolvido um sistema adequado. As atividades de especificação, desenvolvimento e validação são intercaladas ao invés de separadas, com rápido feedback entre elas.
Sommerville define dois tipos fundamentais de desenvolvimento evolucionário.Considere:
I. Descrever todos os requisitos não funcionais antes de fazer o protótipo. Descrever os requisitos funcionais e técnicos. Implementar todos requisitos e desenvolver novo protótipo.
II. Trabalhar com o cliente para explorar os requisitos e entregar um sistema final. O desenvolvimento começa com as partes do sistema compreendidas. O sistema evolui por meio da adição de novas características propostas pelo cliente.
III. Incorporar e implementar todas as mudanças do software no primeiro estágio do desenvolvimento, definindo todos os requisitos técnicos. Formar um protótipo a partir daí. O sistema evolui por meio da adição de novas características propostas pelo cliente.
IV. Compreender os requisitos do cliente e, a partir disso, desenvolver melhor definição de requisitos para o sistema. O protótipo se concentra na experimentação dos requisitos mal compreendidos do cliente.
De acordo com Sommerville
Sommerville define dois tipos fundamentais de desenvolvimento evolucionário.Considere:
I. Descrever todos os requisitos não funcionais antes de fazer o protótipo. Descrever os requisitos funcionais e técnicos. Implementar todos requisitos e desenvolver novo protótipo.
II. Trabalhar com o cliente para explorar os requisitos e entregar um sistema final. O desenvolvimento começa com as partes do sistema compreendidas. O sistema evolui por meio da adição de novas características propostas pelo cliente.
III. Incorporar e implementar todas as mudanças do software no primeiro estágio do desenvolvimento, definindo todos os requisitos técnicos. Formar um protótipo a partir daí. O sistema evolui por meio da adição de novas características propostas pelo cliente.
IV. Compreender os requisitos do cliente e, a partir disso, desenvolver melhor definição de requisitos para o sistema. O protótipo se concentra na experimentação dos requisitos mal compreendidos do cliente.
De acordo com Sommerville
Conheça nossos planos