SóProvas



Questões de Metodologia de desenvolvimento 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
17773
Banca
CESGRANRIO
Órgão
BNDES
Ano
2008
Provas
Disciplina
Engenharia de Software
Assuntos

Suponha que um projeto de software siga o modelo cascata e utilize técnicas de refatoração apoiadas por uma ferramenta durante a etapa de implementação. Qual o impacto resultante na etapa de análise e projeto?

Alternativas
Comentários
  • Achei uma pergunta um tanto capciosa do examinador, porque existem diversos aspectos envolvidos em um projeto de software que podem influir de modo favorável ou prejudicial ao se utilizar 'refactoring'. Um deles, de grande relevância, é o uso de testes unitários e funcionais. A XP se baseia efetivamente nisso, desenvolver os testes primeiramente. E sem um bom projeto de testes, fazer refatoração pode até ser desastroso em alguns casos.

    Mas partindo do pressuposto de "condições normais de temperatura e pressão (CNTP)" eu pensei do seguinte modo: o gestor responsável pela fase de análise e projeto ficaria bem mais tranquilo porque ao promover mudanças no modelo estas seriam implementadas mais facilmente e com mais segurança num código refatorado, pois este tem como premissas ser mais claro (limpo, fácil de entender e de manter) e funcional.
  • Quando se utiliza uma ferramenta de refatoração o custo das mudanças na implementação são reduzidos, consequentemente pode-se fazer um projeto menos aprofundado pois caso se encontre algum erro o custo para correção deste é reduzido quando comparado aos projetos que não utilizam tais ferramentas.Esse conceito foi extraído do livro de refatoração do Martin Fowler. Segue o trecho do livro que trata a respeito:

    As refactoring becomes less expensive, design mistakes become less costly. Because it is less expensive to fix design mistakes, less design needs to be done up front. Upfront design is a predictive activity because the requirements will be incomplete. Because the code is not available, the correct way to design to simplify the code is not obvious. In the past, we had to livewith whatever design we initially created because the cost to change the design was too great. With automatic refactoring tools, we can allow the design to be more fluid because changing it is much less costly. Given this new set of costs, we can design to the level of the current problem knowing that we can inexpensively extend the design to add additional flexibility in the future. Nolonger do we need to attempt to predict every possible way the system might change in the future. If we find that the current design makes the code awkward with the smells described in Chapter 3, we can quickly change the design to make the code clean and maintainable.

  • Gostei da citação que o Renato fez. Muito bom o livro do Fowler...

    O que Fowler quis dizer foi que antigamente, corrigir um erro de programação ou acabar com a ambiguidade ou simplesmente, refinar o software era muito dispendioso. Qualquer mudança no código tinha um efeito no modelo de análise e no projeto. Com o aparecimento das ferramentas, essas mudanças para melhor nos códigos (refabricação - Pressman) pode ser feita sem medo de aumentar os custos nas etapas anteriores.
    Antes, quando o modelo de análise estava pronto, quando o projeto estava pronto, o código estava imutável, praticamente. Qualquer refabricação era custoso demais para ser aplicado. Hoje, a história é diferente. Se for necessário otimizar o código, faça. As ferramentas automatizadas lhe ajudarão a encaixar essas mudanças no modelo de análise e no projeto.

    Lembrando que o modelo de análise é uma abstração do sistema, utilizado para construção do projeto.
  • Complementando: se um analista de análise e projeto sabe que na fase de implementação são usadas ferramentas de refabricação, ele fica mais tranquilo. Não terá que prever o melhor modelo e projeto para ser implementado. Ele poderá desenvolver os modelos e projeto com o que tem no momento. Sabe ainda que quaisquer mudanças nessas etapas serão adaptadas na implementação mais facilmente, pois há o uso das ferramentas automatizadas.
  • Achei o enunciado muito mal escrito.

    Pois há ambiguidade na frase "mudanças futuras no modelo gerado durante essa etapa poderão ser realizadas com um custo menor na etapa de implementação".

    Menor custo em relação a implementação sem refactoring? O que torna a alternativa verdadeira.
    Ou menor custo em relação às outras fases? O que é falso. Pois mudanças na fase de implementação é mais custoso do que na fase de concepção.

ID
28459
Banca
CESGRANRIO
Órgão
DNPM
Ano
2006
Provas
Disciplina
Engenharia de Software
Assuntos

O Modelo Essencial de um Sistema de Informação subdivide- se em dois tipos de modelo, que são:

Alternativas
Comentários
  • A análise essencial é constituída basicamente por duas fases ou modelos: ambiental e comportamental.

    Segundo Yourdon:

    1. MODELO AMBIENTAL
    1.1 Finalidade do Sistema (Declaração de Objetivos)
    1.2 Diagrama de Contexto
    1.3 Lista de Eventos

    2. MODELO COMPORTAMENTAL
    2.1 Modelo Comportamental Preliminar
    2.1.2 Modelagem das atividades essenciais
    (uma bolha por evento)
    2.1.3 Modelo de Dados - primeira versão;
    2.2 Modelo Comportamental Complementar
    2.2.1 Gerar dfd de nível ascendente-macro;
    2.2.2 Subdivisão em níveis descendentes
    (detalhamento)
    2.2.3 Complementar o Modelo de Dados e construir o
    Dicionário de Dados
    3. MODELO DE IMPLEMENTAÇÃO
    3.1 Fronteira manual/automação
    3.2 Formato das entradas e saídas.
    3.3 Escolha de dispositivos.




  • A explicação acima ficou meio confusa, pois a questão trata do "Modelo" Essencial e não da "Análise" Essencial.
    A "Análise Essencial" se divide em dois modelos: o Modelo Essencial e o Modelo Implementação.
    Já o "Modelo Essencial", que é o foco da questão, é subdividido em doi tipos de modelos:
    • Modelo Ambiental: Define a fronteira entre o sistema e o resto do mundo
    • Modelo Comportamental: Define o comportamento das partes internas do sistema necessário para interagir com o ambiente;

    Mais detalhes em http://pt.wikipedia.org/wiki/An%C3%A1lise_essencial

    Abraços.

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

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

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

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

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

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

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

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

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

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

  • XP

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


ID
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
41680
Banca
FCC
Órgão
TRE-PI
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

No diagrama de classes da UML uma superclasse, com uma ou mais subclasses, representa um relacionamento do tipo

Alternativas
Comentários
  • a) Composição - relação entre classes do tipo parte-todo, por exemplo: um carro tem pneus e/ou pneus fazem parte do carro. Nesta relação as partes separadas não têm função utilidade.b) Agregação - relação entre classes do tipo está-contida ou é-uma-parte, por exemplo: um formulário de registro contém um formulário de matrícula e/ou um formulário de matrícula está contido em um formulário de registro. Na agregação existe uma relação de conteúdo, mas as partes existem separadamente.c) Generalização - relação entre classes semelhante a herança de OO, onde uma superclasse define uma hierarquia de subclasses que herdam comportamentos(atributos e métodos), por exemplo: Um elefante é um tipo de animal. Aqui existe uma definição de hieraquia de comportamentos comuns vindo da superclasse(animal) e subclasses(elefante, leão, cavalo)d) Associação - é uma relação de ligação entre classes, significando que elas "conhecem uma a outra", por exemplo: um cliente possui uma conta corrente. As associações podem ser do tipo: normal, recursiva, ternária, agregação, composição.e) Modularização - é uma forma de abordagem de desenvolvimento de software, a modularização tem mais a ver com coesão e acoplamento que com UML. Na modularização o software é desenvolvido por partes(módulos) que funcionam independentes um do outro(baixo acoplamento e alta coesão).
  • LETRA C

    Falou em Super Classe, falou em Generalização, mais conhecido como Herança


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

Estudos baseados na análise de diversos projetos de desenvolvimento de software sugerem que tais projetos têm maior chance de sucesso quando empregam metodologia e gerenciamento alinhados ao paradigma de desenvolvimento de novos produtos, em contraponto ao paradigma de produção industrial. Com base nessas observações, a maioria das metodologias modernas de desenvolvimento de software recomenda:

Alternativas
Comentários
  • Letra D, técnica base do SCRUM.
  • trata-se de desenvolvimento iterativo.
  • a) concluir o trabalho de especificações dos requisitos do sistema, antes de iniciar as atividades de projeto e implementação. --> metodologia antiga - Modelo em cascata.


    b) planejar detalhadamente no início do projeto todas as fases e atividades do mesmo, de forma que seja possível estimar com precisão o esforço necessário e os prazos de cada atividade. --> Dificil de ser implementada

    c) providenciar, desde o início do projeto, mecanismos para prevenir e bloquear solicitações de mudanças de forma a garantir que será entregue exatamente o que foi especificado. --> Não existe essa exigencia de previnir e bloquear mudanças, ocorre justamente o contrário nas metodologia de desenvolvimento modernas.

    e) não produzir documentação técnica para o sistema, tendo em vista que a mesma já nasce condenada a ficar desatualizada, investindo melhor o tempo em atividades de implementação e testes exaustivos . Realmente não há uma ênfase na produção de documentaçaõ, porém é documentado somente o essencial. 



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

Os processos de desenvolvimento de software utilizam, muitas vezes, procedimentos estatísticos para, por exemplo, apoiar a tomada de decisão. Dentro desse contexto, o Diagrama de Pareto é baseado na clássica regra de que

Alternativas
Comentários
  • Link que usei para responder a pergunta: http://www.scribd.com/doc/19750932/Diagrama-de-Pareto
  • A Lei de Pareto (também conhecido como princípio 80-20), afirma que para muitos fenómenos, 80% das consequências advém de 20% das causas. A lei foi sugerida por Joseph M. Juran, que deu o nome em honra ao economista italiano Vilfredo Pareto.

    O Diagrama de Pareto (ou 80-20 ou 70-30) é um gráfico de barras que ordena os problemas, identificando os mais importantes e medindo-os em diversas escalas, permitindo usar a teoria de Pareto (poucos essenciais, muito triviais), ou seja, há muitos problemas sem importância diante de outros mais importantes. Além disso, o Diagrama de Pareto permite agrupar os dados de diferentes formas, medem o impacto de mudanças no processo e quebra causas genéricas em causas específicas.

    No topo da barra mais alta, traça-se uma linha para poder verificar a medida cumulativa das categorias, podendo assim identificar o peso que os problemas têm em relação ao todo.

     

  • a-

    principio de pareto é um modelo que explica ocorrencias de determinados acontcimentos por uma regra de intervalo, cujo padrao é 20% dos motivos causam 80% das consequencias.


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

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

Alternativas
Comentários
  • Características da XP.

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

  •  a)XP.

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

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

     

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


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

Para a especificação de software e verificação de sistemas, uma alternativa que se fundamenta na matemática discreta e na lógica é o modelo incremental.

Alternativas
Comentários
  • Metodos formais são baseados na matemática discreta.
  • Algué sabe porque a questÃo foi anulada??

    Como o colega acima citou, a alternativa descreve metodos formais, ou seja, a resposta é  ERRADO. Não vi nenhum problema no enunciado...

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

Um processo de desenvolvimento de software é um conjunto de atividades, parcialmente ordenadas, com a finalidade de se obter um produto de software. Cada processo tem suas particularidades, entretanto, podem-se destacar atividades que são comuns à maioria dos processos. Com relação a processos de desenvolvimento de software, assinale a opção correta.

Alternativas
Comentários
  • Não poderia ser a letra A ou B?
  • Igor...

    A letra A diz "ou não funcionais, que não estão relacionados às funcionalidades". Na verdade elas estão.
    A letra B é exatamente o inverso.

    []'s
  • a) O levantamento de requisitos tem como objetivo compreender o problema a ser resolvido e identificar necessidades. Os requisitos podem ser funcionais, que definem as funcionalidades do sistema, ou  E não funcionais, que não estão relacionados às funcionalidades.
    Requisitos Funcionais: São aqueles que descrevem o comportamento do sistema, ou seja, descreve o que precisa ser feito pelo sistema.
    Requisitos não funcionais: São aqueles que descrevem como deve ser feito. Em geral se relacionam com padrão de qualidade como confiabilidade, performance e robustez

    b) A análise tem como foco construir uma estratégia de solução. Os modelos construídos nessa fase devem ser verificados e validados. A verificação validação tem como objetivo assegurar que as necessidades do cliente estão sendo atendidas pelo sistema, enquanto a validação verificação tem o objetivo de analisar se os modelos estão em conformidade com os requisitos definidos.

    c) O projeto produz uma descrição computacional do software sem com restrições de tecnologia, ou seja, aspectos físicos e dependentes de implementação não são considerados.

    e) Na fase de implantação, o sistema é testado, empacotado, distribuído e instalado no ambiente do cliente.
    O sistema é testado em todas as fases do projeto.
  • Requisitos não-funcionais são restrições sobre as funções ou serviços oferecidos pelo sistema. Eles estão relacionados aos funcionais.

    Uma questão interessante que vale uma conferida é a Q35197.

  • Igor.
    Muito bom seu comentario. A principio tinha marcado letra A, mas quando cheguei na D fui obrigado a mudar de opiniao pelo fato de que sou programador e seria impossivel nao marcar a letra D. porem marquei a D pensando... a letra A tbm esta certa... dai quando entrei nos comentarios e vi o seu, me chamou atencao para um detalhe que me passou batido e voce esclareceu.  Muito agradecido ok? Coloquei 5 estrelas para vc
    Valew
  • Eu discordo do gabarito, pois considero que a alternativa (e) também está correta.
    Não está presente elementos claros (apenas, somente, etc) que apontam que é incorreta.
  • Bom comentário da Fernanda Rigamont, mas discordo de alguns motivos dos erros das alternativas A, B, C e E. Vamos lá!

    •  a) O levantamento de requisitos tem como objetivo compreender o problema a ser resolvido e identificar necessidades. Os requisitos podem ser funcionais, que definem as funcionalidades do sistema, ou não funcionais, que não estão relacionados às funcionalidades. ERRADA: Na verdade, o erro ocorre no momento que é afirmado que os requisitos não funcionais não estão relacionados com as funcionalidades. É claro que estão, já que requisitos não funcionais dizem respeito a segurança, desempenho, usabilidade, etc... todas restrições estão diretamente relacionadas às funcionalidades!
    •  b) A análise tem como foco construir uma estratégia de solução. Os modelos construídos nessa fase devem ser verificados e validados. A verificação tem como objetivo assegurar que as necessidades do cliente estão sendo atendidas pelo sistema, enquanto a validação tem o objetivo de analisar se os modelos estão em conformidade com os requisitos definidos.  ERRADA: os conceitos estão trocados, onde está verificação deve ser trocado por validação, e vice-versa.
    •  c) O projeto produz uma descrição computacional do software sem restrições de tecnologia, ou seja, aspectos físicos e dependentes de implementação não são considerados. ERRADA: Não são todos os modelos de projeto que utilizam restrição de tecnologia e aspectos físicos, mas o que dizer do nosso glorioso diagrama de IMPLANTAÇÃO, que enfoca na questão da organização física da arquitetura sobre o qual o software irá ser implantado e executado? Nesse diagrama temos elementos como protocolos (TCP/IP, HTTP, máquinas físicas, etc). Ou seja, o erro está ao generalizar que o projeto de software não apresenta restrições de tecnologia.
    •  d) Na fase de implementação, o sistema é codificado, ou seja, a descrição computacional obtida na fase de projeto é traduzida para código executável, por meio do uso de uma ou mais linguagens de programação. CORRETA!
    •  e) Na fase de implantação, o sistema é testado, empacotado, distribuído e instalado no ambiente do cliente. ERRADA: Essa alternativa é mais controversa, pois mesmo que a aplicação já tenha sido testada na fase de construção, certamente, haverão alguns testes no ambiente do cliente. Mas, no geral, os testes devem ser realizados na fase de Construção e não na fase de implantação. Daí o erro da alternativa!
    • Espero ter ajudado na compreensão!

  • Requisitos não funcionais

    São aqueles que não dizem respeito DIRETAMENTE às funções específicas fornecidas pelo sistema

     

  • Numa prova de C/E eu marcaria a E) como certa também, mas a alternativa D) é mais "certa".


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
153094
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 de desenvolvimento por prototipação é caracterizado pela ausência de métricas de controle, dada a natureza experimental do desenvolvimento e do produto obtido.

Alternativas
Comentários
  • Segundo Pressman, o modelo de Prototipagem é muito utilizado quando nem todos os requisitos são definidos de maneira clara pelo cliente. A característica principal desse modelo é gerar protótipos do sistema com definições de requisitos dadas pelo cliente e que então é testado pelo cliente para validar as suas funcionalidades.

  • O modelo de desenvolvimento por prototipação é caracterizado pela ausência de métricas de controle, dada a natureza experimental do desenvolvimento e do produto obtido.

    Errado, a prototipação tem como principal caracterísitca facilitar a coleta de requisitos, o que facilita a obtenção de métricas de controle

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
153103
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 desenvolvimento com base em componentes é uma abordagem típica da programação estruturada e tem foco na produção de bibliotecas de software reutilizáveis.

Alternativas
Comentários
  • Não é típica da programação estruturada.
  • ERRADO, pois um desenvolvimento de componentes reutilizáveis é típico de uma abordagem orientada a objetos.
  • Outro ponto é que o desenvolvimento baseado em componentes tem foco na utilização de componentes já PRONTOS e não na produção de componentes.

  • Programação OO e não estruturada.
  • O problema esta na palavra "Componente" ou "Reutilizável" ?

    Eu pensei que o problema estava apenas na palavra "Componente", mas os comentários dos colegas levantaram essa dúvida.

  • 2 erros: 

    1) "programação estruturada". É programação orientada a objetos.

    2) "foco na produção de bibliotecas de software reutilizáveis". Foco na produção rápida de software.

    A questão fala de RAD (Rapid Application Development)

    É um modelo que enfatiza um ciclo de desenvolvimento curto; * Construção baseada em componentes; * O modelo RAD é usado principalmente para aplicações de sistema de informação; * Adaptação do modelo em cascata, onde um desenvolvimento rápido é obtido através de uma abordagem de construção baseada em componentes. 

    fonte: http://www.adonai.eti.br/wordpress/2014/01/modelos-de-ciclo-de-vida-de-software/


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

Segundo Yourdon, o ciclo de vida de um projeto de sistema é o modo como o projeto é desenvolvido na empresa e uma maneira simples para que qualquer pessoa da área de desenvolvimento de sistemas possa se entrosar com o projeto a ser desenvolvido.

O ciclo de vida de um projeto de sistema é importante pelas razões apresentadas nas alternativas a seguir, à exceção de uma.

Assinale-a.

Alternativas
Comentários
  • O erro da E está em:

    Contemplam as ações sequenciais de um projeto de desenvolvimento, do diagnóstico do problema aos testes necessários à sua implementação.
  • Discordo do comentário,
    Ao citar Yourdon a questão se insere em um contexto estruturado, incluindo neste o modelo de ciclo de vida clássico.
    O que a meu ver coloca a questão incorreta é dizer que as ações sequênciais vão do diagnóstico do problema à implementação.
    É sabido que há atividades anteriores ao diagnóstico do problema (projeto) e postetiores a implementação (codificação/construção).
  • Questão baseada em CTRL+C de partes diferentes do livro... MALDITOS!


    Mas o que interessa é isto:
    Segundo Yourdon (1990), Ter um ciclo de vida de projeto de sistema é importante pelas seguintes razões:
    1.  Definição das atividades a serem executadas em um projeto.
    2.  Consistência entre muitos projetos de desenvolvimento da mesma organização.
    3.  Introdução de pontos de verificação para o controle gerencial de decisões.
    4.  Facilidades no gerenciamento de prazos.
    Ainda segundo Yourdon, as fases pertencentes ao Ciclo de Vida Clássico [cada organização tem as suas fases], contemplam um conjunto seqüencial de ações de desenvolvimento, desde o diagnóstico do problema até os testes necessários à implementação.


    fonte: http://www.abepro.org.br/biblioteca/ENEGEP2001_TR93_0290.pdf

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

Em cada fase de um processo de software são executadas as atividades básicas para que sejam atingidos os objetivos propostos.
Essas atividades podem ser identificadas nas alternativas a seguir, à exceção de uma. Assinale-a.

