SóProvas



Questões de RUP (Rational Unified Process) - Processo Unificado Rational


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

Assinale a opção que NÃO apresenta uma disciplina do RUP.

Alternativas
Comentários
  • Elaboração é uma fase, juntamente com Iniciação ou Concepção, Construção e Transição.

    As disciplinas são:
    - Modelagem de Negócios
    - Requisitos
    - Análise e Design
    - Implementação
    - Testes
    - Implantação
    - Gerência de Configuração e Mudança
    - Gerência do Projeto
    - Ambiente
  •  c)Elaboração.

    Elaboração é a fase depois do concepção e antes de construção & transição.

    As disciplinas sao:

    engenharia: modelagem negocio, requirimentos, analise & design, implementação, teste & deployment.

    suporte: administração de config. & mudança, gerenciamento de projeto, ambiente.

    Na duvida, é so lembrar que as disciplinas de suporte se relacionam a tópicos comuns em governança em TI e engenharia sao processos de produção de software. 


ID
5431
Banca
CESGRANRIO
Órgão
Petrobras
Ano
2006
Provas
Disciplina
Engenharia de Software
Assuntos

Um gerente de projeto decidiu utilizar o Processo Unificado (RUP - rational unified process) como seu processo de desenvolvimento de software. Com base no RUP, quais os objetivos que o gerente deve direcionar para a fase de Elaboração?

Alternativas
Comentários
  • Não entendi esta questão. Se alguém entendeu me mande uma mensagem.
  • a) ERRADA. Pois produzir documento visão acontece na fase de Iniciaçãob) ERRADA. Pois produzir documento visão acontece na fase de Iniciação.c) CORRETA.d) ERRADA. Design de BD e Releases são na fase de Transiçãoe) ERRADA. Detalhar atores é papel do Analista de Negócio.A meta da fase de elaboração é criar a baseline para a arquitetura do sistema a fim de fornecer uma base estável para o esforço da fase de construção. A arquitetura se desenvolve a partir de um exame dos requisitos mais significativos (aqueles que têm grande impacto na arquitetura do sistema) e de uma avaliação de risco. A estabilidade da arquitetura é avaliada através de um ou mais protótipos de arquitetura.- Atividades básicas . Definir, validar e criar a baseline da arquitetura com rapidez e eficiência. . Refinar a Visão, com base nas informações novas obtidas durante a fase, estabelecendo uma compreensão sólida dos casos de uso mais críticos que conduzem as decisões de arquitetura e planejamento. . Criar planos de iteração detalhados e baselines para a fase de construção. . Refinar o caso de desenvolvimento e posicionar o ambiente de desenvolvimento, incluindo o processo, as ferramentas e o suporte de automatização necessários para dar assistência à equipe de construção. . Refinar a arquitetura e selecionar componentes. Os componentes potenciais são avaliados e as decisões de fazer/comprar/reutilizar são bem compreendidas para determinar o custo da fase de construção e programar com confiança. Os componentes de arquitetura selecionados são integrados e avaliados em comparação com os cenários básicos.obs: . Baseline: um release revisado e aprovado de artefatos que constitui uma base ajustada para desenvolvimento ou evolução posterior e que só pode ser alterado através de um procedimento formal . Artefato: pode ser um modelo, uma descrição ou um software. Sinônimo: produto.
  • Ricardo,
    Produzir Documento Visão completo e estável está ambiguo. A fase de iniciacao elabora um documento de visao INICIAL. Na fase de elaboracao REFINA o documento de visao. Ou seja, produz um documento de visao estavel/completo (podemos dizer....). Questao dificil!!!!
  • Fazer o design dos casos de uso críticos; obter um entendimento mais detalhado dos requerimentos; implementar e testar cenários críticos. 

    A fase de Elaboração tem alguma características e a principal é criar uma linha de base da arquitetura que será usada na fase de Construção. Mas temos outras características, tais como:

    1 - Criar um protótipo evolutivo dos componentes de qualidade do projeto.
    2 - Criar protótipos que exercitem as características de maior risco. São protótipos descartáveis. (implementar e testar cenários críticos)
    3 - O documento de visão é refinado. Com isso, há um maior entendimento dos requisitos.      
    4 - Elaborar arquiteturas derivadas dos cenários críticos.

    Casos de uso críticos para a arquitetura é o meu entendimento.
  • Realmente Marcelo, dificil mesmo...pois contrariou alguns conceitos, acho que caberia um belo recurso essa questão!!
  • Pessoal, não cabe nenhum recurso nesta questão. Basta vocês verem os "objetivos principais" da fase ELABORAÇÃO que vocês matam a resposta

    vejam o RUP 7:
    ========================================================
    Os objetivos principais da fase Elaboração incluem:
    • Assegurar que a arquitetura, os requisitos e os planos sejam estáveis o suficiente e que os riscos sejam suficientemente diminuídos a fim de determinar com segurança o custo e a programação para a conclusão do desenvolvimento. Para a maioria dos projetos, ultrapassar essa marca também corresponde à transição de uma operação rápida e de baixo risco para uma operação de alto custo e alto risco com uma inércia organizacional freqüente.
    • Tratar todos os riscos significativos do ponto de vista da arquitetura do projeto.
    • Estabelecer uma arquitetura de baseline derivada do tratamento dos cenários significativos do ponto de vista da arquitetura, que normalmente expõem os maiores riscos técnicos do projeto.
    • Produzir um protótipo evolutivo dos componentes de qualidade de produção, assim como um ou mais protótipos de pesquisa, descartáveis, para diminuir riscos específicos como:
      • trocas de design/requisitos
      • reutilização de componentes
      • possibilidade de produção do produto ou demonstrações para investidores, clientes e usuários finais
    • Demonstrar que a arquitetura de baseline suportará os requisitos do sistema a um custo justo e em tempo justo.
    • Estabelecer um ambiente de suporte.
    Para atingir esses objetivos básicos, é também importante configurar o ambiente de suporte para o projeto. Isso inclui adaptar o processo para o projeto, preparar gabaritos, diretrizes e configurar ferramentas. "
    ========================================================

    tividades Essenciais

    As atividades essenciais da fase Elaboração incluem:

    • Definir, validar e criar a baseline da arquitetura, com rapidez e praticidade.
    • Refinar a Visão, com base nas informações novas obtidas durante a fase, estabelecendo uma compreensão sólida dos casos de uso mais críticos que conduzem as decisões de arquitetura e planejamento.
    • Criar planos de iteração detalhados de baselines para a fase de construção.
    • Refinar o processo de desenvolvimento e posicionar o ambiente de desenvolvimento, incluindo o processo, as ferramentas e o suporte de automação necessário para dar assistência à equipe de construção.
    • Refinar a arquitetura e selecionar componentes. Os componentes potenciais são avaliados e as decisões de fazer/comprar/reutilizar são bem compreendidas para determinar o custo da fase de construção e programar com confiança. Os componentes de arquitetura selecionados são integrados e avaliados em comparação com os cenários básicos. As lições aprendidas dessas atividades podem resultar em um novo design da arquitetura, levando em consideração designs alternativos ou reconsiderando os requisitos.
  • Tambem nao acertei, mas pesquisando olhaí o que obtive:
    a)
    Produzir Documento Visão completo e estável; *
    detalhar os atores e casos de uso chave; - INICIAÇÃO
    determinar pelo menos uma solução possível para o problema. - INICIAÇÃO
     
    b)
    Produzir Documento Visão completo e estável; *
    fazer o design dos casos de uso críticos; ELABORAÇÃO
    obter um entendimento mais detalhado dos requerimentos. ELABORAÇÃO
     
    c)
    Fazer o design dos casos de uso críticos; ELABORAÇÃO
    obter um entendimento mais detalhado dos requerimentos; - ELABORAÇÃO
    implementar e testar cenários críticos. ELABORAÇÃO
     
    d)
    Fazer o design do Banco de Dados; - CONSTRUÇÃO
    implementar e testar cenários críticos; ELABORAÇÃO
    liberar uma versão beta do produto. - TRANSIÇÃO
     
    e)
    Detalhar os atores e casos de uso chave; - INICIAÇÃO
    fazer o design, implementação, validação e estabelecer uma
    linha de base para a arquitetura;
    - ELABORAÇÃO
    determinar pelo menos uma solução possível para o problema. - INICIAÇÃO

    Aí é o pedaço que achei complicado...
    Se o gabarito é letra C e os outros dois itens da letra B estão também na C, o errado tem que ser o "Produzir Documento Visão completo e estável".

    1)
    Aí é que tá, estabilizar o Documento de Visão é realmente um dos objetivos típicos da fase de Elaboração.
    Apesar disso, o Visão é alterado durante todo o projeto. O erro então só pode estar no termo "completo", que passaria a noção de "nada mais a fazer aqui", o que não é a verdade.
    2)
    Mais uma vez, na fase de Elaboração o Visão não é "produzido", e sim refinado.


    É minha opinião... Mas é realmente complicada a questão, apesar desses 2 pontos, tem bancas que entortam tanto conceitos que a presença desses "completo" e "produzir" aí não seria nem de longe justificativa suficiente pra invalidar o item -- se eles assim o quisessem, é claro. Mas... como eles quiseram invalidá-lo (podem dizer também que o item C é "mais certo" O_O)... paciência.
  • Os objetivos principais da fase de iniciação incluem:

    • Estabelecer o escopo do software do projeto e as condições limite, incluindo uma visão operacional, critérios de aceitação e o que deve ou não estar no produto.
    • Discriminar os casos de uso críticos do sistema, os principais cenários de operação e o que direcionará as principais trocas de design.
    • Exibir, e talvez demonstrar, pelo menos uma opção de arquitetura para alguns cenários básicos.
    • Estimar o custo geral e a programação para o projeto inteiro (e estimativas detalhadas para a fase de elaboração imediatamente a seguir).
    • Estimar riscos em potencial (as origens de imprevistos) (consulte Conceitos: Risco ).
    • Preparar o ambiente de suporte para o projeto.
    •  
  • Acho que a grande confusão em torno desta questão está na hora de diferenciar artefatos de objetivos.

    Pode-se ver que o documento de visão não consta como um dos objetivos.

    É, portanto, uma questão literal.

  • c)
    entre os artefatos de fase elaboração estao: use case model, requerimentos suplementares, plano de desenvolvimento, descrição de arquitetura de software


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
27280
Banca
FCC
Órgão
TRE-SE
Ano
2007
Provas
Disciplina
Engenharia de Software
Assuntos

Considere as afirmativas abaixo.

I. O RUP é um processo iterativo.
II. Sob orientação do RUP, o desenvolvimento é centrado na arquitetura.
III. Sob a orientação do RUP, as atividades de desenvolvimento são orientadas por casos de uso.

É correto o que se afirma em

Alternativas
Comentários
  • I) O Rational unified process - RUP apresenta as chamadas 'boas práticas' que são 6.
    primeira: Uso de Iterações: As iterações tem como objetivo desenvolver projetos incrementais. Ao desenvolver gradativamente os analista podem identificar futuros problemas e modificações, uma vez que passam a conhecer melhor o sistema.

    II)A MAior parte de desevolvimento do RUP se da na fase de ELaboração. Esta fase deselvolve-se principalmente na arquitetura.

    III)O Rup utiliza UML para fazer modelagem visual. Dessa forma, a uml norteia os casos de uso e suas especificações. Os casos de uso são muito importantes no RUP pois são utilizados para fazer grande parte da documentação.
  • Eu iria entrar com recurso nesta questão... O RUP não é só iterativo... também é incremental.
  • Washington, a questão não fala que o RUP é um processo SOMENTE iterativo, apenas diz que ele de fato é iterativo.Não vejo brecha para recurso...
  • Uma imagem vale por 1000 palavras :))

    http://marquera.files.wordpress.com/2009/06/rup_lifecycle.jpg
  •  a)I, II e III.

    RUP é iterativo assim como espiral, DSDM e todos processos agile. RUP tambem é baseado em arquitetura de componentes. 


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

No RUP, a maior quantidade da disciplina Análise e Projeto é encontrada na fase de

Alternativas
Comentários
  • O Rup apresenta 4 fases básicas:
    Iniciação ou concepção, Elaboração, Construção e Transição;

    Iniciação: Fase de abordagem e discussão inicial do problema, são desenvolvidos os casos de uso iniciais, e é feito um plano de projeto, onde é mostrado custos e prazos estimados do projeto.

    Elaboração: Nesta fase há a discussão do domínio do problema em si. O plano de projeto passa a ser desenvolvido, Estebelecer a fundação arquitetural e eliminar os riscos. podendo estes riscos serem de requerimentos tecnologicos.

    Construção: Fase de Modelagem e desenvolvimento. Aqui o sistema é programado efetivamente. O rup é baseado no UML.

    TRansição: Aqui o sistema já está pronto. começa um 'transição' para o cliente. ocorrem lançamentos de versões Beta, operção do novo com o antigo sistema da empresa (legado), treinamento de usúarios...

    acho que basicamente isso.
  • Questão bobinha, mas anulável. Não existe disciplina análise e projeto.
  • Análise e Projeto (ou Desgin)


    Análise = Focado em analisar o negócio.

    Projeto = Focado em desenvolver a arquitetura do projeto de software.

  • e-

     Construção - codigo & testes

    Concepção. - analise dos requisitos

    Transição - Implantação.

    Elaboração. - analise & projeto


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

No RUP, que fase tem como resultado uma baseline da arquitetura?

Alternativas
Comentários
  • Elaboração
    Criar a baseline para a arquitetura do sistema a fim de fornecer uma base estável para o esforço da fase de construção
  • 3. Marcos

    Após a conclusão de cada fase temos um marco. Os marcos são avaliados para terminar se os objetivos da fase foram alcançados. É quando você decide se deve passar ou não para próxima fase. Em relação aos marcos, o mais comum nas provas é que examinador apontar um marco de uma fase como sendo de outra. Portanto, memorize os marcos. São eles:


    Fase ---> Marco


    Concepção ---> Objetivos do Ciclo de vida

    Elaboração ---> Arquitetura do Ciclo de vida

    Construção ---> Capacidade Operacional Inicial

    Transição ---> Release do Produto, também conhecido como: liberação do produto.


    Fonte: http://www.meubizu.com.br/rational-unified-process

    MeuBizu um monstro nos estudos!

  • d-

    baseline -> arquitetura -> ELABORACAO.


ID
28978
Banca
CESGRANRIO
Órgão
CAPES
Ano
2008
Provas
Disciplina
Engenharia de Software
Assuntos

Em que fase do RUP deve ser criada uma arquitetura robusta e confiável?

Alternativas
Comentários
  • A questão mostra algumas alternativas que não são fases (Gerencia de Riscos e Arquitetura e Design), ficando assim com apenas 3 alternaticas: [C] Elaboração: Sim, nessa fase já está definida qual a arquitetura que será utilizado no projeto, uma arquitetura robusta e confiavel. [D] Construção: nessa fase deve-se começar a codificar o projeto, a arquitetura já deve está definida. [E] Concepção: Essa fase, pode-se obter uma opção de arquitetura que poderá ser utilizada, porém não é a escolhida é apenas uma opção.

    Reposta: [C] Elaboração
  • Ao final da fase de Elaboração, tem-se o marco da Arquitetura do Ciclo de Vida. Fui por essa lógica e acertei.


ID
41683
Banca
FCC
Órgão
TRE-PI
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Na fase de Elaboração do processo unificado de desenvolvimento de sistemas é criado e apresentado como resultado da fase, dentre outros, o artefato

Alternativas
Comentários
  • A meta da fase de elaboração é criar a baseline para a arquitetura do sistema a fim de fornecer uma base estável para o esforço da fase de construção. A arquitetura se desenvolve a partir de um exame dos requisitos mais significativos (aqueles que têm grande impacto na arquitetura do sistema) e de uma avaliação de risco. A estabilidade da arquitetura é avaliada através de um ou mais protótipos de arquitetura.http://www.wthreex.com/rup/process/itrwkfls/iwf_iie.htm
  • a) modelo de caso de negócio. O certo seria modelo de caso de uso: é um artefato da fase de construção.b) software integrado na plataforma de hardware. Artefato da fase de construção.c) plano de desenvolvimento do software. Não é um artefato.d) protótipo de arquitetura executável. (correto)e) manual de usuário.O manual desta fase é o preliminar, poderia gerar uma dúvida, mas a opção d seria "a mais correta"
  • Embora não sirva de resposta para esta questão, que cita a ELABORAÇÃO, em vez da Iniciação, o Plano de Desenvolvimento de Software é sim um artefato da disciplina Gerenciamento de Projetos.Ref.: http://www.wthreex.com/rup/portugues/process/artifact/ar_sdp.htm"O Plano de Desenvolvimento de Software é um artefato composto e abrangente que reúne todas as informações necessárias ao gerenciamento do projeto. Ele inclui vários artefatos separados, desenvolvidos durante a Fase de Iniciação, e é mantido durante todo o projeto".
  • Pequeno resumo das fases do RUPConcepção: Avaliação inicial de riscos, modelo de negócio preliminar (ênfase no escopo do sistema)Elaboração: Protótipo arquitetural executável(ênfase na arquitetura)Construção: Modelo de projeto completo(ênfase no desenvolvimento)Transição: Relatório de execuções de testes beta(ênfase na implantação)
  • A meta da fase de elaboração é criar a baseline para a arquitetura do sistema a fim de fornecer uma base estável para o esforço da fase de construção.

    A arquitetura se desenvolve a partir de um exame dos requisitos mais significativos (aqueles que têm grande impacto na arquitetura do sistema) e de uma avaliação de risco. A estabilidade da arquitetura é avaliada através de um ou mais protótipos de arquitetura.

    Fonte: http://www.wthreex.com/rup/portugues/index.htm (Fase de elaboração).


ID
51304
Banca
CESGRANRIO
Órgão
TJ-RO
Ano
2008
Provas
Disciplina
Engenharia de Software
Assuntos

O RUP (Rational Unified Process) é um processo iterativo de desenvolvimento de software, baseado no Processo Unificado. A esse respeito, analise as afirmativas a seguir.

I - Um dos objetivos da fase de Elaboração é a criação e estabilização da arquitetura do sistema.

II - São exemplos de disciplinas do RUP: Modelagem de Negócio, Gestão de Portifólios e Gestão da Documentação Técnica.

III - O principal artefato de requisitos utilizado pelo RUP é a Estória de Usuário (User Story), que serve como um "lembrete" para uma conversa sobre os requisitos entre o desenvolvedor e o cliente.

IV - Um dos princípios do RUP é considerar como medida principal do progresso do projeto o software executável funcionando.

Estão corretas APENAS as afirmativas

Alternativas
Comentários
  • Onde eu acho no RUP esses dois itens (corretos da questão):Gestão de Portifólios e Gestão da Documentação Técnica
  • na verdade os dois itens corretos são esses:I - Um dos objetivos da fase de Elaboração é a criação e estabilização da arquitetura do sistema.IV - Um dos princípios do RUP é considerar como medida principal do progresso do projeto o software executável funcionando. Os itens II e III estão incorretos.
  • Não consegui entender o porque da questão I estar correta, até então eu entendia que a arquitetura do sistema era elaborada da fase de contrução junto com o projeto do sistema. Alguém poderia explicar?
  • Igor, a arquietura é elaborada antes da construção do software. Na fase de elaboração é onde é pensado. planejado, ou seja, arquitetado todo o sistema. Também é identificado e mitigado os principais riscos e definidos prazos e custos. Só após essa etapa, onde tudo foi planejado, é que se começa a construir o sistema. Mesmo assim devemos lembrar que o RUP é evolutivo e iterativo. Na fase de elaboração, essas atividades que citei são as mais focadas.
  • I - CORRETO

    II - INCORRETA - Não encontrei os as disciplinas Gestão de Portifólios e Gestão da Documentação Técnica no RUP.

    III - INCORRETO - O item refere-se ao XP.

    IV - INCORRETO - O item refere-se ao XP.

     

    Alguém pode confirmar se Gestão de Portifólios e Gestão da Documentação Técnica está incluso ou não no RUP?

  • Pois é, cara, também acho que o item IV se aplica ao XP. Não encontrei nenhuma referência sendo feita pelo RUP sobre usar o sw executável como medida de progresso. Se alguém tiver, por favor, me mostre.

    Já o Item 2 é flagrantemente errado, pois as disciplinas são:
    - Modelagem de Negócio
    - Requisitos
    - Análise e Projeto
    - Implementação
    - Testes
    - Implantação
    - Ger. de Configuração e Mudança
    - Ger. de Projeto
    - Ambiente

    Dentre os itens passados, o item B acaba sendo o mais certo pq, quer queira quer não, sw executável funcionando dá pra ser usado como métrica na maioria dos projetos.

    O complicado é dizer que é a "principal" para o RUP.
  • Prezados,

    O item I da questão tem um detalhe a ser analisado. Segundo o RUP, a arquitetura começa a ser construída não na fase de Elaboração e sim na fase de Iniciação. Na fase de Elaboração, a arquitetura é estabilizada, tendo como marco Arquitetura do Ciclo de Vida. Basta analisar o famoso Gráfico das Baleias do RUP. No referido gráfico, temos atividades da disciplina Análise e Design na fase de Iniciação.
    Diante do fato acima, o item I da questão afirma que um dos objetivos da fase de Elaboração é a criação da arquitetura. Portanto, na minha opinião, o item está errado.


  • "IV - Um dos princípios do RUP é considerar como medida principal do progresso do projeto o software executável funcionando. "

    Alguém poderia me explicar pq esta IV está correta? Indiar algum material que tenha isso e por favor me avisar com uma mensagem.


    Desde já, agradeço.

  • A respeito do item IV estar correto: http://www.webopedia.com/TERM/R/RUP.html

ID
51325
Banca
CESGRANRIO
Órgão
TJ-RO
Ano
2008
Provas
Disciplina
Engenharia de Software
Assuntos

Três dos principais artefatos da disciplina Requisitos previstos pelo RUP são:

Alternativas
Comentários
  • Tem certeza que o gabarito está errado? A Letra A para mim está correta, vide http://www.wthreex.com/rup/portugues/process/artifact/ars_req.htm
  • Olá, pessoal!

    A banca manteve a resposta como "A".

    Todos os recursos foram indeferidos.

    Bons estudos!

  • Todas as expressões utilizadas num caso de uso são definidas no glossário do projeto. Se existir alguma expressão num caso de uso que não consta do glossário, essa expressão precisará de:

    * Ser adicionada ao glossário, incluindo uma descrição breve (um parágrafo, no máximo);

    * Ser alterada no caso de uso, de modo a refletir a expressão correta que estiver definida no glossário.

    As expressões que são específicas de um determinado caso de uso podem ser definidas na secção de glossário desse caso de uso. Os itens definidos no glossário são apresentados de forma sublinhada.

     

    Definição de e referência a especificações suplementares. Quando existem requisitos adicionais que não podem ser descritos naturalmente durante o fluxo de eventos, os mesmos são definidos como requisitos suplementares. No caso daqueles que são específicos a um caso de uso, são definidos na secção requisitos especiais da especificação do caso de uso. Os requisitos que são aplicáveis a todo o sistema, especialmente os de natureza não funcional, são definidos no documento separado de especificação suplementar.

     

    O presente conjunto de orientações está organizado em duas secções. A primeira descreve a forma preferencial de modelação de casos de uso. A segunda fornece orientações para o conteúdo do modelo de casos de uso e para a atribuição de nomes aos elementos que constam do modelo.


ID
70285
Banca
FCC
Órgão
TRT - 3ª Região (MG)
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

De acordo com o Processo Unificado (UP), o gerente do projeto já está em condição de planejar as atividades e estimar os recursos necessários para completar o projeto no final da fase de

