Objetos são componentes reusáveis, pois encapsulam um conjunto de atributos e operações que fornecem serviços a outros objetos.

Comentário

A análise e projeto orientada a objetos é a abstração conceitual dos componentes como objetos em um sistema, ou seja, através do paradigma orientado a objeto, temos objetos representando "coisas" do mundo real (bola, carros, relógios, pessoas, etc), essa representação se baseia em "componentes que podem ser reusáveis e mais de uma classe " (conjunto de objetos com características em comum).

Esses "componentes" representados por objetos, possuem atributos (características) e operações (comportamentos). Por fim, é a interação entre os objetos que fornecerá os serviços ou funcionalidades em um sistema, logo a questão está correta.

Gabarito: Correto

DevOps é uma metodologia de desenvolvimento de software que utiliza a comunicação para integrar desenvolvedores de software e profissionais de infraestrutura de TI.

Dessa forma, a infraestrutura como código é uma prática importante do DevOps, já que não basta somente o desenvolvedor escrever o código do sistema, é necessário que a área de infraestrutura também atue para liberar, controlar e entregar a versão do sistema de forma contínua, periódica e preferencialmente automática.

Assim, DevOps também ficou conhecida como uma metodologia ágil de controle de versão, entrega e integração contínua.

JSON é um formato de troca de dados utilizado em serviços web e outras aplicações interoperáveis.

Passagem de Parâmetro

Java só faz passagem de parâmetro por valor.

Organização de código em Java

Pacotes(package)

• Permitem a criação de "caminhos" de organização de código
• Normalmente seguem o caminho inverso do domínio da URL de uma empresa, adicionado da aplicação.
  • Ex: com.google.guava, com.facebook.api, com.netflix.docker
• Permitem a organização da sua aplicação por especialidade
  • java.util
  • java.net
  • java.sql
  • java.io

Herança e classe raiz

• Em java, toda classe deve estender de outra classe
• Quando uma classe não declara de quem ela estende, ele implicitamente estende de Object.
• Object é a classe raiz de qualquer hierarquia de classes java

A classe Object

• É o pai em último nível de qualquer classe java
• Declara comportamentos herdados por todos os objetos java
  • toString()
  • hashCode()
  • equals()

Identificadores - Dano nomes

• Identificador é o nome utilizado para representar variáveis, classes, objetos, métodos, pacotes, interfaces, ect.
• Regras
  • Caracteres válidos:
    • Letras UNICODE 16 maiúsculas ou minúsculas de vários idiomas
    • Números 0-9
    • Underscore _ ou cifrão $
  • Não pode começar com número
  • Não pode ser palavra reservada
  • Não pode ser uma literal (true, false, null, 10, etc)
  • Não pode ter caracteres em branco

Exemplos:

int MyVariable, myvariable, MYVARIABLE;
int x, i, OReilly;
int _myvariable, $myvariaBle, _9pins;

Nota: Java é case sensitive, ou seja, java é sensível a maiúsculas e minúsculas.

Palavras Reservadas

abstract, assert, boolean, break, byte, case, catch, char, class, const, continue, default, double, do, else, enum, extends, false, final, finally, float, for, goto, if, implements, import, instanceof, int, interface, long, native, new, null, package, private, protected, public, return, short, static, strictfp, super, switch, synchronized, this, throw, throws, transient, true, try, void, volatile, while

Instanciando objetos em Java

Controle instControle = new Controle();

Blocos e comandos

Comentários

/**
Comentário JAVADOC de mais de uma linha
*/

// Comentário de uma única linha

/*
Comentário de bloco
*/

Tipos Primitivos

• Lógico
  • boolean
• Caractere
  • char de 16 bits
• Inteiro
  • byte de 8 bits
  • short de 16 bits
  • int de 32 bits
  • long de 64 bits
• Decimal
  • float de 32 bits (7 casas decimais)
  • double de 64 bits (15 casas decimais)

