Questões de Concurso

 São componentes de um Diagrama de Fluxo de Dados, segundo Chris Gane: 

Uma das utilizações mais comuns da Análise de Pontos de Função (APF), no Brasil, tem sido para

Considere os diagramas a seguir com base na UML 2.5.

Os conceitos presentes nos diagramas I e II são, respectivamente,

A Engenharia de Requisitos pode ser, em uma visão ampla, dividida em:

I. ...I... : preocupa-se com a descoberta, busca da qualidade (correção, completude, consistência, possibilidade de verificação, ordenação e rastreamento, facilidade de modificação e clareza), detalhamento, documentação, revisão e verificação dos requisitos do sistema.

II. ...II...: é um processo que estabelece e mantém acordos entre o cliente e a equipe do projeto sobre a evolução dos requisitos. Monitora o desenvolvimento e implementação dos requisitos, registrando seus atributos, status e dependência, com o objetivo de controlar o andamento e as mudanças realizadas.

Preenchem, correta e respectivamente, as lacunas I e II:

O Modelo Cascata é considerado o “avô" de todos os ciclos de vida de sistemas e propõe que, antes de produzir linha de código, deve-se fazer um trabalho detalhado de análise e projeto, de forma que, quando o código for efetivamente produzido, esteja o mais próximo possível dos requisitos do cliente. Sobre este modelo, considere:

I. É dirigido por documentação, já que é ela que determina se as fases foram concluídas ou não.

II. Prevê uma atividade de revisão ao final de cada fase para que se avalie se o projeto pode passar à fase seguinte.

III. Tem fases sequenciais, ou seja, com o passar do tempo, o processo de desenvolvimento passa de uma fase à outra, como requisitos, análise, programação, testes e implantação.

IV. São produzidos resultados tangíveis até a fase de codificação, pois sempre são estabelecidos requisitos completos antes desta fase.

Está correto o que se afirma em 

O RUP organiza o desenvolvimento de software em quatro fases, nas quais são tratadas questões sobre planejamento, levantamento de requisitos, análise, implementação, teste e implantação do software. Cada fase tem um papel fundamental para que o objetivo seja cumprido, distribuído entre vários profissionais, como o analista de sistemas, projetista etc., entre outros aspectos. Considere:

I. Desenvolve ou adquire os componentes de software. O principal objetivo desta fase é o desenvolvimento do sistema de software, com foco no desenvolvimento de componentes e outros recursos do sistema.

II. Abrange a modelagem do modelo genérico do processo. O objetivo desta fase é realizar de forma mais detalhada a análise do domínio do problema, revisando os riscos que o projeto pode sofrer. A arquitetura do projeto começa a ter sua forma básica. Indagações como “O plano do projeto é confiável?", “Os custos são admissíveis?" são esclarecidas nesta etapa.

III. Abrange a entrega do software ao usuário e a fase de testes. O objetivo desta fase é disponibilizar o sistema, tornando-o disponível e compreendido pelo usuário final. As atividades desta fase incluem o treinamento dos usuários finais e a realização de testes da versão beta do sistema visando garantir que o mesmo possua o nível adequado de qualidade.

IV. Abrange as tarefas de comunicação com o cliente e o planejamento. É feito um plano de projeto avaliando os possíveis riscos, as estimativas de custo e prazos, estabelecendo as prioridades.

Os itens numerados de I a IV acima descrevem, respectivamente, as fases: 

Na linguagem UML, o diagrama que apresenta as necessidades de hardware do sistema, como o sistema é executado e interligado com os vários dispositivos físicos e como estes componentes são configurados em tempo de execução, é chamado de diagrama de

Os requisitos não funcionais surgem por meio das necessidades dos usuários, devido a restrições de orçamento, políticas organizacionais, necessidade de interoperabilidade e fatores externos. Estes requisitos podem ser classificados como requisitos de produto, organizacionais e externos. Os requisitos externos ainda são classificados como reguladores, éticos e

A documentação de requisitos pode ser feita combinando modelos e linguagem natural. A alternativa que ilustra o diagrama utilizado para documentar requisitos pela perspectiva estrutural é:

