SóProvas


ID
790972
Banca
FCC
Órgão
TST
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

Considere:


Riscos que afetam a qualidade ou o desempenho do software que está sendo desenvolvido, como por exemplo, a falha de um componente comprado para o desempenho esperado e que compromete o desempenho geral do sistema são considerados riscos de I . Outro exemplo de riscos dessa categoria é a II .

As lacunas I e II são preenchidas correta e respectivamente por

Alternativas
Comentários
  • Sommerville(2011)

    "22.1 Risk management
    Risk management is one of the most important jobs for a project manager. Risk
    management involves anticipating risks that might affect the project schedule or the
    quality of the software being developed, and then taking action to avoid these risks
    Chapter 22  Project management
    (Hall, 1998; Ould, 1999). You can think of a risk as something that you’d prefer not
    to have happen. Risks may threaten the project, the software that is being developed,
    or the organization. There are, therefore, three related categories of risk:
    1. Project risks Risks that affect the project schedule or resources. An example of
    a project risk is the loss of an experienced designer. Finding a replacement
    designer with appropriate skills and experience may take a long time and, consequently,
    the software design will take longer to complete.
    2. Product risks Risks that affect the quality or performance of the software being
    developed. An example of a product risk is the failure of a purchased component
    to perform as expected. This may affect the overall performance of the system
    so that it is slower than expected.
    3. Business risks Risks that affect the organization developing or procuring the
    software. For example, a competitor introducing a new product is a business
    risk. The introduction of a competitive product may mean that the assumptions
    made about sales of existing software products may be unduly optimistic."

     
  • Categorias dos riscos: 
    o Riscos relacionados ao projeto – afetam a programação/recursos do projeto; 
    o Riscos relacionados ao produto – afetam a qualidade ou o desempenho do software que está em desenvolvimento;  (a falha de um componente comprado para o desempenho esperado e que compromete o desempenho geral do sistema)
     
    o Riscos para os negócios – afetam a organização que está desenvolvendo ou adquirindo o software. 

    • Exemplos de ocorrências:
     
    o Decorrência de requisitos mal-definidos; 
    o Dificuldades de estimar prazos e custos; 
    o Dependência de habilidades individuais; 
    o Mudanças nos requisitos;

    Fonte:
    http://www.garcia.pro.br/EngenhariadeSW/ULBRA-ENGENHARIA-6%20-%20Projeto%20-%20parte%202.pdf
  • Tem algo estranho nessa questão. Considerando os comentários do Paulo, trecho tirado do Sommervile, podemos classificar a falha de um componente como risco de produto e a mudança frequente de requisitos como risco de projeto. A alternativa (d) coloca na mesma classificação a falha de um produto e a mudança frequente de requisitos!
    Acho também que a tradução de failure para 'falha' é imprópria nesse caso e deixou a frase em português pouco clara.
  • Somerviller 9º ed pag 416

    Riscos de Projeto. Riscos que afetam o cronograma ou os recursos de projeto. Um exemplo de um risco de projeto é a perda de um projetista experiente. Encontrar um Projetista Substituto com competência e experiência adequado pode demorar muito tempo e, por conseguinte, o projeto de software vai demorar mais tempo para ser concluído.

    Riscos de Produto. Riscos que afetam a qualidade ou o desempenho do software que está sendo desenvolvido. Um exemplo de um risco de produto é a falha de um componente comprado para o desempenho esperado, podendo afetar o desempenho do sistema de forma mais lenta que o esperado.

    Riscos de Negocio. Os riscos que afetem a organização que desenvolve ou adquire o software. Por exemplo, um concorrente que introduz um novo produto é um risco empresarial. A introdução de um produto competitivo pode significar que as suposições feitas sobre venda de produtos de software existentes podem ser excessivamente otimistas.