Alternativas
Comentários
  • A e C não são fases.

    D vem depois que o escopo foi definido.

    Escopo é definido em B e é ele quem aborda atividades e recursos.

  • Temos que lembrar dos marcos das fases:

    CONCEPÇÃO - Objetivos do ciclo de vida (requisitos, plano de desenvolvimento)
    ELABORAÇÃO - Arquitetura do Ciclo de Vida (Transforma os requisitos em PROJETO - define atividades e recursos necessários) - Base estável para construção.
    CONSTRUÇÃO - Capacidade Operacional Inicial (As funcionalidades deste ciclo devem estar desenvolvidas e testadas)
    TRANSIÇÃO - Release do PRODUTO (Disponibiliza o software)


  • A fase de elaboração ....
    No auge da fase de elaboração, o plano é revisado cuidadosamente parasegurar  que escopo, riscos e datas de entrega permaneçam razoáveis.
    ....
    Pressman, pag 73, ed 7
  • O gerente está apto a fazer o planejamento na fase de Concepção. Na fase de elaboração o plano é revisto para ver se continua válido ou se precisa ser ajustado. Está no Pressman.

  • Outra indicação de que esse estudo é realizado na fase de Concepção.

    Descrição do Plano de Desenvolvimento de Software no RUP: O Plano de Desenvolvimento de Software inclui vários artefatos separados, desenvolvidos durante a Fase de Iniciação, eé mantido durante todo o projeto.

    P.S: O Plano de Desenvolvimento de Software no RUP é o equivalente ao Plano do Projeto no PMI.



  • O GP faz o planejamento das atividades no "Plano de Desenvolvimento de Software" ao final da fase de "Elaboração"; segundo o RUP:

    A finalidade do Plano de Desenvolvimento de Software é reunir todas as informações necessárias ao controle do projeto. Ele descreve a abordagem dada ao desenvolvimento do software e é o plano de nível mais alto gerado e usado pelos gerentes para direcionar o esforço de desenvolvimento.

    O Plano de Desenvolvimento de Software é usado por estas pessoas:

    Ocoordenador de projetos, para fazer o planejamento do projeto e das necessidades dos recursos e para acompanhar o progresso em relação ao planejamento.

    Os membros da equipe do projeto, para entenderem o que eles precisam fazer, quando precisam fazê-lo e quais são as outras atividades das quais eles dependem.


    Já a atividade de "estimar os recursos necessários para completar o projeto" é feita através do artefato "Caso de Negócio" que é gerado ao final da fase de  "Elaboração"e tem como objetivo, segundo o RUP:

    A finalidade principal do Caso de Negócios é desenvolver um plano econômico para realizar a visão de projeto apresentada em Produto de Trabalho: Visão. Uma vez desenvolvido, o Caso de Negócio é usado para fazer uma avaliação precisa do ROI (Retorno do Investimento) fornecido pelo projeto. Ele fornece a justificativa para o projeto e estabelece suas restrições econômicas. Ele fornece informações para os tomadores de decisões econômicas sobre o valor do projeto e é usado para determinar se o projeto deve continuar.

    Em marcos críticos, o Caso de Negócio é reexaminado para verificar se as estimativas do retorno e do custo esperados ainda são precisas e se o projeto deve continuar. 

    fonte: http://www.wthreex.com/rup/v711_ptbr/index.htm



ID
70288
Banca
FCC
Órgão
TRT - 3ª Região (MG)
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

No UP, a fase que cobre o período em que o produto fica em versão beta é a de

Alternativas
Comentários
  • UP - Unified Process (Processo Unificado)Na fase de Transição: O objetivo dessa fase é garantir que todos os requisitos do projeto foram atendidos e implementados corretamente. O produto final pode ser liberado em uma versão beta.fonte: http://www.devmedia.com.br/articles/viewcomp.asp?comp=8032
  • A fase de transição é a fase em que iremos implantar o sistema, fazer os ajustes finais (teste beta).

    Todas as demais alternativas são disciplinas, para matar a questão bastaria saber distinguir as fases das disciplinas
  • Construção não é uma disciplina como afirmou o colega abaixo. Temos duas fases na questao: Transicao e Construcao. O restante é disciplina.
  • Fase de Construção - produto em versão alfa - os testes são realizados pelos usuários junto com os desenvolvedores.

    Fase de Transição - produto em versão beta - os testes são realizados pelos usuários em seu ambiente, sem os desenvolvedores

  • Concepção - Avaliação inicial dos riscos

    Elaboração - Protótipo Arquitetural executável

    Construção - Modelo de Projeto Completo e testes alfas

    Transição - Relatório de execução de testes betas


ID
70291
Banca
FCC
Órgão
TRT - 3ª Região (MG)
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

No UP, os casos de uso mais importantes são capturados e delimitam o domínio do sistema durante a fase de

Alternativas
Comentários
  • a) Elaboração  - Definição de arquitetura do sistema 
    b) Requisitos - não é uma fase, e sim uma disciplina
    c) Projeto - não é uma fase, e sim uma disciplina
    d) Análise - não é uma fase, e sim uma disciplina
    e) Concepção - Delimita o escopo do sistema 
  • CONCEPÇÃO - Objetivos do ciclo de vida 
    ELABORAÇÃO - Arquitetura do Ciclo de Vida 
    CONSTRUÇÃO - Capacidade Operacional Inicial
    TRANSIÇÃO - Release do produto 


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

Estereótipos podem ser utilizados para categorizar classes durante a fase de análise em um projeto de desenvolvimento de sistemas orientados a objetos e utilizando-se a notação UML (Unified Modeling Language). No RUP (Rational Unified Process), por exemplo, podem-se confeccionar modelos utilizando-se os seguintes estereótipos:

I - limite (boundary);
II - entidade (entity);
III - controle (control).

Na UML, essas classes podem ser representadas de forma visual, respectivamente, pelos símbolos

Alternativas
Comentários
  • Segundo o livro O Processo unificad explicado - Kendall Scoot. A resposta certa é a alternativa C .
    Ou seja o primeiro circulo é: limite (boundary);
    O segundo: entidade (entity);
    E o último o controle (control).
    Exemplo correto : http://www.uidesign.net/2000/opinion/rup/BCEexample.gif
  • Olhei agora no gabarito da prova (questão 49), LETRA C correta!
  • INDUBTAVELMENTE LETRAA C PESSOAL DO QC!!
  • POxa nao querer ajudar blzMas já atrapalhar é palhaçada heinNao eh C nada isso
  • Ok, pessoal!

    Gabarito corrigido.

    Correto: letra "C".

    Bons estudos!

  • Pessoal,
    o padrão Entity-Control-Boundary (ECB) é uma variação do padrão MVC. Sua notação segue abaixo:

    Fonte: http://www.cs.sjsu.edu/~pearce/modules/patterns/enterprise/ecb/ecb.htm
    B
    ons estudos!

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

Rational unified process (RUP) é um processo de
negócios genérico para engenharia de software orientada a
objetos. Ele descreve uma família de processos de engenharia de
software relacionados que compartilham uma estrutura comum,
uma arquitetura de processos comum. Ele proporciona
abordagem disciplinada para a atribuição de tarefas e de
responsabilidades dentro de uma organização de
desenvolvimento. O processo de engenharia de software é o
processo de desenvolvimento de sistema a partir dos requisitos,
sejam eles novos (ciclo de desenvolvimento inicial), ou alterados
(ciclo de evolução).
Internet: (com adaptações).

Tendo o texto acima como referência inicial, julgue os itens a
seguir.

A criação de baselines no RUP tem como motivação a rastreabilidade, a elaboração de relatórios e a reprodutibilidade, além de estabelecer, na fase de construção, um marco da arquitetura do ciclo de vida do projeto. Com os baselines, é possível desfazer mudanças caso as atualizações realizadas sejam consideradas instáveis ou não confiáveis

Alternativas
Comentários
  • Resposta: ErradaNesta questão quase todas as afirmativas estão corretas, ou seja, é verdade que a criação de baselines no RUP tem como motivação a rastreabilidade, a elaboração de relatórios e a produtibilidade. Também é verdadeiro que com baselines é possível desfazer mudanças caso as atualizações realizadas sejam consideradas instáveis ou não confiáveis. O erro da questão está na afirmativa do meio, que diz que na fase de construção é possível estabelecer um marco da arquitetura do ciclo de vida do projeto. Esta afirmação seria correta se dissesse que "na fase de elaboração é possível estabelecer um marco do ciclo de vida do projeto"- Marco dos Objetivos do Ciclo de Vida (Fase de iniciação)- Marco da Arquitetura do Ciclo de Vida (Fase de Elaboração)- Marco da Capacidade Operacional Inicial (Fase de Construção)- Marco de Release do Produto (Fase de Transição)
  • A criação de baselines no RUP tem como motivação a rastreabilidade, a elaboração de relatórios e a reprodutibilidade, além de estabelecer, na fase de construção, ELABORAÇÃO um marco da arquitetura do ciclo de vida do projeto. Com os baselines, é possível desfazer mudanças caso as atualizações realizadas sejam consideradas instáveis ou não confiáveis

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

Rational unified process (RUP) é um processo de
negócios genérico para engenharia de software orientada a
objetos. Ele descreve uma família de processos de engenharia de
software relacionados que compartilham uma estrutura comum,
uma arquitetura de processos comum. Ele proporciona
abordagem disciplinada para a atribuição de tarefas e de
responsabilidades dentro de uma organização de
desenvolvimento. O processo de engenharia de software é o
processo de desenvolvimento de sistema a partir dos requisitos,
sejam eles novos (ciclo de desenvolvimento inicial), ou alterados
(ciclo de evolução).
Internet: (com adaptações).

Tendo o texto acima como referência inicial, julgue os itens a
seguir.

No RUP, a análise estrutural, parte da análise de requisitos, constitui atividade que inclui decisões acerca de implementação da visão, arquitetura física e lógica e requisitos não funcionais do sistema. Além disso, a análise estrutural tem como finalidade definir as estratégias de reutilização e os padrões de arquitetura do sistema.

Alternativas
Comentários
  • do timaster..

     a questão saiu do livro do Craig Larman citado pelo Marcelo:

    "Análise Arquitetural pode ser vista como uma especialização da análise de
    requisitos, com foco nos requisitos que influenciam a 'arquitetura'.

    A análise arquitetural está preocupada com a identificação e resolução dos
    requisitos *não-funcionais* do sistema (por exemplo, segurança), no contexto
    dos requisitos funcionais (por exemplo, processar vendas)."

    A fonte utilizada então foi o livro do Craig Larman (ah, vá! É mermo? :-D) e
    podemos deduzir que a questão do CESPE que estamos debatendo também pode ter
    seguido esse livro.

    Mas, vendo o material do whtreex.com/rup, Análise Arquitetural está na
    disciplina de Análise e Design e não na de Requisitos (que são duas
    disciplinas diferentes). Para maiores informações da Análise Arquitetural,
    acessem o endereço abaixo:

    http://www.wthreex.com/rup/process/activity/ac_arcan.htm

    Visão geral das atividades da disciplina de Análise e Design:

    http://www.wthreex.com/rup/portugues/process/workflow/ana_desi/wfov_and.htm

    Conclusão:

    Vamos estudar alguns tópicos do RUP utilizando o Craig Larman e sempre
    consultando o site da Wtrheex. Fechado? Sei que é chato ver duas correntes
    diferentes, mas temos que fechar o cerco contra o CESPE.
  • O comando da questão fala em Análise Estruturada, como parte da Análise
    Análise Arquitetural e Análise Estruturada são sinônimos?
  • Chamou análise arquitetural de análise estrutural.
    e leva as pessoas ao erro, pois o RUP não usa análise estruturada, mas sim análise OO.

ID
105604
Banca
FCC
Órgão
DPE-SP
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

No contexto do RUP, considere:

I. Estabelecer o escopo do software do projeto e as condições limite, incluindo uma visão operacional, critérios de aceitação e o que deve ou não estar no produto.

II. Estabelecer uma arquitetura da baseline derivada do tratamento dos cenários significativos do ponto de vista da arquitetura, que normalmente expõem os maiores riscos técnicos do projeto.

Os itens I e II constituem alguns dos objetivos principais incluídos, respectivamente, nas fases de

Alternativas
Comentários
  • Uma das entregas da fase de Elaboração é o Documento de Arquitetura de Software. Isso já mata a questão.ENTREGAS DA FASE DE ELABORACAOProtótipos: são usados de uma maneira direta para reduzir o risco.Lista de Riscos: classificada em ordem decrescente de importância e associada a ações específicas de contingência ou diminuição de riscos.Documento de Arquitetura de Software: fornece uma visão geral de arquitetura abrangente do sistema, usando diversas visões de arquitetura para descrever diferentes aspectos do sistema.Modelo de Projeto: é um modelo de objeto que descreve a realização dos casos de uso e serve como uma abstração do modelo de implementação e seu código-fonte. Modelo de Dados: é um subconjunto do modelo de implementação que descreve a representação lógica e física dos dados persistentes no sistema.
  • A fase de Iniciação é onde é definido o escopo do projeto.
    A fase de Elaboração é definida uma arquitetura estabilizada, os casos de uso de maior risco são implementados.

ID
106063
Banca
FCC
Órgão
PGE-RJ
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

O Processo Unificado se caracteriza por ser um

Alternativas
Comentários
  • Pra resumir...Segundo Kruchten (2001), o Rational Unified Process ou simplesmente RUP, é um modelo de desenvolvimento de software interativo, incremental, orientado a objetos, com foco na criação de uma arquitetura robusta, análise de risco e utilização de casos de uso para o desenvolvimento, desenvolvido pela Rational Software Corporation . O RUP “é um framework de Processos Organizacionais que se usados adequadamente garantem o sucesso da área de engenharia de Software.” , (SAKAMOTO, 2001). Já Kruchten (2001) define o RUP , além de um framework, também, como um processo de engenharia e como um Produto.Fonte: http://tadeujnr.sites.uol.com.br/pcc/txt_metodologia.htmlSucesso a todos!
  •     a) ciclo de desenvolvimento de software em cascata, centrado na arquitetura e guiado pela modelagem de negócio.

        b) ciclo de desenvolvimento de software sequencial com todos os entregáveis produzidos em uma só fase.

        c) processo de software específico para reengenharia, centrado em objetos e orientado a casos de uso.

        d) processo de software iterativo e incremental, centrado na arquitetura e guiado por casos de uso.

        e) processo de software interativo, centrado na temporalidade dos negócios e orientado a eventos.
  • d-

    RUP (rational unified process) é uma metodologia de software incremental e iterativa com 4 fases inception, elaboration, consctruction & elaboration. Todas as fases têm milestones para caracterizar o estagio atual do software e 6 disciplinas de engenharia


ID
106066
Banca
FCC
Órgão
PGE-RJ
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

São dois produtos da fase de Elaboração no Processo Unificado:

Alternativas
Comentários
  • Elaboração Marco: Arquitetura do Ciclo de VidaArtefatos:Documento de Arquitetura de Software:Criado e com baseline, incluindo descrições detalhadas para os casos de uso significativos para a arquitetura (visão de caso de uso), identificação dos mecanismos principais e dos elementos de design (visão lógica), mais a definição da visão de processos e da visão da implantação (do Modelo de Implantação) caso o sistema seja distribuído ou deva lidar com problemas de concorrência.Modelo de Análise:Pode ser desenvolvido como um artefato formal; freqüentemente mantido de forma não formal, evoluindo, em vez disso, para uma versão inicial do Modelo de Design.
  • Fazendo uma associação entre os artefatos e a fase, temos:

    a) o Modelo Inicial de Caso de Uso(Concepção) e o Modelo de Projeto(Elaboração).

    b) o Modelo de Caso de Uso(Elaboração) e o Caso de Teste(Construção).

    c) a Descrição da Arquitetura do Software(Elaboração) e o Modelo de Análise(Elaboração).

    d) o Caso de Negócio Inicial(Concepção) e a Lista de Risco Revisada(Elaboração).

    e) o Modelo de Negócio(Concepção) e o Manual Preliminar do Usuário(Elaboração).

     

    [1] http://www.wthreex.com/rup/portugues/index.htm

  • Caso de teste
    Ocorrência 
    As primeiras sugestões de Casos de Teste podem ser identificadas logo na Fase de Iniciação, sendo identificadas subseqüentemente em cada iteração durante o restante do ciclo de vida do projeto. É normal que os Casos de Teste sejam definidos em detalhes de acordo com o trabalho de implementação programado para eles, geralmente iniciando na primeira iteração, na Fase de Elaboração.

    A meu ver a questão possui duas respostas, e provavelmente ficou sendo a C devido ao caso de teste aparecer em outras fases.

    http://www.wthreex.com/rup/portugues/process/artifact/ar_tstcs.htm
  • Saída das respectivas fases:

    - Concepção:   

       documento de visão do sistema;

       caso de uso simplificados;

        riscos;

    - Elaboração:   

        arquitetura do software;

        casos de uso detalhados;

        planos de construção;

        protótipo de arquitetura executável;

    - Construção:   

        Produto inacabado;   

        modelos de projetos associados ao software;

    - Transição:   

        versão final de qualidade do sistema;

  • c-

    A fase de elabora;'ao [e a fase de preparacao para o codigo e testes. Logo, os modelos devem estar prontos, os requisitos bem requisitos e os diagramas devemn refletir o sistema final.


ID
106069
Banca
FCC
Órgão
PGE-RJ
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

No Processo Unificado, o Plano de Projeto é iniciado

Alternativas
Comentários
  • Plano de Projeto = Plano de Desenvolvimento de SoftwareO Plano de Desenvolvimento de Software é um artefato composto e abrangente que reúne todas as informações necessárias ao gerenciamento do projeto. Ele inclui vários artefatos separados, desenvolvidos durante a Fase de Iniciação, e é mantido durante todo o projeto....OcorrênciaEste artefato, desenvolvido durante a Fase de Iniciação, é atualizado em cada marco principal.Fonte: http://www.wthreex.com/rup/portugues/index.htm
  • Fase de concepção

    O objetivo desta fase é a elaboração de uma visão mais abrangente do sistema. Nesta fase, são levantados os principais requisitos e a construção de um modelo conceitual preliminar é feito. Também, identificam-se os casos de uso de alto nível que implementam as funcionalidades solicitadas pelo cliente. Ainda como objetivo desta fase, temos o cálculo de esforço de desenvolvimento de casos de uso e a construção do plano de desenvolvimento. Quando necessário, podem existir implementações e testes, bem como elaboração de protótipos para redução de possíveis riscos ao projeto (WAZLAWICK, 2013). 

    Fase de elaboração

    A fase de elaboração é composta por atividades de comunicação e modelagem de processos, refinando e expandindo os casos práticos preliminares, ampliando a representação da arquitetura e apresentando visões distintas de software: modelo de caso prático, modelo de requisitos, modelo de projeto, modelo de implementação e modelo de emprego (PRESSMAN, 2011). 


ID
106072
Banca
FCC
Órgão
PGE-RJ
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Deployment, no Processo Unificado, entra em ascensão na fase

Alternativas
Comentários
  • Deployment = Implantação!
  • O que é Deployment ?Resumindo: Deployment é a tarefa de instalar um software (Windows, Office ou qualquer outro) em diversas estações de maneira simples e eficiente visando organizar, facilitar e agilizar a manutenção da rede local após a sua implementação.Construção:No Marco da Capacidade Operacional Inicial, o produto está pronto para ser passado para a Equipe de Transição. Toda a funcionalidade já foi desenvolvida e todos os testes alfa (se houver algum) foram concluídos. Além do software, um manual do usuário foi desenvolvido, e existe uma descrição do release atual.Artefatos (Entre outros):"O Sistema" O próprio sistema executável, pronto para começar o teste "beta".Fontes:http://www.wthreex.com/rup/portugues/index.htmhttp://www.baboo.com.br/conteudo/modelos/O-que-e-Deployment_a9928_z0.aspx

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

O RUP (rational unified process) é uma técnica usada na modelagem de sistemas. Com relação a esse assunto, assinale a opção correta.

Alternativas
Comentários
  • a) O RUP é interativo e incremental. Possui um eixo de disciplinas (eixo estático que se repete a cada interação) e um eixo dinâmico ou temporal. A cada passada por uma fase e todas as disciplinas, temos um refinamento do projeto.CORRETOb) AGILIZANDO PROCESSO DE COMPILACAO (???)ERRADOc) Complexidade reduzir risco???ERRADOd) RUP produz muita documentação associada (artefatos). Essa afirmativa se aplica melhor aos metodos de desenvolvimento ageis ERRADOe) Não existe duas formas de comunciação e desconheco qual processo que tenha tais metodos. ERRADO
  • Só para aperfeiçoar o comentário: o RUP é iterativo e não interativo. Há diferença dos dois conceitos.
  • a) RUP trabalha com processos iterativos que ao final de cada ciclo produz uma versao funcional do software. RUP tem 4 fases (inception, elaboration, construction & transition), cujo final de cada fase um milestone é produzido 


ID
120682
Banca
FCC
Órgão
SERGAS
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

No Processo Unificado, o Modelo de Domínio é um

Alternativas
Comentários
  • Sobre PU:a) ERRADO. O diagrama de classe pode ser utilizado apenas para análise, mas isto não é uma peculiaridade do Modelo de Domínio.b) ERRADO. Que nível de desenho é esse? Desenho do software? Se for, muitos dos diagramas da UML faz parte deste nível de desenho e não é uma peculiaridade do Modelo de Domínio.c) CORRETO. Segundo Eric Evans, o Modelo de Domínio deve expressar o negócio, as regras, comportamentos e relações entre os objetos de négocios utilizando uma Linguagem unificada (capturando como o mundo real nomeias os conceitos, características e elementos de negócio de um sistema). Claro que Evans trata o Modelo de Domínio sobre a ótica de DDD, mas ainda sim expressa muito bem seu conceito.d) ERRADO. Nenhum modelo de domínio carregaria TODO comportamento e estrutura (de que mesmo?).e) ERRADO. Nenhum modelo de domínio esta preocupado se as informações serão ou não armazenadas, muito menos NORMALIZADAS. Então como saber se o que estará no Modelo de Domínio estará no DER. Isto fica a cargo do ORM (Mapeamento Objeto-Relacional) o que nada tem haver com ser UP.
  • Segue um esquema para tentar ajudar neste tipo de questão:

    Visão Lógica:
    *Diagrama de classes
    *Modelo E-R (Se o sistema assim o requer)

    Visão de Implementação:
    *Diagrama de Sequência
    *Diagrama de estados
    *Diagrama de Colaboração

    Visão Conceptual:
    *Modelo de domínio ou modelo de negócio

    Visão física:
    *Mapa de comportamento a nível de hardware.

  • A FCC (Fundação Copia e Cola) sempre surpreendendo:

    Fonte: RUP 7

    Definição de Termo: modelo de domínio
     No RUP, o modelo de domínio é um subconjunto do modelo de análise de negócio.
  • c-

    o modelo de dominio amplia o modelo conceitual, incluindo informações relativas a solucao do problema, incluindo os metodos. Um modelo descreve os aspectos do sistema fisico que sao relevantes ao proposito do modelo, no nivel adequado ao detalhe.


ID
121147
Banca
FCC
Órgão
AL-SP
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

São fases do Processo Unificado de desenvolvimento de software:

Alternativas
Comentários
  • No RUP o projeto é composto por quatro fases: Concepção, Elaboração, Construção e Transição. Ao contrário da abordagem em cascata, as fases não seguem uma sequência tradicional de requisitos, análise, programação, integração e testes.
  • Se vc analizar mais, a questão faz uma mesclagem das fases com as disciplinas do PU, pegando eventuais desatentos.

  • Implementação é uma disciplina do PU, e não uma fase. O nome da fase chama-se Construção.

     Fases:
    - Concepção;
    - Elaboração;
    - Construção; (e não Implementação)
    - Transição.

    Disciplinas:

    Seis Disciplinas de Engenharia:
    - Modelagem de Negócios
    - Requisitos
    - Análise e Projeto("Design")
    - Implementação
    - Teste
    - Implantação

    Três Disciplinas de Apoio/Suporte: (RUP)
    - Ambiente
    - Configuração e Gerência de Mudança
    - Gerência de Projeto
  • Respondi rápido e errei. Fase é fase, disciplina é disciplina.

  • Para decorar as fases do PU :

    "Con2 Ela Transa"  => Concepção, Elaboração, Construção e Transição

     


ID
121150
Banca
FCC
Órgão
AL-SP
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

No Processo Unificado de desenvolvimento de software, Requisitos e Teste são

Alternativas
Comentários
  • Requisitos e Testes são algumas das disciplinas do RUP,
    A disciplina Requisitos está concentrada mais nas fases iniciais do RUP ( iniciação e elaboração ). Pois envolve uma interação maior com o cliente para definição das funcionalidades da aplicação e das fronteiras
    A disciplina Testes está mais presente na fase de construção, para verificar/encontrar deficiências no software.
    Todas as disciplinas do RUP definem os fluxos de trabalho para a realização da mesma.
  • Amigos,

    A questão é clara ... "No Processo Unificado de desenvolvimento de software"
    ou seja, a questão trata de UP e não RUP

    em se tratando de UP, 
    Requisitos e Teste estão presentes em Core Worflows(Fluxo de trabalhos)
    já no RUP, estão presentes na 2ª e 5ª disciplinas respectivamente

    Letra B
  • Gabarito: B.

     

    Marcus Vinicius,

     

    Fluxo de trabalho = Workflow = Disciplina.

     

    A Implantação é a única disciplina que não consta em uma das fases, na fase de Concepção/Iniciação. As demais disciplinas são utilizadas em todas as fases, o que muda é o foco/intendidade.

     

    Portanto, o que denuncia o erro das alternativas C, D e E é o termo "apenas".


ID
126244
Banca
FCC
Órgão
DPE-SP
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

A partir da perspectiva de gerenciamento, NÃO faz parte do ciclo de vida de software do RUP (Rational Unified Process):

