SóProvas

Questões de XP (eXtreme Programming)

ID
5239
Banca
CESGRANRIO
Órgão
REFAP SA
Ano
2007
Provas
Disciplina
Engenharia de Software
Assuntos

NÃO é uma característica da Extreme Programming (XP):

Alternativas
Comentários
  • Milho R$ 16,00 Trigo R$ 25,00??? hehehe
  • De onde surgiu esse Milho e Trigo? :D
  • a) Correto! Fazer apenas aquilo que o cliente pediu!
    b) Correto! Por isso reduz várias etapas como a análise e desenho, por exemplo.
    c) Correto! Os testes são feitos antes mesmo da codificação
    d) Correto! Um programa e o outro avalia, sendo que eles revezam.
    e) Utiliza da Engenharia Reversa, pois não se interessam em focar-se na Análise e Desenho.

  • e)documentação extensa e abundante em artefatos.

    Vai contra o principio da simplicidade, o que é necessari considerando que agile prevê que alterações de requisitos sempre vao aparecer

ID
17752
Banca
CESGRANRIO
Órgão
BNDES
Ano
2008
Provas
Disciplina
Engenharia de Software
Assuntos

Que situação favorece a escolha do uso de XP para um projeto de desenvolvimento de software, em oposição à escolha do RUP ou do modelo Cascata?

Alternativas
Comentários
  • O cliente sempre presente é uma das práticas do XP, como pode ser observado em:

    Cliente Sempre Presente - o cliente não é alguém de fora, mas sim um membro da equipe. Ele deve estar sempre disponível e pronto para atender às dúvidas dos desenvolvedores.

    http://agilblog.locaweb.com.br/tag/xp/

  •  a)Equipe do projeto localizada em diferentes cidades e com poucos recursos de colaboração.errado - XP favorece pair programming e trabalho em proximidade com os stakeholders. 

     b)Equipe do projeto formada por pessoas com alto grau de competitividade. - XP encoraja compartilhamento do codigo e trabalho junto; o oposto de competeição

     c)Cliente do projeto trabalhando em parceria com a equipe do projeto e sempre disponível para retirar dúvidas.- correto

     d)Requisitos do software com pequena probabilidade de mudanças. - errado- XP prevê que mudanças podem ocorrer a qualquer momento

     e)Presença de um processo organizacional que exige a elaboração de vários documentos específicos para cada projeto.- agile nao gosta de documentação. 

  • TCU é sessão extraordinária.

ID
27286
Banca
FCC
Órgão
TRE-SE
Ano
2007
Provas
Disciplina
Engenharia de Software
Assuntos

Na XP (eXtreme Programming)

Alternativas
Comentários
  • "O XP recomenda que depois que as histórias forem desenvolvidas e o trbaalho preliminar de projeto for feito, a equipe não avance para o código mas, em vez disso, desenvolva uma série de testes unitários." (Eng. Software - Pressman)
  • A opção correta é a letra B, "os programadores desenvolvem o software criando primeiramente os testes."É o que chamamos de Test First Design - Primeiro são escritos os testes, depois é feita a implementação e por último trabalha-se o design.
  • a) Uma das características do XP é a refatoração, contrário ao modelo de ciclo de vida em cascata tradicional.
    b) correto!
    c) Comunicação com os clientes é uma das características principais do XP.
    d) Não existe nenhum modelo que faça todos os testes possíveis. ISSO É IMPOSSÌVEL! Princípios básicos da Engenharia de Software.
    e) Não é necessário no XP, visto que ele prega a refatoração.
  • De acordo com [1], são práticas do XP:
    1. Planejamento incremental;
    2. Pequenos releases;
    3. Projetos Simples;
    4. Desenvolvimento test-first;
    5. Refactoring;
    6. Programação em pares;
    7. Propriedade coletiva;
    8. Integração contínua;
    9. Ritmo sustentável;
    10. Cliente on-site;
    [1]: Sommerville, ENg. de Software, 8 ª edição, página 264

  • Isso é uma obrigação? Escrever testes primeiro é uma prática, que você pode ou não executar.

  •  b)os programadores desenvolvem o software criando primeiramente os testes.

    EM XP, os desenvolvedores agem em pares planejam testes antes do codigo. 

ID
28570
Banca
CESGRANRIO
Órgão
DECEA
Ano
2006
Provas
Disciplina
Engenharia de Software
Assuntos

Assinale a metodologia de desenvolvimento de software que tem como prática a programação em pares.

Alternativas
Comentários
  • Programação Extrema (do inglês eXtreme Programming), ou simplesmente XP, é uma metodologia ágil para equipes pequenas e médias e que irão desenvolver software com requisitos vagos e em constante mudança. Para isso, adota a estratégia de constante acompanhamento e realização de vários pequenos ajustes durante o desenvolvimento de software.

    Para aplicar os valores e princípios durante o desenvolvimento de software, XP propõe uma série de práticas. Há uma confiança muito grande na sinergia entre elas, os pontos fracos de cada uma são superados pelos pontos fortes de outras. Uma destas práticas é a "Programação em Pares".

    Programação em Pares (Pair Programming): é a programação em par/dupla num único computador. Geralmente a dupla é formada por um iniciante na liguagem e outra pessoa funcionando como um instrutor. Como é apenas um computador, o novato é que fica à frente fazendo a codificação, e o instrutor acompanha ajudando a desenvolver suas habilidades. Desta forma o programa sempre é revisto por duas pessoas, evitando e diminuindo assim a possibilidade de erros (bugs). Com isto busca-se sempre a evolução da equipe, melhorando a qualidade do código fonte gerado.
  • Programação Extrema (do inglês eXtreme Programming), ou simplesmente XP, é uma metodologia ágil para equipes pequenas e médias e que irão desenvolver software com requisitos vagos e em constante mudança. [http://pt.wikipedia.org/wiki/Programa%C3%A7%C3%A3o_Extrema]

    O MSF para Desenvolvimento Ágil de Software é um guia de procedimentos, uma coleção de boas práticas para projetos de desenvolvimento de softwares. [http://pt.wikipedia.org/wiki/Microsoft_Solution_Framework]

    O RUP, abreviação de Rational Unified Process (ou Processo Unificado da Rational), é um processo proprietário de Engenharia de software criado pela Rational Software Corporation. [http://pt.wikipedia.org/wiki/Rup]

    O Project Management Body of Knowledge, também conhecido como PMBOK®[1] é um conjunto de práticas em gerência de projetos. [http://pt.wikipedia.org/wiki/Pmbok]

    O CMMI (Capability Maturity Model Integration) é um modelo de referência que contém práticas (Genéricas ou Específicas) necessárias à maturidade em disciplinas específicas (Systems Engineering (SE), Software Engineering (SE), Integrated Product and Process Development (IPPD), Supplier Sourcing (SS)) [http://pt.wikipedia.org/wiki/Cmmi]

    portanto, XP é a única metodologia de desenvolvimento de software dentre as listadas.
  • Programação extrema (do inglês eXtreme Programming), ou simplesmente XP, é uma metodologia ágil para equipes pequenas e médias e que irão desenvolver software com requisitos vagos e em constante mudança. Para isso, adota a estratégia de constante acompanhamento e realização de vários pequenos ajustes durante o desenvolvimento de software.Os quatro valores fundamentais da metodologia XP são: comunicação, simplicidade, feedback e coragem. A partir desses valores, possui como princípios básicos: feedback rápido, presumir simplicidade, mudanças incrementais, abraçar mudanças e trabalho de qualidade.Dentre as variáveis de controle em projetos (custo, tempo, qualidade e escopo), há um foco explícito em escopo. Para isso, recomenda-se a priorização de funcionalidades que representem maior valor possível para o negócio. Desta forma, caso seja necessário a diminuição de escopo, as funcionalidades menos valiosas serão adiadas ou canceladas.A XP incentiva o controle da qualidade como variável do projeto, pois o pequeno ganho de curto prazo na produtividade, ao diminuir qualidade, não é compensado por perdas (ou até impedimentos) a médio e longo prazo.O Rational Unified Process® (também chamado de processo RUP®) é um processo de engenharia de software. Ele oferece uma abordagem baseada em disciplinas para atribuir tarefas e responsabilidades dentro de uma organização de desenvolvimento. Sua meta é garantir a produção de software de alta qualidade que atenda às necessidades dos usuários dentro de um cronograma e de um orçamento previsíveis.Ou seja a resposta correta é a letra B
  • pessoalzinho do CTRL+C CTRL+V, ao menos divulguem a fonte.

  • Sem mistérios! Falou em programação em PARES falou em Extreme Programming - XP -  que é uma metologia de desenvolmento ágil.

  • XP

    caracteristicas de cp (extreme programming) stand-up meetings, pair programming, escrita de testes antes do codigo, 5 valores (comunicação, simplicidade, feedback, coragem, respeito).

ID
56722
Banca
CESPE / CEBRASPE
Órgão
ANAC
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Segundo Ian Sommerville, (Engenharia de software, 2007, p.
5), a engenharia de software é uma disciplina de engenharia
relacionada a todos os aspectos da produção de software, desde
os estágios iniciais de especificação do sistema até sua
manutenção. Acerca da engenharia de software, julgue os itens a
seguir.

Extreme Programming é um modelo de processo de desenvolvimento de software para equipes com grande número de pessoas, que desenvolvem software com base em requisitos vagos e que são modificados rapidamente.

Alternativas
Comentários
  • a questão ficou errada apenas por colocar que é para equipes grandes... As equipes devem ter no máximo 10 desenvolvedores.
  • ERRADO.
    Extreme Programming é um modelo de processo de desenvolvimento de software para equipes com grande número de pessoas, que desenvolvem software com base em requisitos vagos e que são modificados rapidamente.
    As equipes no XP devem ter tamanho pequeno ou médio, agora grande número de pessoas não e é aí que está o erro da questão. O Software tem requisitos vagos e sofre constante mudanças.

    []s
    Bons estudos
    Marcelo

  • queria que na minha prova do TRE fosse assim!

ID
72097
Banca
CESGRANRIO
Órgão
IBGE
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

O XP (Extreme Programming) usa uma abordagem orientada a objetos como seu paradigma de desenvolvimento predileto. Nessa perspectiva, analise as afirmativas abaixo.
I - A atividade de Codificação começa com a criação de um conjunto de histórias que descreve as características e as funcionalidades requeridas para o software a ser construído.

II - O XP encoraja o uso de cartões CRC (Class- Responsibility-Colaborator) como um mecanismo efetivo para raciocinar sobre o software no contexto orientado a objetos.

III - O XP emprega a técnica de refectoring na codificação, mas desaconselha a utilização da programação por pares.

IV - A criação de testes unitários antes da codificação começar é uma prática do XP.

V - Se um difícil problema de projeto é encontrado como parte do projeto de uma história, o XP recomenda a criação imediata de um protótipo operacional daquela parte do projeto.

Estão corretas APENAS as afirmativas

Alternativas
Comentários
  • A maior duvida deve ficar entre a alterntiva "C" e "E". Existe uma pequena nuance no item I. que diz "A atividade de Codificação começa com a criação de um conjunto de histórias" Atividade de codificação começa com a escrita de testes. Já o item III pode ser desconsidera, pois o XP encoraja a programação em pares.
  • Eu entendo que a opção I está incorreta porque a criação das estórias é feita anteriormente à codificação, e não como inicio da mesma. Se observar bem, I e IV são conflitantes pois, se você começa a testar antes de codificar (e isso está correto), não é possível escrever os testes se primeiro definir a estória.Assim, I não é uma afirmação verdadeira.
  • I. O conjunto de histórias se desenrola nas atividades de planejamento e projeto, na codificação já deverão estar prontas.

    III. A codificação no XP é feita através da programação em pares.

    Demais questões corretas.
  • I - A atividade de (Codificação) Planejamento começa com a criação de um conjunto de histórias que descreve as características e as funcionalidades requeridas para o software a ser construído. 
    Errado. O XP envolve um conjunto de regras e práticas constantes no contexto de quatro atividades metodológicas: Planejamento, Projeto, Codificação e Testes. Na atividade de Planejamento (também denominada o jogo do planejamento) é que são criadas as histórias de usuários. Essas histórias descrevem o resultado, as características e a funcionalidade para o software a ser construído. (pag 88)

    II - O XP encoraja o uso de cartões CRC (Class- Responsibility-Colaborator) como um mecanismo efetivo para raciocinar sobre o software no contexto orientado a objetos.
    Certo. A XP encoraja o uso de cartões CRC como um mecanismo eficaz para pensar sobre o software em um contexto orientado a objetos. Os cartões CRC identificam e organizam as classes orientadas a objetos relevantes para o incremento de software corrente. Os cartões CRC são o único artefato de projeto produzidos como parte do processo XP. (pag 89)

    III - O XP emprega a técnica de refectoring na codificação, (mas desaconselha) como também a utilização da programação por pares. 
    Errado. Um conceito-chave na atividade de codificação (e um dos mais discutidos aspectos da XP) é a programação em dupla. A XP recomenda que duas pessoas trabalhem juntas em uma mesma estação de trabalho para criar código para uma história. (pag 90)

    IV - A criação de testes unitários antes da codificação começar é uma prática do XP.
    Certo. A criação de testes de unidade, antes de começar a codificação, é um elemento-chave da abordagem XP. (pag 90)

    V - Se um difícil problema de projeto é encontrado como parte do projeto de uma história, o XP recomenda a criação imediata de um protótipo operacional daquela parte do projeto.
    Certo. Se um difícil problema de projeto é encontrado como parte do projeto de uma história, o XP recomenda a criação imediata de um protótipo operacional daquela parte do projeto. Denominada solução pontual, o protótipo é implementado e avaliado. O objetivo é reduzir o risco para quando a verdadeira implementação iniciar e validar as estimativas originais para a história contendo o problema de projeto. (pag89)

    (Fonte: Livro Engenharia de Software 7ed, Pressman)

    Logo, gabarito "E"
ID
119287
Banca
FCC
Órgão
TRF - 4ª REGIÃO
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

A Extreme Programming (XP) baseia-se em 12 práticas, que são um conjunto de atividades que deverão ser seguidas pelas equipes que desejam utilizar a XP. Na prática do Jogo do Planejamento, as funcionalidades são descritas em pequenos cartões que são conhecidos como

Alternativas
Comentários
  • Alguma práticas de XP para vocês decorarem :))* Metáforas* Time pequenos e coeso (até 10 membros)* Posse Coletiva do Código* Programação em Par(Pair Programming)* Padrões de Codificação* Clientes Presentes* Jogo de Planejamento: escolhem o que fazer na semana (o mais importante)* Releases Curtos (Small Releases)* Desenvolvimento guiado pelos testes(Test Driven Development) - Automatizados (ex.: JUnit)* Integração Continua(Continuous Integration)* Refatoração(Refactoring ou refabricação: todos são obrigados a melhorar o código)* Reuniões de Pé(Stand-up Meeting)* Ritmo Sustentável(Sustainable Pace)* Duração máxima de 36 meses com semana de 40 horas* Design simples do sistema***** CRC: modelagem de classes usando story cards (usuários descrevem funcionalidade do sistema)
  • Leoh,originalmente, ou seja, aquilo que está nos literatura científica é o que realmente podem ser utilizados para resolver problemas em concurso. Apesar de serem práticas adotadas por alguns, não é parte do XP definir desta maneira as coisas, logo, segundo Kent Beck e Vinicius Teles, algumas das práticas que você colocou estão incorretas. Tais são:-Duração máxima de 36 meses com semana de 40 horas-Times Pequenos.Ainda há autores que consideram que a Design Simples não é uma prática e sim um valor.Em regra geral, não é o que falam por ai que vale para concurso, precisa-se ter embasamento literário aceito no mundo acadêmico. Logo: -Duração máxima de 36 meses com semana de 40 horas, não é uma prática do XP. Qualquer pessoa que adotá-lo pode mudar estes valores, logo não é aceito como uma prática do XP e -Times Pequenos, não é uma prática e sim uma recomendação (apesar de ser praticada).Sobre a questão:a) Cartão de Requisito ainda não foi criado na literatura nacional, pelo menos que eu conheça. Logo ERRADA.b) Cartão de Planejamento: apesar do XP se utilizar de cartões para planejar (estimar) isto não o classifica como cartão de planejamento. Logo ERRADA.c) Cartão chave que eu conheço é aquele que dá acesso a entrada em um quarto no Hotel 5 estrelas aqui da cidade. ERRADAd) Cartões inteligentes são, atualmente, considerados aqueles que possuem um chip e capazes de armazenas informações, inclusive certificados digitais, como é o caso do e-CPF. Logo ERRADA.e) As Historias do Usuário, também conhecido como Store Card (Cartão de História) e a alternativa CORRETA.
  • Citando: Pressman, Engenharia de Software, 6ª edição, p. 63

    "Planejamento. A atividade de planejamento começa com a criação de um conjunto de histórias (também chamado de histórias de usuário) que descrevem as características e funcionalidades requeridas para o software a ser construído. Cada história (semelhantes aos casos de uso descritos nos Capítulos 7 e 8) é escrita pelo cliente e é colocada em um cartão de indexação."

  • Segundo SOMMERVILLE,
    Os cartões de estória são as principais entradas para o processo de planejamento em XP ou "jogo de planejamento". 

ID
128473
Banca
FCC
Órgão
TRT - 15ª Região (SP)
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Histórias de usuários na atividade de planejamento, encorajamento de uso de cartões CRC e de refabricação, reuniões em pé e programação em pares são características típicas do modelo de processo de software

Alternativas
Comentários
  • Características da XP.

    Acrescento outras [1] Planejamento Incremental; Pequenos releases; Projeto Simples; Desenvolvimento test-first; Propriedade coletiva; Integração contínua; Ritmo sustentável; Cliente on-site.
    [1] SOmmerville, Engenharia de Software, 8ª Edição, página 264

  • MVC (Padrão de arquitetura de software - Model, View, Controller)

  •  a)XP.

    XP prioriza simplicidade, comunicação, feedback, coragem & respeito, além de programação a 2 e planejamento de testes antes do codigo

  • A questão tem uma parte errada: "encorajamento de uso de cartões CRC". Os cartões CRC são usados na fase de "Projeto", dentro do ciclo do XP.

     

    Planejamento > Projeto > Codificação > Teste = Entrega de release

ID
136249
Banca
ESAF
Órgão
MPOG
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

As atividades do modelo espiral de Engenharia de Software são:

Alternativas
Comentários
  • =>As atividades do modelo espiral de Engenharia de Software são:

    Apesar de que está faltando Construção e Comunicação com Cliente, o item mais coreto é:
    b) Planejamento, Análise dos Riscos, Engenharia e Avaliação feita pelo cliente
  • Modelo Espiral de Boehm: Planejamento, Análise de riscos, Engenharia e Avaliação do cliente
    Modelo Espiral de Pressman: Comunicação, Planejamento, Análise de riscos, Engenharia, Construção e release e Avaliação do cliente

  • Complementando a resposta, muito boa do colega Leonardo:

    Modelo Espiral de Boehm: Planejamento, Análise de riscos, Engenharia e Avaliação do cliente
    Modelo Espiral de Pressman: Comunicação, Planejamento, Análise de riscos, Engenharia, Construção e release e Avaliação do cliente 

    Modelo Espiral do Sommerville: 

    1) Determinação de objetivos, alternativas e restrições;

    2) Avaliação de alternativas, identificação e solução de riscos;

    3) Desenvolvimento, verificação e produto no próximo nível;

    4) Planejamento da próxima fase;

ID
140890
Banca
CESPE / CEBRASPE
Órgão
ANTAQ
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

A respeito da engenharia de software, julgue os itens de 101 a 109.

O extreme programming (XP) constitui método ágil de desenvolvimento de software. Uma das práticas que se enquadram nos princípios dos métodos ágeis é a programação em pares, que promove o compartilhamento da autoria do código do sistema. Além dessa vantagem, a programação em pares atua como processo informal de revisão porque cada linha de código é vista por pelo menos duas pessoas.

Alternativas
Comentários
  • Nao concordo com o gabarito. Programação em pares é príncipio do XP, não de metodologias ágeis. Alguém pode justificar o gabarito?

    Os princípios do desenvolvimento ágil valorizam:

    • Garantir a satisfação do consumidor entregando rapidamente e continuamente softwares funcionais;
    • Softwares funcionais são entregues frequentemente (semanas, ao invés de meses);
    • Softwares funcionais são a principal medida de progresso do projecto;
    • Até mesmo mudanças tardias de escopo no projecto são bem-vindas.
    • Cooperação constante entre pessoas que entendem do 'negócio' e desenvolvedores;
    • Projetos surgem através de indivíduos motivados, entre os quais existe relação de confiança.
    • Design do software deve prezar pela excelência técnica;
    • Simplicidade;
    • Rápida adaptação às mudanças;
    • Indivíduos e interações mais do que processos e ferramentas;
    • Software funcional mais do que documentação extensa;
    • Colaboração com clientes mais do que negociação de contratos;
    • Responder a mudanças mais do que seguir um plano.

  • Tem vários princípios Ágeis espalhados por aí hehehe Os mais cobrados são os 12 princípios da Agile Alliance (que consta no livro do Pressman), os 5 da Wikipédia e os 5 Princípios do Sommerville.

    Os 12 princípios da Agile Alliance estão aqui -> http://www.agilealliance.org/the-alliance/the-agile-manifesto/the-twelve-principles-of-agile-software/

    Os 5 princípios da Wikipédia são: Feedback rápido, Presumir simplicidade, Mudanças incrementais, Abraçar mudanças e Trabalho de alta qualidade.

    Os 5 princípios do Sommerville são:  Envolvimento do Cliente, Entrega Incremental, "Pessoas, não processo", Aceite as mudanças e Mantenha a Simplicidade.

    A maioria desses princípios é autoexplicativa, com exceção de um:

    Pessoas, não processo: As habilidades da equipe devem ser reconhecidas e exploradas. Os membros da equipe devem desenvolver suas próprias maneiras de trabalhar sem processos prescritivos.

    Sommerville afirma ainda que a Extreme programming envolve um número de práticas que refletem cada um desses princípios dos métodos ágeis:

    1. Desenvolvimento Incremental é apoiado por pequenos e frequentes releases do sistema e por uma abordagem de descrição de requisitos baseadas nas histórias ou cenários do cliente e podem ser a vase para o planejamento do processo.

    2. O Envolvimento do cliente é apoiado pelo engajamento em tempo integral deste na equipe de desenvolvimento. O representante do cliente faz parte do desenvolvimento e é responsável pela definição de testes de aceitação do sistema.

    3. As pessoas, não o processo, são apoiadas ao dividirem a programação com seus pares, partilhando a propriedade do código do sistema e um processo sustentável que não envolva excessivas horas de trabalho.

    4. As mudanças são apoiadas por meio de releases regulares de sistema, desenvolvimento test-first e integração contínua.

    5. A manutenção da simplicidade é apoiada pelo refactoring constante para aprimorar a qualidade do código e o uso de projetos simples que não antecipam mudanças futuras no sistema.

    (Fonte: Livro Engenharia de Software, 8ed, Sommerville, pag 264)

    Logo, não há nada de errado em associar uma prática do XP a um princípio ágil. Questão Correta.

  • Errei, pois quem promove o compartilhamento do código é a prática de "Propriedade Coletiva", não a "Programação em Pares". Mas que seja, ainda assim a questão está correta.

  • Concordo com o José Roberto. Para mim o gabarito está errado, pois programação em pares é um princípio do XP e não das metodologias ágeis em geral.

ID
142231
Banca
CESGRANRIO
Órgão
BNDES
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Determinado projeto de software utiliza XP (eXtreme Programming) como metodologia de desenvolvimento. A esse respeito, é INCORRETO afirmar que

Alternativas
Comentários

  • A programação em pares NÃO dispensa o desenvolvimento orientado a testes no projeto

  • Continuous Integration - Os diversos módulos do software são integrados diversas vezes por dia e todos os testes unitários são executados. O código não passa até obter sucesso em 100% dos testes unitários.

    Sendo assim, a programação em pares não tem porque dispensar o desenvolvimento orientado a testes no projeto, muito pelo contrário a programação em pares ajuda nos testes pois o código a qualquer momento está na forma mais simples para que passe em todos os testes (simple design).

  • Achava que "os integrantes da equipe se reúnem rapidamente no início do dia, de preferência em pé." era apenas característica do SCRUM, mas 
    concordo que a letra D tá mt errada. 
  • XP, RUP e SCRUM utilizam TDD.
  • A prática da programação em par permite que o código seja revisado permanentemente enquanto é construído. A programação em par é um mecanismo de validação do que está sendo construído. Por esse motivo não existe uma fase específica de teste, e acredito que tenha sido esse o foco do avaliador.
ID
144607
Banca
CESPE / CEBRASPE
Órgão
SECONT-ES
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

De acordo com os conceitos relacionados a processos de
desenvolvimento de software e medição de software, julgue os
próximos itens.

Métodos ágeis de desenvolvimento de sistemas foram propostos principalmente para apoiar o desenvolvimento de aplicações de negócios nas quais os requisitos de sistema mudam rapidamente durante o processo de desenvolvimento. Entre esses métodos está o extreme programming, que envolve um número de práticas, como o planejamento incremental, a definição de um ritmo de trabalho sustentável e a divisão das equipes de trabalho por meio da especialização de seus membros.

Alternativas
Comentários
  • Os Métodos Ágeis de desenvolvimento de software têm como objetivo primordial o desenvolvimento de código-fonte de qualidade que atenda às necessidades do cliente. Este objetivo é alcançando através da construção de um ambiente participativo onde a colaboração frequente entre todos os envolvidos é incentivada e praticada diariamente e onde a qualidade do software é buscada diariamente em cada pequena atividade.

  •  Métodos ágeis de desenvolvimento de sistemas foram propostos principalmente para apoiar o desenvolvimento de aplicações de negócios nas quais os requisitos de sistema mudam rapidamente durante o processo de desenvolvimento.
    Correto. O processo de desenvolvimento incremental permite que o projeto se adeque as mudanças nos requisitos.

    Entre esses métodos está o extreme programming, que envolve um número de práticas,
    como o planejamento incremental, OK
    a definição de um ritmo de trabalho sustentável OK
    e a divisão das equipes de trabalho por meio da especialização de seus membros.
    Incorreto: não há menção no XP sobre essa divisão da equipe nem a especialização de membros. O que o XP prega é uma equipe coesa e multidisciplinar.

  • Acertei essa questão porque me lembrei que as equipes no XP são pequenas e que por isso não há espaço para especializações.
  •  A XP defende a não especialização dos membros do time (todos participam de todas as atividades, em pares e com sistema de rodízio dos pares), o desenvolvimento de infra-estruturas e frameworks durante o desenvolvimento da aplicação, e a comunicação face a face ou por meio de testes eficientes e código cuidadosamente escrito.

  • equipes multidisciplinares

  • O que o XP prega é uma equipe coesa e multidisciplinar, além disso as equipes no XP são pequenas e que portanto não há espaço para especializações.