Alternativas
Comentários
  • Atividades:
    1. Especificação
      • Engenharia de Sistema: estabelecimento de uma solução geral para o problema, envolvendo questões extra-software.
      • Análise de Requisitos: levantamento das necessidades do software a ser implementado. A Análise tem como objetivo produzir uma especificação de requisitos, que convencionalmente é um documento.
      • Especificação de Sistema: descrição funcional do sistema. Pode incluir um plano de testes para verificar adequação.
    2. Projeto
      • Projeto Arquitetural: onde é desenvolvido um modelo conceitual para o sistema, composto de módulos mais ou menos independentes.
      • Projeto de Interface: onde cada módulo tem sua interface de comunicação estudada e definida.
      • Projeto Detalhado: onde os módulos em si são definidos, e possivelmente traduzidos para pseudo-código.
    3. Implementação
      1. Codificação: a implementação em si do sistema em uma linguagem de computador.
    4. Validação
      • Teste de Unidade e Módulo: a realização de testes para verificar a presença de erros e comportamento adequado a nível das funções e módulos básicos do sistema.
      • Integração: a reunião dos diferentes módulos em um produto de software homogêneo, e a verificação da interação entre estes quando operando em conjunto.
    5. Manutenção e Evolução
      • Nesta fase, o software em geral entra em um ciclo iterativo que abrange todas as fases anteriores.
  • Não sei de onde tiraram os conceitos acima, mas os abaixo são:
    Segundo Pressman 7a. ED (Pág: 40):

    “Processo é um conjunto de atividades, ações e tarefas realizadas na criação de algum produto de trabalho (work product).”

    Ele conceitua atividades, ações e tarefas, e logo abaixo diz:

    “Uma metodologia de processo genérica para engenharia de software compreende 5 atividades:

    Comunicação;

    Planejamento;

    Modelagem;

    Construção;

    Emprego.

    (...) comunicação, planejamento, modelagem, construção e emprego são aplicados repetidamente quantas forem as iterações do projeto, sendo que cada iteração produzirá um incremento de software. Este disponibilizará uma parte dos recursos e funcionalidade do software. A cada incremento, o software torna-se mais e mais completo.”

    E depois o autor descreve diversas atividades de apoio. Vale a pena dar uma conferida (Pág 41).

    Bons estudos!

  • Questão caberia recurso. 
    Se levar em conta varios autores, Todas essas atividades listas existem. 
    Assim fazendo com que a questão não possui resposta! 
  • Respondendo aos comentários acima. A questão foi retirada do livro do Sommerville. E são as descritas no primeiro comentário, do Mauro (não irei repetir o post).

  • Existem vários processos de desenvolvimento de software, porém algumas atividades fundamentais são comuns a todos eles (SOMMERVILE, 2007):

    ·  Especificação: define a funcionalidade do software e as restrições sobre sua operação.

    · Projeto e implementação: o software que atenda a especificação deve ser produzido.

    · Validação de software: o software deve ser validado para garantir que ela faça o que o cliente deseja.

    · Evolução: o software deve evoluir para atender aos novos requisitos que naturalmente surgirão.


    Analisando cheguei a conclusão que trata-se de um clico PDCA! E todos os outros 437 milhões de processos de engenharia de software acabam  sendo divididos mais ou menos dessa maneira.

    Ex: RUP: 1.Concepção + 2.Elaboração (equivale a  especificação, que equivale a PLAN) 3.Construção (equivale a "Projeto e implementação", que equivale a DO)4.Transição (Validação de software (CHECK) + Evolucao (ACT)

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

O gerenciamento de grande quantidade de informação na construção de sistemas pode ser contornada usando-se a técnica de refinamentos sucessivos, utilizada no modelo de Ciclo de Vida Iterativo e Incremental. A construção de sistemas, com base nesse modelo de ciclo de vida,

Alternativas
Comentários
  • O modelo de ciclo de vida incremental e interativo foi proposto como uma resposta aos problemas encontrados no modelo em cascata. O processo de desenvolvimento divide o desenvolvimento de um produto de software em ciclo. Em cada ciclo de desenvolvimento, podem ser identificadas as fases de: análise, projeto, implementação e testes.

    Cada um dos ciclo considera um subconjunto de requisitos. Os requisitos são desenvolvidos uma vez que sejam alocados a um ciclo de desenvolvimento. No próximo ciclo, um outro subconjunto dos requisitos é considerado para ser desenvolvido, o que produz um novo incremento do sistema que contém extensões e refinamentos sobre o incremento anterior.

    Assim, o desenvolvimento evolui em versões, através da construção incremental e iterativa de novas funcionalidades até que o sistema completo esteja construído. Note que apenas uma parte dos requisitos é considerada em cada ciclo de desenvolvimento. Na verdade, um modelo de ciclo de vida iterativo e incremental pode ser visto como uma generalização da abordagem em cascata: o software é desenvolvimento em incrementos e cada incremento é desenvolvido em cascata.

    A abordagem incremental e iterativa somente é possível se existir um mecanismo para dividir os requisitos do sistema em partes, para que cada parte seja alocada a um ciclo de desenvolvimento. Essa alocação é realizada em função do grau de importância atribuído a cada requisito.
  • Tem um problema com essa questão: a letra "b" também está correta.  As iterações acontecem em sequencia sem se sobrepor, mas os incrementos, não.  http://www.questoesdeconcursos.com.br/questoes/c0780dae-6f
  • realmente de acordo com o nosso amigo Gustavo , os incrementos podem ser desenvolvidos de forma paralela, acho que na época faltou um embasamento mais forte ou birra mesmo da banca em não aceita recurso.

    []'s
  • 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 figurahttp://screencast.com/t/OTg0YTc5Yjct

    P
    ortanto b) errada

    c) correta
  • C) contém atividades que podem exigir trabalho, em maior ou menor grau, em todos os incrementos planejados.

    Se vamos ser puritanos e diferenciar simultâneo de paralelo, então a letra c também não está certa, vejamos:

    dizer que contém atividades que "PODEM" gerar trabalho é um erro. Pois , em maior ou menor grau, todas exigirão trabalho.

     


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

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

O desenvolvimento adaptativo de software (DAS) é uma técnica para construção de sistemas e software complexos que foca na colaboração e na auto-organização da equipe.

Alternativas
Comentários
  • DAS - Desenvolvimento Adaptativo de software - é uma técnica paraa construção de sistemas e software complexos. O apoio filosofico do DAS concentra-se na colaboração humana e na auto-organização da equipe

  • Desenvolvimento adaptativo de software (adaptive software development -- ASD): Prioriza a velocidade e a flexibilidade. Funciona melhor em cenários onde a organização precisa produzir  resultados com rapidez para um aplicativo que pode crescer à medida que os clientes o utilizam. Foi desenvolvido por Jim Highsmith. 

    fonte: http://cio.uol.com.br/tecnologia/2007/11/19/idgnoticia.2007-11-19.18...

  • Livro Pressman


    Página 66, capítulo 4, “Desenvolvimento Ágil”.


    O DAS (Desenvolvimento Adaptativo de Software) foi proposto por Jim Highsmith como uma técnica para construção de sistemas e software complexos. O apoio filosófico do DAS concentra-se na colaboração humana e na auto-organização da equipe.


    Fonte: https://alessandramclima.wordpress.com/2010/09/22/tcu-2010-engsw-parte-2/


ID
197500
Banca
CESPE / CEBRASPE
Órgão
DETRAN-DF
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Acerca do desenvolvimento de aplicações e da arquitetura OLAP,
julgue os itens a seguir.

O modelo de processo de desenvolvimento de software evolucionário parte do desenvolvimento de uma implementação inicial cujos resultados são apresentados aos clientes e refinados por meio de várias versões até que se alcance o sistema adequado. A prototipação, como processo, tem por objetivo compreender as especificações do software para se chegar aos requisitos para o sistema.

Alternativas
Comentários
  • A prototipação evolutiva é utilizada em protótipos que evoluirão até tornarem-se sistemas finais. Neste método, rapidamente é desenvolvido um protótipo que será modificado até que se obtenha o sistema final. Para que sejam feitas as modificações e o protótipo transforme-se em software, começa-se a construção deste protótipo com os requisitos fundamentais e que estejam bem definidos e é necessário o acompanhamento do usuário, para que juntamente com ele o desenvolvedor possa definir os requisitos do sistema.

    Na questão quando se afirma que a prototipação tem por objetivo compreender as especificações do software, a mim parece que o software estaria  pronto, não sendo isto a representação da prototipação, de onde parte-se dos requisitos mínimos fundamentais e destes aplia-se o conhecimento.

  • http://screencast.com/t/MjAzODRjZj

    Pressman 6ed.

    Independente de como a prototipagem é usada, ela auxilia a entender requisitos confusos, e não a especificação de software.

  • O erro está na última frase:

    "A prototipação, como processo, tem por objetivo compreender as especificações do software para se chegar aos requisitos para o sistema."

    e ficaria correta se trocássemos especificações do software por requisitos para o sistema. Ficaríamos então com a seguinte oração:

    "A prototipação, como processo, tem por objetivo compreender os requisitos do sistema para se chegar às especificações do software."

     

  • A prototipação tem como função o levantamento de requisitos. A especificação seria algo muito além daquilo que lhe compete.
  • Na Prototipação Evolucionária os protótipos são desenvolvidos a partir dos requisitos mais bem compreendidos.

  • A prototipação é utilzada para entendimento dos requisitos, quando estes não são bem compreendidos pela equipe de desenvolvimento.

  • Como é possível ter a especificação de um software sem se ter os requisitos do sistema antes?

     

     


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

Com relação à engenharia de software, julgue os itens a seguir.

Um modelo de processo de software consiste em uma representação complexa de um processo de software, apresentada a partir de uma perspectiva genérica.

Alternativas
Comentários
  •  Modelo de Processo de Software: é uma representação simplificada de um processo de software, apresentada a partir de uma perspectiva específica.

  • Um modelo de processo de desenvolvimento de software, ou simplesmente modelo de processo, pode ser visto como uma representação, ou abstração dos objetos e atividades envolvidas no processo de software. Além disso, oferece uma forma mais abrangente e fácil de representar o gerenciamento de processo de software e consequentemente o progresso do projeto.

    Segue alguns exemplos:

    * Modelos ciclo de vida
    * Sequencial ou Cascata (do inglês waterfall) - com fases distintas de especificação, projeto e desenvolvimento.
    * Desenvolvimento iterativo e incremental - desenvolvimento é iniciado com um subconjunto simples de Requisitos de Software e interativamente alcança evoluções subseqüentes das versões até o sistema todo estar implementado
    * Evolucional ou Prototipação - especificação, projeto e desenvolvimento de protótipos.
    * V-Model - Parecido com o modelo cascata, mas com uma organização melhor, que permite que se compare com outros modelos mais modernos.
    * Espiral - evolução através de vários ciclos completos de especificação, projeto e desenvolvimento.
    * Componentizado - reuso através de montagem de componentes já existentes.
    * Formal - implementação a partir de modelo matemático formal.
    * Ágil
    * RAD
    * Quarta geração

    http://pt.wikipedia.org/wiki/Engenharia_de_software#Modelos_de_Processo_de_Software

  • "É uma descrição simplificada de um modelo de software, que é apresentada a partir de uma pesrpectiva específica. Os modelos, pela sua natureza, são simplificações; e, assim, um modelo de processo de software é uma abstração do processo real que está sendo descrito. Dentre outros os modelos de procescossso destacam-se atividades que são parte o processo de software, produtos de software e o papel das pessoas envolvidas na engenharia de software." - Engenharia de Software, Ian Sommerville, 8a edição.

  • Modelos de Processo de Software - Quando se trabalha na elaboração de um produto ou sistema, é importante seguir uma série de passos previsívies - um roteiro que ajude a criar um resultado de alta qualidade e dentro do prazo estabelecido. O roteiro é denominado processo de software.

    Em outra parte do livro ele diz que deve ser um processo que  deve ser visto como algo prático e intelig´´ivel por todos os membros da equipe.

    Engenharria dee Software  - Uma abordaggem profissional - Roger S.Pressman

  • Gabarito: ERRADO

    Um modelo de processo é uma representação abstrata de um esqueleto de processo, incluindo tipicamente algumas atividades principais, a ordem de precedência entre elas e, opcionalmente, artefatos requeridos e produzidos. Em geral, um modelo de processo descreve uma filosofia de organização de atividades, estruturando-as em fases e definindo como essas fases estão relacionadas. Logo, um modelo de processo de software ou modelo de ciclo de vida trata da representação abstrata/simplificada de um processo de software, apresentada a partir de uma perspectiva genérica.


ID
235933
Banca
FGV
Órgão
FIOCRUZ
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Dentre as alternativas a seguir assinale aquela que não está incluída na definição do escopo de um projeto de software.

Alternativas
Comentários
  • Essa questão deveria ser anulada. Pois a Identificação dos envolvidos no projeto faz parte do Gerenciamento de Comunicações.

    Fonte: GUIA OFICIAL DO PMBOK (Pág 209)

     

    10.1.3 Identificar as partes interessadas: saídas
    1 Registro das partes interessadas

    A principal saída deste processo de identificação é o registro das partes interessadas, que contém todos os detalhes relativos às partes identificadas, incluindo, entre outros:

    • Informações de identificação: nome, posição na organização, local, papel no projeto,
    informações de contato;
    • Informações de avaliação: requisitos essenciais, principais expectativas, influência
    potencial no projeto, fase de maior interesse no ciclo de vida e
    • Classificação das partes interessadas: interna/externa, apoiadora/neutra/resistente,
    etc.

    Como a questão também apresenta outra resposta correta (E), essa questão deveria ser anulada pela banca organizadora.

  • (    Comentado por Paulo Cortez há 3 meses. Essa questão deveria ser anulada. Pois a Identificação dos envolvidos no projeto faz parte do                                                                  Gerenciamento de Comunicações.)????
    Não entedi o comentario o comando da questão eh Dentre as alternativas a seguir assinale aquela que não está incluída na definição do escopo de um projeto de software. Então a Identificação dos envolvidos no projeto faz parte sim qual o pro???

     
  • De fato, o único elemento circunstancial entre as alternativas é o nome do SOFTWARE. Quem tem nome no escopo é o PROJETO para poder ser identificado. Contudo, o nome do SOFTWARE em si, não precisa ser definido até o momento da entrega.


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

A respeito de modelo de processo, que pode ser usado para indicar
quais atividades ocorrem, quando e por quem elas são realizadas,
julgue os itens a seguir.

São elementos de um processo de desenvolvimento de software: atividade, sequência, modelo de processo, recursos, controles, políticas e organização.

Alternativas
Comentários
  • Alguém poderia me dizer qual a fonte (bibliografia) desta questão?
  • eu também fico me perguntando também de onde algumas questões são extraídas...

  • Fiz a mesma pergunta!

    Ferramentas e técnicas para a modelagem do processo 
    Modelo estático: Notação de Lai (1991)

    Trata-se da "Notação de Lai" trata-se de uma ferramenta para descrever processos que conta com os seguinte elementos:
    Atividade: o que deverá ser realizado ao longo do processo
    Sequência: ordem das atividades
    modelo de processo: visão de interesse sobre o sistema
    recursos: necessários a realização das atividades, pode ser ferramenta ou pessoa
    controle: influência externa sobre a aprovação do processo, podem ser manuais/automáticos, humanos ou mecânicos.
    Política: princípios de orientação
    Organização: estrutura hierárquica dos agentes do processo

    fonte: 
    1) https://github.com/willystadnick/education/blob/master/Facvest/6%C2%AA%20Fase/Engenharia%20de%20Software/Modelagem%20do%20Processo%20e%20Ciclo%20de%20Vida.txt - Linha 152
    2) http://slideplayer.com.br/slide/295975/

  • São elementos de um processo de desenvolvimento de software: atividade, sequência, modelo de processo, recursos, controles, políticas e organização.

    Basta olharmos para os processos de desenvolvimento de software. Vamos usar o cascata e o XP, por exemplo. Eles possuem atividades bem definidas. Sequência dessas atividades (ainda que o XP não seja bem definida uma após a outra, mas não deixa de existir as atividades). Modelo de processo é um modelo adotado (no caso do cascata é um modelo mais rígido e sequencial enquanto que no XP é um modelo mais flexível e tem outros focos). Recursos são as ferramentas usadas pela metodologia no processo. Controles são as formas de se controlar os marcos. Políticas e organizações impactam e muito (dependendo da organização é possível adotar uma ou outra forma do processo como quantidade de desenvolvedores envolvidos, etc).

  • O processo de desenvolvimento de software é algo tão subjetivo que não merece uma definição específica.


ID
314641
Banca
FCC
Órgão
TRT - 1ª REGIÃO (RJ)
Ano
2011
Provas
Disciplina
Engenharia de Software
Assuntos

É embasado na idéia de desenvolvimento de uma implementação inicial, expondo o resultado aos comentários do usuário e refinando esse resultado por meio de diversas versões, até que seja desenvolvido um sistema adequado. No âmbito do processo de software, trata-se de

Alternativas
Comentários
  • Segundo Sommerville (Engenharia de Software 6 ed), o desenvolvimento evolucionário tem como base a idéia de desenvolver uma implementação inicial, expor o resultado ao comentário do usuário e fazer seu aprimoramento por meio de muitas versões, até que um sistema adequado tenha sido desenvolvido.
  • Alguem me corrija mas no pressman 7. edicao pg 65 diz:

    modelo espiral. o modelo espiral é um modelo de processo de software evolucionário que acopla a natureza da prototipação com aspectos sistemáticos e controlados do modelo cascata.

    a resposta D é mais específica que a A.
  • Procede seu comentário. Fiquei em dúvida na (A) e (D).

    A única coisa que vejo é que todo desenvolvimento em espiral é desenvolvimento evolucionário; no entanto, o inverso não é verdade. Prototipagem e o Modelo de Desenvolvimento Concorrente tbm são abordagens evolucionários.

    Como, infelizmente, o objetivo é dançar conforme a música que a banca (FCC) toca, precisamos escolher uma delas!
  • "O desenvolvimento incremental é baseado na ideia de desenvolver uma implementação inicial, expô-la aos comentários dos usuários e continuar por meio da criação de várias versões até que um sistema adequado seja desenvolvido."

    Livro Engenharia de Software ed. 9, Sommerville, pg. 21.

    A resposta correta não está entre as opções listadas.
  • Pessoal, vamos nos lembrar que o desenvolvimento espiral faz parte do modelo evolucionário de desenvolvimento de software, e que ele não libera versões como diz a questão. Ele evolui o desenvolvimento em etapas definidas até a entrega.
  • Rodrigo,
    Segundo a página 65 da 7a edição do Pressman, o desenvolvimento em espiral libera, sim, versões. Confira.
  • Pessoal, o modelo espiral é iterativo (divide o processo de denvolvimento em iterações) e incremental, mas vejam que os incrementos gerados nesse modelo obedecem duas regras: 

    1) eles não, obrigatoriamente, incrementos operacionais do software. Podem ser partes da modelagem ou do projeto, por exemplo.

    2) os incrementos gerados não são entregues para os clientes; (ver texto explicativos abaixo)

    "É importante ressaltar que as diversas voltas na espiral são utilizadas para se construir as partes do produto, mas essas partes intermediárias e ainda incompletas do produto não são entregues ao cliente. Essa abordagem é utilizada apenas para a redução dos riscos e para o enfoque maior naquilo que é mais importante/complexo/crítico no sistema. O modelo de ciclo de vida chamado incremental, apesar de ser baseado no modelo espiral, apresenta uma leve e sutil diferença: a entrega das partes para o cliente. (e essas partes DEVEM ser operacionais - software funcionando)".

    Assim, já não poderia ser a alternativa D, já que a questão deixa claro que os usuários avaliam as entregas parciais. Mas, como em momento algum a questão restringe que o entrega deve ser de um incremento operacional, o modelo de desenvolvimento evolucionário não está descartado, já que está faz entregas parciais aos usuários/clientes. Seria a alternativa A a correta, então.

    O ponto estranho é que tanto Pressman como Sommerville colocam o desenvolvimento espiral como um modelo evolucionário. Porém, a compreensão deve ser que o modelo espiral é iterativo e gera incrementos nao entregáveis, o que não faz dele um modelo fora do conceito de evolucionário. Esse é o ponto estranho!

    Espero não ter confundido mais que ajudado! kkk

  • Modelo evolucionário > Modelo espiral


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

Acerca dos conceitos básicos e modos de utilização da informática, julgue os itens a seguir

No modelo de desenvolvimento de software iterativo, as atividades do processo são realizadas de maneira sequencial, iniciando-se uma após o término da outra, e com muitas interações entre as partes do sistema que já existem.

Alternativas
Comentários
  • No modelo de desenvolvimento de software iterativo, as atividades do processo são realizadas de maneira sequencial, iniciando-se uma após o término da outra...

    Modelo cascata e não interativo, questão errada.
  • Galera, acho que o erro está somente porque a questão não se refere as repetições do modelo Iterativo. --> "..., as atividades do processo são realizas de maneira sequencial e com uma ou mais repetições, ..." . Olhem essa figura:

  • Dentre os modelos de desenvolvimento/processo de software iterativos, temos o modelo incremental (iterativo, senão viraria Cascata), RAD (pode ser iterativo), Prototipagem, Espiral, Concorrente e Baseado em Componentes.

    O modelo de processo Concorrente, as atividades não são realizadas de maneira sequencial. As atividades são vistas como um rede de atividades, onde um evento em uma atividade dispara um estado em outra atividade. Essas atividades interagem.

    Afirmativa errada.
  • Gabarito E. Segundo Pressman: "um fluxo de processo iterativo repete uma ou mais das atividades antes de prosseguir para a seguinte", logo não é sequencial (linear). 

    (Fonte: Livro Engenharia de Software, Pressman, 7ed, pag 54)
  • Na minha opiniao o erro está em "iniciando-se uma após o termino da outra". No RUP, por exemplo, que é uma abordagem iterativa, as atividades de desenvolvimento realmente seguem uma sequencia bem definida, em cada iteração, mas não é necessário o término de uma para iniciar outra atividade. 
  • No modelo de desenvolvimento de software iterativo, as atividades do processo são realizadas de maneira sequencial, iniciando-se uma após o término da outra, e com muitas interações entre as partes do sistema que já existem. errado

    Bendito serás!!


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

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

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

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

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

  • Carla,

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

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

  • c-

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

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


