SóProvas

Prova IADES - 2013 - EBSERH - Analista de Tecnologia da Informação - Teste e Qualidade

ID
979591
Banca
IADES
Órgão
EBSERH
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

Assinale a alternativa que não corresponde a um dos testes de software,realizados em softwares comerciais.


Alternativas
Comentários
  • Não existe teste de volatilidade de requisitos, os requisitos por si só já são voláteis, o que é necessário que o sistema faça hoje pode não ser necessário que o sistema faça amanhã.

  • Prezados,

    Existem diversas bibliografias que versam sobre testes de software. É comum encontrarmos alguns tipos de testes comuns entre as bibliografias.


    Em Pressman vemos que são definidos os testes de unidade, testes de integração, testes de validação, teste de sistema. A IEEE 829 define também os testes de unidade , integração sistema e o teste de aceitação.


    Vemos que o teste que não é conhecido é o teste de volatilidade de requisitos, portanto, a alternativa correta é a letra D


  • U.I.V.A

ID
979597
Banca
IADES
Órgão
EBSERH
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

A atividade de teste é composta por elementos essenciais, que auxiliam na formalização desta atividade.Entre os principais elementos, é correto citar: casos de teste, procedimentos de teste:


Alternativas
Comentários

  • Acho que este artigo é útil pra questão: http://www.devmedia.com.br/artigo-engenharia-de-software-introducao-a-teste-de-software/8035

  • Prezados,


    Um modelo de teste consiste de Casos de teste e Procedimentos de teste. Um caso teste pode ser implementado por um ou mais procedimentos. Um procedimento de teste implementa (todo ou parte de) um ou mais casos de teste. Use cases são a primeira entrada para identificar casos de teste.


    Ao planejarmos o caso de teste com base no caso de uso, devemos estabelecer os critérios do teste ( casos em que o teste será aceito ou não ), e o critério de cobertura do teste.

    Portanto, alternativa correta é a letra A.


  • Componentes do plano de teste:

    -Descrição do escopo de testes;


    -Abordagens de teste;


    -Recursos para realização dos testes;


    -Cronograma das atividades de teste.

  • A atividade de teste é composta por alguns elementos essenciais que auxiliam na formalização desta atividade. Esses elementos são os seguintes:

    • Caso de Teste: descreve uma condição particular a ser testada e é composto por valores de entrada, restrições para a sua execução e um resultado ou comportamento esperado (CRAIG e JASKIEL, 2002).
    • Procedimento de Teste: é uma descrição dos passos necessários para executar um caso (ou um grupo de casos) de teste (CRAIG e JASKIEL, 2002).
    • Critério de Teste: serve para selecionar e avaliar casos de teste de forma a aumentar as possibilidades de provocar falhas ou, quando isso não ocorre, estabelecer um nível elevado de confiança na correção do produto (ROCHA et al., 2001). Os critérios de teste podem ser utilizados como:

        o Critério de Cobertura dos Testes: permitem a identificação de partes do programa que devem ser executadas para garantir a qualidade do software e indicar quando o mesmo foi suficientemente testado (RAPPS e WEYUKER, 1982). Ou seja, determinar o percentual de elementos necessários por um critério de teste que foram executados pelo conjunto de casos de teste.
        o Critério de Adequação de Casos de Teste: Quando, a partir de um conjunto de casos de teste T qualquer, ele é utilizado para verificar se T satisfaz os requisitos de teste estabelecidos pelo critério. Ou seja, este critério avalia se os casos de teste definidos são suficientes ou não para avaliação de um produto ou uma função (ROCHA et al., 2001).
        o Critério de Geração de Casos de Teste: quando o critério é utilizado para gerar um conjunto de casos de teste T adequado para um produto ou função, ou seja, este critério define as regras e diretrizes para geração dos casos de teste de um produto que esteja de acordo com o critério de adequação definido anteriormente (ROCHA et al., 2001).

    Leia mais em: Artigo Engenharia de Software - Introdução a Teste de Software http://www.devmedia.com.br/artigo-engenharia-de-software-introducao-a-teste-de-software/8035#ixzz3w5DLrrJH

  • Podemos resolver por eliminação: caso de uso e diagrama de classes fazem parte dos conceitos de UML, que é linguagem usada em documentação e não testes.

ID
979600
Banca
IADES
Órgão
EBSERH
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

Em relação ao teste de software, assinale a alternativa correta sobre o teste de integração:


Alternativas
Comentários
  • Tem por finalidade expor defeitos nas interfaces e nas interações entre os componentes ou sistemas integrados.

    Fonte: Roger S. Pressman, Engenharia de Software, Uma Abordagem Profissional, Sétima Edição

  • Prezados,

    Segundo Pressman, página 409, o teste de integração é uma técnica sistemática para construir a arquitetura de software ao mesmo tempo que conduz testes para descobrir erros associados com as interfaces, portanto vemos que a alternativa correta é a letra B.


    Vemos que a letra A está errada pois está tratando de testes de unidade, a letra C não representa o objetivo do teste de integração, a letra D está tratando de testes de aceitação, e a letra E está errada pois os objetivos do teste de integração é verificar a compatibilidade entre as interfaces dos módulos do sistema enquanto o teste de aceitação objetiva verificar se o software atende os requisitos do cliente.


    Fonte : Pressman, Engenharia de Software, 7º edição


  • Como assim "visa testar falhas"?? Como é que eu testo uma falha?? 

    Acho que essa questão foi muito mal escrita.

  • questão mal formulada. Testes de integração são utilizados quando você implementa algo novo. testa-se esse novo artefato por um teste de unidade e depois o software na sua completude por um teste de integração para checar se algo deixou de funcionar com a integração realizada.

  • Antes doccódigo ser iniciado? Onde eu acho isso?

  • Prezados,

    Segundo Pressman, página 409, o teste de integração é uma técnica sistemática para construir a arquitetura de software ao mesmo tempo que conduz testes para descobrir erros associados com as interfaces, portanto vemos que a alternativa CORRETA é a letra B.

     

    A) está errada pois está tratando de testes de unidade,

    C) não representa o objetivo do teste de integração

    D) errada está  tratando de testes de aceitação

    E) está errada pois os objetivos do teste de integração é verificar a compatibilidade entre as interfaces dos módulos do sistema enquanto o teste de aceitação objetiva verificar se o software atende os requisitos do cliente.

     

    Fonte : Pressman, Engenharia de Software, 7º edição

    Prof Leandro Rangel

ID
979603
Banca
IADES
Órgão
EBSERH
Ano
2013
Provas
Disciplina
Segurança da Informação
Assuntos

Sobre gerenciamento de riscos de software, assinale a alternativa correta:


