SóProvas

Questões de Processos de Software

ID
2293
Banca
NCE-UFRJ
Órgão
TRE-RJ
Ano
2001
Provas
Disciplina
Engenharia de Software
Assuntos

Considere as seguintes assertivas sobre modelos teóricos de processo de desenvolvimento de software:

I - O modelo em cascata especifica que a definição do comportamento externo do sistema deve preceder o projeto de sua arquitetura;
II - O modelo incremental requer que na primeira fase seja feito primeiro o levantamento de todos os requisitos do sistema;
III - O modelo de prototipação de requisitos consiste na criação de implementações parciais do sistema com o objetivo de conhecer os requisitos do sistema.

Estão corretas somente:

Alternativas
Comentários
  • A questão pode gerar um pouco de polêmica no item II, onde afirma que TODOS os requisitos devem ser elicitados logo no início do processo. Sendo que Sommerville afirma que o modelo incremental tem a vantagem de postergar o detalhamento de alguns requisitos para os próximos incrementos. Afirmando ser esta uma das características principais dos modelos evolucionários.
    Porém, o que pode ser adiado é o DETALHAMENTO de alguns requisitos e não o levantamento de requistos. E por isso o ítem II está correto.
  • Discordo completamente. A questão não é polêmica, ela está realmente ERRADA.
    Uma das grandes vantagens do modelo incremental é possibilitar que NOVOS requisitos sejam levantados a cada nova iteração, por isso, este modelo não REQUER que primeiro todos requisitos sejam levantados.
  • Eu entendo da seguinte forma:
    O modelo incremental combina elementos do modelo em cascata aplicado de maneira iterativa.
    A cada novo incremento liberado para o cliente, uma nova funcionalidade é agregada. Diferentemente do modelo evolucionário, em que novos incrementos têm melhorias (evoluções) nas funcionalidades já implementadas.
    O início de desenvolvimento do incremento-(N+1) não está condicionando à entrega do incremento-N. Os diversos incrementos podem ser desenvolvidos em paralelo. (Pressman, 6a.Ed. pág.40)
    Deste modo, podemos inferir que todos os requisistos do sistema já estejam levantados, pois de outro modo, como poderia iniciar o desenvolvimento do incremento subsequente antes do feedback do usuário relativo ao incremento anterior, se não tenho os requisitos já levantados?

  • Questão totalmente estranha! Os requisitos não são detalhados todos na primeira iteração! Se assim fosse, seria o modelo cascata! A grande vantagem do modelo incremental é fazer todo o processo de desenvolvimento a cada ciclo!

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
8209
Banca
ESAF
Órgão
Receita Federal
Ano
2005
Provas
Disciplina
Engenharia de Software
Assuntos

O modelo espiral para a Engenharia de Software foi desenvolvido acrescentando-se novos elementos às melhores características de outros modelos. Segundo o modelo espiral, a determinação dos objetivos, alternativas e restrições está relacionada à atividade de

Alternativas
Comentários

  • De acordo com Rezende (2005), o modelo espiral foi desenvolvido para abranger melhor as características do ciclo de vida e prototipação, acrescentando análise de riscos, considerando as seguintes fases:

    Planejamento: determinação dos objetivos, alternativas e restrições.

    Análise de Riscos: análise de alternativas e identificação ou resolução dos riscos.

    Engenharia: desenvolvimento do produto.

    Avaliação: avaliação dos resultados feita pelo usuário.

ID
15790
Banca
CESPE / CEBRASPE
Órgão
ANATEL
Ano
2006
Provas
Disciplina
Engenharia de Software
Assuntos

No que se refere aos modelos de desenvolvimento e ciclos de vida, julgue os itens que se seguem.

No modelo iterativo, divide-se o desenvolvimento em iterações. A cada iteração, podem ser acrescentadas novas funcionalidades ao software. Uma iteração parte do estado no qual se encontravam os artefatos ao término da iteração anterior e resulta em um incremento. Uma iteração pode ter disciplinas como captura de requisitos, análise, projeto, implementação e teste.

Alternativas
Comentários
  • Acho que houve um equivoco da banca ao elaborar esta questão.No meu ponto de vista houve uma confusão entre as metodologias iterativa e incremental.Na incremental, desenvolve-se a primeira versão sem se preocupar muito com o todo.No iterativo, tem-se uma visão geral de todos os requisitos, mas não se implementa todos de uma vez.

  • O Fernando falou e disse.

    Na iteração não se desenvolve novos incrementos e sim se detalha o contexto como um todo.

    Quem faz novos incrementos é o incremental.

    É difícil analisar essas questões, pois isto é apenas teoria, na prática é impossível fazer apenas incremental ou apenas iterativo, um se confude com o utro.

    Na análise da questão ficamos em dúvida se devemos julgar a pratica ou a teoria.

  • Não há nada de errado com a questão.

    Os modelos INCREMENTAL e EVOLUCIONÁRIO ambos são ITERATIVOS.

    A cada iteração o software resulta em incrementos. Os incrementos podem ser novas funcionalidades (modelo incremental), ou podem ser apenas evoluções das funcionalidades existentes na iteração anterior (modelo evolucionário).

  • Realmente o examinador comeu mosca (viajou na maionese) nessa questão. Ele citou o termo "iteração" mas faz referência ao conceito de "incremental".

    Iterativo pode ser Incremental ou Espiral, agora existem diferenças entre Iterativo e Incremental, como mostra a figura abaixo:
  • Gabriel,

    Você tem a referência da imagem? Posso utilizá-la?
  • Fernando,
    Essa imagem eu vi numa apostila de um cursinho de TI para concursos. Bem provável que seja de algum livro, até pq se vc procurar no google por figuras: "monalisa incremental" vc vai ver várias referências a essa imagem.
  • "e resulta em um incremento" o modelo Espiral pode resultar em um incremento, mas não é sempre. Então acho que a resposta esta errada.

  • Perfeito, o desenvolvimento com uso de processo de iteração chegar a ser completo, devido o feedback entre o cliente e desenvolvedores durante todo o processo, pois a interação é constante neste processo.

    Resposta: Certo

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
28603
Banca
CESGRANRIO
Órgão
DECEA
Ano
2006
Provas
Disciplina
Engenharia de Software
Assuntos

