Lista completa de Questões de Ciência da Computação do ano 2001 para resolução totalmente grátis. Selecione os assuntos no filtro de questões e comece a resolver exercícios.
Na gestão de mudanças tecnológicas do Modelo CMM,
os produtos de trabalho de software são mantidos consistentes entre si.
novas tecnologias adequadas são incorporadas na prática normal e transferidas para toda a empresa.
o padrão de processo de software da empresa e os processos de software de cada projeto definido são melhorados continuamente.
A representação dos dados compostos em Análise Estruturada de Sistemas pode ser feita por meio de
(1) uma seqüência de depósitos de dados, (2) uma seleção dentre um conjunto de itens de dados e (3) um agrupamento de dados por itens.
(1) uma seqüência de itens de dados, (2) uma seleção dentre um conjunto de itens de dados e (3) um agrupamento repetido de itens de dados.
(1) uma seqüência de itens de dados, (2) uma relação entre um conjunto de itens de dados e um conjunto de dados repetidos e (3) um agrupamento aleatório de itens de dados.
(1) uma relação composta de dados, (2) uma seleção dentre um extrato de itens de dados e (3) um agrupamento repetido de dados repetidos.
(1) uma relação indexada de itens de dados, (2) um conjunto de itens de dados selecionados por valor e (3) um agrupamento de dados constantes dos processos físicos.
Em Análise e Projeto orientado a Objetos com UML,
o diagrama de janelas constitui uma adaptação direta do diagrama de navegação de tela.
o diagrama de navegação de janelas constitui uma adaptação direta do diagrama de transição de tela.
o diagrama de transição de janelas constitui um desdobramento do diagrama de transição de tela.
o diagrama de navegação de objetos substitui o diagrama de transição de janelas.
a navegação entre diagramas de janelas fundamenta- se na transição de tela de diagramas.
Em Análise e Projeto orientado a Objetos,
modelos ação-resposta e diagramas de transição de dados modelam a visão do usuário, sendo úteis para a definição de serviços e mensagens de objetos.
modelos evento-resposta e diagramas de estado de transição modelam a visão de controle, sendo úteis para a definição de mensagens entre serviços.
sistemas evento-resposta e sistemas de transição de estado expressam controles de fluxo, sendo úteis para a definição de serviços e mensagens de objetos.
modelos evento-transição e diagramas de respostas de dados delimitam os procedimentos necessários para o controle de serviços e de mensagens.
modelos evento-resposta e diagramas de transição de estado modelam a visão de controle, sendo úteis para a definição de serviços e mensagens de objetos.
Em Análise e Projeto orientado a Objetos, as características de seleção para inclusão de objetos no modelo de análise são:
informação transferida, serviços entre objetos, atributos complexos, atributos comuns, transações comuns e requisitos eventuais.
informação repetida, serviços necessários, múltiplos atributos, atributos não comuns, operações essenciais e requisitos comuns.
transação retida, informações necessárias, múltiplos objetos, atributos comuns, operações internas e repositórios essenciais.
informação retida, serviços necessários, múltiplos atributos, atributos comuns, operações comuns e requisitos essenciais.
informação retida, serviços eventuais, atributos supertipos, atributos subtipos, operações entre atributos e relacionamentos essenciais.
Em Análise Orientada a Objetos,
a camada de serviços fornece uma visão dinâmica do sistema a ser modelado.
a camada de serviços fornece uma visão estática do sistema a ser modelado.
a camada de atributos fornece uma visão dinâmica do sistema a ser modelado.
o diagrama IERO não é uma ferramenta útil para visualizar o comportamento dinâmico de um sistema.
comunicações entre instâncias fazem parte da camada de serviços.
No Controle de Projetos de Software, o modelo COCOMO
permite aferir custos de até 63 projetos, simultaneamente, desde que possuam características similares em relação a seus membros.
é baseado em uma amostra de 63 fatores, que foram divididos em três domínios relacionados, definidos por tipo de produção.
é baseado em uma análise de 63 processos, que foram divididos em três diagramas sem acoplamento, definidos por tipo de função e por determinadas características dos gestores.
é baseado em uma análise de 63 objetos, caracterizados por pontos de controle indicativos dos requisitos de desenvolvimento previamente estabelecidos.
é baseado em uma amostra de 63 projetos, que foram divididos em três domínios separados, definidos por tipo de produto e por determinadas características do projeto e dos membros do grupo.
Os procedimentos-chave do esquema de correção de modelos de custos de fator único são:
(1) calcular a inversão de erro para cada projeto, (2) quantificar prováveis fatores não considerados, (3) correlacionar fatores de correção com fatores de previsão e (4) aplicar a correção e avaliar.
(1) calcular a previsão de erro para cada projeto, (2) quantificar prováveis fatores de correção, (3) correlacionar fatores de correção com erros de previsão e (4) aplicar a correção e avaliar.
(1) retirar os erros para cada projeto, (2) quantificar fatores de correção mais relevantes, (3) correlacionar fatores internos e externos de previsão e (4) aplicar a previsão e avaliar.
(1) minimizar o erro para cada previsão, (2) quantificar prováveis fatores subjetivos, (3) eliminar fatores de correção com menor erro de previsão e (4) avaliar a previsão.
(1) calcular a precisão de erro para cada processo, (2) avaliar prováveis fatores de correção, (3) normalizar fatores de correção com erros de precisão e (4) aplicar fator de precisão aceitável.
No Controle de Projetos de Software, uma das medidas da provável utilidade de um modelo de custo é o(a)
grau de convergência dos dados de amostra em torno da linha de previsão.
grau de consistência dos dados de amostra em torno da linha de evolução.
dimensão da amostra em torno da linha de convergência.
maior variância dos dados de amostra em torno da linha de previsão.
grau de convergência dos dados do fluxo em torno do tempo de previsão.
Na apuração de custos de software
utiliza-se uma série de fórmulas, que expressam o cronograma físico-financeiro do sistema.
o modelo de custos é um fluxo, que modela os custos que provavelmente recairão sobre a unidade gestora do projeto.
o modelo de custos é uma fórmula, ou uma série de fórmulas, usada para prever os custos que provavelmente recairão sobre o projeto.
o modelo de custos é uma fórmula destinada à previsão dos recursos financeiros necessários à conclusão do projeto sem a aquisição de recursos materiais e humanos adicionais.
o modelo de custos é um procedimento destinado ao melhor desempenho do sistema.
{TITLE}
{CONTENT}
{TITLE}
Aguarde, enviando solicitação...