Cuidado: A classe String não é um tipo primitivo.

Convertendo tipo primitivos

• Ocorre quando queremos transformar um tipo em outro
• Pode ser implícita ou explícita(quando pode haver alguma perda)
• Regra de ouro: O tipo de origem cabe no tipo de destino?

Operadores Aritméticos

Incremento prefixado e posfixado

• Prefixado: primeiro incrementa e depois retorna o valor.
• Posfixado: primeiro retorna o valor e depois incrementa.

Operadores de Atribuição

Operadores Relacionais

Operadores Lógicos

Operadores bit a bit

Vetores (Array)

Um vetor é uma estrutura de dados formada por um conjunto de dados ou outros elementos de um mesmo tipo, podendo ter uma dimensão ou mais (quando tem duas, é também chamado de matriz) e cujo acesso aos dados é feito através de índices.

Declaração:

// Declaração 1
tipo[] identificador1;
tipo indentifiador1[];

// Declaração 2
tipo[] identificador2 = new tipo[4];
tipo identificador2[] = new tipo[5];

// Declaração 3
tipo[][] identificador 3;
tipo identificador3[][]; 

Inicialização:

// Inicialização 1
int[] vetor1 = {34, 27, 91, 86};

// Inicialização2 (inválida)
int[] vetor2 = new int[4];
vetor2 = {34, 27, 91, 86};

// Inicialização 3
int[] vetor3 = new int[4];
vetor3[0] = 34;
vetor3[1] = 27;
vetor3[2] = 91;
vetor3[3] = 56;

Controle de Fluxo

Estrutura de Controle

IF

IF ... ELSE

IF ... ELSE IF ... ELSE

SWITCH

Estrutura de Repetição

While

Do ... While

Nota: Garante pelo menos 1 execução!

FOR

Continue vs Break

Requisitos não funcionais

• Requisitos do produto
  • Requisitos de eficiência
  • Requisitos de desempenho
  • Requisitos de espaço
  • Requisitos de confiabilidade
  • Requisitos de portabilidade
  • Requisitos de facilidade de uso
• Requisitos organizacionais
  • Requisitos de entrega (ou operacional)
  • Requisitos de implementação (ou desenvolvimento)
  • Requisitos de padrões (ou ambiental)
• Requisitos externos
  • Requisitos reguladores
  • Requisitos éticos
  • Requisitos legais
  • Requisitos de segurança
  • Requisitos de privacidade

Homologação de sistemas consiste em um processo de comprovação ou validação por parte do cliente/usuário de que o sistema de software desenvolvido atende aos requisitos solicitados no início do projeto. É a confirmação que a empresa tem de que o software por ela produzido foi instalado e funciona conforme deveria.

Uma estória de usuário pode ser caracterizada como uma curta e simples descrição da necessidade do cliente.

Ela normalmente é contada a partir da perspectiva de quem precisa da nova necessidade, sendo geralmente um usuário, cliente do sistema ou representante de negócios do cliente.

Uma estória de usuário deve explicar bem para quem, o que e por que está sendo criada.

Para evitar que uma estória de usuário seja feita de maneira despretensiosa foi criado o acrônimo INVEST para que pudéssemos lembrar facilmente das seis características de uma boa estória de usuário:

Independent
Negotiable
Valuable
Estimable
Small
Testable

Uma boa estória de usuário tem as seguintes características:

• Independente: A independência entre as User Stories facilita a priorização e a estimativa.
• Negociável: Pode ser renegociada para responder as mudanças.
• Valiosa: Deve trazer valor ao negócio do usuário.
• Estimável: Deve ser possível determinar o tempo necessário para entregá-la.
• Pequena: Deve caber em um sprint.
• Testável: O sucesso no teste é que vai garantir que a User Story foi desenvolvida corretamente.

Acerca da engenharia de requisitos no desenvolvimento de software, os protótipos descartáveis são os que não são utilizados posteriormente; protótipos evolutivos são aqueles que podem ser utilizados como base de parte ou de todo o software a ser desenvolvido.