Alternativas
Comentários

  • Prezados, vamos analisar as alternativas :

    a) O gerenciamento de riscos de softwarenão envolve os risos ambientais, que possam afetar o projeto.

    Alternativa errada. Existem sim riscos do ambiente, até por isso o RUP define uma disciplina apenas para tratar questões de ambiente.


    b) O controle de riscos é feito pelos planos de casos de uso

    Alternativa errada. Apesar do RUP ser dirigido por casos de uso, o RUP possui artefatos próprios para o controle de riscos.


    c) O controle de riscos é realizado por membros externos ao projeto.

    Alternativa errada. Apesar de haver participação de membros externos, o controle dos riscos é realizado no âmbito do projeto.


    d) Gerenciamento de riscos de softwareconsiste em avaliar e controlar os riscos, que afetam o projeto, processo ou produto de software.

    Alternativa correta, e representa exatamente o conceito de gerenciamento de riscos de software.


    e) O gerenciamento de riscos de software consiste, apenas, no gerenciamento dos Testes de Caixa Branca do Software.

    Alternativa errada. O gerenciamento de riscos não se limita a testar o software.


  • Gabarito D

    Gerenciamento de risco é um processo da engenharia de software com métodos e ferramentas para administrar riscos em um projeto. Isto fornece um ambiente disciplinado para tomadas de decisões com informações de quantidades de riscos que podem ocorrer, determinação sobre quais riscos são importantes e que devem ser tratados, além de informações relacionadas ao desenvolvimento de estratégias para lidar com risco. De acordo com Mattos (1996), falha é algo que prejudica o funcionamento ou a utilização de alguma coisa, é um defeito, uma imperfeição. Baseado em Sherer (1995), Risco de Software é a perda esperada que pode ocorrer no desenvolvimento, na utilização ou na manutenção do software. Com a evolução tecnológica, os riscos de hardware foram minimizados, ficando o software como a maior fonte de problemas que podem resultar em perdas financeiras substanciais. Além de que os softwares estão em constante evolução e manutenção.



    "Retroceder Nunca Render-se Jamais !"

    Força e Fé !

    Fortuna Audaces Sequitur !

ID
979606
Banca
IADES
Órgão
EBSERH
Ano
2013
Provas
Disciplina
Governança de TI
Assuntos

Quais são os riscos do processo de um gerenciamento de riscos de software?


Alternativas
Comentários

  • Prezados,

    De início ao ler essa questão ela pode parecer complicada, mas ela é bem simples.


    Os riscos podem ser divididos em categorias, e na página 231 do PMBOK, o guia trás como exemplo algumas categorias de riscos, riscos técnicos, externos, organizacionais e gerenciais.

    Portanto, alternativa correta é a letra C.


    Fonte : PMBOK 4º edição


  • Risco de software pode ser caracterizado como [PMI 2004]:

    §Riscos de Projeto de Software. Define os parâmetros operacionais, organizacionais e contratuais do desenvolvimento de software. Inclui limites de recursos, interfaces, relacionamentos com fornecedores ou restrições de contratos.

    §Riscos de Processo de Software. Relacionam-se os problemas técnicos e de gerenciamento. Nos procedimentos de gerência podem-se encontrar riscos em atividades como: planejamento, definição e contratação de equipe de trabalho, garantia de segurança e configuração de gerência. Nos procedimentos técnicos, podem-se encontrar riscos nas atividades: análise de requisitos, projeto, codificação e testes, por exemplo.

    §Riscos de Produto de Software. Contém as características intermediárias e finais do produto. Estes tipos de riscos têm origens nos requisitos de estabilidade do produto, desempenho, complexidade de codificação e especificação de testes.


ID
979609
Banca
IADES
Órgão
EBSERH
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

Assinale a alternativa que corresponde às três estratégias de depuração de software.

Alternativas
Comentários
  • Segundo PRESSMAN, quando o caso e teste descobre um erro, a depuração é a ação que resulta na reparação do erro. A depuração não é teste, mas sempre ocorre em conseqüência do teste. A depuração tenta relacionar sintoma com causa levando assim a correção do erro. A mesma apresenta dois resultados: a causa será encontrada e corrigida ou a causa não será encontrada. No caso da última pode suspeitar de uma causa, projetar um caso de teste para ajudar a validar aquela suspeita e trabalhar para correção do erro de um modo interativo.     Independente da abordagem adotada, a depuração tem como objetivo primordial encontrar e corrigir a causa de um erro de software.   Em geral três estratégias de depuração foram proposta por [MYE 79]:       Força Bruta – método mais comum e menos eficiente para isolar a causa de um erro de software. Adotamos a filosofia “deixe o computador encontrar o erro”, são feitas listagem da memória, são invocados rastreadores da execução e o programa é carregado com comandos de saída.   Rastreamento – usada com sucesso em programas pequenos, o código-fonte é rastreado manualmente até que o lugar da causa é encontrado. Infelizmente, a medida que o número de linhas-fonte aumenta, o número de caminhos potenciais para trás pode se tornar inadmissivelmente grande.   Eliminação de causa – manifestada por indução ou dedução e introduz o conceito de particionamento binário. Os dados relacionados à ocorrência do erro são organizados para isolar causas em potencial. Sendo uma hipótese de causa concebida e os dados mencionados são usados para provar ou rejeitar a hipótese. De forma alternativa uma lista de todas as causas possíveis é desenvolvida e são conduzidos testes para eliminar cada uma. Se os testes iniciais indicam que uma hipótese particular de causa é promissora, os dados são refinados em uma tentativa de isolar o defeito.

  • Parabéns ao colega Antonio Vinicius pela excelente colocação em seu comentário.

  • Prezados,

    Segundo Pressman, página 423, existem 3 estratégias de depuração, a força bruta, o rastreamento e a eliminação.


    Portanto, alternativa correta é a letra B


    Fonte : Pressman, Engenharia de Software, 7º edição


  • Letra B

    Em geral três estratégias de depuração foram proposta por [MYE 79]:

    Força Bruta – método mais comum e menos eficiente para isolar a causa de um erro de software. Adotamos a filosofia “deixe o computador encontrar o erro”, são feitas listagem da memória, são invocados rastreadores da execução e o programa é carregado com comandos de saída.

    Rastreamento – usada com sucesso em programas pequenos, o código-fonte é rastreado manualmente até que o lugar da causa é encontrado. Infelizmente, a medida que o número de linhas-fonte aumenta, o número de caminhos potenciais para trás pode se tornar inadmissivelmente grande.

    Eliminação de causa – manifestada por indução ou dedução e introduz o conceito de particionamento binário. Os dados relacionados à ocorrência do erro são organizados para isolar causas em potencial. Sendo uma hipótese de causa concebida e os dados mencionados são usados para provar ou rejeitar a hipótese.

    De forma alternativa uma lista de todas as causas possíveis é desenvolvida e são conduzidos testes para eliminar cada uma. Se os testes iniciais indicam que uma hipótese particular de causa é promissora, os dados são refinados em uma tentativa de isolar o defeito.

ID
979612
Banca
IADES
Órgão
EBSERH
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

Assinale a alternativa que não corresponde a uma das fases do processo de desenvolvimento,dirigido a testes(TDD).