ID
331534
Banca
FGV
Órgão
FIOCRUZ
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Rapid Application Development (RAD) é um modelo de processo de software incremental que enfatiza um ciclo de desenvolvimento curto, com o uso de uma abordagem de construção baseada em componentes. Nesse modelo, três das principais fases são abrangidas pelas modelagens:

Alternativas
Comentários
    • Modelagem de Negócio

    O fluxo de informações entre as funções de negócio é modelado de modo a responder às seguintes questões: - Que informação direciona o processo de negócio? - Que informação é gerada? - Quem a gera? - Para onde vai à informação? - Quem a processa? Na modelagem de negócio são levantados os processos suportados pelo sistema.

    • Modelagem dos dados

    A modelagem de dados responde a um conjunto de questões específicas que são relevantes a qualquer aplicação. O fluxo de informação definido na fase de modelagem de negócio refinado e de forma a extrair os principais objetos de dados a serem processados pelo sistema, qual a composição de cada um dos objetos de dados, onde costumam ficar, qual a relação entre eles e quais as relações entre os objetos e os processos que os transformam.

    • Modelagem do Processo

    Os objetos de dados definidos na modelagem de dados são transformados para conseguir o fluxo necessário para implementar uma função do negócio. Descrições do processamento são criadas para adicionar, modificar, descartar ou recuperar um objeto de dados.

  • Complementando com todas as fases:

    Modelagem de negócio
    Modelagem de dados
    modelagem de processo
    Geração da aplicação
    Teste e modificação
  • No Modelo RAD a modelagem abrange três das principais fases - modelagem de negócio, modelagem de dados e modelagem de processos - e estabelecem representações de projeto que servem com base para a atividade de construção do RAD.

    Resposta: "E"

    Fonte: Livro Engenharia de Software -  Roger S. Pressman - Sexta Edição

     

  • No Modelo RAD a modelagem abrange três das principais fases
    • Modelagem do negócio:O fluxo de informação entre as funções do negócio é modelado
    • Modelagem dos dados: O fluxo de informação e refinado num conjunto de objetos de dados.
    • Modelagem do processo: Os objetos de dados são transformados para conseguir o fluxo de informação necessário para implementar uma função do negócio. Descrições do processamento são criadas.
    • Geração da Aplicação:O RAD considera o uso de técnicas de quarta geração. O processo RAD trabalha para reusar componentes de programas existentes ou criar componentes reusáveis.
    • Teste e entrega:Os componentes novos devem ser testados e todas as interfaces devem ser exaustivamente exercitadas.
  • e-

    Ciclo RAD:

     

    Comunicação

     

    Planejamento

     

    Modelagem - de negócio, de dados e processo

     

    Construção - reuso de componentes, geracao automatica de codigo, testes

     

    Deploy

     

    (Modelagem & construcao em paralelo por n equipes entre 60 e 90 dias)

     

    vantagem do RAD - diminuição de custos com alterações; requisitos incompletos completados durante o desenvolvimento, melhorando sua manutenção. 

     

    Este modelo não é adequado para qualquer tipo de software ou necessidade de aplicação. Recomenda-se desenvolvimento que privilegie modelos ágeis, como componentes ou classes preexistentes, como APIs 


ID
331543
Banca
FGV
Órgão
FIOCRUZ
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Na modelagem de processos, um modelo evolucionário de processo de software, originalmente proposto por Boehm, combina prototipagem e aspectos controlados e sistemáticos dos processos em cascata, sendo um gerador de modelo por risco, usado para guiar a engenharia de sistemas intensivos em softwares com vários interessados concorrentes, tendo duas características distintas, descritas a seguir.

I. É uma abordagem cíclica, para aumentar incrementalmente o grau de definição e de implementação de um sistema enquanto diminui seu grau de risco.
II. É um conjunto de marcos de ancoragem, para garantir o comprometimento dos interessados com soluções exeqüíveis e mutuamente satisfatórias para o sistema.

Esse modelo é conhecido por:

Alternativas
Comentários
  • O modelo proposto por Boehm em 1988 trata de uma abordagem
    cíclica das fases do processo, onde a cada “volta” ou
    iteração temos versões evolucionárias do sistema.
    Este é um modelo guiado por risco, suporta sistemas complexos
    e/ou de grande porte, onde falhas não são toleráveis. Para
    isso, a cada iteração há uma atividade dedicada à análise de
    riscos e apoiada através de geração de protótipos, não necessariamente
    operacionais (desenhos de tela, por exemplo) para
    que haja um envolvimento constante do cliente nas decisões.
  • Modelo em espiral é um processo de desenvolvimento de software que combina elementos de projeto prototipação-em-etapas, em um esforço para combinar as vantagens dos conceitos de top-down e bottom-up, acrescentando um novo elemento, a análise de riscos que falta a esses paradigmas.
  • Onde são descritos modelos dinâmico, globalizado, integrado e empírico.

    Marquei letra A pq foi o único modelo, dentre os descritos, que já ouvi falar.

  • Palavras-chave que definem Espiral
    Barry Boehm, 1988, melhores características modelos cascata e  prototipação, riscos, sentido horário do centro para fora, inclusão requisitos forma evolutiva, sobreposição evolutiva.

  • Falou em risco e prototipagem + Boehm atenção que é Espiral na certa!


ID
331573
Banca
FGV
Órgão
FIOCRUZ
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Os modelos de processo de Engenharia Web (WebE) adotam a filosofia do desenvolvimento ágil, que enfatiza uma abordagem de desenvolvimento simples que incorpora ciclos rápidos. Em conseqüência, o modelo de processo WebE está fixado em três pontos fundamentais, são eles:

Alternativas
Comentários
  • Pressman Maldito!

    Modelo de processo WebE (ou WebApp), segundo Pressman, 2006, está fixado em três pontos:
    • Entrega incremental
    • Alterações frequêntes
    • Tempo curto de desenvolvimento.



    fonte: http://pt.scribd.com/doc/44945336/Default-Title
  • Pág. 383 Pressman 6a edição:

    Antes de definirmos um arcabouç o de process o para WebE devemos reconhece r que:
    1. WebApps com freqüência são entregues incrementalmente. Isto é, as atividades de arcabou -ço vão ocorrer repetidamente à medida que cada increment o é submetid o à engenhari a e entregue.
    2. Modificações ocorrerão freqüentemente. Essa s modificações pode m ocorre r com o resultado da avaliação de um increment o entregue ou com o conseqüênci a de condiçõe s de negóci o mutáveis.
    3. Cronogramas são curtos. Iss o alivia a criaçã o e revisão de volumos a documentaçã o de enge -nharia, ma s nã o despreza a simples realidade de que análise, projeto e teste crítico devem se r registrados de algum modo . 

ID
331576
Banca
FGV
Órgão
FIOCRUZ
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Um modelo de processo de software é uma descrição simplificada desse processo que apresenta uma visão dele. Esses modelos incluem as atividades, que fazem parte do processo, os produtos de software e os papéis das pessoas envolvidas na engenharia do software. Nesse contexto, dois modelos são descritos a seguir.

I. Mostra a seqüência de atividades ao longo do processo, com suas entradas, saídas e dependências entre elas. Neste caso, as atividades representam ações humanas.
II. Mostra o processo como um conjunto de atividades, no qual cada uma realiza alguma transformação de dados, como uma especificação é transformada de entrada em saída. Neste caso, as atividades podem representar transformações realizadas por pessoas ou computadores.

Esses modelos I e II são denominados, respectivamente, de:

Alternativas
Comentários
  • Fluxo de Trabalho (em inglês: Workflow) é a seqüência de passos necessários para que se possa atingir a automação de processos de negócio, de acordo com um conjunto de regras definidas, envolvendo a noção de processos, permitindo que estes possam ser transmitidos de uma pessoa para outra de acordo com algumas regras.
    http://pt.wikipedia.org/wiki/Fluxo_de_trabalho

    Fluxo de dados é um duto de informações que transita entre os componentes do DFD. Características:Identifica dados, documentos a partir de uma origem (Processo, Depósito, Sistema ou Entidade) para um Destino (Processo, Depósito, Sistema ou Entidade). Dados que entram e saem dos processos. É o meio de comunicação entre Entidades Externas, Processos e Depósito de Dados. Dados em movimentação. Analogia com um cano d’água: A água se movimento dentro do cano da sua origem para seu destino. Todo Fluxo de Dados deve possuir um nome. Os dados que compõem um fluxo de dados devem pertencer ao domínio do modelo de dados do sistema em foco. Os dados são atributos das entidades que compõem o modelo de dados do sistema em foco.
    http://pt.wikipedia.org/wiki/Fluxo_de_dados
  • Sommerville, 8a edição, págs. 6 e 7

    1. Um modelo de workflow: mostra a seqüência de atividades ao longo do processo, com suas entradas, saídas e depen-dências entre elas. As atividades neste modelo representam ações humanas.
    2. Um modelo de fluxo de dados ou modelo de atividade: representa o processo com o um conjunto de atividades, no qual cada atividade realiza alguma transformação de dados. Mostra como a entrada do processo, como um a especificação, por exemplo, é transformada em um a saída, como um projeto. As atividades, nesse caso, podem representar transfonnações realizadas por pessoas ou por computadores. 

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

FDD (Feature Driven Development) é uma metodologia muito objetiva, possuindo apenas duas fases:

Alternativas
Comentários
  • Há divergências conceituais quanto a essa questão.
    O FDD é um processo de software que utiliza métodos ágeis.
    Possui 5 processos/fases:
    1. Develop Overall Model
       
    2. Build Features List
       
    3. Plan by Feature
       
    4. Design by Feature
       
    5. Build by Feature

    Esses processos/fases podem ser agrupados em Concepção&Planejamento e Construção.

  • Na verdade:


    A FDD é uma metodologia muito objetiva. Possui apenas duas fases:

    • Concepção & Planejamento: Pensar um pouco antes de fazer (tipicamente de 1 a 2 semanas)
    • Construção: Fazer de forma iterativa (tipicamente em iterações de 2 semanas)


    E possui cinco processos que são bem definidos e integrados:

    1. DMA (Desenvolver um Modelo Abrangente): Análise Orientada por Objetos
    2. CLF (Construir a Lista de Funcionalidades): Decomposição Funcional
    3. PPF (Planejar por Funcionalidade): Planejamento Incremental
    4. DPF (Detalhar por Funcionalidade): Desenho (Projeto) Orientado por Objetos
    5. CPF (Construir por Funcionalidade): Programação e Teste Orientados por Objetos
    Abraço a todos...
  • A resposta para esta questão está neste link:

    http://www.heptagon.com.br/fdd-estrutura

  • Feature-Driven Development (FDD)


    "É um método ágil que enfatiza o uso de orientação a objetos. Possui apenas duas fases:


    1 - Concepção e Planejamento;

    2 - Construção.


    A fase de Concepção e Planejamento possui três disciplinas:


    * Desenvolver Modelo Abrangente;

    * Construir Lista de Funcionalidades; e 

    * Planejar por funcionalidade.


    A fase de Construção possui duas disciplinas:


    * Detalhar por Funcionalidade;

    * Construir por Funcionalidade.


    Fonte: Prova Cobra Tecnologia 2014 - Quadrix

    Naquela oportunidade errei, não erro nunca mais.


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

O conjunto de atividades e resultados associados que resulta em um produto de software recebe o nome de

Alternativas
Comentários
  • Processo de Software

    È um conjunto de atividades bem definidas.Contendo responsáveis,artefatos de entrada e saída,uma ordem de execução e um modelo de ciclo de vida bem definido.
  • Livro  engenharia de software. 7ed. Roger S. Pressman.

    pag 40.

    "Processo é um conjunto de atividades, ações e tarefas realizadas na criação de algum produto de trabalho (work product)."

  • b-

    processo de software - métodos, ferramentas e procedimentos. 

     

    elementos de um processo de software:

     


    atividades -

    pre-atividades
    subatividades

    _________________

    artefatos 
    input
    produtos

    _______________

    recursos
    RH
    ferramentas
    hadrware

    ___________________

    procedimentos
    metodos
    tecnicas
    roteiros


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

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

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

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

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

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

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


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


ID
339103
Banca
COSEAC
Órgão
DATAPREV
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

A identificação de problemasmais complexos resultará no desenvolvimento de algoritmos tambémmais complexos para resolvê-los. Uma abordagem eficiente para este tipo de situação é a divisão do problema complexo em problemas mais simples e, portanto, com soluções algorítmicas também mais simplificadas. Este método é conhecido como:

Alternativas

ID
349573
Banca
CONSULPLAN
Órgão
Prefeitura de Santa Maria Madalena - RJ
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Com base na metodologia de desenvolvimento dinâmico de sistemas (DSDM – Dynamic System Development Method), analise as afirmativas:

I. Estudo de viabilidade: estabelece os requisitos básicos e restrições do negócio associados à aplicação em construção e depois avalia se a aplicação é viável ao processo de desenvolvimento.
II. Estudo do negócio: estabelece os requisitos funcionais e de informação que permitirão à aplicação fornecer valor ao negócio; também define a arquitetura básica da aplicação e identifica os requisitos de manutenibilidade para a aplicação.
III. Iteração do modelo funcional: produz um conjunto de protótipos incrementais que demonstram a funcionalidade para o cliente.
IV. Iteração de projeto e construção: revisita os protótipos construídos durante a iteração do modelo funcional para garantir que cada um tenha passado por engenharia, de modo que seja capaz de fornecer valor ao negócio operacional para os usuários finais.

Estão corretas apenas as afirmativas:

Alternativas
Comentários
  • http://pt.wikipedia.org/wiki/Dynamic_Systems_Development_Method
  • Essa questão é copiada integralmente do Pressman.

    O DSDM Consortium é um grupo mundial de empresas que assumiram coletivamente, o papel de "zeladores do método". O consórcio definiu um modelo ágil de processo, chamado de ciclo de vida DSDM. O ciclo de vida DSDM define três ciclos iterativos diferentes, precedidos por duas atividades adicionais de ciclo de vida:

    Estudo de viabilidade: estabelece os requisitos básicos e restrições do negócio associados à aplicação em construção e depois avalia se a aplicação é viável ao processo de desenvolvimento.
    Estudo do negócio: estabelece os requisitos funcionais e de informação que permitirão à aplicação fornecer valor ao negócio; também define a arquitetura básica da aplicação e identifica os requisitos de manutenibilidade para a aplicação.
    Iteração do modelo funcional: produz um conjunto de protótipos incrementais que demonstram a funcionalidade para o cliente.
    Iteração de projeto e construção: revisita os protótipos construídos durante a iteração do modelo funcional para garantir que cada um tenha passado por engenharia, de modo que seja capaz de fornecer valor ao negócio operacional para os usuários finais.
    Implementação: coloca o último incremento de software no ambiente operacional.
  • a-

    Tudo correto. Lembrando que DSDM (dynamic system development method) tem 5 fases em 3 ciclos iterativos: pre-projeto, ciclo de vida e pos-projeto.

     

    Palavras-chave de cada fase:

    Estudo de viabilidade: requisitos básicos e as restrições do negócio. avaliação se é possivel pelo DSDM.


    Estudo do negócio: arquitetura do software, requisitos funcionais.


    Iteração do modelo funcional: protótipos, obtencao de requisitos adicionais


    Iteração de projeto e construção: revisão dos protótipos


    Implementação: codigo, incrementos funcionais


ID
392146
Banca
Aeronáutica
Órgão
CIAAR
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Associe os workflows com sua descrição.
A. Modelagem de Negócio
B. Requisitos
C. Análise e projeto
D. Implementação
E. Teste

( ) A geração automática de código com base nos modelos de projeto ajuda a acelerar este Processo.
( ) Um modelo de projetos é criado e documentado usando modelos de arquitetura, modelos de componentes, modelos de objeto e modelos de sequência.
( ) Os agentes que interagem com o sistema são identificados e os casos de uso são desenvolvidos.
( ) Processo interativo realizado em conjunto com a implementação.
( ) São modelados usando casos de uso de negócios

Alternativas
Comentários
  • Fluxo de Trabalho (em inglês, workflow) é a seqüência de passos necessários para se automatizar processos de negócio, de acordo com um conjunto de regras definidas, envolvendo a noção de processos, permitindo que possam ser transmitidos de uma pessoa para outra de acordo com algumas regras.

    _____________________________________

    workflow do processo de desenvolvimento de software:


    Modelagem de Negócios é uma técnica de modelagem de alto nível, que hoje é parte integrante no processo de desenvolvimento de software. Ela serviu para facilitar a comunicação com as pessoas que fazem parte do negócio e que não possuem conhecimentos de Engenharia de Software. É um conjunto estruturado de atividades, desenhado para produzir um resultado especificado para um cliente ou um mercado em particular. 

    Projeto: Nesta fase é que deve ser considerado, como o sistema funcionará internamente, para que os requisitos do cliente possam ser atendidos. Alguns aspectos devem ser considerados nessa fase de projeto do sistema, como: arquitetura do sistema, linguagem de programação utilizada, Sistema Gerenciador de Banco de Dados (SGBD) utilizado, padrão de interface gráfica, entre outros.

    Implementação: Nessa etapa, o sistema é codificado a partir da descrição computacional da fase de projeto em uma outra linguagem, onde se torna possível a compilação e geração do código-executável para o software

    Testes: Diversas atividades de testes são executadas a fim de se validar o produto de software, testando cada funcionalidade de cada módulo, buscando, levando em consideração a especificação feita na fase de projeto.


    Gabarito: A




ID
425005
Banca
UFBA
Órgão
UFBA
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

As Abordagens Evolucionárias de desenvolvimento de software permitem determinar, de forma precisa, o número de ciclos necessários para a construção do produto.

Alternativas
Comentários
  • As Abordagens Evolucionárias NÃO permitem determinar, de forma precisa, o número de ciclos necessários para a construção do produto. Pois, o número de ciclos pode ir muito além do que se foi estimado no início do projeto...
  • Abordagens Evolucionárias são indicadas quando os requisitos de software ainda não estão muito bem definidos ou são instáveis. Por isso não há como determinar de forma precisa o número de ciclos necessários para a construção do produto.
  • Os modelos de processo evolucionario produzem uma versao cada vez mais completa do software a cada iteracao.
    Fonte: Pressman, Roger. Engenharia de Software, 7th Edição pág 62.


    Com isto a cada vez que se passa pela fase de análise, novos requisitos surgem alterando o projeto inicial e por este motivo não se tem como medir de forma precisa o número de ciclos.
  • Está sempre Evoluindo....

  • Kayto,

    Seus comentários são os piores que já ví. Para não dizer outra coisa.

    Att.

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

Conforme o SWEBOK, corpo de conhecimento da engenharia de
software, a engenharia de software é a aplicação de uma abordagem
sistemática, disciplinada e quantificada ao desenvolvimento, operação
e manutenção de software. Julgue o item a seguir acerca das
informações apresentadas e dos conceitos de engenharia de software.

Entre as metodologias de desenvolvimento de software atualmente empregadas destacam-se as abordagens embasadas no modelo unificado e as abordagens ágeis. O uso das técnicas de test-driven design, refactoring, design patterns e pair programming é, entre os modelos acima, maior nas abordagens do modelo unificado. Por outro lado, o uso de ferramentas CASE-UML é mais comum nas abordagens ágeis.

Alternativas
Comentários
  • Entre as metodologias de desenvolvimento de software atualmente empregadas destacam-se as abordagens embasadas no modelo unificado e as abordagens ágeis. O uso das técnicas de test-driven design, refactoring, design patterns e pair programming é, entre os modelos acima, maior nas abordagens do modelo unificado. Por outro lado, o uso de ferramentas CASE-UML é mais comum nas abordagens ágeis.

    * A parte em negrito tudo errado!

     

  • O uso das técnicas de test-driven design, refactoring, design patterns e pair programming: Métodos ágeis.

    o uso de ferramentas CASE-UML: Processo Unificado.

  • ERRADO.

    Típica questão da Banca CESPE, INVERTER conceitos/definições.

     

    Métodos Ágeis ---> O uso das técnicas de test-driven design, refactoring, design patterns e pair programming.

    Processo Unificado ---> o uso de ferramentas CASE-UML.

  • o uso de ferramentas CASE-UML é mais comum nas abordagens ágeis.

    test-driven design, refactoring, design patterns e pair programming: Métodos ágeis.

    Bendito serás!!


ID
505162
Banca
CESPE / CEBRASPE
Órgão
TRE-AP
Ano
2007
Provas
Disciplina
Engenharia de Software
Assuntos

O uso de metodologias de desenvolvimento de sistemas tem como objetivo garantir que

Alternativas
Comentários
  • Metodologia de desenvolvimento de software é uma série de passos previsíveis - um toreiro que ajude a criar um resultado de alta qualidade e dentro do prazo estabelecido.

    Pressman, 7ed, pg 52

    letra d