Os Protótipos descartáveis, são aqueles que não se utiliza posteriormente, porque não existe uma reutilização deles para o escopo do projeto de um sistema.

Já os protótipos evolutivos, eles podem ser re-utilizados, para apoiar o desenvolvimento do software de maneira incremental.

As práticas do XP listadas descrevem respectivamente:

I. Integração contínua (continuous integration): Na integração contínua é uma iniciativa presente no XP ocorre durante todo o desenvolvimento, visando ao longo do projeto integrar o código desenvolvido, corrigindo possíveis inconsistência que surgirem.

II. Propriedade coletiva do código (collective code ownership): A propriedade coletiva do código visa possibilitar que qualquer desenvolvedor possa alterar o código, dando assim, mais celeridade ao processo de desenvolvimento.

III. Metáfora do sistema (system metaphor): A metáfora é uma história do usuário em alto nível, ou seja, pressupõe facilitar a abstração de funcionalidades pelos desenvolvedores e pelos usuários, trazendo a ideia que coesão para que qualquer pessoa possa compreender o que está sendo desenvolvido.

IV. Refatoração (Refactoring): A refatoração é uma prática constante no XP, onde o código desenvolvido é continuamente recriado pelos desenvolvedores, a fim de manter o código em aperfeiçoamento constante.

Precisamos, primeiramente, definir as alternativas para encontrar um norte em busca da resposta correta.

Factory Method: modelo de software que permite às classes delegarem funções para as subclasses decidirem, ou seja, permite a instanciação de subclasses, bem como objetos. É importante, para essa questão, ressaltar que esse método possui classes e subclasses bem definidas, possuindo diferenças significativas com a abstração abordada na questão.

Builder: padrão de projeto que visa criar diferentes representações de objetos a partir de um mesmo processo de construção, ou seja, uma única interface é responsável pela construção de diversos objetos. Sua diferença para o Abstract Factory está na construção dos objetos: enquanto o Builder constrói passo a passo, um a um, o AF constrói famílias de uma só vez.

Prototype: modelo de construção de protótipos (ou seja, versões iniciais). A partir deles, pode-se perceber as funcionalidades e implementar melhorias e processos, a fim de chegar ao produto final.

Abstract Factory: modelo de desenvolvimento que cria trechos de código que atuam de maneira genérica. Isso quer dizer que existe um grande nível de abstração, onde o software resultante pode ser “encaixado” em diversos tipos. Funciona assim: são criadas funcionalidades que podem ser aproveitadas em softwares dos mais diferentes tipos, e então pode-se reaproveitar um trecho de código para vários programas, sem necessidade de grandes alterações. Esse é o conceito de genérico.

Singleton: esse padrão permite apenas a criação de apenas uma instância de uma classe, o que garante um único ponto global de acesso ao objeto, e o seu objetivo é centralizar o acesso e gerenciamento de objetos dentro do programa.

Definidos os conceitos das alternativas, vamos analisar as 4 afirmativas, de uma maneira sequencial, integrando-as em uma linha de raciocínio.

Em (I), já é abordado o conceito mais fundamental da questão: a aplicação interage de maneira genérica. Isso dá uma boa pista sobre qual a nossa resposta correta.

Em (II), uma consequência disso: não importa qual a fábrica e o seu tipo, será gerado um objeto condizente com ela, independente de tudo. Isso exprime mais uma ideia de generalização (ou abstração, como queiram). Além disso, precisamos ter em mente que serão construídas famílias de objetos, que são grupos de objetos com estrutura semelhante.

Já em (III), é uma consequência da aplicação genérica: temos uma aplicação que se adapta ao tipo de fábrica, sem precisar sofrer alterações.

Por fim, (IV) segue a mesma lógica: se não é necessário alterar uma aplicação abstrata, pode-se adicionar, retirar ou alterar qualquer fábrica que já exista ou que entre no sistema.