Alternativas
Comentários
  • Fases do TDD:
    1. Adicione um teste
    Em Test Driven Development, cada nova funcionalidade inicia com a criação de um teste. Este teste precisa inevitavelmente falhar porque ele é escrito antes da funcionalidade a ser implementada (se ele não falha, então a funcionalidade ou melhoria 'proposta' é óbvia). Para escrever um teste, o desenvolvedor precisa claramente entender as especificações e requisitos da funcionalidade. O desenvolvedor pode fazer isso através de casos de uso ou user stories que cubram os requisitos e exceções condicionais. Esta é a diferenciação entre desenvolvimento dirigido a testes entre escrever testes de unidade 'depois' do código desenvolvido. Ele torna o desenvolvedor focado nos requisitos 'antes' do código, que é uma sutil mas importante diferença.

    2. Execute todos os testes e veja se algum deles falha
    Esse passo valida se todos os testes estão funcionando corretamente e se o novo teste não traz nenhum equívoco, sem requerer nenhum código novo. Pode-se considerar que este passo então testa o próprio teste: ele regula a possibilidade de novo teste passar.
    O novo teste deve então falhar pela razão esperada: a funcionalidade não foi desenvolvida. Isto aumenta a confiança (por outro lado não exatamente a garante) que se está testando a coisa certa, e que o teste somente irá passar nos casos intencionados.

    3. Escrever código
    O próximo passo é escrever código que irá ocasionar ao teste passar. O novo código escrito até esse ponto poderá não ser perfeito e pode, por exemplo, passar no teste de uma forma não elegante. Isso é aceitável porque posteriormente ele será melhorado.
    O importante é que o código escrito deve ser construído somente para passar no teste; nenhuma funcionalidade (muito menos não testada) deve ser predita ou permitida em qualquer ponto.

     
  • continunando...

    4. Execute os testes automatizados e veja-os executarem com sucesso
    Se todos os testes passam agora, o programador pode ficar confiante de que o código possui todos os requisitos testados. Este é um bom ponto que inicia o passo final do ciclo TDD.

    5. Refatorar código
    Nesse ponto o código pode ser limpo como necessário. Ao re-executar os testes, o desenvolvedor pode confiar que a refatoração não é um processo danoso a qualquer funcionalidade existente. Um conceito relevante nesse momento é o de remoção de duplicação de código, considerado um importante aspecto ao design de um software. Nesse caso, entretanto, isso aplica remover qualquer duplicação entre código de teste e código de produção — por exemplo magic numbers or strings que nós repetimos nos testes e no código de produção, de forma que faça o teste passar no passo 3.

    6. Repita tudo
    Iniciando com outro teste, o ciclo é então repetido, empurrando a funcionalidade a frente. O tamanho dos passos deve ser pequeno - tão quanto de 1 a 10 edições de texto entre cada execução de testes. Se novo código não satisfaz rapidamente um novo teste, ou outros testes falham inesperadamente, o programador deve desfazer ou reverter as alterações ao invés do uso de excessiva depuração. A Integração contínua ajuda a prover pontos reversíveis. É importante lembrar que ao usar bibliotecas externas não é interessante gerar incrementos tão pequenos que possam efetivamente testar a biblioteca ,3 a menos que haja alguma razão para acreditar que a biblioteca tenha defeitos ou não seja suficientemente completada com suas funcionalidades de forma a servir às necessidades do programa em que está sendo escrito.

    A única opção que não contempla uma das fases do TDD é a letra "A".

  • Prezados,

    As fases do processo de TDD são :


    - Adicione um teste

    - Execute todos os testes e veja se algum deles falha

    - Escrever código

    - Execute os testes automatizados e veja-os executarem com sucesso

    - Refatorar código

    - Repita tudo


    Portanto, vemos que a alternativa que não corresponde a uma das fases é a letra A, pois nunca é possível garantir que o software está livre de problemas.



  • Etapas do TDD segundo Sommerville:

    1-Identificar o incremento de funcionalidade necessário.

    2-Escrever um teste para essa funcionalidade e o implementa como um teste automatizado.

    3-Executa o teste, junto com todos os outros testes implementados. O teste irá falhar.

    4-Implementa a funcionalidade e executa novamente o teste.

    5-Depois que todos os testes forem executados com sucesso, voce caminha para implementar a próxima parte da funcionalidade.

  •  e) Implementar a próxima parte da funcionalidade, após todos os testes terem sido executados, com sucesso.

    Após todos os testes terem sido executados com sucesso, se escreve um novo teste para a próxima funcionalidade e só depois se implementa a próxima funcionalidade!

ID
979615
Banca
IADES
Órgão
EBSERH
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

A fase de elaboração dos testes de software é uma das partes mais importantes, no desenvolvimento de um software.Sobre o teste de caixa branca,assinale a alternativa correta.

Alternativas
Comentários

  • O teste caixa-branca fundamenta-se em um exame rigoroso do detalhe procedimental, sendo também chamado teste de caixa-de-vidro. Por ser bem detalhado e chegar a nível de código é feito pelo próprio programador.

  • Prezados, vamos analisar todas as alternativas :

    a) Teste feito pela equipe de testadores de software.

    Alternativa errada. O teste caixa branca é feito pelo próprio desenvolvedor.


    b) Teste executado pelo usuário final do software.

    Alternativa errada. O teste caixa branca é feito pelo próprio desenvolvedor.


    c) Teste realizado, na fase de concepção do software.

    Alternativa errada. Visto que essa é uma questão múltipla escolha, temos que escolher a mais correta. Observamos no RUP que mesmo na etapa de concepção alguns casos de uso são codificados e testados, mas não seria o foco dessa etapa.


    d) Teste executado, após a implantação do software.

    Alternativa errada. O teste é feito durante todo o ciclo de desenvolvimento


    e) Teste feito pelo próprio programador que verifica, se o código que foi construído, é funcional.


    Alternativa correta , o teste caixa branca é feito pelo próprio desenvolvedor e observa se o código construído atente os seus requisitos.


  • Uma dúvida: O programador não teria vício com o código?

    Coloquei letra A -> Teste feito pela equipe de testadores de software.

  • Também coloquei a letra A. No meu entendimento, o teste não é feito pelo próprio programador devido ao vício no código. Poderia considerar como resposta até um outro programador fazendo a revisão do código, mas não o mesmo (próprio programador). 
    Gostaria de saber qual a referencia bibliográfica para essa resolução.

  • O teste caixa branca é recomendado ser feito pelo próprio programador por conhecer a estrutura do código, pois tal teste, tem o objetivo 

    de explorar falhas causadas por defeitos de lógica ou implementação. Até aí ok. Porém, o teste caixa branca ou estrutural não tem por

    objetivo verificar aspectos funcionais. A palavra funcional me induziu ao erro. Marquei letra A.

  • Se o teste é estrutural (linhas de código), faz sentido que ele seja feito por alguém que entenda o código (ou seja, o próprio programador). No meu entender, equipe de teste normalmente executa o teste caixa-preta.

     

    Entretanto, a redação da alternativa E induz ao erro com o uso do termo funcional (que é o outro nome do teste caixa-preta).

  • Para mim, o teste de caixa-preta é que observa que o código construído atende aos requisitos e não caixa branca.

  • ✅Gabarito(A)

    Para realizar os testes de caixa branca é necessário que o profissional de testes conheça a tecnologia empregada pelo software, bem como possua um adequado conhecimento da arquitetura interna da solução, ou seja, esse profissional deverá ter acesso a fontes, estruturas dos bancos de dados e realizar todos os testes previstos no processo de validação de componentes de software.

    Os testes de caixa branca podem ser modelados e estruturados pelos próprios profissionais do desenvolvimento.

    Fonte: Garantia da qualidade de software : adquirindo maturidade organizacional / Alexandre Bartié - 2002 – 13a Reimpressão.

    A técnica de teste de caixa-branca é recomendada para as fases de teste de unidade e teste de integração, cuja responsabilidade principal fica a cargo dos desenvolvedores do sistema, que por sua vez conhecem bem o código produzido.

    Fonte: http://demoiselle.sourceforge.net/process/ds/1.2.3-BETA1/ProcessoDemoisellePlugin/guidances/supportingmaterials/tecnicasTestes_8AB32ED1.html