ID
599719
Banca
CESGRANRIO
Órgão
Petrobras
Ano
2011
Provas
Disciplina
Engenharia de Software
Assuntos

Ainda existem muitos projetos de software que atrasam, ultrapassam o orçamento e não produzem software que atenda às necessidades do cliente.

PORQUE

Não existem métricas de software padronizadas e universalmente aceitas, e, colocar mais homem/hora em um projeto atrasado, pode atrasar ainda mais a construção desse software.

Analisando-se as afirmações acima, conclui-se que

Alternativas
Comentários
  • Alguém pode explicar pq não existem métricas de software padronizadas e universalmente aceitas ??
  • Faço minhas as palavras do colega. Como assim não existem métricas de software mundialmente aceitas????
  • Olha, segundo Elielder Berwanger, na apostila de engenharia de software (p.4): " Um processo de software não pode ser definido de forma universal. Para ser eficaz e conduzir à construção de produtos de boa qualidade, um processo deve ser adequado ao domínio da aplicação e ao projeto específico. Deste modo, processos devem ser definidos caso a caso, considerando-se as especificidades da aplicação, a tecnologia a ser adotada na sua construção, a organização onde o produto será desenvolvido e o grupo de desenvolvimento". 

  • Acho que o que valida a segunda afirmativa é a palavra "universalmente".

    Marquei a letra "C".

  • IFPUG e NESMA não seriam órgãos que desenvolveram padrões de métricas de software internacionalmente aceitos? A questão parece estar equivocada... Aparentemente é a letra C mesmo. Alguém pode dar uma explicação a respeito?

  • Também não entendi o porquê da letra B ser a correta. Também marquei a C.

  • Apesar de muitas métricas serem padronizadas, não conheço uma métrica universal que todos aceitem. (ex. Até contagem de linha de código pode não ser aceito, considerando códigos otimizados).

    Mesmo tendo errado, agora que refleti, eu concordo com a letra B, muito bem elaborada essa questão. 

  • Bom, a primeira afirmação esta correta e é auto explicativa.

     A segunda afirmação também está correta, pois não há um padrão universalmente aceito e conhecido que se adapte a cada caso, logo, pode ser escolhido uma métrica equivocada no projeto, o que poderia atrasá-lo e colocar mais pessoas no projeto poderia atrasá-lo ainda mais pois teria que ser treinado e adaptado a ele antes que começasse a efetivamente desenvolver algo.

    Logo marquei a segunda, pois, caso se escolhesse uma métrica correta, não haveria atraso, mesmo não sendo o padronizado e universalmente aceito, pois não existe um assim.

  • Eu acertei a questão, mas foi por um raciocínio diferente dos colegas abaixo.

    Para mim, a segunda afirmação pode ser verdadeira. Como existem diversos tipos de projetos envolvendo várias tecnologias, uma métrica usada para um tipo de projeto pode não ser aplicável a outro tipo de projeto. Quanto à parte de colocar mais homens trabalhando atrasar o projeto, creio que não é dificuldade nenhuma em concordar com isso.
    Porém, a segunda afirmativa não justifica a primeira. Ou seja, um projeto atrasa não por causa de métricas que medem errado ou pq se colocam mais pessoas trabalhando. Na verdade, entendo a segunda afirmação como um reflexo do próprio atraso. Um projeto atrasa por n motivos, como a dificuldade de definição de requisitos por parte dos clientes, ou por falta de orçamento para ter as ferramentas e tecnologias necessárias, ou por não conseguir contratar profissionais qualificados, etc.
    O que vcs acham?
  • Acredito que dizer "Não existem métricas de software padronizadas e universalmente aceitas" é algo muito forte. Dizer que uma métrica A é melhor que uma métrica B para um determinado tipo de projeto é totalmente diferente de dizer que não existe uma padronização e um reconhecimento da métrica A ou B.

    Traduzindo para linguagens de programação: Dizer que é melhor usar JAVA que C++ para uma aplicação que rode em várias plataformas é apenas afirmar que neste cenário JAVA é melhor aplicada, mas não quer dizer que não se possa efetuar a mesma aplicação usando C++. Ou seja, tanto JAVA quanto C++ estariam como possíveis linguagens a serem usadas para desenvolver a aplicação. Assim sendo, usar uma métrica como Pontos de Função pode ser mais indicada para este ou aquele cenário, mas isso não a deixa como uma métrica mundialmente aceita. Pode não haver UM PADRÃO de adoção de uma determinada métrica para um determinado tipo de aplicação, mas até onde sei, os padrões existentes são universalmente aceitos


ID
610330
Banca
CONSULPLAN
Órgão
INB
Ano
2006
Provas
Disciplina
Engenharia de Software
Assuntos

Quanto à aplicação de uma Metodologia de Desenvolvimento de Sistemas pode-se afirmar que, EXCETO:

Alternativas
Comentários
  • UML não é metodologia de desenvolvimento.
  • Inclusive, existem metodologias criadas exatamente para o uso em projetos OO

  • O gabarito é a letra B.

     

    Metodologia de desenvolvimento pode se aplicar para qualquer tipo de sistema, inclusive na Análise Orientada a Objetos. 


ID
645373
Banca
AOCP
Órgão
BRDE
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

Em Engenharia de Software, temos o Desenvolvimento em Espiral, cada loop da espiral é dividido em quatro setores, a seguir apresentamos alguns deles. Analise as assertivas e assinale a alternativa que apresenta os corretos.

I. Desenvolvimento de integração: O software que não puder ser comprado será desenvolvido, e os componentes e sistemas COTS serão integrados, a fim de criar um sistema. A integração de sistemas, nesse modelo, pode ser parte do processo de desenvolvimento, em vez de uma atividade separada.

II. Definição de objetivos: São definidos os objetivos específicos para essa fase do projeto. São identificadas as restrições para o processo e o produto, e é preparado um plano de gerenciamento detalhado. São identificados os riscos do projeto e, dependendo dos riscos, poderão ser planejadas estratégias alternativas.

III. Avaliação e redução de riscos: Para cada um dos riscos de projeto identificados, é realizada uma análise detalhada e são tomadas providências para reduzir esses riscos. Por exemplo, se houver um risco de os requisitos serem inadequados, poderá ser desenvolvido um protótipo.

IV. Panejamento: O projeto é revisto e é tomada uma decisão sobre continuar com o próximo loop da espiral. Se a decisão for continuar, serão traçados os planos para a próxima fase do projeto.

Alternativas
Comentários
  • Conforme um artigo encontrado na internet, resumindo o desenvolvimento em Espiral:
    no endereço: http://www.linux.ime.usp.br/~cef/mac499-05/monografias/rec/daw/eng_soft.html
    DIZ:

    Neste modelo o processo de software é representado como uma espiral. Cada loop na espiral representa uma fase do processo de software, por exemplo, o loop mais interno pode estar relacionado a viabilidade do sistema. Cada loop é dividido em 4 setores:

    • Definição de objetivos - São definidos os objetivos para a fase do projeto.
    • Avaliação e redução de risco - é realizada uma análise detalhada para cada risco identificado e são tomadas providencias para reduzir esses riscos.
    • Desenvolvimento e validação - é escolhido o modelo de desenvolvimento do sistema, e o sistema é então desenvolvido e validado.
    • Planejamento - O projeto é revisto e é tomada uma decisão sobre continuar com o próximo loop, e se for o caso é traçado o planejamento para a próxima fase.
  • Determinar os objetivos, alternativas e restrições
     -> Análise, identificação e resolução de riscos
         -> desenvolver e verificar o produto
              -> Planejar a próxima fase (ou ciclo)
         N O V O  C I C L O
                      -> Determinar os objetivos, alternativas e restrições
                            -> Análise, identificação e resolução de riscos
                                -> desenvolver e verificar o produto 
                                      -> Planejar a próxima fase (ou ciclo)
  • O gabarito está errado.
    II. Definição de objetivos: São definidos os objetivos específicos para essa fase do projeto. São identificadas as restrições para o processo e o produto, e é preparado um plano de gerenciamento detalhado. São identificados os riscos do projeto e, dependendo dos riscos, poderão ser planejadas estratégias alternativas.
    A letra correta deveria ser D.
  • Gabarito Correto, Segundo Sommerville 9º edição Pag. 33

    I - ERRADO, não tem esse setor e sim o Desenvolvimento e Validação

    II - Definições de Objetivos:  Objetivos especificos para essa fase do projeto são definidos; restrições ao processo e ao produto são identificadas, e um plano de gerenciamento detalhado é elaborado; os riscos do projeto são identificados. Podem ser planejadas estratégias alternativas em função desses riscos.

    III - Avaliação e redução de riscos: copia do livro, CORRETO

    IV - Planejamento: o projeto é revisado, e uma decisão é tomada a respeito da continuidade do modelo com mais uma volta da espiral. caso se decida pela continuidade, planos  são elaborados para a proxima fase do projeto.

    Gabarito LETRA B

  • Um framework de processo de software dirigido a risco. 
    Cada volta da espiral é dividida em quatro setores:
    Definição dos objetivos
    Avaliação e redução de riscos
    Desenvolvimento e validação
    Planejamento
  • Marquei a letra D, pois de que serve então o quadrante de Avaliação e redução de riscos se a questão coloca suas atribuições no quadrante Definição de objetivos? Questão no mínimo questionável. 
  • Minha dúvida era quanto a veracidade do item II, se na fase de Definição dos Objetivos é feita uma identificação dos riscos. Mas, após um estudo mais aprofundado, li o seguinte texto publicado em http://dinobrasilis.pro.br/mod_inic_1.pdf: 

    "Um ciclo da espiral começa com a elaboração de objetivos, como desempenho, funcionalidade, etc. Meios alternativos de atingir esses objetivos e suas restrições são enumerados. Cada alternativa é examinada em relação a cada objetivo. Isso resulta na identificação das causas de riscos. A próxima etapa é avaliar esses riscos. Em seguida uma parte é realizada e parte-se para a próxima fase do projeto."

    Ou seja, para não esquecermos: na fase de "Definição dos objetivos" é feita a identificação dos objetivos, riscos e restrições. Agora, a avaliação e redução desses riscos é feita na fase seguinte do modelo espiral, na fase "Avaliação de Alternativas e Redução de riscos". 

    Ok, entendido!

    Bons estudos!

  • Vide Desenvolvimento em Espiral em Sommerville


ID
675490
Banca
CONSULPLAN
Órgão
TSE
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

Dentre as metodologias de desenvolvimento de sistemas, uma tem se destacado sendo descrita por cinco visões independentes. Uma delas enfatiza as características de concorrência, sincronização e desempenho do sistema, sendo denominado visão de

Alternativas
Comentários
  • O examinador queria saber ou da visão da UML ou da visão do RUP.
    "Visão do processo de um sistema mostra o fluxo de controle entre as várias
    partes, incluindo mecanismos de concorrência e de sincronização. Essa visão
    cuida principalmente de questões referentes ao desempenho, à escalibilidade
    e ao throughput do sistema".
    Fonte: UML, Guia do Usuário, pág. 35.
    "No RUP, você parte de um conjunto típico de visões, denominado "modelo de visão 4+1" [KRU95]. Ele é composto pelas seguintes visões:
    [...]
    A Visão de Processos, que contém a descrição das tarefas (processo e threads) envolvidas, suas interações e configurações, e a alocação dos objetos e classes de design em tarefas. Essa visão só precisará ser usada se o sistema tiver um grau significativo de simultaneidade. No RUP, ela é um subconjunto do modelo de design.
    [..]
    Fonte: http://www.wthreex.com/rup/portugues/process/workflow/ana_desi/co_swarch.htm#A
    Ambos (UML e RUP) em suas descrições estão falando do modelo de visão4+1, até mesmo porque os criadores do RUP são os mesmos da UML.


    P.S.: Esse tal de Mário tá de palhaçada...todos os comentários dele são assim. Quando não o são são sobre coisas que não tem nada a ver com as respostas todas erradas...

ID
677398
Banca
FEC
Órgão
DETRAN-RO
Ano
2007
Provas
Disciplina
Engenharia de Software
Assuntos

A declaração de escopo ajuda o planejador a desenvolver estimativas usando uma ou mais técnicas situadas em duas amplas categorias. Essas categorias são conhecidas como:

Alternativas

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

Sobre Modelagem algorítmica de custos, uma das técnicas de estimativa e planejamento de software, é correto afirmar:

Alternativas
Comentários
  • SOMMERVILLE 9ª EDIÇÃO

    Esforço = A x TamanhoB x M, onde A é uma constante que depende das práticas organizacionais locais e do tipo do software, Tamanho pode ser uma estimativa do tamanho do código. B geralmente fica entre 1 e 1,5, e M outra constante feita pela combinação de atributos de processo, produtos e de desenvolvimento.

    a) V
    b) Se baseiam na experiência do gerente em projetos anteriores e em seu domínio de aplicação.(V) Essencialmente, o gerente faz uma avaliação informada do que os requisitos de esforço podem ser. (F). É utilizada uma fórmula para estimar o esforço.
    c) Modelos algorítmicos de custos são uma maneira sistemática de estimar o esforço necessário para o desenvolvimento do sistema e, devido ao reduzido número de atributos e à pequena margem de incerteza, são de baixa complexidade. São muitos atributos e uma margem considerável de incerteza em estimar esses valores, o que causa uma alta complexidade para o cálculo.
    d)Um ponto que traz agilidade e facilidade a esse modelo é a calibração, no qual os usuários podem determinar valores aos atributos utilizando os dados históricos de projetos anteriores. Na verdade a calibração é uma barreira, pois a maioria das organização não matém dados suficientes de projetos antigos
    e)  
    Sempre permite estimar o tamanho em um estágio de um projeto desde que a especificação esteja disponível, pois, nesse modelo, as estimativas não variam em função da experiência ou do tipo de sistema sendo desenvolvido  . É difícil estimar o tamanho quando se tem apenas a especificação, além de variar quanto à experiência e ao tipo de sistema desenvolvido.
  • "A forma adotada pelas organizações para estimar projetos de software pode variar de acordo com o modelo de processo utilizado em cada uma e do tipo de projeto, porém é desejável que haja um conhecimento prévio sobre técnicas de estimativas, além de uma visão, mesmo que macro, do escopo do projeto e, se possível, uma base histórica onde seja possível consultar estimativas de projetos semelhantes já finalizados. De acordo com Sommerville (2003), normalmente as seguintes técnicas são utilizadas para a realização de estimativas:

    Técnicas baseadas em experiências – As estimativas de requisitos de futuros esforços são baseadas na experiência do gerente com projetos anteriores e no domínio da aplicação. Essencialmente, o gerente faz um juízo fundamentado a respeito de como devem ser os requisitos de esforço.

    Modelagem algorítmica de custos – Nessa abordagem, é usada uma abordagem para calcular o esforço do projeto com base em estimativas dos atributos de produto, como tamanho e características do processo, assim como a experiência da equipe envolvida."

    Fonte: RIBEIRO, Leila de Oliveira - IMPLEMENTAÇÃO DE PROCESSOS: O USO DE TÉCNICAS DE ESTIMATIVAS DE PROJETOS DE SOFTWARE PARA ESTIMAR PROCESSOS DE NEGÓCIO


    Letra A - OK.

    Letra B - Trata-se das técnicas baseadas em experiências.

    Letra C - Não são de baixa complexidade.

    Letra D - Calibração envolve técnicas baseadas em experiências.

    Letra E - Varia em função da experiência SIM!


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

O processo de desenvolvimento de software conhecido como modelo em espiral (Modelo espiral de Boehm), divide cada volta da espiral em quatro setores, sendo um destes setores denominado de:

Alternativas
Comentários
  • No livro do Sommerville, 7º edição, pg 49, possui o modelo em espiral do processo de software de Boehm. Cada volta do espiral possui:
    1. Determinar objetivos, alternativas e restrições
    2. Avaliar alternativas, identificar, resolver riscos
    3. Planejar próxima fase
    4. Desenvolver, verificar produto de próximo nível
  • http://www2.dem.inpe.br/ijar/CicoloVidaSoftPrado_arquivos/c2_5.gif
  • Pelo que eu saiba, no modelo vc pode definar as fases que vc quiser. Isso vai de sistema para sistema.
    Pelo menos no livro do pressman é isso que se fala.
  • Os quatro setores: 

    1 Definição de objetivos.

    2. Avaliação e redução de riscos

    3 Desenvolvimento e validação. 

    4 Planejamento

  • Muito complicado estudar Engenharia de Software, tendo em vista que há mais de um autor consagrado, que dizem coisas totalmente diferentes e as bancas utilizam, aleatoriamente, sem definir bibliografia, cada hora um autor.

  • questoes parecidas

    Segundo Sommerville (2011), no modelo em espiral de Boehm, cada volta está dividida em quatro setores. Uma das alternativas abaixo NÃO denomina um desses quatro setores. Assinale-a:

     a) Desenvolver e verificar próximo nível do produto.

     b) Avaliar alternativas, identificar, resolver riscos.

     c) Gerenciar a qualidade e o custo do desenvolvimento.

     d) Determinar objetivos, alternativas e restrições.

     e) Planejar da próxima fase.


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

A metodologia de desenvolvimento de software desenvolvida pela marinha norte-americana nos anos 60 para permitir o desenvolvimento de softwares militares complexos, onde o projeto segue uma série de passos ordenados e, ao final de cada fase, a equipe de projeto finaliza uma revisão, onde o desenvolvimento não continua até que o cliente esteja satisfeito com os resultados é:

Alternativas
Comentários
  • A metodologia de desenvolvimento em cascata foi desenvolvida pela marinha norte-americana nos anos 60 para permitir o desenvolvimento de softwares militares complexos. No modelo em cascata, o projeto segue uma série passos ordenados. Ao final de cada fase, a equipe de projeto finaliza uma revisão. O desenvolvimento não continua até que o cliente esteja satisfeito com os resultados. A figura abaixo ilustra o funcionamento desta metodologia.

    Metodologia de Desenvolvimento em Cascata

    Se for necessário efetuar alguma modificação, voltar os passos de desenvolvimento do projeto é complicado. A metodologia em cascata é extremamente formal, como seria normal de se esperar de uma metodologia cujas raízes encontram-se no militares. Pode-se afirmar que a metodologia em cascata é baseada em documentos e com certeza possui uma enorme quantidade de “entregáveis” e saídas que nada mais são do que documentos. Outra características deste modelo é o alto valor dado ao planejamento. O forte planejamento inicial reduz a necessidade de planejamento contínuo conforme o andamento do projeto.

  • Não concordo. Segundo o Pressman, o modelo cascata não depende do feedback do usuário para dar continuidade no processo. 
  • Concordo com o Luan. No modelo em cascata, o usuário, teoricamente, só tem o interesse no produto final. As entregas entre cada disciplina (Requisitos, Análise, Projeto, Desenvolvimento ...) não tem interferência "direta" do cliente.
  • Concordo com os colegas. O cascata não trabalha com o feedback. Pelo contrário, nesta metodologia o risco é altíssimo visto que ao final do projeto o negócio pode ter mudado e o que o sistema se propõe a fazer não está de acordo com a nova visão da organização.

    Eu marquei metodologia RUP por se tratar de um sistema complexo.
  • Questão lamentável,
    eu fiz essa prova, errei essa questão, entrei com recurso e  o Instituto Cidades sequer respondeu meu recurso.
    até onde eu sei o processo cascata realmente só inicia a fase seguinte depois de terminada a fase anterior, no entanto
    não há revisões uma vez que o cliente só irá ver o software quando este estiver finalizado.
  • A metodologia de desenvolvimento de software desenvolvida pela marinha norte-americana nos anos 60 para permitir o desenvolvimento de softwares militares complexos, onde o projeto segue uma série de passos ordenados e, ao final de cada fase, a equipe de projeto finaliza uma revisão, onde o desenvolvimento não continua até que o cliente esteja satisfeito com os resultados é:
     
    Há várias “pistas” na questão.
     
    A validação com o usuário é no final de cada fase que somente iniciará a  próxima com a validação da anterior
     
  • Sommerville, 9ed, pg 21
    "Em princípio, o resultado de cada estágio é a aprovação de um ou mais documentos ('assinados'). O estágio seguinte não deve ser iniciado até que a fase anterior seja concluída. Na prática, esses estágios se sobrepõem e alimentam uns aos outros de informações. Durante o projeto, os problemas com os requisitos são identificados; durante a codificação, problemas de projeto são encontrados e assim por diatne. O processo de sw não é modelo linear simples, mas envolve o feedback de uma fase para outra. Assim, os documentos produzidos em cada fase prodem ser modificados para refletirem as alterações feitas em cada um deles."
  • O "usuario" Felipe tem mais de 65 comentarios em questões, todas elas somente com o gabarito da questão conforme acima... evitem qualificar estes tipos de usuarios, mesmo que seja apenas com 1 estrela. 

    QC me ajuda ai!!!

    desculpem o tilt! pessoal, bons estudos!

    Veja como divulgar a Campanha Nota Justa)
  • Também não acredito que seja cascata pela questão do feedback.

  • Embora seja possível responder a questão por outros elementos presentes no comando da mesma, fui atrás da referência da banca.

    As  referências que pude encontrar para essa questão são as seguintes:

    1-

    2.5 Metodologia de desenvolvimento em cascata

    A metodologia de desenvolvimento em cascata foi desenvolvida pela marinha norte-americana nos anos 60,para permitir o  desenvolvimento de softwares militares complexos(PRESSMAN,2006). No modelo em cascata, o projeto segue uma série passos ordenados,ao final de cada fase, a equipe de projeto finaliza uma revisão, conforme Vasconcelos (2006). O desenvolvimento não continua até que o cliente esteja satisfeito com os resultados (SOMMERVILLE, 2003)

     

    Fonte: http://www.abepro.org.br/biblioteca/enegep2011_TN_STO_142_899_17766.pdf

     

    2-

    "Embora o modelo cascata proposto por Winston Royce [Roy70] previsse os feedbacks loops, a vasta maioria das organizações que aplica esse modelo de processo os trata como se fossem estritamente lineares"

    Sommerville, 7 ed, pag. 59, nota de rodapé


