Questões de Concurso Comentadas para serpro

São packages pertencentes à plataforma Java JEE: javax.ejb, javax.faces, javax.jms, javax.servlet, javax.mail e javax.transaction. Desses, os quatro primeiros foram desenvolvidos para uso direto no desenvolvimento de aplicações web.

O mobile Information deviceprofile compreende um conjunto de APIs (Application Programming Interfaces) para a programação Java em dispositivos móveis. Entre os packages disponíveis nesse conjunto, estão: javax.microedition.io, javax.microedition.lcdui, javax.microedition.rms e javax.microedition.midlet. São exemplos de classes pertencentes a cada um desses packages'. Connector, Command, RecordStore e MIDlet, respectivamente.

O padrão Composite é o mais indicado para a construção de componentes tratadores de eventos em interfaces gráficas compostas por múltiplos componentes visuais agregados, quando comparado a um possível emprego do padrão Mediator.

Para um projetista de software estender um componente desenvolvido segundo o padrão Command, com a capacidade de desfazer operações sobre objetos complexos sem violar o encapsulamento de tais objetos, o mais adequado é usar, de forma complementar, o padrão Memento, em vez do padrão Visitor.

Uma das conseqüências desejáveis do uso de uma façade é a promoção de acoplamento fraco entre um sistema e seus clientes, sobretudo porque as dependências de compilação entre módulos podem ser reduzidas. Uma das conseqüências indesejáveis é a redução de portabilidade dos sistemas.

No emprego do padrão fábrica abstrata, a criação de novos produtos dentro de uma mesma família toma-se dificultada, quando comparada à criação de novas famílias de produto que aderem a uma mesma estrutura de produtos abstratos.

No padrão builder, a responsabilidade pela criação de instâncias é compartilhada por um diretor e um construtor, sendo o vínculo entre eles estabelecido pelo cliente do padrão.

Padrões de criação, como singleton e prototype, envolvem necessariamente a instanciação de um ou mais objetos, sendo que, no padrão singleton, o controle sobre a instanciação é cedido ao cliente do padrão, o que não ocorre no padrão prototype.

A engenharia de software é um a disciplina do conhecimento humano que aplica princípios da engenharia ao desenvolvimento de software. N o entanto, existem diferenças significativas entre as engenharias clássicas — mecânica, civil, elétrica— e a engenharia de software, muitas delas decorrentes das diferenças de natureza entre o produto ou sistema resultante da atividade das engenharias clássicas e a engenharia de software. A engenharia de software desdobrou-se em várias áreas especializadas, como as áreas de requisitos de software, de análise e projeto de software, de implementação de software, de testes de software, de gestão de configuração, entre outras. N a interface entre as engenharias clássicas e a de software insere-se a engenharia de sistemas, abordada colateralmente na ISO/IEC 12207.

Identificação, auditoria, controle, contabilização de status e gerenciamento de liberações e entregas são atividades de gerência de configuração de software que ocorrem tipicamente na ordem enunciada, quando executados para determinado item de configuração.

Com relação ao emprego de diferentes técnicas para a realização de testes de software, é correto afirmar que haverá maior diminuição da dependência de acesso às especificações arquiteturais de um sistema se o testador empregar a técnica de caixa-branca (white-box), em vez das técnicas de caixa-cinza (,gray-box) e de caixa-preta (black-box).

A engenharia de software é um a disciplina do conhecimento humano que aplica princípios da engenharia ao desenvolvimento de software. N o entanto, existem diferenças significativas entre as engenharias clássicas — mecânica, civil, elétrica— e a engenharia de software, muitas delas decorrentes das diferenças de natureza entre o produto ou sistema resultante da atividade das engenharias clássicas e a engenharia de software. A engenharia de software desdobrou-se em várias áreas especializadas, como as áreas de requisitos de software, de análise e projeto de software, de implementação de software, de testes de software, de gestão de configuração, entre outras. N a interface entre as engenharias clássicas e a de software insere-se a engenharia de sistemas, abordada colateralmente na ISO/IEC 12207.

A homologação de um software é uma atividade pertinente aos processos de aquisição e não aos processos de garantia de qualidade, sendo ainda diretamente relacionada ao ciclo de vida de sistemas e não apenas de software.