ID
979618
Banca
IADES
Órgão
EBSERH
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

Existem no mercado algumas metodologias de desenvolvimento, que facilitam o processo de produção de software. Uma dessas metodologias é o XP (Extreme Programming), o qual tem um cuidado especial com os processos de teste de software. Como é feito o processo de teste de software, utilizando o XP?

Alternativas
Comentários
  • O XP o cliente/ usuário tem a liberação de pequenas versões(small Releases) funcionais do projeto auxilia muito na avaliação do cliente. Que por sua vez avalia uma parte do software que esta comprando 

  • Para mim o conceito relacionado à teste no XP é TDD.
    Os testes são feitos ANTES da implementação do código, portanto a questão mais adequada seria a 'e': durante a concepção

  • a) Todos os testes são efetuados, ao fim do desenvolvimento pois, assim, o usuário pode ter uma visão ampla dosoftware.

    Alternativa errada. Os testes são efetuados durante todo o ciclo de vida, não só no final do desenvolvimento.


    b) As etapas de teste são suprimidas do processo

    Alternativa errada, muito pelo contrário, os testes são valorizados e não suprimidos.


    c) Ao final de cada etapa, o usuário é convidado a testar o módulo pronto, evitando, assim, erros muito complexos, ao final do desenvolvimento.

    Alternativa correta. A cada entrega o usuário é convidado a testar o produto construído a fim de identificar precocemente problemas que poderiam ficar mais graves ao final do projeto.


    d) O processo é efetuado, apenas por profissionais que trabalharam no desenvolvimento do produto, tornando assim, o teste mais eficaz e próximo da realidade do cliente.

    Alternativa errada. O usuário final também testa o software.


    e) Todos os testes são realizados na etapa de concepção dosoftware.

    Alternativa errada. Os testes são efetuados durante todo o ciclo de vida


  • a questão deveria informar qual o teste - do cliente ou antes da codificação.....como não falou nada a letra E tb está correta.

  • Respondi letra E pensando apenas no teste de aceitação (realizado na fase planejamento). Existe também os testes: unitário (realizado na fase codificação) e aceitação do cliente (realizado na fase teste).

  • O que invalida a alternativa E, é essa palavra "Todos", ou seja, nem todos os teste são feitos na concepção. Na verdade os teste são feitos em todo o ciclo de vida..

  • Essa letra C é a mais certa, mas estranhei esse "o usuário é convidado apara o modulo pronto". Pois o cliente está sempre presente , sempre acompanhando a equipe de desenvolvimento

  • a) E. Primeiro se testa, antes de desenvolver a funcionalidade.

    b) E. Ao contrário, ao longo do processo, vão sendo feitos testes para averiguar a qualidade do produto, isso é uma boa prática.

    c) C. 

    d) E. Se o testes são feito, por exemplo, pelos programadores, não há tanta eficiência quanto um cliente deixar [quem entende 100% o domínio do negócio é o cliente].

    e) E. Vide item b.

ID
979621
Banca
IADES
Órgão
EBSERH
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

A tarefa de efetuar testes,em software, foi considerada secundária por muito tempo. Geralmente,era vista como castigo para o programador ou como uma tarefa,onde não se deveria gastar muito tempo e investimentos.O tema esteve relegado a segundo plano e, até alguns anos atrás,não se encontrava muita literatura sobre o assunto.Este é um paradigma que vem mudando no mundo moderno de desenvolvimento de software. Um dos testes, que ajudou a mudar este paradigma, é o teste de aceitação que tem como principal característica

Alternativas
Comentários
  • Teste de Aceitação: -> são realizados geralmente por um restrito grupo de usuários finais do sistema. Esses simulam operações de rotina do sistema de modo a verificar se seu comportamento está de acordo com o solicitado

  • Apesar do grande enunciado, a questão quer apenas saber a principal característica do teste de aceitação, que é o fato dela ser realizada pelo cliente para verificar se o software atente as expectativas do usuário, portanto, alternativa correta é a letra A.


  •  Testes de Aceitação (validação ou release):Ao final dos testes de integração, o software está consolidado e iniciam-se os testes de aceitação. A finalidade é demonstrar a conformidade com os requisitos de software. O ambiente utilizado deve ser o mais próximo possível do ambiente real. Os mais comuns são Testes Alfa ou Beta.

    Teste Alfa:É virtualmente impossível para o desenvolvedor prever como o software será utilizado pelo usuário. São necessários testes conduzidos pelo cliente nas instalações do desenvolvedor. O desenvolvedor anota os erros e problemas que possam ocorrer. Acontece em ambiente controlado.

    Teste Beta: É conduzido em um ou mais locais do cliente, pelo usuário final do produto, geralmente sem a presença do desenvolvedor, o cliente reporta aos desenvolvedores os possíveis defeitos ou erros encontrados. Acontece em ambiente real.


    Alternativa: A

  • Só faltava a banca ser um pouco mais técnica e ao invés de citar "verificar o sistema" usar "validar o sistema".

ID
979624
Banca
IADES
Órgão
EBSERH
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

A atividade de teste é composta por alguns elementos essenciais, que auxiliam na formalização desta atividade. A afirmação “serve para selecionar e avaliar casos de teste, de forma a aumentar as possibilidades de provocar falhas ou, quando isso não ocorre, estabelecer um nível elevado de confiança na correção do produto”, refere-se a qual elemento da atividade de teste?