Que paradigma da Engenharia de Software é seqüencial e sistemático, iniciando no nível de sistemas e se estendendo pela análise, projeto, codificação, teste e manutenção?

Alternativas
Comentários
  • Também conhecido como Cascata ou Walterfall
  • Esta questão pode confundir devido a palavra: "se estendendo", no entanto torna-se fácil pela palavra: "sequencial e sistemático".

  • Cascata = Sequência linear = Classico

  • Não entendi o que é esse "iniciando no Nível de Sistemas".

  • O Modelo Sequencial Linear (também chamado Ciclo de Vida Clássico ou Modelo Cascata)

    O Modelo Cascata modelo mais antigo e o mais amplamente usado da engenharia de software

    - Modelado em função do ciclo da engenharia convencional

    - Requer uma abordagem sistemática, sequencial ao desenvolvimento de software

    - O resultado de uma fase se constitui na entrada da outra

  • b-

    waterfall model é usado para software, com projeto organizado com fases sucessivas. o release de uma fase é necessario para iniciar a proxima, cujo inicio é predefinido. 

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
114208
Banca
CESPE / CEBRASPE
Órgão
TRE-MT
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Existem vários modelos de desenvolvimento de software, cada um com suas particularidades. A respeito desse assunto, assinale a opção correta.

Alternativas
Comentários
  • a) Etapas do desenvolviemnto em casacata: Requerimento, projeto, implementação, verificação, manutenção ERRADOb) O modelo em cascata acumula riscos ERRADOc) Correto. E atente para o fato que os protótipos não são usáveis. São apenas esqueletos que funcionam usando STUBS ou técnicas de Mágico de Oz, ao contrário do desenvolvimento incremental que produz entregas utilizáveis.d) UML é tecnica de diagramacao ERRADOe) Etapas do desenvolvimento espiral: planejamento, analise de riscos, engenharia e avaliacao do cliente.ERRADO
  • UML é linguagem de modelagem, não é Metodologia.
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
118822
Banca
FCC
Órgão
TRT - 20ª REGIÃO (SE)
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

À medida que se avança pelo modelo ocorre uma iteração e o software evolui para estágios superiores, normalmente com aumento da complexidade. Cada iteração está provida das atividades determinadas pelos quadrantes planejamento, avaliação de alternativas e riscos, desenvolvimento do software e avaliação do cliente. No ciclo de vida de desenvolvimento de software, trata-se da propriedade do modelo

Alternativas
Comentários
  • Modelo de cascata ou sequencial ou modelo clássico: Consiste em um modelo linear em que cada passo deve ser completado antes que o próximo passo possa ser iniciado. Apresenta as seguintes fases:
    1. Análise de requisitos
    2. Projeto
    3. Implementação
    4. Teste
    5. Integração
    6. Manutenção
    Em cada fase desenvolve-se artefatos que serve de base para a fase seguinte.

    Incremental: Combina elementos do modelo cascata de forma interativa. Aplica sequencia linear de uma forma racional à medida que o tempo passa. Cada sequencia linear produz incremento de software passiveis de serem entregues.

    Espiral: O processo de desenvolvimento de software ocorre em ciclo, cada um contendo fases de Planejamento, Análise de risco, Engenharia de software e avaliaçaõ do cliente, onde a opção de abordagem para a próxima fase é determinada.

    Prototipação: É um processo que capacita o desenvolvedor a criar um modelo de software que será implementado. O modelo pode possuir uma das tres formas:
    • Um protótipo em papel
    • Um protótipo de trabalho que implementa algum subconjunto de funções exigidas do software desejado
    • Um programa existente que executa parte ou toda funçao desejada, mas tem outras caracteristicas que são melhoradas

    Balbúrdia:  Não existe. O significado de balbúrdia no dicionário é: desordem ou tumulto que reina em meio a uma multidão.
  • Balbúrdia! Ahahahah. Essa FCC sempre me faz rir.
  • Eu chutei Balbúrdia... :(

    Quem acha que eu deva estudar mais, dá joinha!

  • Mas por que a opção C não estaria correta? O protótipo também não está evoluindo e não tem quadrantes muito similares, vide a definição de Pressman para ambos os modelos?

  • Quando ver RISCOS, já comece a pensar em modelo Espiral

  • c-

    Espiral usa iterações que vao aumentando em complexidade à medida que se aproximam do desejado. Como o colega disse, palavra-chave do espiral é risco

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
126508
Banca
ESAF
Órgão
Prefeitura de Natal - RN
Ano
2008
Provas
Disciplina
Engenharia de Software
Assuntos

O modelo Espiral para a Engenharia de Software define quatro importantes atividades representadas pelos quatro quadrantes da figura. Quanto a estas atividades, é correto afi rmar que a

Alternativas
Comentários
  • As alternativas não estão apresentando coesão alguma também!
  • A questão se refere a essa figura: http://pt.scribd.com/doc/88398248/13/Espiral-ou-Evolutivo (página 15)
  • Planejamento: determinação dos objetivos, alternativas, e restrições

    Letra A
  • Uma das versões da Espiral tem quatro quadrantes: planejamento, análise dos riscos, engenharia e avaliação feita pelo cliente.
    a) CORRETO!
    b) Análise dos Riscos
    c) Avaliação Feita Pelo Cliente
    d) Avaliação Feita Pelo Cliente
    e) Análise dos Riscos
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
129973
Banca
CESPE / CEBRASPE
Órgão
SERPRO
Ano
2008
Provas
Disciplina
Engenharia de Software
Assuntos

Considerando os modelos do ciclo de vida de software, julgue os
itens que se seguem.

O modelo em cascata consiste de fases e atividades que devem ser realizadas em seqüência, de forma que uma atividade é requisito da outra.