ID
776479
Banca
CESGRANRIO
Órgão
Chesf
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

Um analista desenvolve um software e identifica que os seus requisitos iniciais estão razoavelmente bem definidos, mas o escopo geral do desenvolvimento não permite um processo puramente linear. Ele sabe que precisa, em curtíssimo prazo, prover um conjunto limitado de funcionalidades do software para os usuários, que serão refinadas e expandidas em versões futuras.

Qual o modelo de ciclo de vida de desenvolvimento de software mais adequado a esse caso?

Alternativas
Comentários
  • O processo INCREMENTAL garante a entrega de um produto com funcionalidade completa, porem limitada que vai se refinando e melhorando a cada INCREMENTO de software. 
    O processo CASCATA compreende a entrega do software completo, é mais longo e nao recomendado para prazos curtos.
    O processo por PROTOTIPACAO nao entrega software completo e só mostra uma ideia da funcionalidade, podendo até ser descartado. 
    O processo em ESPIRAL é orientado a riscos.
    Obrigado.
  • Segundo o professor Pedrosa...

    a) Cascata não gera versões.
    b) O Espiral, apesar de iterativo e incremental, não vai gerar um produto em "curtíssimo" prazo, pois ele ainda tem um certo formalismo, principalmente em se tratando de Análise de Riscos (quadrante obrigatório do modelo).
    c) Método Formal é custoso, lento.
    e) Prototipação poderia ser uma resposta aceitável... principalmente se pensarmos em Prototipação Evolucionária (começar dos requisitos mais fáceis para entregar versões rápidas ao usuário). Mas, como eu falo em sala de aula, normalmente quando se fala "Prototipação", estamos nos referindo à Prototipação Descartável, que é muito mais uma técnica de elicitação de requisitos do que um modelo de ciclo de vida.

    • d) Incremental 
    • ...precisa, em curtíssimo prazo, prover um conjunto limitado de funcionalidades do software para os usuários,...
    •  
  • Lembrando que modelo em Espiral PODE SER Incremental, porém em sua descrição enxuta dos livros, é caracterizado apenas como ITERATIVO.

    PODE SER Incremental, se combinar outros modelos de ciclo de vida, mas o tradicional, básicão, é apenas ITERATIVO.


    Fonte:  [Duvida] Modelo Espiral é Iterativo e Incremental? http://br.groups.yahoo.com/group/timasters/message/163427
  • Vantagens do Modelo Incremental

    1) Entregas parciais facilitam a identificação e correção de erros entre os componentes do software.
    2) Necessidades não especificadas nas fases iniciais podem ser desenvolvidas nos incrementos.
    3) Cada iteração produz um conjunto de itens utilizáveis.
    4) Os feedbacks de iterações anteriores podem ser usados nos próximos incrementos.
    5) Os incrementos podem ser desenvolvidos por menos profissionais.
    6) Entrega dos incrementos pemite o cumprimento do prazo especificado.


ID
814432
Banca
AOCP
Órgão
TCE-PA
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

A forma de revisão de software em que um desenvolvedor lidera os membros da equipe de desenvolvimento e outras partes interessadas em um produto de software, e possibilita aos participantes fazerem perguntas e comentários sobre possíveis erros, violação de padrões de desenvolvimento, dentre outros, é conhecida como

Alternativas
Comentários
  • d-

    BPMS é uma linguagem de modelagem. Workflow é o diagrama de atividades ou hierarquia. Workaround é uma solução temporaria para gerenciamento de problemas ate que se encontre uma solução duradoura.


ID
871054
Banca
Aeronáutica
Órgão
CIAAR
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

Preencha as lacunas e, em seguida, assinale a alternativa correta.

A _______________ de software ou, mais genericamente, _______________ e _______________, destina-se a mostrar que um sistema está em conformidade com sua especificação e que atende às expectativas do cliente que está adquirindo o sistema. Isso envolve processos de _______________, tais como inspeções e revisões a cada estágio do processo de software, desde a definição de requisitos de usuário até o desenvolvimento do programa.

Alternativas
Comentários
  • Retirado de somerville, página 50 e também na 358
     O objetivo da questão é saber a diferença entre validação e verificação de software, o que somerville deixa bem claro na página 358.

    Verificação --> Diz respeito à o quanto estamos sendo fiéis aos requisitos (já especificados) de software . Estamos fazendo corretamente o software? 
    Validação --> Diz respeito à o quanto estamos sendo fieis à o que o cliente deseja. Estamos fazendo o software correto?

    Verificação está mais relacionado ao projeto de software, enquanto validação está mais relacionada ao cliente, se suas necessidades estão sendo atendidas. Na última lacuna se encaixa perfeitamente a verificação.  Na segunda e na terceira respectivamente se encaixam os conceitos de verificação e validação, mas penso que na verdade a ordem não importa. Já a primeira lacuna está ligada aos conceitos do somerville sobre validação de software em Somerville, páginas 50 e 358


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

Julgue o item a seguir referente à metodologia de desenvolvimento
de software.

Para a utilização de metodologias modernas, com abordagem da engenharia de software, recomenda-se a elaboração dos manuais do sistema ao final do projeto, quando todos os seus detalhes já estão definidos.

Alternativas
Comentários
  • Questão Errada. No RUP, por exemplo, manuais são construídos tanto na fase de Elaboração (Manual preliminar) quanto de Construção (Material de Apoio).

    Fonte: Pressman Engenharia de Software, 6ª Edição , página 54.
  • Prezados,
    A questão esta errada, visto que não existe tal recomendação, pelo contrário, diversas fontes recomendam a elaboração dos manuais do sistema durante o projeto, e não ao final dele.
    Pressman define em seu livro ( item 13.8 , pág 359 ) que na etapa de design já é aconselhado desenvolver um manual preliminar de operações e instalação. No RUP, o manual do usuário é iniciado na fase de elaboração, ou seja, bem antes do final do projeto. O próprio Sommerville ao explicar as fases do RUP ( pág 55 ) informa que ao final da fase de construção a documentação associada já está pronta para ser liberada para os usuários.
    Fontes: 
    - Pressman, Roger S. Software Engineering: A Practiotioner’s Approach. Fifth Edition
    - http://www-01.ibm.com/software/rational/rup/
    - Sommerville, Ian ,Software Engineering, 8th edition

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

Julgue os itens a seguir, acerca de metodologias ágeis de desenvolvimento.

Kanban é um método de desenvolvimento de software que tem como uma de suas práticas o gerenciamento do fluxo de trabalho, que deve ser monitorado, medido e reportado a cada estado do fluxo.

Alternativas
Comentários
  • Certinho, fiquei na dúvida somente no reporte de cada fluxo.
    Kanban não possui sprint, mas tem feedback....
    não sei o que o examinador quis dizer com isso
  • A origem do Kanbam vem da indústria e posteriormente encontrou a aplicação no desenvolvimento de software. A chave do método em manter um quadro branco contendo a fases do projeto e utilizar post-its (etiquetas adevisas) para mostrar como está o andamento das tarefas do projeto. Olhando para esse quadro sabemos como está o andamento do projeto. A questão afirma "tem como uma de suas práticas o gerenciamento do fluxo de trabalho, que deve ser monitorado, medido e reportado a cada estado do fluxo" , tudo o que esse quadro proporciona.


    Fontes:

    Livro Kanban em 10 Passos 
  • Achei esquisito porque Kanban não é um "método de desenvolvimento de software". Estranho....

  • Eu sempre achei que Kanban era um método de suporte ao desenvolvimento de software (o que me fez marcar E), mas uma busca me fez ver que realmente pode ser um método de desenvolvimento de software.

  • Pelo que conhecia Kambam não era um método de desenvolvimento de software.

  • Eu aprendi que Kanban é um método para implantação/gerenciamento de mudanças. Acabei marcando errado por isso. Penso que nada impede que esse método seja aplicado em desenvolvimento de software (e, de fato, o é), principalmente quando estamos falando de mudanças no âmbito das metodologias ágeis. Mas, daí dizer que kanban é um método DE desenvolvimento de software, acho um pouco demais. Pois abre para a interpretação de que Kanban foi concebido para desenvolvimento de software: o que, pelo pouco, ou quase nada, que sei, não seria uma verdade.

    Dificilmente, a CESPE alteraria o gabarito dessa assertiva. O meu histórico de recursos (naturalmente, uns mais bem fundamentados que outros) me ensinou que examinadores geralmente são um tanto quanto bitolados nesse sentido e preferem não enxergar para além de sua zona de conforto técnico. Além do mais, "pega mal" para eles o fato de uma de suas questões escolhidas (muito bem pagas, diga-se de passagem) ser anulada ou ter seu gabarito alterado. Em todo caso, fica o protesto e abertura para discussão/aprendizado.

    Abs,

  • Engraçado como a gente vai abstraindo de alguns detalhes que percebemos que não são importantes para acertar questões de concursos públicos, li meu comentário feito em dezembro de 2015 e aproveitei para atualizá-lo com um novo entendimento postado recentemente em outra questão.

     

    Um framework pode ter um conceito muito próximo ou até convergente ao de uma metodologia. Basta darmos uma "pesquisada" rápida que constataremos a "salada".

     

    De acordo com os conceitos que normalmente me aproprio* para facilitar o meu entendimento, concordo que o Scrum tem um aspecto mais próximo ao de um framework do que de uma metodologia. Mas, na boa, não há o mínimo consenso, seja no âmbito dos concursos públicos, seja no âmbito dos profissionais do mercado privado, seja no meio acadêmico sobre o que seria um framework.

     

    Para complicar ainda mais essa discussão, o livro Implantando a Governança de TI, dos autores Aragon Fernandes e Ferraz de Abreu, diz explicitamente, na página 384, que Scrum é uma metodologia ((...) "a metodologia Scrum foi concebida" (...)). E esse livro é muito usado pelas bancas de concursos públicos.

     

    Quanto ao Kanban, defendê-lo como uma metodologia é "doído" demais. Mas, da mesma forma como acontece com o Scrum, encontramos com facilidade referências a essa ferramenta (também prefiro chamar assim) como framework, como sistema, como técnica e até (pasmem!) como metodologia (e isso em artigos sérios).

     

    Conclusão, não me apegaria a isso, tanto no caso do Scrum como no caso do Kanban, como algo determinante para avaliar uma questão de concurso.

     

     

    Outro ponto que gostaria de comentar é em relação ao gabarito: Incremental diz respeito a algo que adiciona uma parte que antes não existia. É como se fosse a adição de um novo módulo que sequer existia na versão anterior de um software. É como se adicionássemos uma nova peça a um produto.

     

    Iterativo é algo que melhora uma parte que antes já existia em determinado estágio de evolução. É como se fosse a melhoria de um módulo anteriormente elaborado (ou pré-elaborado). É como se fosse um ajuste em uma peça de um produto.

     

    Assim, temos que o Kanban é linear (orientado a fluxo). Nele, uma tarefa (ou atividade, ou entrega) entra de um lado e sai do outro. Pronto! Podemos dizer, assim, que houve um incremento, quando aplicável. Podemos até utilizar o Kanban dentro de uma iteração de modo a forcecer subsídios (entregáveis) para a mesma (e quando ele é utilizado em conjunto com o Scrum, é exatamente isso que acontece dentro de uma Sprint), mas não é essa (a iteração) a preocupação do Kanban, ele é focado, como dito anteriormente, em fluxo. Concordo com o gabarito.

     

    Referente a ao parágrafo anterior, sugiro uma leitura em http://www.netobjectives.com/blogs/real-differences-between-kanban-and-scrum , item Flow vs. Iterations.

     

    Sorte para os que cuidam dela.

     

    * estrutura conceitual básica; esqueleto

  • "método de desenvolvimento de software" uhum... tá....

  • CESPE considera que o Kanban é um método de desenvolvimento.. Bem polêmico desde de questões antigas.


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

Julgue os itens a seguir, acerca de metodologias ágeis de desenvolvimento.

Usando-se o TDD, as funcionalidades devem estar completas e da forma como serão apresentadas aos seus usuários para que possam ser testadas e consideradas corretas.

Alternativas
Comentários
  • TDD é justamente o contrário disso, o teste vem antes
  • Test Driven Development (TDD) ou em português Desenvolvimento dirigido por testes é uma técnica de desenvolvimento de software que baseia em um ciclo curto de repetições: Primeiramente o desenvolvedor escreve um caso de teste automatizado que define uma melhoria desejada ou uma nova funcionalidade. Então, é produzido código que possa ser validado pelo teste para posteriormente o código ser refatorado para um código sob padrões aceitáveis.
  • O desenvolvimento guiado por teste dá uma visão mais ampla do que deve ser feito ao desenvolvedor, pois antes de criar a funcionalidade, deve-se criar um teste da funcionalidade
  • Segundo Pressman:  

    Em desenvolvimento baseado em  teste (test-driven development— TDD),  requisitos para um componente de software servem de base para a criação de uma série de casos de teste que exer­citam  a  interface e  tentam encontrar erros  nas  estruturas de  dados e  funcionalidade fornecida pelo  componente.  A TDD  não  é  realm ente  um a  nova  tecnologia,  mas  sim  uma  tendência  que enfatiza o projeto de casos de teste antes da criação do código-fonte.
    O  processo  TDD  segue  o  fluxo  procedural  simples  ilustrado  na  Figura  31.3.  Antes  de  ser criado o primeiro segm ento de código,  um engenheiro de software cria um teste para exercitar o  código  (tentando  fazer o código falhar).  É  então rescrito o código p ara satisfazer ao teste.  Se passar, um novo teste é criado para o próximo segm ento de código a ser desenvolvido. O proces­so continua até que o com ponente esteja completajnente codificado e todos os testes executam sem erro.  No  entanto,  se algum  teste  conseguir  descobrir um erro,  o código existente é refeito (corrigido) e tod o s os testes criados até aquele ponto são executados novamente.  Esse fluxo ite­rativo continua até que não haja mais teste a ser criado,  implicando que o componente satisfaz a todos o s requisitos definidos para ele.
    Durante o TDD,  o código  é desenvolvido em  inprementos  muito  p eq uenos  (uma  subfunção de  cada vez),  e  nenhum  código  é  escrito  enquantej)  n ão  houver um  teste p ara  experimentá-lo. Você  deve observar que cada iteração  resulta em um ou mais novos testes que são acrescen ta­dos a um conjunto de testes de regressão que roda to m cada mudança.  Isso é feito para garantir que o novo código não ten h a gerado efeitos colaterais que causam erros no código anterior.
  • Questão mal formulada.... a questão não diz que o teste deve vir antes ou não... 


    Apenas diz que as funcionalidades devem estar completas e testadas da forma como serão apresentadas aos seus usuários para serem consideradas corretas.

  • Assertiva ERRADA. 


    Desabafo: o pessoal comenta, comenta, comenta, comenta, comenta, comenta, comenta, critica a banca, critica a redação da questão, e apontar o erro que é bom, nada. 

    O erro está em dizer que o código deve estar pronto quando vai ser testado, sendo que depois dos testes o TDD determina que seja feito o refactor do código, de modo a deixá-lo mais otimizado. Sendo assim o código pode ser modificado mesmo depois de passar nos testes. 
  • e-

    no test-driven development, tests vêem antes


ID
961396
Banca
Marinha
Órgão
Quadro Técnico
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

A modelagem é uma parte central de todas as atividades que levam à implementação de um bom software. Dentre as opções apresentadas, assinale aquela que NÃO apresenta um dos objetivos da modelagem.

Alternativas
Comentários
  • De acordo com Booch, Rumbaugh e Jacobson [1], há quatro objetivos principais para se criar modelos:

     

    1. Eles ajudam a visualizar o sistema como ele é ou como desejamos que ele seja;

    2. Eles permitem especificar a estrutura ou o comportamento de um sistema;

    3. Eles proporcionam um guia para a construção do sistema;

    4. Eles documentam as decisões tomadas no projeto.


ID
977692
Banca
FUNRIO
Órgão
MPOG
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

Considere o seguinte problema encontrado em projetos de desenvolvimento de software:
“Projetos reais raramente seguem um fluxo sequencial. Apesar de um modelo linear poder acomodar a iteração, ele o faz indiretamente. Como resultado, as modificações podem causar confusão à medida que a equipe de projeto prossegue.” Esse é um dos problemas que são algumas vezes encontrados quando é aplicado o modelo de desenvolvimento

Alternativas
Comentários
  • Letra a)

    O modelo em cascata move-se para a próxima fase somente quando a fase anterior está 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.

  • Letra A sem dúvida! Texto retirado da página 39 da sexta edição do livro de Roger S. Pressman.
  • Modelo cascata tem como característica, requisitos estáveis e bem definidos, não aceitando mudanças ao longo do projeto.

  • No modelo CASCATA é necessário que os requisitos estejam bem definidos, alterações no projeto pode representar um estouro no orçamento e no cronograma.


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

Com relação à engenharia de software, julgue os itens seguintes.

A abordagem iterativa e a incremental compõem o desenvolvimento em fases. Na primeira, o sistema é dividido em subsistemas por funcionalidades, adicionando-se mais funcionalidades a cada versão; na segunda, o sistema é entregue completo e muda a funcionalidade a cada nova versão

Alternativas
Comentários
  • Conceitos invertidos.

  • cespe adora inverter conceitos


    Está na dúvida? Chuta errada que a probabilidade de estar invertida é alta!

  • Caros, vamos com calma. A questão está ERRADA, porém os conceitos não estão invertidos:

     Se fosse a sentença abaixo estaria correta: "Na primeira (abordagem iterativa), o sistema é entregue completo e muda a funcionalidade a cada nova versão; na segunda (abordagem incremental), o sistema é dividido em subsistemas por funcionalidades, adicionando-se mais funcionalidades a cada versão"! O que é falso, vejamos o motivo: Com a inversão, o conceito da abordagem incremental está realmente correto! Porém, dizer que na abordagem iterativa o sistema é entregue completo e muda a funcionalidade a cada nova versão está ERRADO! Imagina que em uma aborgadem iterativa o sistema é entregue completo! Nessa abordagem divide-se o desenvolvimento do projeto em iterações menores, e colhe-se feedback ao final de cada iteração para melhoria geral do processo.

    Na verdade a questão está errada, por vários outros motivos. Vejamos:

    1. A abordagem iterativa e a incremental compõem o desenvolvimento em fases. ERRADO: Nada a ver, pode-se ter um desenvolvimento por fases sem ser composto por uma abordagem iterativa e incremental. Por exemplo, o modelo cascata que é linear e por fases e não tem NADA de iterativo e incremental. 

    2. O conceito de iterativo não foi passado corretamente por nenhuma das 2 (duas) definições da questão. O correto é o que está sublinhado no texto posto acima!

    Espero ter ajudado!

  • Perfeito Sergio, o que eu mais vejo aqui no site é a galera reclamando de banca, de questão, etc.... 90% das vezes (ou mais) o que está faltando é estudo.... :)


  • Iterações desenvolvem o produto através de uma série de ciclos repetidos, enquanto os incrementos sucessivamente acrescentam à funcionalidade do produto.


    Fonte: http://c2.com/cgi/wiki?IterativeVsIncremental

  • Só marquei errada porque a questão fala:


    "o sistema é entregue completo e muda a funcionalidade a cada nova versão"



    Se é LOUCO!??!?!!, você entrega o sistema completo e funcionando certinho, ai o cliente quer que fica mudando as funcionalidades.. nem a pau Juvenal.


    Se quiser pagar e acrescentar funcionalidades, tudo bem, mas você vai desenvolvendo módulo por módulo, validando com o cliente e no final quando entrega ele quer mudar o que já foi ¬¬

  • Conceitos invertidos.

    A abordagem iterativa (incremental) e a incremental (iterativa) compõem o desenvolvimento em fases. Na primeira, o sistema é dividido em subsistemas por funcionalidades, adicionando-se mais funcionalidades a cada versão; na segunda, o sistema é entregue completo e muda a funcionalidade a cada nova versão


ID
1035307
Banca
CESPE / CEBRASPE
Órgão
PEFOCE
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