Alternativas
Comentários
  • Fases: 1. Concepção: ênfase no escopo do sistema; 2. Elaboração: ênfase na arquitetura; 3. Construção: ênfase no desenvolvimento; 4. Transição: ênfase na implantação.
  • Não entendi a questão. Alguém poderia comentar?
    Ao perguntar "NÃO faz parte do ciclo de vida de software do RUP", o enunciador está querendo saber quais são as fases do RUP?
    O início da frase "A partir da perspectiva de gerenciamento" influenciaria a resposta?
  • O ciclo de vida de desenvolvimento é definido pelas fases. A única alternativa que não faz referência a uma fase é a disciplina de teste.

    Bons estudos.
  • Iniciação aparece muito (inclusive na FCC) como Concepção.

    Transição pode aparecer (embora com menor frequência) como Deployment.

  • Teste é um workflow, e nao uma fase do RUP


ID
128809
Banca
FCC
Órgão
MPE-SE
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Pertencem à dimensão temporal do modelo iterativo RUP:

Alternativas
Comentários
  • Para capturar a dimensão do tempo de um projeto, o RUP divide o projeto em quatro fases diferentes:
    1. Concepção: ênfase no escopo do sistema;
    2. Elaboração: ênfase na arquitetura;
    3. Construção: ênfase no desenvolvimento;
    4. Transição: ênfase na implantação.
  • A dimensão temporal do RUP é composta pelas fases e iterações, que organizam dinamicamente o processo no tempo, e corresponde ao eixo horizontal do "gráfico das baleias". Ao outra dimensão corresponde ao eixo vertical, e é composta por disciplinas, atividades, fluxos de trabalho e artefatos.

    Como a questão pede a dimensão temporal, a resposta deve conter apenas fases, sem disciplinas. A  alternativa A é a única que atende a isso.

    a) Inception (fase) e Transition (fase)
    b) Implementation (disciplina) e Deployment (disciplina)
    c) Requirement (disciplina) e Configuration (disciplina)
    d) Elaboration (fase) e Implementation (disciplina)
    e) Elaboration (fase) e Test (disciplina)
  • Nessa questão o que me confundiu foi o inglês, por esse motivo acho importante deixar claro aqui quais são as fases do RUP em inglês:

    Inception = Concepção (Iniciação)

    Elaboration = Elaboração

    Construction = Construção

    Transition = Transição


ID
128812
Banca
FCC
Órgão
MPE-SE
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Pertencem aos Core Process ou aos Core Supporting Workflows do modelo iterativo RUP:

Alternativas
Comentários
  • Nessa questão queria a letra que todos os itens são disciplinas do RUP.

     

    A letra a está errada pois Construction é uma Fase

    A letra b está errada pois Construction é uma fase.

    A letra c está correta, os dois são disciplinas. Configuration and change management é uma Core Supporting Workflow e Business Management é um Core Process Workflow.

    A letra d está errada pois Inception é uma fase.

    A letra e está errada pois Transition é uma fase.

     

    Core Process Workflows são: Business Modeling, Requirements, Analysis & design, Implementation, test, Deployment

    Core Supporting Workflows são: Configuration & Change management, Project Management, Environment

     

    Mais informações em:

    http://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_TP026B.pdf

  • Curiosa a questão, enunciado parece confuso.  Supporting Workflows, de acordo com a própria documentação oficial da RUP oferecida pela IBM, está inserido dentro do Core Process que é dividido em 9 disciplinas (6 de Engenharia e 3 Suporte).  Aparentemente a interpretação da FCC é no sentido de Core Process referir-se apenas a Engenharia, há outras questões elaboradas por ela que tendem a essa interpretação.

    Para feito de aprendizado a IBM faz a seguinte divisão:

    Engenharia:
    1. Business modeling workflow
    2. Requirements workflow
    3. Analysis & Design workflow
    4. Implementation workflow
    5. Test workflow
    6. Deployment workflow

    Suporte
    1. Project Management workflow
    2. Configuration and Change Management workflow
    3. Environment workflow

    Obviamente é importante saber qual a linha de entendimento da banca sobre o assunto e caso não tenha uma boa fundamentação para recorrer do item é melhor marcar o que a banca espera.

    Referência -
    http://www.ibm.com/developerworks/rational/library/content/RationalEdge/jan01/WhatIstheRationalUnifiedProcessJan01.pdf
    http://www-01.ibm.com/software/awdtools/rmc/library/
  • Cobrar o Rup em INglês é sacanagem, mas vamos lá:

    http://screencast.com/t/yeGqEa7D

    fonte:http://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_TP026B.pdf (pag 10)

  • Tudo bem que é sensato alinhar com o entendimendo da banca. Mas é impressionante como a FCC se supera na redação do enunciado das questões!

    Geralmente é pedido "pertence a categoria X E a categoria Y, respectivamente". Este enunciado pede "Core Process ou aos Core Supporting Workflows" e nem na ordem é solicitado, Configuration and Change Management (Core Supporting Workflows) e Business modeling (Core Process).

  • Letras A, B, D e E possuem fases o que é diferente do pedido na questão. Por eliminação as letras anteriormente citadas estariam fora. Agora complementando. 
    Processos de apoio são 3: Gerência de Configuração e Mudança, Ambiente e Gerência de Projeto. 

    Agora Core Process são 6: Modelo de Negócio, Requisitos, Análise e Projeto, Implementação, Teste e finalmente Implantação. 
  •  c)Configuration and Change Management e Business modeling.

    core supoprt workflows:

    project management; change configuration management, environment configuration, business modelling, requests, analysis and project, implementation, test & distribution

    http://blog.softelegance.com/tag/rational-unified-process-core-workflows/


ID
128815
Banca
FCC
Órgão
MPE-SE
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Os seguintes produtos especificados no RUP:

I. modelo de caso de uso no mínimo 80% completo;
II. manuais do usuário.

correspondem, respectivamente, aos resultados da

Alternativas
Comentários
  • Com relação ao item I:

    Como um dos resultado finais da Elaboração temos um modelo de caso de uso com no mínimo 80% completo. Todos os casos de uso e os atores foram identificados e a maioria das descrições foram desenvolvidas.

    Com relação aos casos de uso nas fases::

    • na Inception todos os casos de uso são identificados e apenas os mais significativos e críticos são descritos
    • na Elaboration a maiora dos casos de uso são descritos, mínimo de 80%.
    • na Construction os casos de uso mais simples que ainda não foram descritos são terminados.

    Com relação ao item II:

    O resultado final da fase de construção é um produto pronto para ser usado pelos usuários finais. No mínimo: software integrado nas plataformas adequadas, manuais de usuário e uma descrição da release.

    Poderia confundir com a Transition mas nessa fase o manual do usuário já tem que estar pronto, pois o software vai ser entregue para os usuários finais e testado por eles.

     

    Link com mais informações:

    http://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_TP026B.pdf

  • Essa questão deveria ser nula não especifica  com clareza a fase do manual de usuários ficou um sentido duplo com ambiguidade.
  • Padrão FCC de qualidade.
    A questão é boa e faz pensar, no entanto duvido que foi esse o objetivo da Copia/Cola.

    Da forma que o artefato está descrito no item I, realmente ocorre na fase de elaboração. Assim a única resposta possível é a letra E.

    Manuais de usuário se trata do artefato Material de Supórte para o Usuário.
    Tem seu planejamento inicial na fase de elaboração, à mediada que os requisitos e casos de uso se desenvolvem.
    É refinado na fase de construção, paralelamente ao desenvolvimento do próprio sistema.
    É finalizado na fase de transição, pois essa é uma de suas atividades básicas.

    artefato: http://www.wthreex.com/rup/portugues/process/artifact/ar_eusm.htm
    fase: http://www.wthreex.com/rup/portugues/process/itrwkfls/iwf_lit.htm
  • A questão está ok. Resposta letra E

    Segundo o RUP:

    Artefato da fase de elaboração:

    Modelo de Caso de Uso (Agentes, Casos de uso) : Um modelo de caso de uso (aproximadamente 80% concluído) - todos os casos de uso identificados no relatório sintético de modelo de caso de uso, todos os agentes identificados e a maioria das descrições de casos de uso (captura de requisitos) desenvolvidas. 

    Artefato da fase de construção:

    Material de Suporte do Usuário: Manuais do Usuário e outros materiais de treinamento. Rascunho preliminar, com base em casos de uso.  Poderá ser necessário, se o sistema tiver um aspecto sólido de interface com o usuário.

    Fonte: http://www.wthreex.com/rup/v711_ptbr/index.htm

  •  e)elaboration e construction phases.

    Use cases iniciam na fase concepçãop, mas somente na elaboração é que estao quase definidos (80% é o numero magico que define use case na fase de elaboração). 

    http://www.slideshare.net/zoimustafa/rup-model


ID
133987
Banca
CESPE / CEBRASPE
Órgão
CEHAP-PB
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Com relação ao RUP (Rational Unified Process), assinale a opção incorreta.

Alternativas
Comentários
  • Letra dO marco da fase de construção é determinar se o produto está pronto para ser implantado num ambiente de testes beta. As garantias apresentadas na alternativa 'd' referem-se ao marco da fase Transição.
  • Na letra b, cita que um dos objetivos da Elaboração é desenvolver o plano do projeto, porém este é um dos objetivos da Iniciação, como cita Kruchten, pág. 227, The Rational Unified Process Made Easy - A Practitioner's Guide to the RUP.
    Ainda, se fosse o plano de iteração da Construção ou o refinamento do plano do projeto, até ia.
    Na mesma questão, também cita que é objetivo "desenvolver um entendimento do domínio do problema", eu diria refinar o entendimento, pois o domínio do problema é da Iniciação com os casos de uso de negócio e o documento de visão, juntamente com a definição dos requisitos, todos eles iniciando na Iniciação e se estendendo através da Elaboração.
    Na letra d, não vejo problemas, visto que não elucidou se o software funcionava plenamente ou não. Uma versão beta (entrega da última iteração da Construção) funciona no ambiente operacional (visto que para concluir a Construção, deve-se passar pelo marco de Capacidade Operacional Inicial - IOC), embora não seja a release final.

  • A ALTERNATIVA D SE TORNARIA VERDADEIRA SE:
    Ao se concluir a fase de implantacao, produz-se um sistema de software documentado e funcionando adequadamente em seu ambiente operacional.
    Pois nao ha que se falar em software documentado e funcionando adequadamente antes dessa fase.
  • Leandro, ainda assim a afirmativa continuaria falsa. Não necessariamente, após a fase de transição, há um sistema de software funcionando em seu ambiente de trabalho. Após a fase de transição, pode haver apenas um incremento e este compreender somente uma parte do sistema de software.
  • A letra 'b' também estaria errada, não?

  •  d)Ao se concluir a fase de construção, produz-se um sistema de software documentado e funcionando adequadamente em seu ambiente operacional.

    RUP (rational unified process)::

    1- deriva dos use cases do UML

    2- iterações organizadas em workflows

    3- 4 fases: concepção (inception), elboração, construção, transição. Produzir um sofwtare completo & documentado é o artefato da fase de transição, e nao construção

  • Ao se concluir a fase de construção, produz-se um sistema de software documentado e funcionando adequadamente em seu ambiente operacional.(Errado)

    O marco da fase construção é entregar uma capacidade operacional inicial do software com parte de suas funcionalidades prontas ou seja, com as "capacidades mínimas aceitáveis".
    É como uma versão beta do software e não a versão final do produto.

    Agora vejam:

    Ao se concluir a fase de transição, produz-se um sistema de software documentado e funcionando adequadamente em seu ambiente operacional.(Correto ).

    A fase de Transição tem o objetivo de colocar o sistema em funcionamento no ambiente
    real de uso
    . Ao concluir esta fase, você deverá ter um sistema de software documentado.

     

    " Vamos nós"

  • Não entendi porque a questão B está errada, já que segundo Ian
    SOMMERVILLE, na página 34, está escrito:

     Elaboração. As metas da fase de elaboração são desenvolver uma compreensão do problema dominante, estabelecer
    um framework da arquitetura para o sistema, desenvolver o plano do projeto e identificar os maiores
    riscos do projeto.
    No fim dessa fase, você deve ter um modelo de requisitos para o sistema, que pode ser um
    conjunto de casos de uso da UML, uma descrição da arquitetura ou um plano de desenvolvimento do software.


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

O RUP (rational unified process) é um processo de engenharia de
software que 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. Acerca de RUP,
requisitos e casos de uso, julgue os itens seguintes.

A primeira dimensão do RUP representa o aspecto dinâmico do processo quando ele é aprovado e é expressa em termos de fases, iterações e marcos.

Alternativas
Comentários
  •  primeira dimensão do RUP é o TEMPO que mostra os aspectos dinâmicos do processo, os  ciclos, fases, iterações e marcas (milestones)


  • Complementando...

     

    O RUP é descrito a partir de 3 perspectivas:

    * Dinâmica - Fases do modelo (Iniciação, Elaboração, Construção, Transição) no tempo
    * Estática - Atividades dos processos (disciplinas - não estão associadas a uma única fase)
    * Prática - Sugere boas práticas para serem usadas durante o processo

  • o RUP possui duas dimensões:

    • O eixo horizontal representa o tempo e mostra os aspectos do ciclo de vida do processo à medida que se desenvolve. Representa o aspecto dinâmico do processo. É expresso em termos de fases, disciplinas e marcos.
    • O eixo vertical representa as disciplinas, que agrupam as atividades de maneira lógica, por natureza. Representa o aspecto estático do processo. É descrito em termos de componentes, disciplinas, atividades, fluxos de trabalho, artefatos e papéis do processo.

    fonte: http://javafree.uol.com.br/artigo/871455/Obtendo-Qualidade-de-Software-com-o-RUP.html

  • A primeira dimensão representa o aspecto dinâmico do processo quando ele é aprovado e é expressa em termos de fases, iterações e marcos.

    A segunda dimensão representa o aspecto estático do processo, como ele é descrito em termos de componentes, disciplinas, atividades, fluxos de trabalho, artefatos e papéis do processo (consulte Conceitos-chave)

    Fonte: http://www.wthreex.com/rup/process/ovu_proc.htm

  • correto

    RUP tem 2 dimensoes: a 1° lida com a dinâmica do processo contido nas 4 fases (inception, elboration, construction, transition). A 2° é a parte estática e contém os workflows, artefatos e funcções

     

  • Vendo essas definições colocadas pelos colegas fica clara a questão, mas sem ela fica um pouco confuso, pois a parte iterativa do rup tem a ver com as disciplinas e não com as fases.

  • Além disso, também é expressa em ciclos.


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

O RUP (rational unified process) é um processo de engenharia de
software que 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. Acerca de RUP,
requisitos e casos de uso, julgue os itens seguintes.

Sob a perspectiva de gerenciamento, o ciclo de vida de software do RUP é dividido em quatro fases sequenciais cujos finais são delimitados por marcos e avaliados para determinar se os objetivos da fase foram alcançados.

Alternativas
Comentários
  • As fases são iterativas, com sobreposição entre elas. Essa de fases sequenciais ficou estranha...

  • Existe um encadeamento entre as fases. Por exemplo, a fase de construção não pode vir antes da concepção.

  • Concordo que as fases sequenciais deixaram a questão estranha. Qualquer material de RUP explica sempre que essas fases são sobrepostas e iterativas. Na minha opinião, caberia recurso.
  • As fases são sequenciais. As disciplinas é que são revisitadas nas fases.

    Por exemplo, a disciplina de requisitos não é executada apenas na fase de Concepção. É onde ela é mais importante, mas ela é executada em todas as fases.

    Porém, mais uma vez, as fases são sequenciais.
  • Apenas um comentário em cima do comentário do Rodrigo.

    As disciplinas são revisitadas nas fases e as fases são sequenciais, via de regra, porém pode haver iteração entre fases. O sommerville é bem explícito quanto a isso, no capítulo 4, pág. 55, da 8ª edição do seu livro:

    "A iteração no RUP é considerada em duas formas, como apresentado na Figura 4.12. Cada fase pode ser realizada de forma iterativa, com os resultados desenvolvidos incrementalmente. Além disso, o conjunto total de fases pode também ser realizado de forma incremental, conforme apresentado pela seta retornando da Transição para a Concepção na Figura 4.12".

    Quem não tiver o livro, dá uma pesquisada e procura pelos slides do livro, versão inglês. Lá tem a figura.

    Porém, a questão está correta, pois em nenhum momento a questão afirma que as fases são apenas sequenciais.
  • Conforme o RUP:

    O ciclo de vida de software do RUP é dividido em quatro fases sequenciais, cada uma concluída por uma marco principal, ou seja, cada fase é um intervalo de tempo entre dois marcos.

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

O RUP (rational unified process) é um processo de engenharia de
software que 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. Acerca de RUP,
requisitos e casos de uso, julgue os itens seguintes.

No RUP, os manuais dos sistemas e as rotinas de teste são definidos a partir dos casos de uso. Entretanto, os elementos da arquitetura e a estratégia de implantação do sistema, por se relacionarem com a infraestrutura e não com os requisitos funcionais, não são definidos com base nos casos de uso.

Alternativas
Comentários
  • Alguém pode comentar porque a sentença está errada?Obrigado.
  • A arquitetura do do software é uma macroorganização do sotware(conjunto de casos de usos mais críticos).Ao término da fase de Elaboração eu tenho a arquitetura do sistema definido.Portanto, a arquitetura depende sim dos casos de uso.
  •  O RUP é orientado a casos de uso.

  • Gente bonita, como que a partir de caso de uso posso gerar manual de sistema? Piraram!?
  • Marcelo,

    Um diagrama de casos de uso descreve um cenário que mostra as funcionalidades do sistema do ponto de vista do usuário.

    Se temos a descrição da funcionalidade, podemos sim descrever o manual a partir dos casos de uso do sistema.

  • Os manuais (artefato: material de suporte para o usuário) são finalizados na fase de transição, e não construídos nela.
    http://www.wthreex.com/rup/portugues/process/artifact/ar_eusm.htm
    Há que se ressaltar que também há manuais para treinamento (artefato: materias de treinamento) que são refinados na fase de construção.

    Do RUP:
    artefato: material de suporte para o usuário
    "O planejamento inicial do material de suporte para o usuário começa na fase de elaboração, à media que requisitos e casos de uso se desenvolvem e a funionalidade do sistema é definida. Esse artefato é refinado na fase de construção, paralelamente ao desenvolvimento do próprio sistema."
    ...
    "Use os casos de uso como para para seu guia de usuário"

  • Considerando que o RUP é um framework de processos iterativo e Incremental guiado por casos de uso;
    Considerando a arquitetura de Visão 4 + 1 de Krutchen que mostra a Visão de Caso de Uso conectando todas as outras visões, acredito que um dos erros seja que a questão diz: "Entretanto, os elementos da arquitetura e a estratégia de implantação do sistema, por se relacionarem com a infraestrutura e não com os requisitos funcionais, não são definidos com base nos casos de uso. ".

    Como considerado inicialmente, Casos de uso guiam o RUP.





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

Acerca das verificações e dos testes, julgue o item abaixo.

Programação e testes são atividades que acontecem na fase de concepção do processo unificado, pois a realimentação e os testes precoces servem para evoluir os requisitos.

Alternativas
Comentários
  • O fluxo de teste é desenvolvido com base no produto do fluxo de
    implementação.
    Os componentes executáveis são testados exaustivamente no fluxo
    de teste para então ser disponibilizados aos usuários finais.
    O principal propósito do fluxo de teste é realizar vários testes e
    Componentes que possuírem defeitos retornarão a fluxos
    anteriores como os fluxos de projeto e implementação, onde os
    problemas encontrados poderão ser corrigidos.
    O teste de um sistema é primeiramente empregado durante a fase
    de elaboração, quando a arquitetura do sistema é definida, e
    durante a fase de construção quando o sistema é implementado.
    Um planejamento inicial de testes pode ser feito durante a fase de
    concepção.
    Na fase de transição, o fluxo de testes se limita ao conserto de
    defeitos encontrados durante a utilização inicial do sistema.
     O produto do fluxo de teste é o modelo de teste, esse modelo
    primeiramente descreve como componentes executáveis,
    provenientes do fluxo de implementação, são testados.
    O modelo de testes também pode descrever como aspectos
    específicos do sistema testados, como por exemplo, se a interface
    do usuário é útil e consistente ou se o manual do usuário cumpre
    seu objetivo.
    O papel do fluxo de teste é verificar se os resultados do fluxo de
    implementação cumprem os requisitos estipulados por clientes e
    usuários, para que possa ser decidido se o sistema necessita de
    revisões ou se o processo de desenvolvimento pode continuar.sistematicamente analisar os resultados de cada teste.

  • por favor comentar a  respeito dessa questa!!!

  • Vejam o gráfico de baleias do Rup. Verão que a implementação e testes iniciam na fase de Iniciação.

  •  Caí na pegadinha e errei a questão..

    Analisando bem, na fase de Concepção também existe os fluxos de Implementação e Teste, eles não estão lá por acaso. Então como disse o amigo abaixo a situação descrita no enunciado PODE ocorrer, mas é a primeira questão que leio abordando isso.

     

  • Disciplina de Teste

    As finalidades da disciplina de teste são:

    Para verificar a interação entre objetos Para verificar a integração adequada de todos os componentes do software Para verificar se todos os requisitos foram corretamente implementados Identificar e garantir que os defeitos são abordados antes da implantação do software Garantir que todos os defeitos são corrigidos, reanalisados e fechados

    O Rational Unified Process propõe uma abordagem iterativa, o que significa que deve-se testar todo o projeto. Isto permite encontrar defeitos tão cedo quanto possível, o que reduz radicalmente o custo de reparar o defeito. Os testes são realizados ao longo de quatro dimensões da qualidade:confiabilidade, funcionalidade, desempenho da aplicação, e o desempenho do sistema. Para cada uma destas dimensões da qualidade, o processo descreve como passar pelo teste do ciclo de planejamento, projeto, implementação, execução e avaliação.

  • Segundo o O Guia Definitivo do Handbook de TI (ref.1):
    (...) de uma iteração para outra e de uma fase para a próxima, a ênfase sobre as várias atividades muda, como mostra a figura 8.1, em que a cor preta indica grande ênfase, enquanto a cor branca indica muito pouca ênfase.(...)
    Repare que o livro diz 'muito pouca ênfase' e não nehuma enfase.

    Segundo o site open2up.blogspot.com (ref. 2):
    No Processo Unificado, as Tarefas são agrupadas logicamente nas diversas disciplinas, que são distribuídas entre as fases e são executadas a cada iteração, em maior ou menor escala. As disciplinas recebem maior ou menor ênfase de acordo com a fase na qual a iteração corrente está inserida. Observe na figura abaixo a distribuição das disciplinas de acordo com as fases no Open UP.
    link para a figura.
    Aqui diz 'maior ou menos escala'.

    Logo, a afirmativa esta CERTA.

    ref. 1: (página 105) http://www.handbookdeti.com.br/apostilas-teoricas/handbook-de-ti-para-concursos-o-guia-definitivo.html
    ref. 2: http://open2up.blogspot.com/p/papeis-tarefas-e-produtos-de-trabalho.html 
  • Também errei, é porque só vem na cabeça a associação disciplina x fase, implementação e teste não são foco da fase concepção porém, têm esforço mesmo que pouco na concepção. 
  • "Programação e testes são atividades que acontecem na fase de concepção do processo unificado, pois a realimentação e os testes precoces servem para evoluir os requisitos."

    Durante a passada por uma iteração a disciplina de testes é realizada. Porém a questão sugere que é na fase de concepção que o teste ocorre, como se não ocorresse nas demais. Mais uma questão de português e duvidosa da Cespe. Quando vão começar a cobrar TI?
  • Infelizmente, é necessário ter o gráfico das baleias na cabeça, vejamos:

    Programação e testes são atividades que acontecem na fase de concepção do processo unificado??
    Sim, observe que a questão não fala em ênfase, mas sim sim em acontecer, em existir.

    A realimentação e os testes precoces servem para evoluir os requisitos ??
    Sim, exemplo de utilização de prototipagem.

    Observe que a fase de iniciação possui a seguinte Atividade Essencial:
    Sintetizar uma sugestão de arquitetura, avaliando as mudanças no design e em fazer/comprar/reutilizar para que seja possível calcular custo, planejamento e recursos. O objetivo aqui é demonstrar a possibilidade de execução através de alguma forma de prova de conceito. Isso pode ter a forma de um modelo que simula o que é exigido, ou de um protótipo inicial que explora as áreas consideradas de alto risco. O esforço do protótipo durante a iniciação deve se limitar a ganhar confiança na possibilidade de uma solução - a solução será executada durante a elaboração e a construção.

    Fonte: RUP disponível em http://www.wthreex.com/rup/v711_ptbr/rup/customcategories/inception,_vyZOwCVuEdqSZ9OimJ-AzA.html
  • Fase de concepção

    O objetivo desta fase é a elaboração de uma visão mais abrangente do sistema. Nesta fase, são levantados os principais requisitos e a construção de um modelo conceitual preliminar é feito. Também, identificam-se os casos de uso de alto nível que implementam as funcionalidades solicitadas pelo cliente. Ainda como objetivo desta fase, temos o cálculo de esforço de desenvolvimento de casos de uso e a construção do plano de desenvolvimento. Quando necessário, podem existir implementações e testes, bem como elaboração de protótipos para redução de possíveis riscos ao projeto (WAZLAWICK, 2013). 


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

