Questões de Ciência da Computação do ano 2014

O CobiT 4.1 utiliza um modelo de maturidade. A vantagem de uma abordagem de modelo de maturidade é a relativa facilidade de os gerentes colocarem-se a si mesmos em uma escala e avaliar o que está envolvido no aprimoramento da performance dos processos, se necessário. O modelo de maturidade do CobiT 4.1 trabalha numa escala de 0 a 5, que demonstra como um processo evolui de capacidade inexistente (0) para capacidade otimizada (5), conforme apresentado abaixo:

(0) Gerenciamento de processos não aplicado.

( ) Processos seguem um caminho padrão.

( ) Processos são documentados e comunicados.

( ) Boas práticas são seguidas e automatizadas.

( ) Processos são ad hoc e desorganizados.

( ) Processos são monitorados e medidos. Nas definições acima, a escala 0 já foi associada à sua definição.

As associações subsequentes e respectivas dos valores da escala apresentados são:

• A. 1; 4; 2; 5; 3.
• B. 3; 2; 4; 1; 5.
• C. 2; 3; 5; 1; 4.
• D. 4; 5; 1; 3; 2.
• E. 3; 1; 5; 2; 4.

De acordo com o guia PMBoK 4a edição, a estrutura genérica do ciclo de vida de projeto apresenta algumas características, dentre as quais estão as apresentadas no gráfico abaixo.

Considerando o ciclo de vida do projeto e as informações do gráfico, é INCORRETO afirmar:

• A. Os níveis de custo e de pessoal são baixos no início, atingem um valor máximo enquanto o projeto é executado e caem rapidamente conforme o projeto é finalizado.
• B. As curvas representadas pelos custos de mudanças e influência dos stakeholders, riscos e incertezas são diretamente proporcionais devido às dificuldades da etapa de elicitação de requisitos, que permeia todo o ciclo de vida do projeto.
• C. A influência dos stakeholders, os riscos e as incertezas são maiores durante o início do projeto. Estes fatores caem ao longo da vida do projeto.
• D. A capacidade de influenciar as características finais do produto do projeto, sem impacto significativo sobre os custos, é mais alta no início e torna-se cada vez menor conforme o projeto progride para o seu término.
• E. Os custos das mudanças e correções de erros geralmente aumentam significativamente conforme o projeto se aproxima do término.

Está de acordo com o guia PMBoK 4a edição que:

• A. o plano de gerenciamento do projeto deve ser escrito no começo do ciclo de vida do projeto. Assim, um maior detalhamento do plano pode ser obtido na etapa de elaboração da EAP, em que informações mais detalhadas e específicas e estimativas mais exatas tornam-se disponíveis.
• B. gerenciar um projeto resume-se a identificar os requisitos e fazer o balanceamento das restrições conflitantes do projeto que se limitam ao Escopo, Qualidade, Cronograma, Recursos e Riscos.
• C. o gerenciamento de projetos é realizado através da aplicação e integração apropriadas dos 44 processos agrupados logicamente que abrangem os 5 grupos de processo, quais sejam: Planejamento; Execução; Monitoramento; Controle e Encerramento.
• D. o guia PMBoK descreve os processos, ferramentas e técnicas de gerenciamento de projetos a serem usados até a obtenção de um resultado bem-sucedido. Esse padrão é exclusivo ao campo de gerenciamento de projetos de software e tem relacionamento com outras disciplinas como gerenciamento de programas e gerenciamento de portfólios.
• E. o ciclo de vida pode ser definido ou moldado de acordo com aspectos exclusivos da organização, indústria ou tecnologia empregada. Ao passo em que todos os projetos têm um início e um fim definidos, as entregas e atividades específicas conduzidas neste ínterim poderão variar muito de acordo com o projeto.

• A.
• B.
• C.
• D.
• E.

Herança e interfaces são conceitos da orientação a objetos que possibilitam a obtenção de polimorfismo. Em Java, uma interface pode

• A. herdar de mais de uma interface.
• B. ser instanciada diretamente por meio da instrução new.
• C. possuir apenas assinaturas de métodos públicos e protegidos.
• D. possuir métodos abstratos e estáticos.
• E. conter declarações de constantes e de variáveis não inicializadas.

• A. 35.
• B. 33.
• C. 31.
• D. 28.
• E. 30.

Os modelos ágeis de desenvolvimento de software têm menos ênfase nas definições de atividades e mais ênfase na pragmática e nos fatores humanos do desenvolvimento. Um destes modelos enfatiza o uso de orientação a objetos e possui apenas duas grandes fases: 1 − Concepção e Planejamento e 2 − Construção. A fase de Concepção e Planejamento possui três disciplinas (chamadas de processos): Desenvolver Modelo Abrangente, Construir Lista de Funcionalidades e Planejar por funcionalidade. Já a fase de Construção incorpora duas disciplinas (processos): Detalhar por Funcionalidade e Construir por Funcionalidade.

O texto acima apresenta a metodologia ágil conhecida como

• A. XP.
• B. Scrum.
• C. Crystal Clear.
• D. ASD.
• E. FDD.

Considere as seguintes atividades:

1. Compreensão do domínio: os analistas devem desenvolver sua compreensão do domínio da aplicação.

2. Coleta de requisitos: processo de interagir com os stakeholders do sistema para descobrir seus requisitos.

3. Classificação: atividade que considera o conjunto não estruturado dos requisitos e os organiza em grupos coerentes.

4. Resolução de conflitos: Solucionar conflitos decorrentes do envolvimento de múltiplos stakeholders.

5. Definição das prioridades: envolve a interação com os stakeholders para a definição dos requisitos mais importantes.

6. Descarte de requisitos: atividade de descartar requisitos menos importantes, baseando-se nas indicações dos stakeholders.

7. Verificação de requisitos: os requisitos são verificados para descobrir se estão completos e consistentes e se estão em concordância com o que os stakeholders desejam do sistema.

8. Modelagem de requisitos: os requisitos são modelados utilizando-se o diagrama de casos de uso e de sequência da UML.

Faz parte do processo de levantamento e análise de requisitos o que consta em APENAS 1, 2,

• A. 3, 4, 5, 7 e 8.
• B. 3, 4, 5, 6.
• C. 3, 4, 5 e 7.
• D. 4, 5, 7 e 8.
• E. 3, 4, 6 e 8.

Os modelos do CMMI são descritos em termos de áreas de processo, metas e práticas. Áreas de processo são conjuntos de práticas relacionadas em uma determinada área que, quando executadas coletivamente, satisfazem um conjunto de metas consideradas importantes para causarem uma melhoria significativa naquela área. São áreas de processo relacionadas diretamente à Engenharia de Requisitos no CMMI:

• A. Gerência (ou Gestão) de Requisitos, Análise de Requisitos e Desenvolvimento de Requisitos.
• B. Levantamento de Requisitos e Análise de Requisitos.
• C. Levantamento de Requisitos, Modelagem de Requisitos e Desenvolvimento de Requisitos.
• D. Gerenciamento de Requisitos e Negociação de Requisitos.
• E. Gestão (ou Gerência) de Requisitos e Desenvolvimento de Requisitos.

• A. sprint burndown, product backlog, sprint backlog, scrum team.
• B. sprint planning meeting, product backlog, sprint backlog, product owner.
• C. scrum planning, sprint backlog, product backlog, product owner.
• D. sprint planning meeting, product backlog, sprint backlog, scrum master.
• E. scrum daily meeting, product backlog, sprint backlog, scrum master.