Alternativas
Comentários
  • Critério de Teste: -> serve para selecionar e avaliar casos de teste de forma a aumentar as possibilidades de provocar falhas ou, quando isso não ocorre, estabelecer um nível elevado de confiança na correção do produto. Os critérios de teste podem ser utilizados como : Critério de Cobertura dos Testes: ->permitem a identificação de partes do programa que devem ser executadas para garantir a qualidade do software e indicar quando o mesmo foi suficientemente testado Critério de Adequação de Casos de Teste: -> este critério avalia se os casos de teste definidos são suficientes ou não para avaliação de um produto ou uma função Critério de Geração de Casos de Teste: -> define as regras e diretrizes para geração dos casos de teste de um produto que esteja de acordo com o critério de adequação definido anteriormente

  • qual a bibliografia usada @rafael?

  • Prezados,


    Um critério de teste é o que define quais propriedades precisam ser testadas para garantir inexistência de erros. Como é impossível garantir inexistência, o conceito é utilizado, na prática, para definir uma quantidade mínima que será validada pelo teste, visando aumentar a probabilidade de obtermos a inexistência de erros.


    Portanto, alternativa correta é a letra C.


  • Correção da resposta do professor: Correta D.

  • A atividade de teste é composta por alguns elementos essenciais que auxiliam na formalização desta atividade. Esses elementos são os seguintes:

     

    • Caso de Teste: descreve uma condição particular a ser testada e é composto por valores de entrada, restrições para a sua execução e um resultado ou comportamento esperado (CRAIG e JASKIEL, 2002).

     

    • Procedimento de Teste: é uma descrição dos passos necessários para executar um caso (ou um grupo de casos) de teste (CRAIG e JASKIEL, 2002).

     

    • Critério de Teste: serve para selecionar e avaliar casos de teste de forma a aumentar as possibilidades de provocar falhas ou, quando isso não ocorre, estabelecer um nível elevado de confiança na correção do produto (ROCHA et al., 2001). Os critérios de teste podem ser utilizados como:

     

    o Critério de Cobertura dos Testes: permitem a identificação de partes do programa que devem ser executadas para garantir a qualidade do software e indicar quando o mesmo foi suficientemente testado (RAPPS e WEYUKER, 1982). Ou seja, determinar o percentual de elementos necessários por um critério de teste que foram executados pelo conjunto de casos de teste.

     

    o Critério de Adequação de Casos de Teste: Quando, a partir de um conjunto de casos de teste T qualquer, ele é utilizado para verificar se T satisfaz os requisitos de teste estabelecidos pelo critério. Ou seja, este critério avalia se os casos de teste definidos são suficientes ou não para avaliação de um produto ou uma função (ROCHA et al., 2001).

     

    o Critério de Geração de Casos de Teste: quando o critério é utilizado para gerar um conjunto de casos de teste T adequado para um produto ou função, ou seja, este critério define as regras e diretrizes para geração dos casos de teste de um produto que esteja de acordo com o critério de adequação definido anteriormente (ROCHA et al., 2001).

     

    FONTE: http://www.devmedia.com.br/artigo-engenharia-de-software-introducao-a-teste-de-software/8035

ID
979627
Banca
IADES
Órgão
EBSERH
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

Segundo Pressman (2011), a definição de defeito de software é um problema de qualidade encontrado.


Alternativas
Comentários
  • Defeito é somente após a liberação para usuários finais? Dessa eu não sabia

  • Na verdade,

    Defeito é 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.

    fonte:

    www.devmedia.com.br/artigo-engenharia-de-software-introducao-a-teste-de-software/8035#ixzz2oo1rP2rw

    Porém o livro do Pressman na pg 374, trás a seguinte informação: "No contexto da gestão de qualidade, os termos defeito e falha são sinônimos. Ambos implicam um problema de qualidade que é descoberto depois de o software ter sido liberado para os usuários finais (ou para uma outra atividade estrutural dentro da gestão de qualidade)." Ou seja, na minha análise o termo "SOMENTE " utilizado na alternativa "a" deixa a QUESTÃO PASSIVA DE ANULAÇÃO tendo em vista que o próprio autor citado faz uma ressalva grifada em negrito por mim.

  • conforme os colegas disseram, questao estranha, em desacordo com a bibliográfia consagrada. Sabem dizer se o gabarito se manteve?

  • É amigos! Pressman, realmente, faz essa classificação. Ele chama defeito de custo de falha externa e, pode ser assim chamado, somente após a entrega aos usuários finais. Para os problemas de qualidade encontrado antes da entrega do software aos usuários finais ele chama de Erro. Vejam as definições passadas pelo autor:

        * Erro (custo de falha interna): um problema de qualidade encontrado antes que o software seja entregue aos usuários finais. 

        * Defeito (custo de falha externa): um problema de qualidade encontrado depois que o software seja entregue aos usuários finais.

       Porém, nosso ilustre autor admite que essa é uma visão dele e que "o consenso geral na comunidade de engenharia de software é que defeito e erros, falhas e bugs são sinônimos. ..."

       Ref: Presmman Engenharia de Software - uma abordagem profissional 7a Edição (pag. 374)

       Espero ter ajudado!


  • Prezados,

    A definição de Pressman para Defeitos, erros e falhas é diferente da definição de outros autores.


    Para Pressman, erro é um problema de qualidade encontrado antes que o software seja entregue aos usuários finais, enquanto defeito é um problema de qualidade encontrado depois que o software seja entregue aos usuários finais.

    Portanto, a alternativa correta é a letra A.


ID
979630
Banca
IADES
Órgão
EBSERH
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

Os testes de software são executados, usando os procedimentos e documentos de script de teste. Para que a fase de execução de teste, seja realizada com sucesso deve(m) serexecutado(s):

Alternativas
Comentários

  • Nos procedimentos de criação de testes, os casos de testes são definidos, onde se levarão em conta quais testes serão realizados sob quais itens e funcionalidades.

    As outras alternativas não correspondem ao enunciado da questão. No caso do Diagrama de Casos de Uso, o mesmo pode ser utilizado para se realizar teste de requisitos funcionais, os testes de caixa preta.

  • Prezados,


    Não se executa casos de uso , nem diagramas de atividade, portanto as alternativas A e B estão erradas. O "Teste de Turing" testa a capacidade de uma máquina exibir comportamento inteligente equivalente a um ser humano, ou indistinguível deste, porém executar o caso de teste de turing é um teste especifico, aplicado a determinado cenário, não sendo a letra D a resposta da questão, muito menos a letra E que fala de teste de COMA.


    A alternativa correta é a letra C, devemos executar os casos de teste, usando procedimentos ou scripts de teste para executarmos os testes e garantir que essa fase será realizada com sucesso.


  • Etapas do Processo de Teste:

    • Planejamento: aqui são elaborados o projeto e o plano de testes que acompanham todo o processo de teste.
    • Preparação: relativo à preparação do ambiente: infraestrutura, equipamentos, pessoal capacitado etc.
    • Especificação: aqui é elaborado e revisado os casos de testes e roteiros de testes (scripts).
    • Execução: execução do testes conforme os roteiros(scripts) estabelecidos na etapa de especificação.

    Entrega: finalização do projeto de teste, registra-se a documentação relativa à melhorias, geram-se relatórios de conformidades e não-conformidades

ID
979633
Banca
IADES
Órgão
EBSERH
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

Sempre que é encontrado um erro, no processo de teste de software, é necessário relatar o incidente. Para isso, deve- se defnir os relatórios necessários, para acompanhar o progresso do projeto de teste, segundo a norma IEEE 829- 1998. Os relatórios de teste que a IEEE sugere são:

Alternativas
Comentários
  • log de teste para o desenvolvedor poder acompanhar o que aconteceu no momento, o que o testador estava inserindo de entradas
    incidente de teste para descrever o que houve de problema, sempre incluindo o maior número de informações possível
    e sumário de teste pois é nele que estará o resumo do teste que auxiliará à criação do cenário de testes.

  • Prezados,


    A IEEE 829 define 3 relatórios, o Log de testes, o relatório de incidentes e o sumário de avaliação dos testes, portanto a alternativa correta é a letra B.


  • Complementando: 


    Teste de aceitação:


    Ao final dos testes de integração, o software está consolidado e iniciam-se os testes de aceitação, a finalidade é demonstrar a conformidade com os requisitos de software.

    O ambiente utilizado deve ser o mais próximo possível do ambiente real

    Os mais comuns são Testes Alfa ou Beta


  • Essa dá pra ir até por eliminação. Por exemplo, "teste de sistema", que está nas outras alternativas, obviamente não é um relatório.

