Questões sobre Programação de Sistemas

Na etapa inicial do método MAgil estão previstas as atividades ilustradas no diagrama abaixo.

De acordo com as práticas Scrum, o

• A. Time Scrum é o único responsável por gerenciar o Backlog do Produto e busca garantir que o Backlog do Produto seja visível, transparente, claro para todos, indicando o que o Time de Desenvolvimento vai trabalhar a seguir.
• B. Product Owner pode ser um comitê e não uma pessoa. O comitê pode representar o desejo do Product Owner e o Scrum Master, podendo realizar alterações nas prioridades dos itens de Backlog do Produto.
• C. Scrum não reconhece títulos para os integrantes do Time de Desenvolvimento que não seja o Desenvolvedor, independentemente do trabalho que está sendo realizado pela pessoa e não há exceções para esta regra.
• D. Time Scrum consiste de profissionais que realizam o trabalho de entregar uma versão usável que potencialmente incrementa o produto “Pronto” ao final de cada Sprint. Somente integrantes do Time Scrum criam incrementos.
• E. Backlog do Produto é um conjunto de itens do Backlog da Sprint selecionados para a Sprint, juntamente com o plano para entregar o incremento do produto e atingir o objetivo da Sprint. O Backlog do Produto é a previsão do Time Scrum sobre qual funcionalidade estará no próximo incremento.

A etapa “Elicitar Requisitos” do método MAgil objetiva identificar, detalhar, documentar e fazer o gerenciamento dos requisitos que compõem os itens da Sprint, conforme os padrões de modelagem do projeto ou do Time Scrum.

Dentre as entradas desta etapa encontram-se:

− Visão do produto.

− Itens da Sprint.

− Entrevistas, brainstorming, questionários.

− Ferramentas e modelos de documentos.

Na técnica de Elicitação de Requisitos

• A. por entrevistas, o analista se insere no ambiente de trabalho em que o sistema será utilizado. O trabalho diário é observado e são anotadas as tarefas reais em que o sistema será utilizado.
• B. brainstorming, há um facilitador neutro cujo papel é conduzir o brainstorm e promover a discussão entre os vários mediadores. As tomadas de decisão são baseadas em processos bem definidos com o objetivo de obter um processo de negociação mediado pelo facilitador.
• C. por questionários, o objetivo é explorar aspectos críticos dos requisitos do produto a ser desenvolvido, implementando de forma rápida um pequeno subconjunto de funcionalidades deste produto.
• D. brainstorming, é indicado o uso de formulários quando há diversos grupos de usuários que podem estar em diferentes locais do país. Devem ser realizadas pesquisas específicas de acompanhamento apenas com usuários selecionados, e, dentre eles, aqueles cuja contribuição em potencial pareça mais importante.
• E. por entrevistas, um modo adequado para agir seria, por exemplo, dizer: “O Sr. José vê a solução para o projeto dessa forma. E a senhora, Maria, qual é a sua opinião?” O analista deve evitar colocar a credibilidade do entrevistado em cheque e ter em mente que ele é o perito no assunto e fornecerá as informações necessárias ao sistema.

A etapa “Testar os Requisitos Construídos” do método MAgil recomenda a aplicação das estratégias de teste definidas pelo projeto para minimizar os defeitos e não conformidades do produto no momento de sua verificação no ambiente de homologação, aumentando as chances de sua aprovação pelo Product Owner. São atividades previstas nesta etapa:

− Realizar o teste unitário da funcionalidade.

− Preparar e realizar os testes de integração e de regressão.

− Realizar teste de verificação e validação da funcionalidade.

− Autorizar, na medida do possível, os testes unitários, de integração e funcionais.

O teste