ID
144823
Banca
CESPE / CEBRASPE
Órgão
INMETRO
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Acerca das relações estabelecidas entre os modelos de ciclo de
vida de software, os modelos de gestão e seus exemplos, julgue
os itens de 62 a 71.

São práticas ou princípios recomendados no modelo de desenvolvimento de software XP (eXtreme Programming) proposto por Kent Beck: programação em pares; semana de trabalho de 40 horas; refatoração sem piedade; desenvolvimento orientado a testes TDD (Test Driven Development); e desenvolvimento de metáforas arquiteturais.

Alternativas
Comentários
  • Acho que refatoração sem piedade, quis dizer que deve-se refatorar(otimizar) o máximo que puder, sem alterar as funcionalidades já existentes, e não deixar nada que possa ser refatorado sem rafatorar.
  • Isso da semana de 40 horas eu não sabia.

    achei no wikipedia falando dos princípios do xp:

    Ritmo Sustentável (Sustainable Pace): Trabalhar com qualidade, buscando ter ritmo de trabalho saudável (40 horas/semana, 8 horas/dia), sem horas extras. Horas extras são permitidas quando trouxerem produtividade para a execução do projeto. Outra prática que se verifica neste processo é a prática de trabalho energizado, onde se busca trabalho motivado sempre. Para isto o ambiente de trabalho e a motivação da equipe devem estar sempre em harmonia.

    interessante...
  • O candidato lê essa questão, conhece tudo sobre o assunto, mas vem a banca e põe a expressão sem piedade no meio. Nesse momento a banca ao invés de exigir do candidato o conhecimento da matéria está exigindo que a gente tenha poderes sobrenaturais de ler a mente do avaliador.
    A interpretação da expressão é ambígua. Na hora da prova eu estaria quebrando a cabeça pra decidir se o avaliador quis dizer refatoração constante ou se ele quis inventar uma modalidade fictícia de refatoração para tornar a questão errada.
    Aí é falta de respeito com quem está se ralando nos estudos como a gente. Quer exigir interpretação por parte do candidato, que o faça, mas dentro dos limites de proporcionalidade e da razoabilidade.
  • Concordo com o que foi dito e vou além: quem garante que essa questão não foi feita para "alguém" acertar? Diante de tamanho disparate a hipótese torna-se provável.
  • Concordo PLENAMENTE com o que foi dito pelo colega Fabiano, até porque, a CESPE é craque em tornar uma questão errada apenas por uma "palavra", tanto que sempre que estou resolvendo uma prova da banca eu leio atentamente a questão, palavra por palavra, porque em muitos casos o examinador apenas "enfia" uma expressão no meio e torna a questão errada. Tive o mesmo sentimento quando cheguei na palavra "sem piedade":

    - E aí, marco certo pois a palavra em questão não contraria a definição do quesito mencionado, ou marco errado por achar que a cespe só "copiou" a definição e colocou uma palavra no meio pra tornar a questão errada (como já fez em diversas questões)?

    Sinceramente, uma falta de respeito com o concurseiro. Questão muito mal elaborada.
  • Pelo que eu vejo, assim como está no livro de Kent Beck o cara tira maior onda. Acho que a CESPE tentou passar esse espírito para a questão, por isso não vejo problema nenhum nesta questão. CORRETÍSSIMA!!!

  • 40 horas semanais é novo para mim

  • No pain no gain kkkk (sem piedade?)

  • Ao meu ber, esse sem piedade é ainda mais crível que as metáforas arquieturais. Quando ele diz: "e desenvolvimento de metáforas arquiteturais." ele restringe o conceito. O "sem piedade" pelo menos não restringe.

  • Alguém explica ou cita a fonte que fala de "Metáforas Arquiteturais"?

  • Aconselho aos nobres colegas a conhecer as regras que norteiam o XP antes de saírem comentando o que não conhecem, pois, não tem nada de errado o próprio nome é da coisa em si é "PROGRAMAÇÃO EXTREMA" e sim Kent orienta o que é bom deve ser levado ao extremo, se refatorar é bom? Então refatore sem pena, se testar é bom ? teste sem dó, e um dos artefatos do XP é o uso de metáforas, muito choro e pouco conhecimento.

    recomendo o curso de metodologias ágeis do Pedrosa no PdTI

  • Gostaria de saber mais sobre Metoforas Arquiteturais...

ID
144838
Banca
CESPE / CEBRASPE
Órgão
INMETRO
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Acerca das relações estabelecidas entre os modelos de ciclo de
vida de software, os modelos de gestão e seus exemplos, julgue
os itens de 62 a 71.

Nas abordagens de desenvolvimento bazaar e catedral e na sua relação com modelos de ciclo de vida de software, observa-se que em um desenvolvimento na abordagem bazaar, a arquitetura é emergente, o que não ocorre com um desenvolvimento na abordagem catedral; o conceito de liberação de código cedo e frequente, presente na abordagem catedral, afina-se com os métodos da eXtreme Programming e em ambos modelos, o desenvolvimento de software é colaborativo, aberto e embasado em prototipação.

Alternativas
Comentários
  • A questão se entrega nesse ponto:"o conceito de liberação de código cedo e frequente, presente na abordagem CATEDRAL"O correto seria:"o conceito de liberação de código cedo e frequente, presente na abordagem BAZAR"

  •  Apenas complementando...

    Não existe uma formalização acadêmica sobre os modelos bazar e catedral. Esta foi apenas uma metáfora abordada por Eric S. Raymond (http://www.dominiopublico.gov.br/download/texto/tl000001.pdf) em um artigo que ele escreveu analisando a estratégia de desenvolvimento de Linus Torvalds. Um dos focos importantes é que o modelo catedral é o modelo tradicional, robusto de desenvolvimento de softwares, no qual entregas de valor são realizadas após longas iterações de desenvolvimento. Neste modelo, erros são complexos e profundos e são descobertos como uma surpresa infeliz pelo usuário, trazendo insatisfação pela inviabilização do uso do sistema. O modelo bazar enfatiza o conceito "Libere cedo, libere freqüentemente", por meio do qual os erros se tornam triviais e de fácil manutenção, pelo fato de vários "testadores" estarem analisando o software em curtos períodos de tempo. Este modelo também se baseia no efeito Delphi, no qual sociologistas descobriram que a opinião média de uma massa de observadores especialistas (ou igualmente ignorantes) é um indicador mais seguro que o de um único observador escolhido aleatoriamente.  

     

  •  Ainda há alguns conceitos importante sobre o modelo bazar:

     

    • Tratar seus usuários como co-desenvolvedores é seu caminho mais fácil para uma melhora do código e depuração eficaz. 
    • Dada uma base grande o suficiente de beta-testers e co-desenvolvedores, praticamente todo problema será caracterizado rapidamente e a solução será óbvia para alguém. (lei de Linus)
    • Estrutura de dados inteligentes e código burro trabalham muito melhor que ao contrário. Brooks, Capítulo 11: "Mostre-me seu código e esconda suas estruturas de dados, e eu poderei continuar mistificado. Mostre-me suas estruturas de dados, e eu provavelmente não necessitarei do seu código; ele será óbvio.''
    • Se você tratar seus beta testers como seu recurso mais valioso, eles irão responder tornando-se seu mais valioso recurso. 
  • é correto afirmar que XP é embasado em prototipação?

  • Entendo que não seja correto dizer que o desenvolvimento de software XP é embasado em prototipação.

    Se fosse "metáfora" no lugar de "prototipação" tudo bem. Mas prototipação é diferente.

ID
149971
Banca
CESPE / CEBRASPE
Órgão
ANAC
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

A respeito dos conceitos relacionados ao desenvolvimento de
sistemas e às metodologias de desenvolvimento de sistemas,
julgue os itens seguintes.

Para o método ágil de desenvolvimento conhecido como extreme programming, todos os requisitos funcionais são expressos como cenários (histórias do usuário) que são implementados diretamente como uma série de tarefas.

Alternativas
Comentários
  • Uma das características importantes do XP é que não existe um processo de design tradicional com a elaboração de modelos da arquitetura do software. O sistema é concebido a partir de uma metáfora e são descritos em estórias do usuário. Uma metáfora é a transposição de uma conceitualização do mundo real para o sistema a ser desenvolvido. Por exemplo, os programas de correio eletrônico foram construídos utilizando os conceitos de mensagem, caixa de entrada e caixa de saída. Cada mensagem possui remetente, destinatário, assunto e cópias carbono (cc). Este modelo conceitual reflete a forma como correspondências são enviadas nos escritórios e pelo sistema de correio dos Estados Unidos. A metáfora passa a ser fundamental para a elaboração das estórias de usuários.Fonte: http://engenhariadesoftware.blogspot.com/2007/03/programao-extrema-xp.html
  • [1]:
    "...os requisitos de usuário na XP são expressos com ocenários ou histórias, e o usuário prioriza esses requisitos para o desenvolvimento. A equipe de desenvolvimento avalia cada cenário e o divide em tarefas. Cada tarefa representa uma característica discreta do sistema e um teste unitário pode então ser projetado para essa tarefa."
    [1]; Sommerville, Engenharia de Software, 8ª Edição, página 266
ID
149974
Banca
CESPE / CEBRASPE
Órgão
ANAC
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

A respeito dos conceitos relacionados ao desenvolvimento de
sistemas e às metodologias de desenvolvimento de sistemas,
julgue os itens seguintes.

A técnica conhecida como refactoring é constantemente aplicada no desenvolvimento baseado no método ágil extreme programming.

Alternativas
Comentários
  • Refatoração (Refactoring): É um processo que permite a melhoria continua da programação, com o mínimo de introdução de erros e mantendo a compatibilidade com o código já existente. Refabricar melhora a clareza (leitura) do código, divide-o em módulos mais coesos e de maior reaproveitamento, evitando a duplicação de código-fonte; Fonte: http://pt.wikipedia.org/wiki/Programa%C3%A7%C3%A3o_extrema

  • Segundo Pressman, em seu livro Engenharia de Software, o XP encoraja a refabricação (refactoring). Um projeto em XP deve manter a simplicidade. Ele (o projeto) é visto como um artefato provisório que pode e deve ser continuamente modificado à medida que a construção prossegue.

    A intenção do refactoring é controlar essas modificações sugerindo pequenas alterações de projeto que "podem aperfeiçoar radicalmente o projeto".

  • Otimização constante.

  • Refatoração: constante melhoramento, faz parte do extreme programming

ID
149977
Banca
CESPE / CEBRASPE
Órgão
ANAC
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

A respeito dos conceitos relacionados ao desenvolvimento de
sistemas e às metodologias de desenvolvimento de sistemas,
julgue os itens seguintes.

No modelo extreme programming, os testes de software só são realizados na etapa, final de desenvolvimento do software e, somente nessa etapa, os programadores trabalham, obrigatoriamente, em pares, utilizando cada um o próprio computador.

Alternativas
Comentários
  • Programação em Pares (Pair Programming): é a programação em par/dupla num ÚNICO computador. Geralmente a dupla é formada por um iniciante na linguagem e outra pessoa funcionando como um instrutor. Desenvolvimento Orientado a Testes (Test Driven Development): Primeiro crie os testes unitários (unit tests) e depois crie o código para que os testes funcionem.

    Fonte: http://pt.wikipedia.org/wiki/Programa%C3%A7%C3%A3o_extrema
  • Se testar é bom, vamos testar toda hora. Levar ao extremo.

  • Extreme Programming inclui uma abordagem de testes que reduz as chances de erros desconhecidos na versão atual do sistema. O desenvolvimento test-first é uma das mais importantes inovações no XP. Em vez de escrever algum código e, em seguida, escrever testes para esse código, você escreve os testes antes de escrever o código. Isso significa que você pode executar o teste enquanto o código está sendo escrito e pode encontrar problemas durante o desenvolvimento.

    Fonte: SOMMERVILLE, Engenharia de Software, 9 Ed., pág 47.

  • Dividindo para conquistar:


    No modelo extreme programming, os testes de software só são realizados na etapa final de desenvolvimento do software (Erro 1: os testes são feitos o tempo todo (ao extremo), até mesmo antes da codificação de cada funcionalidade, já que o XP faz uso do TDD) e, somente nessa etapa, os programadores trabalham, obrigatoriamente, em pares, utilizando cada um o próprio computador (Erro 2: Os programadores trabalham sempre em pares, sendo vinculado apenas um computador para cada dupla de desenvolvedores).


    Bons estudos!

ID
152503
Banca
CESPE / CEBRASPE
Órgão
TRE-MG
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Assinale a opção correta acerca das metodologias de desenvolvimento de software.

Alternativas
Comentários
  • A) Errado! O XP não se preocupa tanto com documentação de apoio;
    B) Errado! O RUP não prega a agilidade;
    C) Errado! MSF não é utilizado no UNIX;
    D) Errado! As metodologias foram feitas para melhorar o desempenho, não piorar;
    E) Correto!  O RUP utiliza protótipagem e modularização, o que faz com que exista modelos executáveis até mesmo para o levantamento de requisitos (protótipos).

  • o XP(extreme progamming) O método Programação eXtrema (XP, do inglês eXtreming Programming) é uma proposta de desenvolvimento ágil e iterativa. O método XP propõe um processo leve, centrado no desenvolvimento iterativo e com a entrega constante de pequenas partes da funcionalidade do software.

    o uso de uma   ou mais....letra d) se eu não uso metodologias eu vou contra as boas práticas de desenvolvimento de software na atualidade, ficaria artesanal o desenvolvimento, agora não podemos usar várias ao mesmo tempo, misturar metodologias pode não ser muito prático.

  • Gostaria de saber em qual literatura a banca se fundamentou para justificar a letra "d" como falsa. Parece ir contra o bom senso dizer que é benéfico ao projeto a utilização de múltiplas metodologias de desenvolvimento. Quem souber de onde a banca tirou essa "pérola". Por favor, me diga?
  • Márcio, acho que o maior problema da letra D está em dizer que o uso de UMA ou mais metodologias de desenvolvimento é prejudicial. O uso de UMA metodologia certamente NÃO é prejudicial.
    Mais que uma, só se fosse SCRUM + XP, algo assim....
  • Marcio, ha duas afirmacoes:
    O uso de uma metodologia de desenvolvimento é prejudicial ao bom desempenho do projeto. ERRADO.
    O uso de mais de uma metodologia de desenvolvimento é prejudicial ao bom desempenho do projeto.  CERTO
    Um item errado torna a questa errada.
    Questao de ler com calma.

  • Ao contrário se uma ou mais prejudica então uma apenas prejudica.

     

    Será que tinha MSF no edital? Qual a base do CESPE para considerá-la errada? Na prática é difícil ver MSF em ambiente UNIX mas é impossível? E se por exemplo considerarmos tecnologias como Xamarin para Android e iOS ambos baseados em Unix(Linux e XNU/BSD)

     

    Microsoft Solutions Framework (MSF) is a set of principles, models, disciplines, concepts, and guidelines for delivering information technology solutions from Microsoft. MSF is not limited to developing applications only, it is also applicable to other IT projects like deployment, networking or infrastructure projects. MSF does not force the developer to use a specific methodology (Waterfall, Agile) but lets them decide what methodology to use.

     

  • Embora o RUP não seja um processo adequado a todos os tipos de desenvolvimento de software, ele representa uma nova geração de processos genéricos. A mais importante inovação é a separação de fases e workflows, e o reconhecimento de que a implantação de software no ambiente do usuário é parte do processo. As fases são dinâmicas e tem objetivos. Os workflows são estáticos e constituem atividades técnicas que não estão associadas a uma única fase, mas podem ser utilizados ao longo do desenvolvimento para atingir os objetivos de cada fase 

ID
162205
Banca
FCC
Órgão
TCE-AL
Ano
2008
Provas
Disciplina
Engenharia de Software
Assuntos

Originalmente, o único produto da atividade de Projeto que é realizado como parte do processo XP (Extreme Programming)

Alternativas
Comentários
  • O uso de cartões CRC (Classes, Responsabilidades e Colaborações) é recomendado de forma a permitir o design em equipe. Cartões CRC permitem a descrição dos conceitos identificados na metáfora na forma de classes. Responsabilidades são identificadas para cada classe. As colaborações determinam as interações entre classes. Os cartões permitem que o todo o time possa colaborar com o design.

    Retirado de: http://engenhariadesoftware.blogspot.com/2007/03/programao-extrema-xp.html
  • Como o projeto XP praticamente não usa nenhuma notação e produz poucos, ou nenhum produto de trabalho que não sejam os cartões CRC e as soluções de ponta, o projeto é visto como um artefato provisório que pode e deve ser continuamente modificado à medida que a construção prossegue.

    Pressman, págin 65

  • Atividades metodológicas do XP:

    - Planejamento: critérios de teste de aceitação, priorização das estórias de usuário, plano de iteração

    - Projeto: cartões CRC, soluções pontuais, protótipos

    - Codificação: refatoração, programação em dupla, testes de unidade, integração contínua

    - Teste: teste de unidades, integração contínua, testes de aceitação

ID
163672
Banca
CESGRANRIO
Órgão
Petrobras
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Em metodologias de desenvolvimento de software, tem-se que

Alternativas
Comentários
  • a) as 6 4 fases da Unified Process (UP) são: Concepção, Elaboração, Construção e Transição. Projeto Lógico, Codificação, Projeto Físico, Testes e Manutenção.

    b) a Extreme Programming (XP) é uma metodologia complexa, complementar ao Unified Process (UP), concebida para sistemas de alto desempenho que exigem trabalho extremo de definição de requisitos muito bem definidos e isolados de mudanças.

    c) a Rational Unified Process (RUP) procura dar um enfoque menor à documentação, valorizando mais a comunicação oral; já a Extreme Programming (XP)  utiliza todos os artefatos da UML2.0 para usar como componente de entrada e saída. --> conceitos trocados
  • a) as 6 4 fases da Unified Process (UP) são: Concepção, Elaboração, Construção e Transição. Projeto Lógico, Codificação, Projeto Físico, Testes e Manutenção.

    b) a Extreme Programming (XP) é uma metodologia complexa, complementar ao Unified Process (UP), concebida para sistemas de alto desempenho que exigem trabalho extremo de definição de requisitos muito bem definidos e isolados de mudanças. 

    c) a Rational Unified Process (RUP) procura dar um enfoque menor à documentação, valorizando mais a comunicação oral; já a Extreme Programming (XP) utiliza todos os artefatos da UML2.0 para usar como componente de entrada e saída.  --> conceitos trocados


    e) a Rational Unified Process (RUP) é usada para desenvolver software de forma sequencial contínua, sem retroalimentação ou repetições evolutivas, e onde o produto só é verificado e testado no final da última fase.
  • Correção do comentário da Fernanda
    As quatro fases to processo unificado são: Concepção, Elaboração, Construção, Transição
    ou em inglês: Inception, Elaboration, Construction, Transition
  • Brincadeira um cidadão desse que coloca um comentario só com a resposta ... Fala serio..
  • a) as 6 fases da Unified Process (UP) são: Concepção, Projeto Lógico, Codificação, Projeto Físico, Testes e Manutenção. ERRADO. São 4 fases: Concepção(ou Iniciação), Elaboração, Construção e Transissão b) a Extreme Programming (XP) é uma metodologia complexa, complementar ao Unified Process (UP), concebida para sistemas de alto desempenho que exigem trabalho extremo de definição de requisitos muito bem definidos e isolados de mudanças.
    ERRADO. XP não é complementar ao RUP, muito menos concebida para sistemas de alto desempenho .... Um resumo do que é a XP: É um modelo Ágil de desenvolvimento. Sua metodologia adequada a equipes pequenas (até 10 pessoas), parte do princípio de que a melhor documentação é o código fonte. Para a XP, a arquitetura é na verdade desenvolvida ao longo do projeto onde todo o código escrito é constantemente reconstruído para aumentar a simplicidade e objetividade do mesmo.É baseada em práticas, como programação aos pares, semana de 40 horas e reuniões em pé. c) a Rational Unified Process (RUP) procura dar um enfoque menor à documentação, valorizando mais a comunicação oral; já a Extreme Programming (XP) utiliza todos os artefatos da UML2.0 para usar como componente de entrada e saída.
    ERRADO. As descrições estão invertidas.     d) a Rational Unified Process (RUP) possui práticas em engenharia de software e sugestões de uso de ferramentas automatizadas que possibilitam acelerar a implementação do CMMI nível 2 e criar uma base consistente para o CMMI nível 3. CORRETA. O RUP é um processo completo de desenvolvimento de software e por causa disso acelera a implementação do CMMI nível 2. Veja abaixo o que o CMMI nível 2 pede: Nível 2: Gerenciado Planejado e executado de acordo com uma política  Emprega pessoas e outros recursos adequados Produz resultados controlados, com envolvimento de todas as partes interessadas É monitorado, controlado e revisado

    A maioria metas acima são atendidas se o processo de desenvolvimento é o RUP. Também se você alcança o CMMI 2 você já está com uma base consistente para trabalhar o nível 3.
      e) a Rational Unified Process (RUP) é usada para desenvolver software de forma sequencial contínua, sem retroalimentação ou repetições evolutivas, e onde o produto só é verificado e testado no final da última fase. ERRADO. O RUP é justamente o contrário de tudo acima, é um processo de software Iterativo e incremental onde o produto é verificado e testado em todas as fases
ID
163969
Banca
FCC
Órgão
TJ-PI
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

XP (eXtreme Programming) é uma metodologia ágil para equipes pequenas e médias que desenvolverão software com requisitos vagos e em constante mudança. Para isso, adota a estratégia de constante acompanhamento e realização de vários pequenos ajustes durante o desenvolvimento de software. Para aplicar os valores e princípios durante o desenvolvimento de software, a XP propõe uma série de práticas, sendo uma delas: sempre que produzir uma nova funcionalidade, nunca esperar uma semana para integrar à versão atual do sistema a fim de evitar o aumento da possibilidade de conflitos e da possibilidade de erros no código fonte. Tal prática é denominada

Alternativas
Comentários
  • Para aplicar os valores e princípios durante o desenvolvimento de software, XP propõe uma série de práticas, sendo uma delas:
     * Integração Contínua (Continuous Integration):
              - Sempre que produzir uma nova funcionalidade, nunca esperar uma semana para integrar à versão atual do sistema.
              - Integrar de forma contínua permite saber o status real da programação.
  • a) Time Coeso. - Mesmo se não for um time reduzido, por seguir padrões de codificação, qualquer membro do time é capaz de entender o que outro codificou.

    b) Refatoração. - O código é melhorado sem alterar o funcionamento externo do módulo. (Retira código redundante, cria funções, reescreve métodos... )

    c) Integração Contínua.  (Todo novo módulo após passar no teste unitário, já é submetido a testes de integração para garantir que não causou erros no restante do sistema)

    d) Desenvolvimento Orientado a Testes.  (Antes de codificar, os testes unitários já são escritos de acordo com os requisitos funcionais. Depois, são escritos os trechos de código de acordo coom estes testes)

    e) Ritmo Sustentável. (Não é pq chama Extreme Programming que a equipe tem que fazer horas extras, virar madrugadas, o XP diz que devem ser no máximo 8 horas de trabalho)

  • Segundo Kent Beck

    Integração Contínua (Continuous Integration): Sempre que produzir uma nova funcionalidade, nunca esperar uma semana para integrar à versão atual do sistema. Isto só aumenta a possibilidade de conflitos e a possibilidade de erros no código fonte. Integrar de forma contínua permite saber o status real da programação.

  • c-

    a integracao continua é um conjunto de praticas q consiste em verificar que a cada modificacao o source code resultante das modificacoes nao produz regressao das aplicacoes ja criadas. o objetivo é identificar problemas de integracao o mais cedo possivel. tb permite automatizar a execucao de suite de testes e ver a evolucao do software

ID
173821
Banca
FGV
Órgão
MEC
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Acerca dos processos XP e Scrum, assinale a afirmativa incorreta.

Alternativas
Comentários

  • fases do RUP: Concepção, Elaboração, Construção e Transição.

    Fases do XP: exploração, planejamento, iterações para release, validação para produção, manutenção e morte.

     

    O SCRUM possui o seguinte grupo de fases [SCHWABER, 1996]:
    Pregame:
     •  Planning: Definição do novo release baseado na lista de atividades
        conhecidas (backlog), juntamente com uma estimativa de tempo e
        custo. Se um novo sistema está sendo desenvolvido, esta fase
        consiste em conceitualização e análise do produto. Se um sistema
        existente está sendo aprimorado, esta fase consiste basicamente em
        análise.
    •  Architecture/Staging: Desenho de como os itens do backlog serão
       implementados. Esta fase inclui modificações na arquitetura do
       sistema bem como atividades de design de alto nível.
    Game:
     •  Development (sprints): Fase de desenvolvimento das funcionalidades
        do novo release, com constante respeito às variáveis de tempo,
        requisitos, qualidade e custo. A interação entre essas variáveis define
       o final dessa fase. Normalmente existem múltiplos sprints, ou
       iterações, que são usados para evoluir incrementalmente o sistema.
    Postgame:
    •  Closure: Preparação para o release, incluindo documentação do
       produto, testes e a realização do release.
     

  • Questão muito fácil, pois as quatro fases da letra a são do RUP, que diferem muito do XP, mas achei a letra d) mal elaborada.

    a) Quem faz essa divisão é o RUP.
    b) Scrum é uma metodologia ágil. Correto!
    c) Os requisitos do projeto são organizados em uma lista de tarefas, chamada de product backlog, em ordem decrescente de prioridade (itens mais importantes no topo). Essa lista deve ser constantemente atualizada e “repriorizada”. O scrum trabalha com desenvolvimento incremental. Correto!
    d) Os requisitos não são vagos, mas podem ser incrementados. Faltou o valor “respeito”. Não são pequenas equipes, mas pares de programação.
    e) Correto! Sem comentários.
  • Henrique, sobre seu comentário a respeito da letra D, eu concordo em parte. Quanto a falta do valor respeito, está correto. Mas quanto a questão das equipes pequenas e médias, eu discordo do que você falou. O XP trabalha com equipes até 10 pessoas, sendo neste caso, 5 máquinas para cada par da equipe. A equipe é formada pelos conjuntos e pares.


    Bons estudos.
  • Pessoal, entendo que a alternativa "c" contém informações erradas também. Para acertar esta questão precisa-se marcar "a mais errada".
    O product backlog contém os requisitos do sistema a ser desenvolvido ordenados por prioridade de valor para o cliente. Não há "tarefas" descritas no product backlog. Até mesmo porque quem é o dono do product backlog é o representante do cliente e ele não define tarefas para a equipe. As tarefas são organizadas no sprint backlog. Vejam o link http://improveit.com.br/scrum/product_backlog

  • No scrum os requisitos do projeto são organizados em uma lista de tarefas (o correto seria funcionalidades), chamada de product backlog, em ordem decrescente de prioridade.

    Product Backlog => Lista de funcionalidades
    Sprint Backlog => Lista de tarefas
    Acho a letra C tão errada quanto a letra A. Esta questão deveria ser anulada.

  • Esqueci que era FCC. em que marcar a mais errada!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Essa banca não é de Deus!!!

  • A banca dessa vez era a FGV hehehe

  • Deveria realmente ser anulada. Scrum não é uma metodologia, é um framework.

  • Que pegadinha!

  • Um projeto XP passa pelas seguintes fases: Exploração, Planejamento Inicial, Iterações do Release, Produção, Manutenção e Morte.

  • O gabarito diz que é A. Mas essa divisão de fases não é no modelo RUP?