ID
979636
Banca
IADES
Órgão
EBSERH
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

Assinale a alternativa correta, sobre automação de teste de software.


Alternativas
Comentários

  • A ferramenta open-source JUnit é um exemplo de automação de teste de software.

  • Prezados, vamos analisar as alternativas :

    a) É a tarefa executada, pelos analistas de teste, tendo como objetivo descrever os fluxos dos UCs do Sistema.

    Alternativa errada. Automação de teste de software não tem como objetivo descrever os fluxos dos casos de uso, essa tarefa é de responsabilidade do Analista .


    b) Tem como principal tarefa, ajudar na concepção do Software.

    Alternativa errada. A principal tarefa da automação de teste de software é executar de forma sistêmica os testes planejados.


    c) É um questionário, aplicado para os usuários finais do Sistema.

    Alternativa errada. O questionário é uma ferramenta que pode ser utilizada para medir a satisfação dos usuários, mas ela por si só não é a automação de testes.


    d) É ferramenta de instalação de Software.

    Alternativa errada. Automação de teste de software não é wizard de instalação.


    e) É a utilização de um sistema, para controlar a execução dos testes de umSoftware

    Alternativa correta, automação de teste de software é o uso de um aplicativo para executar os testes de forma automática.


  • Resposta correta: É a utilização de um sistema, para controlar a execução dos testes de um Software
    Quando se fala em "sistema", sub entende-se de algum software de automação de testes, como por exemplo: JUnit e Selenium.

ID
979639
Banca
IADES
Órgão
EBSERH
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

A automatização de software é um processo, em qual, de alto custo financeiro e que envolve várias etapas de teste. Alguns dos testes de software, aplicados nesse processo, são os testes de caixa branca e os testes de caixa preta. Assinale a alternativa correta sobre o teste de caixa preta.

Alternativas
Comentários

  • Os testes de caixa preta tem por objetivo testar os requisitos funcionais do sistema. Por exemplo:

    - Tenho uma lista de requisitos funcionais no qual meu sistema deve ter, supondo que um deles seja: "Ao digitar o CPF o sistema deve consumir um WEBService e retornar o nome da pessoa ou avisar que o CPF não foi encontrado".

    - No teste de caixa preta, ele irá verificar através da entrada de um CPF se o requisito vai ser atendido.

    O Nome é caixa preta, pois não olhamos para o código, não temos acesso ao comportamento do código, o código pode até ser executado de forma incorreta, mas se a saída for verdadeira, o teste de caixa preta está completado com sucesso.

  • Apesar do grande enunciado, a questão deseja saber apenas o que é uma definição correta de teste caixa preta.


    Vemos que a única definição que se enquadra é a letra D, onde o usuário realiza o uso do software colocando algumas entradas, e observa se as saídas são as esperadas, sem ter acesso ao código fonte ou ao processamento do sistema, ele apenas observa a funcionalidade.


  • Teste de Caixa Preta (Black Box): Concentram-se nos requisitos funcionais do software, nesta metodologia, os casos de testes são gerados sem o conhecimento da estrutura interna do programa. Apenas o conhecimento das entradas e saídas possíveis para o programa é necessário. Ou seja, esse teste possibilita que o engenheiro de software derive de condições de entrada que exercitem completamente todos os requisitos funcionais para um programa. O teste de caixa preta não é uma alternativa para o teste de caixa branca. Ao contrário, trata-se de uma abordagem complementar que tem a probabilidade de descobrir uma classe de erros daquela dos métodos de caixa branca.


    Fonte: Pressman

ID
979642
Banca
IADES
Órgão
EBSERH
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

Assinale a alternativa que não corresponde a risco de um projeto de teste de software.


Alternativas
Comentários

  • Prezados,


    Todas as alternativas apresentam incertezas que prejudicariam o projeto de teste de um software, exceto a letra C, que apresenta um cenário positivo e um a característica desejada em nosso projeto, tendo ele um escopo bem delimitado podemos estabelecer um cronograma de testes com razoável segurança e ficarmos mais seguros de sua correta execução.


  • Ridícula esta questão....

  • questãozinha confusa

    mas oque não é um risco para o projeto de testes do software é ter um escopo do projeto bem delimitado, isso não traz riscos e sim o benefício.

  • Só a questão c que não traz risco para o projeto de teste. Todas as demais são iminentes de risco. E o enunciado quer saber exatamente qual das questões que não traz risco ao projeto de teste. 


  • Essa questão é mais Raciocínio Lógico do que Engenharia de Sw.

ID
979645
Banca
IADES
Órgão
EBSERH
Ano
2013
Provas
Disciplina
Segurança da Informação
Assuntos

As estratégias de gerenciamento de risco são divididas em três categorias.Uma dessas categorias é a estratégia:

Alternativas
Comentários

  • Prezados,

    Os riscos podem ter impactos positivos e negativos, e a depender do impacto do risco algumas estratégias podem ser aplicadas.


    Para os riscos de impactos positivos ( ou oportunidades ) podemos usar as estratégias de Explorar, Compartilhar e Melhorar.


    Para os riscos de impactos negativos ( ou ameaças ) podemos usar as estratégias de eliminar, transferir ou mitigar ( reduzir a probabilidade e/ou impacto ).


    Para ambos os tipos de riscos podemos usar a estratégia de aceitar.


    Vemos que a única alternativa que faz algum sentido é a letra B, estratégia de minimização, que seria a estratégia de mitigar o risco.


    Fonte : PMBOK 4º edição


  • Minimizar, aceitar e transferir

  • MORRE COM RISCOS

    * Modificar

    * Reduzir

    * Reter

    * Compartilhar

  • Minimizar, aceitar,  transferir e mitigar.

  • Limitar à 3 categorias não foi uma boa estratégia, visto que essa relação não é taxativa, contudo,

    De acordo com o TCU, as opções de tratamento de riscos incluem evitar, reduzir (mitigar), transferir

    (compartilhar) e aceitar (tolerar) o risco, devendo-se observar que elas não são mutuamente

    exclusivas.

    Poderíamos associar o termo minimizar a “reduzir” ou “mitigar”.

ID
979648
Banca
IADES
Órgão
EBSERH
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

métricas de software são parâmetros utilizados,para mensurar ou medir algo que se queira estimar,do ponto de vista da produção de software.Em relação às métricas de qualidade de software, assinale a alternativa correta.