A respeito de metodologias de desenvolvimento de sistemas e suas técnicas, julgue os itens subsecutivos.

Na análise estruturada de sistemas, o fato de o analista verificar que é indispensável representar as relações entre terminadores (entidades externas) indica que as entidades não são realmente externas, mas partes do sistema, e devem ser modeladas como processos.

Alternativas

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

Quanto a metodologias de desenvolvimento de software, julgue os seguintes itens.

A análise orientada a objetos, o projeto orientado a objetos e a programação orientada a objetos compreendem atividades de engenharia de software voltadas à construção de sistemas orientados a objetos. Nesses sistemas, objetos interagem para prover serviços. No nível de programação, as interações ocorrem via interfaces das classes das quais os objetos são instâncias. Essas interfaces contêm membros públicos das classes.

Alternativas
Comentários
  • As interfaces são visualizações programadas para o usuário, as interações ocorrem através de instanciações de objetos, em que uma classe chama a outra, obtendo as interfaces que são públicas para o usuário final. 

  • Alguém poderia ajudar? Entendo que a questão tem um erro: as interações ocorrem via interfaces das classes das quais os objetos são instâncias.

     

    As interações entre objetos não ocorrem por meio de mensagens?


ID
1049461
Banca
FCC
Órgão
AL-RN
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

Metodologias estruturadas podem ser utilizadas para documentar, analisar e projetar sistemas de informação. Quando se utiliza essas metodologias, a ferramenta primária para representar os processos componentes de um sistema e as interfaces entre eles é o Diagrama de

Alternativas
Comentários
  • O diagrama de fluxo de dados (DFD) é uma representação gráfica do "fluxo" de dados através de um sistema de informação, modelando seus aspectos de processo.


    https://pt.wikipedia.org/wiki/Diagrama_de_fluxo_de_dados


  • O Diagrama de Fluxo de Dados (DFD) é uma das principais ferramentas utilizadas no projeto de sistemas de informação. O DFD é um diagrama gráfico, baseado apenas em quatro símbolos, que mostra a estrutura do sistema e sua fronteira, ou seja, todas as relações entre os dados, os processos que transformam esses dados e o limite entre o que pertence ao sistema e o que está fora dele.

     

    DFD é uma representação em rede dos processos (funções) do sistema e dos dados que ligam esses processos. Ele mostra o que o sistema faz e não como é feito. É a ferramenta de demonstração central da análise estruturada.

     

    Um DFD apresenta as partes componentes de um sistema e as interfaces entre elas. É um conjunto integrado de procedimentos, sendo que as partes do computador poderão estar inseridos ou não.


ID
1049464
Banca
FCC
Órgão
AL-RN
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

Há diversos métodos que podem ser utilizados na construção de sistemas de informação. Sobre eles, analise:

I. O desenvolvimento é feito em estágios formais, que devem evoluir em sequência e ter resultados definidos. Cada um precisa ser formalmente aprovado antes que o próximo se inicie. É indicado para grandes projetos que exijam especificações formais e rígido controle administrativo sobre cada estágio do desenvolvimento.

II. Consiste em desenvolver um sistema experimental de maneira rápida e barata para que os usuários finais interajam com ele e o avaliem. Esse sistema é refinado e aperfeiçoado até que os usuários sintam que ele atende às suas necessidades, podendo ser usado como modelo para criar o sistema final.

Os itens I e II referem-se, respectivamente,

Alternativas
Comentários
  • O ciclo de vida de desenvolvimento de sistemas (CVDS), do inglês systems development life cycle (SDLC), em engenharia de sistemas, sistemas de informação e engenharia de software, é um processo de criação ou alteração de sistemas de informação,[1] e os modelos e metodologias que as pessoas utilizam para desenvolver esses sistemas. Em engenharia da computação, o conceito de SDLC sustenta muitos tipos de metodologias de desenvolvimento de software. Estas metodologias formam a estrutura (framework) para o planejamento e controle da criação de um sistema de informação:[2] o processo de desenvolvimento de software.

     

    https://pt.wikipedia.org/wiki/Ciclo_de_vida_de_desenvolvimento_de_sistemas

     

     

     

    Prototipagem:

    Usado quando o cliente não define requisitos para funções e recursos detalhamente

     

    Em outros casos, o desenvolvedor encontra-se seguro quanto à eficiência do um algoritmo.

    Paradigmas:

     

    -Construção de um protótipo

     

    -Modelagem projeto rápido

     

    -Projeto rápido

     

    -Comunicação

     

    -Emprego entrega e realimentação

     

    Pressman

     

     

    Letra A

     

     

    Qcom - Questão comentada

    https://www.youtube.com/channel/UCBY27FNGgRpPa-PgFubwjPQ


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

Com relação a engenharia de software, julgue os itens que se seguem.

Métodos de engenharia de software definem a abordagem que é adotada quando o software é elaborado.

Alternativas
Comentários
  • ERRADA - A elaboração de software já é parte constituinte de um tipo de abordagem em engenharia de software. A abordagem genérica de "Planejamento"(ou elaboração) por exemplo, está presente em diversos tipos de abordagem, seja nos processos ágeis, evolutivos, etc...

  • e-

    processo de software - atividades, métodos e ferramentas que orientam equipes para produtividade e qualidade.

     

    métodos -como fazer o projeto

    ferramentas - como automatizar os métodos

    -procedimentos - padrão de desenvolvimento de como a ferramenta executa os métodos
    como guia


ID
1098025
Banca
IADES
Órgão
TRE-PA
Ano
2014
Provas
Disciplina
Engenharia de Software
Assuntos

Na área de engenharia de software, há dois métodos de desenvolvimento de sistemas, chamados Catedral e Bazar. Essa descrição foi inicialmente lançada como um debate e crítica aos métodos de desenvolvimento de softwares livres e hoje é utilizada para descrever modelos de gestão de desenvolvimento em sentido amplo. Assinale a alternativa correta quanto aos dois métodos de desenvolvimento de software.

Alternativas
Comentários
  • O modelo Catedral, no qual o código fonte está disponível para cada release do software, mas o código desenvolvido entre dois releases é restrito a um exclusivo grupo de desenvolvedores. Os projetos Emacs e GCC são apresentados no ensaio como exemplos.

    O modelo Bazar, no qual o código é desenvolvido de forma totalmente aberta e pública, utilizando a Internet. Raymond credita Linus Torvalds, líder do projeto Linux, como o inventor deste modelo de desenvolvimento de software. Ele também fornece alguns relatos anedóticos da aplicação desse modelo ao projeto Fetchmail

  • Modelos de Gestão: Catedral e BAZAR

    Não existe uma formalização acadêmica sobre os modelos bazar e catedral. Esta foi apenas uma metáfora abordada por Eric S. Raymond em um artigo que ele escreveu analisando a estratégia de desenvolvimento de Linus Torvalds.

    Um dos focos importantes é que o modelo Catedral é o modelo tradicional, robusto de desenvolvimento de softwares, no qual entregas de valor são realizadas após longas iterações de desenvolvimento. Neste modelo, erros são complexos e profundos e são descobertos como uma surpresa infeliz pelo usuário, trazendo insatisfação pela inviabilização do uso do sistema.

    O modelo Catedral, no qual o código fonte está disponível para cada release do software, mas o código desenvolvido entre dois releases é restrito a um exclusivo grupo de desenvolvedores. Os projetos Emacs e GCC são apresentados no ensaio como exemplos.

    O modelo Bazar enfatiza o conceito "Libere cedo, libere freqüentemente", por meio do qual os erros se tornam triviais e de fácil manutenção, pelo fato de vários "testadores" estarem analisando o software em curtos períodos de tempo. Este modelo também se baseia no efeito Delphi, no qual sociologistas descobriram que a opinião média de uma massa de observadores especialistas (ou igualmente ignorantes) é um indicador mais seguro que o de um único observador escolhido aleatoriamente.

    O modelo Bazar, no qual o código é desenvolvido de forma totalmente aberta e pública, utilizando a Internet. Raymond credita Linus Torvalds, líder do projeto Linux, como o inventor deste modelo de desenvolvimento de software. Ele também fornece alguns relatos anedóticos da aplicação desse modelo ao projeto Fetchmail.

  • Qual o erro da D?

ID
1101346
Banca
UNIRIO
Órgão
UNIRIO
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

Um processo de software é um conjunto de atividades e resultados associados que levam à produção de um produto de software. Embora existam muitos processos ou paradigmas de software diferentes, há atividades fundamentais comuns a todos eles. São exemplos dessas atividades:

Alternativas

ID
1122043
Banca
FCC
Órgão
SABESP
Ano
2014
Provas
Disciplina
Engenharia de Software
Assuntos

Um processo de engenharia de software é formado por um conjunto de passos parcialmente ordenados, relacionados com artefatos, pessoas, recursos, estruturas organizacionais e restrições, tendo como objetivo produzir e manter os produtos de software finais requeridos. Sobre estes processos é INCORRETO afirmar que

Alternativas
Comentários
  • O modelo em cascata é um exemplo de modelo sequencial e linear, invalidando assim a afirmativa de que “todos os modelos de processo têm fases cíclicas”.


ID
1128616
Banca
CS-UFG
Órgão
UEAP
Ano
2014
Provas
Disciplina
Engenharia de Software
Assuntos

No modelo espiral de Boehm, o processo de software é representado como uma espiral e não como uma sequência de atividades com retornos de uma para outra. O modelo espiral de Boehm é

Alternativas
Comentários
  • Falou  em modelo espiral falou em Riscos 

     

  • o MODELO espiral é um FRAMEWORK??? Complicado hein...

  • a) C.

    b) E. São 4 setores:

    c) E. Como ele é um modelo evolucionário, está apto a trabalhar com mudanças.

    d) E. Ao contrário, a fase mais interna é que define o início do projeto.


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

Assinale a alternativa correta sobre o processo de validação do software.

Alternativas
Comentários
  • Somente - Através dessa palavra, analisando as alternativas, é possível eliminar as letras d e  e.

    As letras a e b não tem nada ver com o enunciado.

     

    Só sobra a letra C !

  • Conceitos importantes de de Eng. de Software que muitas vezes se confundem.

    Verificação - Fizemos o software corretamente?

    A verificação tem como objetivo avaliar se o que foi planejado realmente foi realizado.

    Validação - Fizemos o software correto?

    Já a validação tem o objetivo de avaliar se o que foi entregue atende as expectativas do cliente.

    Dessa forma, a que mais se aproxima a resposta correta é a letra C.

    Gabarito C


ID
1153834
Banca
INSTITUTO AOCP
Órgão
UFGD
Ano
2014
Provas
Disciplina
Engenharia de Software
Assuntos

Sobre Modelos de Processo de Software, assinale a alternativa INCORRETA.

Alternativas
Comentários
  • As atividades do processo incremental são:  Requisitos, Projeto, Implementação, Testes, Implantação e Manutenção.

  •  a) O modelo de desenvolvimento incremental considera atividades fundamentais do processo de especificação, desenvolvimento, validação e evolução.

  • Alguém comenta a letra C??

    Nao entendi o que ele quis dizer com: "..... portanto, fornece informações parciais sobre ele....."

     

    Não seriam informações completas do processo???


ID
1153858
Banca
INSTITUTO AOCP
Órgão
UFGD
Ano
2014
Provas
Disciplina
Engenharia de Software
Assuntos

Sobre Entrega Incremental, assinale a alternativa INCORRETA.

Alternativas
Comentários
  • RESPOSTA 

    b) Uma das desvantagens deste modelo é que os clientes podem usar incrementos iniciais como protótipos e ganhar experiência, a qual informa seus requisitos para posteriores incrementos do sistema.

  • GABARITO B

     

    B) Uma das VANTAGENS deste modelo é que os clientes podem usar incrementos iniciais como protótipos e ganhar experiência, a qual informa seus requisitos para posteriores incrementos do sistema.


ID
1155904
Banca
FJPF
Órgão
CONAB
Ano
2006
Provas
Disciplina
Engenharia de Software
Assuntos

O modelo de processo de desenvolvimento de software incremental que enfatiza um ciclo de desenvolvimento extremamente curto, que compreende as fases de modelagem do negócio, modelagem dos dados, modelagem do processo, geração da aplicação, além de teste e entrega, e que o desenvolvimento é conseguido pelo uso de construção baseada em componentes, é conhecido como modelo:

Alternativas
Comentários
  • b-

    RAD foi criado em 1990 por James Martin. É um processo incremental mais curto de desenvolvimento entre as etapas de modelagem e codigo, em até 90 dias. O planejamento é essencial, várias equipes trabalham em paralelo. Possui as fases de comunicação, planejamento, diversos incrementos durante a modelagem e construção com uso de componentes de software e concluído na implantação do sistema.


ID
1175965
Banca
CESPE / CEBRASPE
Órgão
TC-DF
Ano
2014
Provas
Disciplina
Engenharia de Software
Assuntos

Acerca das metodologias de desenvolvimento de software, julgue os itens subsecutivos.

Um protótipo de sistema auxilia na validação de requisitos, no projeto de interface com o usuário, podendo, ainda, ser usado para a realização de testes.

Alternativas
Comentários
  • A prototipagem é utilizada quando não se conhece bem os requisitos e ainda 

    Pode ser protótipo evolucionário ou descartável

  • Pessoal, alguém encontrou nas bibliografias renomadas referência sobre testes utilizando protótipos? 

    Achei o link abaixo afirmando isso mas sem muita explicação:

    http://thiagonasc.com/desenvolvimento-web/a-importancia-dos-prototipos-no-desenvolvimento-de-sistemas

    Não concordo que protótipos possam ser utilizados para realizar testes, segue o que li em Pressman, Eng.Software, 6ª Edição:

    p.42: "Idealmente, o protótipo serve como um mecanismo para identificação dos requisitos do software."  (e não para verificação e validação dinâmica no caso)... pois:

    p.43: "... a prototipagem pode ser problemática pelas seguintes razões: 1. O cliente vê o que parece uma versão executável do software, ignorando que o protótipo apenas consiga funcionar precariamente..." (como vou executar testes, obtendo resultados confiáveis, em uma versão precária??)

    "... cliente e desenvolvedor devem estar de acordo que o protótipo é construído para servir como um mecanismo de definição dos requisitos." (e não para testes...)

    Eu errei a questão pois não havia lido sobre testes com protótipo, se alguém puder dar uma luz ai agradeço!! : )

  • É claro que o protótipo PODE ser usado nos testes, o que proíbe dele ser usado em testes de validação, por exemplo?

  • Mozart, você encontrou alguma referência renomada que afirme que os protótipos são utilizados em testes de validação? 

  • Sommerville, 9a edição, pg 77

    Existe uma série de técnicas de validação de requisitos que podem ser usadas individualmente ou em conjunto:

    Revisões de requisitos

    Prototipação: nessa abordagem para validação, um modelo executável do sistema em questão é demonstrado para os usuários finais e clientes. Estes podem experimentar o modelo para verificar se ele atende a suas reais necessidades

    Geração de casos de teste

  • já vi questões de múltiplas escolhas em que uma questão estava errada justamente por afirmar que protótipo validava requisitos, essa é a visão de Pressman. Na verdade sou a favor que a prototipação seja uma forma de validação de requisitos, faço isso inclusive.Concordo com Sommerville e com o Cespe.

  • Também fiquei na dúvida quanto a testes em protótipos, mas aí considerei o seguinte cenário:

    Na Prototipagem Evolucionária (https://pt.wikipedia.org/wiki/Modelos_ciclo_de_vida) existem dois submodelos:

    1 - modelo exploratório ou evolucionário - em que você não joga fora o protótipo, mas vai evoluindo ele.

    2 - throw-away / descartável - você joga fora o protótipo.

     

    No submodelo em que você não joga fora o protótipo é razoável considerar que você "pode" realizar testes nele, já que ele será evoluído para virar o produto final.

     

    Gabarito: Certo


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

NÃO é um tipo de ferramenta utilizado na técnica de desenvolvimento estruturado de sistemas:

Alternativas

ID
1234207
Banca
VUNESP
Órgão
PRODEST-ES
Ano
2014
Provas
Disciplina
Engenharia de Software
Assuntos

Assinale a alternativa que apresenta uma afirmação verdadeira sobre a documentação de software.

Alternativas

ID
1234210
Banca
VUNESP
Órgão
PRODEST-ES
Ano
2014
Provas
Disciplina
Engenharia de Software
Assuntos

Na escrita de um manual operacional de software, um dos métodos é composto de 4 etapas: I. Conhecer ou adquirir conhecimento do produto; II. Planejar a formatação final e executá-la; III. Redigir e conferir o texto; IV. Planejar a aparência e seções do manual.

A ordem correta de execução dessas quatro etapas é:

Alternativas
Comentários
  • Q quadro?

  • q quadro?


ID
1252174
Banca
CESPE / CEBRASPE
Órgão
TRT - 17ª Região (ES)
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

Acerca de conceitos, ciclos de vida e testes de software, julgue o item que se seguem.

Uma das desvantagens atribuídas ao modelo do desenvolvimento rápido de aplicação consiste na exigência da dedicação total do cliente e de desenvolvedores para a execução de tarefas constantes em um curto período de tempo.

Alternativas
Comentários
    • Desvantagens:
    • Se uma aplicação não puder ser modularizada de modo que cada função principal seja completada em menos de 3 meses, não é aconselhável o uso do RAD;
    • Para projetos grandes (mas escaláveis) o RAD exige recursos humanos suficientes para criar o número correto de equipes, isso implica um alto custo com a equipe;
    • O envolvimento com o usuário tem que ser ativo;
    • Comprometimento da equipe do projeto;
    • O RAD não é aconselhável quando os riscos técnicos são altos e não é indicada quando se está testando novas tecnologias ou quando o novo software exige alto grau de interoperabilidade com programas de computador existentes. Falta de prazo pode implicar qualidade reduzida, e há necessidade de habilidade maior dos desenvolvedores, e suporte maior da gerência e dos clientes.
    • Desenvolver pode economizar recursos se comparado a comprar;
    • Custo do conjunto de ferramentas e hardware para rodar a aplicação;
    • Mais difícil de acompanhar o projeto(pois não existe os marcos clássicos);
    • Menos eficientes;
    • Perda de precisão científica (falta de métodos formais);
    • Pode acidentalmente levar ao retorno das práticas caóticas no desenvolvimento;
    • Funções reduzidas (reuso, "timeboxing");
    • Funções desnecessárias (reuso de componentes);
    • Problemas legais;
    • Requisitos podem não se encaixar (conflitos entre desenvolvedores e clientes)
    • Padronização (aparência diferente entre os módulos e componentes)
    • Sucessos anteriores são difíceis de se reproduzir

  • Confundi com o XP e errei.


    Realemente o RAD não exige dedicação completa do cliente, pois é baseado em uma adaptação do modelo Cascata de alta velocidade que incorpora implementação baseada em componentes.

  • Questão inicialmente CERTA, sendo posteriormente alterado o gabarito para ERRADA.

    Motivo: O uso do termo “dedicação total” tornou incorreta afirmação feita no item. Dessa forma, opta-se pela alteração do gabarito.

     

    http://www.cespe.unb.br/concursos/TRT17_13/arquivos/TRT17_13_JUSTIFICATIVAS_DE_ALTERA____ES_DE_GABARITO.PDF


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

Com relação à gestão de requisitos e de configuração, julgue os itens subsequentes.

Nos processos iterativos de desenvolvimento de software, o tratamento de mudanças em requisitos deve ser priorizado com a realização de um processo formal de gerenciamento de mudanças.

Alternativas
Comentários
  • Alguém sabe justifica-la?

  • Os passos fundamentais do processo estão em iniciar o desenvolvimento com um subconjunto simples de Requisitos de Software e iterativamente alcançar evoluções subsequentes das versões até o sistema todo estar implementado. A cada iteração, as modificações de projeto são feitas e novas funcionalidades são adicionadas.

    Não há necessidade de formalismo, o processo é simples envolve construções modulares e várias validações; o que permite identificar mudanças em requisitos rapidamente e tratá-las sem grandes impactos.


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

  • A frase "Nos processos iterativos de desenvolvimento de software (...)" matou a questão porque generalizou. Por exemplo, o XP é Iterativo, mas não requer um processo formal de tratamento de mudanças! E mesmo se pensar no RUP, onde existe a disciplina Gestão de Configuração e Mudança, ela pode ser excluída do processo se o Engenheiro de Processos achar necessário. Questão errada.

  • 2015
    As mudanças de requisitos em processos ágeis de desenvolvimento não seguem um processo formal de gerenciamento de requisitos.

    certa


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

Com relação à gestão de requisitos e de configuração, julgue os itens subsequentes.

No processo tradicional de desenvolvimento em cascata, a gestão de configuração começa a atuar no momento em que todos os testes são concluídos.

Alternativas
Comentários
  • Não encontrei na literatura o processo gestão de configuração no Modelo em Cascata.

  • Em outras palavras, a Gerência de Configuração de Software tem como objetivo responder as seguintes perguntas:

    • O que mudou e quando?
    • Por que mudou?
    • Quem fez a mudança?
    • Podemos reproduzir esta mudança?

    Cada uma dessas perguntas corresponde a uma das atividades realizadas pela Gerência de Configuração de Software. O controle de versão é capaz de dizer o que mudou e quando mudou. O controle de mudanças é capaz de atribuir os motivos a cada uma das mudanças. A Auditoria por sua vez responde as duas últimas perguntas: Quem fez a mudança e podemos reproduzir a mudança?


    Antes de você testar e até mesmo de construir, alguém precisa autorizar a mudança com base na avaliação do impacto e dos riscos. É preciso controlar as mudanças pela identificação dos produtos do trabalho que serão alterados.


    http://pt.wikipedia.org/wiki/Ger%C3%AAncia_de_configura%C3%A7%C3%A3o_de_software

  • De acordo com PRESSMAN, "Gestão de configuração é um conjunto de atividades de rastreamento e controle
    iniciadas quando um projeto de engenharia começa e termina apenas quando o software sai de operação."


    Fonte: Engenharia de Software, PRESSMAN, 7ed.


ID
1360378
Banca
CESGRANRIO
Órgão
Petrobras
Ano
2014
Provas
Disciplina
Engenharia de Software
Assuntos

Um técnico de informática, com o objetivo de agilizar o desenvolvimento de um software, escolheu o desenvolvimento evolucionário, uma abordagem da área de Engeharia de Software, que

Alternativas
Comentários
  • O modelo de desenvolvimento evolucionário intercala as atividades de especificação, desenvolvimento e validação. Um sistema inicial é desenvolvido rapidamente baseado em especificações abstratas. Este sistema é, então, refinado com as entradas do usuário para produzir um sistema que satisfaça suas necessidades. Esta abordagem é mais eficaz do que a abordagem em cascata na produção de sistemas que atendam às necessidades imediatas dos usuários. A vantagem de um processo de software baseado na abordagem evolucionária é que a especificação pode ser desenvolvida de forma incremental. À medida que os usuários compreendem melhor seu problema, esse conhecimento é repassado para o desenvolvimento do software (SOMMERVILLE, 2007).

    Leia mais em: Processos de Software http://www.devmedia.com.br/processos-de-software/21977#ixzz3QXiP6Fb3

  • Essa o Somerville pisou na bola... especificações abstratas ninguém merece

  • acho que está na moda cobrar isso

     

    2016

    Um modelo de desenvolvimento de software intercala as atividades de especificação, desenvolvimento e validação. Ele permite desenvolver rapidamente um sistema inicial a partir de especificações abstratas, que são então refinadas com informações do cliente, para produzir um sistema que atenda suas necessidades. Esse modelo é conhecido como desenvolvimento

     a) em espiral.

     b) em cascata.

     c) evolucionário.

     d) formal de sistemas.

     e) orientado a reuso.


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