Levando em consideração tudo o que foi desenvolvido na questão, devemos escolher o Abstract Factory.

O CakePHP segue o padrão de projeto Model-View-Controller.

Programar usando o MVC separa sua aplicação em três partes principais:

A camada Model

A camada Model (modelo) representa a parte de sua aplicação que implementa a lógica do negócio. Isto significa que ela é responsável por obter os dados convertendo-os em conceitos significativos para sua aplicação, assim como, processar, validar, associar e qualquer outra tarefa relativa ao tratamento dos dados.

À primeira vista, os objetos do tipo Model podem ser vistos como a primeira camada de interação com qualquer banco de dados que você possa estar usando na sua aplicação. Mas em geral eles representam os principais conceitos em torno do qual você implementa sua aplicação.

No caso de uma rede social, a camada Model cuida de tarefas como as de salvar os dados dos usuários e o relacionamento entre amigos, armazenar e recuperar as fotos dos usuários, encontrar novos amigos para sugestões e etc. Neste exemplo os Models podem ser vistos como «Amigo», «Usuario», «Comentario»e «Foto».

A camada View

Uma View exibe uma representação dos dados modelados. Sendo separadas do objeto Model, é responsável por usar as informações disponibilizadas para produzir qualquer interface de apresentação que sua aplicação possa necessitar.

Por exemplo, como a camada Model retorna um conjunto de dados, a view pode usá-los para exibir uma página HTML ou retornar o resultado em um formato XML para que outros o consuma.

A camada View não está limitada à representações dos dados no formato HTML ou texto, podendo ser usada para entregar uma variedade de formatos diferentes, dependendo do que você precisar, como vídeos, músicas, documentos e qualquer outro formato que você puder pensar.

A camada Controller

A camada Controller (controlador) lida com as requisições dos usuários. É responsável por retornar uma resposta com a ajuda das camadas Model e View.

Os Controllers podem ser vistos como gerentes tomando os devidos cuidados para que todos os recursos necessários para completar uma tarefa sejam delegados para os trabalhadores corretos. Ele aguarda os pedidos dos clientes, verifica a validade de acordo com as regras de autenticação e autorização, delega dados para serem obtidos ou processados pelos Models e seleciona o tipo correto de apresentação dos dados para o qual o cliente está aceitando para finalmente delegar o trabalho de renderização para a camada de visualização.

Cliclo de Vida de Requisição

Um ciclo de requisição típico do CakePHP começa com o usuário solicitando uma página ou recurso em sua aplicação. Esta solicitação é primeiramente processada por um dispatcher (expedidor) que irá selecionar o objeto Controller correto para lidar com a solicitação feita.

Assim que a solicitação do cliente chega ao Controller, este irá se comunicar como a camada Model para processar qualquer operação de busca ou armazenamento de dados que for necessário. Após esta comunicação terminar, o Controller continuará delegando, agora para o objeto View correto a tarefa de gerar uma saída resultante dos dados fornecidos pelo Model.

Finalmente quando a saída é gerada, ela é imediatamente enviada para o usuário.

A UML (Unified Modeling Language) é uma linguagem visual utilizada para modelar (especificar, visualizar, construir e documentar) os artefatos de sistemas computacionais por meio do paradigma de Orientação a Objetos. Tornou-se a linguagem-padrão de modelagem de software adotada internacionalmente pela indústria de Engenharia de Software.

A linguagem apoia a Engenharia de Software ao auxiliar na descrição do sistema em um alto nível de abstração. Ela não é uma linguagem de programação, mas uma linguagem de modelagem, cujo objetivo é auxiliar na definição das características do software, tais como requisitos, comportamento, estrutura lógica, a dinâmica de processos, etc.

A UML surgiu da união de três metodologias de modelagem: o método do americano Grady Booch, o método OMT(Object Modeling Technique) do sueco Ivar Jacobson e o método OOSE(Object-Oriented Software Engineering) do americano James Rumbaugh.

