Foram encontradas 1.558 questões
Resolva questões gratuitamente!
Junte-se a mais de 4 milhões de concurseiros!
Hipoteticamente, um Analista de Sistemas levantou os seguintes requisitos de negócio para o controle de processos civis no Tribunal Superior do Trabalho − TST:
− A área Recepção é responsável por receber e registrar uma impetração de processo civil − Receber AP − que provém de um Cidadão (não controlado pelo sistema) quando este apenas deverá identificar-se e instruir o objeto do processo. Esses são os dados AP que deverão ser arquivados na Folha de Abertura de Processo – FAP.
− Após o arquivamento, a Recepção informa a área Análise de Dados para obter a FAP arquivada, realizar sua validação – Validar AP − e proceder ao seu subsequente encaminhamento ao Parecer Jurídico ou para, em caso de dados inconsistentes, Comunicar o Cidadão para corrigir e/ou complementar eventuais informações faltantes quando da instrução do objeto do processo, por meio do Aviso de Revisão – AR, cujos dados são arquivados no Cadastro de Revisões - CR, aguardando a correção pelo cidadão e correspondente baixa.
As áreas envolvidas, as baixas e outras supostas atividades não devem ser consideradas. Os elementos que devem ser considerados são:
Cidadão, Receber AP, Dados AP, Folha de Abertura de Processo - FAP, Validar AP, Parecer Jurídico, Comunicar o Cidadão, Aviso de Revisão – AR, Cadastro de Revisões - CR.
Durante a fase de teste de um software desenvolvido para um sistema em tempo real que usa memória compartilhada, um Analista de Sistemas verificou que, apesar de seus componentes já terem sido testados de modo individual e terem tido todos os erros corrigidos, ele não funcionava como deveria, de acordo com sua especificação. O Analista realizou, então, um teste de interface que conseguiu detectar o erro. O motivo era que o produtor e o consumidor de dados estavam operando em velocidades diferentes e o consumidor estava acessando informação desatualizada, pois o produtor da informação não atualizava as informações da interface compartilhada.
Na Engenharia de Software, o tipo de teste de interface e o erro detectado são denominados, correta e respectivamente, interface de
Hipoteticamente, durante a fase de levantamento de requisitos, um Analista de Sistemas do TST aplicou uma técnica que trata de realizar uma imersão no ambiente de trabalho de seus usuários buscando observar, no dia a dia, como as atividades eram executadas. Esse trabalho lhe ajudou a descobrir requisitos funcionais e não funcionais, implícitos, que refletiam as formas reais com que as pessoas trabalhavam ao invés de refletir processos formais definidos pelo Tribunal. Um outro Analista de Sistemas que o acompanhava perguntou:
Qual técnica da Engenharia de Requisitos é essa que você aplicou?
Qual requisito funcional você observou?
Qual requisito não funcional você observou?
As respostas corretas a essas perguntas foram, respectivamente,
Um Analista de Sistemas do Tribunal Superior do Trabalho − TST, de modo hipotético, necessitou aplicar princípios ágeis e de controle usando elementos de três modelos, em processos de manutenção de software. Considere:
I. Dividir o cronograma em iterações time-box ou ciclos (sprints).
II. Orientar o trabalho a eventos ao invés de limite de tempo.
III. Aplicar a programação em pares, integração contínua, orientação a testes (TDD), revisão de código e todas as demais prescrições antes da implantação.
As características acima correspondem, respectivamente, a
Hipoteticamente, um Analista de Sistemas do Tribunal Superior do Trabalho − TST precisou elaborar um diagrama UML 2.5 que se caracteriza por alguns componentes e símbolos específicos, a fim de modelar o fluxo do processo e seus pontos de controle. Considere:
I. Os componentes: estados iniciais e finais; atividades e transições; decisões; bifurcação e união.
II. O símbolo utilizado em nós de controle desse diagrama, como na bifurcação e na união, para modelar atividades paralelas (concorrentes).
O diagrama constituído pelos componentes (I) e o símbolo nele utilizado (II) são, correta e respectivamente, diagrama de
Considere uma aplicação bancária na qual exista uma classe denominada ContaCorrente que tem os seguintes métodos:
abrir(),depositar(),retirar(),saldo(),limiteCredito(),cartoesAssociados(),fechar(),excluir()
Cada um destes métodos ou operações pode ser aplicado à ContaCorrente, mas há certas restrições implícitas como: a conta precisa ter sido aberta para que se possam realizar outras operações e precisa ser fechada após todas as operações terem sido realizadas. Se a conta for excluída nenhuma operação pode mais ser realizada. Mas as operações podem ser realizadas em diversas ordens e diversas vezes. Desta forma, o teste da classe deve assumir diversos cenários. Considere as sequências de casos de testes:
I. abrir→depositar→retirar→fechar
II. abrir→depositar→retirar→saldo→retirar→retirar→limiteCredito→fechar
III. abrir→saldo→retirar→depositar→retirar→depositar→cartoesAssociados→retirar→retirar→fechar
Os casos de testes
Considere, por hipótese, que uma equipe de Especialistas em Tecnologia da Informação está trabalhando em um projeto da ARTESP com base no RUP. Os objetivos a serem alcançados são:
− Verificar a interação entre os objetos do sistema.
− Verificar se os componentes do software estão adequadamente integrados.
− Verificar se todos os requisitos foram corretamente implementados.
− Certificar que os defeitos foram identificados antes da implantação do software.
É correto afirmar que estes objetivos se referem ao
Considere que um Analista esteja participando de um projeto que utiliza as melhores práticas da Extreme Programming − XP. No início de uma iteração a equipe de desenvolvimento, da qual o Analista fazia parte, convidou o cliente a escrever as funcionalidades que desejava no sistema em pequenos cartões chamados user stories. Depois disso, a equipe de desenvolvimento estimou o tempo e o custo de cada funcionalidade para o cliente. O cliente foi informado do tempo e custo, e foi solicitado a decidir a prioridade em que cada user story deveria ser desenvolvida.
Esta prática XP é conhecida como
Considere a classe abaixo, que compõe um diagrama UML 2.5, criada por um Analista para uma aplicação orientada a objetos da Defensoria Pública.
A classe ServicoBusca
Comparando-se os métodos ágeis com os tradicionais, considere:
I. Os ágeis priorizam mais a implementação e os tradicionais geralmente preocupam-se mais com a documentação.
II. As metodologias ágeis são mais preditivas e os tradicionais mais adaptativas, ou seja, buscam se adaptar às mudanças ao invés de realizar longas análises sobre o futuro.
III. Os ágeis podem ser indicados quando o cliente não sabe muito bem o que deseja. Realizam entregas constantes, que nem sempre acontece com os tradicionais, e os testes podem melhorar a qualidade do produto.
IV. Os ágeis não rejeitam processos e ferramentas dos tradicionais, mas as colocam em posição secundária, privilegiando os indivíduos e a comunicação entre eles.
Está correto o que se afirma APENAS em
Considere que um sistema está sendo desenvolvimento na Defensoria Pública e algumas das práticas adotadas são listadas a seguir:
− O Time de Desenvolvimento funciona de forma auto-organizada, sendo composto por profissionais que realizam o trabalho de entregar uma versão do sistema que seja funcional e que incrementa o produto “Pronto” ao final de cada sprint. Somente quem integra o Time de Desenvolvimento cria incrementos.
− Para desenvolver o sistema podem ser criadas várias sprints. Cada sprint é uma iteração que segue o ciclo PDCA. Ao final de cada sprint bem sucedida o time terá produzido um incremento potencialmente integrável, ou seja, com qualidade, testado, completo e pronto, por isso são realizadas reuniões de planejamento para definir a meta de cada sprint.
− O desenvolvedor escreve um teste que falha, faz este teste passar da maneira mais simples possível e, por fim, refatora o código. Esta prática visa a criação de código limpo, atuando como uma ferramenta de apoio na qualidade do desenvolvimento de sistema.
Um Técnico em Informática afirma, corretamente, que
Conheça nossos planos