Com relação aos conceitos e às disciplinas considerados no
processo unificado, julgue os itens de 76 a 80.

São atividades que se realizam no âmbito da disciplina de requisitos: identificar junto aos clientes o que o sistema deve fazer; definir escopo; e fornecer uma base para estimativas.

Alternativas
Comentários
  • Disciplina de Requisitos, cujos objetivos são: 

    • Estabelecer   e  manter   o   consenso   entre   os   desenvolvedores   e   os   demais   envolvidos   (clientes, testadores, investidores, usuários, etc) sobre o que o sistema deve fazer e porque;
    • Permitir que os desenvolvedores tenham um melhor entendimento dos requisitos do sistema;
    • Definir as fronteiras do sistema (delimitar o sistema);
    • Fornecer uma base para planejar o conteúdo técnico das iterações;
    • Fornecer uma base para estimar o custo e o tempo de desenvolvimento
    • Definir uma interface de usuário orientada para as necessidades e objetivos dos clientes.

    fonte: www.daeln.ct.utfpr.edu.br/~lalucas/Disciplinas/Tec.../Aula3.pdf

  • Lembrar que "Fornecer uma base para estimar o custo e o tempo de desenvolvimento" é da disciplina de requisitos.


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

Com relação aos conceitos e às disciplinas considerados no
processo unificado, julgue os itens de 76 a 80.

No processo unificado, os modelos de caso de uso encontramse na disciplina de requisitos, enquanto plano de desenvolvimento de software e especificações suplementares são partes da disciplina gerenciamento de projeto.

Alternativas
Comentários
  • Especificações suplementares fazem parte da disciplina de requisitos e não de gerenciamento de projeto, como fala a questão.

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

Com relação aos conceitos e às disciplinas considerados no
processo unificado, julgue os itens de 76 a 80.

A disciplina análise e projeto desenvolve e mantém os artefatos de suporte que são utilizados pela disciplina teste.

Alternativas
Comentários
  • No RUP existem 6 disciplinas de engenharia e 3 disciplinas de suporte/apoio, a saber:

    1)Disciplinas de engenharia:
          -Modelagem de negócio
          -Requisitos
          -Análise e projeto
          -Implementação
          -Teste
          -Implantação

    2)Disciplinas de apoio/suporte
         -Gerenciamento de configuração
         -Ambiente
         -Gerenciamento de projeto

    As disciplinas de engenharia geram os artefatos responsáveis pelo desenvolvimento do software como produto. Já as disciplinas de suporte, geram/produzem os artefatos de suporte. Portanto, a questão só erra em uma palavra:

    A disciplina análise e projeto desenvolve e mantém os artefatos de suporte que são utilizados pela disciplina teste.

    Ora, a disciplina de análise e suporte pertence ao grupo das disciplinas de engenharia e portanto não produzem artefatos de suporte. Se não houvesse a palavra "suporte" a questão passaria a ser verdadeira, já que os artefatos dessa disciplina são usados tanto pela disciplina de implementação como pela disciplina de teste. Questão muito sutil essa aqui...

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

Com relação aos conceitos e às disciplinas considerados no
processo unificado, julgue os itens de 76 a 80.

O escopo da disciplina implementação é limitado aos testes das classes individuais e ao teste de implementação, enquanto o teste do sistema é descrito na disciplina teste.

Alternativas
Comentários
  • Dizer que o escopo da disciplina implementação é limitado aos testes das classes individuais é forçar demais a barra. E a codificação? Fica em segundo plano? Que viagem do CESPE.

  • Márcio, concordo contigo que o CESPE forçou a barra. Mas, é que ele queria se referir ao escopo de testes dentre as fases do RUP. Com o tempo eles aprendem! Rss

    Bons estudos!
  • Também entendi que ele se referia a fronteira do escopo. Não excluindo, assim, a parte de desenvolvimento da implementação.

  • "O escopo da disciplina implementação é limitado aos testes das classes "... Incrível não passar recurso para essa questão.


ID
137245
Banca
CESGRANRIO
Órgão
Casa da Moeda
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

23 A fase do RUP, em que são implementados os cenários críticos dos casos de uso arquiteturalmente significativos, se chama

Alternativas
Comentários
  • O RUP possue 4 fases (aspecto dinâmico - eixo horizontal):Iniciação - objetivos do ciclo de vidaElaboração - arquitetura do ciclo de vidaConstrução - capacidade operacional inicialTransição - lançamento do produto
  • A única coisa que nos remete a fase de Elaboração é a palavra "arquiteturalmente". Se não prestar muita atenção acabamos por pensar em Construção , fase na qual ocorre a implementação do software propriamente dito. Muito maliciosa a questão e caberia recurso.
  • do timaster...


    No livro "Introdução ao RUP" do Booch, Jacobson e Rumbaugh temos a seguinte
    definição na página 59, que trata da fase de elaboração: "Na fase de
    elaboraçãoum protótipo executável de arquitetura é contruído em uma ou
    mais
    iterações, dependendo da extensão, tamanho, risco e novidade do projeto. No
    mínimo, este esforço deveria endereçar os casos de uso críticos
    identificados na fase de concepção
    , que tipicamente expõe os riscos
    técnicos principais do projeto".

    Mateus de Souza Rocha
  • Fonte: RUP 7

    As atividades essenciais da fase Elaboração incluem:

    • Definir, validar e criar a baseline da arquitetura, com rapidez e praticidade.
    • Refinar a Visão, com base nas informações novas obtidas durante a fase, estabelecendo uma compreensão sólida dos casos de uso mais críticos que conduzem as decisões de arquitetura e planejamento.
    • Criar planos de iteração detalhados de baselines para a fase de construção.
    • Refinar o processo de desenvolvimento e posicionar o ambiente de desenvolvimento, incluindo o processo, as ferramentas e o suporte de automação necessário para dar assistência à equipe de construção.
    • Refinar a arquitetura e selecionar componentes. Os componentes potenciais são avaliados e as decisões de fazer/comprar/reutilizar são bem compreendidas para determinar o custo da fase de construção e programar com confiança. Os componentes de arquitetura selecionados são integrados e avaliados em comparação com os cenários básicos. As lições aprendidas dessas atividades podem resultar em um novo design da arquitetura, levando em consideração designs alternativos ou reconsiderando os requisitos.
  • A palavra "implementados" no enunciado da questão induz ao erro.
    Conforme os comentários dos colegas, o trecho diz :
    "estabelecendo uma compreensão sólida dos casos de uso mais críticos que conduzem as decisões de arquitetura e planejamento."

    Entendo "Compreensão" bem diferente "Implementação".
    Acabei marcando (D) Construção.
  • Replicando para melhor visualização.


    As atividades essenciais da fase Elaboração incluem:


    Definir, validar e criar a baseline da arquitetura, com rapidez e praticidade.


    Refinar a Visão, com base nas informações novas obtidas durante a fase, estabelecendo uma compreensão sólida dos casos de uso mais críticos que conduzem as decisões de arquitetura e planejamento.


    Criar planos de iteração detalhados de baselines para a fase de construção.


    Refinar o processo de desenvolvimento e posicionar o ambiente de desenvolvimento, incluindo o processo, as ferramentas e o suporte de automação necessário para dar assistência à equipe de construção.


    Refinar a arquitetura e selecionar componentes. Os componentes potenciais são avaliados e as decisões de fazer/comprar/reutilizar são bem compreendidas para determinar o custo da fase de construção e programar com confiança. Os componentes de arquitetura selecionados são integrados e avaliados em comparação com os cenários básicos. As lições aprendidas dessas atividades podem resultar em um novo design da arquitetura, levando em consideração designs alternativos ou reconsiderando os requisitos.


    Fonte: EuVouPassarNessaPorra

  • d) eloboração. As atividades essenciais de elaboração:

    +definir e validar arquitetura

    +refinar visao - identificação dos use cases mais criticos em que a arquitetura e decisões de baseam

    +projetar o plano de iteração para fase construção 

    +otimizar desenvolvimento e planejar o ambiente de desenvolvimento

    +aprimoração da arquitetura e seleção de componentes


ID
141223
Banca
ESAF
Órgão
ANA
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

O fluxo de trabalho de processo RUP que efetua o controle de alterações e mantém a integridade dos artefatos do projeto é denominado

Alternativas
Comentários
  • O RUP possui 9 disciplinas (Modelagem de Negócios, Requisitos, Análise e Design, Implementação, Testes, Implantação, Ger. de Config. e Mudança, Ger. de Projeto, Ambiente) e 4 fases (Iniciação, Elaboração, Construção, Transição).

    A disciplina Gerenciamento de Configuração e Mudança é traduzida em um fluxo (workflow) de mesmo nome: "Gerência de Configuração de Mudanças". Este fluxo mantém os artefatos salvaguardados e disponíveis para reutilização. Há uma evolução e, especialmente no desenvolvimento iterativo, esses artefatos são repetidamente atualizados durante as fases.

    DICA: Para quem é desenvolvedor, pode associar esse fluxo às equipes de versionamento de projetos e backup, que geralmente utilizam ferramentas como o ClearCase ou SourceSafe.

  • Essa questão gera confusão por não mencionar a mudança.

    Normalmente encontramos "Disciplina de Configuração e Gerência de Mudança".

    Mas a resposta E não deixa de estar certa.

  •  e)gerenciamento de configuração & mudanças. 

    Esse workflow tambem tem a função de garantir que as mudanças requeridas estejam de acordo com as politicas do projeto e assegura um ambiente preciso para desenvolvimentio


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

O RUP (Rational Unified Process) é um processo de engenharia de software que oferece uma abordagem com base 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 e que atenda às necessidades dos usuários dentro de um cronograma e de um orçamento previsíveis. A respeito de RUP, assinale a opção correta.

Alternativas
Comentários
  • a) O RUP divide o projeto em 4 fases difentes: Concepção (ou Iniciação), Elaboração, Construção e Transição.
    b) Certo.
    c) As disciplinas de suporte do RUP são: gerenciamento de configuração e mudança, gerenciamento de projeto e ambiente.
    d) Os papéis definidos pelo RUP são: gerente de projeto, arquiteto, analista, desenvolvedor e testador.
    e) As disciplinas de engenharia ou processo do RUP são: modelagem de negócio, requisito, análise e design, implementação, teste, implantação
  • a) O RUP é dividido em 4 fases: Iniciação (ou concepção), elaboração, construção e transição.

    c) As disciplinas de suporte (Core Supporting Workflows) sao: Gerência de Configuração e Mudanças (Configuration and Change Management); Gerência de Projetos (Project Management); e Ambiente(Enviroment).

    d) Um papel é uma definição abstrata de um conjunto de atividades executadas e dos respectivos artefatos. Os papéis do Analista organizam os papéis envolvidos principalmente na identificação e na investigação de requisitos (Analista de Sistemas, Designer de Negócios, etc). Os papéis do Desenvolvedor organizam os papéis envolvidos principalmente no design e desenvolvimento de software (Designer de Cápsula, Revisor de Código, etc). Os Papéis do Testador organizam os papéis que lidam com habilidades específicas exclusivas para teste (Testador). Os papéis do Gerente organizam os papéis envolvidos principalmente no gerenciamento e na configuração do processo de engenharia de software (Engenheiro de Processo, Gerente de Projeto, etc). Os papéis adicionais organizam os papéis que envolvem funções diversas ou de suporte no projeto (Desenvolvedor do Curso, Artista Gráfico, Especialista em Ferramentas, etc).

    e) As disciplinas (workflows) do RUP são separadas em dois grupos: Core Engineering Workflows(contendo 6 disciplinas) e Core Supporting Workflows (contendo 3 disciplinas). Os dois grupos (engineering e supporting) formam um grupo mais generico chamado: Core Process Workflows (contendo as 9 disciplinas do RUP)
    OBS.: As vezes o grupo Core Engineering Workflow é chamado simplesmente de Core Process WorkFlow.
    • Core Process Workflows:
      • Core Engineering Workflows:
        • Business Modeling (modelo de negócios)
        • Requirements (requisitos)
        • Analysis and Design (análise e desenho)
        • Implementation (implementação)
        • Test (teste)
        • Deployment (implantação)
      • Core Supporting Workflows:
        • Configuration and Change Management (Gerência de Configuração e Mudanças)
        • Project Management (Gerência de Projetos)
        • Environment (ambiente)

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

A gerência de desenvolvimento de sistemas de uma empresa está reformulando seu processo de software. Para isso, deseja criar uma metodologia de desenvolvimento baseada no Processo Unificado. A respeito desse processo, é INCORRETO afirmar que o(a)

Alternativas
Comentários
  • A fase de elaboração possui como marca a arquitetura da solução, para validar a arquitetura é importante implementar o caso de uso mais critico.
  • Os casos de uso mais criticos, entenda-se mais dificil de serem resolvidos/implementados, geralmente vao ser o núcleo do sistema ou função mais importante, devem ser implementados primeiro. com isso o problema com maior risco de ser resolvido se resolve no comeco do projeto. Com isso desperdicios de tempo e dinheiro com o desenvolvimento de partes simples do projeto nao acontecem caso a equipe falhe em fazer o principal do projeto.
  • Os casos de uso mais críticos são atacados primeiro no RUP, com a justificativa de que eles definem a arquitetura, que deve ser estabilizada logo.

    No XP as funcionalidades mais críticas são atacadas por último, com a justificativa de que os requisitos são instáveis e tudo pode ser mudado, então existe a chance de uma funcionalidade com grande impacto na arquitetura sofrer mudanças de requisito.

ID
143749
Banca
FIP
Órgão
Câmara Municipal de São José dos Campos - SP
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Com relação ao "Rational Unified Process" (RUP), não é correto afirmar que:

Alternativas
Comentários
  • Questão típica de eliminação de possibilidades:

    a) Sem dúvidas o RUP é um modelo versátil que se adapta aos mais variados tipos de projetos, com flexibilidade em arquitetura por não estar 'preso' a nenhuma implementação específica.

    b) Iteratividade e incrementos são o ponto forte do RUP, que visa iterar e incrementar gerando releases ao término de cada etapa.

    c) Tirando o fato de o RUP ter os mesmos criadores da UML, toda a metodologia RUP está voltada aos casos de uso, bem como uma das sugestões das melhores práticas "Modelar Visualmente".

    d) Em nenhum ponto da documentação RUP faz menção à RAD, se é que RAD existe!

    e) Semelhante ao observado nas alternativas 'b' e 'c'
  • Nâo entendi porque na questão "b" ele deu como certa já que não é INTERATIVO mas sim ITERATIVO. Existe diferença entre os dois.
  • O que tenho visto são questões afirmando que o RUP baseia-se nessas premissas (dentre outras): interativo e iterativo.

    Iterativo é que itera, repete.
    Interativo é que interage, comunicação bidirecional.
  • O RUP também é interativo, no entanto não há processo de "Desenvolvimento de software interativo e incremental"
    Foi vacilo da banca mesmo.
  • ITERATIVO x INTERATIVO

    O nome iterativo (fazer de novo; REITERAR; REPETIR) e interativo (atividade ou trabalho compartilhado, em que existem trocas e influências recíprocas) se confundem em função até dos seus significados. Se imaginarmos o desenvolvimento de sistemas como puramente a criação de programas dentro da área de TI, sem a intervenção dos usuários, até que eles estejam coerentes com os requisitos de software, o correto é estarmos usando a palavra ITERATIVO, devido a repetição dessa ação.

    No entanto, se imaginarmos que a cada repetição deve-se interagir com os usuários para que o sistema cada vez mais corresponda as expectativa deles, o correto seria usar, a rigor, a palavra INTERATIVO. Mas, por convenção (ou por repetição), a grande maioria dos autores de Engenharia de Software adotam a palavra ITERATIVO para identificar este tipo de desenvolvimento.

    http://pt.wikipedia.org/wiki/Desenvolvimento_iterativo_e_incremental

    __________________________

    Já vi autores utilizarem interativo, para este caso, referindo-se ao processo de desenvolvimento de software, tanto faz.
  • O Modelo RAD (Rapid Application Development) atua com requisitos bem definidos, risco baixo e enfatiza o ciclo de desenvolvimento curto, ao contrário do RUP


ID
144613
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.

O processo unificado é estruturado em duas dimensões. A dimensão horizontal representa o aspecto dinâmico do processo, onde estão representadas suas fases, às quais estão associados marcos que determinam sua finalização. Na outra dimensão estão representadas as disciplinas, que agrupam logicamente as atividades. É possível haver disciplina que não esteja presente em todas as fases.

Alternativas
Comentários
  • O RUP tem duas dimensões:

    • o eixo horizontal representa o tempo e mostra os aspectos do ciclo de vida do processo à medida que se desenvolve
    • o eixo vertical representa as disciplinas, que agrupam as atividades de maneira lógica, por natureza.

    A primeira dimensão  representa o aspecto dinâmico  do processo quando ele é aprovado e é expressa em termos de fases, iterações e marcos.
    A segunda dimensão  representa o aspecto estático do processo, como ele é descrito em termos de componentes, disciplinas, atividades, fluxos de trabalho, artefatos e papéis do processo (consulte Conceitos-chave)
    Por exemplo, nas iterações iniciais, dedicamos mais tempo aos requisitos. Já nas iterações posteriores, gastamos mais tempo com implementação.

  • Complementando o explicado pelo colega. "É possível haver disciplina que não esteja presente em todas as fases." É o caso da disciplina de implantação que não esta presente na fase de Iniciação.

     

  • Uma dúvida:
    Se toda fase entrega um executável, como pode haver uma disciplina não estar presente em uma fase?
  • Pessoal, fiquei muito na dúvida nessa questão. Marquei errado pq a ultima frase diz: "É possível haver disciplina que não esteja presente em todas as fases."

    Contudo, observando o famoso gráfico do rup, é possível observar que a implementação possui sim participação na iniciação. Isso me fez marcar a questão como errado. Mas olhando atentamente, é possível ver que, na verdade, a disciplina que não participa da inicição é o Deployment.

    Fica a dica p/ o pessoal: implementação faz parte da iniciação, o que não faz é o deployment!!!!
  • Marquei errado por pensar no conceito de que uma iteração é uma passagem por todas as disciplinas.

    O mais óbvio é marcar "certo" na questão mas, por ser uma questão do CESPE, achei que poderia haver uma pegadinha.

  • O RUP possui 2 dimentões:

    A dimensão horizontal que contém as fases temporais, por isso são chamadas de dinâmicas
    A dimensão vertical que contém as disciplinas que são executadas sobrepostas, sem ordem temporal, também chamada de estáticas

  • Gabarito: C.

     

    A disciplina Implantação é a única que não possui atividade em todas as fases do RUP. Ela não é executada na fase de Concepção. 


ID
144811
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.

A metodologia RUP, no que se refere à disciplina de Análise e de Desenho durante a fase de iniciação, não se destaca como um modelo orientado a reúso.

Alternativas
Comentários
  • A análise e desenho na iniciação focada no levantamento de requisitos. Orientado ao reuso ocorre em maior parte na elaboração.
  • Soh complentando...

    Copiado do timaster..
    "Acho que é porque na fase de iniciação o objetivo é definir o escopo, os custos, os riscos, etc. Até se fala em arquitetura nessa fase, mas com o objetivo de demonstrar que ela é possível em alguns cenários mais simples Essa fase não é o momento para pensar muito em reúso. Já na elaboração, aí sim essa preocupação é bem mais intensa. "
  • Além dos comentários acima, vejo que na iniciação temos algo novo, estamos entendendo o negócio. Dessa forma, o reuso não se enquadraria nessa fase de iniciação.

    Logo, a questão está correta ao afirmas que nessa fase o RUP "não se destaca como um modelo orientado a reuso".

  • correto- na fase de iniciação, o foco é o acordo entre os stakeholders para avaliar a validade do projeto. reuso é uma das melhores praticas em RUP para codigo; nao tem muito uso nesta fase


ID
144814
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.

Ao comparar os modelos RUP e PMBOK, constata-se que cada fase no RUP pode ser executada como uma fase do ciclo de projeto no PMBOK.

Alternativas
Comentários
  • Questão duvidosa. Como comparar maçãs com bananas? RUP é uma metodologia para desenvolvimento de software, equanto que o PMBOK é um conjunto de boas práticas para gerência de quaisquer projetos, não necessariamente de software.

  • Tirado do TIMASTER:

     

    Veja que você esqueceu do "ciclo do projeto NO PMBoK". Faz muita diferença.

    Com isso, o Tiagão raciocinou certo:

    Concepção => Iniciação, Planejamento, Execução, Controle, Encerramento
    Elaboração => Iniciação, Planejamento, Execução, Controle, Encerramento
    Construção => Iniciação, Planejamento, Execução, Controle, Encerramento
    Transição => Iniciação, Planejamento, Execução, Controle, Encerramento

    Vamos entender então por que a questão está certa. Vejam [1]:

    "O ciclo de vida de projeto define as fases do projeto que une o início de
    um projeto ao seu fim..."

    "O que um ciclo de vida define:

    * Trabalho técnico a ser realizado em cada fase;

    * Quando as entregas devem ser geradas e como devem ser revisadas,
    verificadas e validadas;

    * Quem está envolvido em cada fase e;

    * Como controlar e aprovar cada fase."

    Com isso, podemos entender que cada fase do RUP pode está relacionado com
    uma fase do ciclo de vida de um projeto no PMBoK.

    E, aproveitando, GRUPOS DE PROCESSOS NÃO SÃO FASES! O próprio Guia do PMBoK
    deixa claro esse texto (e ainda deixou-o em negrito).

    Um projeto pode ter inúmeras fases, onde em cada uma delas, você usa
    processos dos grupos de processos definidos no PMBoK [2].

    Referência:
    [1] PMBOK: Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos:
    Ciclo de Vida e Organização do Projeto:
    http://www.oficinadanet.com.br/artigo/2197/pmbok_guia_do_conjunto_de_conheciment\
    os_em_gerenciamento_de_projetos_ciclo_de_vida_e_organizacao_do_projeto

    [2]
    http://leadinganswers.typepad.com/photos/uncategorized/2008/02/21/pmbok_1_2.jpg

  • Resumindo o comentário acima, o PMBOK não define um ciclo de vida. E mais: ele diz que a organização é quem define, e que pode ter quantas fases quiser, e pode dar os nomes que quiser.

    Portanto, quando a questão diz que cada fase do RUP pode ser uma fase do PMBOK, está correto.
    Se a questão dissesse que as fases do PMBOK podem ser A, B, C e D, também estaria correto. Pode ser qualquer coisa.
  • Outro ponto, é que o fim de cada fase apresenta um marco, um entregável.
  • Bom realmente está ambigua... eu deixaria sem marcar...

    mas tem algumas questões que devem ser levadas em consideração q não consta nos comentários...

    no RUP, as "fases" do projeto são sobrepostas assim como no pmbok (vide gráfico das baleias).

    agora o que deixa a questão duvidosa, é que o PMBOK bate sempre na tecla que iniciação, planejamento, execução, m & c, encerramento não são fases... são grupos de processos.

    realmente
  • O PMBOK v4, apesar de dizer que as fases serão organizadas de acordo com a organização, fornece uma estrutura genércia de ciclo de vida:
    Início do projeto
    Organização e preparação
    Execução do tragalho do proejto
    Encerramento do projeto.


    Já o PMBOK v3 diz que "o término e a aprovação de um ou mais produtos caracteriza uma fase do projeto"
    O perigo que reside na questão é inferir que o examinador esteja querendo confundir o candidato chamando os grupos de processo do pmbok de fase. No entanto, não é esse o conhecimento cobrado na questão.
  • Outra forma de raciocinar é lembrar do "gráfico de baleias" do RUP...
    O gráfico da discilplina de gerência de projetos, a segunda de baixo pra cima, está presente em todas as fases e visivelmente tem um "início" e "fim" bem definido entre cada mudança de fase do RUP. Esse "ínício e fim" da gerência de projetos caracteriza uma fase no ciclo do projeto. Quando se compara RUP com PMBoK deve-se olhar principalmente para essa disciplina, portanto, por analogia, é coerente aceitar que cada fase do RUP pode ser executada como uma fase do ciclo de projeto do PMBoK.

    Como dica (não necessariamente relacionado à questão), vale lembrar duas coisas:
    1 - Fases do ciclo de vida de um projeto é um conceito DIFERENTE de grupo de processos do PMBoK.
    2 - A disciplina de gerência de projetos no RUP NÃO CONTEMPLA todas as áreas de conhecimento do PMBoK (falta RH, Custos, contratos)

  • Questões que necessitam mirabolantes raciocínios, pra mim tem um portugês sujo e ambíguo. Na minha visão a questão queria associar um única fase do RUP com uma única "pseudo fase" (já que o PMBOK não considera Iniciação, Planejamento... como fases). Logo estaria errada.
  • Se o PMBoK for realizado como base de comparação com o RUP, é possível inferir com ponto comum principal o fato de que muitos dos processos diretamente associados ao gerenciamento de projetos são iterativos, devido a necessidade de elaboração e realização incremental dos documentos e tarefas ao longo do ciclo de vida do projeto.

  • PMBOK x RUP

    Início do projeto x Concepção

    Organização e preparação x Elaboração

    Execução do trabalho do projeto x Construção

    Encerramento do projeto x Transição