Um Técnico está participando de uma fase do PU e ajudou na especificação inicial de dois requisitos, considerados de maior risco. Estes requisitos foram implementados, servindo de base para o planejamento da próxima iteração. Nas iterações seguintes mais requisitos foram detalhados e melhor esclarecidos. Ao fim da fase, 90% dos requisitos estavam detalhados, o núcleo do sistema estava implementado com alta qualidade e os principais riscos puderam ser tratados. O Técnico participou da fase de

a) Concepção.
b) Requisitos.
c) Elaboração.
d) Construção.
e) Transição.

Comentário

A questão aborda as fases do processo unificado. Para o PU, fase é o intervalo entre dois marcos principais do projeto, durante o qual um conjunto bem definido de objetivos é atendido, artefatos são concluídos e decisões são tomadas sobre passar ou não para a próxima fase.

Vejamos algumas características de suas quatro fases:

Concepção: o objetivo desta fase é levantar, de forma genérica e pouco precisa, o escopo do projeto. Não deve existir aqui a pretensão de especificar de forma detalhada requisitos, a ideia é ter uma visão inicial do problema, estimar de forma vaga esforço e prazos e determinar se o projeto é viável e merece uma análise mais profunda.

Marco: Objetivos do Ciclo de vida: decide se o projeto é financeiramente viável e se vai ou não prosseguir com ele

Elaboração: a meta é criar a baseline para a arquitetura do sistema a fim de fornecer uma base estável para o esforço da fase de construção. Nesta fase todos (ou a grande maioria dos requisitos) são levantados em detalhes. Numa primeira iteração um ou dois requisitos, os de maior risco e valor arquitetural, são especificados em detalhes. Estes são implementados e servem como base de avaliação junto ao usuário e desenvolvedores para o planejamento da próxima iteração. Em cada nova iteração na fase de elaboração pode haver um seminário de requisitos, onde requisitos antigos são melhor esclarecidos e novos são detalhados. Ao fim da fase, 90% dos requisitos foram levantados em detalhes, o núcleo do sistema foi implementado com alta qualidade, os principais riscos foram tratados e pode-se então fazer estimativas mais realistas.

Marco: Arquitetura do Ciclo de Vida. Arquitetura estável, um dos critérios de avaliação é comparar a despesa real com a planejada

Construção: a meta é esclarecer os requisitos restantes e concluir o desenvolvimento do sistema com base na arquitetura da baseline. Nesta fase, ocorre a implementação iterativa dos elementos restantes de menor risco e mais fáceis e preparação para a implantação. Entre os objetivos desta fase temos: atingir as versões úteis (alfa, beta e etc.), concluir a análise, o projeto, o desenvolvimento e o teste de todas as funcionalidades necessárias, decidir se o software, os locais e os usuários estão prontos para a implantação.

Marco: Capacidade Operacional Inicial: determina se o produto está pronto para ser implantado num ambiente de teste beta

Transição: o objetivo é assegurar que o software esteja disponível para seus usuários finais. Inclui testar o produto em preparação para release e ajustes pequenos com base no feedback do usuário, que deve priorizar o ajuste fino do produto, a instalação, configuração e problemas de usabilidade. Problemas estruturais mais graves já devem ter sido tratados antes.

Marco: Release do Produto: decide se os objetivos foram atendidos e se outro ciclo de desenvolvimento deve ser iniciado.

Como pode ser percebido, os conceitos apresentados no comando da questão se referem à fase de elaboração.

Para a descrição de termos, o HTML utiliza 3 tags:

• <dl> - Description List - Lista de Definições
• <dt> - Description Term - Termo a ser descrito
• <dd> - Description Description - Descrição do termo propriamente dito

É um padrão de arquitetura de software que é muito utilizado em aplicações de grandes corporações.