Alternativas
Comentários
  • Fonte: Engenharia de Software
    Autor: Roger S. Pressman
    Página: 39

    Capítulo 3 - Modelos prescritivos de processos
    3.1 O modelo em Cascata
    (...)
    Numa análise interessante de projetos reais, Bradac descobriu que a natureza linear do modelo em cascata leva a "estado de bloqueio" nos quais alguns membros da equipe de projeto precisam esperar que outros embros completem as tarefas dependentes.
  • Pressman, pg 39
    As fases seriam a comunicação, planejamento, modelagem, construção e implantação. E dentro de cada fase existem atividades, como:
    na comunicação (iniciação do projeto,levantamento de requisitos)
    no planejamento (estimativas, cronogramação e monitoração)
    etc.
  • Formalizado por Royce em 1970, é o modelo mais antigo. Começa pela parte mais simples do software. O modelo em cascata tem o grande mérito de ser o primeiro a impor o planejamento e o gerenciamento ao processo de software, que antes era casual. O nome "cascata" foi atribuído em razão da sequência das fases, onde cada fase só começa quando a anterior termina, e da transmissão do resultado da fase anterior como entrada para a fase atual (o fim de cada fase resulta em um documento aprovado). Nesse modelo, portanto, é dada muita ênfase às fases de análise e projeto antes de partir para a programação, a fim de que o objetivo do software esteja bem definido e que sejam evitados retrabalhos. Na falta de uma abordagem estruturada, foi a primeira tentativa de formalizar uma metodologia de desenvolvimento de software. Devido à sua simplicidade, o modelo em cascata é fácil de ser entendido pelo cliente. É um modelo que supõe um início e fim claro e determinado, assim como uma estimativa precisa de custo logo no início, fatores importante na conquista do cliente. O modelo em cascata não prevê revisão de fases. Assim, o risco é muito alto, principalmente para sistemas complexos, de grande porte, afinal, o modelo em cascata pressupõe uma realidade estática e bem conhecida, comparado a uma linha de produção fabril.
    Alternativa: Certa

    Fonte: Artigo Dev Media

  • Fases são a mesma coisa que Atividades? Fases são em sequência e uma é requisito da outra, isso é claro, mas Atividades também?

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

Considerando os modelos do ciclo de vida de software, julgue os
itens que se seguem.

O modelo iterativo e o modelo em espiral possuem características semelhantes: ambos permitem que as atividades do processo sejam planejadas e avaliadas ao longo do ciclo de vida.

Alternativas
Comentários
ID
129982
Banca
CESPE / CEBRASPE
Órgão
SERPRO
Ano
2008
Provas
Disciplina
Engenharia de Software
Assuntos

Considerando os modelos do ciclo de vida de software, julgue os
itens que se seguem.

O modelo orientado a reúso parte de um software existente para que se crie outro, no todo ou apenas em parte de seus componentes.

Alternativas
Comentários

  • Gabarito: Certo
    Os     modelos econômicos de reuso podem ajudar na tomada de decisões relacionadas ao     investimento em reuso. Estas decisões envolvem questões sobre se deve, ou não, investir em reuso, se se deve investir em um tipo de reuso ou outro, e se se deve desconsiderar reuso e investir em outra coisa. Estes modelos objetivam capturar custo e benefícios de reuso numa simples formulação matemática. Seu principal uso é apresentar os benefícios líquidos estimados de um potencial investimento em reuso. Entretanto, pelo fato de que as poupanças de reuso podem ser difíceis de determinar mesmo depois que o reuso tenha sido adotado, um outro uso de modelos econômicos é estimar os benefícios líquidos devido ao reuso depois do evento, ou seja, depois de sua adoção.
     

    Graça e Paz

  • Discordo do gabarito. Questão mal formulada.

    Nem todo software novo será criado a partir de um existente no modelo a reuso. O software pode ser inteiramente novo, desde que criado pensando em se reutilizar as suas partes no futuro.
  • Modelo orientado à Reuso: 
    O conceito de reutilização de software se baseia na programação modular onde podemos fazer uso de procedimentos, funções e classes pré-existentes criados por outros que servirão para que outros literalmente montem suas aplicações finais. 
    Muitas bibliotecas são oferecidas juntamente com as ferramentas de desenvolvimento para reduzir o tempo e a complexidade de projetos de software.
  • As questões do CESPE são sempre sujeitas a interpretação. Eu considero esta questão errada. O modelo orientado a reuso parte de um componente de software existente, não de um software existente.
  • Pessoal, procurem colocar as fontes sempre que possível.
    Abraço!

  • Complicado!! Então para CESPE não é possível desenvolver um software do zero, utilizando o modelo orientado a reuso?  Lamentável 

  • Quando a questão menciona que o modelo parte de um software existente, significa dizer, no meu entendimento, que aquele componente que será usado, foi utilizado por um sistema já em produção. Logo, partimos de um software existente. Isto é provado na página 307 do livro do Sommerville (9ª Edição):

    Reúso de produtos COTS: Um produto de prateleira (COTS, do inglês, commercial-off-the-shelf) é um sistema de software que pode ser adaptado às necessidades de diferentes clientes sem alterar o código-fonte do sistema.

    São complicadas questões do CESPE. Precisamos não generalizar demais, caso contrário a probabilidade de erro é grande.

  • Questão certa e não vejo erro nenhum nela, quem já leu o Capitulo 3 Processos de Software do livro do Sommervile 6º Edição logo no inicio ele é bem claro "Processo de software pode envolver o desenvolvimento de software desde o início, embora, cada vez mais, ocorra o caso de um software NOVO ser desenvolvido mediante a EXPANSÃO e a modificação de sistemas JÁ EXISTENTES"

    Questão CERTA !
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
135406
Banca
CESPE / CEBRASPE
Órgão
EMBASA
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Acerca de princípios de engenharia de software, julgue os itens a
seguir.

Um modelo de processo de software descreve os processos que são realizados para atingir o seu desenvolvimento. A notação para as tarefas, os artefatos, os atores e as decisões varia conforme o modelo de processo utilizado.