ID
144817
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.

O modelo de ciclo de vida empregado pelo RUP é mais formal que iterativo.

Alternativas
Comentários
  • É mais interativo que formal.
  • Corrigindo o comentário do colega, é mais iterativo que formal.

    iNterativo (com N) é outra coisa.

  • O RUP é um processo adaptativo, por ser iterativo e incremental.

    Bons estudos!
  • errado- RUP é bastante formal, se baseando no escopo e milestones para datas específicas, mas é mais iterativo porque as atividades sao feitas em ciclos com as 4 fases: concepção, leaboração, construção, transição,


ID
144820
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.

As técnicas, os métodos e as ferramentas classicamente associados às fases do modelo de ciclo de vida em cascata, na metodologia RUP, estão melhor distribuídos ao longo das disciplinas do que ao longo das fases do modelo.

Alternativas
Comentários
  • As disciplinas do RUP estão muito próximas das fases do modelo em cascata tradicional.
  • Discordo plenamente do gabarito. o RUP é um modelo que substituiu o modelo em cascata. É, na verdade, um modelo iterativo-incremental.  Recurso na certa. 
  • Na verdade o RUP é um modelo iterativo e incremental. No entanto, acho que a questão quis dizer é que entre fase e disciplina o que mais está relacionado com o modelo em cascata (top-down) é o das disciplinas. Na verdade cada iteração (passagem pelas disciplinas) é um mini modelo em cascata.



    Só um adendo : "Uma passagem pelas quatro fases é um ciclo de desenvolvimento; cada passagem pelas quatro fases produz uma geração do software". A primeira passagem é o ciclo inicial de desenvolvimento, as demais são ciclos de evolução.
  • Pessoal, a questão nao está comparando RUP com Cascata, mas apenas enfatizando que as atividade tradicionais de desenvolvimento do Cascata (Negocios, Requisitos, A/P....etc) estão presentes no RUP como Disciplinas, e não como fases. Correto.
  • Gostaria apenas de acrescentar o que diz o Sommerville sobre o RUP 

    " As fases do RUP estão mais estritamente relacionadas aos negócios do que a assuntos técnicos"

    Logo, técnicas, métodos e ferramentas estão claramente mais envolvidos às disciplinas. Acredito que sabendo isso, daria pra facilitar a resposta.


ID
147724
Banca
FCC
Órgão
MPU
Ano
2007
Provas
Disciplina
Engenharia de Software
Assuntos

No Processo Unificado são, respectivamente, uma fase e um fluxo de trabalho:

Alternativas
Comentários
  • Fases do Ciclo de Vida do Processo Unificado: Concepção Elaboração Construção Transição Fluxos de Trabalho do Processo Unificado: Modelagem de Negócio (descreve a estrutura e a dinâmica da empresa) Requisitos (descreve o método baseado em casos de uso para identificar requisitos) Análise e Projeto (descreve várias visões da arquitetura) Implementação (leva em consideração o desenvolvimento do software, o teste da unidade e a integração) Teste (descreve casos de teste, procedimentos e medidas para acompanhamento de erros) Entrega (abrange a configuração do sistema a ser entregue) Gerenciamento da configuração (controla as modificações e mantém a integridade dos artefatos do projeto) Gerenciamento do projeto (descreve várias estratégias para o trabalho com um processo iterativo) Ambiente (abrange a infra-estrutura necessária para o desenvolvimento do sistema)
  •   a) ERRADO. Análise (Fluxo de trabalho) e Elaboração (Fase).

      b) ERRADO. Concepção (Fase) e Construção (Fase).

      c) ERRADO. Requisitos (Fluxo de trabalho) e Análise (Fluxo de trabalho).

      d) CORRETO. Construção (Fase) e Requisitos (Fluxo de trabalho).

      e) ERRADO. Análise (Fluxo de trabalho) e Requisitos (Fluxo de trabalho).


ID
147727
Banca
FCC
Órgão
MPU
Ano
2007
Provas
Disciplina
Engenharia de Software
Assuntos

No ciclo de vida do Processo Unificado, os testes têm seu apogeu demonstrado na linha divisória entre

Alternativas
Comentários


  • O engraçado é que no gráfico de Baleias parece que a atuação maior dos testes é na Elaboração e na Construção, e não na Construção e Transição.

  • Uma breve explicação sobre o comentário da colega Iara Schiavon:

    Segundo o RUP, testes estão espalhados por todas as fases do ciclo de vida, entretanto há uma ênfase ao final da fase CONSTRUÇÃO.

    Corroborando com a banca que o seu apogeu é na linha transitório entre construção e transição

    GABARITO ALTERNATIVA E


ID
148792
Banca
FCC
Órgão
TJ-SE
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

NÃO é um dos Core Process Workflows do RUP o

Alternativas
Comentários
  •  Os Core Process Workflows do RUP também são conhecidos como Disciplinas de Engenharia de software, são elas:

    1 - Modelagem do negócio
    2 - Requisitos
    3 - Análise e projeto
    4 - Implementação
    5 - Testes
    6 - Implantação

    As outras disciplinas do RUP são de suporte, listadas a seguir:

    7 - Gerência de projetos
    8 - Gerência de configuração e mudanças
    9 - Gerência de ambiente

  • Não é isso não.

    Os core process workflows são todas as 9 discplinas do RUP.
    Porém, essas se dividem em 6 core engineering workflows e 3 core supporting workflows.

    Ou seja, todas as opções são core process workflows, porém, dentre as mesmas, apenas 1 é um dos core supporting workflows.

    Tem jeito pra essa banca não.
  • A colocação do colega foi perfeita.

    Essa questão não tem resposta.

    Esta passagem extraída do manual da IBM corrobora isso:

    "There are nine core process workflows in the Rational Unified Process, which represent a partitioning of all 
    workers and activities into logical groupings.

    The core process workflows are divided into six core “engineering” workflows: 
    1.  Business modeling workflow 
    2.  Requirements workflow 
    3.  Analysis & Design workflow 
    4.  Implementation workflow 
    5.  Test workflow 
    6.  Deployment workflow 
    And three core “supporting” workflows: 
    1.  Project Management workflow 
    2.  Configuration and Change Management workflow 

  • o nome da disciplina é gerência de ambiente, e não ambiente, como colocado na questão.

  • Concordo com o comentário do Manoel Marcondes.


  • Seis Disciplinas Principais de Engenharia de Software (core business):

     

    1. Disciplina de Modelagem de Negócios[editar | editar código-fonte]

    2. Disciplina de Requisitos

    3. Disciplina de Análise e Projeto ("Design")

    4. Disciplina de Implementação

    5. Disciplina de Teste

    6. Disciplina de Implantação

     

    Três Disciplinas de Apoio/Suporte

    1. Disciplina de Ambiente

    2. Disciplina de Configuração e Gerência de Mudança

    3. Disciplina de Gerência de Projeto[editar | editar código-fonte]

     

    Fonte: https://pt.wikipedia.org/wiki/IBM_Rational_Unified_Process#Disciplinas

  • b)Environment.

    Core process workflows (engineering): 1-business modelling; 2- requirements 3- analysis & projeto 4- implementatio 5- tests 6- deployment

    core support workflows: a- project management; b- change configuration management; c- environment.

    Lembra quando disseram que RUP tem uma forte orientação ao negocio? é porque ele define que as disciplinas de negocio (nao-tecnicas) sao as que guiam a parte tecnica. é por isso que todas as disciplinas de suporte sao governança de melhores praticas, enquanto que engenharia é a parte tecnica


ID
148795
Banca
FCC
Órgão
TJ-SE
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

A maior porção da Configuration & Change Management do RUP encontra-se nas fases

Alternativas
Comentários
  • É só olhar a imagem abaixo:

    http://edn.embarcadero.com/article/images/33319/RUP.JPG
  • Além de saber a teoria sobre a matéria ainda temos que entender de inglês na mesma questão.

  • Acho totalmente desnecessário essa redação das questões da FCC misturando inglês com português. Para quê?
    Não se ve isso em outras bancas.
  •  d)Construction e Transition.

    As 2 fases finais do RUP têm como artifatos manuals de usuario, descrição do release, o produto de software ja integrado e o baseline final.

     


ID
148801
Banca
FCC
Órgão
TJ-SE
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

A Organization along content do RUP está estruturada em

Alternativas
Comentários
  • Após uma busca incançável do google por todas as páginas web no sistema solar, eis que surge o artigo de onde a Fundação Copia e Cola tirou o tal "Oraganization Along Content".

    http://www.cs.technion.ac.il/~tomera/publications/Iterative%20Development/Rafael_USDP_paper_SM_conf_2002.pdf
    Ver: p3 figura 3.1

    Querer a banca FCC entenda do estão falando é pedir demais... portanto, bola pra frente que essa foi chute pra todo mundo
  • Só no chute mesmo, pq eu não tinha visto esse termo até então.

     

  • http://www.augustana.ab.ca/~mohrj/courses/2000.winter/csc220/papers/rup_best_practices/rup_bestpractices.pdf

    p. 3
  • Letra: E

    Organization along Content: as 9 Disciplinas (process + supporting)

    Organization along Time: Fases e as iterações.



  • Questãozinha difícil. A manha pra responder (que foi recomendada por uma colega daqui do qconcursos e que realmente funciona) é usar da tradução.

    Organization along content se traduz para: Organização através de Conteúdo.
    No RUP, falou em conteúdo, falou em perspectiva estática, ou vertical. E, assim como o Ricardo disse, também se teria a Organização através do Tempo, em que se trata da perspectiva dinâmica.
    Fica ai essa dica simples, que já me ajudou um bocado e espero que ajude você também.
  • Questão maldita!


ID
148816
Banca
FCC
Órgão
TJ-SE
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

De acordo com o RUP, balancear objetivos, administrar riscos e superar restrições para entregar um produto que atenda às necessidades de clientes e usuários é papel do

Alternativas
Comentários
  • "...balancear objetivos, administrar riscos e superar restrições para entregar um produto que atenda às necessidades de clientes e usuários..."

    a) Gerente de Projetos: 
    Aloca recursos; Coordena a iteração com os clientes; Mantém a equipe focada aos objetivos do projeto; Cria prioridade no que deve ser feito.

    b) Analista de Sistemas: Coordena elicitação dos requerimentos e modelação dos casos de uso; Define as funcionalidades do sistema.

    c) Administrador de Dados: Não tem nada a ver com o enunciado da questão.

    d) Analista de Requisitos: Não aloca recursos e também não 
    administra riscos.

    e) Arquiteto de Software: Tem um visão do negócio como um todo (estratégica), não é focado em cada projeto da empresa/corporação.

ID
150388
Banca
FCC
Órgão
TJ-PA
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

O RUP é geralmente descrito por meio

Alternativas
Comentários
  • Será que o gabarito está correto?The process can be described in two dimensions, or along two axis: • The horizontal axis represents time and shows the dynamic aspect of the process as it is enacted, and it is expressed in terms of cycles, phases, iterations, and milestones. • The vertical axis represents the static aspect of the process: how it is described in terms of activities, artifacts, workers and workflows.
  • De acordo com o livro Engenharia de Software 8a edição no capitulo 4 que fala sobre o RUP são essas as 3 perspectivas:

    Dinâmica - Fases do modelo (Iniciação, Elaboração, Construção, Transição) no tempo Estática - Atividades dos processos (disciplinas - não estão associadas a uma única fase) Prática - Sugere boas práticas para serem usadas durante o processo
  • Essa questão deveria ser anulada, pois é passível de duas respostas!
  • O RUP apresenta três perspectivas:

     

    1. Perspectiva dinâmica: abordagem que trata o projeto em função do tempo, considerando questões importantes como iteratividade – onde o projeto é direcionado a partir de versões menores chamadas incrementos – e divisão de fases.

    2. Perspectiva estática: direciona o entendimento do projeto a partir de uma série de disciplinas – ou workflows – associadas às fases dinâmicas, além de atividades de apoio – necessárias em todo o projeto.

    3. Perspectiva prática: onde são definidas boas práticas a serem executadas em todos os processos de software.

     

    Fonte: http://linu.com.br/papers/paper042.html

  •  e)das perspectivas dinâmica, estática e prática.

    Perspectivas do RUP: dinamica ( as fases da modelagem); estatica (atividades) & praticas (as boas praticas). As perspectivas dinamicas sao geralmente combinadas em 1 so workflow, o que define as 4 fases do RUP: concepção, elaboraçao, construção, transição

     


ID
150391
Banca
FCC
Órgão
TJ-PA
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Considere os artefatos de software abaixo.

I. Protótipo arquitetural executável.

II. Descrição da arquitetura.

III. Produto de software integrado na adequada plataforma.

A correta e respectiva associação desses artefatos com as fases do RUP é

Alternativas
Comentários
  • Bom, um protótipo arquitetural executável é uma das possíveis formas da Prova de Conceito Arquitetural (que pode ser, também, uma descrição detalhada, uma lista de frameworks, um esboço de modelo, uma simulação, etc.), que resulta da atividade Construir Prova de Conceito Arquitetural. A atividade pertence à disciplina de Análise e Design e é executada durante a Iniciação. Assim sendo, a resposta A não pode ser a correta (ou única correta), pois associa o item I à fase de Elaboração (não que o artefato não esteja nela também). A alternativa C também seria uma candidata.
  • Iniciação
    * Ênfase do Escopo
    * Propor arquitetura, que deve ser consolidada em Elaboração.
    * Discriminar os cenários críticos para serem implementados na Elaboração.


    Elaboração
    * Ênfase na Arquitetura
    * Protótipo Arquitetural Executável - Implementar cenários críticos discrimidados em Iniciação

    Construção
    * Ênfase em Implementação.
    *  Produto completo desenvolvido, de forma interativa e incremental.
    * Modelo de projeto completo e plano de procedimento de teste.

    Transição
    * Ênfase em Testes - Garantir que o sistema apresenta um nível adequado de qualidade
    * Entrega de um release do projeto
  •  Fase de CONCEPÇÃO
    - Documento de visão
    - Modelo inicial do caso de uso ( de 10 a 20%)
    - Glossário do projeto
    - Definiçaõ de objetivos e viabilidade do projeto
    - Avaliação inicial dos riscos
    - Plano de projeto com fases e interações
    - Modelo de negócio, se necessário
    - Protótipo(s)
    Fase de ELABORAÇÃO
    - Modelo de caso de uso
    - Requisitos não funcionais
    (II) Descrição da arquitetura do software
    (I)  Protótipo arquiteturais executáveis
    - Revisão da visão do negócio e linha de risco
    - Plano detalhado do desenvolvimento do projeto
    - Plano de processo de desenvolvimento
    - Manual do usuári preliminar
    Fase de CONSTRUÇÃO
    (III) O produto descrito e integrado na plataforma adequada.
    Fase de TRANSIÇÃO
    - Incremento do software entregue
    - Relatório de teste beta
    - Realimentação geral do usuário

ID
150934
Banca
CESGRANRIO
Órgão
Petrobras
Ano
2008
Provas
Disciplina
Engenharia de Software
Assuntos

Um princípio fundamental do Processo Unificado é

Alternativas
Comentários
  • O processo unificado não é em cascata, pois é iterativo e incremental;

    Programação em pares é característica de desenvolvimento ágil;

    Não necessariamente o código deve ser propriedade coletiva, não faz diferença;

    O foco do UP é possuir um arquitetura para a construção do software.

  • Fundamentos Processo Unificado de Desenvolvimento - RUP
    • ORIENTADO A DIAGRAMA DE CASO DE USO:
      • Sequencia de ações de um sistema que devolve um resultado de valor.
      • Conjunto de casos de uso = diagrama de caso de uso
      • Define a funcionalidade do sistema
    • CENTRADO NA ARQUITETURA DO SISTEMA
      • Visão do Projeto como um todo, destacando suas características mais importante de forma abrangente e sem detalhes específicos 
    • METODOLOGIA ITERATIVA E INCREMENTAL
      • Pode ser entendida como uma mini-projeto que resulta em uma nova versão do sistema
      • Cada iteração gera uma versão
  • Até onde eu sei é ser centrado em componentes.

  • a) ser centrado em arquitetura.- unified process

    b)empregar times auto-dirigidos e auto-organizados. - scrum

    c) o desenvolvimento em cascata. - waterfall model

    d) a programação em pares. - Extreme Programming (XP)


ID
150937
Banca
CESGRANRIO
Órgão
Petrobras
Ano
2008
Provas
Disciplina
Engenharia de Software
Assuntos

O modelo de casos de uso é um dos artefatos mais importantes previstos pelo Processo Unificado. Sobre o modelo de casos de uso, são feitas as afirmativas a seguir.

I - Atores humanos são identificados com base no papel que desempenham do ponto de vista do sistema, e não necessariamente no cargo que ocupam na instituição em que o sistema rodará.

II - A evolução dos casos de uso ao longo do ciclo de vida do projeto prevê que os mesmos ganhem em seu texto os detalhes específicos de implementação necessários à construção do software na tecnologia adotada.

III - As combinações possíveis do fluxo principal com os fluxos alternativos de um caso de uso fornecem todos os cenários possíveis para o mesmo, os quais, por sua vez, podem ser utilizados como unidades de planejamento, implementação e testes.

IV - É recomendável que cada caso de uso seja decomposto funcionalmente e passe a incluir casos de uso menores, sucessivamente, até a menor unidade implementável possível, atendendo ao princípio da decomposição funcional.

Estão corretas APENAS as afirmativas

Alternativas
Comentários
  •  II - não está certo colocar que um caso de uso irá representar detalhes de implementação

    IV - não é necessário dividir um caso de uso até a menor unidade implementável, os casos de uso críticos são implementados.

  • I. Correto! Pessoas e sistemas são respresentados pelos atores.
    II. Errado! Detalhes técnicos, como tecnologias adotadas não fazem parte dos casos de uso;
    III. Correto! Fluxos principais e alternativos são os passos-a-passo de todas possibilidades do caso de uso.
    IV. Errado! A decomposição só ocorre caso o caso de uso seja muito complexo.
  • De acordo com o RUP (http://www.wthreex.com/rup/portugues/index.htm):

    Caso de Uso (classe)
    Uma descrição de comportamento do sistema em termos de seqüências de ações. Um caso de uso deve produzir um resultado de valor observável para um ator. Ele contém todos os fluxos alternativos de eventos referentes à produção do "resultado de valor observável".
    Mais formalmente, um caso de uso define um conjunto de instâncias de casos de uso ou cenários.


    Ator
    Alguém ou algo fora do sistema que interage com ele.

    Sobre Visão de Caso de Uso:
    Para fornecer uma base para o planejamento do conteúdo técnico de iterações, uma visão de arquitetura chamada visão de casos de uso é utilizada na disciplina Requisitos. Só existe uma visão de casos de uso do sistema, que ilustra os casos de uso e cenários que englobam o comportamento, as classes ou os riscos técnicos significativos do ponto de vista da arquitetura. A visão de casos de uso é refinada e considerada inicialmente em cada iteração.

     
    Especificação de uma seqüência de ações (incluindo variantes) que um sistema (ou outra entidade) pode executar, interagindo com atores do sistema. Consulte instância de caso de uso, cenário.

ID
150943
Banca
CESGRANRIO
Órgão
Petrobras
Ano
2008
Provas
Disciplina
Engenharia de Software
Assuntos

A atividade analisar um caso de uso, prevista no Processo Unificado, produz um artefato chamado realização de análise de caso de uso, que mostra como as classes de análise colaboram para que o caso de uso apresente o comportamento especificado. A esse respeito, assinale a afirmação correta.

Alternativas
Comentários
  • Acredito que só pelo fato do Diagrama de Classes não ser um diagrama comportamental e sim estrutural, invalida a questão de interação.
  • Erro da letra  c): A interação entre as classes são expressas em um diagrama de interação (ex: diagrama de sequência) e não no diagrama de classes.
  • Para mim, o erro na letra "C" está na fato onde a banca define "A interação entre as classes de análise é expressa PRIMARIAMENTE através de diagramas de classes UML", ao meu ver essa interação entre classes não é representada através de diagramas de classes somente primariamente e sim algo frequente, constante em todo o momento do projeto. 

ID
150946
Banca
CESGRANRIO
Órgão
Petrobras
Ano
2008
Provas
Disciplina
Engenharia de Software
Assuntos

Sobre testes no Processo Unificado, é correto afirmar que um(a)

Alternativas
Comentários
  • A) Um plano de teste contém um conjunto de classes de testes. Dentro do plano de teste, há os casos de testes, que são os testes esolhidos dentro de uma classe. Quando se escolhe um plano de teste e casos de teste, se está querendo abranger ao máximo o software à procura de erros. Você estará abrangendo os requisitos funcionais e os não-funcionais - como usabilidade, p. ex.

    Assim, a alternativa inverte as definições.

    B) Script de teste: Instruções passo a passo que permitem a execução de um teste. Os Scripts de Teste podem assumir a forma de instruções de texto documentadas e executadas manualmente ou de instruções que podem ser lidas pelo computador para ativar a execução automática do teste.

    C) Não conheço modelos de testes de software, mas somente Estratégias de teste de software (teste unitário, teste de integração e validação).

    D) prova de conceito não é um tipo de caso de teste. Caso de teste, como já dito, vem a ser teste que você aplica ao software. O caso de teste deve especificar a saída esperada e os resultados esperados do processamento. Numa situação ideal, no desenvolvimento de casos de teste, se espera encontrar o subconjunto dos casos de teste possíveis com a maior probabilidade de encontrar a maioria dos erros

    E) CORRETA - A avaliação de um teste de software é baseada na sua cobertura dos requisitos e casos de teste - ou seja, erros encontrados - ou pela cobertura do código.
  • Só completando a resposta de Wilson:

    Prova de conceito é um documento arquitetural. O nome completo é 'Prova de conceito arquitetural'.
    Esse artefato é criado para determinar uma solução para requisitos críticos. Pode ser dispensado quando os riscos são considerados baixos.

    Ou seja, nada a ver com testes.
  • Retificando a Letra A que comentei...

    Um plano de teste se encontra dentro da estratégia de teste. O plano de teste tem as classes de teste que serão executadas. Algumas classes de testes são teste unitário, teste de integração e teste de sistema. Dentro de cada classe há os casos de teste. Por exemplo, uma classe de teste unitário tem casos de teste ue executa os caminhos independentes do módulo, a sua interface, sua estrutura de dados interna, o fluxo de controle, dentre outros.

    Assim, um plano de teste tem classes de teste que têm casos de teste, tudo dentro de uma estratégia de teste.

  • Complementando a letra B...

    Script de teste vem a ser a estratégia de teste que comentei rapidamente na letra A.
  • FLUXO DE TESTE
    Principal proposito do fluxo de teste é realizar vários teste e sistematicamente analisar os resultado de cada teste
    Verificar se os resultados do fluxo de implementação cumprem os requisitos estipulados p/ cliente e usuários.
     
    MODELO DE TESTE
    É a principal ATIVIDADE
    Descreve como os teste de integração e de sistema exercitarão componentes executáveis a partir do modelo de implementação.
     
    CASO DE TESTE
    Conjunto de entradas, condições de execução e resultados esperados.
    Juntos identificam a finalidade de avaliar um determinado aspecto de um item de teste-alvo
     
    PLANO DE TESTE
    Definição das metas e dos objetivos dos testes no escopo
     
    SCRIPT TESTE
    Conjunto de instruções passo a passo que permitem a execução de um teste.
     
    PROVA DE CONCEITO
    É a prova de uma teoria, que só existia no papel
     
    AVALIAÇÃO DE TESTE
    É a avaliação dos resultado de um conjunto de testes.

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
158032
Banca
FCC
Órgão
METRÔ-SP
Ano
2008
Provas
Disciplina
Engenharia de Software
Assuntos

Representar a arquitetura de software em várias visões, utilizando vários modelos, produz um resultado mais consistente uma vez que há muita informação dissociada para retratar em um único modelo. Nesse sentido considere os itens abaixo, relativos aos principais esquemas de visões:

I. Um esquema que ressalta, em separado, os detalhes estático, dinâmico e funcional dos objetos identificados no sistema, ou seja, cada objeto possui sua estrutura e sua descrição definidas do ponto de vista estático, dinâmico e funcional.
II. As visões determinam uma seqüência de atividades que ocorrem no tempo, ou seja, uma evolução incremental dos conceitos do negócio e suas representações. Primeiro devem ser pensados os detalhes da visão lógica para, em seguida, se pensar nos detalhes da visão física. As semânticas determinam as representações estática e dinâmica de ambas as visões.
III. Um esquema onde as visões são coordenadas com o objetivo de representar a arquitetura como um modelo de abstração que possui o foco na estrutura nos elementos essenciais, sugerindo a notação UML [Booch98] como principal mecanismo de representação dos propósitos das visões. IV. Um esquema onde vários propósitos são atendidos pelas visões, tais como, abordar a organização lógica do sistema, organizar suas funcionalidades, abordar os aspectos de concorrência e descrever a distribuição física do software na plataforma utilizada. As visões se dividem em lógica, de processo, de desenvolvimento, de implementação e de casos de uso.