ID
183778
Banca
FCC
Órgão
TRE-RS
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

No eXtreme Programming ? XP

Alternativas
Comentários

  • a) Sempre que produzir uma nova funcionalidade, nunca esperar uma semana para integrar à versão atual do sistema. Isto só aumenta a possibilidade de conflitos e a possibilidade de erros no código fonte. Integrar de forma contínua permite saber o status real da programação.

    b) A programação é em par/dupla num único computador.

    c) A equipe de desenvolvimento é formada pelo cliente e pela equipe de desenvolvimento.

    d) Releases é a a liberação de pequenas versões funcionais do projeto. As versões chegam a ser ainda menores que as produzidas por outras metodologias incrementais, como o RUP. Portanto não são complexos. Lembre-se simplicidade é um dos valores do XP.

    e)O código fonte não tem dono e ninguém precisa solicitar permissão para poder modificar o mesmo. O objetivo com isto é fazer a equipe conhecer todas as partes do sistema. CORRETO

  • Não vejo erro na letra C)  as equipes de desenvolvimento estabelecem suas próprias regras, mas uma equipe pode adotar as regras de outra equipe.
  •  a) o código é integrado e testado depois de alguns dias e, no máximo, até o final da semana.
     
        O CODICO É TESTADO ANTES DA CODIFICAÇÃO E A INTEGRAÇÃO PODE SER DIARIA
    • b) a codificação é feita em grupos de programadores (no mínimo 3 integrantes), preferencialmente num único computador.

    FEITA EM PARES

    • c) as equipes de desenvolvimento estabelecem suas próprias regras, mas uma equipe pode adotar as regras de outra equipe.
    • EQUIPES SÃO AUTO-ORGANIZADAS
    • d) releases quando complexos não podem deixar de fora os requisitos de negócio de maior valor para o cliente.
    • RELEAES SIMPLES
    • e) módulos não são propriedade de nenhum desenvolvedor; todo desenvolvedor da equipe tem o direito de checar um módulo e modificá-lo.  
    • OK

  •  e)módulos não são propriedade de nenhum desenvolvedor; todo desenvolvedor da equipe tem o direito de checar um módulo e modificá-lo.

    Em agile, sempre que um incremento é entrgue a um cliente, os testes de aceitação sao os use cases, o que causa feedback. 

  • e) Propriedade Coletiva 

  • Letra E. 

     

    O  Processo XP 

    Emprega uma abordagem orientada a objetos e envolve um conjunto de regras e práticas constantes no contexto de quatro atividades metodológicas: 

    1 – Planejamento 

    Jogo do Planejamento, se inicia com ouvir que conduz a criação de um conjunto de histórias (similar ao caso de uso) pelo próprio cliente. Cada história é colocada em uma ficha (CRC), o cliente atribui um valor e os membros da equipe atribui um custo medido em semanas de desenvolvimento, pode ter até 3 semanas, caso tenha mais a história tem que ser quebrada e reavaliada. Clientes e desenvolvedores decidem como agrupar as histórias para a versão seguinte (incremento). As histórias podem ser ordenadas de 3 formas: 

    Depois da primeira versão (também denominada incremento de software) ser entregue pela equipe XP, é calculada a velocidade do projeto. Conforme o trabalho de desenvolvimento prossegue, o cliente pode acrescentar histórias, alterar ou eliminar outras. 

    2 – Projeto 

    Segue o princípio KIS (keep is simple, ou seja, preserve a simplicidade). Encorada o uso de cartões CRC (classe-responsabilidade-colaborador), CRC é o único artefato. Se uma história estiver traumática para ser construída, é feito um protótipo operacional (solução pontual). Encoraja a refatoração, Fowler diz: "Refabricação é o processo de alteração de um sistema de software de tal forma que não se altere o comportamento externo do código, mas se aprimore a estrutura interna. É uma forma disciplinada de organizar código [e modificar/simplificar o projeto interno] que minimiza as chances de introdução de bugs. Em resumo, ao se refabricar, se está aperfeiçoando o projeto de codificação depois de este ter sido feito." 

    3 – Codificação 

    Etapas: 

    4 – Testes 

    Teste de unidade deve ser automatizado encorajando uma estratégia de teste de regressão (utiliza a prática/método TDD). Testes de unidades individuais são organizados em um "conjunto de testes universal". Teste de aceitação ou teste de cliente, é especificado pelo próprio cliente obtidos de histórias de usuários 

     

     

     

    Fonte:  

    Livro: Engenharia de SOFTWARE 

    Autor: Roger S. Pressman 

    Editora: AMGH Editora LTDA 

    Edição: 7ª - 2011 

    Capítulo: 3 

ID
183781
Banca
FCC
Órgão
TRE-RS
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Prática que deve ser utilizada com intensidade durante um projeto de XP para facilitar a comunicação e fixação dos assuntos entre as partes, uma vez que, ao criar comparações e analogias com o assunto em questão as pessoas passarão a entender de uma forma muito mais rápida e possivelmente não terão dificuldade de memorização. Ela está fortemente associada a outra boa prática, que para ser exercida exige bem estar e boa condição física do desenvolvedor. Tais práticas são, respectivamente:

Alternativas
Comentários

  • São práticas ágeis que se aderem as características posta na questão:

    1. Metáfora: o time se comunica sobre o software em termos de uma metáfora, caso consiga encontrar uma boa.

    2. Semana de 40 horas (ritmo sustentável): trabalhar por longos períodos é contraproducente.

    Bons estudos!


  • São práticas do XP:


    - Padrões de desenvolvimento;


    - Design simples;


    - Cliente sempre disponível ou presente;


    - Jogo de planejamento;


    - Stand up meeting;


    - Programação em pares;


    - Refactoring;


    - Desenvolvimento guiado por testes;


    - Código coletivo;


    - Metáfora;


    - Ritmo sustentável;


    - Integração contínua;


    - Releases curtos;



    Metodologias Ágeis - Engenharia de Software sob Medida (Sbrocco & Macedo, 1ª Edição, 2012)

ID
189238
Banca
CESGRANRIO
Órgão
ELETROBRAS
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

No âmbito de desenvolvimento de sistemas, o XP tem como característica a programação em par, na qual o(a)

Alternativas
Comentários
  • A idéia de programação em pares é a de que, tendo dois programadores em uma mesma estação de trabalho, enquanto um programa, o outro verifica o que esta sendo feito, sendo que ambos revezam. A intenção é a de que um possa identificar falhas do outro, reduzindo assim os erros.
  • "A pessoa que está conduzindo o teclado (condutor) tem um campo de observação diferente do seu parceiro. Quem digita normalmente está olhando sobretudo para a linha que está editando e adjacências. O navegador, por sua vez, tem uma visão mais ampla e olha não apenas a linha que está sendo editada, mas também o restante do código que aparece na tela."

    Fonte: http://improveit.com.br/xp/praticas/programacao_par
  • Alternativa C
  • esse Kayto fica postando as respostas e acha que tá abafando. Baseado nos 2 primeiros comentários, qualquer um com 2 neurônios conseguiria deduzir a resposta.
  • Segundo SOMMERVILLE,
    Programação em pares: Os desenvolvedores trabalham em pares, verificando o trabalho dos outros e prestando apoio para um bom trabalho sempre.

    Segundo Artigo DevMedia: 

    Programação em pares: Trata-se de duas pessoas trabalhando com uma máquina em que um codifica, e o outro critica ou dá susgetões. Os pares trocam de lugar periodicamente. Essa prática é excelente e favorece comunicação e aprendizado.

ID
192862
Banca
FCC
Órgão
MPE-RN
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Refactoring, programação em pares e Stand-up Meeting são características das práticas do

Alternativas
Comentários

  • Jogo de Planejamento (Planning Game):
    Pequenas Versões (Small Releases):
    Metáfora (Metaphor):
    Projeto Simples
    Time Coeso (Whole Team):
    Testes de Aceitação (Customer Tests):
    Ritmo Sustentável (Sustainable Pace):
    Reuniões em pé (Stand-up Meeting):
    Posse Coletiva (Collective Ownership):
    Programação em Pares (Pair Programming):
    Padrões de Codificação (Coding Standards):
    Desenvolvimento Orientado a Testes (Test Driven Development):
    Refatoração (Refactoring):
    Integração Contínua
     

  • Me surgiu uma dúvida. O SCRUM também não possui essas características não?
  • O Scrum não tem programação em pares.
  • c) Extreme programming.

  • "O Scrum não tem programação em pares."

    Na teoria não tem, mas na prática o SCRUM pode adotar as boas práticas do XP e utilizar a técnica de programação em pares.

  • Refactoring é um conceito praticamente criado pelo XP

  •  c)Extreme programming.

    o que define XP: 4 valores- comunicação, simplicidade, respeito, coragem, feedback-, programação a 2, stand-up meeting, criação de testes antes de programação

  • Que explicação! Eu também cheguei a essa conclusão antes de vir aos comentários

ID
195310
Banca
CESPE / CEBRASPE
Órgão
TCU
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Julgue os itens a seguir, relativos a modelos ágeis de processo.

O processo XP (extreme programming) envolve a realização das atividades de planejamento, de projeto, de codificação e de teste.

Alternativas
Comentários

  • o XP usa a abordagem orientada a objeto com oparadigma de desenvolvimento predileto. Inclui um conjunto de regras e práticas que ocorrem no contexto de 4 atividades:

    1. Planejamento

    2. Projeto

    3. Codificação

    4. Teste

  • 4 atividades básicas do desenvolvimento: Programar, testar, ouvir, projetar (Kent Beck)

    4 atividades de arcabouço:Planejamento,  projeto, codificação e teste (Pressman)

    Questão correta , seguindo a definição dada por Pressman.

ID
195313
Banca
CESPE / CEBRASPE
Órgão
TCU
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Julgue os itens a seguir, relativos a modelos ágeis de processo.

A atividade de planejamento XP inclui a criação das denominadas histórias de usuário, nas quais devem ser descritas as características e as funcionalidades requeridas para o software em desenvolvimento.

Alternativas
Comentários

  • A atividade de planejamento começa com a criação de um conjunto de histórias ( também chamadas de história dos usuários) que descrevem as caracteristicas e as funcionalidade requerida para o software  a ser construído. Cada história é escrita pelo cliente e é colocada em um cartão de indexação. O cliente atribui uma valor ( prioridade) para a história com base  no valor do negeócio global da caracterisitca ou da função. Membros da equipe XP avaliam cada história e lhe atribui um custo - medido em semanas de desenvolvimento.

ID
195316
Banca
CESPE / CEBRASPE
Órgão
TCU
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Julgue os itens a seguir, relativos a modelos ágeis de processo.

A atividade de projeto é uma desvantagem do processo XP, pelo fato de requerer uma quantidade de produtos de trabalho considerada excessiva pela comunidade de desenvolvimento de software.

Alternativas
Comentários

  • o XP segue rigorosamente o principio KIS ( Keep it  simple - mantenha a simplicidade).

     O XP encoraja o uso de cartões CRC ( class-Responsibility-Colaborator) que identifica e organizam as classes orientadas a objetos., que são relevantes para o incremento do software atual. OS  cartões CRC são o único produto de trabalho do projeto que é realizado como parte do projeto XP.

    pressamn, 6º edição. pág. 64

  • Prática do XP: Projeto simples - O código está, a qualquer momento, na forma mais simples que passe todos os testes.
ID
215665
Banca
CESPE / CEBRASPE
Órgão
MPU
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Julgue o seguinte item a respeito de qualidade de software.

Extreme programming (XP) é embasado em requisitos conhecidos, definidos de antemão, que não sofram muitas alterações, devendo ser usado por equipes de pequeno porte, formadas por representantes de todos os stakeholders.

Alternativas
Comentários

  • Em desenvolvimento ágil, os requisitos não são estáveis e nem são previamente conhecidos

  • Em XP, normalmente os requisitos são definidos no decorrer das entregas das iterações e podem sim sofrer muitas alterações no decorrer do desenvolvimento!

  • A filosofia é abraçar as mudanças!
  • Definição do XP - "Trata-se de uma metodologia ágil para equipes pequenas e médias desenvolvendo software com requisitos vagos e em constante mudança” – Kent Beck

  • parei de ler em "Extreme programming (XP) é embasado em requisitos conhecidos,"

ID
218188
Banca
CESPE / CEBRASPE
Órgão
TRE-BA
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

A respeito das metodologias eXtreme programming (XP) e Scrum,
julgue os itens a seguir.

A metodologia XP prevê valores e princípios básicos para serem considerados durante o desenvolvimento de software. Feedback, coragem e respeito são exemplos de valores; mudanças incrementais, abraçar mudanças e trabalho de qualidade são exemplos de princípios básicos.

Alternativas
Comentários

  • Os valores são 5:

    CorSim ComFeRe

    1. Corajem
    2. Simplicidade
    3. Comunicação
    4. Feedback
    5. Respeito

    Os princípios são 5 também:

    1. Feedback rápido
    2. Abraçar as Mudanças
    3. Presumir Simplicidade
    4. Mudanças Incrementais
    5. Trabalho de Qualidade

  • Resumo de cada VALOR.


    Valores do Extreme Programming

    Focada na agilidade de equipes e na qualidade dos projetos e tem como seus valores a simplicidade, o feedback, a comunicação, a coragem, o respeito.

    Comunicação: Segundo Beck “Os problemas nos projetos invariavelmente recaem sobre alguém não falando com alguém sobre algo importante”. Assim, a comunicação enfatiza que devemos sempre estar se comunicando seja entre desenvolvedores ou com os clientes.

    Simplicidade: é tentar fazer o mais simples possível e caso seja necessário faremos algo mais complexo amanhã. Muitas vezes algo é feito de forma completa e posteriormente não é mais sequer usado ou necessário.

    Feedback: é muito presente no SCRUM através das reuniões diárias, retrospectiva, reuniões de revisão do produto, etc. Feedback é o valor primordial dentro do desenvolvimento ágil.

    Coragem:XP diz que devemos ter coragem de sempre colocar o cliente a par do que está acontecendo.

    Respeito: Respeito é um valor que dá sustentação a todos os demais. Membros de uma equipe só irão se preocupar em comunicar-se melhor, por exemplo, se se importarem uns com os outros. Respeito é o mais básico de todos os valores.

ID
239731
Banca
CESPE / CEBRASPE
Órgão
ABIN
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Julgue os itens a seguir, relativos a métodos de desenvolvimento de
software.

Na extreme programming, os requisitos são expressos como cenários e implementados diretamente como uma série de tarefas. O representante do cliente faz parte do desenvolvimento e é responsável pela definição de testes de aceitação do sistema.

Alternativas
Comentários

  • Programação extrema (do inglês eXtreme Programming), ou simplesmente XP, é uma metodologia ágil para equipes pequenas e médias e que irão desenvolver software com requisitos vagos e em constante mudança.

    Para aplicar os valores e princípios durante o desenvolvimento de software, XP propõe uma série de práticas.

    • Time Coeso (Whole Team): A equipe de desenvolvimento é formada pelo cliente e pela equipe de desenvolvimento.
    • Testes de Aceitação (Customer Tests): São testes construídos pelo cliente e conjunto de analistas e testadores, para aceitar um determinado requisito do sistema.
    • ....

    pt.wikipedia.org/wiki/Programa%C3%A7%C3%A3o_extrema

  • Ao meu ver, essa questão está errada, pois ela afirma "O representante do cliente" e não o próprio cliente, como colocou nosso colega aí de cima. Questão passível de recurso.
  • Na verdade o XP diz claramente que se não for possível que o cliente esteja presente fisicamente no ambiente de desenvolvimento do projeto, ele pode escolher um representante que assuma essa função. Por isso tanto faz dizer "o cliente" diretamente ou "o representante do cliente", pois a função é justamente representar o cliente e seus interesses.

    Infelizmente não estou com a fonte dessa informação aqui, mas eu lembro de ter lido claramente essa parte em um livro escrito pelos próprios criadores do XP.
  • Lembrem-se, uma questão só está errada quando encontramos um erro na questão!
    Infelizmente temos que focar no que quiz dizer o examinador e em que qual o objetivo da questão, e certamente colocando representante ou cliente ele passou a idéia que o time não é composto somente por desenvolvedores!
  • Em relação ao "representante do cliente" segue o que Sommerville tem a dizer:

    "Cliente on-site: Um representante do usuário final do sistema (o cliente) deve estar disponível em tempo integral para apoiar a equipe de XP."

    Fonte: Sommerville, Eng. de Software, 8ª Edição, Página 264.

  • Sommerville:
    Em extreme Programming, os requisitos são expressos como cenários (chamados de estórias do usuário), que são implementados diretamente como uma série de tarefas. Os programadores trabalham em pares e desenvolvem testes para cada tarefa antes de escreverem o código. Quando o novo código é integrado ao sistema, todos os testes devem ser executados  com sucesso. Há um curto intervalo entre os releases do sistema.

    Pressman 7ª Ed.(pg. 88-90):
    Os testes de aceitação da XP, também denominados testes de cliente, são especificados pelo cliente e mantêm o foco nas características e na funcionalidade do sistema total que são visíveis e que podem ser revistas pelo cliente. Os testes de aceitação são obtidos de histórias de usuários implementadas como parte de uma versão de software.

  • Quer dizer que o representante do cliente coloca a mão na massa, no desenvolvimento??

    O Cliente paga pelo software e ele trabalha?

    Eu pago para uma pessoa fazer meu armário e eu corto a madeira e parafuso???

  • Errei por falta de atenção.

    A parte da questão onde cita "O representante do cliente faz parte do desenvolvimento" pode trazer duplo sentido.

    Eu, na primeira leitura, entendi que o representante também desenvolve o sistema (coloca a mão na massa ou desenvolve parte do sistema) e fui marcando errado por causa disso, mas o que a banca quis dizer, é que ele participa do desenvolvimento, não necessariamente desenvolve.

    Cai na armadilha.. rsrs.

  • Prezados,

    Essa questão foi extraída do livro do Sommerville, 8º edição , página 264, vejamos o que o autor fala :

    Na extreme programming, todos os requisitos são expressos como cenários ( chamados histórias do usuário ), que são implementados diretamente como uma série de tarefas. O envolvimento do cliente é apoiado pelo engajamento em tempo integral deste na equipe de desenvolvimento. O representante do cliente faz parte do desenvolvimento e é responsável pela definição de testes de aceitação do sistema. 

    Portanto a questão está correta.

  • Gente, por favor, sejam menos literais nas questões do Cespe.

    Um "representante" do cliente pode ser qualquer um, e não um preposto oficialmente registrado em cartório ou qualquer outra coisa. Um representante do cliente pode ser um estagiário que o gerente colocou lá para ajudar na especificação de uma tabelinha de-para.

    "Fazer parte do desenvolvimento" não significa sentar e programar junto com os programadores. O gerente do projeto também faz parte do desenvolvimento e nem por isso programa, mas ele está lá, ajudando a desenvolver apoiando com o seu conhecimento.

ID
246922
Banca
COVEST-COPSET
Órgão
UFPE
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Na metodologia de desenvolvimento ágil, a prática da programação em par (pair programming, em inglês) sugere que todo e qualquer código produzido no projeto seja sempre implementado por duas pessoas juntas. Como é denominado o papel da pessoa que revê cada linha de código enquanto ela é digitada, verificando erros e pensando sobre o projeto global?

Alternativas
Comentários
  • "A pessoa que está conduzindo o teclado (condutor) tem um campo de observação diferente do seu parceiro. Quem digita normalmente está olhando sobretudo para a linha que está editando e adjacências. O navegador, por sua vez, tem uma visão mais ampla e olha não apenas a linha que está sendo editada, mas também o restante do código que aparece na tela."

    Fonte: http://improveit.com.br/xp/praticas/programacao_par

    Obs: Vale a pena ler esse artigo. Muito bem escrito.
  • Outra fonte: http://en.wikipedia.org/wiki/Pair_programming

    Pair programming is an agile software development technique in which two programmers work together at one workstation. One, the driver, types in code while the other, the observer (or navigator[1]), reviews each line of code as it is typed in. The two programmers switch roles frequently.

    While reviewing, the observer also considers the strategic direction of the work, coming up with ideas for improvements and likely future problems to address. This frees the driver to focus all of his or her attention on the "tactical" aspects of completing the current task, using the observer as a safety net and guide.

  • Para memorizar: é como um Rally

    O piloto dirige (executa) , o navegador informa (verifica o código e aponta erros).

  • Banca sem moral. Retira questão da Wikipédia. Assim, de quê adianta comprar livros de autores renomados???

  • acertei, mas não entendi.

  • Muito boa a explicação !!

  • vlz

  • vlz

  • vlz

  • vlz

ID
252067
Banca
CESPE / CEBRASPE
Órgão
STM
Ano
2011
Provas
Disciplina
Engenharia de Software
Assuntos

Julgue os itens seguintes, a respeito de diferentes abordagens
para o processo de desenvolvimento de software.

O extreme programming (XP), que se inclui entre os métodos ágeis, apresenta, entre outras, as seguintes características: pequenos releases, projeto simples, refactoring, programação em pares e propriedade coletiva.

Alternativas
Comentários
  • Práticas do XP:
    Cliente presente
    Jogo do planejamento
    Stand Up meeting
    Programação em par
    Desenvolvimento guiado pelos testes
    Refactoring
    Código coletivo
    Código padronizado
    Design simples
    Metáfora
    Ritmo sustentável
    Integração contínua
    Releases Curtos

    Fonte: Extreme Programming Vinicius Magalhaes Teles, Pag 23.

  • Certíssimo, todo o texto correto, é a base do XP, são as práticas, a vida do XP.

ID
266812
Banca
CESPE / CEBRASPE
Órgão
PC-ES
Ano
2011
Provas
Disciplina
Engenharia de Software
Assuntos

A respeito de desenvolvimento de sistema, reengenharia e
linguagens de programação, julgue os próximos itens.

O extream programming é um método de desenvolvimento ágil de software, em que o representante do cliente faz parte do desenvolvimento, e os programadores de software desenvolvem testes antes da escrita do código.

Alternativas
Comentários
  • Gabarito preliminar: Certo
    Gabarito definitivo: Anulada
    Justificativa: Onde se lê “extream”, deveria ser lido “ extreme”.Dessa forma, opta-se pela anulação do item.
  • Poderiam ter corrigido aqui no site. Deixar uma mensagem afirmando que o item foi modificado por um erro na redação do original. Assim não se perderia uma questão.

  • Independente do "estream", o representante do cliente faz parte do desenvolvimento?? 

    A questão quis perguntar se o cliente coloca a mão no código fonte ou apenas participa do "desenvolvimento" como nas 'user stories' e na priorização das funcionalidades/requisitos ???


    Ficou mal elaborada, concorda?

  • acredito que não seja isso, como os colegas abaixo explicaram. O sujeito do verbo existir é o pronome relativo antes dele, que retoma uma uma ideia do período anterior: o poder não existe ... o que (há/existe)

    -suj

  • acredito que não seja isso, como os colegas abaixo explicaram. O sujeito do verbo existir é o pronome relativo antes dele, que retoma uma uma ideia do período anterior: o poder não existe ... o que (há/existe)

    -suj

ID
267811
Banca
CESPE / CEBRASPE
Órgão
TRE-ES
Ano
2011
Provas
Disciplina
Engenharia de Software
Assuntos

A respeito de engenharia de software, julgue os itens subsequentes.

A metodologia Rational Unified Process (RUP) promove o envolvimento do cliente, bem como iterações e testes contínuos, o que torna o processo dependente de outros, apesar de reduzir os seus riscos. Já a metodologia Extreme Programming (XP) proporciona flexibilidade e agilidade, visto que, por meio dela, realiza-se a divisão de tarefas de forma específica.

Alternativas
Comentários
  • Questão errada por dizer que a metodologia XP realiza a divisão de tarefas de forma específica, pois isso ocorre com o RUP e não com a XP.
    Na XP a divisão de papéis tem um caráter de “uso-geral”, sem atribuições específicas dentro das atividades.

    Fonte: 
  • Amigos, O RUP em sua versão 7 proporciona flexibilidade e agilidade também pois suas disciplinas podem ser adaptadas à realiadado do negócio, podendo até remover algumas disciplinas. Existem também o RuP For Small Project para pequenos projetos o que o torna mais ágil e menos burocrático. Por esses fatores considerei errada a resposta.
  • Conceitos trocados:
    A metodologia Rational Unified Process (RUP) proporciona flexibilidade e agilidade, visto que, por meio dela, realiza-se a divisão de tarefas de forma específica.
    A metodologia Extreme Programming (XP) promove o envolvimento do cliente, bem como iterações e testes contínuos, o que torna o processo dependente de outros, apesar de reduzir os seus riscos.
  • O RUP não proporciona tanta flexibilidade e muito menos agilidade, metodologias ágeis surgiram como alternativas à metodologias como o RUP...

    O comentário do @Yes we can esta certo ao afirmar que o Rup realiza a divisão de tarefas de forma específica e não o XP
  • RUP não é uma metodologia. Parei de ler aí... RUP é um framework. 

  • em equipes XP há a interdisciplinaridade

ID
275089
Banca
COMPERVE
Órgão
UFRN
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Sobre a metodologia de desenvolvimento Extreme Programming (XP), é correto afirmar que

Alternativas
Comentários

  • Alternativa B.

    b) Trata-se do TDD.

  • E porque a alternativa A) está errada?