• A. unitário de classes de objetos fica mais complicado com generalização e herança, pois não se pode testar um método na classe em que está definido e assumir que funcionará corretamente nas classes que herdam este método.
• B. de validação é uma técnica sistemática para construir a arquitetura do software enquanto, ao mesmo tempo, conduz testes para descobrir erros associados às interfaces. O objetivo é, a partir de componentes testados no nível de unidade, construir uma estrutura de programa determinada pelo projeto.
• C. de verificação é a reexecução de algum subconjunto de testes que já foi conduzido para garantir que as modificações não propaguem efeitos colaterais indesejados.
• D. de regressão é conhecido como teste de caixa branca ou teste de caixa preta.
• E. de integração começa no fim do teste de validação e tem como objetivo avaliar se o que foi entregue atende às expectativas do cliente. A integração do software é obtida por meio de uma série de testes que demonstram conformidade com os requisitos.

A etapa “Construir os itens da Sprint” do método MAgil refere-se à implementação dos requisitos com apoio dos padrões de arquitetura, de banco de dados e de design estabelecidos para o projeto, com a intenção de entregar algo que possa gerar resultado observável ao Product Owner. Técnicas da eXtreme Programming − XP podem ser utilizadas.

Neste caso, a equipe pode optar pela técnica XP:

• A. BDD (Behavior-Driven Development), na qual os testes são escritos depois da funcionalidade. Esta técnica é muito simples mesmo quando há dependências entre classes da aplicação.
• B. Refatoração, que consiste em integrar o trabalho diversas vezes ao dia, assegurando que a base de código permaneça consistente ao final de cada integração.
• C. Integração contínua, que significa melhorar o código sem alterar sua funcionalidade. Se após a integração o código continuar funcionando como anteriormente, as novas mudanças são incluídas, o que possibilita manter um bom projeto, apesar das mudanças frequentes.
• D. Propriedade coletiva, que indica que todos são igualmente responsáveis por todas as partes. Os pares se revezam, as pessoas se revezam na formação dos pares e todos têm acesso e autorização para editar qualquer parte do código da aplicação, a qualquer momento.
• E. Incremento pronto, um time-boxed de um mês ou menos durante o qual um “Pronto”, versão incremental potencialmente utilizável do produto, é criado.

Os princípios SOLID reúnem cinco boas práticas para projetos Orientados a Objetos-OO. O princípio S, que se refere ao Single Responsability Principle-SRP ou Princípio de Responsabilidade Única, indica que uma classe deve ter uma e, apenas uma, razão para mudar. Considere a classe Java abaixo.

Com base no princípio SRP e nas boas práticas para projetos OO, é correto afirmar:

• A. O SRP visa aumentar o acoplamento entre classes e separar responsabilidades como forma de melhorar o código da aplicação OO sendo desenvolvida.
• B. A classe UrnaEleitoral tem acoplamento baixo, ou seja, tem um número pequeno de dependências e, portanto, fica mais sujeita a mudanças em decorrência de alterações em outras classes.
• C. Uma classe com mais de um motivo para mudar possui mais de uma responsabilidade e apresentando dificuldade de manutenção, mas, por outro lado, tem maior facilidade de reúso e de coesão.
• D. A classe UrnaEleitoral apresenta uma quebra do SRP, uma vez que possui responsabilidades que deveriam ser de componentes distintos do software.
• E. Em um projeto com várias classes seguindo o padrão da classe UrnaEleitoral fica mais fácil manter a coesão em um nível mais alto ou em nível de componentes, pois o software fica com uma divisão clara de camadas.

De acordo com o Modelo de Referência MPS para Software (MR-MPS-SW), alguns processos podem ser excluídos do escopo de uma avaliação MPS, total ou parcialmente, por não serem pertinentes ao negócio da unidade organizacional que está sendo avaliada. Cada exclusão deve ser justificada no Plano de Avaliação. A aceitação das exclusões e suas justificativas é responsabilidade do Avaliador Líder. É permitida a exclusão completa do seguinte processo do nível de maturidade F, desde que não executado pela organização,