Os itens acima referem-se, respectivamente, às visões

Alternativas
Comentários
  • A afirmativa IV) fala das visões 4 + 1, no entanto está faltando a visão de implantação.  A alternativa cita visão lógica, de processo, de desenvolvimento (que para mim é a de implementação) e a de implementação (acho que aqui deveria ser implantação!).



ID
161773
Banca
FCC
Órgão
TRF - 5ª REGIÃO
Ano
2008
Provas
Disciplina
Engenharia de Software
Assuntos

O RUP possibilita o desenvolvimento

Alternativas
Comentários
  • O correto seria ser iterativo, isto é, repetitivo.
  • iterativo e incremental, premissa básica quando se pensa em rup.

  •  interativo? Serio mesmo FCC? 

     

    O correto 'e ITERATIVO!!!

  • Pode ter sido erro na hora de colocar os dados da questão aqui no site. Ou erro mesmo da FCC e sendo, dificilmente eles anulam questões assim.
  • Na prova está INTERATIVO... bizarro:
    http://questoesdeconcursos.com.br/prova/arquivo_prova/1020/fcc-2008-trf-5a-regiao-analista-judiciario-tecnologia-da-informacao-prova.pdf

    Welkson
  • Iterativo é que itera, se repete.
    Interativo é que interage, comunicação bidirecional.
    O RUP assume essas duas características básicas.
  •  a)incremental e interativo, guiado por casos de uso e centrado na arquitetura do sistema. 

    palavras-chave do RUP (rational unified process) arquitetura baseada em componentes, caso de uso (UML), iterações baseadas em workflow que terminam em milestones;.


ID
161785
Banca
FCC
Órgão
TRF - 5ª REGIÃO
Ano
2008
Provas
Disciplina
Engenharia de Software
Assuntos

No RUP, desde a concepção do sistema é definido um padrão de construção dos componentes que, inicialmente, visa elaborar,

Alternativas
Comentários
  • Uma prévia da arquitetura do sistema já é criada na fase de iniciação, e continua sendo melhorada na fase de elaboração que será concluída sendo chamada de arquitetura estabilizada.

  •   Muitos de nós caimos em questões que citam uma arquitetura candidata na fase de concepção, porém esta arquitetura é realmente definida na concepção(fazendo parte da definição do escopo do projeto de software) e ela será consolidada na elaboração que possui o marco de concluí-la como uma espinha dorsal do sistema(não inteiramente completa devido ao processo ser iterativo incremental) e é implementada em sua completude na fase de construção.

  • É só lembrar que o RUP é centrado em arquitetura.
  • alguém pode me explicar porque não é a letra B
  • Olá,

    Sobre a alternativa B, não vi um sentido completo na assertiva "a estrutura de negócios". A idéia ficou meio confusa.

    Mesmo que nós consideremos como "regras de negócio" ou "casos de negócio", ainda assim não estaria de acordo com o que o enunciado pede: definir um padrão de construção dos componentes, na fase de concepção, não visa a elaborar as regras de negócio. Visa a iniciar a construção da arquitetura.
  • RUP é baseado nos seguintes principios:

    casos de uso

    arquitetura no centro do planejamento

    ciclos iterativos & incrementais

  • O que alguns pensaram ao marcar letra (B) é achar que o marco da fase de Concepção está na na "Estrutura de Negócios". Contudo, o marco dessa fase é definir o objetivo do ciclo de vida que busca a viabilidade básica do projeto.


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

A maior parcela do fluxo dos processos fundamentais do RUP, correspondente à modelagem de negócio,

Alternativas
Comentários
  • A modelagem do negócio começa na fase de iniciação e continua na fase de elaboração. Portanto, letra D é a alternativa correta.

  • http://static.infoescola.com/wp-content/uploads/2010/03/graficoRUP.jpg
  • d

    O artefato da concepção é a modelagem de negocio e planod e projeto, o qual continua na elaboração

    https://marquera.files.wordpress.com/2009/06/rup_lifecycle.jpg


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

Conforme proposto originalmente, o Processo Unificado é dividido em diversas fases, e em cada uma delas podem ser realizadas atividades de diferentes fluxos de trabalho (workflows), em diferentes proporções. A característica que NÃO se aplica a esse processo é ser

Alternativas
Comentários
  • Modelo Prescritivo retrata como um processo deveria ser executado, o que é o objetivo do PU.

    Modelo Descritivo diz como um processo é executado.

  • O PU é guiado por casos de uso.
  • Existem dois tipos de modelos: os adaptativos, que são fundados nos modelos ágeis, os quais possuem uma cultura que demanda menor ordem de desenvolvimento e um pequeno número de desenvolvedores experientes. E os modelos prescritivos, que se baseiam em modelos com uma cultura que exige maior ordem e com grande número de desenvolvedores.

    Por conseguinte, o modelo de desenvolvimento RUP ou simplesmente UP, utiliza princípios/características de modelos prescritivos.
  • Aspectos

    Os aspectos que distinguem o processo unificado são três conceitos chave, a saber:

    • direcionado a casos de uso;
    • centrado na arquitetura;
    • iterativo e incremental.
  • O Processo Unificado não é guiado por testes de aceitação.
  • Características do PU

     

    Iterativo e Incremental

     

    O Processo Unificado é um processo Iterativo e Incremental. As fases de Elaboração, Construção e Transição são divididas em uma série de interações. (A fase de Iniciação também pode ser dividida em iterações para grandes projetos). Cada iteração resulta em um incremento, que é uma versão do sistema que contém funcionalidades adicionais ou melhoradas em comparação com a versão anterior.

     

    Dirigido por Casos de Uso

     

    No Processo Unificado, Casos de Uso são usados para capturar requisitos funcionais e refinar o conteúdo das iterações. Cada iteração tem um conjunto de casos de uso ou cenários de requisitos durante todo o tempo de implementação, teste e desenvolvimento.

     

    Centrado na Arquitetura

     

    O Processo Unificado insiste que a Arquitetura deve estar no centro dos esforços da equipe do projeto, para dar forma ao sistema. Uma vez que não existe um modelo único suficiente para cobrir todos os aspectos do sistema, o Processo Unificado suporta múltiplas visões e modelos arquiteturais.

    Uma das entregas mais importantes do processo é a arquitetura executável, que é criada durante a fase de Elaboração. Esta implementação parcial do sistema serve para validar a arquitetura e atuar como uma base para o desenvolvimento do restante.

     

    Focado no Risco

     

    O Processo Unificado requer que a equipe do projeto concentre-se em enfrentar os Riscos mais críticos no início do ciclo de vida do projeto. As entregas de cada iteração, especialmente na fase de Elaboração, devem ser selecionadas de forma a garantir que os maiores riscos sejam tratados em primeiro lugar.

     


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

Uma das características do Processo Unificado (Unified Process) é ser dirigido a casos de uso (use case driven). Nesse contexto, analise as afirmações a seguir.

O modelo de casos de uso representa o comportamento de um sistema, conforme percebido do ponto de vista externo a esse sistema.

PORQUE

A construção do modelo de classes conceituais de um sistema pode usar como ponto de partida o modelo de casos de uso.

A esse respeito, conclui-se que

Alternativas
Comentários
  • Questão igual a "Q54557 "
  • Entendi  "modelo de classes conceituais do sistema" como a perspectiva conceitual do diagrama de classe, onde as classes são conceitos do mundo real, e não as classes do sistema propriamente.

     

    http://www.dsc.ufcg.edu.br/~jacques/cursos/apoo/html/anal1/anal1.htm

  • O Modelo Conceitual do Diagrama de Classes é um artefato do domínio do problema e não do domínio da solução, portanto, não é utilizado para especificação da arquitetura do sistema. Ele é formado pelos conceitos obtidos a partir da análise textual da definição do problema (enunciado do problema e casos de uso), atibutos e associações.


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

Sobre o ciclo de vida de um projeto, segundo o RUP, analise as afirmativas a seguir.

I - Na fase de execução, a equipe do projeto junto com o gerente de projeto vai resolver conflitos sobre prioridades, custos, recursos de mão de obra, opiniões técnicas e performance do produto.

II - Na fase de controle, o escopo deve ser especificado com critérios rígidos, pois uma alteração do escopo na fase de controle aumenta o custo do projeto na fase de planejamento.

III - Na fase de início, os custos e recursos utilizados devem ser previstos para começar em níveis baixos, sendo que, em algum momento da fase de execução, eles alcançarão o seu valor máximo .

Está correto o que se afirma em

Alternativas
Comentários
  • Detro do RUP existe uma disciplina de suporte chamada Gerenciamento de Projetos. É a ela que esta questão se refere. No entanto, não achei nenhuma correlação entre estas fases mencionadas na questão e as fases presentes no RUP.

    A Cesgranrio deve ter tirado isso de algum Artigo obscuro da internet ou então ela fez alguma analogia/adaptação com outra metodologia que eu ainda não identifiquei.
  • Questão sem sentido!
    realmente não entendi.
  • Fases

    Iniciação
     (ou Concepção), Elaboração, Construção e Transição
  • O que acontece é que no RUP existe uma disciplina Gerenciamento de Projetos ou Gerência de Projetos. Existem algumas boas práticas no mercado que auxiliam essa disciplina, podemos citar no caso o PMBOK. Esse conjunto de práticas definem fases:
    • Iniciação
    • Planejamento
    • Execução
    • Monitoramento e controle
    • Encerramento
    Essas fases não têm a ver com cada fase do RUP que são: Concepção, Elaboração, Construção e Transição. Utilizaremos essas fases de acordo com os marcos definidos dentro de cada fase do RUP.

    II - Na fase de controle, o escopo deve ser especificado com critérios rígidos, pois uma alteração do escopo na fase de controle aumenta o custo do projeto na fase de planejamento.

    Na fase Monitoramento e controle não especificamos o escopo.
    Num processo com ciclo de vida iterativo e incremental é impossível fecharmos o escopo por completo como é feito no ciclo de vida cascata.
    Acontece que na fase de controle, segundo o PMBOK, podemos ter modificações no escopo e essas mudanças deverão ser controladas e estar em consonância com todas as partes interessadas. Isso impactará diretamente na tríplice restrição(escopo, custo, tempo).
  • I - Na fase de execução, a equipe do projeto junto com o gerente de projeto vai resolver conflitos sobre prioridades, custos, recursos de mão de obra, opiniões técnicas e performance do produto.  (CERTO)
     
    II - Na fase de controle, o escopo deve ser especificado com critérios rígidos, pois uma alteração do escopo na fase de controle aumenta o custo do projeto na fase de planejamento.  (NÃO EXISTE A FASE CONTROLE NO RUP - ERRADO)
     
    III - Na fase de início, os custos e recursos utilizados devem ser previstos para começar em níveis baixos, sendo que, em algum momento da fase de execução, eles alcançarão o seu valor máximo .  (CERTO)
  • É praticamente uma questão sobre gerenciamento de projetos. A citação do RUP é só uma pegadinha de mal gosto para confundir o candidato.



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

O RUP, Processo Unificado da Rational, é dividido em fases e atividades, sendo que

Alternativas
Comentários
  • Fases: iniciação, elaboração, construção e transição

    Atividades: modelagem de negócios, requisitos, análise e projeto, implementação, testes, implantação, ambiente, gerencia de projeto e configuração e mudanças.

  • a) a primeira fase do RUP que corresponde ao levantamento de requisitos é também chamada de concepção.

    Várias disciplinas são executadas nesta fase, inclusive o levantamento de requisitos. A principal saída desta fase é o escopo do sistema.

    b) o início da fase de análise depende do levantamento de requisitos, que devem ser estáveis e bem documentados.

    Análise é uma disciplina do RUP.

    c) ao término da fase de concepção, um dos artefatos produzidos é um documento de visão refinado.

    O documento de visão é criado na fase de concepção e refinado posteriormente.

    d) na fase de construção, a atividade de análise já foi concluída e o foco é a implementação.

    A disciplina/atividade de análise se estende por toda a fase de construção, tendo seu declínio em termos de ênfase na fase de transição.

    e) cada fase é dividida em uma ou mais iterações e, ao final de cada interação, artefatos são necessariamente validados.

    Opção correta

  • Ao final de cada iteração algum artefato deverá ser gerado, senão não foi uma iteração. A quantidade de iterações por fase esta logo abaixo:
    • Concepção: 1
    • Elaboração: 2
    • Construção: 1 ou mais
    • Transição: 2
  • Para ratificar a opção (E) como correta.

    e) cada fase é dividida em uma ou mais iterações e, ao final de cada interação, artefatos são necessariamente validados.

    Iteração é algo que se itera, se repete.Cada passagem pelas disciplinas é definido como uma iteração. Como as fases contém pelo menos uma disciplina, cada fase é dividida em uma ou mais iterações.

    Interação é comunicação bidirecional, interagir. Os interessados e a equipe de engenharia de software interagem, apresentando os artefatos, que são então validados.
  • Questão deveria caber recurso.
    A opção a) não contém erros.
    E a opção e) troca iteração por interação. Ao final de cada iteração artefatos são validados.
    O final de cada interação seria uma comunicação interna da equipe, gerente de projetos com cliente, etc. artefatos não precisam ser validados.
  • Manoel, se a letra "a" fosse "a primeira fase do RUP que corresponde UNICAMENTE ao levantamento de requisitos é também chamada de concepção.", eu concordaria ctg. 

  • e

    Os artefatos devem ser testados no final de cada iteração porque um artefato validado é necessario p/ continuar a proxima fase do RUP. 

  • a)a primeira fase do RUP que corresponde ao levantamento de requisitos é também chamada de concepção.[ERRADO. A primeira fase não corresponde NECESSARIAMENTE ao levantamento de requisitos, a fase de concepção contém outras disciplinas relevantes, como Análise e Design e Modelagem de Negócios]
    b)o início da fase de análise depende do levantamento de requisitos, que devem ser estáveis e bem documentados.[ERRADO. O modelo em Cascata que exige requisitos estáveis, não o RUP]
    c)ao término da fase de concepção, um dos artefatos produzidos é um documento de visão refinado.[ERRADO.O documento de visão é refinado após CADA ITERAÇÃO, não apenas da fase de Concepção]
    d)na fase de construção, a atividade de análise já foi concluída e o foco é a implementação.[ERRADO. A disciplina Análise está presente em mais de uma fase]
    e)cada fase é dividida em uma ou mais iterações e, ao final de cada interação, artefatos são necessariamente validados.[CORRETO]


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

A análise de risco no RUP é algo constante nas diversas fases do processo de desenvolvimento. Em cada uma das fases, o foco da gerência de riscos se diferencia em função do objetivo de cada fase. Assim, a manipulação dos riscos está relacionada, na fase de

Alternativas
Comentários
  • Uma arquitetura deverá ser pensada de tal forma que evite quaisquer riscos durante o projeto. Caso um risco ocorrá em outra fase, será mais dificil controlá-lo, pois não havia sido planejado.
  • a) análise, ao refinamento do modelo de requisitos e à sua possível alteração. ANALISE é disciplina e não fase
    b) construção, à instalação e distribuição do produto no ambiente do cliente. Instalação e distribuição são associadas a fase de transição c) transição, à logística, uma vez que é a fase que envolve o maior número de profissionais. Apesar de não haver conscenso, pois o número de profissionais envolvidos em cada fase de projeto depende muito da natureza deste, EM GERAL, a fase que envolve o maior número de profissionais é a construção. d) requisitos, à modelagem de negócio. Requisitos é disciplina e não fase e) elaboração, a questões técnicas, envolvendo a arquitetura escolhida. CORRETO!

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

Em relação ao Unified Process (UP), considere as seguintes atividades:

I - utilização como um "framework" que se baseia em componentes, o qual modela os processos de forma iterativa e incremental;

II - atuação no direcionamento do desenvolvimento de várias maneiras, criando mecanismos, por exemplo, para a validação da arquitetura do sistema;

III - utilização dos artefatos de construção de sistema para facilitar a reusabilidade dos componentes do sistema.

A(s) atividade(s) necessária(s) para transformar requisitos do usuário em um sistema de software é (são)

Alternativas
Comentários
  • Reusabilidade (III) é NECESSÁRIO para transformar requisitos em sistema de software?
  • Rodrigo, onde vc viu "Necessário" no item III?
    Onde vc viu  
  • No enunciado... =)

    A(s) atividade(s) necessária(s) para transformar requisitos do usuário em um sistema de software é (são)
  • Eu marquei letra (A) como resposta.
    Não entendi a questão.
    Algum comentário pertinente?
  • Respondi letra (E) mesmo, mas nem considerei o enunciado:
    "A(s) atividade(s) necessária(s) para transformar requisitos do usuário em um sistema de software é (são)"
    Avaliei o que o RUP abrange.


     

  • A I e III eu achei corretas, mas na II ficou confuso o "...desenvolvimento de várias maneiras...".

    Alguma explicação para a II ?



  • Eu entendi  "... de várias maneiras..." como em várias formas durante etapas do desenvolvimento de software, desde a Concepção até a Transição.
  • I - utilização como um "framework" que se baseia em componentes, o qual modela os processos de forma iterativa e incremental; 

    A utilização de componentes permite o utilização do reuso. Consite portanto em partes do software, que quando juntas, podem formar um sistema maior.

    II - atuação no direcionamento do desenvolvimento de várias maneiras, criando mecanismos, por exemplo, para a validação da arquitetura do sistema; 

    No RUP temos na fase da elaboração como resultado final: uma arquitetura de software estabilizada. A estabilidade da arquitetura pode ser adquirida de diversas maneiras. Via de regra, são atacados os requisitos de maiores risco, pois eles são responsáveis por um desenho de arquitetura de sistema de maneira fiel.


    III - utilização dos artefatos de construção de sistema para facilitar a reusabilidade dos componentes do sistema. 

    Com o uso destes artefatos, na etapa de elaboração, pode ser analisada de maneira mais criteriosa os possíveis componentes do sistema. Tais elementos são genéricos, podendo fazer parte de outros sistemas (reuso).
  • @Eduardo Haddad: fui na mesma linha. Vi ali o enunciado e ficou tudo muito confuso, já que 'necessário' é uma palavra forte. Desconsiderando deu para marcar melhor.

  • Péssima questã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
163678
Banca
CESGRANRIO
Órgão
Petrobras
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Uma das características do Processo Unificado (Unified Process) é ser dirigido a casos de uso. Nesse contexto, analise as afirmações a seguir.

O modelo de casos de uso representa o comportamento de um sistema, conforme percebido do ponto de vista externo a esse sistema.

PORQUE

O modelo de classes conceituais de um sistema pode ser obtido a partir do modelo de casos de uso.

A esse respeito, conclui-se que

Alternativas
Comentários
  • Questão identica a "Q54345"
  • Primeira alternativa correta, justificativa:
        A criação destes diagramas deve ser feita de uma maneira completamente fechada, ou seja, assumindo que o actor não tem conhecimento sobre o estado interno do sistema quando acessa uma dada funcionalidade. Devendo as iterações ser descritas do ponto de vista externo. Esta forma de encarar a descrição de iteração simplifica a descrição dos requisitos evita falsas assumpções sobre como a funcionalidade será implementada no sistema. (fonte: http://pt.wikipedia.org/wiki/Caso_de_uso)

    A segunda nao encontrei nenhuma referencia.
  • Explicação para definição do diagrama de classe através do diagrama de caso de uso.

    3.1 Definição das Classes por Caso de Uso
       A definicão de classes por partes significaria, em uma abordagem estruturada, estudar as classes dividindo-se o sistema em módulos ou subsistema. Na orientação a objetos, e em particular na UML, sugere-se que o levantamento das classes do sistema seja feita por caso de uso. Desta forma, tomaria-se isoladamente cada caso de uso para definição das classes necessa rias a sua implementação. 
      Nesta abordagem, não se deve considerar os casos de uso como subsistemas. Embora, o levantamento das classes seja feito por caso de uso, elas não são exclusivas de certos casos de uso. Uma mesma classe pode ser empregada em mais de um caso de uso com o mesmo ou com papéis diferentes.

    http://www.etelg.com.br/paginaete/downloads/informatica/apostila2uml.pdf
  • Errei a segunda afirmação devido ao uso da palavra modelo em negrito. Não deveria ser diagrama?
    O modelo de classes conceituais de um sistema pode ser obtido a partir do modelo de casos de uso.


ID
163966
Banca
FCC
Órgão
TJ-PI
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

É um processo de desenvolvimento de software que oferece uma forma sistemática para construir um tipo de sistema que usa a arquitetura baseada em componentes; pode ser facilmente extensível, promovendo a reutilização de software e um entendimento intuitivo; define tanto métodos para controlar e monitorar mudanças quanto áreas de trabalho seguras, garantindo a um programador que as mudanças efetuadas em outro sistema não afetarão o seu sistema. Trata-se do processo

Alternativas
Comentários
  • É o RUP que é composto por fases: iniciação, elaboração, construção e transição;

    e disciplinas, sendo elas: modelagem do negócio, requisitos, análise e projeto, implementação, testes, implantação, configuração e mudanças, gerencia do projeto e ambiente.

  • Resposta certa letra A

    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.
    Fonte: http://www.wthreex.com/rup/portugues/index.htm
  • O RUP é baseado em um conjunto de princípios de desenvolvimento de software e melhores práticas, por exemplo:

    1. Desenvolvimento de software iterativo
    2. Gerenciamento de requisitos
    3. Uso de arquitetura baseada em componente
    4. Modelagem visual de software
    5. Verificação da qualidade do software
    6. Controle de alteração no software



    Uso de arquitetura baseada em componentes

    Arquitetura baseada em componentes cria um sistema que é facilmente extensível, intuitivo e de fácil compreensão e promove a reusabilidade de software. Um componente freqüentemente se relaciona com um conjunto de objetos na programação orientada ao objeto.




    Gestão e Controle de Mudanças do Software

    Em todos os projetos de software a existência de mudanças é inevitável. O RUP define métodos para controlar e monitorar mudanças. Como uma pequena mudança pode afetar aplicações de formas inteiramente imprevisíveis, o controle de mudanças é essencial para o sucesso de um projeto.

    O RUP também define áreas de trabalho seguras, garantindo a um programador que as mudanças efetuadas noutro sistema não afetarão o seu sistema.



    Referência: pt.wikipedia.org/wiki/IBM_Rational_Unified_Process#Controle_de_altera.C3.A7.C3.B5es_no_software



    http://pt.wikipedia.org/wiki/IBM_Rational_Unified_Process#Controle_de_altera.C3.A7.C3.B5es_no_software  .http://pt.wikipedia.org/wiki/IBM_Rational_Unified_Process#Controle_de_altera.C3.A7.C3.B5es_no_softwarept.wikipedia.org/wiki/IBM_Rational_Unified_Process#Controle_de_altera.C3.A7.C3.B5es_no_software

  • palavras-chave do RUP - mudanças & componentes.

    RUP (rational unified process) tem 3 perspectivas: dinamica (os estagios do modelo), estatica (atividades) & pratica, o qual inclui: desenvolvimento iterativo, gerenciamento de requisitos, arquitetura vaseada em componentes, modelo de software, verificação de qualidade e controle de mudanças.


ID
178789
Banca
VUNESP
Órgão
CETESB
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Em RUP, a integração contínua, no contexto do ciclo de vida iterativo, significa

Alternativas
Comentários
  •  b)integração no fim de cada iteração.

    EM RUP os artefatos devem ser validados a fim de serem usados na fase seguinte para produzir novos artefatos que irao medir o progresso do projeto. A integração continua significa que os artefatos devem seguir a politica de centralização de arquitetura de componentes do RUP

  • Há ferramentas que efetuam a integração contínua com realização de testes unitários(JUnit) a cada ciclo de iteração, tais como o Jenkins


ID
178792
Banca
VUNESP
Órgão
CETESB
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Em RUP, a iteratividade ajuda no gerenciamento de recursos e custos porque