ID
280198
Banca
IADES
Órgão
CFA
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Assinale a alternativa correta acerca da Programação Extrema (Extreme Programming - XP).

Alternativas
Comentários

  • a) Na programação por pares, os códigos são escritos por dois programadores em cada máquina. Enquanto um dos programadores codifica, o outro é responsável para aspectos como a simplificação do código.
    BANCA DEU CORRETA. Mas não ficou claro que são dois programadores usando a mesma máquina.
    b) A refatoração tem por objetivo reestruturar um software e NÃO modificar as funcionalidades disponibilizadas pelo mesmo. Ao refatorar, um desenvolvedor pode eliminar duplicações e simplificar o projeto.
    c) A estratégia adotada no projeto de software se NAO baseia em contemplar todos os possíveis cenários de evolução empregando-se padrões de projeto. A implementação não inicia até antes de ser concluído todo o projeto.
    d) É recomendável que não se adotem padrões para as práticas de codificação e que não se limite a quantidade de horas trabalhadas por semana. (LIMITADO EM 40 HORAS)
  • Essa questão era passivel de anulação, pois, a programação em pares, os códigos são escritos por dois programadores, mas sempre utilizando a mesma máquina. Portanto a letra A também está errada.
  • Concordo com Emerson Abreu, em Programação em Pares, 2 desenvolvedores usam uma única máquina
  • "...os códigos são escritos por dois programadores em cada máquina."

    O que há de dúbio aí?
  • Olha a INTERPRETAÇÃO aí, pessoal!
    Concordo com o colega Mohamed.
    "Na programação por pares, os códigos são escritos por dois programadores em cada máquina."
    Está mais do que óbvio!
    Bons estudos.

  • "Na programação por pares, os códigos são escritos por dois programadores em cada máquina. "

    Troquem a ordem: Em cada maquina, os codigos sao escritos por dois programadores. Ou, Os codigos sao escritos por dois programadores por maquina. (Em cada maquina da sala, e nao cada um na sua maquina).

  • Pegadinha do MALANDRO.... Affffzzzzzzzzzz....caí bonitinho nessa.

  • Deveria ser ÚNICA máquina.

  • A frase "Na programação por pares, os códigos são escritos por dois programadores em cada máquina." apresenta duplo sentido. Os dois programadores em uma máquina só ou cada um em sua própria máquina ?

     

  • Não existe erro de na A. "Vão duas pessoas em cada carro" é igual a "São escritos por dois programadores em cada máquina ". Acho que foi so confusão na interpretação. 

  •  a)Na programação por pares, os códigos são escritos por dois programadores em cada máquina. Enquanto um dos programadores codifica, o outro é responsável para aspectos como a simplificação do código.correto, com ressalvas- dizer que algo é feito por 2 pessoas em cada maquina pode ser entendido como os 2 estarem em maquinas diferentes

     b)A refatoração tem por objetivo reestruturar um software e modificar as funcionalidades disponibilizadas pelo mesmo. Ao refatorar, um desenvolvedor pode eliminar duplicações e simplificar o projeto. - errado - refatorar significa alterar os requisitos nao-funcionais,e  nao funcionais do sistema. em suma, o software continua o mesmo para o usuario.

     c)A estratégia adotada no projeto de software se baseia em contemplar todos os possíveis cenários de evolução empregando-se padrões de projeto. A implementação não inicia até ser concluído todo o projeto.- errado- acabar uma fase p/ iniciar outra é coisa do waterfall model

     d)É recomendável que não se adotem padrões para as práticas de codificação e que não se limite a quantidade de horas trabalhadas por semana.- errado- se necessitar mais tempo, usam-se mais iterações em xp

  • a) C

    b) E. A refatoração não muda o comportamento, ou seja, as funcionalidades.

    c) E. Ela é gradativa ao longo do projeto. 

    d) E. Deve-se adotar padrões e limitar horas [40h semanais segundo o XP]. 

ID
315652
Banca
FCC
Órgão
TRE-RN
Ano
2011
Provas
Disciplina
Engenharia de Software
Assuntos

Considere as seguintes características:

I. Propriedade coletiva.

II. Integração contínua.

III. Metáfora.

Dentre as práticas componentes da Extreme Programming, aplica-se o que consta em

Alternativas
Comentários
  • Metáforas são usadas frequentemente durante o desenvolvimento de sistemas, na medida em que os desenvolvedores criam elementos dentro do computador para simular outros que existem regularmente fora dele, no mundo físico. A lixeira, a mesa de trabalho, janelas, pastas e outros itens que estamos habituados a encontrar no computador, simulam elementos do mundo físico e seus respectivos comportamentos. XP procura explorar ao máximo a utilização de metáforas, para que clientes e desenvolvedores sejam capazes de estabelecer uma vocabulário apropriado para o projeto, repleto de nomes representando elementos físicos com os quais os clientes estejam habituados em seu dia-a-dia, de modo a elevar a compreensão mútua. 
  • São práticas do XP:

    Posse coletiva (Collective Code Ownership) - E equipe como um todo é responsável por cada arquivo de código. Não é preciso pedir autorização para alterar qualquer arquivo.

    Integração contínua (Continuous Integration) - Os diversos módulos do software são integrados diversas vezes por dia e todos os testes unitários são executados. O código não passa até obter sucesso em 100% dos testes unitários. .

    Metáfora (Metaphor) - O time se comunica sobre o software em termos de uma metáfora, caso consiga encontrar uma boa.

  • Praticas XP

    1.    Metáfora (Metaphor)
    2.Ritmo Sustentável (40 Hour Week)
    3.Padrões de Codificação (Coding Standards)
    4.Propriedade Coletiva (Collective Ownership)
    5.Programação em pares (Pair Programming)
    6.Refatoração (Refactoring)
    7.Projeto Simples (Simple Design)
    8.Integração Contínua (Continuous Integration)
    9.Desenvolvimento Guiado pelos testes (Test First Design)
    10.  Pequenos Lançamentos (Small Releases)
    11.  Jogo do Planejamento (The Planning Game)
    12.  Cliente Presente (On-site customer)
  • Uma das características importantes do XP é que não existe um processo de design tradicional com a elaboração de modelos da arquitetura do software. O sistema é concebido a partir de uma metáfora e são descritos em estórias do usuário. Uma metáfora é a transposição de uma conceitualização do mundo real para o sistema a ser desenvolvido. Por exemplo, os programas de correio eletrônico foram construídos utilizando os conceitos de mensagem, caixa de entrada e caixa de saída. Cada mensagem possui remetente, destinatário, assunto e cópias carbono (cc). Este modelo conceitual reflete a forma como correspondências são enviadas nos escritórios e pelo sistema de correio dos Estados Unidos. A metáfora passa a ser fundamental para a elaboração das estórias de usuários.

    http://engenhariadesoftware.blogspot.com.br/2007/03/programao-extrema-xp.html

  •  

    Práticas do XP:

    Collective Code Ownership (Propriedade Coletiva do Código)
    Todos são responsáveis pelo código, não é necessário autorização para
    alterar qualquer arquivo.

     

    Metaphor (Uso de Metáforas no Projeto)
    Como forma de facilitar a comunicação da equipe, o estabelecimento de
    metáforas em pontos chave do projeto permite uma fácil assimilação.

     

    Continuous Integration (Integração Contínua)
    Os diversos módulos devem ser integrados tão logo sejam
    construídos. O código precisa obter sucesso em uma série de
    fatores pré-definidos

ID
316390
Banca
FCC
Órgão
TRE-RN
Ano
2011
Provas
Disciplina
Engenharia de Software
Assuntos

Assegurar que a equipe se concentre em fazer, primeiro, apenas aquilo que é claramente necessário e evite fazer o que poderia vir a ser necessário, mas ainda não se provou essencial. Este é um dos cinco valores fundamentais do XP (Extreme Programming), denominado

Alternativas
Comentários
  • Simplicidade: a solução adotada deve ser sempre a mais simples que alcance os objetivos esperados.
  • Princípios Básicos do XP:
    1- Feedback rápido;
    2- Presumir simplicidade;
    3- Mudanças incrementais;
    4- Abraçar mudanças;
    5-Trabalho de qualidade;
    grande abraço
    Marcelo



  • 5 Valores

    • Comunicação: evitar o gasto de um valioso esforço na tentativa de trocar informações por meios de extensos documentos escritos que freqüentemente são interpretados de forma incorreta ou incompleta;
    • Simplicidade: : garantir que seja desenvolvido apenas o suficiente para atender as necessidades atuais do cliente, desprezando qualquer funcionalidade não essencial;
    • Feedback: fazer com que o cliente conduza o desenvolvimento diariamente a fim de garantir que a equipe direcione toda a sua atenção para aquilo que de fato irá gerar mais valor;
    • Coragem: devido ao XP ser uma metodologia de software que se baseia em diversas premissas que contrariam os processos tradicionais de desenvolvimento de software, é preciso que todos da equipe tenham coragem para adotá-las e acreditar que, utilizando as práticas e valores do XP, serão capazes de fazer com que o software evolua com segurança e agilidade.
    • Respeito

    5 Princípios Básicos

    • Feedback rápido
    • Presumir simplicidade
    • Mudanças incrementais
    • Abraçar mudanças
    • Trabalho de alta qualidade.

    Práticas

    Para aplicar os valores e princípios durante o desenvolvimento de software, XP propõe uma série de práticas. Há uma confiança muito grande na sinergia entre elas, os pontos fracos de cada uma são superados pelos pontos fortes de outras.

    http://code.google.com/p/extreme-programming-mds/wiki/XP

  • Solução:

    a) Coragem: capacidade de responder às mudanças de requisito e os problemas à medida que surgem, de forma ágil e audaciosa.

    b) Respeito: o projeto só alcança sucesso quando cada membro reconhece e respeita as contribuições de toda a equipe;

    c) Comunicação: diálogo direto e constante entre a equipe de desenvolvedores e clientes;

    d) Simplicidade: o design do software deve ser o mais simples possível;

    e) Feedback: como as entregas são feitas o mais rapidamente possível, o feedback já deve ocorrer desde o início do projeto;

ID
319555
Banca
CESPE / CEBRASPE
Órgão
INMETRO
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Um modelo de processo de software, como os modelos cascata, iterativo e rational unified process (RUP), consiste em uma representação abstrata de um processo de software. Abordagens como extreme programming (XP) e Scrum propõem uma forma mais ágil de desenvolver produtos de software. A esse respeito, assinale a opção correta.

Alternativas
Comentários

  •  a) O RUP é constituído de quatro fases, nas quais as iterações ocorrem: concepção, elaboração, construção e transição. Na primeira, identificam-se todas as entidades externas que irão interagir com o sistema e definem-se essas interações. Na segunda, são elaborados o modelo de requisitos para o sistema, a descrição da arquitetura e o plano de desenvolvimento de software. No final da fase de construção (DURANTE), que se relaciona ao projeto e programação do sistema, este deve estar em funcionamento e a documentação associada pronta. A fase de transição envolve os testes e a transferência do sistema para o ambiente real.

     b) O modelo cascata representa as fases do processo separadas e encadeadas, tais como especificação de requisitos, projeto de software, implementação, teste, entre outras. A fase seguinte não pode começar antes que a fase anterior tenha terminado. O maior problema do modelo cascata é a divisão inflexível do projeto em estágios distintos, as iterações são onerosas e envolvem retrabalho. OK

     c) No modelo em espiral, um exemplo de modelo iterativo, cada loop da espiral representa uma fase do processo de software. Nesse modelo, os riscos não (Grenciado por risco) são considerados, pois podem impactar o projeto.

     d) XP engloba princípios como trabalhar com os clientes, utilizar metáforas, manter reuniões curtas, programar por pares, simplicidade, fazer releases em incrementos pequenos e integração contínua. O teste, uma importante atividade da engenharia de software, não é abordado na XP (É abordando com frequência), o que constitui a sua maior limitação.

     e) Embasado nas melhores práticas aceitas pelo mercado, o Scrum não é um processo ou uma técnica para o desenvolvimento de produtos, mas sim um framework que indica diversos processos e técnicas. Ele emprega uma abordagem iterativa e incremental, e trabalha com os seguinte conceitos: backlog do produto, uma lista priorizada de tudo que pode ser necessário no produto; product owner (única pessoa (PO pode ser um conjunto de pessoas) responsável pelo gerenciamento do backlog do produto); sprint (iteração); e times, cujo tamanho ideal, indicado pela abordagem, está entre 15 a 20 pessoas, de forma a facilitar a gestão.

    Gabarito B

  • a)  Na primeira, identificam-se todas as entidades externas que irão interagir com o sistema e definem-se essas interações e os requisitos.

    b) ok

    c) modelo em espiral -> riscos

    d) XP engloba testes

  • Na primeira fase do RUP, Concepção, são identificados apenas os requisitos mais importantes, delimitando o domínio do sistema. Define-se o escopo do sistema.

    É na fase de Elaboração que se completa todos ou a maior parte dos requisitos.

  • Mais uma questão para o caderno de questões que errei.

  • Na letra A, o trecho "A fase de transição envolve os testes e a transferência do sistema para o ambiente real."

    Os testes no RUP estão presentes em todas as fases e não só na transição.

  • Iterações onerosas? Não existem iterações no modelo em cascata, pois ele é sequencial e linear.

    Questão horrível.

ID
326248
Banca
FUMARC
Órgão
CEMIG-TELECOM
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Sobre modelos de processo de desenvolvimento de software, assinale a alternativa INCORRETA:

Alternativas
Comentários
  • c) Programação extrema (XP – extreme programming) é um processo de desenvolvimento ágil baseado em feedback rápido, e simplicidade; com enfoque explícito em tempo, custo e qualidade no desenvolvimento, que são alcançados através de uma definição rígida do escopo das funcionalidades da aplicação.
  • Extreme Programmning (XP) trabalha com o conceito que os requisitos mudam. Logo não exsite uma definição rígida do escopo, ao contrário ele mudará e o projeto se adaptará as novas exigências.
  • A letra A também está errada pois define SCRUM como um processo de desenvolvimento de software, quando na verdade é um processo para gerenciamento de projetos ágil.
  • Ravi
    os modelos ageis podem ser encaixados em qualquer metodologia de desenvolvimento.
    da uma olhadinha no livro do Pressman =]
  • Apenas complementando o primeiro comentario do colega acima, ja trabalhei com o XP, e a melhor frase que define a flexibilidade do meto e':
    "Mudancas sao sempre bem vindas"
    logo essa ideia ja mata a possibilidade de uma "definicao rigida" como afirma a letra C, tornando a afirmativa falsa e consequentemente a resposta da questao.
    Bons Estudos

  • Concordo que a letra C é a correta.

    Mas alguém explica por que a letra D está certa?

    Análise de riscos e estimativas do progresso do trabalho mais realistas no modelo em cascata?

  • Carla,

    Na letra D a questão cita o modelo espiral e não cascata. Acho que vc confundiu.

  • Talvez a pressuposição equivocada "de uma definição rígida do escopo das funcionalidades da aplicação" faça sentido no ambiente real que tudo muda sempre.

  • c-

    xp (qualquer processo agile) prevê mudanças nos requisitos, o que contradiz rigidez no escopo.

    (nao sabia que sprints no scrum se baseiam no pdca...)

ID
334612
Banca
FCC
Órgão
TRT - 23ª REGIÃO (MT)
Ano
2011
Provas
Disciplina
Engenharia de Software
Assuntos

No desenvolvimento de software em Extreme Programming (XP) há uma confiança muito grande na sinergia entre as práticas, já que os pontos fracos de cada uma são superados pelos pontos fortes de outras. Dentre elas, aquela em que o código fonte não tem dono e ninguém precisa solicitar permissão para poder modificá-lo, permitindo, assim, que a equipe conheça todas as partes do sistema, é chamada de

Alternativas
Comentários
  • Todas as opções são práticas do XP. Mas a que prescreve que o código fonte não tem dono e ninguém precisa solicitar permissão para poder modificá-lo, permitindo, assim, que a equipe conheça todas as partes do sistema, é chamada de:
    Collective Ownership (Posse Coletiva).
  • O QC está bugado! rsrs
    Esse meu comentário com certeza não foi feito nesta questão.
  • Extraído da renomada fonte consagrada e onipresente utilizada pela FCC: wikipedia.

    Time Coeso (Whole Team): A equipe de desenvolvimento é formada pelo cliente e pela equipe de desenvolvimento.

    Ritmo Sustentável (Sustainable Pace): Trabalhar com qualidade, buscando ter ritmo de trabalho saudável (40 horas/semana, 8 horas/dia), sem horas extras. Horas extras são permitidas quando trouxerem produtividade para a execução do projeto. Outra prática que se verifica neste processo é a prática de trabalho energizado, onde se busca trabalho motivado sempre. Para isto o ambiente de trabalho e a motivação da equipe devem estar sempre em harmonia.

    Programação em Pares (Pair Programming): é a programação em par/dupla num único computador. Geralmente a dupla é formada por um iniciante na linguagem e outra pessoa funcionando como um instrutor. Como é apenas um computador, o novato é que fica à frente fazendo a codificação, e o instrutor acompanha ajudando a desenvolver suas habilidades. Desta forma o programa sempre é revisto por duas pessoas, evitando e diminuindo assim a possibilidade de defeitos. Com isto busca-se sempre a evolução da equipe, melhorando a qualidade do código fonte gerado.

    Padrões de Codificação (Coding Standards): A equipe de desenvolvimento precisa estabelecer regras para programar e todos devem seguir estas regras. Desta forma parecerá que todo o código fonte foi editado pela mesma pessoa, mesmo quando a equipe possui 10 ou 100 membros.
  • Só porque a questão está igual a da wiki não necessariamente a FCC copiou de lá. Pode ser que quem publicou na Wiki tirou da mesma fonte que a da FCC.

    Bons estudos e que o Monstro de Espaguete Voador esteja com vós. Rámen!

  • LETRA "D" SEM DÚVIDA. TÁ NO LIVRO DO KENT BECK.

ID
337732
Banca
CS-UFG
Órgão
UFG
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

A abordagem iterativa de desenvolvimento de software tem se popularizado como técnica-padrão de desenvolvimento de sistemas pequenos e médios, especialmente no mundo dos negócios. Scrum e eXtreme Programming são métodos ágeis e iterativos de desenvolvimento de software que compartilham a característica de

Alternativas
Comentários
  • a) desenvolvimento e entrega incrementais de software. (correto)  b) ênfase em processos em vez de pessoas. Ênfase em pessoas e interações MAIS QUE processos e ferramentas (XP)  c) envolvimento restrito do cliente no processo de desenvolvimento. Envolvimento AMPLO e contínuo do cliente. Parceria total com o cliente  d) dificuldade de atender a contínuas mudanças nos requisitos. Métodos apropriados para requisitos e prioridades INSTÁVEIS

  • Manifesto do Desenvolvimento ágil de Software

    Indivíduos e interações são mais importantes que os processos e ferramentas

    Software funcionando é mais importante do que documentação completa e detalhada

    Colaboração com o cliente é mais importante do que negociação de contratos

                   Adaptação de mudanças é mais importante do que seguir o plano inicial


    http://dropsti.blogspot.com/2014/05/modelo-cascata-tambem-chamado-de.html

ID
362887
Banca
CESPE / CEBRASPE
Órgão
TRE-BA
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

A respeito das metodologias eXtreme programming (XP) e Scrum,
julgue os itens a seguir.


Os quatro valores fundamentais da metodologia XP são: comunicação, simplicidade, feedback e coragem.

Alternativas
Comentários
  • Na verdade são cinco valores:
    Comunicação
    Simplicidade
    Feedback
    Coragem
    Respeito [faltou]

    a questão dá margem a um entendimento de que faltou alguma coisa.
    Contudo, os valores ditos FUNDAMENTAIS são apenas os quatro primeiros
  • Faltou recurso aí na Bahia... fala sériow
  • Apenas acrescentado aos comentários acima...
    Na bibliografia utilizada pela banca, respeito não é um valor fundamental ao XP, mas de apoio aos demais valores. Observem as outras questões sobre o assunto e vejam por si mesmos.
  • Galera, uma dica para o XP é não confundir princípios com valores!

    A questão está certa por que cobrou os valores.

    Os cinco valores fundamentais: comunicação, simplicidade, feedback, coragem e respeito.
    Princípios básicos: feedback rápido, presumir simplicidade, mudanças incrementais, abraçar mudanças e trabalho de qualidade.
  • só uma observação. O valor "respeito" foi adicionado na segunda edição do livro "Extreme Programming Explained" do Kent Beck.
    Talvez a questão tenha se baseado na primeira versão do livro.

  •  Os valores do XP: ComFé, CorResSim

    Comunicação

    Feedback

    Coragem

    Respeito

    Simplicidade

    Os princípios do XP são 5 também:

    Feedback rápido

    Abraçar as Mudanças

    Presumir Simplicidade

    Mudanças Incrementais

    Trabalho de Qualidade

  • Sem duplo sentido, faltou respeito respeito nesta questão ¬¬

  • Na minha opinião o respeito também é fundamental! Esta questão deveria ser anulada! o XP possui 5 cinco valores e não 4 quatro!

  • XP possui 5 cinco valores e não 4 quatro!

  • Pessoal, essa questão é de 2010, nessa época só existiam 4 valores.

    Em uma outra edição posterior a data dessa prova que entrou "respeito" como valor fundamental da XP também.

ID
362890
Banca
CESPE / CEBRASPE
Órgão
TRE-BA
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

A respeito das metodologias eXtreme programming (XP) e Scrum,
julgue os itens a seguir.


Em XP, a prática denominada programação em pares (pair programming) é realizada por um desenvolvedor em dois computadores, com o objetivo de aumentar a produtividade.

Alternativas
Comentários
  • Programação em pares ( dois desenvolvedores em um computador )

    Questão Errada
  • Se as questões fossem sempre assim! :)
  • Edluise Costa O erro não está em dois programadores em um computador! É desta forma mesmo que funciona a programação em par! Imagine na aviação um avião ele precisa de um co-piloto! O erro está em com o objetivo de aumentar a produtividade. O objetivo da programação em par não é: Compartilhamento do conhecimento, Correção de falhas, Manutenibilidade, Confiança, Amadurecimento e outros.

  • Fiquei com vergonha alheia de quem fez essa questão...

ID
450007
Banca
FGV
Órgão
MEC
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Acerca dos processos XP e Scrum avalie as afirmativas a seguir:
I. XP é uma metodologia ágil para equipes de tamanho pequeno ou médio desenvolverem software com requisitos vagos ou que mudem rapidamente. Seus valores são comunicação, simplicidade, feedback e coragem.
II. O Scrum foi criado para gerenciamento de projetos de fabricação de automóveis e produtos de consumo. Sua popularização no desenvolvimento de software ocorreu em 1995 após a formalização de sua definição, feita por Ken Schwaber.
III. No XP os requisitos do projeto são organizados em uma lista de tarefas, chamada de product backlog, em ordem decrescente de prioridade.
Assinale:

Alternativas
Comentários
  • O Product Backlog é uma gama de funcionalidades, definidas, no começo do projeto e é organizada por prioridade de entrega pelo Product Owner, com o suporte do scrumMaster. As funcionalidades devem ser incluídas pela lista e devem ser  visíveis ao cliente, assim como os requisitos-não funcionais para a implementação do projeto. As tarefas de maior prioridade e complexidade são divididas em subtarefas para que sejam estimadas e testadas.

    Ao longo do desenvolvimento do projeto, o Product Backlog pode receber novos itens, ter itens removidos ou repriorizados, de acordo com as necessidades do cliente ou visando um melhor ROI. Há a possibilidade, ainda, de inclusão de alguns requisitos técnicos que, muitas vezes, não são visíveis ao cliente.
  • Inicialmente, o Scrum foi concebido como um estilo de gerenciamento de projetos em empresas de fabricação de automóveis e produtos de consumo, por Takeuchi e Nonaka no artigo "The New Product Development Game" (Harvard Business Review, Janeiro-Fevereiro 1986). Eles notaram que projetos usando equipes pequenas e multidisciplinares (cross-functional) produziram os melhores resultados, e associaram estas equipes altamente eficazes à formação Scrum do Rugby (utilizada para reinício do jogo em certos casos). Jeff Sutherland, John Scumniotales e Jeff McKenna conceberam, documentaram e implementaram o Scrum, conforme descrito abaixo, na empresa Easel Corporation em 1993, incorporando os estilos de gerenciamento observados por Takeuchi e Nonaka. Em 1995, Ken Schwaber formalizou a definição de Scrum e ajudou a implantá-lo no desenvolvimento de softwares em todo o mundo.
  • Faltou respeito com um dos valores do XP.
  • product backlog é um termo do SCRUM, não do XP.
  • I - XP é uma metodologia ágil para equipes de tamanho pequeno ou médio desenvolverem software com requisitos vagos ou que mudem rapidamente. Seus valores são comunicação, simplicidade, feedback e coragem. (Correto. O quinto valor Respeito foi introduzido na segunda versão do livro Extremme Programming Explained - Embrace Change do Kent Beck.)
    II - O Scrum foi criado para gerenciamento de projetos de fabricação de automóveis e produtos de consumo. Sua popularização no desenvolvimento de software ocorreu em 1995 após a formalização de sua definição, feita por Ken Schwaber. (Correto)
    III - No XP os requisitos do projeto são organizados em uma lista de tarefas, chamada de product backlog, em ordem decrescente de prioridade. (Errado. No Scrum é que possui essa divisão do product backlog e a prioridade dos requisitos são definidos pelo Product Owner).
  • Apenas complementando o comentário de um colega acima, RESPEITO é um valor introduzido pelo Kent Beck somente na 2a. Edição do livro "Extreme Programming Explained", livro que, em sua primeira edição, apresentou o XP.

    A questão está de acordo com a primeira versão do livro citado, na qual o autor elenca apenas quatro valores, como dito: comunicação, simplicidade, feedback e coragem.
  • Porque eu deveria saber a história do SCRUM?
  • Sabemos que XP tem 5 valores, além dos citados também temos "Respeito"

    Entretanto para analisar na hora de marcar, basta observar.
    "Seus valores são comunicação, simplicidade, feedback e coragem." -> 
    -> -> ->
    "    comunicação, simplicidade, feedback e coragem são seus valores "

    Se a segunda afirmativa parecer mais correto, então a primeira está correta. Pois não foi informado "APENAS", "SOMENTE"
  • Falta de criatividade... isso sim...

  • Se você não sabe porque uma coisa foi criada, bem possível que ainda não tenha entendido completamente pra que ela serve, ou tudo que ela pode oferecer.

  • Novamente, Porque eu deveria saber a história do SCRUM?

    Resposta: pra nada, concurso é busca em largura, não em profundidade! Não tem só SCRUM na sua prova, é mais uma palavra no mar de palavras do seu edital...o erro é da banca em cobrar esse tipo de coisa...