Software, assim como todos os sistemas complexos, evolui ao longo do tempo. Modelos de processos evolucionários reconhecem a natureza iterativa e incremental da maioria dos projetos de engenharia de software e são projetados para adequar mudanças. Os modelos a serem utilizados em um processo evolucionário são:

As características listadas a seguir referem-se, preferencialmente, a qual modelo de desenvolvimento?
• Resultados úteis a cada duas semanas ou menos. • Blocos pequenos de funcionalidade valorizada pelo cliente, chamados "Features". • Planejamento detalhado e guia para medição. • Rastreabilidade e relatórios com maior precisão. • Monitoramento detalhado, com resumos para clientes e gerentes, em termos de negócio. • Fornece uma forma de saber, dentro dos primeiros 10% de um projeto, se o plano e a estimativa são sólidos.

Nas metodologias ágeis, encontramos uma forma para o desenvolvimento fragmentado em etapas onde parte do software vai sendo apresentado em reuniões. Isso ocorre várias vezes, mesmo muito antes da finalização ou término do software. O que podemos esperar do acompanhamento do desenvolvimento ágil em relação aos processos de teste?

Sobre a documentação de teste de software, podem-se destacar os seguintes documentos:
I. Plano de Teste: descreve o escopo dos testes a serem realizados, a abordagem e os recursos que serão utilizados como ferramenta de apoio. O documento contempla a elaboração de um cronograma contendo todas as atividades e responsáveis por sua execução. II. Especificação do Projeto ou Desenho do Teste: especifica os detalhes da abordagem do teste e identifica as características a serem testadas, incluindo os aspectos funcionais e não funcionais relacionados com o software e classes de equivalência e valores-limite. III. Especificação de Casos de Teste: define o conjunto de casos de teste a serem realizados, itens a serem testados, especificação das entradas e saídas esperadas, premissas e restrições do ambiente onde o teste deverá ocorrer. IV. Especificação de Procedimento de Teste: especifica os passos para execução do caso de teste, basicamente os passos utilizados para analisar os recursos do software e avaliação de suas características.
É correto o que se afirma em:

Atividades de testes, escopo, cobertura dos testes, funcionalidades do software que não serão testadas, premissas, restrições, requisitos de ambiente, rastreabilidade dos casos de teste, critérios de validação e os responsáveis pelas tarefas de teste. Os itens relacionados são exemplos de:

Os Casos de Testes são elaborados e revisados dentro da etapa de Especificação do Ciclo de Vida de Testes. Assinale a alternativa que se refere ao método ou técnica demonstrada no diagrama seguinte.

Dados de entrada são fornecidos, o teste é executado e o resultado obtido é comparado a um resultado esperado previamente conhecido. Haverá sucesso no teste, se o resultado obtido for igual ao resultado esperado. Interessa a função executada, e não a característica interna do componente. O componente de software a ser testado pode ser um método, uma função interna, um programa, um componente, um conjunto de programas e/ou componentes ou mesmo uma funcionalidade. Trata-se de um teste:

Assinale a alternativa que contém apenas fases do clico de vida dos testes.

No planejamento dos testes de software, programam-se, por exemplo, o teste de integração, o teste de sistema e o teste de unidade. Esse grupo de testes está assim relacionado por fazer parte de uma organização de testes denominada:

Segundo o Institute of Electrical and Electronics Engineers (IEEE), o âmbito, ou área de impacto, onde os defeitos, erros e falhas ocorrem são, respectivamente:

Observe os seguintes conceitos, segundo o Institute of Electrical and Electronics Engineers (IEEE) sobre os problemas com softwares.
I. Um ato inconsistente cometido por um indivíduo ao tentar entender uma determinada informação, resolver um problema ou utilizar um método ou uma ferramenta. Por exemplo, uma instrução ou comando incorreto. II. Uma manifestação concreta de um defeito num artefato de software. Diferença entre o valor obtido e o valor esperado, ou seja, qualquer estado intermediário incorreto ou resultado inesperado na execução de um programa constitui um erro. III. O comportamento operacional do software diferente do esperado pelo usuário. Uma falha pode ter sido causada por diversos erros e alguns erros podem nunca causar uma falha.
Agora, observe os seguintes termos.
a. Falha. b. Defeito. c. Erro.
Correlacione os conceitos com os termos e assinale a alternativa correta.