Uma aplicação monolítica é aquele tipo de aplicação na qual toda a base de código está contida em um só lugar, ou seja, todas as funcionalidades estão definidas no mesmo bloco.

Os aplicativos que adotam o padrão monolítico são caracterizados por serem uma única aplicação onde a interface do usuário e o acesso e manipulação das informações são feitas em uma única camada.

Vantagens

• Facilidade de Desenvolvimento
  • Arquitetura mais simples de dá manutenção
  • Os desenvolvedores estão mais acostumados a trabalhar com essa arquitetura
  • Toda a aplicação é desenvolvida em uma mesma tecnologia, facilitando a coesão da equipe.
• Deploy único:
  • Fluxo de publicação mais simples e rápido. Um único pacote para se preocupar.
  • Alterou, compilou, é só publicar

Desvantagens

• Forte acoplamento entre os componentes
• Único ponto de falha: um pequeno problema em uma funcionalidade não muito importante pode quebrar a toda a aplicação.
• Base de código gigante: tende crescer desenfreadamente e se tornar um grande emaranhado de código.
• Baixa escalabilidade: serviços críticos não podem ser escalados individualmente.
• Preso a tecnologia: a adoção de novas tecnologias é difícil e geralmente toda a aplicação precisa ser migrada, o que geralmente resulta em uma stack de tecnologias defasadas a longo prazo.

A ferramenta SonarQube permite analisar a qualidade dos códigos-fontes que envolvem linguagens de computador e de dispositivos móveis e abrange categorias como padrões de codificação, testes e identificação de erros.

Comentário

O SonarQube é uma plataforma de software livre para realizar revisões automáticas com análise estática de código para detectar erros, códigos fora do padrão adequado e vulnerabilidades de segurança em mais de 25 linguagens de programação, incluindo Java, C #, JavaScript, TypeScript, C / C ++, COBOL e outras.

Totalmente integrado com as cadeias de ferramentas DevOps, ele vem com:

• integração com a maioria das ferramentas de construção, o que permite, na maioria dos casos, uma abordagem sem configuração;
• integração fácil com mecanismos de integração contínua, como Jenkins, DevOps do Azure, TeamCity, Bamboo, entre outros;
• suporte para inúmeras ferramentas de gerenciamento de configuração de origem, como Git, Subversion, CVS, Mercurial, entre outros;

Logo, a questão está correta ao afirmar que ferramenta SonarQube permite analisar a qualidade dos códigos-fontes que envolvem linguagens de computador e de dispositivos móveis e abrange categorias como padrões de codificação, testes e identificação de erros.

Nos anos 70 surgiu o modelo cascata, ou sequencial linear, ou monolítico, ou tradicional, ou waterfall. O modelo cascata é distribuído em fases, onde uma desencadeia a outra, logo cada fase possui requisitos para a fase seguinte, assim, uma fase só se inicia, quando a fase anterior é finalizada, por essa razão o modelo cascata é rígido, o que obviamente dificulta o processo de desenvolvimento e aumenta relativamente o risco do desenvolvimento de software, tendo em vista, que não teremos várias versões operacionais do software, teremos somente uma versão operacional, no final do desenvolvimento do software.

Assim sendo, caso eu não descubra um erro, ou um requisito errado, no inicio do desenvolvimento, provavelmente o produto final (software) será comprometido, por essa razão, a correção de erros no cascata é muito mais complexa, do que em outros modelos como o iterativo ou incremental.

O GIT é um sistema de gerenciamento de código fonte. Basicamente, serve como um grande monitor para desenvolvedores. Por meio dele, os desenvolvedores conseguem controlar e gerenciar programas em estágio de desenvolvimento, ou mesmo fazer a manutenção de códigos já prontos.

Dentro do Git, existem os snapshots: são mecanismos de controle que especificam um determinado estado de algo (por exemplo, uma pasta) em um momento exato, como se fosse uma “fotografia” de um radar de rodovia, por exemplo. Já o commit é um termo que remete à tornar permanente uma mudança feita experimentalmente, ou seja, confirmar alguma alteração no código. A questão quer dizer que o arquivo marcado terá sua especificação de estado feita assim que for confirmada no próximo evento de commit.