Alternativas
Comentários
  • Entendo que há uma imprecisão na alternativa B, que no entanto não a invalida.
    O aumento da precisão nas estimativas e a evolução dos artefatos se dá a cada iteração. Não obstante, como as iterações estão contidas nas fases, poder-se-ia dizer que esse aumento/evolução acontece em cada fase.
  • Qual seria o erro da letra "e"? Vejo que seria plenamente possível ao gerente de projetos realizar orçamentos por iterações.

  • A letra e afirma sobre a geração de orçamentos para cada iteração, sendo que orçamento se passa antes do desenvolvimento em si e não durante todo o processo de desenvolvimento. Contudo, depois que o orçamento foi passado, deve-se gerenciar os custos e recursos para que se mantenham dentro do orçamento.

  •  b)ajuda o gerente de projetos a organizar recursos e custos por fases. Os artefatos do projeto evoluem conforme requerido por cada fase e aumenta-se a precisão na estimativa de custo fase a fase.

    Em agile e modelos evolutivos "a principal medida  de progresso é software funcionando". Se deve haver software funcional como milestone no final de cada iteração, o adminisrtrador ja sabe o que tem que produzir, o que ajuda a julgar e administrar os recursos necessários, incluindo $

  • a) ERRADO. Alocar os requisitos por fase? Requisitos? Não!

    b) CORRETO. Perfeito, a iteratividade reduz riscos, organizando recursos e custos. Como se repete diversas vezes, melhora a precisão de diversas estimativas.

    c) ERRADO. Isso não tem relação com recursos e custos.

    d) ERRADO. Interação não tem nada a ver com gerenciamento de recursos e custos.

    e) ERRADO. Não vejo nada de errado nesse item, mas a Letra B é mais completa.


ID
178795
Banca
VUNESP
Órgão
CETESB
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Os planos de desenvolvimento de software cobertos em RUP são:

Alternativas
Comentários
  • Questão difícil.

    segue os artefatos que o plano de desenvolvimento de software cobre:

    * Artefato: Plano de Iteração
    * Artefato: Plano de Gerenciamento de Requisitos
    * Artefato: Plano de Métricas
    * Artefato: Plano de Gerenciamento de Riscos
    * Artefato: Caso de Desenvolvimento
    * Artefato: Guia de Modelagem de Negócios
    * Artefato: Guia de Interface do Usuário
    * Artefato: Guia de Modelagem de Caso de Uso
    * Artefato: Guia de Design
    * Artefato: Guia de Programação
    * Artefato: Guia de Teste
    * Artefato: Manual de Guia de Estilo
    * Artefato: Plano de Infra-estrutura
    * Artefato: Plano de Aceitação do Produto
    * Artefato: Plano de Gerenciamento de Configuração
    * Artefato: Plano de Documentação
    * Artefato: Plano de Garantia de Qualidade
    * Artefato: Plano de Resolução de Problemas
    * Artefato: Plano de Gerenciamento de Subfornecedores
    * Artefato: Plano de Melhoria do Processo

     

    fonte: http://www.wthreex.com/rup/process/artifact/ar_sdp.htm
     

  • quando eu achei que estava sabendo RUP....

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

No RUP, os casos de uso mais críticos devem ser atacados

Alternativas
Comentários
  •  No RUP a fase de iniciação planeja o escopo do sistema e categoriza os casos de uso com relação a sua relevância para o sistema. Essa categorização é utilizada na fase seguinte de elaboração onde a arquitetura consolidada do sistema é definida através da implementação dos casos de uso mais críticos para o sistema. Essa abordagem permite avaliar o sistema mais rapidamente, permitindo também ao engenheiro de software a conclusão de viabilidade do sistema sem gastos desnecessários.

  • Resumo da Fase de Concepção

    Finalidade
    – Definir objetivos e viabilidade do projeto (o idéia do projeto) e o escopo de vários aspectos 

    • Atividades
    – Definir: critérios de sucesso de projeto, riscos, recursos necessários e data de realização das principais etapas
    – Delimitar o escopo do projeto
    – Identificar os atores que interagem com o sistema
    – Identificar as interações dos atores com o sistema (casos de uso)

    • Resultados (artefatos)
    – Documento de visão: visão geral dos requisitos, características e restrições essenciais do projeto.
    – Modelo inicial de casos de uso (10%-20%).
    – Glossário do projeto (opcionalmente um modelo de domínio).
    – Definição de objetivos e viabilidade do projeto incluído contexto, critérios de sucesso, projeção de ROI, e prognóstico financeiro.
    – Avaliação inicial de riscos.
    – Plano de projeto, com fases e interações.
    – Modelo de negócios, se necessário.
    – Um ou vários protótipos.

    • Critérios de Satisfação
    – Concordância quanto à definição de escopo e estimativas de custo e cronograma.
    – Compreensão dos requisitos funcionais.
    – Credibilidade das estimativas de custo, cronograma, prioridades, riscos, e processo de desenvolvimento.
    – Profundidade e amplitude dos protótipos desenvolvidos.
    – Custos planejados versus realizados
  • Os riscos são reduzidos mais cedo, pois os elementos são integrados progressivament


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

São respectivamente disciplina (Core Process Workflow) e fase (Phase) do RUP:

Alternativas
Comentários
  •  Para uma maior clareza na resposta da questão, podemos enumerar as disciplinas do RUP como segue:

    Disciplinas de Engenharia(1 a 6) e disciplinas de infra-estrutura(7 a 9)

    1 - Modelagem de negócio
    2 - Requisitos
    3 - Análise e Design
    4 - Implementação
    5 - Teste
    6 - Implantação
    7 - Gerenciamento de configuração e mudanças
    8 - Gerenciamento de Projetos
    9 - Ambiente

    Ressaltando que uma passagem pelas disciplinas é definido como uma iteração e uma passagem nas fases como um ciclo de desenvolvimento completo, sendo que as fases do RUP são divididas da seguinte forma:

    1 - Concepção/Iniciação: marco definido pelo plano de escopo do projeto
    2 - Elaboração: marco definido pela estabilização da arquitetura do ciclo de vida
    3 - Construção:  marco definido pela capacidade operacional inicial(espinha dorsal)
    4 - Transição: marco definido pela definição de um release do produto

     

  • só pra complementar de forma ilustrativa:
  • b-

    elaboracao é a fase que detalha arquitetura e descricao dos casos de uso elaborados. o planejamento para a fase de construcao é parte desta fase, cujo milestone é a arquitetura do ciclo de vida.


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

No RUP, a ênfase no escopo do sistema está na fase de

Alternativas
Comentários
  • a) Concepção: é uma das fases do RUP que possui grande parte do esforço no planejamento e definição do escopo do sistema. Também é definida uma arquitetura proposta que será consolidada na fase seguinte(elaboração)

    b) Implementação: é uma das disciplinas do RUP que está presente desde a primeira fase(concepção) até a última(transição), sendo que sua maior participação é na fase de construção(terceira fase do RUP)

    c) Elaboração: segunda fase do RUP, onde é empenhado um maior esforço em definir uma arquitetura consolidada para o sistema e implementação dos casos de uso mais críticos

    d) Transição: última fase do RUP marcada pela entrega de um release do produto final e pelo planejamento de um novo ciclo de vida de desenvolvimento iniciado pelo início de uma nova concepção

    e) Construção: terceira fase do RUP marcada por uma grande ênfase na implementação do sistema, paralelismo de desenvolvimento e entrega final da capacidade operacional inicial

     

  • Descordo do gabarito. Acredito que a fase da Elaboração fica com " ênfase no escopo do sistema"

  • Gabarito: A.

     

    O gabarito está correto.

     

    Fase - Ênfase

     

    Concepção - Escopo

    Elaboração - Arquitetura

    Construção - Desenvolvimento

    Transição - Implantação


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

No RUP, a ênfase em arquitetura está na fase de

Alternativas
Comentários
  • a) Transição: é a quarta fase do RUP responsável pela entrega de um release do projeto

    b) Modelagem de Negócio: é a primeira disciplina( de engenharia) do RUP responsável por definir a necessidade do negócio para o qual a organização irá desenvolver um sistema

    c) Implantação: disciplina de engenharia responsável por implantar o software e treinar os usuários finais

    d) Implementação: disciplina de engenharia responsável pela codificação do software

    e) Elaboração: segunda fase do RUP responsável por consolidadar arquitetura do sistema

  • Elaboração
     
    A Segunda Fase do RUP cuja finalidade principal é criar uma baseline para a arquitetura do sistema e fornecer uma base estável para o esforço em massa do design e implemnetação na próxima fase
  • O RUP divide o projeto em quatro fases:

     

    1. Iniciação ou Concepção: ênfase no escopo do sistema;

    2. Elaboração: ênfase na arquitetura;

    3. Construção: ênfase no desenvolvimento;

    4. Transição: ênfase na implantação.

     

    Fonte: https://pt.wikipedia.org/wiki/IBM_Rational_Unified_Process#Fases

  • Como a colega ja disse:

    fases do RUP:

    Iniciação ou Concepção: ênfase no escopo do sistema
    Elaboração: " na arquitetura
    Construção: " no desenvolvimento
    Transição: " na implantação

    Wikipedia coloca os processos como disciplinas, enquanto que alguns autores classificam-os como diagramas(6 de engenharia & 3 suporte):

    suporte:

    1-administração de projeto

    2- gestao de configuração de mudança

    3-configuração de ambiente

    engenharia:

    1-modelagem de negocio

    2-requisitos

    3-analise & projeto 

    4-implementação

    5-teste

    6-distribuiçao

    Notem que as disciplinas de suporte sao topicos típicos de governança em TI (gerencia de prj é coisa do PMBOK, enquanto que change configuration management é um conceito do ITIL). As disciplinas de engenharia sao processos de software.


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

No RUP, Project Management e Environment são

Alternativas
Comentários
  •  Existem 3 disciplinas de suporte ou infra-estrutura:

    1 - Gerenciamento de configuração e mudança
    2 - Gerenciamento de projetos
    3 - Ambiente

    No RUP as disciplinas por se tratarem de como é para ser feita uma determinada atividade também são denonimadas de fluxos de trabalho ou workflows. Então podemos chamar as disciplinas de suporte de Supporting Workflows.

  • Concordo que a letra D é "mais completa", mas a questão possui duas respostas.

    Todas as 9 disciplinas são core process workflows, e os core process workflows são divididos em 6 core engineering workflows e 3 core supporting workflows.

    Portanto, Project Management e Environment são Core Process Workflows (letra B) e Core Supporting Workflows (letra D).

     

  • Rodrigo Pacheco, esse tipo de questão ai é daquelas que tem-se que procurar a mais certa ou a menos errada. Já ouvi e vi comentários sobre ela antes. Na veradade dá para matar fácil pelo fato da letra D) ser bem mais completa, visto que o enunciado fala de duas das três disciplinas de Suporte.

    Temos de ter cuidado nessas questões, as vezes perdemos pontos preciosos nelas....
  • Essa questão não tem nada de "+ completa ou - errada". Só tem 1 resposta mesmo! Project Management e Environment são DISCIPLINAS do RUP

    Vejam os comentários
    • a) Phases. (as Fases são IECT - Iniciacao, Elaboracao, Construcao e transicao)
    • b) Core Process Workflows. (Os CPW Sao as 6 primeiras DISCIPLINAS do RUP, que sao na ordem: Modelagem de Negocios, REquisitos, Analise e design, implantacao, teste e implementacao). Logo, as Core Supporting WOrkFlows sao as outras 3 (gerencia de Config. e mudança, gerencia de projetos e AMbiente)
    • c) Metrics. (me corrijam se eu estiver errado, mas não encontrei nada relacionado a métrica no RUP).
    • d) Core Supporting Workflows. (resposta correta)
    • e) Analysis & Design Process. (Nao sao processos, mas sim DISCIPLINAS),.
    QUem tiver com dúvida, basta ver a figura clássica do RUP

  • O colega Roberto está equivocado.
    Core  workflows 
    There are nine core process workflows in the Rational Unified Process, which represent a partitioning of all workers and activities into logical groupings.
    The core process workflows are divided into six core “engineering” workflows
    1.  Business modeling workflow 
    2.  Requirements workflow 
    3.  Analysis & Design workflow 
    4.  Implementation workflow 
    5.  Test workflow 
    6.  Deployment workflow 
    And three core “supporting” workflows
    1.  Project Management workflow 
    2.  Configuration and Change Management workflow 
    3.  Environment workflow
    http://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_TP026B.pdf

    Saliento que a partir da versão 2001A.04.00 o termo "Core Workflow" foi substituído por "Discipline"

    http://www.ts.mah.se/RUP/RationalUnifiedProcess/manuals/intro/im_diff.htm
  • Seis Disciplinas Principais de Engenharia de Software (core business):

     

    1. Disciplina de Modelagem de Negócios[editar | editar código-fonte]

    2. Disciplina de Requisitos

    3. Disciplina de Análise e Projeto ("Design")

    4. Disciplina de Implementação

    5. Disciplina de Teste

    6. Disciplina de Implantação

     

    Três Disciplinas de Apoio/Suporte (Core Supporting Workflows)

     

    1. Disciplina de Ambiente

    2. Disciplina de Configuração e Gerência de Mudança

    3. Disciplina de Gerência de Projeto[editar | editar código-fonte]

     

    Fonte: https://pt.wikipedia.org/wiki/IBM_Rational_Unified_Process#Disciplinas

  •  d)Core Supporting Workflows.

    core supporting workflows: 1-gerencia de projeto2- gerencia de configuração de mudança; 3- gerencia de mabiente

    core processo workflows: 1- modelagem de negocios 2- requisitos 3- analise e projeto 4- implementação 5- testes 6- distribuição

    Para lembrar, é so lembrar que o primeiro contato deve tratar do entendimento do ambiente de negocios do cliente e como o mapeamento de processos pode agregar valor ao seu negocio. Daí a modelagem de negocio e de processos. Assim que houver um modelo de negocio bem definido, deve-se listar os requisitos (backlog em scrum). Com os requisitos e processos modelados, fazem-se analise e projeto do software. Apos é a parte mais interna da coisa, implementação (codigo do sistema e arquitetura por componentes, o que é tipico do RUP) e testes. Aí sim a distribuição


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

No Processo Unificado (UP), o fluxo de trabalho Análise, tem forte concentração na fase de