A respeito de engenharia de software, julgue os itens de 91 a 100.

Segundo o SWEBOK, o processo de projeto de software geralmente considera duas etapas: projeto arquitetural, no qual é descrito como o software é decomposto e organizado em componentes; e o detalhamento do projeto, em que é descrito e especificado o comportamento desses componentes.

Alternativas

ID
1392151
Banca
FCC
Órgão
Câmara Municipal de São Paulo - SP
Ano
2014
Provas
Disciplina
Engenharia de Software
Assuntos

O desenvolvimento de uma solução para um sistema de informação baseia-se no processo de resolução de problemas. Esse processo pode ser descrito em quatro passos:

1. Definição e entendimento do problema.
2. Desenvolvimento de soluções alternativas.
3. Escolha da melhor solução.
4. Implementação da solução.

A seguir são descritas três atividades que ocorrem neste processo:

I. Define cuidadosamente os objetivos do sistema modificado ou do novo sistema e desenvolve uma descrição detalhada das funções que um novo sistema deve desempenhar.

II. Define se cada alternativa de solução é um bom investimento, se a tecnologia necessária para o sistema está disponível e pode ser administrada pela equipe designada da empresa, e se a organização é capaz de acomodar as mudanças introduzidas pelo sistema.

III. É a “planta” ou modelo para a solução de um sistema de informação e consiste em todas as especificações que executarão as funções identificadas durante a análise de sistemas. Essas especificações devem abordar todos os componentes organizacionais, tecnológicos e humanos da solução.

A associação correta das atividades I, II e III aos passos ao qual pertencem no processo de resolução de problemas está, correta e respectivamente, apresentada em

Alternativas
Comentários
  • Letra E.

    Os itens descritos correspondem a:

    Análise de Requisitos;

    Estudo de Viabilidade;

    Projeto de sistema.


ID
1404493
Banca
FGV
Órgão
PROCEMPA
Ano
2014
Provas
Disciplina
Engenharia de Software
Assuntos

Com relação às metodologias de desenvolvimento de projetos de software, analise as afirmativas a seguir:

I. Scrum permite a construção de software incrementalmente por meio de iterações curtas para promover visibilidade para o desenvolvimento e pressupõem equipes pequenas, requisitos pouco estáveis ou desconhecidos.

II. Feature Driven Development (FDD) suporta o desenvolvimento ágil com rápidas adaptações às mudanças de requisitos focados nas fases de desenho e construção de projeto de software.

III. Kanban considera a utilização de uma sinalização ou registro visual para gerenciar o limite de atividades em andamento, indicando se um novo trabalho pode ou não ser iniciado e se o limite acordado para cada fase está sendo respeitado.

Assinale:

Alternativas
Comentários
  • I. Errada. Acredito que no Scrum os requisitos são mais definidos pois temos o product backlog; Essa definição tá mais para o XP; 

    II. Errada. FDD tem o seu próprio processo e fases; 

    III. Certo. No Kanban é só lembrarmos das sinalizações e WIP ( work in progress );
  • Não escutem o cara abaixo... =D

  • Lendo estes artigos sobre metodologias FDD, SCRUM e Kanbam, ja da pra responder facil essa questao

    http://www.desenvolvimentoagil.com.br/scrum/

    http://imasters.com.br/artigo/7396/gerencia/um_cardapio_de_metodologias_ageis/

    http://www.brq.com/metodologias-ageis/

  • Concordo plenamente com o Luciano.

  • Colegas, por favor...

     

    O Backlog do Produto pode ser refinado a todo momento, as reuniões de revisões preconizam mudanças nesse artefato. Os itens de Backlog do Produto que não são elencados como prioritários pelo Product Owner para a próxima Sprint, sequer precisam ter seus requisitos detalhados e, ao detalhar, podem ser aperfeiçoados ou, até mesmo, retirados do Backlog do Produto. O único compromisso que o P.O. assume com o Scrum Master e Scrum Team é de não inserir ou modificar algum item do Backlog da Sprint. De resto, colegas, tudo pode mudar, ou seja, "requisitos pouco estáveis ou" até mesmo "desconhecidos" (inclusive por todos).

     

    Em relação ao FDD: sim, possui seus próprios estágios e processos, mas isso de nada impede que seja aplicado um modelo ágil. Aplicar FDD indica que estaremos nos orientando por funcionalidades (no XP, por exemplo, o FDD nos dá o tom da medida/intensidade/frequência em que vamos convocar os clientes para participação). Só nunca tinha visto ninguém chamar a etapa de Concepção e Planejamento de Desenho, mas como não havia a opção I e III corretas, isso não foi importante e, na minha interpretação, não comprometeu o gabarito.


ID
1460191
Banca
FCC
Órgão
CNMP
Ano
2015
Provas
Disciplina
Engenharia de Software
Assuntos

Baseando-se na premissa de que se o código fonte estiver disponível para teste e experimentação pública, então os eventuais erros serão descobertos mais rapidamente, foram desenvolvidos modelos de desenvolvimento de software e gestão de projetos, sobre os quais é correto afirmar:

Alternativas
Comentários
  • E a majestosa Fundação Copia e Cola mais uma vez tirando o conteúdo da Wikipedia: http://pt.wikipedia.org/wiki/A_Catedral_e_o_Bazar


    Os conceitos estão invertidos nas alternativas sobre os modelos Catedral e Bazar e a letra D é absurda. Alternativa correta letra A.

  • Com o detalhe que de o PMBOK não é uma 'norma'. Ou seja, não tem correta.

  • Definição de Catedral e Bazar O modelo Catedral, no qual o código fonte está disponível para cada release do software, mas o código desenvolvido entre dois releases é restrito a um grupo de desenvolvedoresexclusivo. Os projetos Emacs e GCC são apresentados no ensaio como exemplos. O modelo Bazar, no qual o código é desenvolvido de forma totalmente aberta e pública, utilizando a Internet. Raymond credita Linus Torvalds, líder do projeto Linux, como o inventor deste modelo de desenvolvimento de software. Ele também fornece alguns relatos anedóticos da aplicação desse modelo ao projeto Fetchmail.

  • WTF?


ID
1523653
Banca
FEMPERJ
Órgão
TCE-RJ
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

Observe a lista de “princípios” a seguir, associados às metodologias de desenvolvimento de software.

I. Cooperação constante entre pessoas que entendem do ‘negócio’ e desenvolvedores;
II. Simplicidade;
III. Software funcional mais do que documentação extensa;
IV. Documentação extensa mais do que Software funcional;
V. Responder a mudanças mais do que seguir um plano;
VI. Etapas, artefatos e requisitos minuciosamente planejados de antemão;
VII. Equipes de desenvolvedores com um grande número de pessoas;
VIII. Equipes de desenvolvedores com um pequeno número de pessoas.

A lista que contém apenas princípios característicos dos métodos ágeis é:

Alternativas
Comentários
  • II. Simplicidade; 
    III. Software funcional mais do que documentação extensa; 
    V. Responder a mudanças mais do que seguir um plano; 
    VIII. Equipes de desenvolvedores com um pequeno número de pessoas.

  • Embora eu tenha acertado a questão, não entendo o motivo dos itens I e II terem sido descartados do cenário de metodologia ágil:

     

    I - Isso não é a caracterísitca do cliente sempre presente? (Conscientes disso, aqueles que trabalham com XP priorizam o uso do diálogo presencial, com o objetivo de garantir que todas as partes envolvidas em um projeto tenham a chance de se compreender da melhor maneira possível) Fonte: http://www.desenvolvimentoagil.com.br/xp/valores/comunicacao

    II - Conceito de projeto simples? (O XP utiliza o conceito de simplicidade em inúmeros aspectos do projeto para assegurar que a equipe se concentre em fazer, primeiro, apenas aquilo que é claramente necessário e evite fazer o que poderia vir a ser necessário, mas ainda não se provou essencial.) Fonte: http://www.desenvolvimentoagil.com.br/xp/valores/simplicidade

     

    O que acham?

  • Não entendi a I não estar certa.

  • Prezados,

    A questão pede os princípios que se aplicam apenas aos métodos ágeis.

    O item I está errado. Tal cooperação não é uma exclusividade dos métodos ágeis.
    O item II está correto.
    O item III está correto.
    O item IV está errado. Documentação extensa não é principio ágil.
    O item V está correto.
    O item VI está errado, pois não há planejamento minucioso em métodos ágeis. 
    O item VII está errado, as equipes ágeis são menores e auto gerenciáveis.
    O item VIII está correto.

    Portanto a alternativa correta é a letra C.


ID
1544479
Banca
Prefeitura do Rio de Janeiro - RJ
Órgão
Câmara Municipal do Rio de Janeiro
Ano
2014
Provas
Disciplina
Engenharia de Software
Assuntos

Considere as afirmativas que seguem, relacionadas com processos de desenvolvimento de software.

I - Pequenas equipes de trabalho são organizadas de modo a minimizar a comunicação, maximizar a supervisão e minimizar o compartilhamento de conhecimento tácito informal.

II - O trabalho de desenvolvimento e o pessoal que o realiza é dividido em partições claras, de baixo acoplamento, ou em pacotes.

III - O processo produz frequentes incrementos de software que podem ser inspecionados, ajustados, testados, documentados e expandidos.

IV - Os testes são realizados e a documentação elaborada somente após o produto final ter sido construído.

As afirmativas que estão de acordo com os princípios SCRUM e consistentes com a política de desenvolvimento ágil são:

Alternativas

ID
1555786
Banca
Quadrix
Órgão
CFA
Ano
2015
Provas
Disciplina
Engenharia de Software
Assuntos

Assinale a metodologia de desenvolvimento de sistemas que é marcada pela construção de modelos que retratam o fluxo de informações e divisão em camadas.

Alternativas
Comentários
  • A questão está se referindo ao DFD.

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

Acerca de integração contínua e entrega contínua, julgue o próximo item.

Na gerência de um pipeline de implantação (deployment pipeline), recomenda-se que o código-fonte seja compilado repetidas vezes em contextos diferentes: durante o estágio de commit, nos testes de aceitação, nos testes de capacidade e nos testes exploratórios.

Alternativas
Comentários
  • ERRADO: A questão afirma que, em cada fase, recomenda-se que o código seja compilado.Vocês se lembram da figura apresentada em aula? Pois é, o código deve ser compilado todas as vezes em que falhar em alguma das fases, porque há o feedback e a correção. Caso não haja falha, não faz sentido compilar o código em cada fase.

    FONTE: https://www.estrategiaconcursos.com.br/blog/concurso-tcu-engenharia-de-software-e-desenvolvimento-de-sistemas/

  • Acrescento também que Testes Exploratórios não podem ser reproduzidos na Integração Contínua pois ele não seguem nenhum roteiro padrão. Testes de Aceitação até podem ser executados de forma automática, desde que acompanhado pelo usuário.

  • "Testes exploratórios [...] são impossíveis de automatizar." [1] página 87

    "Pipeline de implantação é, em essência, uma implementação automatizada do processo de compilar todas as partes de uma aplicação, implantá-la em uma ambiente qualquer, homologação ou produção, testá-la e efetuar sua entrega final." [1] página 111

    Para conhecimento:

    "O teste exploratório é, na sua definição mais básica, a criação e a execução ao mesmo tempo de um teste." [2]

    "Testes de exploração são descritos por James Bach como uma forma de teste manual em que o testador controla ativamente o projeto desses testes, já que eles são executados e usam informações coletadas durante os testes para confeccionar testes novos e melhoresTestes explorátorios são um processo de aprendizado criativo que não apenas descobre erros, mas também leva a criação de novos conjuentos de testes automatizados, e potencialmente novos requisitos para a aplicação." [1] página 90

    [1] Entrega Contínua: Como Entregar Software (Jez Humble, David Farley)
    https://books.google.com.br/books?id=CB04AgAAQBAJ&printsec=frontcover&source=gbs_ge_summary_r&cad=0#v=onepage&q&f=false

    [2] Testes Exploratórios de A a Z (Cristiano Caetano)
    http://www.linhadecodigo.com.br/artigo/1102/testes-exploratorios-de-a-a-z.aspx

  • Que aula Luiz Miguel ?????? ¬¬

    Segue link sobre Deployment Pipeline http://www.informit.com/articles/article.aspx?p=1621865&seqNum=2

    Resumindo, o erro esta nos testes exploratórios, no demais, apesar da redação não estar 100%, mas há as demais fases no deploy pipeline e creio que as repetidas vezes refere-se a novos incrementos de código, que resulta na necessidade de novas compilações.

  • Essa questão não deveria estar com a tag Arquitetura de Computadores.


ID
1660531
Banca
Quadrix
Órgão
COBRA Tecnologia S/A (BB)
Ano
2015
Provas
Disciplina
Engenharia de Software
Assuntos

As características listadas a seguir referem-se, preferencialmente, a qual modelo de desenvolvimento?

• Resultados úteis a cada duas semanas ou menos.
• Blocos pequenos de funcionalidade valorizada pelo cliente, chamados "Features".
• Planejamento detalhado e guia para medição.
• Rastreabilidade e relatórios com maior precisão.
• Monitoramento detalhado, com resumos para clientes e gerentes, em termos de negócio.
• Fornece uma forma de saber, dentro dos primeiros 10% de um projeto, se o plano e a estimativa são sólidos.

Alternativas
Comentários
  • O FDD (Desenvolvimento Guiado por Características) é algo mais "formal" do que outros métodos ágeis, mas ainda mantém agilidade por concentrar a equipe de projeto no desenvolvimento das características - funções valiosas para o cliente que podem ser implementadas em duas semanas ou menos. O FDD fornece maior ênfase em gestão de projeto e qualidade do que outras abordagens ágeis. 

    PRESSMAN, 2006.

  •  c)FDD. (feature driven development) usa features que sao implementadas a cada 2 semanas (ou menos). crataceristicas do FDD:

    a - features - pequenos blocos de funcionalidade para entregar 

    b - features organizados por hierarquia

    c - features a cada 2 semanas

    d - features sempre mantendo simplcidade

    e - planejamento, cronograma & monitoramento por hierarquia de features


ID
1707715
Banca
EXATUS
Órgão
BANPARÁ
Ano
2015
Provas
Disciplina
Engenharia de Software
Assuntos

Sobre metodologias de desenvolvimento de sistemas em Engenharia de software:

I - Métodos ágeis focam em simplicidade, software funcional no início das iterações, flexibilidade e intensa comunicação tanto internamente quanto com clientes.

II - Desenvolvimento incremental é uma estratégia de planejamento estagiado em que várias partes do sistema são desenvolvidas em paralelo, e integradas quando completas, enquanto que o desenvolvimento iterativo é uma estrategia de planejamento de retrabalho em que o tempo de revisão e melhorias de partes do sistema é pré-definido.

III - Princípios que regem as metodologias ágeis: Pessoas e interações, ao contrário de processos e ferramentas; Documentação extensa ao invés do sistema em funcionamento; Colaboração do cliente, ao contrário de constantes negociações de contratos; Respostas rápidas para as mudanças, ao contrário de seguir planos previamente definidos.

Está(ão) correta(s):

Alternativas
Comentários
  • Princípios do Manifesto Ágil:

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

    Fonte: http://www.manifestoagil.com.br/principios.html

    Manifesto Ágil:

    Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo. Através deste trabalho, passamos a valorizar:

    - Indivíduos e interação entre eles mais que processos e ferramentas
    - Software em funcionamento mais que documentação abrangente (Erro do item III)
    - Colaboração com o cliente mais que negociação de contratos
    - Responder a mudanças mais que seguir um plano

    Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.

    Fonte: http://www.manifestoagil.com.br/index.html

  • Modelo Evolucionário

    O software evolui ao longo do tempo e conforme o desenvolvimento deste software avança também temos mudanças nas necessidades de negócio e de produtos que mudam frequentemente. Isso torna inadequado seguirmos um planejamento em linha reta de um produto. Os modelos de processo evolucionário tornaram-se realidade para que possamos desenvolver um produto que evolua ao longo do tempo.


    Modelo Incremental

    O modelo de processo incremental entrega um produto operacional a cada incremento, ou seja, um produto sem erros e pronto para o usuário utilizar. Mesmo que os primeiros incrementos sejam partes do produto, essas partes são operacionais e funcionam sem as outras. Portanto, os incrementos possuem totais condições de atender ao usuário.


    Fonte: http://www.devmedia.com.br/introducao-aos-processos-de-software-e-o-modelo-incremental-e-evolucionario/29839

  • Desde quando o Desenvolvimento Incremental prega que as partes do sistemas devem ser desenvolvidas em paralelo?????

  • o desenvolvimento iterativo é uma estrategia de planejamento de retrabalho...

    Sério isso?

  • Desenvolvimento Iterativo e Incremental


    Desenvolvimento Incremental é uma estratégia de planejamento estagiado em que várias partes do sistema são desenvolvidas em paralelo, e integradas quando completas. Não implica, requer ou pressupõe desenvolvimento iterativo ou em cascata – ambos são estratégias de retrabalho. A alternativa ao desenvolvimento incremental é desenvolver todo o sistema com uma integração única.


    O 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. Uma diferença típica é que a saída de um incremento não é necessariamente assunto de um refinamento futuro, e seu teste ou retorno do usuário não é utilizado como entrada para planos de revisão ou especificações para incrementos sucessivos. Ao contrário, a saída de uma iteração é examinada para modificação, e especialmente para revisão dos objetivos das iterações sucessivas.

    FONTE: https://goo.gl/tBgpj5


ID
1740466
Banca
FCC
Órgão
TRE-AP
Ano
2015
Provas
Disciplina
Engenharia de Software
Assuntos

A fase de projeto de software possui duas atividades básicas: projeto da arquitetura e projeto detalhado. Nesta fase