Alternativas
Comentários
  • Como assim? E se eu quiser usar notação UML para descrever "tarefas, os artefatos, os atores e as decisões"?
  • Também não entendi.
    Algum comentário?
  • A notação para as tarefas, os artefatos, os atores e as decisões varia conforme o modelo de processo utilizado ==> Não quer dizer UML

  • Um modelo de processo de software é uma representação simplificada de um processo de software. Cada modelo representa uma perspectiva particular de um processo e, portanto, fornece informações parciais sobre ele.

     

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

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

  •  A 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
136249
Banca
ESAF
Órgão
MPOG
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

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

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

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

  • Complementando a resposta, muito boa do colega Leonardo:

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

    Modelo Espiral do Sommerville: 

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

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

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

    4) Planejamento da próxima fase;

ID
137128
Banca
FGV
Órgão
Senado Federal
Ano
2008
Provas
Disciplina
Engenharia de Software
Assuntos

Considere as seguintes assertivas sobre modelos de processos de software:

I. No modelo em cascata, a fase seguinte não deve iniciar antes que a fase precedente tenha sido concluída.
II. No modelo evolucionário, a mudança constante tende a corromper a estrutura do software
III. A explícita consideração dos riscos no modelo em espiral distingue esse modelo dos modelos em cascata e evolucionário.

As assertivas corretas são:

Alternativas
Comentários

  • De acordo com o link http://www.linux.ime.usp.br/~cef/mac499-05/monografias/rec/daw/eng_soft.html, o item II está correto. Assimo como a maioria, tinha colocado a letra C, mas infelizmente a correta é a letra E.

  • Sommerville, no capítulo sobre processos de software:   "... a abordagem evolucionária tem dois problemas:
      1. ...   2. Os sistemas são frequentemente mal estruturados. A mudança contínua tende a corromper a estrutura do software."
  • Muito estranha essa questão, pois o modelo em espiral faz parte da categoria dos modelos evolucionários.
  • A resposta correta desta questão deveria ser a alternativa B. O modelo em espiral não se destingue dos modelos evolucionários uma vez que ele faz parte do modelo evolucionário. Os Modelos evolucionários são: Prototipagem, Espiral e Desenvolvimento Concorrente. 
  • Que ódio desse QC. Digita o captcha errado e perde TODO o comentário. Parece projeto final de faculdade.


    Enfim, eu havia dito que na pagina 49 da 8a edicao do Sommervile responde ao comentário do Jorge.

    E a pagina 45 corrobora o item II da questao.
  • Sommerville, 9ª pág. 34:
    From a management perspective, the incremental approach has two problems:
    1. The  process  is  not  visible.  Managers  need  regular  deliverables  to  measure progress. If systems are developed quickly, it is not cost-effective to produce documents that reflect every version of the system.
    2. System structure tends to degrade as new increments are added. Unless time and money is spent on refactoring to improve the software, regular change tends to corrupt its structure. Incorporating further software changes becomes increas-ingly difficult and costly
  • Justificativa da III:

    "The main difference between the spiral model and other software process models is its explicit recognition of risk"

    Sommerville, 9ed., página 50
  • Prezado Marcelo Guimaraes,

    Você poderia reproduzir o texto     da página 49 da 8a edicao do Sommervile que responde ao comentário do Jorge? Tenho a mesma dúvida mas não possuo o livro.

    Obrigado.
  • I. No modelo em cascata, a fase seguinte não deve iniciar antes que a fase precedente tenha sido concluída.   VERDADEIRO 
    Para seguir um modelo em cascata, o progresso de uma fase para a próxima se dá de uma forma puramente sequencial.

    II. No modelo evolucionário, a mudança constante tende a corromper a estrutura do software     VERDADEIRO
    Embora a prototipação tenha enormes vantagens e deva ser incentivada, basear o desenvolvimento no incremento de protótipos pode levar a software mal documentados e com arquiteturas mal definidas. Como os requisitos estão sempre sendo revistos a cada ciclo de desenvolvimento, torna-se praticamente impossível estimar custos e prazos e planejar as atividades de desenvolvimento. Assim  corrompendo a estrutura do software.

      III. A explícita consideração dos riscos no modelo em espiral distingue esse modelo dos modelos em cascata e evolucionário.   VERDADEIRO
    "A principal diferença entre o modelo espiral e outros modelos de processo de software é o reconhecimento explícito de risco"

    []'s
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
140887
Banca
CESPE / CEBRASPE
Órgão
ANTAQ
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

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

O modelo em espiral, que descreve o processo de desenvolvimento de um software, apresenta uma espiral em que cada loop representa uma fase distinta desse processo. A ausência de risco nesse modelo o diferencia dos demais modelos de software.

Alternativas
Comentários

  •  O modelo espiral é um modelo evolucionário que consequentemente são iterativos, ou seja, permite que os engenheiros de software produzem versãoes de software cada vez mais completas.

     
    1 erro -> No modelo espiral cada loop representa uma ITERAÇÃO e não uma fase distinta.
    2 erro -> Outro erro é falar que neste modelo não há riscos. Pressman diz: "...O modelo espiral exige a consideração direta dos riscos técnicos em todos os estágios do projeto e, se aplicando adequadamente, deve reduzir os riscos antes que eles se tornem problemáticos."

  • Na minha humilde opinião, no trecho abaixo...

    "uma espiral em que cada loop representa uma fase distinta desse processo"

    Essa trecho está correto. Já vi isso em várias fontes... Inclusive na questão http://www.questoesdeconcursos.com.br/questoes/953bea1c-bc.

    O erro está aqui: "A ausência de risco nesse modelo o diferencia dos demais modelos de software."

    O modelo espiral se diferencia dos outros, justamente por incluir explicitamente os riscos.

  • Concordo com vc, Betopanza. Cada loop representa uma fase no processo. Sommerville ainda afima que a principal diferença entre esse modelo e outros eh o reconhecimento explícito dos riscos. Ou seja, as duas partes da afirmação estão erradas.
  • "O modelo espiral de desenvolvimento é um gerador de modelos de processos dirigidos a riscos e é utilizado para guiar a engenharia de sistemas intensivos de software, que ocorre de forma concorrente e tem múltiplos envolvidos"
    Pressman, 7ed, pag 65

    Uma das principais características do modelo espiral é a intensa e contínua gestão de riscos.
  • Livro do Sommerville, 8ª edição, capítulo 4 - Processos de software, página 48:

    "Em vez de representar o processo de software como uma sequência de atividades com algum retorno entre uma atividade e outra, o processo é representado como uma espiral.Cada loop na espiral representa uma fase do processo de software. Dessa forma, o loop mais interno pode estar relacionado à viabilidade do sistema; o próximo loop, à definição de requisitos; o próximo, ao projeto de sistema e assim por diante."

  • Olha aqui uma questão pra cair na PF-21

  • cespe ama esse peguinha

    Considerando a teoria geral de sistemas e sistemas de informação, julgue o item a seguir.

    Embora não seja dirigido a riscos, o modelo de desenvolvimento de sistemas espiral de Boehm inclui, em seu framework, a etapa de análise e validação dos requisitos. 

    GABARITO: Errado.

  • Espiral é uma abordagem para desenvolvimento de software na qual se cria um modelo do software que será implementado, é composta de quatro etapas: planejamento, análise de risco, engenharia e avaliação do cliente

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