Alternativas
Comentários
  • Categorização de Métricas

    Métricas de produtividade
    Concentram-se na saída do processo de engenharia de software.
    Ex.: no. de casos de uso/iteração.

    Métricas de qualidade
    Oferecem uma indicação de quanto o software se adequa às exigências implícitas e explícitas do cliente.
    Ex.: erros/fase

    Métricas técnicas
    Concentram-se nas características do software e não no processo por meio do qual o software foi desenvolvido.
    Ex.: complexidade lógica e grau de manutenibilidade

  • Prezados, vamos aos comentários das alternativas:


    a) É uma abordagem utilizada para definir o tempo gasto, em cada ponto de função.

    Alternativa errada. Por métricas podemos até estimar o tempo gasto por ponto de função , mas isso será uma média. As métricas de qualidade não tem por objetivo definir o tempo gasto, principalmente o tempo gasto em cada ponto de função.


    b) Oferece meios de mensurar o tempo gasto, para o desenvolvimento do software.

    Alternativa errada. As métricas de qualidade podem ser utilizadas para estimar o tempo gasto, antes do desenvolvimento.


    c) Fornece informações sobre a quantidade de linhas de código

    Alternativa errada. As métricas de qualidade não tem como objetivo fornecer informações sobre a quantidade de linhas de código. Nos projetos de desenvolvimento de softwares atuais, a quantidade de linhas de código do software não serve de parâmetro para mensurar qualidade.


    d) É uma abordagem utilizada, para reforçar os testes de aceitação

    Alternativa errada. Os testes de aceitação são realizados com o cliente para verificar se o software construído atente as expectativas do cliente. Isso é realizado após o software ou módulo estar concluído.


    e) Oferece uma estimativa de quanto o software se adequa às exigências implícitas e explícitas do cliente.

    Alternativa correta. Com métricas de qualidade conseguimos estimar a quantidade de erros embarcados no software, assim como estimar o grau de aderência dele aos seus requisitos.


  • essa letra B pq está errada? a APF realmente não oferece meios para mensurar o tempo gasto? No comentário do professor
    "Alternativa errada. As métricas de qualidade podem ser utilizadas para estimar o tempo gasto, antes do desenvolvimento.", Ao meu ver a questão não diz que as métricas estão sendo utilizadas durante ou depois do desenvolvimento.

  • e-

    As métricas servem para estipular e medir fatores como recursos humanos / tempo de desenvolvimento, cronogramas, falhas, erros, retrabalhos. Além disso tudo, também definem tamanho, sendo necessário coleta de dados destas medições já no inicio. alguns exemplos de métricas q utiliza a Orientação a Objetos:]]

    1- quantidade total de classes;
    2- quantidade total de operações;
    3- quantidade de classes reutilizadas e n° de classes desenvolvidas;
    4- quantidade de operações reutilizadas e n° de operações desenvolvidas;
    5-  quantidade de mensagens enviadas.


    A experiência na medição de cada projeto permite definir e planejar melhor os que virão. conhecendo o tempo médio gasto para um caso de uso, estipula-se o tempo para os demais. As métricas mais utilizadas no desenvolvimento Orientado a Objetos : métricas de análise, de projeto e de construção.

  • Com base na APF, a B também está certa.

ID
979651
Banca
IADES
Órgão
EBSERH
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

À qual modalidade de métrica pertencem a funcionalidade,a modularidade e a manutenibilidade?

Alternativas
Comentários
  • Categorização de Métricas

    Métricas de produtividade
    Concentram-se na saída do processo de engenharia de software.
    Ex.: no. de casos de uso/iteração.

    Métricas de qualidade
    Oferecem uma indicação de quanto o software se adequa às exigências implícitas e explícitas do cliente.
    Ex.: erros/fase

    Métricas técnicas
    Concentram-se nas características do software e não no processo por meio do qual o software foi desenvolvido.
    Ex.: complexidade lógica e grau de manutenibilidade

  • Prezados,


    Funcionalidade, modularidade e a manutenibilidade estão diretamente relacionados a parte técnica do produto construído, sendo diretamente afetadas pela arquitetura escolhida, pela linguagem utilizada. Portanto , alternativa correta é a letra B.


ID
979654
Banca
IADES
Órgão
EBSERH
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

Durante a realização de um checklist de inspeção de software, a equipe de teste de qualidade de software, de um órgão público, deparou com uma classe de defeito de interface.Qual das afirmativas, a seguir, corresponde a verificação que deverá ser feita, para checar a existência desta classe de defeito?

Alternativas
Comentários

  • Prezados,


    O enunciado apresenta um cenário onde será necessário realizarmos um teste que objetiva detectar um defeito de interface. As alternativas A, B, C e D realizam testes dentro do código, o que seria desnecessário para testar sua interface, bastando verificar a invocação dos métodos, conforme sugere a letra E.

    Portanto, a alternativa correta é a letra E.


  • Letra E. Defeito - é 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 um comando incorreto.

ID
979657
Banca
IADES
Órgão
EBSERH
Ano
2013
Provas
Disciplina
Governança de TI
Assuntos

De acordo com o padrão de qualidade ISO 9126, são identifcados seis atributos fundamentais da qualidade. Sobre o tema, assinale a alternativa correta.