Alternativas
Comentários
  • Análise e o Desenho também (uma única disciplina no UP) ocorrem em sua maior parte na fase da elaboração.

  • Gabarito: B

    A maior parte do processo de Análise ocorre na segunda fase, chamada de Elaboração. (ver figura: http://dn.codegear.com/article/images/33319/RUP.JPG )

    O Processo Unificado organiza suas iterações em quatro fases principais:

    1. Concepção: o objetivo desta fase é levantar, de forma genérica e pouco precisa, o escopo do projeto. Não deve existir aqui a pretensão de especificar de forma detalhada requisitos, a idéia é ter uma visão inicial do problema, estimar de forma vaga esforço e prazos e determinar se o projeto é viável e merece uma análise mais profunda.
    2. Elaboração: na fase de elaboração todos (ou a grande maioria dos requisitos) são levantados em detalhes. Numa primeira iteração um ou dois requisitos, os de maior risco e valor arquitetural, são especificados em detalhes. Estes são implementados e servem como base de avaliação junto ao usuário e desenvolvedores para o planejamento da próxima iteração. Em cada nova iteração na fase de elaboração pode haver um seminário de requisitos, onde requisitos antigos são melhor esclarecidos e novos são detalhados. Ao fim da fase, 90% dos requisitos foram levantados em detalhes, o núcleo do sistema foi implementado com alta qualidade, os principais riscos foram tratados e pode-se então fazer estimativas mais realistas.
    3. Construção: implementação iterativa dos elementos restantes de menor risco e mais fáceis e preparação para a implantação.
    4. Transição: testes finais e implantação.
    Fonte:http://www.devmedia.com.br/post-3931-Introducao-ao-Processo-Unificado.html
  • Basta lembrar da clássica Figura "DISCIPLINAS e FASES" do RUP. Reparem que a disciplina "análise e design" apresenta maior parte em "elaboração"

    http://engenhariarequisitos.files.wordpress.com/2011/05/img_grafico_rup2.jpg



  • Fases do RUP

    Concepção: envolve a atividade de comunicação com o cliente e o planejamento.

    Elaboração: desenvolve uma compreensão do problema, estabelece um framework da arquitetura para o sistema, desenvolve o plano do projeto e identifica os maiores riscos do projeto.

    Construção: envolve projeto, programação e teste do sistema. É a etapa mais longa e que tem a maior investimento de recursos.

    Transição: é a transferência do sistema de desenvolvimento para a os usuários e em seu funcionamento em um ambiente real.

    Alternativa: B


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

Considere:

I. Dirigido por caso de uso.
II. Orientado por quatro workflows.
III. Centrado em arquitetura.
IV. Distribuído em cinco fases.
V. Iterativo e incremental.

São características do Processo Unificado (UP) o que consta APENAS em

Alternativas
Comentários
  • I. Correto. Os casos de uso são predominantemente criados nas fases de Concepção e elaboração;

    II. Não é orientado por fluxo, pois é iterativo.

    III. Correto. Centrado na arquitetura, por isso as disciplinas de Modelagem de negócios, requisitos e análise e desenho.

    IV. Errado. São quatro fases: Concepção, elaboração, construção e transição.

    V. Correto. É uma característica do RUP.

  • Gabarito: C

    O processo unificado (UP) de desenvolvimento de software é o conjunto de atividades necessárias para transformar requisitos do usuário em um sistema de software. O UP de desenvolvimento de sistemas combina os ciclos iterativo e incremental para a construção de softwares. É fundamental na visão de que o avanço de um projeto deve estar baseado na construção de artefatos de software, e não apenas em documentação.

    Os aspectos que distinguem o processo unificado são três conceitos chave, a saber:

    • direcionado a casos de uso;
    • centrado na arquitetura;
    • iterativo e incremental.
    Fonte: Wikipédia
  • II-errada.

    são nove workflows, tambem conhecidos como disciplinas, e não quatro. Quatro são as fases.
    disciplinas são as partes estáticas do RUP/UP.

    ex de workflow: analise e design, gerenciamento de projeto, ambiente, implementação, teste, implantação, etc.
  • O processo é formado:

     5 workflows:

    1- Requesitos
    2-Análise
    3-Projeto
    4- Implementação
    5- Teste

    4 Fases:

    Concepção
    Elaboração
    Construção
    Transição
  • DANIEL,

    São 9 "workflow's" (ou disciplinas) e não 5. CUIDADO.

    Veja em: http://www.wthreex.com/rup/portugues/manuals/intro/im_keymc.htm#Software%20Engineering%20Process
  • Pessoal, o Daniel está correto. A questão faz referência ao Unified Process (UP) e não ao Rational Unified Process (RUP) que é uma instância do mesmo.
  • UP:
    5 fluxos:

    RUP:
    9 disciplinas:
     3- 
  • Mata eliminação, é dirigido por caso de uso e iterativo e incremental, só tem 1 alternativa (C) que engloba os 2.

  • Rational Unified Process (RUP)

    - É um processo de engenharia de software;

    - Seu objetivo é garantir a produção de software de alta qualidade que atenda aos requisitos do usuário em um prazo e orçamento previsíveis.

    -  É derivado de trabalhos sobre a UML;

    -  É Iterativo (feito em ciclos) e incremental (planejado em incrementos);

    -  Guiado por casos de uso;

    -  Centrado em uma arquitetura;

    -  Baseado em modelos;

    Alternativa: C


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

Acerca do processo unificado de software, julgue os itens
subsequentes.

UML (unified modeling language) é uma tecnologia concorrente com o processo unificado, no que diz respeito ao apoio à prática de engenharia de software orientada a objetos.

Alternativas
Comentários
  •  Na verdade a UML é um modelo para diagramação de sistemas orientados a objetos. O processo unificado faz uso do UML.

    Errado: UML (unified modeling language) é uma tecnologia concorrente com o processo unificado

    Certo: ao apoio à prática de engenharia de software orientada a objetos. (O UML apoia a pratica, ao invés de ser concorrente ao PU).

     

  •  UML não é uma tecnologia. É uma linguagem de modelagem. Ela é usada no RUP.

  • Errado pois

    O UML é obrigatório e usado em quase todas as etapas do RUP.
  • UML não é obrigatório no RUP. Ela é uma boa prática, na qual se for usada em conjunto com o RUP trará resultados satisfatórios.

  • questão ERRADA:

    O erro da questão está na língua portuguesa e não na linguagem de notação.

    o verbo concorrer pode ser intransitivo ou transitivo indireto, neste caso  com as seguintes regências:

    concorrer com: disputar, competir em busca de vitória;

    concorrer em: coexistir, ao mesmo tempo;

    concorrer para: contribuir, ter parte em um resultado.

    Assim, o uso da preposição com na assertiva tornou o RUP rival da UML, e a questão ficou errada por este motivo.

    Seria mais correto uma das seguintes:

    UML e RUP são tecnologias concorrentes no (coexistem) apoio à prática de engenharia de software orientada a objetos.

    UML e RUP são tecnologias que concorrem para (contribuem) apoiar à prática de engenharia de software orientada a objetos. 

  • O que a questão está perguntando é se UML é concorrente com PU no que diz respeito à metodologia de desenvolvimento de SW, o que sabemos que NÃO, por ser uma linguagem de modelagem e não uma metodologia de desenvolvimento como RUP,  XP, Scrum etc. Acredito que o autor tentou fazer uma pegadinha, já que tanto PU como UML possuem os mesmos autores (Booch, Jacobson e Rumbaugh).

  • UML é uma linguagem, não necessariamente método ou tecnologia, que se enquadra perfeitamente bem às práticas de formalização do RUP. Não há concorrência. 

  • O erro está em "UML (unified modeling language) é uma tecnologia concorrente com o processo unificado". UML não é concorrente, e sim atua com o Processo Unificado. Concorrente sugere substituição de uma tecnologia por outra.


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

Acerca do processo unificado de software, julgue os itens
subsequentes.

O processo unificado de software é centrado na arquitetura e orientado por casos de uso, o que sugere um fluxo de processo iterativo e incremental.

Alternativas
Comentários
  • Resposta correta.

    A questão traz consigo apenas a descrição das principais características do processo unificado, que são:

    - Iterativo e Incremental
    - Guiado por casos de uso
    - Centrado na arquitetura
    - Orientado a Objetos
    - Planejado por riscos

  • Apenas acrescentando:

    O fato de um modelo ser centrado na arquitetura sugere que o sistema será o mais modularizado e componentizado possível, isso facilta na inserção de novos módulos e componentes (Ver Pressman, Sommerville ou Wilson).

  • Esse "sugere" me matou!

  • nossa, cespe cobra essa questao faz tempo hein

     

    2015
    Orientação a casos de uso, arquitetura e iteração são os princípios básicos nos quais o RUP está fundamentado.

    certa

     


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

A metodologia RUP, que consiste no desenvolvimento interativo com foco na redução dos riscos do projeto, agrega um valor real à organização que necessita manter padrões relativos às comunicações externas e à comunicação com a equipe de desenvolvimento.

Alternativas
Comentários
  • por que está CERTO? O enunciado diz "interativo" ao passo que deveria ser "iterativo", náo é isso?

  • Interativo: que interage; que permite comunicação em dois sentidos.

    Iterativo: que serve para iterar; repetido.

    O RUP é interativo e iterativo, ele é repetido, ele é incremental, ou seja; o software produto do projeto é incrementado partindo de um processo repetido, mas que necessita de interações ou comunicações, entre processos, papeis e interessados.

    Sucesso.

  • Acredito que ninguém entrou com recurso contra essa questão na época.
    O certo de fato ser ITERATIVO e não INterativo.
  • Não é a primeira e nem vai ser a última questão que encontro considerada correta, mesmo com a palavra "interativo" usada erroneamente.

  • A Cespe sempre colocando interativo no contexto do RUP, e sempre está "correto". Acredito que devam achar ser uma boa casca de banana. Portanto, se achar que o erro é o "INTERATIVO", MARQUE CORRETO e DEIXE O RECURSO PARA OS OUTROS.

  • 2011

    A metodologia RUP faz uso de UML (unified modeling language) e procura reduzir riscos do projeto.

    Certa

     


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

Na fase elaboração, prevista no processo unificado de desenvolvimento de software, deve ser produzido o artefato descrição da arquitetura de software.

Alternativas
Comentários
  • Item correto.

    O marco da fase de elaboração é a arquitetura do ciclo de vida e seus principais artefatos são:

    ?Protótipos(comportamental,estrutural
    Exploratório p/ descarte,evolutivo)
    ?Lista de riscos
    ?Documento de arquitetua de Stw
    ?Modelo de Projeto
    ?Modelo de dados
    ?Modelo de caso de uso

  • Na fase de elaboração são produzidos os seguintes artefatos:

    1. Modelo de caso de uso

    2. Requisitos não funcionais

    3. Descrição da arquitetura do software

    4. Revisão da visão de negócio e linha de risco

    5.  Prótotipo arquitetural executável

    6. Plano detalhado de desenvolvimento do projeto

    7.  Plano de processo de desenvolvimento

    8.  Manual do usuário preliminar

  • 2011

    Elaboração, no contexto do RUP, é uma fase que visa criar a baseline para a arquitetura do sistema a ser desenvolvido e, no contexto de engenharia de requisitos, a elaboração consiste em atividade cujo objetivo é o desenvolvimento de um modelo técnico refinado das funções, características e restrições do sistema.

    Certa

     


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

Julgue o seguinte item a respeito de qualidade de software.

Na fase de elaboração do RUP, são desenvolvidas as funcionalidades do sistema e implementados os requisitos identificados na fase de concepção.

Alternativas
Comentários
  • Item Errado.

    Na fase de construção do RUP, são desenvolvidas as funcionalidades do sistema e implementados os requisitos identificados na fase de concepção e não na fase de elaboração como afirma a questão.

    Na fase de contrução ocorre o marco da capacidade operacional Inicial (funcionalidades desenvolvidas e conclusão do teste alfa).

    Fonte: www.dominandoti.com.br

  • O propósito desta fase é:

    1. Analisar o domínio do problema;

    2. Desenvolver o plano de projeto

    3. Estabelecer a fundamentação estrutural

    4. Eliminar os elementos de alto risco

    É nesta fase que são implementados os cenários críticos dos casos de uso arquiteturalmente significativos.

  • elaboração é quando se determina a base do projeto (baseline). Desenvolver é só na construção

  • 2015

    Na fase de elaboração, realiza-se a descrição da arquitetura do software, em que os requisitos que impactam a arquitetura são capturados na forma de use cases.

    Certa

     


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

Um processo de desenvolvimento de software contém a descrição
de uma abordagem para a construção de sofware. A UML (unified
modeling language) é uma linguagem visual para especificar,
documentar e construir os artefatos de sistemas orientados a
objetos. Quanto ao ambiente de desenvolvimento de sistemas
orientados a objetos, julgue o item a seguir.

O processo unificado (PU) é um processo iterativo para a análise de projetos orientados a objetos, no qual o trabalho e as iterações são organizados em três fases principais: concepção, elaboração e construção.

Alternativas
Comentários
  • O Processo Unificado divide o projeto em quatro fases:

    1 - Concepção
    2 - Elaboração
    3 - Construção
    4 - Transição

  • Complementando a resposta do colega abaixo:

    O Processo Unificado organiza suas iterações em quatro fases principais:

    1. Concepção: o objetivo desta fase é levantar, de forma genérica e pouco precisa, o escopo do projeto. Não deve existir aqui a pretensão de especificar de forma detalhada requisitos, a idéia é ter uma visão inicial do problema, estimar de forma vaga esforço e prazos e determinar se o projeto é viável e merece uma análise mais profunda.
    2. Elaboração: na fase de elaboração todos (ou a grande maioria dos requisitos) são levantados em detalhes. Numa primeira iteração um ou dois requisitos, os de maior risco e valor arquitetural, são especificados em detalhes. Estes são implementados e servem como base de avaliação junto ao usuário e desenvolvedores para o planejamento da próxima iteração. Em cada nova iteração na fase de elaboração pode haver um seminário de requisitos, onde requisitos antigos são melhor esclarecidos e novos são detalhados. Ao fim da fase, 90% dos requisitos foram levantados em detalhes, o núcleo do sistema foi implementado com alta qualidade, os principais riscos foram tratados e pode-se então fazer estimativas mais realistas.
    3. Construção: implementação iterativa dos elementos restantes de menor risco e mais fáceis e preparação para a implantação.
    4. Transição: testes finais e implantação.

  • Na sétima edição Eng. SW Pressman Pag. 73, ele cita mais uma fase: Fase de Produção.

    "Coincide com a atividade do emprego do processo genérico. Durante essa fase, monitora-se o uso contínuo do SW, disponibiliza-se suporte para o ambiente operacional,  realiza-se e avalia-se relatórios de defeitos"
  • 1. Dica para decorar as 4 fases: CON ELA CONTRA! (CONcepção, ELAboração, CONstrução, TRAnsição)


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

Um processo de desenvolvimento de software contém a descrição
de uma abordagem para a construção de sofware. A UML (unified
modeling language) é uma linguagem visual para especificar,
documentar e construir os artefatos de sistemas orientados a
objetos. Quanto ao ambiente de desenvolvimento de sistemas
orientados a objetos, julgue o item a seguir.

No PU, a elicitação de requisitos do sistema de software iniciase na fase de concepção.

Alternativas
Comentários
  • É na fase de iniciação (ou concepção) que há uma maior ênfase na disciplina de requisitos.
    É nesta fase onde estabelece-se o que o sistema deve fazer, define-se as fronteiras do sistema e fornece uma base para estimar o custo e o tempo de desenvolvimento do sistema.
    Para isso, é necessário que sejam levantados os requisitos mais críticos. Um dos artefatos importantes dessa fase é o Modelo de Casos de Uso, utilizado pelos Analistas que realizam a elicitação dos requisitos.

    Logo, questão correta.

  • Olá, pessoal!

    O gabarito foi atualizado para "C", após recursos, conforme edital publicado pela banca, e postado no site.

    Justificativa da Banca:  De fato, na fase de concepção inicia a elicitação de requisitos e conclui na fase de elaboração.

    Bons estudos!

  • Conforme foi dito pelo Sílvio, a Engenharia de Requisitos esta presenta tanto na fase de Concepção e em quantidade quase nula nas outras 2 fases.

  • 2011

    Na denominada fase de elaboração, tipicamente, o foco é inserido na maneira como se gerenciam requisitos e como se gerencia o projeto.

    errada

     


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

Acerca do RUP (rational unified process), julgue os próximos
itens.

Uma falha comum em projetos de sistemas computacionais é não assegurar a qualidade do software. Normalmente, essa questão é discutida após o término dos projetos, ou a qualidade fica sob a responsabilidade de equipe diferente da equipe de desenvolvimento. O RUP, proposto pela IBM, é um processo que provê uma solução disciplinada sobre como assinalar tarefas e responsabilidades dentro de uma organização de desenvolvimento de software, porém, não auxilia no controle do planejamento e verificação da qualidade.

Alternativas
Comentários
  • O RUP visa auxiliar no controle do planejamento da qualidade, verificando-a na construção de todo o processo e envolvendo todos os membros da equipe de desenvolvimento.

    fonte: wikipédia

  • O RUP foca-se na arquitetura com o objetivo de se obter qualidade.
  • Melhores Práticas do RUP:

    • 1. Desenvolvimento Iterativo
    • 2. Gerenciamento de Requisitos
    • 3. Uso da Arquitetura de Componentes
    • 4. Modelagem Visual (UML)
    • 5. Contínua Verificação da Qualidade
    • 6. Gerenciamento de Mudança

    O RUP não possui uma disciplina Qualidade. A despeito disso, assume-se que cada membro da equipe é responsável pela qualidade durante todo o processo. O processo foca na descoberta do nível de qualidade esperado e provê testes nos processos para medir este nível.
  • Bom dia, pessoal.

    Só encontrei dois erros:

    1- O RUP descrito não foi proposto pela IBM, mas Rational Software Corporation, que mais tarde foi adquirida pela IBM.
    2- O RUP auxilia no controle do planejamento e verificação da qualidade.

    Inté!


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

Acerca do RUP (rational unified process), julgue os próximos
itens.

A disciplina de gestão de mudança em negócios com RUP abrange três gerenciamentos específicos: de configuração; de solicitações de mudança; e de status e medição.

Alternativas
Comentários

ID
226309
Banca
CESGRANRIO
Órgão
EPE
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Uma pessoa leiga no assunto pediu informações a um Analista de TI sobre o papel da Engenharia da Informação (EI) em empresas. O Analista explicou que a EI

Alternativas
Comentários
  • Engenharia da Informação (EI):

    Definição - A aplicação de um conjunto interligado de técnicas formais de planejamento, análise,
    projeto e construção de Sistemas de Informações (SI) sobre uma organização como um todo ou
    em um dos seus principais setores.

    Diferença entre engenharia de software e engenharia da informação:
    • A engenharia de software aplica técnicas estruturadas a um projeto.
    A engenharia da informação aplica técnicas estruturadas à empresa como um todo, ou a um
    de seus setores.

    • As técnicas de engenharia da informação englobam as técnicas de engenharia de software de
    uma forma diferente (como uma organização é bastante complexa, o planejamento, análise,
    projeto e construção não podem ser efetuados sobre a empresa como um todo sem o uso de
    ferramentas automatizadas).

    Outra definição para EI fazendo referência a técnicas automatizadas:
    • Um conjunto interligado de técnicas automatizadas no qual são construídos modelos da
    organização, modelos de dados e modelos de processos em uma abrangente base de
    conhecimentos, a fim de serem usados para criarem e manterem sistemas de processamento
    de dados.
    OU
    • Um conjunto de disciplinas automatizadas em nível de organização, cuja finalidade é fornecer
    as informações certas às pessoas certas e na hora certa.

    A EI não é uma metodologia rígida como a engenharia de software, porém esta tem que ser
    formal, computadorizada e aceita em todo o segmento da organização que utiliza a EI.

     

    www.cefetba.br/professores/pablovf/repositorio/siEinf1.pdf


ID
230905
Banca
FUNCAB
Órgão
PRODAM-AM
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Assinale a alternativa que NÃO representa uma característica do Processo Unificado (UP) original, descrito no livro The Unified Software Development Process (1999).

Alternativas
Comentários
  • O desenvolvimento ágil não é característica do UP, o desenvolvimento ágil não foca-se nas etapas de Análise e Desenho como o RUP, sua prioridade é que a implementação comece o quanto antes e que os ajustes são parte do processo, portanto iterativo e incremental.

  • Metodos ágeis prioriza a iteração verbal ao invés de documental, tal como no RUP


ID
240787
Banca
FCC
Órgão
TRT - 8ª Região (PA e AP)
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

No Processo Unificado, uma descrição da arquitetura do software, um documento de visão e um modelo de projeto são aplicáveis, respectivamente, nas fases

Alternativas
Comentários
  • O RUP é dividido em 4 fases e 9 disciplinas.

    Descrição Arquitetura de Software: Trata-se do desenho da arquitetura. A disciplina que aborda esta atividade é a de Análise e Desenho, que predominantemente ocorre durante a fase da Elaboração.

    Documento de visão: Este documento é a visão de como deverá ser o sistema, portanto faz parte da Engenharia de Requisitos, que encontra-se entre as fases de concepção e elaboração, para se adequar a questão, então considerei como concepção.

    Modelo do projeto: Faz parte da implementação, que predominantemente encontra-se na fase de construção.

  • Então...

    Todos sabemos que as 4 fases do RUP são INICIAÇÃO (ou CONCEPÇÃO), ELABORAÇÃO, CONSTRUÇÃO E TRANSIÇÃO.

    Cada fase desta apresenta um marco (vide figura abaixo)



    Cada MARCO contem ARTEFATOS.

    Dentre os ARTEFATOS do MARCO da fase INICIAÇÃO (parece confuso mas não é.. basta entender a lógica), temos o "Documento de Visão"
    (vide http://www.wthreex.com/rup/portugues/process/itrwkfls/ms_lco.htm)

    Dentre os ARTEFATOS do MARCO da fase ELABORAÇÃO temos a DESCRIÇÃO DA ARQUITETURA DE SW
    (vide http://www.wthreex.com/rup/portugues/process/itrwkfls/ms_lca.htm)

    Dentre os ARTEFATOS do MARCO da fase CONSTRUÇÃO temos o TEMPLATES ESPECIFICOS DE PROJETO
    (vide http://www.wthreex.com/rup/portugues/process/itrwkfls/ms_ioc.htm) que a banca considerou como MODELOS DE PROJETO.

    BRINCADEIRA HEIN? Banca "lixeba"...
  • Só lembrando que RUP (Rational Unified Process) é uma implementação do UP (Unified Process).
    O RUP especifica artefatos como resultados das fases e papeis para execução das mesmas, já o UP não.
    Entretanto, o UP deixa claro o que deve ser alcançado a cada fase.
    Segundo John Hunt, no livro "Guide To The Unified Process Featuring UML, Java And Design Patterns", Cada fase consiste em:
     - Concepção: A saída desta fase é a visão do sistema. Isto inclui modelos de caso de uso muitos simplificados (para identificar as principais funcionalidades do sistema) e são identificados os riscos mais importantes ou significativos.
     - Elaboração: A saída primária dessa fase é a arquitetura, juntamente com um modelo detalhado de casos de uso e um conjunto de planos para a fase de construção.
     - Construção: O resultado final desta fase é o produto implementado, que inclui o software, bem como os modelos associados. O produto não precisa ser isento de defeitos, pois ainda há trabalho a ser feito na fase de transição.
     - Transição: A fase de transição é a última fase de um ciclo. O grande marco desta fase é uma versão final de qualidade do sistema.
  • nota máxima no seu comentário Forrest. Tem que lembrar sempre que RUP não é exatamente igual a UP. A questão esta corrétissima sob o prisma do UP.
  • Fases do RUP:

    •Indicam a ênfase que é dada ao projeto em um momento específico.

    •Um projeto é dividido em quatro fases:

    1.Concepção (ou Iniciação) : ênfase no escopo do sistema;

    2.Elaboração: ênfase na arquitetura;

    3.Construção: ênfase no desenvolvimento;

    4.Transição: ênfase na implantação.

  • Tentando resumir o comentário do Forrest:


    - Concepção:
       visão do sistema
       caso de uso simplificados
       riscos

    - Elaboração:
       arquitetura
       casos de uso detalhados
       planos de construção

    - Construção:
       Produto inacabado
       modelos associados ao software

    - Transição:
       versão final de qualidade do sistema.



ID
252070
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 RUP (rational unified process) é um modelo de processo de desenvolvimento genérico e moderno, organizado em fases - concepção, elaboração, construção e implantação -, que separa as atividades em requisitos, análise e projeto.

Alternativas
Comentários
  • As fases do RUP são:

    1 - Concepção
    2 - Elaboração
    3 - Construção
    4 - Transição

    O erro da questão é informar que implantação é uma das fases.
     
  • Fases do RUP:
    1- Concepção
    2- Elaboração
    3- Construção
    4- Transição

    Disciplinas do RUP
    1- Modelagem de Negócio
    2- Requisitos
    3- Design (Análise e Projeto)
    4- Implementação
    5- Testes
    6- Implantação

    Disciplinas de apoio:
    7- Ambiente
    8- Config. e Gerência de Mudanças
    9- Gerência de Projeto
  • além de conter um erro em uma das fases, também há um problema no trecho "que separa as atividades em requisitos, análise e projeto", pois o modelo é iterativo.
  • Eu diria que há dois erros nessa questão. 

    O primeiro está ao citar a fase de Implantação como uma das fases do RUP, como disse o colega anteriormente.

    O segundo está na forma com que o RUP separa as suas atividades. As atividades do RUP são separadas em suas 9 disciplinas e não somente nas duas (Requisitos e Análise e Projeto) citadas. 
  • Questão chata.... Pq dizer que o erro está em dizer que é por conta da fase de Implantação, que deveria ser Transição, é o mesmo que dizer que estaria errado dizer que as fases são: Iniciação(ao invés de Concepção), Elaboração, Construção e Transição. E notem que tem muita banca usando a nomenclatura de Iniciação, ao invés de Concepção... Aí para ter que adivinhar na hora da prova são outros 500.

     

    Dizer que o erro está no trecho: "...que separa as atividades em requisitos, análise e projeto." Ao meu ver é complicado, pois o examinador não disse SOMENTE. Seria o mesmo que que é errado dizer que:  o RUP possui duas disciplinas. Sabe-se que ele possui 9 disciplinas, logo possui duas disciplinas SIM. Se a afirmação fosse: o RUP só possui duas disciplinas, estaria errada, mas o examinador, ao citar requisitos, análise e projeto não usou nenhum termo excluindo as outras disciplinas....

     

    Complicado!!!!!!!

  • Análise do gráfico de baleias:

    Fases: Iniciação, elaboração, contrução e transição.

    Disciplinas: Modelagem de Negócio; Requisitos; Análise e Design; Implementação; Teste; Implantação; Gerneciamento de Config. e Mudanças; Gerenciamento de Projetos e AMbiente.

     

  • po, ele não restringiu as atividades do RUP a essas 3

     

    eu fui de Certa facil

     

     

    e transição por implantação... já vi tanta questao tratar isso como sinonimo

  • Fases do RUP: concepção; elaboração; construção; transição.

     

    Diciplinas do RUP: modelo de negócios; requisistos; analise e design; implementação; testes; implantação; gerenciamento de configurações e mudanças; gerenciamento de projeto; gerenciamento de ambiente.

  • Outro erro é dizer que o RUP é um "processo de desenvolvimento genérico". Ele é um processo de desenvolvimento de Software guiado por caso de uso, orientado a objetos. Portanto não é tão generico assim.


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
277282
Banca
CESPE / CEBRASPE
Órgão
TRE-ES
Ano
2011
Provas
Disciplina
Engenharia de Software
Assuntos

Acerca de RUP (rational unified process), julgue os itens que se seguem.

O conjunto de artefatos de requisitos do RUP contém artefatos relativos ao planejamento, tais como o plano de projeto e os planos de iteração.

Alternativas
Comentários
  • O Conjunto de Artefatos de Gerenciamento de Projeto captura os artefatos associados ao planejamento e à execução do projeto e do processo. Um dos artefatos dessa disciplina é o Plano de Iteração. Outro problema é que não encontrei o artefato Plano de Projeto entre os artefatos do RUP.
    http://www.wthreex.com/rup/portugues/process/artifact/ars_mgmt.htm

    O conjunto de artefatos de Requisitos captura e apresenta informações usadas para definir os recursos necessários do sistema.
    http://www.wthreex.com/rup/portugues/process/artifact/ars_req.htm
  • No RUP temos 12 produtos de trabalho do tipo Plano, estando alocados nas seguintes disciplinas:

    Modelagem de Negócio (nenhum plano)

    Requisitos
    * Plano de Gerenciamento de Requisitos

    Análise e Design (nenhum plano)

    Implementação
    * Plano de Integração do Build

    Teste
    * Plano de Teste

    Implantação (nenhum plano)


    Gerenciamento de Projeto
    * Plano de Desenvolvimento de Software
      ** Plano de Resolução de Problemas
      ** Plano de Aceitação de Produtos
      ** Plano de Garantia de Qualidade
      ** Plano de Gerenciamento de Riscos
      ** Plano de Métricas
    * Plano de Iteração
    * Plano de Implantação


    Gerenciamento de config. e Mudança
    * Plano de Gerenciamento de Configuração

    Ambiente (nenhum plano)

    Concluímos que quando o RUP falar em Plano, muito provavelmente estará falando na disciplina de Gerenciamento de Projeto, pois esta disciplina possui 8 dos 12 artefatos de planejamento, além dos demais artefatos deixarem claro a qual disciplina pertence. Devemos ter cuidado com o Plano de Implamtação que não pertence a disciplina de implantação mas sim a disciplina de Gerenciamento e Projeto.

    Bem, espero ter ajudado quanto a visualização do artefato Plano dentro do RUP.
  • Concordo com quase tudo que o amigo abaixo colocou. Discordo somente do ponto onde é dito que o Plano de Implantação não pertence a disciplina de Implantação e sim a disciplina de Gereciamento de Projetos, com base no RUP.

    O Plano de implantação é criado e atualizado pelo papel Gerente de implantação e essa atividade ocorre na disciplina de Implantação do RUP e não na disciplina de Gerenciamento de Projetos. O Gerente de projetos, somente participa da disciplina de implantação aprovando o Plano de Implantação com base nas impressões do usuários e resultados dos testes.

    Ver a referência confiável em: Gerenciando Projetos de Desenvolvimento de Software com PMI, RUP e UML (5a Edição) - pag 210: http://books.google.com.br/books?id=8ect3L-yozkC&pg=PA254&lpg=PA254&dq=plano+de+implantacao+rup+pertence+a+qual+disciplina&source=bl&ots=ow8Uy5PCh_&sig=OYu7DuBj6ihxlRmE5X0GSwceSIs&hl=pt-BR&sa=X&ei=c2LPUuOuMZOHkQfY4oC4DA&ved=0CFUQ6AEwBQ#v=snippet&q=%22plano%20de%20implantação%22&f=false.

    É só para não passarmos informações erradas para pessoas que precisam saber o correto!

    Espero ter ajuadado. Bons estudos!

  • Prezado Sérgio Raunilo,

    Acredito que sua base esteja equivocada para você fazer tal afirmação. Com o objetivo de não passar informações erradas, eu analisei a documentação oficial do RUP antes de postar meu primeiro comentário. Acredito que a documentação oficial do RUP seja superior a qualquer livro que você considera "confiável" para tratar o assunto específico do RUP.

    Veja:

    http://www.wthreex.com/rup/v711_ptbr/rup/workproducts/rup_deployment_plan,%7B993ED293-A529-4B3F-82CB-2BF289D9E4E4%7D.html


    Artefato: Plano de Implantação

    Esse artefato descreve o conjunto de tarefas necessárias para instalar e testar o produto desenvolvido, de forma que ele possa ser efetivamente transferido para a comunidade de usuários.

    Domínio: Gerenciamento de Projeto
    Tipos de Produto de Trabalho: Plano


    Domínio: Implantação

    Este domínio captura e apresenta as informações relacionadas a executar a transição do sistema apresentada no conjunto de Implementações dentro do ambiente de produção.

    Produtos de Trabalho
    * Manual de Guia de Estilo
    * Material de Suporte do Usuário
    * Produto

    Consulta da Documentação Oficial do RUP para o Domínio Implantação:

    http://www.wthreex.com/rup/v711_ptbr/rup/domains/deployment,_7CnosP_FEdmAzesbYywanQ.html

    Espero ter fornecido uma base oficial e confiável para esclarecimento da informação postada no meu primeiro comentário.


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

Acerca de RUP (rational unified process), julgue os itens que se seguem.

RUP e UML são interdependentes, isto é, não há como se aplicar o RUP no desenvolvimento de um sistema se não se utilizar o UML.

Alternativas
Comentários
  • Alguma explicação por favor. Eu sei que o RUP faz uso da UML. Então dá pra fazer a disciplina de Requisitos, por exemplo, sem utilizar os Diagramas de Caso de Uso, mas fica uma coisa esquisita, só com a documentação escirta dos requisitos, sem um diagrama se quer.
  • O problema é que querem vender o RUP e UML sempre juntos. Sempre!
  • O RUP tem como boa prática a utilização de modelagem visual. No meu entender, boa prática é opcional e não obrigatório e mesmo que fosse obrigatório, fala-se em modelagem visual onde existindo uma outra linguagem que não UML poderia ser utilizada para fazer os modelos necessários que as atividades do RUP demandam.
  • Galera acho que o erro do item está no "interdependentes", o RUP depende da UML mas a UML não depende do RUP. 
  • Concordo com o colega Thiago.

    O problema está interpretação da redação do enunciado da questão.
    RUP e UML são interdependentes, isto é, não há como se aplicar o RUP no desenvolvimento de um sistema se não se utilizar o UML.

    Significado de Interdependência
    Dependência mútua

    O RUP é um caso particular derivado do Processo Unificado (PU) e da UML.
    Entendo que RUP depende da UML; mas o contrário, não.
    A UML é anterior à criação do RUP.
    Portanto, não há dependência mútua.
  • Pra mim, o problema da questão é mesmo o fato de ligar o RUP a UML. O RUP é framework de processos, ou seja, você customiza de acordo com suas necessidades.
    A Modelagem Visual utilizando a UML é uma boa prática, mas não significa que você deve utilizar obrigatoriamente a UML.
  • O erro da questão é que RUP é um processo de desenvolvimento de software e UML é uma linguagem visual de modelagem.
    Eu posso usar RUP, sem usar UML posso usar outras notações para isso. 

    Questão: Errada.
  • Concordo parcialmente com você Thiago. De fato se o RUP é dependente da UML, mas a UML é independente do RUP não seria totalmente correto dizer que são interdependentes. Mas essa é uma questão de engenharia de software e não de português e como a própria assertiva definiu interdependentes de uma forma que faria sentido teria marcado correto.

     

    Enfim acho que a questão podia ter sido anulada por estar mal formulada. Esse é o grande problema do CESPE, no certo e errado quando está dubio não dá pra fazer por eliminação então tens que ter a sorte de advinhar o que examinador estava pensando. Muitas questões com impropriedades como essa são dadas como certa, enquanto outras tantas como erradas.

     

    Já vi questõs do tipo, a alíquota do ISS não pode ser superior a 10% dadas como certo e como erradas. Ao rigor, e ao meu ver estão certas pois 10 é maior que 5, mas como que vais advinhar o que o examinador pensa? Particularmente, como regra tento não pensar que é pegadinha e ser mais tolerante com a banca.

     

     

    ,

     

  • RUP e UML não são dependentes entre si. Assim está errado quando fala que são INTERDEPENDENTES. 

  • errado - como os colegas observaram, UML é a primeira parte do processo, usado para modelar, para criar uma representação visual de como o software sera desenvolvido. é possivel usar UML (assim como ARIS, EKD etc) e depois uma outra metodologia de desenvolvimento como scrum, xp, dsdm waterfall model etc. A unica coisa que RUP tem em relação ao UML é ter sido baseado nele, mas nao ha "interdependencia" entre eles