O modelo de processo de software caracterizado por intercalar as atividades de especificação, desenvolvimento e validação, denomina-se

Alternativas
Comentários

  • Na verdade, o correto é letra C. O gabarito foi alterado pela ESAF, mas o QC não atualizou a prova.

    Segundo Sommerville:

    Desenvolvimento Evolucionário: abordagem que intercala as atividades de especificação, desenvolvimento e validação. Um sistema inicial é rapidamente desenvolvido a partir de especificações abstratas, que são então refinadas com informações do cliente, para produzir um sistema que satisfaça suas necessidades.

     

  • Puxa, obrigada, Samuel. Coloquei a letra C, quando vi o gabarito do QC, pensei: "Realmente não sei mais nada de EngSoft".

    :-)

  • Olá, pessoal!
     
    O gabarito foi atualizado para "C", após recursos, conforme edital publicado pela banca, e postado no site.
    Bons estudos!
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
142036
Banca
CESPE / CEBRASPE
Órgão
TRE-MT
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Assinale a opção correta acerca de modelos de processo de software.

Alternativas
Comentários

  • a) Alternativa errada pois o modelo em cascata necessita da fase de análise de requisitos.
    O modelo em cascata move-se para a próxima fase somente quando a fase anterior esta completa e perfeita. Desenvolvimento de fases no modelo em cascata são discretas, e não há pulo para frente, para trás ou sobreposição entre elas.
    Fonte: http://pt.wikipedia.org/wiki/Modelo_em_cascata

     Alternativa B Correta: Os processos de desenvolvimento ágil de software valorizam mais:
    1) interações > processos e ferramentas;
    2) software funcionando >documentação compreensível;
    3) colaboração do cliente > negociação contratual; e
    4 ) respostas a mudanças > planejamento seguido
    http://www.slideshare.net/rafael.ufs/metodologias-ageis-presentation

    Alternatica C errado. São definições semelhantes, porém não iguais.

    Desenvolvimento Incremental é uma estratégia de planejamento estagiado em que várias partes do sistema são desenvolvidas em paralelo, e integradas quando completas.

    Desenvolvimento iterativo é uma estratégia de planejamento de retrabalho em que o tempo de revisão e melhorias de partes do sistema é pré-definido. Isto não pressupõe desenvolvimento incremental, mas funciona muito bem com ele.

    d) Alternativa incorreta. Não há ausencia do cliente  nas áreas iniciais.  Está sempre um representante do cliente no local e faz parte da equipe

    Fonte: www.estig.ipbeja.pt/~eides/XP%20-%20Presentation.ppt 

    e) Alternativa E: InCorreta. Pois não se dá em todas as fases dos processos.
    Programação em par ou programação em duplas é uma das práticas mais conhecidas e mais polêmicas utilizadas pelos que adotam o Extreme Programming (XP).sugere que todo e qualquer código produzido no projeto seja sempre implementado por duas pessoas juntas
    Fonte: http://improveit.com.br/xp/praticas/programacao_par

  • Só uma coisinha a respeito da letra "C". Se alguém teve dúvidas (assim como eu) da diferença entre iterativo e incremental, é só dar uma olhada nessa figura:

  • Pelo que eu li, valorizam mais software funcionando do que "documentação abrangente" e não "documentação compreensível'. Isso me deixou com dúvidas na hora de marcar a questão.

  • Concordo com a Renata, 

    (Pelo que eu li, valorizam mais software funcionando do que "documentação abrangente" e não "documentação compreensível'. Isso me deixou com dúvidas na hora de marcar a questão.)

    "abrangente" é diferente de "compreensível". Isso muda o sentido da frase. e para mim esta errada. No desenvolvimento ágil toda documentação que é elaborada ela tem que ser "compreensível".

  • Fonte: Manifesto Ágil

    Individuos e interações do que processos e ferramentas

    Software em funcionamento do que documentação abrangente

    Colaboração do cliente do que negociação de contrato

    Respostas a mudanças do que seguir um plano


    Feito em 2048.

  • A B tá certíssima!

    Entretanto, a C tb!

    Pois os processos de desenvolvimento iterativos são os incrementais e os evolucionários (prototipagem, espiral), só ver no livro do pressman ou do sommerville, easy-easy!

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
142258
Banca
CESGRANRIO
Órgão
BNDES
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

No ciclo de vida em cascata, o custo de correção é menor na fase de

Alternativas
Comentários
  • No ciclo de vida em cascata os custos aumentam à medida que as fases avançam.
  • Um erro identificado na fase final do ciclo de vida em cascata pode representar de 60-100 vezes o custo para corrigi-lo se fosse identificado logo no início na fase de requisitos.
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
147289
Banca
FCC
Órgão
SEFAZ-SP
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

O processo de engenharia de software denominado ciclo de vida clássico refere-se ao modelo

Alternativas
Comentários
  • Resposta letra A.

    O modelo em cascata sugere uma abordagem sistemática seguindo uma seqüênciade acontecimentos que darão início a outras fases até que o processo inteiro estejaterminado

    . Comunicação ou Requisitos
    . Planejamento
    . Analise e projeto
    . Construção
    . Testes
    . Implantação

    Fonte: Pressman.
  • Só pra constar, o modelo em cascata também é conhecido pelos seguintes nomes:
    • Cascata;
    • Linear;
    • Sequêncial;
    • Clássico.

  • Definição classica de cascata:

     

    Modelo de ciclo de vida clássico, abordagem sistemática em que as fases são funções na engenharia convencional. Característica :todas as fases têm início e término definidos; uma fase só inicia se anterior concluída. Proposto por Winston W. Royce em 1970, é desde a década de 1980 amplamente usado porque é a mais conhecida, simples e fácil de trabalhar.Ao final de cada fase ou marco uma revisão avalia se pode avançar para a próxima e, quando apontar que o projeto não está apto a entrar na fase seguinte, ele permanece na fase atual até aprovado, ou seja, especificação, codigo e testes seguem uma única disciplina; nenhuma atividade inicia sem anterior aprovada.

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
153091
Banca
CESPE / CEBRASPE
Órgão
TJ-DFT
Ano
2008
Provas
Disciplina
Engenharia de Software
Assuntos

Acerca da engenharia de software e de metodologias e ciclos de
desenvolvimento de software, julgue os itens subseqüentes.

O modelo em espiral é um modelo de processos de software que reúne a natureza iterativa da prototipação com os aspectos sistemáticos e controlados do modelo seqüencial linear.

Alternativas
Comentários

  • Segundo Pressman, o modelo Espiral é um modelo iterativo, como o modelo de prototipagem, e sistemático como o modelo Linear, isso facilita com que sejam lançadas versões utilizáveis do projeto ao final de cada iteração do modelo. 

  • Não ficou claro pra mim o trecho "natureza iterativa da prototipação". A prototipação sequer é iterativa e sim, no máximo, evolucionária. Na minha opinião isso invalida o item.

  • Ctrl + C seguido de Ctrl + V do livro do Pressman, em relação à definição do modelo esperial.

  • (CESPE - COHAB - 2004) O modelo espiral é um modelo de processo de software que combina a natureza iterativa da prototipagem com os aspectos controlados e sistemáticos do modelo sequencial linear. 

    Questão copiada do CESPE para o CESPE.

ID
153097
Banca
CESPE / CEBRASPE
Órgão
TJ-DFT
Ano
2008
Provas
Disciplina
Engenharia de Software
Assuntos

Acerca da engenharia de software e de metodologias e ciclos de
desenvolvimento de software, julgue os itens subseqüentes.

No modelo de desenvolvimento incremental, embora haja defasagem entre os períodos de desenvolvimento de cada incremento, os incrementos são desenvolvidos em paralelo.

Alternativas
Comentários
  • CORRETO.

    Note da figura abaixo que em um dado momento do tempo estamos testando um incremento, codificando outro, desenhando outro e analisando outro. Portanto, "os incrementos são desenvolvidos em paralelo."

    http://screencast.com/t/OTg0YTc5Yjct
    Fonte.: Pressman 5ed p35

  •  incrementos são desenvolvidos em paralelo??

  • Apenas para exemplificação, o modelo RAD é um modelo de desenvolvimento incremental e seus incrementos são implementados em paralelo.

     

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

  • No modelo de desenvolvimento incremental, embora haja defasagem entre os períodos de desenvolvimento de cada incremento, os incrementos são desenvolvidos em paralelo.

    Uma duvida pessoal existe um modelo de desenvolvimento com o nome de modelo de desenvolvimento incremental?

    O certo não seria:
    No modelo de desenvolvimento Iterativo, embora haja defasagem entre os períodos de desenvolvimento de cada incremento, os incrementos são desenvolvidos em paralelo.
  • Não confundir Simultâneo com Paralelo. 

    Em que Simultâneo faz com que todos as interações comecem e terminen todas ao mesmo tempo.
    Já o Paralelo, não exige que todos comecem ao mesmo tempo, como mostrado nesta figura: http://screencast.com/t/OTg0YTc5Yjct
  • creio que a confusão seja essa:

    desenvolvido é entendido como codificação pra qm programa. E se for nesse aspecto, não é feito simultaneamente.

    mas pelo visto o "desenvolvimento" usado na pergunta seria p/ o projeto em geral, aí nesse caso estaria correto! 
  • Acredito que o mais correto seria falar que os incrementos são concorrentes.

  • Os incrementos PODEM ser desenvolvidos em paralelo, mas nem sempre o são. Como foi escrita, a questão afirma que não posso ter um incremento de software finalizado e começar a desenvolver um segundo incremento por exemplo, supondo que o projeto sofreu uma restrição orçamentária, o que atrasou o desenvolvimento do próximo incremento. Isso acontece na prática, aliás acontece em larga escala. No meu ver questão incorreta.

ID
153100
Banca
CESPE / CEBRASPE
Órgão
TJ-DFT
Ano
2008
Provas
Disciplina
Engenharia de Software
Assuntos

Acerca da engenharia de software e de metodologias e ciclos de
desenvolvimento de software, julgue os itens subseqüentes.

No modelo seqüencial linear, os produtos do projeto são entregues somente após a validação do produto.

Alternativas
Comentários
  • Ao final de cada etapa os produtos do projeto referentes aquele etapa são entregues.
  • Discordo da opnião do colega abaixo.
    Segundo Pressman:

    "Sometimes called the classic life cycle or the waterfall model, the linear sequential model
    suggests a systematic, sequential approach5 to software development that begins at
    the system level and progresses through analysis, design, coding, testing, and support."

    Portanto, a entrega é feita após os testes, quando se inicia o suporte.
    As entregas em cada etapa, segundo afirmou o colega, não são características de um modelo em cascata. Este tem suas entregas apenas ao final do projeto
  • A interpretação do primeiro colega está correta, visto que entregas como é definida na questão se refere a qualquer tipo de entrega e não apenas ao software executavel, assim modelos, documentos, relatórios e qualquer outro tipo de elemento que possa ser entregue nas fase de concepção, planejamento, desenvolvimento e implantação invalidam a questão!!
  • Errado. No modelo sequencial linear só é possível passar para a próxima etapa do processo, quando a etapa anterior for validada. E a questão diz:
    "No modelo seqüencial linear, os produtos do projeto são entregues somente após a validação do produto"
    O Correto Seria
    No modelo seqüencial linear, o produto é entregue somente após a validação dos produtos do projeto.
  • Modelo sequencial linear é o modelo cascata.
    validação = construimos o produto corretamente? De acordo com o que foi especificado?
    verificação = construimos o produto certo? O que foi especificado era o esperado pelo cliente?
    Ambas realizadas pela a equipe de SQA. Por isso a questão está errada, os produtos do projeto são entregues após validação e verificação.
  • Acho que o erro está na palavra validação.

    os produtos são entregues após a aceitação do produto por parte do cliente, e não após a validação do produto...
  • Eu acho que o erro é que falta a palavra aceitação. Não adianta só o cliente avaliar. Ele tem que aceitar também.
    Na minha opinião, o certo seria:
    No modelo seqüencial linear, os produtos do projeto são entregues somente após a validação e aceitação do produto.

    Me desculpem, mas não lembro da fonte desta citação, mas está nos meus resumos (e eu tenho certeza de que foi tirado, ou do Pressman, ou do Sommerville): "O modelo em cascata tem a vantagem que só avança para a tarefa seguinte quando o cliente dá validade e aceitação os produtos finais da tarefa atual."
  • Como já disse outro colega, o primeiro comentário está correto. Os produtos do projeto não são só os executáveis, são também a documentação do projeto.
    Conforme Sommerville, 8ª edição. p. 44:

    Em princípio, o resultado de cada fase consiste de um ou mais documentos aprovados('assinados').
  • Bom, acho que a questão é passivel de anulação.
    No modelo em cascata (linear), no final de cada fase é feita uma verificação e homologação a fim de definir se os documentos gerados na fase atendem aos requisitos do sistema. O problema que esses documentos NÃO SÃO PRODUTOS, alias,  a essência do modelo em cascata é justamente não ter produtos intermediários.

  • ****************** DESVENDANDO*****************

    No modelo em cascata, os artefatos de requisitos (produtos do projeto) são entregues somente quando o software está finalizado (validado) ?

    Claro que não. Até pq esses podem fazer parte do contrato de aquisição do software.


    Abraço.

  • Acho que validação tem mais a ver com os requisitos do sistema...e aceitação com o cliente, então acho que a questão quis dizer que os produtos do projeto (software + documentação) só são entregues após o cliente dar o aceite...pois como disse o colega, uma das características do modelo linear é realmente não ter entregas intermediárias. Agora, se compreendermos a palavra "validação" como sendo a validação final dada pelo cliente, a sentença estaria verdadeira!

  • banca porca!

  • Com uma maior documentação e entendimento atualmente/2021 é possível garantir que o gabarito dessa questão é "CORRETO"

    Por partes...

    1 - O Modelo Sequencial Linear também é chamado Modelo Cascata.

    2 - Sua principal característica (Modelo Cascata) é a divisão das tarefas em etapas predeterminadas, que são executadas de forma sequencial.

    3 - É preciso finalizar todas as tarefas de uma etapa para que seja possível passar para a seguinte. Ao cumprir todas as etapas, o resultado será um produto de software funcional, pronto para ser entregue ao cliente.

    4 - Basicamente, o desenvolvimento é dividido em cinco etapas, que começam assim que a anterior termina:

    Especificação 

    Projeto do software

    Implementação

    Teste unitário

    Integração

    Teste de Sistema 

    No final da integração, é feito um teste geral para certificar (validação) que os “requisitos do sistema” foram completamente atendidos. Por fim, o software é entregue ao cliente;

    Operação e manutenção

    Fontes:

    https://edisciplinas.usp.br/pluginfile.php/839466/mod_resource/content/1/Aula02_ModelosProcessos.pdf

    https://blog.betrybe.com/tecnologia/modelo-cascata/

    https://medium.com/contexto-delimitado/o-modelo-em-cascata-f2418addaf36

    Engenharia de software / Roque Maitino Neto - 2016

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
159001
Banca
CESPE / CEBRASPE
Órgão
STJ
Ano
2008
Provas
Disciplina
Engenharia de Software
Assuntos

Acerca de processos de software, julgue os itens de 75 a
78.

Entre as atividades em um processo de projeto de software, pode-se ter: a identificação e a documentação dos subsistemas existentes e os seus relacionamentos; a especificação dos serviços providos por cada subsistema e das restrições de operação dos mesmos; a documentação da interface entre subsistemas; a especificação de estruturas de dados e algoritmos usados.

Alternativas
Comentários

  • O erro está destacado em negrito e sublinhado:

    Entre as atividades em um processo de projeto de software, pode-se ter: a identificação e a documentação dos subsistemas existentes e os seus relacionamentos; a especificação dos serviços providos por cada subsistema e das restrições de operação dos mesmos; a documentação da interface entre subsistemas; a especificação de estruturas de dados e algoritmos usados.

  • Análise x Projeto:

    - Abstrato x Concreto
    - Independente x Dependente da tecnologia de implementação
    - Simples x Detalhado
    - Modelos por caso de uso x Unificação em um único modelo

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
162925
Banca
CESGRANRIO
Órgão
Petrobras
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Uma das principais atividades do processo de teste de um ciclo de vida de um projeto qualquer é

Alternativas
Comentários
  • Durante o ciclo de vida do projeto é necessária a criação de documentos de testes, rotinas de testes e em alguns casos é necessária a criação de sistemas teste automático afim de que não se perca horas e esforço humano para tal serviço.
  • a) projetar testes que tratem da especificação de procedimentos externos ao computador, tais como: captação das informações, identificação das partes interessadas e distribuição das saídas.
    ERRADO - Os testes devem ser projetados visando as funcionalidades do próprio sistema, e não o que acontece externamente a ele. Além disso captação das informações, identificação das partes interessadas e distribuição de saídas não fazem parte do processo de testes.

    b) projetar o processo de teste criando casos de teste, rotinas de teste e, eventualmente, desenvolvendo programas que fazem o teste de forma automática.
    CERTO - Estas são as principais tarefas do processo de testes. O desenvolvimento de programas que realizam o teste de forma automática é especialmente importante para a realização de testes de regressão.

    c) analisar e definir testes através da manipulação de ferramentas de processos usadas especialmente para obtenção de requisitos de teste de software, tais como: CMMI, BPM e ISO 9001:2000. 
    ERRADO - O processo de testes utiliza Ferramentas de Testes, e não de processos. CMMI, BPM e ISO são não são usados para obtenção de requisitos de teste. Em resumo, CMMI é um modelo de referência para processos, BPM é uma metodologia para modelagem e melhoria de processos e a ISO 9001:2000 é a norma que define um sistema de gestão da qualidade para as empresas.

    d) produzir testes e o manual de especificação do uso do sistema que é utilizado para ensinar o usuário a manipular o produto final do software.
    ERRADO - O RUP fala que o manual do usuário "pode ser escrito por escritores técnicos, com a colaboração de desenvolvedores, ou pode ser escrito pela equipe de teste, cujos membros provavelmente compreendem a perspectiva do usuário". O que invalida a questão é que esta não é uma das atividades principais do processo de testes.

    e) testar as unidade de software na fase de operação e manutenção do sistema e utilizar os resultados como métricas para eventuais ajustes em projetos anteriores.
    ERRADO - Os testes unitários devem ser realizados pelos desenvolvedores durante a fase de implementação, e não na fase de operação e manutenção.

  • Solange, gostei da sua resposta porém BPM não é Metodologia.


    Metodologia está ligado a uma prescrição (detalhada) de atividades a serem feitas para chegar num determinado objetivo. 


    BPM é uma disciplina gerencial que integra estratégias e objetivos de uma organização com expectativas e necessidades de clientes, por meio do foco em processos ponta a ponta.


    Na página 54 do BPM CBOK v3 está explícito:

    2.2.2 BPM não é uma prescrição de estrutura de trabalho, metodologia ou conjunto de ferramentas


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
163036
Banca
CESGRANRIO
Órgão
Petrobras
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