Estabelecidos os conceitos, vamos agora partir para as alternativas e explanar o que cada uma representa nesse contexto. Precisamos ter em mente que iremos analisar a ação de marcação do arquivo modificado.

• preparado: arquivos que estejam prontos para serem efetivados ou utilizados para qualquer função específica dentro de um contexto. Nesse caso, o arquivo modificado será efetivado no próximo commit.

• modificado: arquivo que sofreu alguma alteração dentro da sua funcionalidade. Nesse caso, o arquivo já estava modificado, e a ação que se analisa é a marcação de um arquivo modificado, e não a modificação dele. Cuidado com isso, é uma pegadinha!

• consolidado: arquivo que já foi efetivado após um commit. Não é o caso da questão.

• persistido: arquivo que se manteve inalterado. Também não é o caso da questão.

• depreciado: arquivo que urge por alguma modificação para que se mantenha com uma funcionalidade válida no sistema. Também não representa o caso.

EJB

Os dois containers que existem e executam em um servidor de aplicações Java EE completo são o Web Container e o EJB Container.

Exemplos: client container, applet container, web container , e EJB container.

Web Container

O Web Container é um container J2EE que hospeda aplicativos da web e amplia a funcionalidade do servidor web, fornecendo aos desenvolvedores a ambiente para executar servlets e Java Server Pages (JSPs).

EJB Container

Já para o EJB Container, temos os Beans corporativos (componentes EJB) que são componentes do servidor de linguagem de programação Java que contêm lógica de negócios. O EJB container fornece acesso local e remoto para beans corporativos.

JPA

HIBERNATE

Os testes de integração servem para verificar se o sistema desenvolvido está em conformidade com os requisitos levantados.

Comentário

Segundo (SOMMERVILLE, p.357), o teste de integração verifica se os componentes funcionam em conjunto.

Os testes que verificam a conformidade com os requisitos levantados seriam o teste de sistema (simula hardware e software reais) e o de aceitação (grupo de usuários finais validando os requisitos solicitados).

Gabarito: ERRADO.

Referência

SOMMERVILLE. Engenharia de Software. 8° Edição. Pearson. São Paulo, 2007.

Considere que um sistema está sendo desenvolvimento na Defensoria Pública e algumas das práticas adotadas são listadas a seguir:

− O Time de Desenvolvimento funciona de forma auto-organizada, sendo composto por profissionais que realizam o trabalho de entregar uma versão do sistema que seja funcional e que incrementa o produto “Pronto” ao final de cada sprint. Somente quem integra o Time de Desenvolvimento cria incrementos.
− Para desenvolver o sistema podem ser criadas várias sprints. Cada sprint é uma iteração que segue o ciclo PDCA. Ao final de cada sprint bem sucedida o time terá produzido um incremento potencialmente integrável, ou seja, com qualidade, testado, completo e pronto, por isso são realizadas reuniões de planejamento para definir a meta de cada sprint.
− O desenvolvedor escreve um teste que falha, faz este teste passar da maneira mais simples possível e, por fim, refatora o código. Esta prática visa a criação de código limpo, atuando como uma ferramenta de apoio na qualidade do desenvolvimento de sistema.

Um Técnico em Informática afirma, corretamente, que

a) todas as práticas indicam que a Defensoria adota somente a metodologia SCRUM. 
b) todas as práticas indicam que a Defensoria adota somente a metodologia XP. 
c) nenhuma das práticas indica que a Defensoria adota uma metodologia ágil de desenvolvimento. 
d) as práticas indicam que a Defensoria adota o desenvolvimento baseado em componentes. 
e) as práticas indicam que a Defensoria adota uma metodologia híbrida que reúne práticas ágeis.