Questões de Concurso Comentadas para analista de tecnologia da informação - desenvolvimento de sistemas

O nível de maturidade G é composto pelos processos Gerência de Projetos, Gerência de Requisitos e Gerência de Configuração – GCO.

No contexto do MR-MPS considera-se que o termo produto não pode incluir também serviços, mesmo que estes sejam entregues como parte do produto final ao cliente.

O propósito do processo de Medição e Análise é assegurar que os produtos de trabalho e a execução dos processos estejam em conformidade com os planos, procedimentos e padrões estabelecidos.

O propósito do processo Gerência de Configuração é estabelecer e manter todas as configurações dos equipamentos (hardware) necessários para o desenvolvimento do sistema e para a execução da aplicação, quando finalizada.

O propósito do processo Gerência de Projetos é estabelecer e manter planos que definem as atividades, recursos e responsabilidades do projeto, bem como prover informações sobre o andamento do projeto que permitam a realização de correções quando houver desvios significativos no desempenho do projeto. O propósito deste processo evolui à medida que a organização cresce em maturidade. Assim, a partir do nível E, alguns resultados evoluem e outros são incorporados, de forma que a gerência de projetos passe a ser realizada com base no processo definido para o projeto e nos planos integrados.

O processo Aquisição (AQU) não pode ser excluído de nenhuma avaliação do Nível F.

No nível A do MPS.BR somente é avaliado o processo Gerência de Projetos – GPR (evolução).

O processo Gerência de Portfólio de Projetos (GPP) não pode ser excluído de nenhuma avaliação do Nível F.

A divisão em 7 estágios tem o objetivo de possibilitar uma implementação e avaliação adequada às micros, pequenas e médias empresas.

O progresso e o alcance de um determinado nível de maturidade do MR-MPS-SW se obtêm quando são atendidos pelo menos 70% dos propósitos, 70% de todos os resultados esperados dos respectivos processos e 70% dos resultados esperados dos atributos de processo estabelecidos para aquele nível.

O Guia de Avaliação contém o processo e o método de avaliação MA-MPS, bem como os requisitos para as instituições implementadoras.

O Guia de Implementação sugere formas de se avaliar cada um dos níveis do MR-MPS-SW. Assim, este guia é destinado, principalmente, aos avaliadores líderes, avaliadores adjuntos e Instituições Avaliadoras (IA).

O Guia de Aquisição do MPS.BR é um documento complementar destinado, exclusivamente, a organizações públicas, principalmente do Governo Federal, que pretendam adquirir software e serviços. O Guia de Aquisição não contém requisitos do MR-MPS-SW e MR-MPS-SV, mas boas práticas para a aquisição de software e serviços.

O MR-MPS-SW define sete níveis de maturidade: A (Em Otimização), B (Gerenciado Quantitativamente), C (Definido), D (Largamente Definido), E (Parcialmente Definido), F (Gerenciado) e G (Parcialmente Gerenciado). A escala de maturidade se inicia no nível A e progride até o nível G.

O modelo MPS está dividido em quatro (4) componentes: Modelo de Referência MPS para Software (MR-MPS-SW), Modelo de Referência MPS para Serviços (MR-MPS-SV), Método de Avaliação (MA-MPS) e Modelo de Negócio (MN-MPS).

a OQL (Object Query Language) é o dialeto SQL padrão do Hibernate.

pode ser utilizado em aplicações Java standalone ou em aplicações Java EE, utilizando servlet, mas não pode ser utilizado em aplicações EE baseadas em Enterprise Java Beans (EJBs).

seu principal objetivo é diminuir a complexidade entre os programas Java, baseado no modelo orientado a objeto, que precisam trabalhar com um banco de dados relacional (maioria dos SGBDs comerciais).

no caso de aplicações construídas para serem executadas em servidores de aplicação, o gerenciamento das transações é realizado segundo o padrão JDBC. Já nas aplicações standalone, o programa delega o tratamento transacional ao driver JTA.

é um framework para o mapeamento objeto-relacional escrito na linguagem Java. Este framework facilita o mapeamento entre um banco de dados relacional e o modelo de objeto de uma aplicação OO, utilizando para isso, exclusivamente, arquivos (XML).

Todas as classes devem definir um destrutor.

Todas as classes devem definir um construtor.

Um construtor só pode acessar as variáveis estáticas (ou de classe).

Um construtor pode acessar as variáveis (atributos) de instância (não estáticas) de uma classe.

Um construtor é utilizado, principalmente, para inicializar os valores das variáveis estáticas (ou de classe).