• A. Desenvolvimento para Reuso − DRE.
• B. Aquisição − AQU.
• C. Integração do Produto − ITP.
• D. Gerência de Reúso − GRE.
• E. Medição de Riscos − MRI.

Considere que o Tribunal Regional Eleitoral esteja considerando a possibilidade de implantar um modelo de referência para qualidade de software. Um Técnico com especialidade em Programação de Sistemas após fazer um comparativo entre o primeiro nível de maturidade do CMMI versão 1.3 e do MR-MPS-SW, afirmou que o primeiro nível de maturidade do MR-MPSSW corresponde ao

• A. A (Parcialmente Gerenciado) e não possui processos específicos. Já no CMMI, o primeiro nível de maturidade inicia-se pelo 0 − Incompleto e não existe objetivo genérico neste nível, já que não há razão para institucionalizar um processo parcialmente executado.
• B. G (Parcialmente Gerenciado), composto pelos processos Gerência de Projetos e Gerência de Requisitos. Já no CMMI, o primeiro nível de maturidade inicia-se pelo 0 − Inicial e um processo deste nível realiza as atividades necessárias para produzir produtos de trabalho.
• C. G (Parcialmente Definido), composto pelos processos Definição do Processo Organizacional, Avaliação e Melhoria do Processo Organizacional e Gerência de Requisitos. Já no CMMI, o primeiro nível de maturidade inicia-se pelo 0 − Incompleto e um processo deste nível contribui com experiências de uso do processo para os ativos organizacionais.
• D. A (Parcialmente Definido) e não possui processos específicos. Já no CMMI, o primeiro nível de maturidade inicia-se pelo 0 − Inicial e os processos deste nível caracterizam melhoria organizacional relativa a uma única área de processo.
• E. G (Parcialmente Gerenciado), composto pelos processos Gerência de Projetos e Gerência de Requisitos. Já no CMMI, o primeiro nível de maturidade inicia-se pelo 1 − Inicial e os processos deste nível são usualmente ad-hoc e caóticos.

No âmbito de um projeto conduzido de acordo com as práticas do Scrum, a quantidade de dias estimada para concluir uma tarefa pode ser medida a partir da quantidade de atividades que um profissional consegue finalizar em um dia de trabalho. Para isso, considere que o cálculo seja feito utilizando a seguinte fórmula:

 Com esses valores definidos, a QD corresponde a

• A. 25 dias.
• B. 15 dias.
• C. 10 dias.
• D. 21 dias.
• E. 18 dias.

Consider the UML use case diagram below.

The diagram shows that

• A. top level use cases are View Items, Make Purchase, Online Shopping and Client Register.
• B. Make Purchase use case could be used by customer as top level use case if customer only wants to find and see some products. This use case could also be used as a part of View Items use case.
• C. Checkout use case is included use case, so it is not available by itself, as checkout is part of making purchase.
• D. the Online Shopping use case allows customer to register on the web site, for example to get some coupons or be invited to private sales.
• E. PayPal actor uses some web site to make purchases online.

The Rational Unified Process-RUP describes how to effectively deploy commercially proven approaches to software development. These are called best practices not so much because it´s possible to quantify precisely their value, but rather, because they are observed to be commonly used in industry by successful organizations. RUP provides each team member with the guidelines, templates and tool mentors necessary for the entire team to take full advantage, following best practices. One of these practices shows how to visibly model software to capture the structure and behavior of architectures and components. This allows the developer to hide the details and write code using graphical building blocks. Visual abstractions help to communicate different aspects of the software; see how the elements of the system fit together; make sure that the building blocks are consistent with the code; maintain consistency between a design and its implementation; and promote unambiguous communication. The industry standard UML, created by Rational Software, is the foundation for successful modeling.

The described practice refers to

• A. Develop software iteratively and verify software quality.
• B. Visually model software.
• C. Manage requirements.
• D. Use component-based architectures.
• E. Control changes to software.