Alternativas
Comentários

  • Funcionalidade

    A capacidade de um software prover funcionalidades que satisfaçam o usuário em suas necessidades declaradas e implícitas, dentro de um determinado contexto de uso.

    Suas sub-características são:

    • Adequação, que mede o quanto o conjunto de funcionalidades é adequado às necessidades do usuário;
    • Acurácia (ou precisão) representa a capacidade do software de fornecer resultados precisos ou com a precisão dentro do que foi acordado/solicitado;
    • Interoperabilidade que trata da maneira como o software interage com outro(s) sistema(s) especificados;
    • Segurança mede a capacidade do sistema de proteger as informações do usuário e fornecê-las apenas (e sempre) às pessoas autorizadas
    • ,,, Segurança também pode estar dirigida em, processar gerar e armazenar as informações.

    Confiabilidade

    O produto se mantém no nível de desempenho nas condições estabelecidas.

    Suas sub-características são:

    • Maturidade, entendida como sendo a capacidade do software em evitar falhas decorrentes de defeitos no software;
    • Tolerância a Falhas representando a capacidade do software em manter o funcionamento adequado mesmo quando ocorrem defeitos nele ou nas suas interfaces externas;
    • Recuperabilidade que foca na capacidade de um software se recuperar após uma falha, restabelecendo seus níveis de desempenho e recuperando os seus dados;

    Usabilidade

    A capacidade do produto de software ser compreendido, seu funcionamento aprendido, ser operado e ser atraente ao usuário.

    Note que este conceito é bastante abrangente e se aplica mesmo a programas que não possuem uma interface para o usuário final. Por exemplo, um programa batch executado por uma ferramenta de programação de processos também pode ser avaliado quanto a sua usabilidade, no que diz respeito a ser facilmente compreendido, aprendido, etc. Além disto, a operação de um sistema é uma interface Humano-Computador (ver IHC) sujeita às avaliações de usabilidade.

    Suas sub-características são:

    • Inteligibilidade que representa a facilidade com que o usuário pode compreender as suas funcionalidades e avaliar se o mesmo pode ser usado para satisfazer as suas necessidades específicas;
    • Apreensibilidade identifica a facilidade de aprendizado do sistema para os seus potenciais usuários;
    • Operacionalidade é como o produto facilita a sua operação por parte do usuário, incluindo a maneira como ele tolera erros de operação;
    • Atratividade envolve características que possam atrair um potencial usuário para o sistema, o que pode incluir desde a adequação das informações prestadas para o usuário até os requintes visuais utilizados na sua interface gráfica;

  • Eficiência

    O tempo de execução e os recursos envolvidos são compatíveis com o nível de desempenho do software.

    Suas sub-características são:

    • Comportamento em Relação ao Tempo que avalia se os tempos de resposta (ou de processamento) estão dentro das especificações;
    • Utilização de Recursos que mede tanto os recursos consumidos quanto a capacidade do sistema em utilizar os recursos disponíveis;

    Manutenibilidade

    A capacidade (ou facilidade) do produto de software ser modificado, incluindo tanto as melhorias ou extensões de funcionalidade quanto as correções de defeitos, falhas ou erros.

    Suas sub-características são:

    • Analisabilidade identifica a facilidade em se diagnosticar eventuais problemas e identificar as causas das deficiências ou falhas;
    • Modificabilidade caracteriza a facilidade com que o comportamento do software pode ser modificado;
    • Estabilidade avalia a capacidade do software de evitar efeitos colaterais decorrentes de modificações introduzidas;
    • Testabilidade representa a capacidade de se testar o sistema modificado, tanto quanto as novas funcionalidades quanto as não afetadas diretamente pela modificação;

    Portabilidade

    A capacidade do sistema ser transferido de um ambiente para outro.

    Como "ambiente", devemos considerar todo os fatores de adaptação, tais como diferentes condições de infra-estrutura (sistemas operacionais, versões de bancos de dados, etc.), diferentes tipos e recursos de hardware (tal como aproveitar um número maior de processadores ou memória). Além destes, fatores como idioma ou a facilidade para se criar ambientes de testes devem ser considerados como características de portabilidade.

    Suas sub-características são:

    • Adaptabilidade, representando a capacidade do software se a adaptar a diferentes ambientes sem a necessidade de ações adicionais (configurações);
    • Capacidade para ser Instalado identifica a facilidade com que pode se instalar o sistema em um novo ambiente;
    • Coexistência mede o quão facilmente um software convive com outros instalados no mesmo ambiente;
    • Capacidade para Substituir representa a capacidade que o sistema tem de substituir outro sistema especificado, em um contexto de uso e ambiente específicos. Este atributo interage tanto com adaptabilidade quanto com a capacidade para ser instalado;

  • Prezados, A ISO 9126 traz 6 atributos de qualidade, que são Funcionalidade, Confiabilidade, Usabilidade, Eficiência, Manutenibilidade e portabilidade.


    Vamos comentar as alternativas :

    a) A usabilidade diz respeito à quantidade de tempo, que osoftware fica disponível para uso.

    Alternativa errada, ela está tratando de disponibilidade e não de usabilidade


    b) A eficiência é o grau com que o software satisfaz às necessidades declaradas.

    Alternativa errada, ela está tratando de funcionalidade e não de eficiência.


    c) A disponibilidade é o grau de tempo em que o software permanece no ar para utilização

    Alternativa errada, apesar de parecer correto, disponibilidade não é um atributo de qualidade definido nessa ISO


    d) A portabilidade é a facilidade com a qual um software pode ser transportado de um ambiente para outro.

    Alternativa correta,  a definição de Portabilidade segundo a ISO é a capacidade do sistema ser transferido de um ambiente para outro.


    e) A confidencialidade é a capacidade de manter partes do software, em sigilo, só sendo permitido o conhecimento, por parte de pessoas autorizadas.

    Alternativa errada, confidencialidade não é um atributo de qualidade definido nessa ISO 


  • Apenas complementando, existe uma nota na norma 9126, que explica: 

    "Disponibilidade é a capacidade de um produto de software de estar pronto para executar uma função requisitada num dado momento, sob condições especificadas de uso. Externamente, a disponibilidade pode ser avaliada pela proporção do tempo total durante o qual o produto de software está disponível. 
    A disponibilidade é, portanto, a combinação de maturidade (a qual controla a freqüência de falhas), tolerância a falhas e recuperabilidade (a qual controla o período de tempo inativo após cada falha). Por esta razão elanão   foi incluída como uma subcaracterística distinta."

    Essa nota se encontra logo após a descrição da subcaracterística Recuperabilidade.

  • Qualidade Interna Externa

     

    CEF - MPU

     

     

    Confiabilidade

    Eficiencia

    Funcionalidade

     

    Manutenibilidade

    Portabilidade

    Usabilidade

     

     

     

     

    Qualidade em Uso

    SESP

     

    Seguranca

    Eficacia

    Satisfacao

    Produtividade

     

     

  • d-

    A questao ate diz transportar de um local a outro. E portabilidade vem de portar- do latin portare - carregar

    https://en.wiktionary.org/wiki/portare

     

    Funcionalidade - PAIS - precisao, adequação, interoperacao, segurança
    Confiabilidade - um adulto tem maturidade, tolerancia e sabe se recuperar
    a e i o u - Aprensibilidade/Atratividade, inteligibilidade, operacao é USABILIDADE
    Eficiencia - CU - comportamento & uso de recursos
    Manutencao - AME o teste - Analise, Modificacao, Estabilidade
    POrtabilidade - cacaca - capacidade de substituir, coexistencia, adaptacao, capacidade de instalar

    Conformidade esta em todos. Nao ha necessidade de lista-lo

ID
979663
Banca
IADES
Órgão
EBSERH
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

O gerenciamento de Configuração de Software trabalha diretamente ligado com os Baselines. De acordo com essa informação, assinale alternativa correta.

Alternativas
Comentários
  • Conjunto de atividades projetadas para controlar as mudanças pela identificação dos produtos do trabalho que serão alterados, estabelecendo um relacionamento entre eles, definindo o mecanismo para o gerenciamento de diferentes versões destes produtos, controlando as mudanças impostas, e auditando e relatando as mudanças realizadas.


    Fonte: http://pt.wikipedia.org/wiki/Ger%C3%AAncia_de_configura%C3%A7%C3%A3o_de_software

  • Linhas-base ou Baseline é um conceito de gerenciamento de configuração de software que nos ajuda a controlar as mudanças, sem impedir seriamente as mudanças justificáveis. Segundo PRESSMAN no contexto de engenharia de software, definimos uma linha-base como um marco de referência no desenvolvimento de um software, que é caracterizado pela entrega de um ou mais itens de configuração (em inglês, Software Configuration Items - SCIs) e pela aprovação desses SCIs, obtida por meio de uma revisão técnica formal.

    Exemplos de linhas-base:

    • Versão 1.0
    • Versão de correção de erros 1.1

  • Prezados, 

    o enunciado dessa questão deseja saber o que é uma baseline.


    A alternativa mais correta é a letra E , visto que a geração da baseline segue um rito formal dentro da empresa, lastrada por um processo, e a baseline uma vez gerada , representa uma fotografia dos itens de configuração em determinado momento, e passa a ser gerenciada como uma coisa só, e serve de referência para o desenvolvimento posterior do sistema.