ID
456184
Banca
FCC
Órgão
TRT - 23ª REGIÃO (MT)
Ano
2011
Provas
Disciplina
Engenharia de Software
Assuntos

NÃO se aplica à disciplina de desenvolvimento de software extreme programming (XP):

Alternativas
Comentários
  • talvez o termo "refabricação" possa dar margem a uma avaliação equivocada da alternativa B.
    O termo realmente não foi muito feliz...
    Deve ser entendido como "refatoramento", o "refactoring", que é sim uma das práticas do XP.
  • Domingos mas é essa a tradução que se encontra na última versão do Pressman. 
  • A letra B esta correta, no Pressman fala exatamente isso.
    A letra A está incorreta, no Pressman, 6ed, diz:

    "Como o projeto XP praticamente não usa notação e produz
    poucos, ou nenhum, produto de trabalho que não sejam
    os cartões CRC e as soulões de ponta o projeto é visto como um artefato
    provisório que pode e deve ser (....)"
  • a) Usa notações próprias para construir os diversos produtos de trabalho do projeto. - Tenta confundir com SCRUM que tem sprints, backlogs...
    b) Encoraja a refabricação para modificar um sofware sem alterar o comportamento externo do código. - Definição exata.
    c) Recomenda que dois programadores trabalhem juntos no mesmo computador para escrever um código. - Pair Programming
    d) Baseada em valores de simplicidade, comunicação, feedback e coragem. - Também Respeito
    e) Adota como um elemento-chave a criação de testes unitários antes da codificação começar. - desenvolvimento orientado a testes.
  • Também fui de B, só uma dúvida, o que essa alternativa quer dizer com "comportamento externo do código." ?

    []´s
  • Sem alterar o comportamento externo significa que o desenvolvedor pode alterar as linhas de códigos entre outras coisas mas para o usuário comum, o programa vai estar a mesma coisa. A letra B está correta, mas a questão quer a errada.
  • a) é falso pessoal, o processo XP, em seu projeto, não usa praticamente nenhuma notação e produz poucos, se algum, artefatos, além dos cartões CRC e soluções pontuais.

    b) CORRETO. refabricação faz parte do XP, este também é um método de otimizaçaõ de projetos, é o processo de alteração de um sistema de software de tal forma que não se altere o comportamento externo do código, mas se aprimore a estrutura interna. É uma forma disciplinada de organizar o código [e modificar/simplificar o projeto interno] que minimiza as chances de introdução de bugs. Em resumo, ao se refabricar, se está aperfeiçoando o projeto de codificaçaõ e depois de este ter sido feito.


    não vou explicar as demais porque os colegas abaixo já explicaram direitinho.
    bons estudos.

  • a)Usa notações próprias para construir os diversos produtos de trabalho do projeto.

    As notações são vistas na parte de modelagem de software, podendo usar BPMN, EPC, ARIS e/ou UML. 

ID
459256
Banca
FCC
Órgão
INFRAERO
Ano
2011
Provas
Disciplina
Engenharia de Software
Assuntos

Para gerenciar uma equipe de desenvolvimento de software, que utiliza a metodologia ágil XP,

Alternativas
Comentários
  •  a) não se permite a presença constante do cliente durante o desenvolvimento do projeto para não haver interferência na interpretação dos requisitos.

     b) é necessário adotar medidas para que os desenvolvedores trabalhem mais de 40 horas semanais fazendo horas extras, para agilizar o desenvolvimento e concluir o projeto em menos tempo.

    d) um nível médio de complexidade de programação deve ser definido de modo que satisfaça os requisitos atuais e futuros.

    e) uma entrega de versões do software a cada seis meses deve ser cumprida, contemplando o maior número possível de requisitos.
  • É o que se chama de Programação em Pares, umas das práticas adotadas pelo XP que consiste em programação em par/dupla num único computador, Geralmente um iniciante (codificando) + um instrutor. O programa é sempre revisto, evitando defeitos.
    Abraço e bons estudos.
    Marcelo
  • d) um nível médio de complexidade de programação deve ser definido de modo que satisfaça os requisitos atuais e futuros.

    O erro da opção (D) é apenas quando se refere aos requisitos futuros? O nível médio de complexidade de programação está correto? Não devria ser simples (não confundir com fácil)?
  • a) Na verdade é desejável a presença constante do cliente durante o desenvolvimento do projeto. Sempre auxiliando na interpretação dos requisitos.
    b) Na verdade é necessário adotar medidas para que os desenvolvedores trabalhem no máximo 40 horas semanais. Para manter um ritmo sustentável
    c) CERTO
    d) Na verdade deve-se adotar soluções simples de programação, de modo que satisfaça os requisitos atuais e futuros. obs. quando menciona-se requisitos futuros, podemos também entender como sendo futuras refatorações nessa solução aplicada hoje. Soluções simples auxiliará futuras refatorações.
    e) Na verdade uma entrega de versões do software deve ter duração de poucas semanas (incrementos, releases).

  • Nunca trabalhei com XP. Imagino que deve ser muito chato ser o programador "instrutor", que fica observando o que o colega está fazendo....

  • XP - Programação em pares!!!!! 

  • c-

    Programação a 2, um faz e o outro observa. xp nao gosta de documentação, devido a sua natureza de agile, a qual tambem prioriza proximidade com cliente e prazos curtos e entregas como milestones destes prazos

ID
495790
Banca
FUMARC
Órgão
BDMG
Ano
2011
Provas
Disciplina
Engenharia de Software
Assuntos

Analise as seguintes afirmativas sobre o processo ágil Extreme Programming (XP).

I. Planejamento, Projeto, Codificação e Teste são atividades de arcabouço do XP.

II. Cartões CRC (Class Responsibility Collaborator) são produtos de trabalho da atividade de projeto do XP.

III. O XP recomenda a programação em par durante a atividade de codificação.

Marque a alternativa CORRETA:

Alternativas
Comentários
  • I. Correto

    Processo XP

    Planejamento -> Projeto -> Codificação -> Teste

    II. Correto

    Na fase de projeto utiliza-se os cartões CRC

    III. Correto

    Na fase de codificação utiliza-se a programação em par
  • todas as afirmações estão corretas..... a mais estranha é a primeira: Planejamento, Projeto, Codificação e Teste são atividades de arcabouço do XP.
    troque arcabouço por framework.
  • I - Certo. A Extreme Programming emprega uma abordagem orientada a objetos como o seu paradigma de desenvolvimento preferido e envolve um conjunto de regras e práticas constantes no contexto de quatro atividades metodológicas: planejamento, projeto, codificação e testes. (pag 88)
    "Arcabouço de Processo" é um termo utilizado por Pressman para definir a estrutura principal de um processo, geralmente em termos de suas atividades.
    II - Certo. A XP encoraja o uso de cartões CRC como um mecanismo eficaz para pensar sobre o software em um contexto orientado a objetos. Os cartões CRC (classe-responsabilidade-colaborador) identificam e organizam as classes orientadas a objetos relevantes para o incremento de software corrente. Os cartões CRC são o único artefato de projeto produzido como parte do processo XP. (pag 89) III - Certo. Um conceito chave na atividade de codificação (e um dos mais discutidos aspectos da XP) é a programação em dupla. A XP recomenda que duas pessoas trabalhem juntas em uma mesma estação de trabalho para criar código para uma história. (pag 90) (Fonte: Engenharia de Software, 7ed, Pressman)
    Gabarito "D".
ID
606214
Banca
CESGRANRIO
Órgão
FINEP
Ano
2011
Provas
Disciplina
Engenharia de Software
Assuntos

São práticas recomendadas pelo processo ágil de desenvolvimento de software Extreme Programming (XP), EXCETO a

Alternativas
Comentários
  • Letra C. Na Extreme Programming, a documentação existe, é simplificada, e o nível de detalhamento é básico.

  • Programação em Pares: Um computador, um teclado, dois programadores; Papéis são alternados freqüentemente; Pares são trocados periodicamente. Benefícios: Melhor qualidade do design, código e testes; Revisão constante do código; Nivelamento da equipe e Maior comunicação. 

    Refatoração (Refactoring): Não existe uma etapa isolada de projeto em XP, o código é o projeto! O projeto é melhorado continuamente através de mudança proposital de código que está funcionando (melhorar o design, simplificar o código, remover código duplicado, aumentar a coesão, reduzir o acoplamento). 

    Integração contínua: manter o sistema integrado o tempo todo. Integração de todo o sistema pode ocorrer várias vezes ao dia (pelo menos uma vez ao dia) e todos os testes (unidade e integração) devem ser executados. Benefícios: Expõe o estado atual do desenvolvimento (viabiliza lançamentos pequenos e freqüentes); Estimula design simples, tarefas curtas, agilidade; Oferece feedback sobre todo o sistema; Permite encontrar problemas de design rapidamente. 

    Padrões de codificação (Coding Standards): O código escrito em projetos XP segue um padrão de codificação, definido pela equipe em relação a padrão para nomes de métodos, classes, variáveis e organização do código (chaves, etc.) Facilita e estimula a posse coletiva, a comunicação dentro da equipe, a simplicidade, a programação em pares, o refinamento do design. 

    Outras práticas: 

    • Whole Team – Equipe

    • Plannig Game – Jogo do planejamento

    • Customer Tests – Testes de aceitação

    • Small releases – Versões pequenas

    • Simple Design – Projeto simples

    • Test-driven Development – Desenvolvimento orientado a testes (TDD)

    • Collective Ownership – Posse coletiva

    • Metaphor – Metáfora

    • Sustainable Place – Ritmo saudável

  •  c)Documentação Abundante e Detalhada

    Como ja foi dito antes (nao lembro quem), agile não gosta de documentação

  • Pessoal, a metodologia XP como todas as demais derivam do Manifesto Ágil, que diz é preferível um software em funcionamento a uma documentação abrangente. Isso não quer dizer que não haverá documentação. Haverá sim, mas apenas aquelas que realmente seja necessárias.

    Gabarito

    c) X.

ID
644440
Banca
FCC
Órgão
TJ-PE
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

Sobre XP e SCRUM é INCORRETO afirmar:

Alternativas
Comentários
  • c) No XP, não há indicação de que é necessário criar documentação no código porém, os documentos tradicionais são reduzidos aos aspectos mais relevantes, visando obter no final do processo, apenas artefatos e grande importância para o projeto.

       A DESCRIÇÃO ACIMA ESTARIA CORRETA SE NO LUGAR DE XP TIVESSE SCRUM. O PRINCIPAL ERRO DA QUESTÃO ESTAR EM DIZER QUE NO XP NÃO SE PRECISA DOCUMENTAR NO CÓDIGO.
  • O XP define algumas documentações mais simples, como por exemplo um modelo de arquitetura feito em um quadro branco e cartões CRC para definições das classes.
  • A resposta E está incorreta, segundo o livro Extreme Programming de Vinícius Teles. Na página 84 ele afirma o seguinte: "O cliente pode alterar as est[orias que serão implementadas em um release. Já no caso da iteração isto não é possível. Uma vez que o cliente priorize um conjunto de estórias para uma iteração, a equipe irá trabalhar somente naquelas estórias e não aceitará que o usuário faça mudanças"

    Logo o XP não é receptivo a mudanças durante a iteração.
  • Comentário da letra C: "[...] os documentos tradicionais são reduzidos aos apectos mais relevantes[...]".

    O único produto de trabalho (artefato) do XP são os cartões CRC. O XP produz muito pouco ou nenhum artefato atém dos cartões CRC. Assim, não há documentos tradicionais.

    Comentário da letra E: "[...]no SCRUM as solicitações do cliente demvem aguardar o término da iteração em andamento".

    Pressman diz que enquanto um sprint está em andamento, as pendências a que ele se relaciona são congelados, ou seja, não podem ser inseridas modificações. Contudo, dá para entender que pela passagem do livro que enquanto um sprint em andamento está trabalhando em uma ou mais pendências, somente essas pensdências ficam congeladas e modificações não podem ser inseridas. As demais não se encontram congeladas e assim, solicitações de modificação podem ser inseridas.
  • Comentário da letra E: "[...]no SCRUM as solicitações do cliente devem aguardar o término da iteração em andamento".
    Se a Equipe de Desenvolvimento determina que tem excesso ou falta de trabalho, os itens do Backlog da Sprint pode ser renegociados com o Product Owner.

    Somente a Equipe de Desenvolvimento pode alterar o Backlog da Sprint durante a Sprint. O Backlog da Sprint é altamente visível, uma imagem em tempo real do trabalho que a Equipe de Desenvolvimento planeja completar durante a Sprint, e pertence exclusivamente à Equipe de Desenvolvimento

    O Product Owner é a única pessoa responsável por gerenciar o Backlog do Produto. 

    Revisão da Sprint
    A Revisão da Sprint é executada no final da Sprint para inspecionar o incremento e adaptar o Backlog do Produto se necessário. Durante a reunião de Revisão da Sprint o Time Scrum e as partes interessadas colaboram sobre o que foi feito na Sprint. Com base nisso e em qualquer mudança no Backlog do Produto durante a Sprint, os participantes colaboram nas próximas coisas que precisam ser prontas. Esta é uma reunião informal, e a apresentação do incremento destina-se a motivar e obter comentários e promover a colaboração.

    Como vimos o cliente pode alterar o Backlog do Produto a qualquer momento porque é responsável por este artefato, porém "solicitações do cliente" nos remete a uma comunicação do cliente com os demais membros do time scrum, e portanto seria uma modificação do Backlog da Sprint.
    Que só são modificadas em caso de excesso ou falta de trabalho, de acordo com a visão da Equipe de Desenvolvimento.
  • "O SCRUM tem como características a divisão do processo em pequenos ciclos de desenvolvimento chamados Sprint, o monitoramento do progresso do processo através de reuniões diárias com toda a equipe e, reuniões com os Stakeholders no fim de cada ciclo de desenvolvimento."

    Reuniões com stakeholders?tá certo isso?
  • Pessoal, vamos lá.

    Se o XP recomenda práticas como programação em pares e código coletivo, a documentação no código se torna necessária. Do contrário, como imaginar que qualquer programador possa alterar qualquer parte do código, sem o mínimo de orientação sobre o que exatamente aquele trecho de código se propõe a fazer.

    Questão fácil de matar por eliminação e seguindo este raciocínio.
    Bons estudos.

  • Um dúvida na letra B. As reuniões feitas após uma sprint não são feitas apenas com o Product Owner. O termo Stakeholders não está generalizando? 

  • Além de citar reunião com os Stakeholders, o que pode abranger o cliente, não necessariamente algo obrigatório já que não fala TODOS os Stakeholders, visto que o temo generaliza todos os INTERESSADOS no projeto de algum modo, ainda cita o termo "com toda equipe" não deixa claro que equipe está sendo considerada, as reuniões diárias ocorrem apenas com a equipe de desenvolvimento, diferente de uma reunião de fim de ciclo com os interessados no projeto, correto?

  • EITA QUESTÃO DANADA DE MAL ELABORADA!

  • Opinião sobre a letra (e). O que se prevalece é aquilo que o SCRUM diz e não o sr. Pressman

    "During the Sprint:

    - No changes are made that would affect the Sprint Goal"

    Da licença né? se o cliente pedir para mudar a cor de um grid para melhor visualizar os registros vai ter que esperar por 1mês?

  • Acho que esse é um bom artigo para abordar essa questão: http://www.eventosufrpe.com.br/jepex2009/cd/resumos/R0484-2.pdf

  • Apenas reforçando o que foi dito:
    A alternativa "E" não está completamente correta, umas vez que o guia Oficial do Scrum afirma:
    "During the Sprint:

    No changes are made that would endanger the Sprint Goal;" Ou seja, as modificações são aceitas, desde que não coloque em perigo as metas da Sprint.

  • Este e o motivo da letra do gabarito ser incorreta : 
    "visando obter no final do processo, apenas artefatos de grande importância para o projeto." 
    Deve-se obter no final do 'processo' ou 'projeto' aquilo que adiciona valor ao "software" ou ao "negócio do cliente".  
    'APENAS ....para o projeto'
    Software em funcionamento mais que documentação abrangente: a documentação deve existir para ajudar pessoas a entender como o sistema foi construído. 
    http://www.manifestoagil.com.br/

  • o erro da questão é dizer que no XP não há necessidade de criar a documentação no código.

    Metodologias ágeis como a XP enfatizam a documentação de software no próprio código, seguindo os padrões de codificação que é uma das boas práticas que é justamente você comentar o seu código nas interfaces dos métodos, funções.

  • Na minha visão, o maior erro da alternativa D) é dizer que se deve obter apenas artefatos de grande para o projeto. XP preconiza pequenos releases que vão sendo incrementados ao primeiro release, de forma que seja possível realizar releases frequentes.

  •  c)No XP, não há indicação de que é necessário criar documentação no código porém, os documentos tradicionais são reduzidos aos aspectos mais relevantes, visando obter no final do processo, apenas artefatos de grande importância para o projeto.

    XP é o que usa programação a 2, plano de testes antes do codigo. é indicado sim incluir comentarios no codigo para facilitar o andamento do processo

ID
646153
Banca
FCC
Órgão
TJ-PE
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

Nos métodos ágeis XP e Scrum, as entregas de partes funcionais do projeto são divididas em ciclos, geralmente compreendidos no período de 1 a 4 semanas. Estes ciclos denominam-se, respectivamente,

Alternativas
Comentários
  • LETRA A.
    XP     é uma metodologia ágil, para o desenvolvimento de projetos de IT cujas especificações são passíveis a alterações. As iterações do XP costumam ser curtas, provendo constantes versões do produto (releases) para o cliente, que por sua vez provê comentários e opiniões que realimentam a próxima iteração. O objetivo do XP é tornar o projeto flexível, diminuindo o custo a possíveis mudanças. O código produzido é tomado como indicador de progresso do projeto.

    No Scrum, os projetos são dividos em ciclos (tipicamente mensais) chamados de Sprints. O Sprint representa um Time Box dentro do qual um conjunto de atividades deve ser executado. Metodologias ágeis de desenvolvimento de software são iterativas, ou seja, o trabalho é dividido em iterações, que são chamadas de Sprints no caso do Scrum. As funcionalidades a serem implementadas em um projeto são mantidas em uma lista que é conhecida como Product Backlog. No início de cada Sprint, faz-se um Sprint Planning Meeting, ou seja, uma reunião de planejamento na qual o Product Owner prioriza os itens do Product Backlog e a equipe seleciona as atividades que ela será capaz de implementar durante o Sprint que se inicia. As tarefas alocadas em um Sprint são transferidas do Product Backlog para o Sprint Backlog. A cada dia de uma Sprint, a equipe faz uma breve reunião (normalmente de manhã), chamada Daily Scrum. O objetivo é disseminar conhecimento sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho do dia que se inicia.

  • a-

    ciclos têm nomes diferentes dependendo da metodologia. EM xp, iterações. EM scrum, sprints.

ID
646156
Banca
FCC
Órgão
TJ-PE
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

No contexto de programação ágil XP, um débito técnico é descrito como o

Alternativas
Comentários
  • Débito Técnico seria o gap entre o estado de um artefato técnico e como ele o seria em seu estado da arte. No ramo de desenvolvimento de software, é a medida de quanto uma deficiência técnica compromete o futuro do projeto e pode ser utilizado para antecipar problemas como bugs, baixa produtivadade, dificuldades com manutenção e dificuldades com transferência de tecnologia.
    Isso exposto, o gabarito correto é a letra E de esfuziante.
  • debito tecnico é uma parte do codigo q não foi feita de forma adequada/padronizada q podera causar dificuldade em futuras manutenções.
  • O defeito é o efeito visível da baixa qualidade. O efeito, nem sempre visível, é o débito técnico. O débito técnico foi um termo cunhado para descrever o valor negativo de código escrito com baixa qualidade interna. Ao longo do tempo essa baixa qualidade vai cobrando o seu preço e tornando o time de desenvolvimento menos responsivo. 
    Como o código fica cada vez mais difícil de manter, para continuar atendendo o cliente, os desenvolvedores desrespeitam, cada vez mais, bons padrões de desenvolvimento de software, em um ciclo que vai se retroalimentando, engessando o time de forma crescente, gerando insatisfação nos seus membros e também com os clientes

  • Matéria interessante que explana o assunto: http://bytesdontbite.com/2011/09/26/a-metafora-da-divida-tecnica/

ID
704293
Banca
CESPE / CEBRASPE
Órgão
MPE-PI
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

A direção de uma empresa designou uma equipe de
analistas para garantir a qualidade dos sistemas de informação em
produção na entidade. Para cumprir suas atribuições, a equipe
recorreu a diversas técnicas e metodologias para a avaliação da
qualidade do desenvolvimento de software.

Com base nessa situação hipotética, julgue os itens que se seguem

O XP (extreme programming) é um método ágil, que preconiza a criação de um caso de teste unitário antes do início da codificação.