O modelo de ciclo de vida em cascata

Alternativas
Comentários
  • Modelo de Prototipagem:
    enfatiza a comunicação estreita com o cliente durante o desenvolvimento do produto de software
    envolve a ideia principal de criar um protótipo executável e, através de transformações sucessivas, chegar ao sistema completamente implementado.

    Modelo Espiral
    envolve a análise dos riscos envolvidos no desenvolvimento dos requisitos identificados para produto de software.

    Modelo Evolutivo
    recomenda a geração de versões incompletas do sistema, que podem ser passadas para o usuário final, o que permite a retroalimentação do processo de desenvolvimento.
  • b) enfatiza a comunicação estreita com o cliente durante o desenvolvimento do produto de software. --> XP, SCRUM

     c) envolve a ideia principal de criar um protótipo executável e, através de transformações sucessivas, chegar ao sistema completamente implementado. --> Prototitagem Evolucionada

     d) envolve a análise dos riscos envolvidos no desenvolvimento dos requisitos identificados para produto de software. --> Espiral

    e) recomenda a geração de versões incompletas do sistema, que podem ser passadas para o usuário final, o que permite a retroalimentação do processo de desenvolvimento.

  • a) enfatiza a realização sequencial das atividades do desenvolvimento de um produto de software

    Em cascata, as atividades sao isoladas e iniciadas somente quando a anterior terminar (sequencial, linear & rigido). As fases sao engenharia de sistema, analise, projeto, codigo, teste & manuntenação. Analise de risco pe tratado em espiral, o qual tem 4 fases: planejamento, analise risco, engenharia e avaliação do cliente. Em prototipação, ha 2 tipos: evolucionario, o qual produz um prototipo p/ usuario e discartavel, o qual é um prototipo para verificar problemas com requisitos.

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
164599
Banca
FGV
Órgão
BADESC
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