A engenharia de software é um a disciplina do conhecimento humano que aplica princípios da engenharia ao desenvolvimento de software. N o entanto, existem diferenças significativas entre as engenharias clássicas — mecânica, civil, elétrica— e a engenharia de software, muitas delas decorrentes das diferenças de natureza entre o produto ou sistema resultante da atividade das engenharias clássicas e a engenharia de software. A engenharia de software desdobrou-se em várias áreas especializadas, como as áreas de requisitos de software, de análise e projeto de software, de implementação de software, de testes de software, de gestão de configuração, entre outras. N a interface entre as engenharias clássicas e a de software insere-se a engenharia de sistemas, abordada colateralmente na ISO/IEC 12207.

A atividade de teste unitário de software é, conforme os modelos de ciclo de vida de software vigentes, realizada de forma mais eficaz no escopo da implementação e da construção de software — nas quais a codificação de uma unidade executável de software é feita —, quando comparada à situação em que o teste unitário é realizado simultaneamente ao teste de integração.

A engenharia de software é um a disciplina do conhecimento humano que aplica princípios da engenharia ao desenvolvimento de software. N o entanto, existem diferenças significativas entre as engenharias clássicas — mecânica, civil, elétrica— e a engenharia de software, muitas delas decorrentes das diferenças de natureza entre o produto ou sistema resultante da atividade das engenharias clássicas e a engenharia de software. A engenharia de software desdobrou-se em várias áreas especializadas, como as áreas de requisitos de software, de análise e projeto de software, de implementação de software, de testes de software, de gestão de configuração, entre outras. N a interface entre as engenharias clássicas e a de software insere-se a engenharia de sistemas, abordada colateralmente na ISO/IEC 12207.

O emprego de padrões de projeto reusáveis, como façade, builder e singleton, é uma prática com nível inferior de abstração, quando comparado ao emprego de estilos arquiteturais de software, como camadas, cliente-servidor e peer-to-peer.

A engenharia de software é um a disciplina do conhecimento humano que aplica princípios da engenharia ao desenvolvimento de software. N o entanto, existem diferenças significativas entre as engenharias clássicas — mecânica, civil, elétrica— e a engenharia de software, muitas delas decorrentes das diferenças de natureza entre o produto ou sistema resultante da atividade das engenharias clássicas e a engenharia de software. A engenharia de software desdobrou-se em várias áreas especializadas, como as áreas de requisitos de software, de análise e projeto de software, de implementação de software, de testes de software, de gestão de configuração, entre outras. N a interface entre as engenharias clássicas e a de software insere-se a engenharia de sistemas, abordada colateralmente na ISO/IEC 12207.

A rastreabilidade bidirecional entre os requisitos e os demais produtos de trabalho do desenvolvimento de software — como as especificações arquiteturais, os planos de teste e os componentes de software — é uma característica de processos de gerenciamento de requisitos que exibem nível de capacidade 1 em organizações aderentes ao modelo CMMI.

Se o processo de desenho arquitetural de software, proposto na ISO/IEC 12207, for implementado de forma aderente ao padrão, ele produzirá uma linha de base (baseline) do desenho arquitetural do software, a qual será mantida sob gerência de configuração.

Visando a maior efetividade no processo de desenvolvimento, os requisitos de software são, em geral, desenvolvidos antes dos requisitos de sistema.

A área de atividade de requisitos de software apresenta maior interface com a engenharia de sistemas quando comparada à área de análise e projeto de software.

Acerca de modelos e abordagens à gestão de empreendimentos de desenvolvimento de software, julgue o item abaixo.

O modelo de gestão bazar, comparado ao modelo catedral, apresenta melhores condições para apoiar o desenvolvimento de software colaborativo, especialmente se este tiver código aberto e for aderente à abordagem de software livre. Tal modelo, comparado ao modelo catedral, apresenta ainda menor previsibilidade acerca da arquitetura do software que emerge da interação entre as pessoas.

O desenvolvimento sistemático de documentos XML que descrevem a arquitetura de software executável, composta por componentes, interfaces e interligações entre componentes, é uma característica de um modelo de ciclo de vida de software conhecido como DDP (document-driven process).

No modelo RUP, a primeira linha de base da arquitetura de um software é produzida ao final da fase de elaboração.