Alternativas
Comentários
  • PROJETO

    O projeto possui duas atividades básicas: projeto da arquitetura (ou projeto de alto nível), e projeto detalhado (ou projeto de baixo nível).

     Em um processo de desenvolvimento orientado a objetos, o projeto da arquitetura normalmente é realizado por um arquiteto de software. O projeto da arquitetura visa distribuir as classes de objetos relacionados do sistema em subsistemas e seus componentes, distribuindo também esses componentes pelos recursos de hardware disponíveis.

     Já no projeto detalhado, são modeladas as relações de cada módulo com o objetivo de realizar as funcionalidades do módulo. Além de desenvolver o projeto de interface com o usuário e o projeto de banco de dados.


    IMPLEMENTAÇÃO
    Pode-se também utilizar na implementação ferramentas de software e bibliotecas de classes preexistentes para agilizar a atividade, como também o uso de ferramentas CASE, que dinamizam o processo de desenvolvimento, nas várias atividades, onde inclui-se geração de código-fonte, documentação, etc


    Leia mais em: http://www.devmedia.com.br/atividades-basicas-ao-processo-de-desenvolvimento-de-software/5413

  • Distribuir classes pelos recursos de hardware disponíveis?!??! nossa, que definição imbecil

  • O projeto de software pode ser divido em níveis:

    - Projeto Arquitetural
    - Projeto de Interface
    - Projeto de Componentes
    - Projeto de Implantação

     

    Projeto de Implantação

    Elementos de projeto em nível de implantação indicam como a funcionalidade e os subsistemas serão alocados no ambiente computacional físico que vai apoiar o software

     

    Fonte: Pressman, 6a Edição

     

     

     

     

     

  • Hardware? Não seria no projeto de implantanção?

    Alguém?

  • Questão retirada do livro do Eduardo Bezerra.

     

    A fase de projeto consiste em duas atividades principais: projeto da arquitetura (também conhecido como projeto de alto nível) e projeto detalhado (também conhecido como projeto de baixo nível). Essas duas atividades são descritas a seguir.
    Durante o processo de desenvolvimento de um sistema de software orientado a objetos, o projeto da arquitetura consiste em distribuir as classes de objetos relacionadas do sistema em subsistemas e seus componentes. Consiste também em distribuir esses componentes fisicamente pelos recursos de hardware disponíveis. Os diagramas da UML normalmente utilizados nessa fase do projeto são os diagramas de implementação.

    Fonte: Princípios de Análise e Projeto de Sistema com UML - Eduardo Bezerra

     

    Entretanto, foi omitido o trecho em azul, que destaca a utilização dos diagramas de implementação.

    Acredito que se trata do diagrama de implantação, pois pelo o que pesquisei não existe esse diagrama em uma fonte oficial.

     

    Fontes:

    http://www.itnerante.com.br/group/engenhariadesoftware/forum/topics/diagrama-de-implementa-o-x-implanta-o

    Questão Q297943

  • a - implementação
    b - implementação
    c - projeto de arquitetura (GABARITO) - PROJETO
    d - o que ocorre depois da "Teste"
    e - projeto detalhado - faz parte de PROJETO, mas não de confundi com "projeto de arquitetura"
     


ID
1748398
Banca
VUNESP
Órgão
Prefeitura de São Paulo - SP
Ano
2015
Provas
Disciplina
Engenharia de Software
Assuntos

Considerando uma sequência linear do processo regular de implantação de software, assinale a alternativa que apresenta a etapa constituída por: (a) realizar o check-list de infraestrutura dos usuários; (b) verificar a disponibilidade dos ambientes de treinamento e produção; e (c) realizar cargas iniciais de dados.

Alternativas

ID
1764208
Banca
CESPE / CEBRASPE
Órgão
TCE-RN
Ano
2015
Provas
Disciplina
Engenharia de Software
Assuntos

Com relação à engenharia de software, julgue o próximo item.

Em uma organização, o projeto de um software é dividido em aspectos gerenciais — com as etapas de projeto preliminar e projeto detalhado — e em aspectos técnicos — com as etapas de projeto de dados, projeto arquitetural, projeto procedimental e projeto de interface.

Alternativas
Comentários
  • Um projeto de software é uma descrição da estrutura do software a ser implementado, dos modelos de estruturas e dados usados pelo sistema, das interfaces entre os componentes do sistema e, às vezes, dos algoritmos usados.


    A especificação de requisitos é uma descrição da funcionalidade que o software deve oferecer, e seus requisitos de desempenho e confiança.


    As atividades no processo de projeto podem variar, dependendo do tipo de sistema a ser desenvolvido. São exemplos:


    1) Projeto de arquitetura: identifica a estrutura geral do sistema, os componentes principais, seus relacionamentos e como eles são distribuídos.

    2) Projeto de interface: define as interfaces entre os componentes do sistema.

    3) Projeto de componente: verifica cada componente do sistema e projeta seu funcionamento.

    4) Projeto de banco de dados: projeta as estrutura de dados do sistema  e como eles devem ser representados em um banco de dados.


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


    Podemos concluir que a questão realmente está correta! Espero ter ajudado.


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

Considere que o capítulo sobre segurança de aplicações contenha proposta de adoção de uma metodologia de desenvolvimento de aplicações com segurança fundamentalmente embasada na metodologia OWASP (open web application security project), envolvendo uma proposta de processo de desenvolvimento de aplicações aderente ao arcabouço software assurance maturity model da OWASP, conhecido como SAMM ou OpenSAMM, em combinação com aspectos técnicos como arquiteturas seguras para aplicações web, análise de vulnerabilidades, testes de invasão, gestão de patches e ataques. Nesse contexto, julgue o item seguinte.

Em aderência ao arcabouço SAMM da OWASP, o plano deve promover um processo de desenvolvimento seguro de software com base na adoção de práticas de segurança para quatro funções vinculadas ao negócio de desenvolvimento de software, as quais são: governança, construção, verificação e implantação (deployment). Para cada função, são prescritas três práticas.

Alternativas
Comentários
  • OpenSAMM: o que é e para que serve? 
    O SAMM é um framework aberto para ajudar as organizações a formular e implementar uma estratégia para a segurança de software. Após o seu lançamento ele foi integrado a OWASP (Open Web Application Security Project) que ficou conhecido como Open SAMM.

     

    O Open SAMM especifica quatro funções de negócios críticos, cada um com três práticas de segurança, são elas: 


    Governança: são as atividades da gerência, que seria examinar os grupos de desenvolvimento e também gerenciar os níveis dos negócios estabelecidos pela empresa. 
      1- Estratégia e Métricas: Definição da estratégia que será utilizada para a garantia de software ou seja criar definições de metas de segurança e também estudar os riscos da empresa.  
      2- Políticas e Conformidade: Entender as diretrizes/políticas e regulamentá-las nos padrões de seguranças, também fazer auditorias para descobrir se algum projeto não está dentro das expectativas.  
     3- Orientação e Educação: Ensinar as pessoas que estão envolvidas no desenvolvimento do software como desenvolver e implementar um software mais seguro, o OpenSAMM também indica que uma boa alternativa para melhorar o desempenho é através de objetivos para cada funcionário. 


    Construção: definir metas e criar os software dentro dos padrões. Isso inclui o gerenciamento do produto, a especificação do nível da arquitetura, design e implementação. .
       1- Modelagem de Ameaças: Identificar e entender os níveis de risco na funcionalidade do software no ambiente em que ele será executado, a partir dos detalhes conseguidos ficara mais fácil tomar decisões.  
       2- Requisitos de Segurança: Definir qual será o comportamento esperado a respeito da segurança do software, definindo cada processo por níveis e fazer auditorias para garantir que todas as especificações de segurança estão sendo utilizadas.  
       3- Arquitetura Segura: Projetar softwares seguros por padrões, reutilizando os componentes assim os riscos de segurança do software serão drasticamente reduzidos.  

    Fonte: http://blog.conviso.com.br/opensamm-o-que-e-e-para-que-serve/

  • Continuando:

    Verificação: verificações e testes nos produtos durante o desenvolvimento do software, garantindo uma boa qualidade do software.  
       1- Revisão de Arquitetura: Avaliar a segurança da arquitetura do software, permitindo assim detectar problemas logo no inicio. Quando se resolve o problema no inicio se reduz também o tempo e dinheiro que seria gasto a procura desse problema.  
       2- Revisão de Código: Inspecionar os códigos fontes a fim de encontrar potenciais falhas no software que ocorreu no desenvolvimento. O Code Review seria uma revisão mais profunda já que na hora do desenvolvimento também acontece algumas revisões, outra função é estabelecer uma base para uma codificação mais segura.  
      3- Testes de Segurança: Testar o software a procura de vulnerabilidades, para garantir que os resultados serão os esperados quando estiver em execução, basicamente seria a fase de teste a procura de qualquer tipo de erro.  


    Implantação: gerenciar a liberação do software, ou seja, essa função serve para saber se o produto vai chegar de acordo com o que foi especificado para o usuário final.  
       1- Gerenciamento de Vulnerabilidades: Gerenciar os relatórios de vulnerabilidades e incidentes operacionais ganhando assim uma base de dados dos problemas que já ocorreu, se por acaso acontecer novamente ficará mais fácil resolver.  
       2- Proteção de Ambiente: Garantir que o software será executado corretamente no ambiente de produção, reforçar a segurança da infraestrutura e implementar atualizações de segurança.  
       3- Capacitação Operacional: Procurar todo tipo de informação que possa afetar a segurança do software e comunicar aos desenvolvedores, assim detalhando os impactos que possam ocorrer para os usuários e operadores. 

    Fonte: http://blog.conviso.com.br/opensamm-o-que-e-e-para-que-serve/


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

NÃO é objetivo da homologação de sistemas:

Alternativas
Comentários
  • Validação de software ou, mais genericamente, verificação e validação (V&V), tem a intenção de mostrar que um software se adequa a suas especificações ao mesmo tempo que satisfaz as especificações do cliente do sistema. Teste de programa, em que o sistema é executado com dados de testes simulados, é a principal técnica de validação. A validação também pode envolver processos de verificação, como inspeções e revisões, em cada estágio do processo de software, desde a definição dos requisitos de usuário até o desenvolvimento do programa. Devido à predominância dos testes, a maior parte dos custos de validação incorre durante e após a implementação.


    Pessoal, a homologação do sistema está muito ligada à verificação e validação (V&V) do sistema. De acordo com a definição dada por Sommerville, temos que as alternativas A, B, C e D estão ligadas ao processo V&V. A letra E é mais voltada para Especificação de Software e Projeto/Implementação de software, a saber:


    - Especificação de software: também conhecida como Engenharia de requisitos, consiste no processo de compreensão e definição dos serviços requisitados do sistema e identificação de restrições relativas à operação e ao desenvolvimento do sistema. É um estágio particularmente crítico do processo de software, pois erros nessa fase inevitavelmente geram problemas no projeto e na implementação do sistema. Possui como atividades principais: Estudo de viabilidade, Elicitação e análise de requisitos, Especificação de requisitos e Validação de requisitos.

    - Projeto e implementação de software: processo de conversão de uma especificação do sistema em um sistema executável. Consiste na descrição da estrutura do software a ser implementado, dos modelos e estruturas de dados usados pelo sistema, das interfaces entre os componentes do sistema e, às vezes, dos algoritmos usados.


    Entendam a etapa de projeto como uma continuidade da especificação de requisitos, com a tradução dos requisitos de alto nível para a criação de uma arquitetura estável. Esta arquitetura estabilizada será formada pelos requisitos mais críticos do sistema.


    É isso, bons estudos!


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


  • O estudo de viabilidade é desenvolvido durante a fase inicial de um projeto de software, a homologação é uma das etapas finais


ID
1866844
Banca
CESPE / CEBRASPE
Órgão
TRE-PE
Ano
2016
Provas
Disciplina
Engenharia de Software
Assuntos

A respeito das metodologias de análise e desenvolvimento de software, assinale a opção correta.

Alternativas
Comentários
  • Discordo do gabarito.

    De acordo com uma questão do próprio Cespe de 2010

    Desenvolvimento ágil de software (agile software development) ou método ágil é aplicado, principalmente, a grandes corporações, uma vez que permite produzir grandes sistemas de forma ágil.  Gabarito E

    Metodologias ágeis são adequadadas para pequenas e medias empresas.

    Acho que o gabarito seria letra E. Não está completa. Mas acho que é a menos errada

  • Somente para complementar o comentário anterior, essa questão citada não invalida a questão de 2016.

    Observe que o erro da questão de 2010 foi colocar o principalmente, a grandes corporações.

    As metodologias ágeis GERALMENTE são utilizadas em pequenas e médias empresas para construções de softwares de pequeno e médio porte.

    Porém o GERALMENTE não signifca SOMENTE.

    A métodologia ágil pode sim ser adaptada para a construção de grandes sistemas.

     

    O erro da E vem "na letra da lei" de Sommervile, 2007:

    Existem vários processos de desenvolvimento de software, porém algumas atividades fundamentais são comuns a todos eles:

    Especificação: define a funcionalidade do software e as restrições sobre sua operação.
    Projeto e implementação: o software que atenda a especificação deve ser produzido.
    Validação de software: o software deve ser validado para garantir que ela faça o que o cliente deseja.
    Evolução: o software deve evoluir para atender aos novos requisitos que naturalmente surgirão

     

    Abraços e bons estudos!!

  • Homologação não é encontrada em TODAS as metodologias de desenvolvimento, por isso a letra E está ERRADA.

  • Não entendi a parte do "Métodos ágeis de desenvolvimento podem ser adaptados". Os métodos ágeis tem os seus principios bem definidos, nunca vi essa questão de adaptação por causa do tamanho do sistema.

    Existe alguma referência para isso?

  • Acho que essa é uma questão mais relacionada à interpretação, que acaba levando a analisar algumas palavras:

    b) A metodologia ágil Scrum prescreve o uso prático de técnicas de programação, como, por exemplo, programação em pares e desenvolvimento orientado a testes.

    c) De acordo com as metodologias de desenvolvimento ágil de software, não se emprega documentação para o desenvolvimento da solução tecnológica.

    d) A metodologia RUP (rational unified process) é integralmente derivada do modelo de desenvolvimento espiral orientado a riscos.

    e) Design e implementação, validação e homologação são as atividades fundamentais para a engenharia de software encontradas em todas as metodologias de desenvolvimento.

  • Existe uma seção no livro do Sommerville só sobre isso:

    3.5 Escalamento de métodos ágeis

    Métodos ágeis precisam ser adaptados para lidar com sistemas de engenharia de grande porte. Leffingwell  (2007) argumenta que é essencial manter os fundamentos dos métodos ágeis — planejamento flexível, freqüentes  releases do sistema, integração contínua, desenvolvimento dirigido a testes e boa comunicação entre os membros  da equipe. (Sommerville 2011, p. 52)

  • B = Isso aqui é a XP

    C = Emprega documentação, contudo de forma simplificada

    D = Lhufas

    E = '' Todas '' acabou com a alternativa

    GABARITO A


ID
1932238
Banca
FCC
Órgão
TRT - 14ª Região (RO e AC)
Ano
2016
Provas
Disciplina
Engenharia de Software
Assuntos

A opção pela metodologia de desenvolvimento

Alternativas
Comentários
  • a) ERRADA. O XP tem a propriedade do código ser coletivo
    b) ERRADA. Os passos sequenciais são: 1) Teste que falha (Red), 2) Teste que passa (Green) e 3) Refatoração.
    c) ERRADA. No XP, o código é coletivo.
    d) ERRADA. No UP ou RUP não há definição do número de dias para as iterações nem o conceito de reuniões em pé, como no XP e no Scrum
    e) CORRETA. O Scrum estrutura-se sobre roles (papéis), artifacts (artefatos), activities (or events ou cerimônia)

  • No FDD, o código NÃO é de propriedade coletiva!!


ID
1984918
Banca
FCC
Órgão
Copergás - PE
Ano
2016
Provas
Disciplina
Engenharia de Software
Assuntos

O principal negócio de uma empresa é armazenar e devolver combustíveis. A armazenagem ocorre a) por recebimento dutoviário, em que as distribuidoras clientes compram gasolina e GNV que são armazenados nos tanques da empresa; b) por recebimento rodoviário, pelo qual as distribuidoras clientes compram biocombustíveis (biodiesel e etanol) de usinas e o transportam até a empresa. Para armazenar os produtos a distribuidora precisa emitir uma NF − Nota Fiscal de armazenagem.

Considerando o negócio da empresa, a equipe de Analistas de TI iniciou o desenvolvimento de um sistema com uma reunião em que os clientes elegeram os pontos fundamentais do projeto, priorizando a emissão de NFs. Porém, para chegar ao ponto de emitir uma NF, muitas rotinas precisavam ser desenvolvidas, entre elas alguns cadastros essenciais. Após a definição de um layout simples para as telas de cadastro, foram executados testes funcionais e foi entregue a 1ª versão do sistema em 1 semana de trabalho. Os clientes, sempre presentes, iniciaram imediatamente o uso do sistema e deram os feedbacks, solicitando melhorias e novos recursos. No início a entrega de versões era constante, mas depois se estabilizaram em torno de 1 semana, mantendo sempre a comunicação ativa e o respeito. Os analistas usavam muito a refatoração e práticas TDD − Test-Driven Development durante o desenvolvimento. 

Pelas características, a metodologia de desenvolvimento utilizada pela equipe de Analistas de TI é:

Alternativas
Comentários
  • Quando fez referência a TDD, vinculou diretamente XP − Extreme Programming

     

    Corrobora:

     

    A prática de teste no XP é bastante técnica, e envolve a presença do cliente no desenvolvimento e na validação de testes.

    O cliente compartilha com o desenvolvedor sobre o funcionamento do sistema. Os testes também se tornam as especificações da programação, visto que o teste diz o que deve estar de acordo e o que não deve estar de acordo, é como uma especificação.

    Os testes são escritos antes da funcionalidade, o que também é conhecido como TDD (Test-Driven Design) onde intercala-se a função de testar um pouco e codificar um pouco.

  • XP - Extreme Programming 

    Enunciado longo!  sendo a partir da 9º linha que percebi que o texto trata-se da Extreme Programming

     

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

    1 - Comunicação

    2 - Simplicidade

    3 - FeedBack (Realimentação ou retorno)

    4 - Coragem

    5 - Respeito

     

    Fonte: Pressman

  • Palavras-chave para identificar que é o XP:
    Os clientes, sempre presentes
    deram os feedbacks
    mantendo sempre a comunicação ativa e o respeito
    refatoração e práticas TDD

  •  d)XP − Extreme Programming. 

    Todos os valores do XP foram citados na questão, com exceção de coragem: simplicidade, comunicação, feedback, respeito. 


ID
1990531
Banca
FCC
Órgão
ELETROBRAS-ELETROSUL
Ano
2016
Provas
Disciplina
Engenharia de Software
Assuntos

Atualmente os softwares podem ser desenvolvidos utilizando-se métodos ágeis ou métodos tradicionais. A escolha da metodologia mais adequada vai depender de vários fatores, como por exemplo, a característica de projeto, da empresa ou da gestão. Para fazer a escolha correta, é necessário ainda conhecer as características dos principais métodos e modelos de processo de desenvolvimento de software. Sobre estes métodos e modelos de processo é correto afirmar:

Alternativas
Comentários
  • a) As metodologias ágeis são indicadas principalmente em casos em que os requisitos são bem compreendidos e provavelmente não sofrerão grandes alterações durante o desenvolvimento do sistema.
    ERRADO! O indicado nesse caso é o cascata
    b) Os diagramas de Caso de Uso da UML são utilizados intensamente na fase de Elaboração do Rational Unified Process − RUP para criar um modelo de requisitos para o sistema.
    CORRETA!
    c) Nos modelos em cascata os testes são desenvolvidos paralelamente aos requisitos, antes de iniciar o desenvolvimento, ajudando testadores e desenvolvedores a compreenderem os requisitos.
    ERRADA! Não há paralelismo no cascata. Todas as fases são sequenciais.
    d) No Rational Unified Process − RUP o cliente participa do processo de desenvolvimento discutindo cenários com a equipe para gerar os cartões de estórias, que englobam as necessidades do cliente.
    ERRADA! cartões de estórias é no XP
    e) Sprinter e programação em pares são práticas descritas e amplamente utilizadas na eXtreme Programming − XP para agilizar o processo de desenvolvimento e reduzir a possibilidade de erros.
    ERRADA! Sprint é no Scrum

     

  • Sprinter? Examinador noiado...
    O correto é Splinter, grande mestre das Tartarugas Ninja! kkkkkkk

  • Corrigindo cada alternativa:

    a) As metodologias ágeis são indicadas principalmente em casos em que os requisitos não são bem compreendidos e provavelmente sofrerão grandes alterações durante o desenvolvimento do sistema.

     b) Os diagramas de Caso de Uso da UML são utilizados intensamente na fase de Elaboração do Rational Unified Process − RUP para criar um modelo de requisitos para o sistema. (CORRETA)

     c) No XP os testes são desenvolvidos paralelamente aos requisitos, antes de iniciar o desenvolvimento, ajudando testadores e desenvolvedores a compreenderem os requisitos.

     d) Nos modelos em cascata  o cliente participa do processo de desenvolvimento discutindo cenários com a equipe para gerar os cartões de estórias, que englobam as necessidades do cliente. (Na modelo em cascata as fases são sequenciais)

     e) programação em pares são práticas descritas e amplamente utilizadas na eXtreme Programming − XP para agilizar o processo de desenvolvimento e reduzir a possibilidade de erros. (Splinter não faz parte do XP)


ID
2008492
Banca
Aeronáutica
Órgão
EEAR
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

“O analista de sistemas deve verificar se existem manuais, diagramas ou outros documentos que mostram como os processos são realizados ou deveriam ser realizados. ”

Dada a afirmação acima, de qual processo da análise do sistema existente estamos falando?

Alternativas
Comentários
  • C

    Análise de Procedimentos