Questão nº 45
Questão de Tecnologia da Informação · FCC TRT-20 2016 (nº 45)
A norma NBR ISO/IEC 12207:2009 estabelece uma estrutura comum para os processos de ciclo de vida de software, que pode ser referenciada pela indústria de software. A norma agrupa as atividades que podem ser executadas durante o ciclo de vida de um sistema que contém software em sete grupos de processo. No grupo de Processos de Projeto encontra-se o processo de
- AGestão de Risco, cujo propósito é identificar, analisar, tratar e monitorar riscos de forma contínua. (alternativa correta)
- BGestão de Configuração e Ativos de Serviço, cujo propósito é garantir a instalação e configuração dos softwares e controlar os ativos de serviço.
- CDefinição dos Requisitos dos Stakeholders, cujo propósito é definir os requisitos funcionais e não funcionais de um sistema.
- DAquisição, que tem como propósito obter um produto que satisfaça a necessidade expressa pelo adquirente.
- EGestão de Modelo de Ciclo de Vida, que tem como propósito definir, manter e garantir disponibilidade das políticas e modelos de ciclo de vida de software.
Resposta comentada
Gabarito Alternativa A
A NBR ISO/IEC 12207:2009 é um guia que organiza todas as etapas e atividades necessárias para desenvolver, operar e manter um software, agrupando-as em categorias para padronizar o trabalho. A questão se refere a um desses grupos de atividades.
- A) Correta: O processo de Gestão de Risco faz parte do grupo de "Processos de Habilitação Organizacional de Projeto" (Organizational Project-Enabling Processes) da norma, que pode ser interpretado como "Processos de Projeto" no contexto da questão. Seu propósito, "identificar, analisar, tratar e monitorar riscos de forma contínua", está em perfeita consonância com a descrição da norma (Seção 6.2.8).
- (B) Incorreta: O processo de Gestão de Configuração é um "Processo de Apoio" (Support Process), não de projeto, e "Ativos de Serviço" não é um processo direto da 12207.
- (C) Incorreta: A Definição dos Requisitos dos Stakeholders é um "Processo Técnico" (Technical Process), que foca na engenharia do software, e não um "Processo de Habilitação Organizacional de Projeto" (ou "Processo de Projeto" no sentido da questão). A armadilha da banca aqui é que a definição de requisitos é uma atividade crucial e inicial de qualquer projeto de software, fazendo com que muitos a associem diretamente a um "processo de projeto" de forma genérica, esquecendo a categorização específica da norma.
- (D) Incorreta: O processo de Aquisição é um "Processo de Acordo" (Agreement Process), que ocorre antes ou no início do projeto para contratar ou comprar o software, não sendo um processo de projeto em si.
- (E) Incorreta: Embora o processo de Gestão de Modelo de Ciclo de Vida também seja um "Processo de Habilitação Organizacional de Projeto", a descrição de seu propósito na alternativa ("garantir disponibilidade das políticas e modelos de ciclo de vida de software") tem pequenas imprecisões em relação à norma (Seção 6.2.2), que foca em "definir, manter e tornar disponível o(s) modelo(s) de ciclo de vida a ser(em) utilizado(s) pela organização", sem mencionar explicitamente "políticas" ou restringir a "de software" no propósito. A alternativa A é uma descrição exata.
Fonte: FCC TRT-20 2016 Técnico Judiciário - Área Apoio Especializado - Especialidade Tecnologia da Informação (Caderno Tipo 1). Reproduzida para fins de estudo.