Alternativas
Comentários
  • Os testes unitários são um dos elementos chave em XP, pois são criados antes do código e armazenados em um repositório junto ao código que será testado. Um código que não possua seu respectivo teste unitário não deve ser liberado, pois cada parte do sistema com possibilidade de falha precisa ser verificada. Além disso, a criação de testes unitários antes do código provê uma melhor compreensão dos requisitos e direciona o foco dos desenvolvedores

    Verdadeiro!
  • Famoso TDD - Test Driven Development.

    Resposta: Certo.

  • Gaba: Certo.

    Desenvolvimento Orientado a Testes(Test Driven Development): 

    Primeiro crie os testes unitários (unit tests) e depois crie o código para que os testes funcionem. Esta abordagem é complexa no início, pois vai contra o processo de desenvolvimento de muitos anos. Só que os testes unitários são essenciais para que a qualidade do projeto seja mantida.

  • Software Engineering: A Practitioner`s Approach, Seventh Edition, Roger S. Pressman

    "After stories are developed and preliminary design work is done, the team does not move to code, but rather develops a series of unit tests that will exercise each of the stories that is to be included in the current release (software increment)"


    "I have already noted that the creation of unit tests before coding commences is a key element of the XP approach. "


    Parte One, Chapter 3, Pg. 76

ID
708943
Banca
FCC
Órgão
MPE-PE
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

Dentre as práticas do método ágil Extreme Programming (XP), está a prática de propriedade coletiva. É correto afirmar que, nessa prática,

Alternativas
Comentários
  • A propriedade coletiva do código é outra característica fundamental do método XP, com a rotatividade do código entre os programadores e reuniões freqüentes para estabilizar o código. A propriedade coletiva encoraja o time todo a contribuir com novas idéias. Qualquer membro do time pode adicionar funcionalidade, corrigir erros ou re-fabricar o código. Não existe a figura do arquiteto chefe. Todos são responsáveis pelo código inteiro. Não existe alguém para aprovar as mudanças. Reuniões freqüentes devem ser definidas como parte do processo iterativo de programação. Estas reuniões devem ser curtas e são realizadas com todos de pé.

    letra C
  • Marquei a letra "A" porque, apesar de não falar que o código não tem um 'dono',  ela diz respeito ao fato de que qualquer um pode revisar o código de qualquer um, não há código necessariamente restrito a modificação por alguém.

    A letra "B" está fora do contexto da prática de propriedade coletiva.

    A letra "C" diz respeito mais ao Pair Programming do que à propriedade coletiva do código.

    A letra "D" diz respeito ao Sustainable Pace, ou Ritmo Sustentável.

    A letra "E" está fora do contexto da prática de propriedade coletiva.
  • Caro Bruno,
    Na letra A ela dá enfoque à programação em pares quando afirma "os trabalhos são desenvolvidos em conjunto, para que um programador possa analisar o trabalho do outro".
    Já na letra C, ele destaca que a dupla deve trabalhar em todas as áreas do sistema.
  • De cara já podemos eliminar a letra D,pois quando falamos em Xp
    sabemos que não são utilizadas horas extras.
  • A) Pair programming
    B) ?
    C)Propriedade Coletiva
    D) Ritmo Sustentável
    E) Cliente sempre presente

  • Não entendi porque a D poderia estar errada!

  • Extreme Programming envolve um conjunto de práticas, algumas delas são:

    - Planejamento Incremental: Os requisitos são registrados em cartões de histórias e as histórias a serem incluídas em um release são determinadas pelo tempo disponível e sua prioridade relativa. Os desenvolvedores dividem essas histórias em “tarefas”.

    - Pequenos Releases: O conjunto mínimo útil de funcionalidade que agrega valor ao negócio é desenvolvido primeiro. Releases do sistema são frequentes e adicionam funcionalidade incrementalmente ao primeiro release.

    - Projeto Simples: É realizado um projeto suficiente para atender aos requisitos atuais e nada mais.

    - Desenvolvimento test-first: Um framework automatizado deteste unitário é usado para escrever os testes para uma nova parte da funcionalidade antes que esta seja implementada.

    - Refactoring: Espera-se que todos os desenvolvedores recriem o código continuamente tão logo os aprimoramentos do código forem encontrados. Isso torna o código simples e fácil de manter.

    - Programação em Pares: Os desenvolvedores trabalham em pares, um verificando o trabalho do outro e fornecendo apoio para realizar um bom trabalho.

    - Propriedade Coletiva: Os pares de desenvolvedores trabalham em todas as áreas do sistema, de tal maneira que não se formem ilhas de conhecimento, com todos os desenvolvedores de posse de todo o código. Qualquer um pode mudar qualquer coisa.

    - Integração Contínua: Tão logo o trabalho em uma tarefa seja concluído, este é integrado ao sistema como um todo. Depois de qualquer integração, todos os testes de unidade devem ser realizados.

    - Ritmo Sustentável: Grandes quantidades de horas extras não são consideradas aceitáveis, pois, no médio prazo, há uma redução na qualidade do código e na produtividade.

    - Cliente on-site: Um representante do usuário final do sistema (o cliente) deve estar disponível em tempo integral para apoiar a equipe XP. No processo da extreme programming, o cliente é membro da equipe de desenvolvimento e é responsável por trazer os requisitos do sistema à equipe para implementação.

    (Fonte: Livro Engenharia de Software, Sommerville, 8ed, pag 264)

    Então Alexandre, como já foi destacado pelos colegas, cada uma das alternativas está relacionada a uma prática distinta do XP. A questão pede para escolhermos a alternativa que descreve a prática de "Propriedade Coletiva". Logo, não poderia ser a letra "D" pois esta descreve a prática "Ritmo Sustentável". Gabarito letra "C".


  • Todas as afirmativas fazem sentido no contexto do XP, mas a única que tem relação com a prática da propriedade coletiva é a letra C.

ID
726907
Banca
INSTITUTO CIDADES
Órgão
TCM-GO
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

São consideradas metodologias ágeis de desenvolvimento:

I. Scrum

II. DSDM

III. XP (Extreme Programming – Programação Extrema)

IV. FDD

Alternativas
Comentários
  • Não conhecinha a métodologia DSDM!
    Metodologia de Desenvolvimento de Sistemas Dinâmicos (do inglês Dynamic Systems Development Method - DSDM): 
    É interativa e incremental de propriedade da Agile Alliance. Caracterizada por cronogramas e custos limitados.
    3 fases: pré-projeto, ciclo de vida, e pós-projeto.
    A fase ciclo de vida é subdividida em 5 estágios: análise de viabilidade, análise de negócio, Iteração do Modelo Funcional, iteração de elaboração e construção e, por fim, implantação.
  • Modelos Ágeis:
    - DSDM (Dynamic Systems Development Method)
    - Scrum
    - Crytal
    - FDD (Feature Driven Development)
    - XP (Extreme Programing)
    - ASD (Adaptive Software Development)

  • - Kaban

    - DDD (Domain-Driven Design)

    - TDD (Test-Driven Development)


  • METODOLOGIA DE DESENVOLVIMENTO ÁGIL
    1.   RUP
    2.   SCRUM
    3.   XP
    4.   DSDM
    5.   DAS OU ASD
    6.   FDD
    7.   MODELAGEM ÁGIL
    8.   OPEN SOURCE SOFTWARE DEVELOPMENT - segundo o Cespe


    Só não entendi a carinha amarela

    Basta consultar Pressman que gabarita a questão

    Letra E

  • RUP???

  •  e)Todas as afirmações .

    Metologias agile prescrevem desenvolvimento de software com varias iterações por todos os esteagios da produção varias vezes, o que faz com que seja chamado de modelo iterativo e desenvolvimento espiral. Os estagios sao os mesmos do waterfall model (analise, design, implementação, testes, implantação, manutencção), mas produz uma versao funcionald o software no final de cada ciclo. metologias agile:

    XP (programação a 2 e testes antes do codigo), Scrum (equipes auto-organizaveis com base no empirismo), FDD (features a cada 2 semanas), crystal (uma familia determinada por cores e com incrementos a cada 4 meses), DSDM (base no RAD (rapid application development) com destaque à participação do usuario)

  • RUP não é agil.

ID
753193
Banca
FCC
Órgão
MPE-AP
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

O Extreme Programming (XP) é, talvez, o mais conhecido e mais utilizado dos métodos ágeis. Dentre suas práticas se encontram programação em pares, integração contínua, refatoração e

Alternativas
Comentários
  • a) Posse Coletiva (Collective Ownership): O código fonte não tem dono e ninguém precisa solicitar permissão para poder modificar o mesmo. O objetivo com isto é fazer a equipe conhecer todas as partes do sistema.

    b) O envolvimento do cliente é constante, durante todo o processo de desenvolvimento.

    c)     Ritmo Sustentável (Sustainable Pace): Trabalhar com qualidade, buscando ter ritmo de trabalho saudável (40 horas/semana, 8 horas/dia), sem horas extras. Horas extras são permitidas quando trouxerem produtividade para a execução do projeto. Outra prática que se verifica neste processo é a prática de trabalho energizado, onde se busca trabalho motivado sempre. Para isto o ambiente de trabalho e a motivação da equipe devem estar sempre em harmonia.

    d) idem letra A

    e) Pequenas Versões (Small Releases): A liberação de pequenas versões funcionais do projeto auxilia muito no processo de aceitação por parte do cliente, que já pode testar uma parte do sistema que está comprando. Metáfora (simples histórias): Procura facilitar a comunicação com o cliente, entendendo a realidade dele. O conceito de rápido para um cliente de um sistema jurídico é diferente para um programador experiente em controlar comunicação em sistemas em tempo real, como controle de tráfego aéreo. É preciso traduzir as palavras do cliente para o significado que ele espera dentro do projeto.
  • letra e: Histórias de Clientes?

    O correto seriam histórias de usuários

    A letra A também está correta, já que aumenta o desempenho da equipe
    questão passível de recurso

  • Quando se fala em propriedade coletiva não está se referindo a participação nos lucros da empresa, e sim a propriedade coletiva do código fonte, onde todos os membros da equipe podem 'fuçar' no código que foi produzido por outro membro da equipe. A programação em pares funciona nesse sentido, enquanto um está programando o outro está do lado enchendo o saco e dizendo o que ele acha, que era melhor fazer de outro jeito ou simplesmente concordando.

    A letra 'A' é a mais errada de todas.

  • propriedade coletiva: encoraja o time todo a contribuir com novas idéias.

    envolvimento do cliente: Clientes devem ser profundamente envolvidos no processo de desenvolvimento

  • Segundo SOMMERVILLE as Práticas de " eXtreme Programming - XP" São divididas em 10 são elas:

    Planejamento Incremental;
    Pequenos Releases;
    Projeto Simples;
    Desenvolvimento test-first;
    Refatoração;
    Programação em Pares;
    Propriedade Coletiva;
    Integração Contínua;
    Ritmo Sustentável;
    Cliente no Local.

    DESENVOLVIMENTO INCREMENTAL: É sustentado por meio de pequenos e frequentes releases do sistema. Os requisitos são baseados em cenários ou em simples estórias de clientes, usadas como base para decidir a funcionalidade que deve ser incluída em um incremento do sistema.
    Referência:
    SOMMERVILLE (Pág. 44 e 45) -  Engenh. de Soft. 9° Edição.

  • A) Erro: não existe participação do lucro, a questão de ser propriedade coletiva está relacionado ao código fonte pois todo mundo pode alterar o código de todo mundo. 

    B) Erro: envolvimento do cliente em toda fase do processo. 

    C) Erro: não existe horas extras, 100% das 40 horas semanais trabalhando e o resto é 100% do tempo de descanso.

    D) Error: Código sempre LIMPO.

    E) Correta.

  • Ri D+ com o item A

ID
770152
Banca
CESPE / CEBRASPE
Órgão
Banco da Amazônia
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

Julgue os itens que se seguem, em relação a metodologias de
análise, projeto e desenvolvimento de sistemas.

Metodologias de desenvolvimento XP contam com o desenvolvimento orientado a testes, que engloba duas etapas: escrever um teste automatizado e desenvolver um código adequado o suficiente para ter sucesso nesse teste.

Alternativas
Comentários
  • No XP, os testes são realizados antes da codificação.
  • Na Metodologia Ágil XP uma estrutura de testes unitários automatizada é criada e os testes são escritos antes das funcionalidades serem implemetadas.
  • Na metodologia de desenvolvimento XP, os testes são escritos antes da implementação do código, para que o mesmo não fique viciado pelo desenvolvedor ( geralmente tendemos a fazer o teste em nossos sistemas de forma viciada pois já testamos de modo que não de erro) , 

    dessa maneira quando a questão afirma 
    "desenvolver um código adequado o suficiente para ter sucesso nesse teste." 

    o teste já esta escrito e o desenvolvedor vai se esforçar para que seu código não gere erros pois ele já sabe quais os possíveis erros. 
  • Verdade mesmo são três etapas: teste - codigo - refactoring. Mas bom saber como o Cespe cobra

    http://www.google.com/imgres?imgurl=http://rtigger.com/images/posts/tdd.png&imgrefurl=http://rtigger.com/blog/2013/03/11/tdd-training-wheels-for-developers&h=417&w=670&sz=498&tbnid=vzhiMs9j3y7MRM:&tbnh=68&tbnw=110&zoom=1&usg=__idvgUsAH4XYtD61d8sL16Uinmq4=&docid=xaFoEfSy1zmPOM&sa=X&ei=5HiBUc6mHbS24AOskIDAAg&ved=0CFYQ9QEwBQ&dur=123



  • Complicado assim. Como apontou o Raphael, são 3 etapas: escreve um teste que falhe, faça o teste passar e refatore. Vou ter que criar uma regra à parte pra cespe pelo jeito.

  • Realmente são 3 etapas, escrever um teste, fazer o teste passar e por fim refatorar. 

    A questão está certa por ela falar que engloba essas 2 fases. A regra da CESPE é: Omitir não torna a questão errada.

    Tem que se pensar da seguinte forma na CESPE: se ela afirmar que o XP possui 2 etapas, está CORRETO, afinal possui até 3, quanto mais 2.

  • É a terceira vez que erro esta questão. Ora, um dos princípios da aplicação do TDD não é primeiramente criar um teste que falhe? "Each test case fails initially: This ensures that the test really works and can catch an error. Once this is shown, the underlying functionality can be implemented. This has led to the "test-driven development mantra", which is "red/green/refactor," where red means fail and green means pass. Test-driven development constantly repeats the steps of adding test cases that fail, passing them, and refactoring. Receiving the expected test results at each stage reinforces the developer's mental model of the code, boosts confidence and increases productivity." Não consigo me conformar com esse gabarito =\

  • O TDD (usado no XP) possui 3 fases: Red (criar os testes) > Green (escrever a funcionalidade que implemente o teste) > Refact (refatorar esse código).


    No meu entendimento, a questão está correta em dizer que o desenvolvimento orientado a testes possui duas etapas, pois aduz à ideia de que a segunda etapa mencionada (desenvolver um código adequado o suficiente para ter sucesso nesse teste) engloba tanto a fase Green quanto a Refact.


    Portanto, gabarito correto.
ID
783589
Banca
CESPE / CEBRASPE
Órgão
MEC
Ano
2011
Provas
Disciplina
Engenharia de Software
Assuntos

Julgue o  item  seguinte , relativo a processos de software e a sistemas orientados a objetos (OO).

O desenvolvimento de um código na Extreme Programming está relacionado à fase de planejamento, pois, nessa metodologia, não há fase de desenvolvimento, haja vista que a codificação é realizada em pares.

Alternativas
Comentários

  • Questão errada, pois existe sim a etapa de desenvolvimento no XP. Segundo Sommerville, o ciclo de um release em Extreme Programming é: Selecionar estórias do usuário para este release, dividir estórias em tarefas, planejar release, DESENVOLVER/INTEGRAR/TESTAR software, liberar software e avaliar sistema.

     

    Fonte: Sommerville, 9ª Edição, Capítulo 3.

  • Ciclo XP -> avaliar o sistema; selecionar o cenário para versão atual; dividir histórias em tarefas; planejar a versão; desenvolver, integrar CONTINUAMENTE, testar o software; liberar o software;

     

    Ciclo XP (curto) -> planejamento, projeto, codificação, testes. (eventualmente ciclo é "quebra" e sai um incremento de software)

ID
795166
Banca
FCC
Órgão
TST
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

O XP (Extreme Programming) utiliza uma abordagem orientada a objetos como seu paradigma de desenvolvimento predileto. Ele

Alternativas
Comentários
  • O XP (Extreme Programming) utiliza uma abordagem orientada a objetos como seu paradigma de desenvolvimento predileto. Ele
    a) (CORRETA) recomenda que duas pessoas trabalhem juntas para criar o código correspondente a uma história.
    - Pair Programming é uma das práticas do XP - Programadores trabalham em pares, checando (validando) mutuamente o trabalho feito.
    b) (ERRADA) recomenda que a equipe XP e os clientes trabalhem de forma separada para não mudar o compromisso básico definido para a versão a ser entregue.
    - Cliente sempre presente é uma das práticas do XP - O cliente, com conhecimento do negócio, deve estar disponível de forma integral para a equipe.
    c) (ERRADA) segue rigorosamente o princípio FDD - Feature Driven Development.
    - O XP não segue rigorosamente o FDD, na verdade trata-se de metodologias ágeis distintas que apenas são Valeu Driven
    d) (ERRADA) recomenda que depois que as histórias forem desenvolvidas e o trabalho preliminar do projeto for feito, a equipe XP avance diretamente para o código.
    - O XP apoia diretrizes de desenvolvimento que enfatizam entregas em contraposição à análise e projeto.
    e) (ERRADA) inclui um conjunto de regras e práticas que ocorrem no contexto de 3 atividades de arcabouço: projeto, implementação e entrega.
    - Não existem regras no XP, apenas práticas e valores.
  • A nomenclatura "história" causa muito desconforto nessa questão. Mas as letras b a e estão todas erradas, como o colega já apontou.
  • Em relação a letra E: de acordo com Pressman, sexta edição, pg 63
    O XP inclui um conjunto de regras e práticas que ocorrem no contexto de quatro atiivdades de arcabouço: planejamento, projeto, codificação e teste.

    Em relação a letra D: de acordo com Pressman, sexta edição, pg 65
    O XP recomenda que depois que as histórias forem desenvolvidas e o trabalho preliminar de projeto for feito, a equipe não avance para o código mas, em vez disso, desevnovla uma série de testes unitários que exercitarão cada uma das histórias que devem ser incluídas na versão atual (incremento do sw).

  • Gaba: Letra A

    Pair Programming (Programação em dupla)

    Todo código de produção é desenvolvido por duas pessoas trabalhando com o mesmo teclado, o mesmo mouse e o mesmo monitor, somando forças para a implementação do código. À primeira vista pode parecer loucura, pois se imagina estar gastando dois recursos humanos ao mesmo tempo para fazer a mesma tarefa e sem possibilidade de avanço substancial no projeto. Mas na verdade, essa prática tem pontos positivos como:

    Compartilhamento de conhecimento sobre das regras de negócio do projeto por todos da equipe de desenvolvimento;

    Fortalece a prática de Propriedade Coletiva do Código;

    Nivelação de conhecimento técnico dos programadores;

    Elevação dos níveis de atenção ao código produzido, pois um “supervisiona” e orienta o trabalho do outro. Dessa forma, minimiza-se a possibilidade de erros no código, erros de lógica e produção de um código fora dos padrões estabelecidos pela equipe.

  •  a)recomenda que duas pessoas trabalhem juntas para criar o código correspondente a uma história. 

    XP prega programação a 2 com testes antes do codigo. As atividades do arcabouço sao 4: planejamento, projeto, codigo & testes.

ID
800770
Banca
Exército
Órgão
EsFCEx
Ano
2011
Provas
Disciplina
Engenharia de Software
Assuntos

Com relação aos modelos de desenvolvimento ágeis de software, qual modelo ágil de processo possui como principais características o uso de histórias do usuário durante as atividades de planejamento, o uso de cartões CRC (Class- Responsability-Colaboration) como mecanismo efetivo para raciocinar sobre o software no contexto orientado a objetos e o uso de protótipos denominados “solução de ponta” como estratégia de diminuir riscos antes da implantação real do software?

Alternativas
Comentários

  • A XP estimula o uso de cartões CRC como um mecanismo eficaz para pensar o software em um contexto orientado a objetos. Os cartões CRC (classe-responsabilidade-colaborador) identificam e organizam as classes orientadas a objetos relevantes para o incremento de software corrente. Os cartões CRC são o único artefato de projeto produzido como parte do processo XP.

    A XP estimula a refatoração – é o processo de alterar um sistema de software de modo que o comportamento externo do código não se altere, mas a estrutura interna se aprimore. É uma forma disciplinada de organizar código [e modificar/simplificar o projeto interno] que minimiza as chances de introdução de bugs. Em resumo, ao se refatorar, se está aperfeiçoando o projeto de codificação depois de este ter sido feito.

    Fonte: Roger S. Pressman • Bruce R. Maxim Engenharia de Software

    UMA ABORDAGEM PROFISSIONAL

    8a EDIÇÃO

    Capítulo 5 - Desenvolvimento Ágil - Página - 74

    @papirobizurado

  • Extreme Programming (XP)

    ·  É o modelo mais utilizado de todos os modelos de processos ágeis.

    ·  Emprega uma abordagem orientada a objetos.

    ·  Envolve um conjunto de regras e práticas constantes no contexto de quatro atividades metodológicas: planejamento, projeto, codificação e teste;

    · Várias novas versões de um sistema podem ser desenvolvidas, integradas e testadas em um único dia por programadores diferentes.

    ·  Os requisitos são expressos como cenários (histórias do usuário)

    ·  Os programadores trabalham em pares.

    ·  Clientes estão intimamente envolvidos na especificação e priorização dos requisitos do sistema. O cliente ajuda a desenvolver testes de aceitação.

    ·  O cliente é parte da equipe de desenvolvimento e discute cenários com outros membros da equipe. Juntos, eles desenvolvem um “cartão de história”

    ·    Sugeri que o software deve ser constantemente refatorado.

    ·     Desenvolvimento test-first (escreve o teste antes do código)

    Alternativa C

ID
804523
Banca
CESPE / CEBRASPE
Órgão
MEC
Ano
2011
Provas
Disciplina
Engenharia de Software
Assuntos

Considerando que processo de software pode ser definido como um conjunto de atividades inter-relacionadas que transformam insumos (entradas) em produtos (saídas), julgue o  item  que se segue.

A extreming programming (XP) é considerada um método ágil, em que todos os requisitos são expressos por meio de cenários. O ciclo de release em XP engloba: selecionar as histórias dos usuários para implementação na versão, dividir as histórias em tarefas, planejar a versão, desenvolver/construir e testar o software, liberar o software e avaliar o sistema.

Alternativas
Comentários

  • Cada iteração terá um conjunto de estórias a serem implementadas, que  passam por uma análise, por um design, e  por testes na  mesma iteração vigente.

    http://www.devmedia.com.br/planejando-seu-projeto-com-extreme-programming-parte-i/4273

ID
804526
Banca
CESPE / CEBRASPE
Órgão
MEC
Ano
2011
Provas
Disciplina
Engenharia de Software
Assuntos

Considerando que processo de software pode ser definido como um conjunto de atividades inter-relacionadas que transformam insumos (entradas) em produtos (saídas), julgue o  item  que se segue.

São características de teste na XP: desenvolvimento test-first, desenvolvimento incremental de testes a partir de cenários, envolvimento do usuário no desenvolvimento e validação de testes e o uso de ferramentas de teste automatizadas.

Alternativas
Comentários

  • Além desses, podemos citar: reuniões em pé; time coeso; projeto simples; desenvolvimento em pares; pequenos releases; código de propriedade coletiva; time coeso; integração contínua; ritmo sustentável, releases; jogo do planejamento.

  • Que merd4 é essa?

ID
869497
Banca
VUNESP
Órgão
TJ-SP
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

Dentre as metodologias de desenvolvimento de software, pode-se citar a linha dos métodos ágeis. Assinale a alternativa que contém apenas métodos dessa linha.

Alternativas
Comentários

  • Questaão pra não zerar. 

  • Alternativa correta: LETRA C

ID
898123
Banca
CESGRANRIO
Órgão
BNDES
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

Sendo atualmente conhecida por just-in-time, a produção enxuta contém princípios que compõem a base dos processos ágeis de desenvolvimento de software, como o Extremme Programming (XP).

Um dos princípios básicos do XP, a eliminação de desperdícios, busca

Alternativas
Comentários

  • Conforme os princípios do XP : An iterative development style can add agility to your development process. Try just in time planning by not planning specific programming tasks farther ahead than the current iteration.

ID
900373
Banca
IADES
Órgão
EBSERH
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

O XP (Programação Extrema) é uma metodologia de desenvolvimento de software, que visa a agilidade no processo de desenvolvimento. A utilização desta metodologia

Alternativas
Comentários

  • a) E. O cliente é uma peça fundamental para o projeto, afinal o produto está sendo feito para atender as expectativas dele. Logo nenhuma metodologia de desenvolvimento de software preverá afastar o cliente.

    b) C.

    c) E. Qualidade é uma palavra que sempre é levada em consideração nos processos de desenvolvimento de software. Software com qualidade que atenda as expectativas do cliente.

    d) E. Utiliza teste exaustivamente, porque testar uma pouca prática. Antes de escrever qualquer funcionalidade, se desenvolve primeiro o teste.

    e) E. Vide item d.

    Não sei por que a questão foi anulada.

ID
906340
Banca
FCC
Órgão
TRT - 9ª REGIÃO (PR)
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

Os modelos de processos tradicionais surgiram em um cenário muito diferente do atual, baseado em mainframes e terminais remotos. Já os modelos de processos ágeis são adequados para situações atuais nas quais a mudança de requisitos é frequente. Dentre os modelos de processos ágeis mais comuns temos: Extreme Programming (XP), Scrum e Feature Driven Development (FDD).

Algumas das práticas e características desses modelos de processo são descritas a seguir:

I. Programação em pares, ou seja, a implementação do código é feita em dupla.

II. Desenvolvimento dividido em ciclos iterativos de até 30 dias chamados de sprints.

III. Faz uso do teste de unidades como sua tática de testes primária.

IV. A atividade de levantamento de requisitos conduz à criação de um conjunto de histórias de usuários.

V. O ciclo de vida é baseado em três fases: pre-game phase, game-phase, post-game phase.

VI. Tem como único artefato de projeto os cartões CRC.

VII. Realiza reuniões diárias de acompanhamento de aproximadamente 15 minutos.

VIII. Define seis marcos durante o projeto e a implementação de uma funcionalidade: walkthroughs do projeto, projeto, inspeção do projeto, codificação, inspeção de código e progressão para construção.

IX. Os requisitos são descritos em um documento chamado backlog e são ordenados por prioridade.

A relação correta entre o modelo de processo ágil e a prática/característica é:

Alternativas
Comentários
  • Referente ao item V, o manual oficial do scrum não fala sobre este tal ciclo de vida em três fases, porém pesquisando encontrei o seguinte artigo http://dc471.4shared.com/doc/vVNfxCWW/preview.html que mostra que a afirmação está correta

  • IV. A atividade de levantamento de requisitos conduz à criação de um conjunto de histórias de usuários.

    Essa não é a definição de product backlog do scrum (o conjunto de histórias do usuários)? 

    Os itens II,V,VII e IX são definitivamente scrum, mas para mim o IV também. Se alguém puder tirar a dúvida fico grato.

  • "Unlike XP, Scrum does not make specific suggestions on how to write requirements, test-first development, etc. However, these XP practices can be used if the team thinks they are appropriate."

    (Fonte: Livro Engenharia de software, 9 ed, pag 74)

    Então Kaio, o Scrum não diz como você escreve seus requisitos. Você poderia escrever na forma de história do usuário, caso de uso, texto etc. Por outro lado, escrever requisitos na forma de histórias é listada como uma das práticas primárias do XP. (http://desenvolvimentoagil.com.br/xp/praticas/historias)

  • Sobre o item V, encontrei essa explicação: http://www.scrummethodology.org/scrum-phases.html

  • Questão meio mal elaborada. Bastava saber que o item II é do Scrum e matava a questão.

  • b

    palavras-chave que definem cada uma das metodlogias:

    XP - pair programming, testes escritos antes do codigo

    scrum - backlog (requisitos do cliente), sprints (ciclos), scrum team (product owner, equipe desenvolvimento, scrum master).

    fdd - features, 2 semanas, planejamento,cronograma, monitoramento, implementação por features.

  • Robson Gomes, na vdd bastava saber o item  I 

  • Questão pra tirar tempo do candidato. Se souber a I já mata.

  • Questão só pra assustar, só precisa ler 3 palavras

ID
931360
Banca
CESPE / CEBRASPE
Órgão
SERPRO
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Julgue os itens a seguir, referentes aos modelos de ciclo de vida de software e aos processos de desenvolvimento de software.

Cada seqüência de etapas de um ciclo de vida aderente ao modelo cascata é equivalente a uma iteração em um processo embasado no XP (eXtreme Programming).

Alternativas
Comentários

  • Já que ninguém comentou, farei um breve comentário.


    XP utiliza desenvolvimento incremental jovens.


    #Paz

ID
931366
Banca
CESPE / CEBRASPE
Órgão
SERPRO
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Julgue os itens a seguir, referentes aos modelos de ciclo de vida de software e aos processos de desenvolvimento de software.

Metodologias ágeis, como a XP, enfatizam a documentação de software no próprio código, que deve ser escrito por meio de ferramentas CASE voltadas ao desenvolvimento rápido de aplicações (RAD tools).

Alternativas
Comentários

  • que deve ser escrito por meio de ferramentas CASE. Quem escreve o código é o desenvolvedor. Item ERRADO.

ID
933700
Banca
CESPE / CEBRASPE
Órgão
SERPRO
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Julgue os itens a seguir, referentes aos modelos de ciclo de vida de
software e aos processos de desenvolvimento de software.

Cada seqüência de etapas de um ciclo de vida aderente ao modelo cascata é equivalente a uma iteração em um processo embasado no XP (eXtreme Programming).

Alternativas
ID
979618
Banca
IADES
Órgão
EBSERH
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

Existem no mercado algumas metodologias de desenvolvimento, que facilitam o processo de produção de software. Uma dessas metodologias é o XP (Extreme Programming), o qual tem um cuidado especial com os processos de teste de software. Como é feito o processo de teste de software, utilizando o XP?

Alternativas
Comentários
  • O XP o cliente/ usuário tem a liberação de pequenas versões(small Releases) funcionais do projeto auxilia muito na avaliação do cliente. Que por sua vez avalia uma parte do software que esta comprando 

  • Para mim o conceito relacionado à teste no XP é TDD.
    Os testes são feitos ANTES da implementação do código, portanto a questão mais adequada seria a 'e': durante a concepção

  • a) Todos os testes são efetuados, ao fim do desenvolvimento pois, assim, o usuário pode ter uma visão ampla dosoftware.

    Alternativa errada. Os testes são efetuados durante todo o ciclo de vida, não só no final do desenvolvimento.


    b) As etapas de teste são suprimidas do processo

    Alternativa errada, muito pelo contrário, os testes são valorizados e não suprimidos.


    c) Ao final de cada etapa, o usuário é convidado a testar o módulo pronto, evitando, assim, erros muito complexos, ao final do desenvolvimento.

    Alternativa correta. A cada entrega o usuário é convidado a testar o produto construído a fim de identificar precocemente problemas que poderiam ficar mais graves ao final do projeto.


    d) O processo é efetuado, apenas por profissionais que trabalharam no desenvolvimento do produto, tornando assim, o teste mais eficaz e próximo da realidade do cliente.

    Alternativa errada. O usuário final também testa o software.


    e) Todos os testes são realizados na etapa de concepção dosoftware.

    Alternativa errada. Os testes são efetuados durante todo o ciclo de vida


  • a questão deveria informar qual o teste - do cliente ou antes da codificação.....como não falou nada a letra E tb está correta.

  • Respondi letra E pensando apenas no teste de aceitação (realizado na fase planejamento). Existe também os testes: unitário (realizado na fase codificação) e aceitação do cliente (realizado na fase teste).

  • O que invalida a alternativa E, é essa palavra "Todos", ou seja, nem todos os teste são feitos na concepção. Na verdade os teste são feitos em todo o ciclo de vida..

  • Essa letra C é a mais certa, mas estranhei esse "o usuário é convidado apara o modulo pronto". Pois o cliente está sempre presente , sempre acompanhando a equipe de desenvolvimento

  • a) E. Primeiro se testa, antes de desenvolver a funcionalidade.

    b) E. Ao contrário, ao longo do processo, vão sendo feitos testes para averiguar a qualidade do produto, isso é uma boa prática.

    c) C. 

    d) E. Se o testes são feito, por exemplo, pelos programadores, não há tanta eficiência quanto um cliente deixar [quem entende 100% o domínio do negócio é o cliente].

    e) E. Vide item b.

ID
984637
Banca
CESPE / CEBRASPE
Órgão
MPOG
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

No que se refere às metodologias ágeis, julgue os próximos itens.


A metodologia XP diferencia-se das outras metodologias com abordagem incremental e com o feedback constante.

Alternativas
Comentários
  • Que questão bizarra essa. Eu passei meia hora lendo pra tentar entender o que o examinador quis dizer. Acredito que ele pegou o texto em inglês e colocou no google translate e em seguida botou na prova.

    A metodologia XP diferencia-se das outras metodologias (que outras metodologias????) com abordagem incremental (xp é incremental ou é diferente de outras abordagens incrementais???) e com o feedback constante (xp faz feedback constante ou as outras possuem e ele não???).

  • Pelo amor de Deus.. Preciso de comentários sobre essa questão...

  • Deveria ser: A metodologia XP diferencia-se das outras metodologias, com abordagem incremental e com o feedback constante.

  • Entre as principais diferenças da XP em relação às Metodologias Clássicas estão o feedback constante, a abordagem incremental e o encorajamento da comunicação entre as pessoas.


  • Questão bizarramente mal escrita, pelo amor de Deus!


    Como se só o XP tivesse essas características, enquanto as demais metodologias não. O SCRUM também é uma metodologia ágil, incremental e com feedback constante. E aí?

  • Dentre as principais diferenças da XP em relação às outras metodologias estão:

    ·Feedback constante

    ·Abordagem incremental

    ·A comunicação entre as pessoas é encorajada.

    O primeiro projeto a usar XP foi o C3, da Chrysler que após anos de fracasso utilizando metodologias tradicionais, com o uso da XP o projeto ficou pronto em pouco mais de um ano.



    Leia mais em: Processos Ágeis para desenvolvimento de Software – Parte 02 http://www.devmedia.com.br/processos-ageis-para-desenvolvimento-de-software-parte-02/9209#ixzz3iXJz04Il

  • Tudo bem Humberto Sousa, porém, a questão dá a entender que a XP diferencia-se das outras metodologias com abordagem incremental e com o feedback constante. Ou seja eu posso interpretar que a XP não possui abordagem incremental e com feedback constante, como existem nas outras metodologias que a possuem. Acredito que faltou uma vírgula nesta questão: A metodologia XP diferencia-se das outras metodologias,(VÍRGULA ou DOIS PONTOS) com abordagem incremental e com o feedback constante.

  • Questão mais de interpretação. Na realidade qualquer metodologia incremental vai ter algum aspecto que é diferente.

  • Examinador que fez essa questão deveria fazer vários cursinhos de português. CESPE, zero para seu examinador!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

  • Deboas fingindo que essa questão não existiu

ID
984676
Banca
CESPE / CEBRASPE
Órgão
MPOG
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

Com relação às metodologias ágeis de desenvolvimento, julgue os itens a seguir.


O Scrum diferencia-se do XP pela existência do papel de product owner (PO), tendo o Scrum master e o coach atribuições similares em uma equipe ágil de desenvolvimento.

Alternativas
Comentários

  • Embora em uma primeira vista pareçam similares, os papéis de SM e COACH são bem diferentes. O Scrum Master é um cara mais focado em disseminar o processo Scrum, facilitando o acontecimentos de seus eventos, removendo impedimentos, etc. Ele não é um cara técnico, de mão na massa, na verdade é interessante que ele tenha as chamadas soft skills, que estão mais voltadas para relações interpessoais.

    O Coach do XP já se diferencia do SM por ser um cara mais técnico. Ele também vai ajudar o time na implantação do método ágil, porém ele pode sugerir mudanças, melhorias e inclusive pôr a mão na massa se for necessário. Diferente do SM, o coach é uma espécie de líder técnico da equipe.

  • Coach:

    Responsável pelas questõestécnicas do projeto de software. O coach deve possuir grande conhecimento emtodas as fases do XP e conhecer bem os membros da equipe. É o responsável porestimular a equipe a dar o melhor sempre que possível. Ao conhecer e aplicar osconceitos de XP, o coach deve estar apto para sinalizar a sua equipe os erros cometidosao longo do projeto e dar os passos necessários para consertá-los.

    Scrum Master:

    É o responsável porproteger os membros da equipe de desenvolvimento de qualquer pressão ou ameaçaexterna, seja isto clientes esbravejantes, diretores da empresa insatisfeitosou qualquer outra coisa que seja considerado “perigoso” para a produtividade daequipe. Tenta garantir que todas as práticas do Scrum sejam utilizadas com perfeiçãopela equipe. Assim como também tem um papel de facilitador nas reuniões daSprint. Normalmente assumem esse papel os gerentes de projeto ou líder técnico,mas na prática pode ser assumido por qualquer um com experiência o suficientena metodologia.


  • XP = O cliente é o maior interessado no software que esta sendo desenvolvido, além de ser a fonte de informações que a equipe precisa para desenvolver a melhor solução. Por isso, a sua presença junto ao desenvolvimento é muito importante afinal, o objetivo do projeto é que o sistema realmente o atenda.

    product owner (PO) também pode ser o cliente.

    Marquei (E) devido " O Scrum diferencia-se do XP "

ID
1029796
Banca
CESPE / CEBRASPE
Órgão
TCE-RO
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

Com relação às metodologias ágeis de desenvolvimento, julgue os itens subsequentes.

No método XP (eXtreming programming), os sistemas são concebidos a partir de uma metáfora e descritos em estórias do usuário. Esse método busca facilitar a comunicação com o cliente, entendendo a realidade deste e guiando o desenvolvimento com o uso de estória simples.

Alternativas
Comentários
  • Correto. Essa é uma prática do XP chamada Metáfora, que é uma história que todos - programadores, clientes e gerentes - podem contar acerca de como funciona o sistema. Facilita a comunicação entre os interessados.

  • Entendo que está incorreta, porque estão invertidas as ideias. Na verdade, o sistema é construído a partir de estórias do usuário e descritos por metáforas.

  • Mozart, não é assim não. Vc pode fazer uma metáfora do seu sistema com outro sistema (não necessariamente de software). Estórias de usuário são montadas e o sistema é produzido em cima delas. Nas estórias de usuário é que vc coloca o que vc quer para o sistema. Exemplos de estórias de usuário: "Como cliente, eu preciso de adicionar itens no carrinho para poder fechar a compra.". Daí, a partir dela, vc implementa a funcionalidade.

  • Para agregar aos comentários já citados, uma fonte, assim fica melhor e paramos com o achismo hehe

    http://www.desenvolvimentoagil.com.br/xp/praticas/metafora

    http://www.desenvolvimentoagil.com.br/xp/praticas/historias

ID
1042582
Banca
CESPE / CEBRASPE
Órgão
MPU
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

Em relação às abordagens de desenvolvimento de software, julgue os próximos itens.

XP é um método de desenvolvimento de software em que os requisitos são especificados em user stories; requisitos, arquitetura e design surgem durante o curso do projeto; e o desenvolvimento ocorre de maneira incremental

Alternativas
Comentários

  • XP - Trata-se de uma metodologia ágil desenvolvendo software com requisitos vagos e em constante mudança.

    Práticas XP

    Planejamento incremental - Requisitos são registrados para serem incluídos em interações.


  • XP é um método de desenvolvimento de software em que os requisitos são especificados em user stories; requisitos, arquitetura e design surgem durante o curso do projeto; não intendi essa parte, por isso errei a questão. alguém explica?

  • Caro colega Dyogo,

    A questão deve ser dividida por partes para ser melhor compreendida, pois existem 3 assertivas na mesma questão:1. XP é um método de desenvolvimento de software em que os requisitos são especificados em user stories; - Item correto. Os requisitos no XP normalmente são transformados em estórias de usuários, para melhor compreensão e entendimento do requisito vagamente elicitado.2. requisitos, arquitetura e design surgem durante o curso do projeto;- Item correto. De fato, como o XP é uma metodologia ágil e sua abordagem não é orientada a processos, ou seja, não segue uma rigorosa ordem de produção para entrega de software funcional. Dessa forma, é natural que os requisitos, arquitetura e design surjam durante o curso do projeto, pois há interação constante com o cliente conforme se amadurece o projeto e o produto.3. e o desenvolvimento ocorre de maneira incremental.
    - Assertiva correta. O desenvolvimento de entregas (partes funcionais) existentes no XP segue o princípio da abordagem incremental de desenvolvimento. Portanto, o desenvolvimento de software nesse rol ocorre de maneira incremental, ainda que de forma iterativa.

  • Pra mim existe uma diferença entre método e metodologia, por isso marquei como errada.

  • Há um erro aí. User stories não apresentam requisitos, e sim uma descrição informal de uma feature.

ID
1055818
Banca
CESPE / CEBRASPE
Órgão
STF
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

Com referência a aspectos diversos de engenharia de software, julgue os itens subsecutivos.

XP (Extreme Programming) é uma metodologia ágil voltada para equipes pequenas e médias que desenvolvam software baseado em requisitos vagos e se caracteriza por possibilitar modificações rápidas.

Alternativas
Comentários

  • A Extreme Programming (XP) é uma metodologia ágil para equipes pequenas e médias que desenvolvem software baseado em requisitos vagos e que se modificam rapidamente.

    Dentre as principais diferenças da XP em relação às outras metodologias estão:

    ·  Feedback constante

    ·  Abordagem incremental

    ·  A comunicação entre as pessoas é encorajada.

    A XP enfatiza o desenvolvimento rápido do projeto e visa garantir a satisfação do cliente,além de favorecer o cumprimento das estimativas. As regras, práticas e valores da XP proporcionam um agradável ambiente de desenvolvimento de software para os seus seguidores, que são conduzidos por quatro valores: comunicação, simplicidade, feedback e coragem.


    Beck, K., “Programação Extrema Explicada” , Bookman, (1999)

  • Requisitos vagos?

  • Requisitos vagos?

  • Visto que vários colegas estranharam a questão do termo VAGO, vejamos:

    No dicionário vago significa:

    Inconstante, instável, volúvel: vagas imagens surgem no sonho.
    Falto de certeza, de precisão; impreciso, incerto: promessas vagas.
    Que não se distingue bem; indefinido, confuso: lembranças vagas; sons vagos.

    Fonte: http://www.dicio.com.br/vago/

    Sim prezados, os requisitos são vagos, pois não são bem definidos como no modelo de desenvolvimento em cascata, onde só inicia-se outras fases quando a fase atual, no caso, de requisitos está concluída. As metodologias ágeis baseiam-se na mudança constante dos requisitos, levando em consideração que a mudança é uma oportunidade de entregar valor ao cliente em vez de ser uma ameaça ao desenvolvimento.

    Observe um trecho dos princípios do manifesto ágil:

    Mudanças nos requisitos são bem-vindas,
    mesmo tardiamente no desenvolvimento.
    Processos ágeis tiram vantagem das
    mudanças visando vantagem competitiva para o cliente. 

    Fonte: http://agilemanifesto.org/iso/ptbr/principles.html

    Bons estudos.

  • sim, requisitos vagos!

     

    vc não precisa especificar toooodo o sistema para sair codando!

     

    vai codando e de forma iterativa vai entregando valor

  • Pessoal, o termo vagos, ficou realmente meio vago, rs. Porém, a metodologia XP foi escrita para pequenas e medias equipes de produção. 

    Resposta: Certo

ID
1095994
Banca
CAIP-IMES
Órgão
Câmara Municipal de São Caetano do Sul - SP
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

Considere as afirmações abaixo.

I - Os princípios do SCRUM são consistentes com o manifesto ágil e são usados para orientar as atividades de desenvolvimento dentro de um processo que incorpora as seguintes atividades estruturais: requisitos, análise, projeto, evolução e entrega. Em cada atividade metodológica, ocorrem tarefas a realizar dentro de um padrão de processo chamado sprint.

II - A Extreme Programming – XP emprega uma abordagem orientada a objetos como seu paradigma de desenvolvimento preferido e envolve um conjunto de regras e práticas constantes no contexto de quatro atividades metodológicas: planejamento, projeto, codificação e testes.

Pode-se afirmar que:

Alternativas
Comentários

  • I - Os princípios do SCRUM são consistentes com o manifesto ágil e são usados para orientar as atividades de desenvolvimento dentro de um processo que incorpora as seguintes atividades estruturais: requisitos, análise, projeto, evolução e entrega. Em cada atividade metodológica, ocorrem tarefas a realizar dentro de um padrão de processo chamado sprint.

    Sprint não é uma medida de período? Alguém me explica porque esse item está correto?)

  • A I está certa porque é um copia e cola do Pressman: "Os princípios do Scrum são consistentes com o manifesto ágil e são usados para orientar as atividades de desenvolvimento dentro de um processo que incorpora as seguintes atividades estruturais: requisitos, análise, projeto, evolução e entrega. Em cada atividade metodológica, ocorrem tarefas a realizar dentro de um padrão de processo chamados sprint. O trabalho realizado dentro da sprint (o número de sprints necessários para cada atividade metodológica varia dependendo do tamanho e da complexidade do produto) é adaptado ao problema em questão e definido, e muitas vezes modificado em tempo real, pela equipe Scrum."

    (Fonte: Livro Engenharia de Software, 7ed, Pressman, pag 95)

    Gabarito Letra "D".

  • Leia: Página 88 (Pressmann 7º Edição) e Página 95 (Pressman 7º Edição) e corra para o abraço.

ID
1110295
Banca
IPAD
Órgão
IPEM-PE
Ano
2014
Provas
Disciplina
Engenharia de Software
Assuntos

A metodologia XP (Extreme Programing) é considerada uma metodologia ágil, pois se ajusta bem a pequenas ou médias equipes de desenvolvimento de software, em que projetos são produzidos em base de requisitos vagos que se modificam rapidamente. O XP possui algumas características bem marcantes que são Feedback constante, abordagem incremental, e o encorajamento a comunicação entre as pessoas envolvidas. O XP também apresenta quatro valores que devem ser seguidos a risca, assinale a alternativa que apresenta esses valores:

Alternativas
Comentários

  • Segundo Pressman, livro de Engenharia de Software 7 ed uma abordagem profissional cap 3 Desenvolvimento Agil pg 87

    Cinco valores que estabelecem as bases para todo o trabalho realizado como parte da xp

    1 - Comunicação

    2 - Simplicidade

    3 - FeedBack (Realimentação ou retorno)

    4 - Coragem

    5 - Respeito


  • As alternativas B e C estão corretas. Questão deve/deveria ser anulada.


    http://www.extremeprogramming.org/values.html

  • Valores do XP:

     

    Comunicação: Quanto maior a capacidade de compreensão, maiores as chances de evitar problemas como ambiguidades, entendimento equivocados, entre outros. Diálogos são mais eficazes que videoconferências, que são melhores que telefonemas, que são mais expressivos que emails e assim sucessivamente. Conscientes disso, aqueles que trabalham com XP priorizam o uso do diálogo presencial, com o objetivo de garantir que todas as partes envolvidas em um projeto tenham a chance de se compreender da melhor maneira possível.

    Coragem: Costuma-se dizer que a única constante em um projeto de software é a mudança. Clientes mudam de ideia com frequência, mesmo quando fecham contratos nos quais, teoricamente, assumem o compromisso de não alterar o que está na especificação. Eles mudam porque aprendem durante o projeto e descobrem problemas mais prioritários a serem solucionados ou formas mais apropriadas de resolvê-los. Embora isso seja natural, gera uma preocupação para a equipe de desenvolvimento que, de tempos em tempos, precisa alterar partes do sistema que já estavam prontas, correndo o risco de se quebrar o que já vinha funcionando.

    Feedback: Normalmente, quanto mais cedo descobrimos um problema, menos prejuízos ele pode causar e maiores são as chances de resolvê-lo de forma barata. Por isso, projetos XP estabelecem formas de encurtar ao máximo a defasagem de tempo entre o momento em que uma ação é executada e o seu resultado é observado.

    Respeito: Respeito é um valor que dá sustentação a todos os demais. Membros de uma equipe só irão se preocupar em comunicar-se melhor, por exemplo, se se importarem uns com os outros. Respeito é o mais básico de todos os valores. Se ele não existir em um projeto, não há nada que possa salvá-lo. Saber ouvir, saber compreender e respeitar o ponto de vista do outro é essencial para que um projeto de software seja bem sucedido.

    Simplicidade: O XP utiliza o conceito de simplicidade em inúmeros aspectos do projeto para assegurar que a equipe se concentre em fazer, primeiro, apenas aquilo que é claramente necessário e evite fazer o que poderia vir a ser necessário, mas ainda não se provou essencial.

ID
1110298
Banca
IPAD
Órgão
IPEM-PE
Ano
2014
Provas
Disciplina
Engenharia de Software
Assuntos

Assim como os valores, existe na XP um conjunto de boas práticas a serem seguidas com o objetivo de garantir um ciclo de desenvolvimento fortemente dependente. Essas práticas são expressas por atitudes que devem ser seguidas pela equipe de desenvolvimento, e somadas aos valores. Assinale a alternativa que não representa uma dessas práticas:

Alternativas
Comentários
  • No XP, o desenvolvimento é Guiado por Testes, enquanto que, por exemplo, no RUP, o desenvolvimento é guiado por Casos de Uso.


    Logo, a alternativa C está incorreta.


    Metodologias Ágeis - Engenharia de Software sob Medida (Sbrocco & Macedo, 1ª Edição, 2012)

  • Não conhecia essa reunião de 20 min em pé.

ID
1112887
Banca
FCC
Órgão
AL-PE
Ano
2014
Provas
Disciplina
Engenharia de Software
Assuntos

O principal objetivo da XP é dar agilidade ao desenvolvimento do projeto, buscando garantir a satisfação do cliente. As práticas, regras e os valores da XP garantem um agradável ambiente de desenvolvimento de software para os seus seguidores, que são conduzidos por estes 4 norteadores básicos:

Alternativas
Comentários

  • Comunicação

    Coragem

    Feedback

    Respeito

    Simplicidade

    http://desenvolvimentoagil.com.br/xp/valores/

  • Alternativa A é a correta! Os 5 valores do XP, com suas características está listados abaixo:

    1. Comunicação: a comunicação não é limitada por procedimentos formais. Usa-se o melhor meio possível, que pode ser:

     -Uma conversa ou reunião informal.

     -Um e-mail, um bate-papo, um telefonema.

     -Diagramas, se necessário (pode, mas não precisa, ser UML).

     -O próprio código.

     -"Estórias" elaboradas pelo usuário-final.

    2. Simplicidade: a solução adotada deve ser sempre a mais simples que alcance os objetivos esperados:

     -Use as tecnologias, design, algoritmos e técnicas mais simples que permitirão atender aos requisitos do usuário-final.

     -Design, processo e código podem ser simplificados a qualquer momento.

     -Qualquer design, processo ou código criado pensando em iterações futuras deve ser descartado.

    3. Feedback: várias práticas do XP garantem um rápido feedback sobre várias etapas/partes do processo:

     -Feedback sobre qualidade do código (testes de unidade, programação em pares, posse coletiva).

     -Feedback sobre estado do desenvolvimento (estórias do usuário-final, integração contínua, jogo do planejamento).

    4. Coragem: testes, integração contínua, programação em pares e outras práticas do XP aumentam a confiança do programador e ajudam-no a ter coragem para melhorar o design de código que está funcionando para torná-lo mais simples:

     -jogar fora código desnecessário.

     -investir tempo no desenvolvimento de testes.

     -mexer no design em estágio avançado do projeto.

     -pedir ajuda aos que sabem mais.

     -dizer ao cliente que um requisito não vai ser implementado no prazo prometido.

     -abandonar processos formais e fazer design e documentação em forma de código.

    5. Respeito: ao seguir cada um dos valores anteriores a equipe ágil inculta respeito:

    -entre seus membros;

    -entre outros envolvidos e membros da equipe;

    -com o software;

    -pelo processo XP, conforme conseguem entregar com sucesso incrementos de software.

    Bons estudos!




  • Letra A – A questão pede os 4 básicos, apesar de serem 5, a mesma não é invalidada. 

     

    Valores da XP 

    Os cinco valores com suas características: 

    1 - Comunicação 

    Estreita e informal colaboração com todos os envolvidos (desenvolvedores e clientes) com estabelecimento de metáforas para solidificar conceitos importantes e evitar documentação volumosa 

    2 - Simplicidade 

    Projetar apenas necessidades imediatas e mais simples possível 

    3 - Feedback 

    Provém de 3 fontes (sw, cliente e membros da equipe). Ademais: 

    4 - Coragem 

    Disciplina e coragem para projetar hoje e não no futuro incerto 

    5 - Respeito 

     

     

    Fonte:  

    Livro: Engenharia de SOFTWARE 

    Autor: Roger S. Pressman 

    Editora: AMGH Editora LTDA 

    Edição: 7ª - 2011 

    Capítulo: 3 

ID
1112890
Banca
FCC
Órgão
AL-PE
Ano
2014
Provas
Disciplina
Engenharia de Software
Assuntos

Considere:

O código do projeto pertence a todos os membros da equipe. Isto significa que qualquer pessoa que percebe que pode adicionar valor ao código, mesmo que ele próprio não o tenha desenvolvido, pode fazê-lo, desde que faça os testes necessários e não prejudique as funcionalidades atuais. Isto é possível porque todos são responsáveis pelo software. Caso um membro da equipe deixe o projeto antes do fim, a equipe consegue continuar o projeto sem grandes dificuldades, pois todos conhecem todas as partes do software, mesmo que não seja de forma detalhada.

Esta prática é

Alternativas
Comentários

  • Em um projeto XP, 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. Ou seja, a propriedade do código é coletiva e todos são igualmente responsáveis por todas as partes. Com isso, os desenvolvedores ganham tempo, pois não precisam esperar a autorização de um colega para editar uma área do código e há maior disseminação de conhecimento. Além disso, quando diversas pessoas têm a chance de olhar uma mesma área do código, torna-se mais freqüente a identificação de oportunidades de melhoria, levando freqüentemente à refatoração em áreas que precisam da mesma.

    http://desenvolvimentoagil.com.br/xp/praticas/codigo_coletivo

  • Princípios por trás do manifesto ágil

    Nós seguimos os seguintes princípios:

    • -Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor.
    • -Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas.
    • -Entregar software funcionando com freqüencia, na escala de semanas até meses, com preferência aos períodos mais curtos.
    • -Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diáriamente, durante todo o curso do projeto.
    • -Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho.
    • -O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara.
    • -Software funcional é a medida primária de progresso.
    • -Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes.
    • -Contínua atenção à excelência técnica e bom design, aumenta a agilidade.
    • -Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.
    • -As melhores arquiteturas, requisitos e designs emergem de times auto-organizáveis.
    • -Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo.

  • Proriedade coletiva e programação em par.

ID
1112893
Banca
FCC
Órgão
AL-PE
Ano
2014
Provas
Disciplina
Engenharia de Software
Assuntos

Scrum e XP são duas metodologias ágeis que provêm práticas e regras que apresentam diferenças e também pontos em comum. Comparando-se estas metodologias, é correto afirmar:

Alternativas
Comentários

  • ERRADO em negrito   a) A XP enfatiza a proximidade física do cliente com a equipe de desenvolvimento para facilitar a comunicação. No Scrum existem diversos eventos formais, tais como sprint backlog meeting e product backlog review, que incentivam a comunicação entre todos os profissionais envolvidos no projeto.   Sprint review meeting    sprint planning meeting retrospective meeting   daily meeting
    ERRADO em negrito  b) As duas metodologias utilizam iterações curtas de desenvolvimento (sprints), mas divergem no tempo de duração das mesmas. Enquanto no Scrum uma sprint dura de 15 minutos a 8 horas, na XP costuma durar de 1 a 24 horas.
    Errado c) Tanto o Scrum quanto a XP explicitamente não permitem que ocorram mudanças de escopo ou definição dentro de uma sprint. Por isso o cliente deve validar todos os requisitos no início do projeto, isso vai contribuir para evitar atrasos e até mesmo construções erradas.   No SCRUm eh possivle renegocias escop durante a sprint
    CORRETA  d) A XP enfatiza que não se deve fazer horas extras constantemente e, se isso ocorrer, existem problemas no projeto que devem ser resolvidos não com aumento de horas, mas com melhor planejamento. O Scrum enfatiza que equipes auto- organizáveis escolhem qual a melhor forma para completarem seu trabalho.
    Errado em negrito e) O Scrum estabelece que os testes devem ocorrer o tempo todo durante o desenvolvimento, principalmente usando técnicas automatizadas. Na XP os testes podem ser realizados apenas na parte final de cada sprint, usando a técnica de refatoração, que busca validar todas as funcionalidades, pensando estrategicamente em como refatorar o código que está sendo implementado. refatorar eh otimizacao de codigo. os desenvolvedores fazem  continuamente testes unitarios e depois tem os testes de aceitação, desenvolvidos pelo cliente 

  • Na letra E não ocorreu troca de conceitos entre XP e Scrum?

ID
1143502
Banca
VUNESP
Órgão
DCTA
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

No modelo de desenvolvimento XP (Extreme Programming) há uma atividade na qual os usuários descrevem as funcionalidades que o software deverá possuir. Essa descrição recebe a denominação de

Alternativas
Comentários

  • Storycards ("histórias de usuário"): cartões escritos pelos usuários, com a descrição das funcionalidades do sistema.

  • Que se encontra na atividade de Planejamento

ID
1151542
Banca
INSTITUTO AOCP
Órgão
Colégio Pedro II
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

Extreme Programming (XP) é um dos mais conhecidos métodos ágeis de desenvolvimento de software. Assinale a alternativa correta sobre este método.

Alternativas
Comentários

  • Gabarito D

    Extreme Programming (XP) é uma metodologia de desenvolvimento de software, nascida nos Estados Unidos ao final da década de 90. Vem fazendo sucesso em diversos países, por ajudar a criar sistemas de melhor qualidade, que são produzidos em menos tempo e de forma mais econômica que o habitual. Tais objetivos são alcançados através de um pequeno conjunto devalores, princípios e práticas, que diferem substancialmente da forma tradicional de se desenvolver software.

    Manifesto Ágil

    Indivíduos e interações entre eles mais que processos e ferramentas;

    Software em funcionamento mais que documentação abrangente;

    Colaboração com o cliente mais que negociação de contratos;

    Responder a mudanças mais que seguir um plano.

     

    "Retroceder Nunca Render-se Jamais !"
    Força e Fé !
    Fortuna Audaces Sequitur !     

ID
1153873
Banca
INSTITUTO AOCP
Órgão
UFGD
Ano
2014
Provas
Disciplina
Engenharia de Software
Assuntos

Assinale a alternativa que NÃO apresenta uma prática da Programação Extrema (Extreme Programming).

Alternativas
Comentários
  • São Pequenos Releases.  Você vai desenvolver pequenos releases do sistema e entregar ao cliente para ele testar e dar feedback dando confiança a ele sobre o progresso do sistema

  • e)Grandes Releases.

    As iterações sao de 1 a 3 semanas com um artefato no final de cada ciclo obedenco um dos valores do xp - simplicidade

ID
1175971
Banca
CESPE / CEBRASPE
Órgão
TC-DF
Ano
2014
Provas
Disciplina
Engenharia de Software
Assuntos

Acerca das metodologias de desenvolvimento de software, julgue os itens subsecutivos.

Uma das características do método XP é o uso de um modo de desenvolvimento orientado a testes frequentes, o que garante a entrega de uma única versão do sistema inteiro, testado e validado.

Alternativas
Comentários

  • a ideia é justamente fazer entregas parciais e incrementais

  • XP é uma metodologia Ágil. Ágil é iterativo e incremental, logo possue entregas parciais e não apenas um release. 

ID
1178011
Banca
CESGRANRIO
Órgão
Banco da Amazônia
Ano
2014
Provas
Disciplina
Engenharia de Software
Assuntos

Uma prática que NÃO é adotada por Extreme Programming (XP) é

Alternativas
Comentários

  • Marquei a A pois a questão fala que uma dupla de programadores produz TODO o código do sistema...quando na verdade produzem uma parte, e se o código é grande?

    Já a letra E, acontece isto mesmo: as iterações vão mudando de duração para atender aos requisitos e prioridades mutáveis dos clientes.

  •  e) variar a duração de cada iteração durante todo o projeto para acomodar eventuais mudanças de prioridade dos requisitos, definidas pelo cliente.

    A duração das iterações (1 a 3 semanas) não altera, somente a quantidade de vezes que elas sao executadas.

    http://www.extremeprogramming.org/rules/iterationplanning.html

  • Mario caí nessa pegadinha também, mas lendo de novo notei que a questao não fala "todo o código do SISTEMA" e sim "todo o código que será enviado para produção"

    O XP é iterativo e incremental. O que será enviado para produção é um incremento do software.

ID
1225498
Banca
FCC
Órgão
MPE-CE
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

O modelo de processo ágil Extreme Programming (XP) envolve um conjunto de regras e práticas que constam no contexto de diversas atividades metodológicas. A atividade metodológica na qual se estabelece um guia de implementação para uma história de usuário à medida que é escrita, em que se encoraja o uso de cartões CRC como um mecanismo eficaz para pensar sobre o software em um contexto orientado a objetos é conhecida como

Alternativas
Comentários

  • Quando li "estabelece um guia de implementação" deu pra matar a questão. A atividade que gera isso é o Projeto.

  • Cartões CRC(class-responsability-collaboration) são uma ferramenta de brainstorming utilizada no projeto de software orientado a objeto. Essa técnica é recomendada pelos apoiadores do XP (extreme programming). Fonte: http://en.wikipedia.org/wiki/Class-responsibility-collaboration_card

  • Projeto é um dos processos envolvidos no ciclo de vida de desenvolvimento da metodologia XP:


    - oferece um guia de implementação para uma história a medida que é escrita

    - utilização de cartões CRC(classe-responsabilidade-colaborador); identificam e organizam as classes orientadas a objetos relevantes para o incremento de software corrente;

    Fonte: http://www.itnerante.com.br/profiles/blogs/extreme-programming-xp

  •  

    Letra B - Projeto 

     

    O  Processo XP 

    Emprega uma abordagem orientada a objetos e envolve um conjunto de regras e práticas constantes no contexto de quatro atividades metodológicas:

    1 – Planejamento 

    Jogo do Planejamento, se inicia com ouvir que conduz a criação de um conjunto de histórias (similar ao caso de uso) pelo próprio cliente. Cada história é colocada em uma ficha (CRC), o cliente atribui um valor e os membros da equipe atribui um custo medido em semanas de desenvolvimento, pode ter até 3 semanas, caso tenha mais a história tem que ser quebrada e reavaliada. Clientes e desenvolvedores decidem como agrupar as histórias para a versão seguinte (incremento). As histórias podem ser ordenadas de 3 formas: 

    Depois da primeira versão (também denominada incremento de sw) ser entregue pela equipe XP, é calculada a velocidade do projeto. Conforme o trabalho de desenvolvimento prossegue, o cliente pode acrescentar histórias, alterar ou eliminar outras. 

    2 – Projeto 

    Segue o princípio KIS (keep is simple, ou seja, preserve a simplicidade). Encorada o uso de cartões CRC (classe-responsabilidade-colaborador), CRC é o único artefato. Se uma história estiver traumática para ser construída, é feito um protótipo operacional (solução pontual). Encoraja a refatoração, Fowler diz: "Refabricação é o processo de alteração de um sistema de software de tal forma que não se altere o comportamento externo do código, mas se aprimore a estrutura interna. É uma forma disciplinada de organizar código [e modificar/simplificar o projeto interno] que minimiza as chances de introdução de bugs. Em resumo, ao se refabricar, se está aperfeiçoando o projeto de codificação depois de este ter sido feito." 

    3 – Codificação 

    Etapas: 

    4 – Testes 

    Teste de unidade deve ser automatizado encorajando uma estratégia de teste de regressão. (TDD) Testes de unidades individuais são organizados em um "conjunto de testes universal". Teste de aceitação ou teste de cliente, é especificado pelo próprio cliente obtidos de histórias de usuários 

     

     

     

    Fonte:  

    Livro: Engenharia de SOFTWARE 

    Autor: Roger S. Pressman 

    Editora: AMGH Editora LTDA 

    Edição: 7ª - 2011 

    Capítulo: 3 

ID
1282984
Banca
CESPE / CEBRASPE
Órgão
ANCINE
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

Acerca do Scrum e do XP (eXtreme Programming), julgue o item .


Na reunião de planejamento do sprint backlog, se o product owner afirmar que todos os requisitos do produto foram identificados, é correto concluir que o backlog do produto está completo, visto que este é uma lista ordenada de todos os requisitos necessários para o desenvolvimento do produto.

Alternativas
Comentários

  • Conforme o Scrum Guide - Scrum.org 10/2011


    "

    Um Backlog do Produto nunca está completo. Os primeiros desenvolvimentos apenas estabelecem os requisitos inicialmente conhecidos e melhor entendidos. O Backlog do Produto evolui tanto quanto o produto e o ambiente no qual ele será utilizado evoluem. O Backlog do Produto é dinâmico; mudando constantemente para identificar o que o produto necessita para ser mais apropriado, competitivo e útil. O Backlog do Produto existirá enquanto o produto também existir. 

    "


  • Lembre-se sempre: o Product Backlog é um documento VIVO! Isto é, está em constante mutação e existirá enquanto o produto exitir!


    Bons estudos!

  • Assertiva ERRADA. 


    O backlog nunca está completo pois, embora definidos todos os requisitos na reunião inicial, durante o desenvolvimento podem surgir requisitos novos ou os antigos podem precisar ser alterados. Sendo assim, ele nunca chega ao estado de "pronto". 

  • Pessoal, se eu tiver um produto, implementei TODOS os requisitos levantados, validei o produto com o cliente, NÃO foi visto nenhuma alteração, mesmo assim, o product backlog não estará completo? Não tem mais nada para fazer.

    *claro que é uma situação hipotética, mas a afirmação que NUNCA estará pronto, acho muito forte.

    valeu

  • Focado na missão, na teoria, teoria e prática são a mesma coisa, na prática não.

    Olhando friamente para o guia scrum, vimos que o backlog do produto é um artefato vivo. Os requisitos nunca são estáticos.

    ✅ Gabarito - E

ID
1282990
Banca
CESPE / CEBRASPE
Órgão
ANCINE
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

Acerca do Scrum e do XP (eXtreme Programming), julgue o  item.  

No desenvolvimento de software conforme as diretivas do TDD (test-driven development), deve-se elaborar primeiramente os testes e, em seguida, escrever o código necessário para passar pelos testes.

Alternativas
Comentários

  • Ciclo de Desenvolvimento do TDD:

    1 Adicione um teste

    2 Execute todos os testes e veja se algum deles falha

    3 Escrever código

    4 Execute os testes automatizados e veja-os executarem com sucesso

    5 Refatorar código6 Repita tudo

  • Assertiva CORRETA. 


    No TDD os testes são escritos assim que se conhece um requisito. Conhecendo um requisito é possível saber como o software deve se comportar e assim se torna possível criar um teste que verifique se o software está se comportando como desejado. Por fim, escreve-se o código que tem como objetivo passar nesse teste. 

  • Test Driven Development (TDD) ou em português Desenvolvimento guiado por testes é uma técnica de  que se relaciona com o conceito de  e se baseia em um ciclo curto de repetições: Primeiramente o desenvolvedor escreve um  automatizado que define uma melhoria desejada ou uma nova funcionalidade. Então, é produzido código que possa ser validado pelo teste !!

    Primeiro : conceito de  e se baseia em um ciclo curto de repetições: Primeiramente o desenvolvedor escreve um  automatizado

    Depois escreve o código..

    Não seria (E) ????

ID
1305085
Banca
CESPE / CEBRASPE
Órgão
ANATEL
Ano
2014
Provas
Disciplina
Engenharia de Software
Assuntos

Julgue os itens subsecutivos, a respeito das metodologias, dos processos e das práticas ágeis de desenvolvimento de software. Nesse sentido, considere que a sigla XP, sempre que empregada, refere-se a programação extrema.

No XP, o projeto é uma atividade-chave que ocorre antes de a codificação começar e se prolonga até depois de escrito o programa.

Alternativas
Comentários

  • Cespe sendo Cespe. Atividade chave ? Nunca ouvir falar...

  • Então tá, né...

  • Atividades chaves: planejamento -> projeto -> codificação -> testes ( Pressman 8° edição, página 72)
ID
1305088
Banca
CESPE / CEBRASPE
Órgão
ANATEL
Ano
2014
Provas
Disciplina
Engenharia de Software
Assuntos

Julgue os itens subsecutivos, a respeito das metodologias, dos processos e das práticas ágeis de desenvolvimento de software. Nesse sentido, considere que a sigla XP, sempre que empregada, refere-se a programação extrema.

Uma vez que o SCRUM não estabelece a programação em pares nem o desenvolvimento teste-primeiro (test-first), o XP pode ser usado em conjunto com o SCRUM em um projeto com a abordagem ágil.

Alternativas
Comentários

  • certinho, essas técnicas são pregadas pelo XP

  • Correto.


    O XP pode atuar bem em conjunto com o Scrum, pois quando o Scrum atuar com foco no gerenciamento do projeto, o XP pode atuar no processo de desenvolvimento.


  • a alternativa é correta, pois tanto XP quanto SCRUM são FRAMEWORKS DE BOAS PRÁTICAS (assim como o PMBOK) e não metodologias de desenvolvimento. Logo, pode-se elaborar uma metodologia que utilize práticas de ambos os frameworks. 

  • Confundi com o desenvolvimento em pares. É o XP 

  • Assertiva CORRETA. 


    XP foca na parte técnica do desenvolvimento e o SCRUM foca na parte gerencial, podendo ser usados para complementarem um ao outro. Como programação em pares e os testes são partes técnicas, o XP é quem lida com isso. 

  • c-

    programacao a 2 e tests antes sao tipicos do xp. o scrum usa pequenas equipes e funciona com sprints (iteracoes)

ID
1305097
Banca
CESPE / CEBRASPE
Órgão
ANATEL
Ano
2014
Provas
Disciplina
Engenharia de Software
Assuntos

Julgue os itens subsecutivos, a respeito das metodologias, dos processos e das práticas ágeis de desenvolvimento de software. Nesse sentido, considere que a sigla XP, sempre que empregada, refere-se a programação extrema.

No contexto de um processo ágil, tal como o XP, é necessária a criação dos casos de usos da linguagem de modelagem unificada (UML) depois da modelagem das histórias de usuários.

Alternativas
Comentários

  • não é necessário não, faz um rabisco no papel, manda brasa nos testes automatizados e vc tem um software

  • Metodologia ágil para equipes pequenas e médias desenvolvendo software com requisitos vagos e em constante mudança.


  • Não existe esse tipo de exigência. Caso houvesse, o SCRUM seria um processo como o UP, que utiliza UML. 

  • Não é necessário - se quiser, faça. Tem que ter cuidados com essas palavras: necessário, obrigatório, deve...

  • XP - documentação mínima.

  • XP e SCRUM são desapegados de tecnologia.

  • "A verdade está no Código" - Uso intenso de comentários em código padronizado e conhecido por toda equipe. Como requisito, tem-se as histórias dos usuários.

  • Posterior a criação das histórias vem a divisão delas em tarefas através do artefato 'Sprint Backlog', que são testados e desenvolvidos. Quando falamos em SCRUM as histórias de usuários substituem os casos de uso. Alguém concorda ou não?

  • Não é necessária que seja feito depois, pois pode ser feito concomitante, à medida que as Users Stories são escritas.

  • linda

ID
1305100
Banca
CESPE / CEBRASPE
Órgão
ANATEL
Ano
2014
Provas
Disciplina
Engenharia de Software
Assuntos

Julgue os itens subsecutivos, a respeito das metodologias, dos processos e das práticas ágeis de desenvolvimento de software. Nesse sentido, considere que a sigla XP, sempre que empregada, refere-se a programação extrema.

No XP, as mudanças são antecipadas e o software é projetado para facilmente acolher essas mudanças.

Alternativas
Comentários

  • não entendi essa.. alguém? ²

  • Dentre as variáveis de controle em projetos (custo, tempo, qualidade e escopo), há um foco explícito em escopo. Para isso, recomenda-se a priorização de funcionalidades que representem maior valor possível para o negócio. Desta forma, caso seja necessário a diminuição de escopo, as funcionalidades menos valiosas serão adiadas ou canceladas.

    • Jogo de Planejamento (Planning Game): O desenvolvimento é feito em iterações semanais. No início da semana, desenvolvedores e cliente reúnem-se para priorizar as funcionalidades. Essa reunião recebe o nome de Jogo do Planejamento. Nela, o cliente identifica prioridades e os desenvolvedores as estimam. O cliente é essencial neste processo e assim ele fica sabendo o que está acontecendo e o que vai acontecer no projeto. Como o escopo é reavaliado semanalmente, o projeto é regido por um contrato de escopo negociável, que difere significativamente das formas tradicionais de contratação de projetos de software. Ao final de cada semana, o cliente recebe novas funcionalidades, completamente testadas e prontas para serem postas em produção.
    http://pt.wikipedia.org/wiki/Programa%C3%A7%C3%A3o_extrema

    Então, serão antecipadas mudanças a partir das que agregam mais valor. Dizer que todas serão antecipadas é loucura, no XP há priorização para o que vai ser trabalhado em cada semana.


  • As mudanças não são antecipadas. Reage-se a elas.

  • boa andré.. concordo

  • Um preceito fundamental da engenharia de software tradicional é que você deve projetar para a mudança. Ou seja. você
    deve antecipar mudanças futuras para o software e projetá-lo dc tal maneira que essas mudanças possam ser implementadas
    facilmente.

    A extreme programming, contudo, descarta esse princípio alegando que projetar para a mudança é, geralmente, um esforço inútil. As mudanças antecipadas muitas vezes não ocorrem e as solicitações de mudança realizadas são completamente diferentes.

    O problema com a implementação de mudanças não antecipadas á que elas tendem a degradar a estrutura do software,
    fazendo com que as mudanças tomem-se cada vez mais difíceis dc implementar. A extreme programming lida com este
    problema defendendo que o software deve passar por refactoring constantemente. Isso significa que a equipe de programação procura por possíveis melhorias no software, implementando-as imediatamente. Portanto, o software deve sempre scr fácil de compreender e alterar quando novas histórias são implementadas

    Sommerville, Engenharia de Software 8ª ed., pág 265

  • sempre erro essa merda

  • As mudanças NÃO são antecipadas. Reage-se a elas. (2)

  • Não erremos mais, pessoal.

     

    Vida que segue.........

     

    MANIFESTO ÁGIL

     

    → indivíduos e interações do que técnicas e ferramentas

    → software em funcionamento do que documentação abrangente

    → colaboração com o cliente  do que negociação de contrato

    → respostas a mudanças do que seguir com o plano

  • Em relação a mudanças, o XP não é preventivo, mas sim reagente. 

     

    Implementar um software direcionado a mundanças requer esforço, que o XP considera desnecessário. O XP tem sua manuntenção de código por refactoring. 

  • evitar trabalho especulativo

ID
1306588
Banca
CESPE / CEBRASPE
Órgão
ANATEL
Ano
2014
Provas
Disciplina
Engenharia de Software
Assuntos

Acerca dos processos de desenvolvimento de software, julgue o item subsequente.


A etapa de planejamento do Extreme Programming (XP) inicia-se com a escrita de UserStories (história do usuário). Por meio dessa ferramenta, aqueles que conhecem a técnica de construção de uma solução poderão guiar quem necessita dessa solução no exercício de descrevê-la de forma simples e concisa.

Alternativas
Comentários

  • User stories are one of the primary development artifacts for Scrum and Extreme Programming (XP) project teams

  • Traduzindo (livremente) o que o Cleodenis colou ali em baixo: " Histórias de Usuários são um dos principais artefatos de desenvolvimento para equipes de projeto que utilizem Scrum e XP (programação extrema)."

  • Anteriormente, neste livro, ao falar sobre Extreme Programming, já mencionei User Stories, ferramenta que envolve o cliente e o fornecedor/desenvolvedor na descrição da solução. Mike Cohn, autor da clássica apresentação sobre Scrum, que traduzi para o português, é também o autor de um dos melhores livros sobre User Stories: User Stories applied. Resumindo ao extremo, as User Stories permitem aqueles que conhecem a técnica da construção de uma solução (linguagem de programação,ferramentas, bases de dados) guiar quem necessita dessa solução no exercício de descrevê-la de forma simples e concisa.

     

    Fonte: Cesar Brod , Scrum Guia Prático para Projetos Ágeis – 2ª ed, pag. 70

  • Se é análise de requisitos, e feito pelo cliente...não vejo como uma técnica de construção pode influenciar neste momento...o cliente diz o que quer e pronto...a não ser que estejamos já refinando a User Storie, o que não é dito na questão.

  • A questão cobra conhecimento sobre o processo de desenvolvimento de software do Extreme Programming (XP).

    Conforme Pressman, as atividades-chave, em ciclo iterativo e incremental, do processo XP são:

    1. Planejamento;

    2.  Projeto:

    3. Codificação: e

    4. Teste.

    O Planejamento “engloba a criação de um conjunto de histórias de usuários que descreve o resultado, as características e a funcionalidade requisitados para o software a ser construído. Nesse sentido, clientes e desenvolvedores trabalham juntos para decidir como agrupar histórias para a versão seguinte, conforme alguns passos detalhados abaixo.


    1. Cada história é escrita pelo cliente e é colocada em uma ficha.


    2. O cliente atribui um valor (uma prioridade) à história baseando-se no valor de negócio global do recurso ou função.


    3. Os membros da equipe XP avaliam então cada história e atribuem um custo (medido em semanas de desenvolvimento)." [1]


    Assim, o planejamento do XP inicia-se com a escrita da história de usuário pelo cliente e não há empecilho para que os desenvolvedores auxiliem o cliente nessa atividade, até que ele entenda como usar a ferramenta.


    Gabarito da professora: CERTO.



    Referência:

    [1] Engenharia de software: uma abordagem profissional, Roger S. Pressman; tradução Ariovaldo Griesi ; revisão técnica Reginaldo Arakaki, Julio Arakaki, Renato Manzan de Andrade. – 7. ed. – Dados eletrônicos. – Porto Alegre : AMGH, 2011, com alterações pela professora.

ID
1309777
Banca
CESPE / CEBRASPE
Órgão
ANTAQ
Ano
2014
Provas
Disciplina
Engenharia de Software
Assuntos

Julgue o item a seguir, com base nos processos e nas práticas ágeis de desenvolvimento de software.


No XP (Extreme Programming), todos os desenvolvedores da equipe devem possuir autorização para modificar, consertar ou refatorar partes do sistema.

Alternativas
Comentários

  • Collective Code Ownership - A equipe como um todo é responsável por cada arquivo de código. Não é preciso pedir autorização para alterar qualquer arquivo.

    fonte - http://www.univasf.edu.br/~ricardo.aramos/disciplinas/ESI2009_2/Aula13_14_DesenvolvimentoAgil.pdf

  • chama-se propriedade coletiva de código

  • Questão correta.

    No xp todos são proprietários do código. Logo, qualquer membro da equipe tem autorização para alterar o sistema.

  • Segundo SummerVille "Os pares de desenvolvedores trabalham em todas as áreas do sistema, de tal maneira que não se formem ilhas de conhecimento, com todos os desenvolvedores de posse de todo o código. Qualquer um pode mudar qualquer coisa." 

  • Só achei estranho a parte "devem possuir autorização". Esta frase pode ser interpretada como se os devs dependessem da autorização de alguém pra poder modificar o código.

  • Onde que diz que no XP é necessário possuir autorização para fazer alguma modificação no código? Depois de ter visto tanta questão do cespe cheguei a uma conclusão: "se quer estudar pra outro concurso, então não estude pelas questões do cespe". Esses caras acham que são donos do conhecimento! Tem questão que não tem sentido desses caras! Essa questão tá errada!

  • Qualquer membro da equipe pode fazer alterações no código, mas do jeito que a questão está escrita dá a entender que é necessário pedir autorização antes...

  • Ráááááá!!! Pegadinha do Malandrooooo!!!! Se você ler rápido e ler "pedir" ao invés de "possuir" é glu glu ye yééééé !!!

  • Como já foi comentado, o enunciado da questão dá a entender que os desenvolvedores precisam ser autorizados antes de fazer alterações, o que pode fazer o candidato pensar que a afirmação está errada.

ID
1340221
Banca
CESPE / CEBRASPE
Órgão
BACEN
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

Julgue o   item  subsequente, no que se refere aos processos de desenvolvimento de software.

As principais características do Extreme Programming são a divisão em equipes de até 7 pessoas, duração de uma iteração de quatro semanas e distribuição de equipes.

Alternativas
Comentários

  • Equipes de até 12 programadores. E cada iteração terá duração de 1 a 3 semanas. Caso esta informação esteja errada, por favor comente.

    Fonte: http://www.cin.ufpe.br/~gamr/FAFICA/Desenvolvimento%20de%20sistemas/XP.pdf

  • Extreme Programming Explained (Kent Beck, 1999):

    "XP is designed to work with projects that can be built by teams of two to ten programmers, that aren't sharply constrained by the existing computing environment, and where a reasonable job of executing tests can be done in a fraction of a day"

    "Schedule slips—XP calls for short release cycles, a few months at most, so the scope of any slip is limited. Within a release, XP uses one- to four-week iterations of customer-requested features for fine-grained feedback about progress. Within an iteration, XP plans with one- to three-day tasks, so the team can solve problems even during an iteration. Finally, XP calls for implementing the highest priority features first, so any features that slip past the release will be of lower value."


ID
1356106
Banca
Quadrix
Órgão
COBRA Tecnologia S/A (BB)
Ano
2014
Provas
Disciplina
Engenharia de Software
Assuntos

Documentos de requisitos são essenciais quando se está desenvolvendo o sistema de software. Entretanto, os métodos ágeis de desenvolvimento argumentam que os requisitos mudam tão rapidamente que o documento de requisitos já estará ultrapassado assim que terminar de ser escrito. Em vez de um documento formal, abordagens como Extreme Programming (XP) coletam os requisitos de usuário de forma incrementai e escrevem-nos em cartões na forma de:

Alternativas
Comentários

  • Estórias de Usuários - ptbr, User Story inglês usa. Dentro da metodologia ágil Scrum, são definições em um documento de como será o comportamento de um requisito ao ser transformado em software propriamente dito. É nessa etapa que podem ser usadas prototipações, por exemplo para demonstrar ao cliente como seria o comportamento final do software, antes mesmo que se tenha código fonte desenvolvido e com isso uma eventual mudança nos requisitos teria um custo muito inferior se fosse entregado ao cliente o software já em execução.

  • Prezados,

    O artefato previso no XP para representar as necessidades do usuário é o cartão de estórias de usuário.

    Portanto a alternativa correta é a letra C


  • Muito bom, Letra de lei, acompanho seus comentários há um tempo, meus parabéns, se possível acredito que ficaria melhor seus comentários sem essas cores, deixasse só o negrito estaria bacana, uma dica, valeu

ID
1356130
Banca
Quadrix
Órgão
COBRA Tecnologia S/A (BB)
Ano
2014
Provas
Disciplina
Engenharia de Software
Assuntos

O modelo ágil Extreme Programming (XP) segue uma série de práticas que dizem respeito ao relacionamento com o cliente, a gerência do projeto, a programação e aos testes. NAO é uma dessas práticas:

Alternativas
Comentários
  • Product backlog é do Scrum.

    Letra E,
  • Prezados,

    O product backlog é um artefato previsto no SCRUM e não no XP , o product backlog é uma lista contendo todas as funcionalidades desejadas para um produto.

    Portanto a alternativa correta é a letra E


  • O que é "jogo do planejamento"?

  • Sávio é o mesmo que Game Phasing Plan. É uma fase do Scrum em que você planeja uma sprint.

    Dá uma lida nesse documento aqui: http://homepages.dcc.ufmg.br/~figueiredo/disciplinas/aulas/metodo-agil-scrum-fases_v01.pdf

  • 'jaco freire',

     

    Obrigado.