O Modelo Espiral, segundo Pressman (1995), incorpora as melhores características do Ciclo de Vida Clássico e da Prototipação e acrescenta o seguinte elemento:

Alternativas
Comentários
  • Letra A

    A analise de riscos é uma das principais implementações do modelo espiral.
    As demais alternativas não estão de acordo.
  • Ele usa uma abordagem “evolucionária” à engenharia de software, capacitando o desenvolvedor e o cliente a entender e reagir aos riscos em cada fase evolutiva. O modelo espiral usa a prototipação como um mecanismo de redução de riscos, mas, o que é mais importante, possibilita que o desenvolvedor aplique a abordagem de prototipação em qualquer etapa da evolução do produto. Ele mantém a abordagem de passos sistemáticos sugerida pelo ciclo de vida clássico, mas incorpora-a numa estrutura iterativa que reflete mais realisticamente o mundo real. O modelo espiral exige uma consideração direta dos riscos técnicos em todas as etapas do projeto e, se adequadamente aplicado, deve reduzir os riscos antes que eles se tornem problemáticos.

  • Sempre que referenciar modelo espiral fique atento as menções à risco.

  • Uma dúvida.. nos outros modelos não há a análise de risco ou somente não é explítica como  no modelo espiral?

    De acordo com o professor Diego do Estratégia concursos:

    "Conforme vimos em aula, existe sim Análise de Riscos no Modelo em Espiral. No entanto, isso não significa que ela seja inexistente no Modelo em Cascata e no Modelo de Prototipação, ela apenas não é explícita como no Modelo em Espiral."

  • Falou em ESPIRAL falou em Riscos

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