Questões de Desenvolvimento de Software

Questão 43696

• Banca: CESGRANRIO
• Órgão: Petrobras
• Ano: 2008
• Provas: CESGRANRIO - 2008 - BR Distribuidora - Analista de Sistemas Júnior - Processos de Negócios
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software; Teste de Software

Um importante aspecto da elaboração de casos de testes para um sistema em desenvolvimento é a escolha dos valores de entrada e das saídas previstas dos casos de teste. Escolhas baseadas apenas em valores típicos, em geral, são incapazes de revelar todas as falhas da implementação. É necessário identificar conjuntos de valores que possuam características comuns, do ponto de vista das funcionalidades a serem testadas, como, por exemplo, "números negativos", "números com mais dígitos do que o previsto", "strings sem brancos", "arrays de um só elemento", além de prever casos de teste cobrindo a totalidade destes conjuntos, e projetar, para cada conjunto, casos de teste com valores nos limites e próximos ao ponto médio do conjunto. Esses conjuntos são denominados

• A. partições de equivalência.
• B. grupos de controle.
• C. espaços amostrais.
• D. classes características.
• E. intervalos de testes.

Gabarito: A

Comentários

• o particionamento por equivalência é uma técnica de teste da caixa preta, ele seleciona um dominio de entrada de dados de um programa de classe, a partir dos quais os casos de teste possam ser derivados a fim de realização das verificações, Existem mais três tipos de teste da caixa preta que são: a) causa e efeito; b) valor limite; c) comparação
• Explicando o primeiro comentário, que ficou bem confuso no começo:O particionamento de equivalência divide o domínio de entrada de um programa em classes de dados, das quais os casos de testes podem ser derivados.
• Segundo Pressman:
  O particionamento de equivalência é um método de teste caixa-preta que divide o domínio de entrada de um programa em classes de dados, das quais os casos de testes podem ser derivados. Ele busca definir um caso de teste que descobre classes de erros, reduzindo assim o número total de casos de testes que precisam ser desenvolvidos.

• Se a coloca uma alternativa com "análise do valor limite" ficaria muito mais difícil de resolver a questão

Questão 56716

• Banca: CESPE / CEBRASPE
• Órgão: ANAC
• Ano: 2009
• Provas: CESPE - 2009 - ANAC - Analista Administrativo - Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

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

O termo engenharia pretende indicar que o desenvolvimento de software submete-se a leis similares às que governam a manufatura de produtos industriais em engenharias tradicionais, pois ambos são metodológicos.

• C. Certo
• E. Errado

Gabarito: C

Comentários

• Eu não tocaria nessa questão em uma situação real. É controverso. Dizer que submete-se a lei é exagero. Além disso, produtos manufaturados são regidos por processos. Ou seja, são contínuos, iguais e sem fim. O crontrário de um projeto de software, que é sempre diferente, tem final determinado e é interativo.Agora, realmente, ambos seguem uma metodologia...Como não sei o que se passava na cabeça de quem formulou essa questão, o melhor é deixar em branco!

• Sommerville, na introdução do referido livro, diz  "a engenharia de software é um ramo da engenharia cujo foco é o desenvolvimento dentro de custos adequados de sistemas de software de alta qualidade. Software é abstrato e intangível. Náo é limitado por materiais ou controlado por leis da física ou por processos de manufatura.... a falta de restrições naturais significa que o software pode facilmente se tornar extremamente complexo e, portanto, muitto difícil de ser compreendido.", o que contraria a questão.

  O trecho seguinte "...pois ambos são metodológicos" pode ser considerado correto. Segundo o próprio autor, "noções fundamentais de processo e de organização de sistemas constituem a base de todas essas técnicas que constituem a essência da engenharia de software".

  O trecho inicial invalida a questão e, portanto, acredito que o gabarito da questão deveria ser ERRADO.

• Marquei errado, mas essa questão foi retirada do livro  "Engenharia de software e Sistemas da Informação" de Denis Alcides Rezende 3e Ed.
  
  Pág. 5
  
  "Associado a esses objetivos, o termo engenharia pretende indicar que o desenvolvimento de software deve submeter-se a leis similares às que governam a manufatura de produtos industrias em engenharias tradicionais, pois ambos são metodológicos (MAFFEO, 1992) "
• O ponto nevrálgico da questão é o entendimento do trecho "(...) submete-se a leis similares (...)".
  Muito subjetivo e difícil determinar a fronteira de que até que ponto é aderente as leis que governam a manufatura de produtos industriais.
  Como é CESPE, boa pedida é deixar em branco! :)
• Salvo engano, no livro do Pressman fala justamente que o software não pode ser comparado a outros produtos de engenharia por não ser manufaturado.
  Embora eu tenha marcado errado, revendo o enunciado acredito que a resposta esteja mesmo correta pois cita que o desenvolvimento se submete a leis "similares" e não idênticas as que governam a manufatura de produtos. Talvez a questão tenha ficado ainda mais confusa por causa do termo "leis".
• Boa noite,
  marquei Correto usando analogia, vejam como faz sentido : produtos industriais (uma casa pré-fabricada por exemplo) e produtos de software sao regidos por ciclos realmente similares - a casa tem um orçamento inicial, um projeto de requisitos (piso, metais, tubulacoes, cores, etc), uma fase de construcao (literalmente até) e uma fase de entrega, onde o dono recebe a casa. tambem tem fases de validacao onde o  dono "aprova" o andamento da obra e "testa" o resultado preliminar. Ou seja, é muito parecido com software. Acredito ser por isso que o autor da questao comparou software e produto industrial como resultado de trabalhos de engenharia.
  Obrigado.

Questão 56725

• Banca: CESPE / CEBRASPE
• Órgão: ANAC
• Ano: 2009
• Provas: CESPE - 2009 - ANAC - Analista Administrativo - Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software; Engenharia de Requisitos; UML

Em engenharia de software, o processo de
desenvolvimento de software designa uma sequência de
atividades, agrupadas em fases e tarefas, executadas de forma
sistemática e uniformizada, realizadas por pessoas com
responsabilidades bem definidas e que, a partir de um conjunto
de entradas (inputs) produzem um conjunto de saídas (outputs).
Como objetivos, o processo de desenvolvimento de software deve
prover orientação sobre as sequências das atividades envolvidas,
especificar os modelos descritivos do sistema, gerenciar as tarefas
e definir métricas para os modelos e atividades.

R. A. Ramos. Treinamento em UML (com adaptações).

Quanto às fases e tarefas no processo de desenvolvimento de
software, julgue os itens de 64 a 67.

A fase de projeto define o que o software deve fazer, enquanto a fase de eliciação de requisitos define como o software deve atingir seus requisitos.

• C. Certo
• E. Errado

Gabarito: E

Comentários

• Modelagem de negócio é que define o que o projeto deve fazer.
• E elicitação é o levantamento dos requisitos.

• Fase de eliciação de requisitos = análise de requisitos: Define o que o sistema deve fazer, focando apenas nas funções sem se preocupar como será implementado (tecnologia, linguagem, ambiente,...)

  Fase de projeto: Define como o sistema deve ser implementado para que melhor sejam executadas as funções que este deve fazer.

• acredito que esteja invertido

Questão 76918

• Banca: CESGRANRIO
• Órgão: BACEN
• Ano: 2010
• Provas: CESGRANRIO - 2010 - BACEN - Analista do Banco Central - Área 1
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

Determinada superintendência de um órgão público solicita o desenvolvimento de um sistema de informação que deve recolher informações de pessoas físicas de todo o Brasil, pela Internet. O superintendente, que abandonará a gestão em menos de 1 mês, exige que o sistema completo esteja no ar em 2 semanas e aponta que erros podem ser reparados após a implantação do sistema. Com base nesse relato, afirma-se que

• A. a correção de erros deve ser feita, preferencialmente, na fase de manutenção, já que é mais eficiente corrigir o produto depois de construído.
• B. a construção de sistemas WEB, nesse prazo, é inviável, independente do tamanho do projeto.
• C. esse tipo de solicitação é muito improvável na atualidade, uma vez que há expectativas quanto à redução de custos, mas não de prazo.
• D. o custo esperado de reparo na fase de manutenção é até três vezes superior ao custo de reparo na fase de requisitos.
• E. os erros mais caros são aqueles cometidos na análise de requisitos e descobertos pelo usuário.

Gabarito: E

Comentários

• Questão mal formulada.Com base no relato, o que é afirmado está na opção A. Basta interpretar o texto.No entanto, a afirmativa correta é a E, que realmente entre as 5 opções é a única certa.A pergunta da questão deveria ter sido: "Qual das afirmações abaixo é a correta ?". Nesse caso alternativa E.Como a pergunta foi "Com base nesse relato afirma-se que ..." a resposta certa é a A.Espero que a questão seja anulada (mais provável) ou o gabarito seja revisto.
• Nao concordo, lendo o texto fica claro que o superintendente pretende "concluir" o projeto de qualquer forma antes de deixar o cargo. E é claro que isso é uma prática totalmente contrária à engenharia de software. Não foi uma questão super bem elaborada mas, achei que ficou claro. Na verdade acho que foi proposital, é mais um teste para quem tá esperto na hora da prova do que um teste de conhecimento de eng soft.

•  a) Dizer que a correção de erros deve ser feita PREFERENCIALMENTE na fase de manutenção é absurdo, e dizer que é mais eficiente corrigir o produto depois de construído piorou, completamente errada. Quanto mais cedo identificar e corrigir os erros melhor.

  b) A questão afirma ser inviável, mas isso vai depender de vários fatores como: bom planejamento, escopo e cronograma adequado, recursos coerentes com escopo e cronograma.

  c) Mesma resposta da b).

  d) É verdade que o custo de manutenção é bem maior quanto mais avançado estiver o projeto, mas eu nunca li em lugar algum que era 3x maior (alternativa duvidosa).

  e) Questão sem dúvidas e sem erros. Se uma equipe comete um erro na fase de requisitos e quem descobre é o usuário, é porque esse erro não foi descoberto em nenhuma fase do projeto, ou seja, para corrigi-lo deve-se repetir todo o processo desde o início (pelo menos nas partes do produto relacionadas ao requisito realizado de forma errada), o que obviamente sai bem mais caro.

   

• Excelente a explicação do Renato, porém acho que gera dúvida na leitura da resposta. Pois os erros foram "descobertos" quando? A questão não disse em que face foram descobertos. Se forem descobertos já na análise, os custos não serão os mais caros, serão se descobertos nas faces subsequentes. Concordam?
   

   

  
• Renato achei sua explicacao excelente mesmo
  Apenas para acrescentar, e' importante observar que em momento algum foi citado o tamanho do projeto. Isso ja torna a Letra B totalmente falsa, pois imaginemos que esse projeto fosse tao somente um cadastro de funcionarios do setor com nome endereco etc.... Com isso conclui-se que nao existe nenhum elemento palpavel para afirmar co mcerteza que o prazo de um mes e' inviavel para a execucao do projeto.
  As vezes estamos tao acostumados a pegar projetos gigantescos, que esquecemos que apra passar em concurso nao adianta usar somente o conehcimento do dia a dia, e' preciso entender a malicia do examinador na pergunta, pois no fim das contas nao e' uem sabe mais quem passa na prova, e sim quem responde mais questoes de forma correta.
  Fiquei em duvida entre a D e a E, mas como estou querendo alem de passar, ser tambem chamado, optei pela E, pois como bem falou o Renato, alem de nao ter visto isso escrito em lugar algum na minha vida, ja participei de projetos que o custo de manutencao chegou a 30 ou 40 vezes o custo do desenvolvimento( aqui sim utilizei um conhecimento do dia a dia). Sabemos que as empresas de consultoria gostam de ganhar exatamente em cima da manutencao, e ano so do desenvolvimento do projeto em si.
  Bons Estudo e rumo ao Senado

• e-

  a analise de requisitos sao as tarefas cujo objetivo determinar as exigencias para um novo sistema, considerando o conflito entre as diversas exigencias dos stakeholders, tais como os usuarios. a analise de requisitos é fundamental para o sucesso do projeto

Questão 105595

• Banca: FCC
• Órgão: DPE-SP
• Ano: 2010
• Provas: FCC - 2010 - DPE-SP - Agente de Defensoria - Programador
• Disciplina: Engenharia de Software
• Assuntos: Conceitos Básicos em Engenharia de Software; Desenvolvimento de Software

A Engenharia de Software

I. não visa o desenvolvimento de teorias e fundamentações, preocupando-se unicamente com as práticas de desenvolvimento de software.

II. tem como foco o tratamento dos aspectos de desenvolvimento de software, abstraindo-se dos sistemas baseados em computadores, incluindo hardware e software.

III. tem como métodos as abordagens estruturadas para o desenvolvimento de software que incluem os modelos de software, notações, regras e maneiras de desenvolvimento.

IV. segue princípios, tais como, o da Abstração, que identifica os aspectos importantes sem ignorar os detalhes e o da Composição, que agrupa as atividades em um único processo para distribuição aos especialistas.

É correto o que se afirma em

• A. III e IV, apenas.
  
• B. I, II, III e IV.
  
• C. I e II, apenas.
  
• D. I, II e III, apenas.
  
• E. II, III e IV, apenas.

Gabarito: D

Comentários

• Questão passível de recurso. O item I está incorreto, pois temos os métodos formais que se preocupam em dar uma base matemática para o desenvolvimento de sistemas.

•  É porque ele se baseou na afirmação de Somerville Sabe-tudo:

   

   

  A Ciência da Computação está relacionada com teoria e fundamentos. A Engenharia de Software está preocupada com as práticas de desenvolvimento e entrega de software útil.

   

   

•  Mas o próprio Sommerville cita que a Engenharia de Software abrange todos aspectos relacionados ao desenvolvimento de software, incluindo "o desenvolvimento de ferramentas, métodos e teorias para auxiliar na produção de software"

   

  "Software engineering is not just concerned with the technical processes of software development but also with activities such as software project management and with the development of tools, meth- ods and theories to support software production."

• ou a questão foi mal feita ou ela foi "comprada"..o único item certo é o III.
• Concordo com o Diego Martins, a única correta é a afirmação III.
• I. não visa o desenvolvimento de teorias e fundamentações, preocupando-se unicamente com as práticas de desenvolvimento de software. 
  
  "Computer science focuses on theory and fundamentals; software engineering is concerned with the practicalities of developing and delivering useful software." (Sommerville 9, pág.6)
  
  II. tem como foco o tratamento dos aspectos de desenvolvimento de software, abstraindo-se dos sistemas baseados em computadores, incluindo hardware e software. 
  Quem se preocupa com os aspectos de hardware e software é a Eng. de Sistemas: "System engineering is concerned with all aspects of computer-based systems development including hardware, software, and process engineering. Software engineering is part of this more general process".
  
  IV. segue princípios, tais como, o da Abstração, que identifica os aspectos importantes sem ignorar os detalhes e o da Composição, que agrupa as atividades em um único processo para distribuição aos especialistas. 
  "o correto seria: [...] aspectos importantes ignorando os detalhes [...]
• Apenas complementando o comentário do Luiz Cláudio, não há o princípio da Composição e sim da Decomposição:
  É a técnica de se dividir o problema em partes de maneira que cada uma possa ser resolvida de uma forma mais específica.

• 1.1.1 Engenharia de software
  

  
  

  Engenharia de software é uma disciplina de engenharia cujo foco está em todos os aspectos da produção de software, desde os estágios iniciais da especificação do sistema até sua manutenção, quando o sistema já está sendo usado.

  
  

  Todos os aspectos da produção de software.
  

  A engenharia de software não se preocupa apenas com os processos técnicos do desenvolvimento de software. Ela também inclui atividades como gerenciamento de projeto de software e desenvolvimento de ferramentas, métodos e teorias para apoiar a produção de software.

  -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

  
  

  0 que é engenharia de software?

  É uma disciplina de engenharia que se preocupa com todos os aspectos de produção de software.

  
  

  Ciências da Computação:

  Foca a teoria e os fundamentos.

  
  

  Engenharia de Sistemas:
  

  Se preocupa com todos os aspectos do desenvolvimento de sistemas computacionais, incluindo engenharia de hardware, software e processo.

  
  

  Fonte: 9°edição - Ian Sommerville
  

• Questão contrária à questão Q343284 (CESPE). Uma considera verdadeiro e a outra falso.

• (I) Errado, Sommerville diz: “Computer science focuses on theory and fundamentals; software engineering is concerned with the practicalities of developing and delivering useful software”. No entanto, ele não diz que a engenharia de software se preocupa unicamente com as práticas de desenvolvimento de software.

   

  (II) Errado, Pressman diz: “System engineering is concerned with all aspects of computer-based systems development including hardware, software, and process engineering” – a questão trata da Engenharia de Sistemas.

   

  (III) Correto, de fato ela tem como métodos as abordagens estruturadas para o desenvolvimento de software que incluem os modelos de software, notações, regras e maneiras de desenvolvimento.

   

  (IV) Errado, o princípio da abstração ignora os detalhes; e o princípio da composição não existe – o que existe é o princípio da decomposição. E ele divide o problema em partes menores.

   

  Em suma, nenhuma das opções nos atende! Vocês sabem qual opção a banca marcou como correta? A Letra D!!! E ela voltou atrás com os recursos? Não!!! Pois é, galera! Acostumem-se com isso :( 

   

  Fonte : https://www.estrategiaconcursos.com.br/curso/engenharia-de-software-para-concursos-curso-regular-2017/

• Adeilson Aragão,  por isso me matei pra acertar a questão achando que o louco era eu, e na verdade a má formulação da mesma me fez perder pontos. Lastimável...

• Aí a pessoa estuda dias e dias e vem a banca querendo impor novos conceitos. Horrível essa questão, a unica alternativa 100% correta é a III.

• Questão sem gabarito, todas estão incorretas.

Questão 114208

• Banca: CESPE / CEBRASPE
• Órgão: TRE-MT
• Ano: 2010
• Provas: CESPE - 2010 - TRE-MT - Analista Judiciário - Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software; Modelo em cascata; Outros modelos de Processo de Software; Processos de Software

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

• A. No modelo de desenvolvimento em cascata, a primeira etapa é a modelagem do sistema.
  
• B. No modelo de desenvolvimento incremental, da mesma maneira que no modelo cascata, é possível a solução dos riscos logo no início do projeto.
  
• C. A metodologia de prototipagem evolutiva é uma abordagem que visualiza o desenvolvimento de concepções do sistema conforme o andamento do projeto, por meio de protótipos visuais.
  
• D. O modelo de desenvolvimento UML é uma metodologia de desenvolvimento orientada a objetos que gera protótipos muito rapidamente, em função das ferramentas case disponíveis.
  
• E. O modelo de desenvolvimento em espiral, que tem a codificação como segunda etapa, gera o código do sistema muito mais rapidamente que o modelo de prototipação.

Gabarito: C

Comentários

• a) Etapas do desenvolviemnto em casacata: Requerimento, projeto, implementação, verificação, manutenção ERRADOb) O modelo em cascata acumula riscos ERRADOc) Correto. E atente para o fato que os protótipos não são usáveis. São apenas esqueletos que funcionam usando STUBS ou técnicas de Mágico de Oz, ao contrário do desenvolvimento incremental que produz entregas utilizáveis.d) UML é tecnica de diagramacao ERRADOe) Etapas do desenvolvimento espiral: planejamento, analise de riscos, engenharia e avaliacao do cliente.ERRADO
• UML é linguagem de modelagem, não é Metodologia.

Questão 136249

• Banca: ESAF
• Órgão: MPOG
• Ano: 2010
• Provas: ESAF - 2010 - MPOG - Analista de Planejamento e Orçamento - Tecnologia da Informação - Prova 2
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software; Outros modelos de Processo de Software; Processos de Software; Processos de Software - Desenvolvimento Ágil; XP (eXtreme Programming)

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

• A. Planejamento, Análise dos Componentes, Análise de Hierarquia e Avaliação feita pelo cliente.
• B. Planejamento, Análise dos Riscos, Engenharia e Avaliação feita pelo cliente.
• C. Projeto, Análise dos Benefícios, Engenharia e Avaliação feita pelo gestor.
• D. Planejamento, Eliminação dos Riscos, Análise de Contingência e Avaliação feita pelo cliente.
• E. Planejamento, Projeto, Análise dos Riscos e Engenharia.

Gabarito: B

Comentários

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

• Complementando a resposta, muito boa do colega Leonardo:

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

  Modelo Espiral do Sommerville: 

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

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

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

  4) Planejamento da próxima fase;
  

Questão 142243

• Banca: CESGRANRIO
• Órgão: BNDES
• Ano: 2009
• Provas: CESGRANRIO - 2009 - BNDES - Profissional Básico - Análise de Sistemas - Desenvolvimento
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software; Processos de Software; RUP (Rational Unified Process) - Processo Unificado Rational

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

• A. desenvolvimento é iterativo, incremental e orientado por casos de uso.
• B. caso de uso mais crítico deve ser atacado, preferencialmente, no final.
• C. fase de transição envolve treinamento de usuários e assistência no uso do produto.
• D. arquitetura se desenvolve a partir das visões do usuário expressas em casos de uso.
• E. arquitetura, na fase de construção, é estável, ainda que possa ser evoluída.

Gabarito: B

Comentários

• A fase de elaboração possui como marca a arquitetura da solução, para validar a arquitetura é importante implementar o caso de uso mais critico.
• Os casos de uso mais criticos, entenda-se mais dificil de serem resolvidos/implementados, geralmente vao ser o núcleo do sistema ou função mais importante, devem ser implementados primeiro. com isso o problema com maior risco de ser resolvido se resolve no comeco do projeto. Com isso desperdicios de tempo e dinheiro com o desenvolvimento de partes simples do projeto nao acontecem caso a equipe falhe em fazer o principal do projeto.
• Os casos de uso mais críticos são atacados primeiro no RUP, com a justificativa de que eles definem a arquitetura, que deve ser estabilizada logo.
  
  No XP as funcionalidades mais críticas são atacadas por último, com a justificativa de que os requisitos são instáveis e tudo pode ser mudado, então existe a chance de uma funcionalidade com grande impacto na arquitetura sofrer mudanças de requisito.

Questão 143761

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

Assinale a afirmação incorreta com relação ao desenvolvimento de uma aplicação que será disponibilizada na Web:

• A. O código-fonte e os programas executáveis são itens de configuração de software.
• B. A segurança é um requisito não funcional do sistema.
  
• C. Os Web Services permitem publicar serviços de forma simples e isolada da base de dados.
  
• D. Os diagramas da UML são artefatos do projeto e devem ser acompanhados pelo sistema de gestão da configuração de software.
  
• E. A confiabilidade é um requisito funcional de sistema.

Gabarito: E

Comentários

• Os requisitos não funcionais, ao contrário dos funcionais, não expressam nenhuma função a ser realizada pelo software, e sim comportamentos e restrições que este software deve satisfazer.

  Um exemplo da diferença entre os dois pode ser visto a seguir:

  Requisito funcional: 
  
  Calcular saldo a pagar de imposto de renda.

  Requisito não funcional

  A declaração deve ser simples o suficiente para que o cálculo do imposto seja feito sem a necessidade do usuário pedir ajuda a um contador.
  
  Portanto confiabilidade é um requisito não funcional

Questão 144946

• Banca: CESPE / CEBRASPE
• Órgão: INMETRO
• Ano: 2009
• Provas: CESPE - 2009 - INMETRO - Analista Executivo em Metrologia e Qualidade - Desenvolvimento de Sistemas - Parte II
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

Acerca de linhas de produtos e de componentes de software, julgue os itens subsequentes.

A análise de características comuns e variáveis (comunalidades e variabilidades) é uma das importantes técnicas empregadas durante a análise de um domínio de componentes em uma abordagem de linha de produtos.

• C. Certo
• E. Errado

Gabarito: C

Comentários

• Comunalidade e variabilidade são o coração da maioria das técnicas de projetos.

  Com a análise da comunalidade e variabilidade podemos formar grupos com características comuns, chamados de famílias, que podem ser módulos, classes, funções, objetos entre outros. Usamos a análise da comunalidade para formar as famílias e a analise da variabilidade para identificar as características que diferenciam cada membro.

  http://www.lisha.ufsc.br/teaching/sce/ine5612-2001-2/work/coplien.html

   

   

•  A questão versa sobre Linhas de Produtos de Software - LPS (Software Product Lines - SPL)
  

Questão 153091

• Banca: CESPE / CEBRASPE
• Órgão: TJ-DFT
• Ano: 2008
• Provas: CESPE - 2008 - TJ-DFT - Analista Judiciário - Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software; Metodologia de desenvolvimento de software; Outros modelos de Processo de Software; Processos de Software

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.

• C. Certo
• E. Errado

Gabarito: C

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.

Questão 153094

• Banca: CESPE / CEBRASPE
• Órgão: TJ-DFT
• Ano: 2008
• Provas: CESPE - 2008 - TJ-DFT - Analista Judiciário - Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software; Metodologia de desenvolvimento de software; Prototipação

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.

• C. Certo
• E. Errado

Gabarito: E

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

Questão 153151

• Banca: CESPE / CEBRASPE
• Órgão: TJ-DFT
• Ano: 2008
• Provas: CESPE - 2008 - TJ-DFT - Analista Judiciário - Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software; Qualidade de Software

Julgue os itens a seguir, acerca da qualidade e da maturidade em
projetos de software.

Um dos objetivos de uma técnica de revista formal é de garantir que o software foi representado em conformidade com padrões predefinidos.

• C. Certo
• E. Errado

Gabarito: C

Comentários

• Segundo Pressman:
  "Uma revisão técnica formal é uma atividade de garantia de qualidade de software realizada por engenheiros de software (e outros). Os objetivos são:
  1 - Descobrir erros na função, na lógica ou na implementação, para qualquer representação do software;
  2 - Verificar se o software sob revisão satisfaz os requisitos;
  3 - Garantir que o software tenha sido representado de acordo com padrões pre-definidos;
  4 - Conseguir software que seja desenvolvido de modo uniforme;
  5 - Tornar os projetos mais administráveis".

Questão 162907

• Banca: CESGRANRIO
• Órgão: Petrobras
• Ano: 2010
• Provas: CESGRANRIO - 2010 - Petrobrás - Analista de Sistemas Júnior - Processos de Negócios
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software; Web 2.0

Nos testes de usabilidade de um sistema Web, foi definido um conjunto de tarefas a serem realizadas nesse sistema, assim como foi selecionado um conjunto de potenciais usuários para realizar essas tarefas. É atribuição dos membros da equipe de desenvolvimento do sistema Web, que aplica os testes,

• A. assegurar que os usuários que realizam as diversas tarefas tenham o mesmo nível de experiência na realização das tarefas e já tenham sido treinados no uso do sistema.
  
• B. solicitar aos usuários o uso do menor número de comandos possível para realizar cada tarefa, no caso de haver mais de uma maneira de realizá-la.
  
• C. instruir aos usuários que permaneçam em silêncio durante a realização das tarefas, para que o conhecimento de seu modelo mental não influencie nos resultados dos testes.
  
• D. usar os tempos e as taxas de sucesso coletados na realização de cada tarefa para posterior geração de relatórios com resultados dos testes.
  
• E. apresentar os casos de uso do sistema aos usuários, para que indiquem inconsistências entre os casos apresentados e a interface gráfica correspondente.

Gabarito: D

Comentários

• e) apresentar os casos de uso do sistema aos usuários, para que indiquem inconsistências entre os casos apresentados e a interface gráfica correspondente.
  
  Qual o erro desta opção?
• Luciano, a comparação entre a especificação e os casos de uso seria um teste funcional, não de usabilidade. Usabilidade limita-se na facilidade em utilizar o sistema, sem avaliar a funcionalidade em si.
• E) caso de uso é para usuário ver????
• Respondendo:
  Diagrama de casos de uso pode auxiliar no entendimento dos requisitos entre equipe técnica e usuários (logo, o usuário pode sim ver  este diagrama e entende-lo sem problemas)
  Mas como já foi dito, ele não irá auxiliar se tratando de testes de usabilidade.

• Eu acredito que erro da letra 'e' está relacionado: 

  1) Apresentar os casos de uso do sistema aos usuários e papel da equipe de Análise de requisitos.

  2) Casos de Uso e Protótipo de Interface gráfica faz parte da fase Iniciação ou Elaboração e não testes. 

  Resumindo a Equipe de Teste preocupa-se apenas com relatórios com resultados dos testes. Letra D

  
  

Questão 163963

• Banca: FCC
• Órgão: TJ-PI
• Ano: 2009
• Provas: FCC - 2009 - TJ-PI - Analista Judiciário - Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

Em se tratando de processo de desenvolvimento de software, é um modelo que utiliza o feedback mais do que o planejamento como seus mecanismos de controle primário para produzir testes regulares e as versões do software desenvolvido. Assim, o seu desenvolvimento prescreve a construção de uma porção pequena, mas abrangente, do projeto de software para ajudar a todos os envolvidos a descobrir cedo os problemas ou suposições, falhas que possam levar ao desastre. Trata-se do modelo de processo

• A. DSDM.
• B. ágil.
• C. em cascata.
• D. formal.
• E. iterativo.

Gabarito: E

Comentários

• Feedback = Realimentação = Processo Iterativo
• O feedback é uma das principais características do desenvolvimento ágil. Essa questão confunde o candidato porque cita uma característica marcante do desenvolvimente ágil. 
  
  "Em se tratando de processo de desenvolvimento de software, é um modelo que utiliza o feedback mais do que o planejamento como seus mecanismos de controle primário para produzir testes regulares e as versões do "
  
  Na segunda frase, mudou completamente e agora ele fala do processo iterativo
  
  "Assim, o seu desenvolvimento prescreve a construção de uma porção pequena, mas abrangente, do projeto de software para ajudar a todos os envolvidos a descobrir cedo os problemas ou suposições, falhas que possam levar ao desastre. Trata-se do modelo de processo"
  
  A banca misturou conceitos e acabou confundindo o candidato. Lamentável essa questão.

• O Desenvolvimento iterativo e incremental prescreve a construção de uma porção pequena, mas abrangente, do projeto de software para ajudar a todos os
  envolvidos a descobrir cedo os problemas ou suposições, falhas que possam a levar ao desastre (PRESSMAN, 2006). O processo iterativo é preferido por
  desenvolvedores porque lhes fornece um potencial para atingir os objetivos de projeto de um cliente que não sabe exatamente o que quer, ou quando não se
  conhece bem todos os aspectos da solução.
  
  http://www.esab.edu.br/arquivos/monografias/monografia_andre%20martins.pdf
   

• Infelizmente o examinador tirou a questão do wikipedia (http://pt.wikipedia.org/wiki/Processo_de_desenvolvimento_de_software):
  
  

  Processos Iterativos

  O Desenvolvimento iterativo e incremental prescreve a construção de uma porção pequena, mas abrangente, do projeto de software para ajudar a todos os envolvidos a descobrir cedo os problemas ou suposições, falhas que possam a levar ao desastre. O processo iterativo é preferido por desenvolvedores porque lhes fornece um potencial para atingir os objetivos de projeto de um cliente que não sabe exatamente o que quer, ou quando não se conhece bem todos os aspectos da solução.

  Processos de desenvolvimento ágil de software são construídos com os fundamentos do desenvolvimento iterativo. Os processos ágeis usam o feedback, mais que o planejamento, como seus mecanismos de controle primário. O feedback é produzido por testes regulares e das versões do software desenvolvido.

• O mais grave é que processos ágeis são iterativos. Portanto, ao meu ver, o gabarito deveria ser B.

• Ágil é uma METODOLOGIA e não um processo. Por isso não pode ser letra B.

• O modelo incremental propõe que cada versao é um incremento. geralmente é usado pra longos projetos com prazos curtos seguindo o ciclo de waterfall model com um release no final

• Acho que o principal motivo de não pode ser a letra B é por causa da utilização do termo "prescreve" no segundo período da questão.

Questão 163966

• Banca: FCC
• Órgão: TJ-PI
• Ano: 2009
• Provas: FCC - 2009 - TJ-PI - Analista Judiciário - Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software; Processos de Software; RUP (Rational Unified Process) - Processo Unificado Rational

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

• A. RUP.
• B. DSDM.
• C. XP.
• D. TDP.
• E. DDP.

Gabarito: A

Comentários

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

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

• Resposta certa letra A
  
  O Rational Unified Process® (também chamado de processo RUP®) é um processo de engenharia de software.  Ele oferece uma abordagem baseada em disciplinas para atribuir tarefas e responsabilidades dentro de uma organização de desenvolvimento.  Sua meta é garantir a produção de software de alta qualidade que atenda às necessidades dos usuários dentro de um cronograma e de um orçamento previsíveis.
  Fonte: http://www.wthreex.com/rup/portugues/index.htm

• O RUP é baseado em um conjunto de princípios de desenvolvimento de software e melhores práticas, por exemplo:

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

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

  
  
  
  Gestão e Controle de Mudanças do Software

  Em todos os projetos de software a existência de mudanças é inevitável. O RUP define métodos para controlar e monitorar mudanças. Como uma pequena mudança pode afetar aplicações de formas inteiramente imprevisíveis, o controle de mudanças é essencial para o sucesso de um projeto.
  
  O RUP também define áreas de trabalho seguras, garantindo a um programador que as mudanças efetuadas noutro sistema não afetarão o seu sistema.
  
  
  
  Referência: pt.wikipedia.org/wiki/IBM_Rational_Unified_Process#Controle_de_altera.C3.A7.C3.B5es_no_software
  
  
  
  http://pt.wikipedia.org/wiki/IBM_Rational_Unified_Process#Controle_de_altera.C3.A7.C3.B5es_no_software  .http://pt.wikipedia.org/wiki/IBM_Rational_Unified_Process#Controle_de_altera.C3.A7.C3.B5es_no_softwarept.wikipedia.org/wiki/IBM_Rational_Unified_Process#Controle_de_altera.C3.A7.C3.B5es_no_software

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

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

Questão 164602

• Banca: FGV
• Órgão: BADESC
• Ano: 2010
• Provas: FGV - 2010 - BADESC - Analista de Sistemas - Desenvolvimento de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

O Projeto de software é o primeiro passo da fase de desenvolvimento de qualquer produto ou sistema de engenharia.

Do ponto de vista técnico, a fase de projeto produz:

• A. projeto de dados, sistema e domínio.
  
• B. projeto de dados, sistema, domínio e interface.
  
• C. projeto de dados, arquitetural, procedimental e interface.
  
• D. projeto de dados, sistema, domínio, procedimental e interface.
  
• E. projeto de dados, domínio, arquitetural, procedimental e interface.

Gabarito: C

Comentários

• Resposta letra C.
  
  Projeto de dados: interpreta objetos de dados do modelo de análise (abstrato) para estruturas de dados que são usadas nos componentes do software e, quando necessário, uma arquitetura de banco de dados para a aplicação.
  Projeto arquitetural: vem a ser a estrutura do software, com os seus componentes interligados, com as suas interfaces internas, externas e interface com os usuários.
  Projeto procedimental ou projeto de componentes: vem a ser os módulos do software, com os seus atributos e procedimentos para processamentos dos dados. Possui um algorítmo descrevendo como o módulo funciona e como funciona a interface de entrada e saída de dados do módulo.
  Projeto de interface: é parecido com uma classe. Possui os métodos que implementam a interface e a permissão para que sejam acessados.
• Questão retirada da página 418 do Pressman 3a edição, conforme a figura:
  
  http://s12.postimage.org/nauqx8cot/pastewzb5gw.jpg
• Essa questão pode ser resolvida da seguinte forma:
  na letra a) temos sistema que seria uma fase de desenvolvimento pós-projeto, o sistema é algo completo que é obtido na fase de construção. na letra b) novamente temos sistema e isso invalida a alternativa, na letra d) temos domínio que invalida a alternativa, pois o domínio é obtido antes do projeto, na fase de elaboração, de especificação de requisitos, por esta mesma razão a letra e) está errada, restando assim a letra c)

• Há 2 (dois) aspectos para serem considerados no Projeto de Software: Aspectos Gerenciais e Aspectos Técnicos
  
  - Aspectos Gerenciais: Projeto Preliminar e Projeto Detalhado
  - Aspectos Técnicos: Projeto de Dados; Projeto Arquitetural; Projeto Procedimental; Projeto de Interface;
  
  Obs.: Projeto de Sistema e de Domínio não são aspectos técnicos. Ambos têm relações os requisitos

Questão 189259

• Banca: CESGRANRIO
• Órgão: ELETROBRAS
• Ano: 2010
• Provas: CESGRANRIO - 2010 - ELETROBRAS - Analista de Sistemas - Suporte Basis SAP R3
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

No contexto de desenvolvimento de software, uma DLL é

• A. o ambiente de desenvolvimento de software (IDE) adequado para código Visual Basic (VB).
• B. o procedimento padrão de linkedição de código-fonte e biblioteca de sistemas.
• C. o kernel dos sistemas operacionais Windows, podendo ser acessado a partir dos programas desenvolvidos em VB.
• D. uma biblioteca de código e dados que pode ser usada, simultaneamente, por mais de um programa.
• E. um algoritmo de alocação dinâmica de memória eficiente, disponível no próprio Windows.

Gabarito: D

Comentários

• DLL= Dynamic-link library (Biblioteca de ligação dinâmica)

  É a implementação feita pela Microsoft para o conceito de bibliotecas compartilhadas nos sistemas operacionais Microsoft Windows e OS/2. Essas bibliotecas geralmente tem as extensões DLL, OCX (para bibliotecas que contêm controles ActiveX), ou DRV (para drivers de sistema legados).

  Fonte: pt.wikipedia.org/wiki/DLL

Questão 201319

• Banca: CESPE / CEBRASPE
• Órgão: Banco da Amazônia
• Ano: 2010
• Provas: CESPE - 2010 - Banco da Amazônia - Técnico Científico - Tecnologia da Informação - Arquitetura de Tecnologia
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

Com relação aos conceitos de desenvolvimento de sistemas, julgue os itens a seguir.

Os princípios de engenharia de software definem a necessidade de formalidades para reduzir inconsistências e a decomposição para lidar com a complexidade.

• C. Certo
• E. Errado

Gabarito: C

Comentários

• A questão cita dois princípios da engenharia de software:
  
  Formalidade: técnica onde o software deve ser desenvolvido de acordo com passos definidos com precisão e seguidos de maneira efetiva. Ou seja, ser consistente!
  
  Decomposição: técnica de se dividir o problema em partes, de maneira que cada uma possa ser resolvida de uma forma mais especifica. Ideal para lidar com a complexidade do problema.
• Princípios da Engenharia de Software   A formalidade é a técnica onde o software deve ser desenvolvido de acordo com passos definidos com precisão e seguidos de maneira efetiva.   A Abstração preocupa-se com a identificação de um determinado fenômeno da realidade, sem se preocupar com detalhes, considerando apenas os aspectos mais relevantes.   A decomposição é a técnica de se dividir o problema em partes, de maneira que cada uma possa ser resolvida de uma forma mais específica.   A generalização é a maneira usada para resolver um problema, de forma genérica, com o intuito de poder reaproveitar essa solução em outras situações semelhantes.   A flexibilização é o processo que permite que o software possa ser alterado, sem causar problemas para sua execução.
  
  Alternativa: Certa

Questão 205420

• Banca: FEPESE
• Órgão: SEFAZ-SC
• Ano: 2010
• Provas: FEPESE - 2010 - SEFAZ-SC - Auditor Fiscal da Receita Estadual - Parte III - Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

Identifique as alternativas corretas a respeito de engenharia reversa.

1. Descompiladores são usados para obter o código fonte de um software a partir de seu código binário.

2. Ofuscadores de código efetuam a cifragem de códigos binários de programas com o intuito de impedir a sua descompilação.

3. Através de técnicas de engenharia reversa, é possível obter diagramas UML de um programa a partir de seu código fonte.

4. Descompilação de código e esteganografia são duas técnicas frequentemente usadas para realizar a engenharia reversa de sistemas computacionais.

Assinale a alternativa que indica todas as afirmativas corretas.

• A. São corretas apenas as afirmativas 1 e 3.
• B. São corretas apenas as afirmativas 1 e 4.
• C. São corretas apenas as afirmativas 2 e 3.
• D. São corretas apenas as afirmativas 1, 2 e 4.
• E. São corretas apenas as afirmativas 2, 3 e 4.

Gabarito: A

Comentários

• 1 - OK

  2 - Os ofuscadores cifram o código fonte

  3 - OK. É o que fazem programas como o Together, Power Architect, etc.

  4 - Esteganografia (do grego "escrita escondida") é o estudo e uso das técnicas para ocultar a existência de uma mensagem dentro de outra. Em outras palavras, esteganografia é o ramo particular da criptologiaque consiste em fazer com que uma forma escrita seja camuflada em outra a fim de mascarar o seu verdadeiro sentido.

   
  É importante frisar a diferença entre criptografia e esteganografia. Enquanto a primeira oculta o significado da mensagem, a segunda oculta a existência da mensagem.
   
  Um exemplo básico de técnica moderna de esteganografia é a alteração do bit menos significativo de cada pixel de uma imagem colorida de forma a que ele corresponda a um bit da mensagem. Essa técnica, apesar de não ser ideal, pouco afeta o resultado final de visualização da imagem.
• Ofuscação de Código é o nome dado a uma tentativa deliberada de fazer um código de programação tornar-se difícil de entender por outras pessoas. Isto é feito pela adição de código não destrutivo e irrelevante como redundâncias de código, uso de nomes de variáveis sem sentido,  códigos de resultado nulo, entre outras técnicas, produzindo um código confuso e ilegível, mas com a mesma funcionalidade de uma versão eficiente do programa. Evitam- se, assim, muitas das regras básicas de legibilidade de código como variáveis bem nomeadas, comentários adequados e outros recursos.
• 1. Descompiladores são usados para obter o código fonte de um software a partir de seu código binário.
  
  Correto.
  
  2. Ofuscadores de código efetuam a cifragem de códigos binários de programas com o intuito de impedir a sua descompilação.
  
  Errado. Isso nem sempre acontece. Existem bankers por aí que simplesmente utilizam base64 para ofuscar o código; e isso não é cifrar (emprego de algoritmo criptográfico).
  
  3. Através de técnicas de engenharia reversa, é possível obter diagramas UML de um programa a partir de seu código fonte.
  
  Correto. Isso pode ser feito após a descompilação de um programa ou até mesmo manualmente visualizando as funcionalidades do executável em um depurador.
  
  4. Descompilação de código e esteganografia são duas técnicas frequentemente usadas para realizar a engenharia reversa de sistemas computacionais.
  
  Errado. Esteganografia não é uma técnica de engenharia reversa.

• Será que não poderiam ter feito essa questão em português.

• Questão comentada e utilizada no curso do GV! ehehhehehe

  Vamos seguindo!!

• Prezados, 
  
  O item 1 está correto, descompiladores fazem o processo inverso do compilador , ao invés de transformar código fonte em executável , ele transforma executável em código fonte.
  O item 2 está errado, ofuscadores não realizam a cifragem , e sim a alteração dos nomes para dificultar a interpretação
  O item 3 está correto, com a engenharia reversa podemos construir diagramas a partir do código fonte
  O item 4 está errado, esteganofrafia é uma técnica de ocultação de informação, e não de engenharia reversa.
  
  Portanto a alternativa correta é a letra A
  
  

Questão 215722

• Banca: CESPE / CEBRASPE
• Órgão: MPU
• Ano: 2010
• Provas: CESPE - 2010 - MPU - Analista de Informática - Desenvolvimento de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software; Diagrama de Sequência; UML

Um processo de desenvolvimento de software contém a descrição
de uma abordagem para a construção de sofware. A UML (unified
modeling language) é uma linguagem visual para especificar,
documentar e construir os artefatos de sistemas orientados a
objetos. Quanto ao ambiente de desenvolvimento de sistemas
orientados a objetos, julgue o item a seguir.

Na convenção de notação usada na UML, a chamada por mensagens assíncronas é representada no diagrama de sequência por meio de seta cheia (não pontilhada).

• C. Certo
• E. Errado

Gabarito: E

Comentários

•  O correto seria: Na convenção de notação usada na UML, a chamada por mensagens síncronas é representada no diagrama de sequência por meio de seta cheia (não pontilhada).

  Mensagem assíncrona é representada no diagrama de sequência por meio de seta aberta. 

  Dica: Assíncrona > Aberta

• Ambas as mensagens (síncronas ou assíncronas) são representadas por setas nas extremidades. 

  A notação UML para uma mensagem síncrona é a de um segmento de reta com uma seta cheia em uma das extremidades. 
  A notação UML para uma mensagem assíncrona é a de um segmento de reta com uma meia seta em uma das extremidades.

• Os tipos de mensagens estão no link abaixo:http://bp0.blogger.com/_a-TB_d8huPY/Rxi0Iz-L9hI/AAAAAAAAAb8/Ll9eyO31064/s1600-h/mensagens_uml.jpg
  
  Espero ter ajudado, bons estudos !

Questão 218161

• Banca: CESPE / CEBRASPE
• Órgão: TRE-BA
• Ano: 2010
• Provas: CESPE - 2010 - TRE-BA - Analista Judiciário - Análise de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

Acerca de mudança de software, julgue o item abaixo.

Das várias estratégias de mudança de software, realizar alterações significativas na arquitetura do sistema de software diz respeito a reengenharia de software.

• C. Certo
• E. Errado

Gabarito: E

Comentários

• Nem toda reestruturação na arquitetura do sw é reengenharia, podemos alterar a arquitetura por motivos de correção ou adaptação do software a outros requisitos de negócio, não sendo necessariamente com um foco preventivo ou evolutivo.

  Mudança de Software pode ser (pressman - pg 685):
  * Manutenção Corretiva;
  * Manutenção Adaptativa;
  * Manutenção Evolutiva;
  * Manutenção Preventiva ou Reengenharia.

• A reengenharia trata de modificar componentes de software ou trechos dele, sem modificar seu comportamento, oferecendo melhorias estruturais. 

  Realizam alterações significativas ou não e pode ser em sua arquitetura ou componentes de apoio. Sendo assim, considerei a afirmativa correta, pois a frase não fala que APENAS realizam alterações significativas. Fala que realiza. E pode realizar! 

  Achei essa questão mal elaborada pela banca. 

  
  

• Projetos de reengenharia empreendidos com a intenção de recriar um sistema existente
  (legado) no todo ou em parte.
   

  Considere qualquer produto
  de tecnologia que tenha lhe servido
  bem. Você o utiliza regularmente, mas
  ele está ficando obsoleto. Apresenta
  problemas com muita frequência, leva mais tempo
  para ser reparado do que você aceitaria e já
  não representa a tecnologia mais atualizada. O
  que fazer? Por um tempo, você tenta consertá-lo,
  remendá-lo ou até ampliar sua funcionalidade.
  Isso se chama manutenção. Mas a manutenção
  se torna cada vez mais difícil à medida que os
  anos passam. Chega então um momento em que
  precisa reformá-lo. Você criará um produto com
  mais funcionalidades, melhor desempenho e confiabilidade e de manutenção m
   

  [Roger S. Pressman]

   

  reengenharia é recirar, reformular o sistema existente.

  Realizar alterações significativas é mudança de software, não reengenharia.

• Não concordo com a resposta, pois alguns processos de reengenharia de software ocasionam alteração na estrutura, exemplo disso é a tradução do código fonte e a modularização do sistema (Pressman - Eng de Soft)

• Não concordo com a respostas, pois alguns processos de reengenharia de software ocasionam alteração na estrutura, exemplo disso é a tradução do código fonte e a modularização do sistema (Pressman - Eng de Soft)

Questão 223990

• Banca: UFF
• Órgão: UFF
• Ano: 2009
• Provas: UFF - 2009 - UFF - Analista de Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

No tocante ao desenvolvimento de software em camadas, a camada que define as regras para utilização na persistência de dados é conhecida como:

• A. Dados;
• B. Suporte;
• C. Física;
• D. Cliente;
• E. Negócio.

Gabarito: E

Comentários

• É a camada de negócio, que está mais próximo das entidades do banco de dados.
• Camada de negócio

  Também chamada de Lógica empresarial, Regras de negócio ou Funcionalidade.
  É nela que ficam as funções e regras de todo o negócio. Inexiste uma interface para o usuário e seus dados são voláteis, ou seja, para que algum dado seja mantido deve ser utilizada a camada de dados

• Modelo três camadas
  
  As três partes de um ambiente modelo três camadas são: camada de apresentação, camada de negócio e camada de dados. Deve funcionar de maneira que o software executado em cada camada possa ser substituído sem prejuízo para o sistema. De modo que atualizações e correções de defeitos podem ser feitas sem prejudicar as demais camadas. Por exemplo: alterações de interface podem ser realizadas sem o comprometimento das informações contidas no banco de dados.
  
  
  Camada de apresentação - É a chamada GUI (Graphical User Interface), ou simplesmente interface. Esta camada interage diretamente com o usuário, é através dela que são feitas as requisições como consultas, por exemplo.
   
  Camada de negócio - Também chamada de Lógica empresarial, Regras de negócio ou Funcionalidade. É nela que ficam as funções e regras de todo o negócio e são definidas as regras para utilização na persistência de dados. Não existe uma interface para o usuário e seus dados são voláteis, ou seja, para que algum dado seja mantido deve ser utilizada a camada de dados. 
   
  Camada de Dados - A terceira camada é definida como o repositório das informações e as classes que a manipulam. Esta camada recebe as requisições da camada de negócios e seus métodos executam essas requisições em um banco de dados. Alterando o banco de dados alteraria apenas as classes da camada de dados, e o restante das camadas não seriam afetados por essa alteração.

Questão 230911

• Banca: FUNCAB
• Órgão: PRODAM-AM
• Ano: 2010
• Provas: FUNCAB - 2010 - PRODAM-AM - Analista de TI - Desenvolvimento de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software; Outros modelos de Processo de Software; Processos de Software

Qual das alternativas a seguir corresponde ao modelo de processo, proposto no final da década de 80, que tem como principais características ser evolucionário, iterativo e focado na redução dos riscos?

• A. Modelo em Espiral.
• B. Modelo em Cascata.
• C. Modelo em V.
• D. ModeloTransformacional.
• E. Modelo de Especificação Operacional.

Gabarito: A

Comentários

• O modelo em espiral foi definido por Barry Boehm em seu artigo de 1988 A Spiral Model of Software Development and Enhancement.
  Este modelo não foi o primeiro a discutir o Desenvolvimento iterativo e incremental, mas ele foi o primeiro modelo a explicar o porque do modo iterativo. Como originalmente antevisto, as iterações têm uma duração típica de 6 meses a dois anos. Cada fase inicia com um objetivo esperado e termina como uma revisão pelo cliente do progresso (que deve ser interna) e assim por diante. Esforços de análise e engenharia são aplicados em cada fase do projeto, com um olho focado no objetivo do projeto.
  
  Fonte: http://pt.wikipedia.org/wiki/Modelo_em_espiral

• Apenas complementando o que o colega explicou, o diferencial do modelo em espiral reside no foco na análise e redução dos riscos, ponto forte do modelo.
  

• a)Modelo em Espiral.

  Espiral é para projetos especificos com base na analise de riscos. A "espiral" deste modelo contém, alem da comunicação com cliente, planejamento, analis de risco, engenharia (construção & entrega) e, ao final de cada evolução, avaliação do cliente

Questão 266809

• Banca: CESPE / CEBRASPE
• Órgão: PC-ES
• Ano: 2011
• Provas: CESPE - 2011 - PC-ES - Perito Criminal - Específicos; CESPE - 2011 - PC-ES - Perito Criminal Especial - Específicos
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

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

A reengenharia procura introduzir melhorias em processos já existentes, reformulando o que já existe ou fazendo pequenas mudanças que deixem as estruturas básicas intactas.

• C. Certo
• E. Errado

Gabarito: E

Comentários

• As mudanças feitas podem alterar a estrutura do processo, logo o trecho "fazendo pequenas mudanças que deixem as estruturas básicas intactas" invalida a questão.
• A partir da ótica da Administração Pública, Reengenharia é um processo definido de cima para baixo (alto escalão da empresa), e que tem como meta sacudir toda a empresa. Não é um processo de melhoria ou de pequenas mudanças. O que a reengenharia faz é mudar radicalmente os processos da empresa tentando torná-la mais eficaz e eficiente.
  Existem bons materiais no ponto dos concursos e no eu vou passar de Administração Pública que tratam de reengenharia.
• O que isso tem a ver com engenharia de software ?!
• A reengenharia é basicamente colocar a casa abaixo e construir uma nova! Não são mudanças sutis ou pequenas, são mudanças drásticas, radicais.

Questão 267814

• Banca: CESPE / CEBRASPE
• Órgão: TRE-ES
• Ano: 2011
• Provas: CESPE / CEBRASPE - 2011 - TRE-ES - Analista - Análise de Sistemas - Específicos
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software; Engenharia de Requisitos

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

Para se chegar ao produto, a primeira ação que se deve fazer é definir o escopo do projeto. Para tal, é necessário realizar um levantamento inicial de requisitos, decompondo-se o problema segundo a abordagem “dividir para conquistar”. Inicialmente, o sistema deve ser decomposto em subsistemas que são, por sua vez, decompostos em módulos. Os módulos podem, ainda, ser recursivamente decompostos em submódulos ou funções, até que se obtenha uma visão geral das funcionalidades a serem tratadas no projeto.

• C. Certo
• E. Errado

Gabarito: C

Comentários

• Correto

• Essas questões sem contexto são muito difíceis de responder. Qualquer pessoa que tenha estudado o assunto mais a fundo ou tenha experiência prática sabe que essa assertiva não é verdade para todos os casos. Por exemplo, em prototipação não é necessário nem definir o escopo do projeto, já que os requisitos e as necessidades de desenvolvimento vão surgindo no decorrer do processo. 

• Realmente... Esses "deve" deixam a questão, no mínimo, confusa. Na prova, não arriscaria respondê-la. 

• No que se refere ao produto, a primeira coisa a se fazer é definir o escopo do projeto. Para tal, é necessário fazer um levantamento de requisitos inicial. A idéia é decompor o problema, em uma abordagem “dividir para conquistar”. Inicialmente, o sistema deve ser decomposto em subsistemas que são, por sua vez, decompostos em módulos. Os módulos podem, ainda, ser recursivamente decompostos em sub-módulos ou funções, até que se tenha uma visão geral das funcionalidades a serem tratadas no projeto. 

   

  FALBO, R. Engenharia de Software. 2005. 99 f. Notas de Aula (Disciplina de Engenharia de Software) – Universidade Federal do Espírito Santo, Espírito Santo, 2005

Questão 280180

• Banca: IADES
• Órgão: CFA
• Ano: 2010
• Provas: IADES - 2010 - CFA - Analista de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

Considerando os modelos de desenvolvimento de software, assinale a alternativa correta.

• A. O modelo de 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.
• B. No modelo de desenvolvimento por prototipação não existem métricas de controle, dada a natureza experimental do desenvolvimento e do produto obtido.
• C. Uma das restrições do modelo sequencial linear, é a de entregar os produtos do projeto somente após a validação do produto.
• D. O modelo em espiral é um tipo de processo de software que reúne a natureza iterativa da prototipação com os aspectos sistemáticos e controlados do modelo sequencial linear.

Gabarito: D

Comentários

• a) O modelo com base em componentes é uma abordagem tipicamente orienteda a objetos.
  b) No modelo de desnevolvimento por prototipação podem existir métricas, como números de protótipos apresentados antes da homologação, tempo de construção de cada protótipo, e outras.
  c) O modelo linear entrega os produtos ao final de cada fase, sendo assim, os requisitos são entregues antes do projeto, que é entregue antes da implementação.
  d) Correto.
• Segundo Pressman, o modelo espiral é um modelo evolucionário de processo de software que combina a natureza iterativa da prototipagem com os aspectos controlados e sistemático do modelo em cascata. Ele fornece o potencial para o desenvolvimento rápido de versões de software cada vez mais completas.
• alguem poderia explicar o porque da alternativa C estar errada.
  
  c)Uma das restrições do modelo sequencial linear, é a de entregar os produtos do projeto somente após a validação do produto.
  
  nesse modelo, os produtos nao sao entregues apos a validacao?
  
• Diego, na verdadi essa é mais uma daquelas questões subjetivas em que depende muito da interpretação. 
  
  Neste caso os produtos que a questão se referem são os entregáveis no final de cada fase, pelo menos é isso que parece ser. 
  
  Eu havia interpretado igual você.. 
  
  abc

Questão 280189

• Banca: IADES
• Órgão: CFA
• Ano: 2010
• Provas: IADES - 2010 - CFA - Analista de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

A Engenharia de Software é uma disciplina que se ocupa de todos os aspectos da produção de software, desde os estágios iniciais de especificação do sistema até a sua manutenção. A Engenharia de Software adota métodos que

• A. são um conjunto de atividades, cuja meta é o desenvolvimento ou a evolução do software.
• B. são uma representação simplificada de um processo de software, apresentada a partir de uma perspectiva específica.
• C. são abordagens de estruturadas para o desenvolvimento de software, que incluem modelos de sistemas, notações, regras, recomendações de projetos e diretrizes de processos.
• D. se ocupam da teoria e dos fundamentos de desenvolvimento de software.

Gabarito: C

Comentários

• a) refere-se a PROCESSO DE SOFTWARE
  b) refere-se a MODELO DE PROCESSO DE SOFTWARE
  c) CORRETA
  d) refere-se a CIÊNCIA DA COMPUTAÇÃO
• O que é Engenharia de Software
  Disciplina de engenharia preocupada com todos os aspectos sobre a produção de software, incluindo:
  
  Processos ou Procedimentos
  Racionalizam o desenvolvimento de Software, ou seja, técnicas de manuseio das ferramentas para aplicação dos métodos;
  Métodos
  Conhecimento técnico; “Como” fazer, são as técnicas/paradigmas para o desenvolvimento de software;
  Ferramentas
  Suporte automatizado para processos e métodos
  Alternativa: C
  
  Fonte: Aulas Fernando Pedrosa

Questão 280879

• Banca: INSTITUTO CIDADES
• Órgão: AGECOM
• Ano: 2010
• Provas: INSTITUTO CIDADES - 2010 - AGECOM - Analista de Gestão Administrativa - Analista de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software; Qualidade de Software

A Engenharia de Software trata de aspectos relacionados ao estabelecimento de processos, métodos, técnicas, ferramentas e ambientes de suporte ao desenvolvimento de software. Com relação à Engenharia de Software, assinale a alternativa correta.

• A. Atividades de Desenvolvimento são as atividades diretamente relacionadas ao processo de desenvolvimento do software, ou seja, que contribuem diretamente para o desenvolvimento do produto de software a ser entregue ao cliente. São exemplos de atividades de desenvolvimento: especificação e análise de requisitos, projeto e implementação.
• B. Atividades de Gerência são aquelas relacionadas com a garantia da qualidade do produto em desenvolvimento e do processo de software utilizado, tais como revisões e inspeções de produtos (intermediários ou finais) do desenvolvimento.
• C. Atividades de Garantia da Qualidade são aquelas relacionadas ao planejamento e acompanhamento gerencial do projeto, tais como realização de estimativas, elaboração de cronogramas e análise dos riscos do projeto.
• D. No Processo de Software são abordadas as principais atividades da gerência de projetos, a saber: definição do escopo do projeto, estimativas, análise de riscos, elaboração de cronograma, elaboração do plano de projeto e acompanhamento de projetos.
• E. O Planejamento e Gerência de Projetos enfoca os processos de software, os elementos que compõem um processo, a definição de processos para projetos, modelos de processo, normas e modelos de qualidade de processo de software e a automatização do processo de software.

Gabarito: A

Comentários

• b) ERRADO. Atividades de Garantia da Qualidade: são aquelas relacionadas com a garantia da qualidade do produto em desenvolvimento e do processo de software utilizado, tais como revisões e inspeções de produtos (intermediários ou finais) do desenvolvimento.

  c) ERRADO. Atividades de Gerência: são aquelas relacionadas ao planejamento e acompanhamento gerencial do projeto, tais como realização de estimativas, elaboração de cronogramas, análise dos riscos do projeto etc.

  d) ERRADO. Planejamento e Gerência de Projetos – são abordadas as principais atividades da gerência de projetos, a saber: definição do escopo do projeto, estimativas, análise de riscos, elaboração de cronograma, elaboração do plano de projeto e acompanhamento de projetos

  e) ERRADO. Processo de Software – enfoca os processos de software, os elementos que compõem um processo, a definição de processos para projetos, modelos de processo, normas e modelos de qualidade de processo de software e a automatização do processo de software.

• a-

  Atividades diretamente ligadas ao projeto:

  Planejamento (Plano de execução do projeto, levantamento de requisitos, casos de uso), construção (analise, projeto, implementação, testes), implantação (avaiação, manutenção).

Questão 280912

• Banca: INSTITUTO CIDADES
• Órgão: AGECOM
• Ano: 2010
• Provas: INSTITUTO CIDADES - 2010 - AGECOM - Analista de Gestão Administrativa - Analista de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software; Gestão de Projetos em Engenharia de Software

Com relação à Engenharia de Software, marque a alternativa INCORRETA.

• A. Um processo de software pode ser visto como o conjunto de atividades, métodos, práticas e transformações que guiam pessoas na produção de software.
• B. Um processo de software pode ser definido de forma universal.
• C. A Gerência de Projetos de Software envolve o Produto, o Processo e as Pessoas envolvidas no projeto.
• D. Antes mesmo de serem iniciadas as atividades técnicas de um projeto, o gerente e a equipe de desenvolvimento devem estimar o trabalho a ser realizado, os recursos necessários, o tempo de duração e, por fim, o custo do projeto.
• E. Para a realização de estimativas de tempo e custo, é fundamental estimar, antes, o esforço necessário para completar o projeto ou cada uma de suas atividades.

Gabarito: B

Comentários

• b-

  Um processo de software não pode ser definido de forma universal. Para qualidade, um processo deve se adequar ao domínio da aplicação e ao projeto específico.

Questão 280915

• Banca: INSTITUTO CIDADES
• Órgão: AGECOM
• Ano: 2010
• Provas: INSTITUTO CIDADES - 2010 - AGECOM - Analista de Gestão Administrativa - Analista de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

O projeto de software encontra-se no núcleo técnico do processo de desenvolvimento de aplicativos, sendo aplicado independentemente do modelo de ciclo de vida e paradigma adotados. Com relação ao Projeto de Software, marque a alternativa correta:

• A. A atividade de projeto envolve a modelagem de como o sistema será implementado, com a adição dos requisitos não funcionais aos modelos construídos na análise.
• B. O objetivo do projeto é incorporar a tecnologia aos requisitos essenciais do sistema, projetando o que será construído na implementação.
• C. O projeto de software é um processo iterativo. Inicialmente, o projeto é representado em um nível baixo de abstração. À medida que iterações ocorrem, os refinamentos conduzem a representações de menores níveis de abstração.
• D. Uma especificação de projeto deve contemplar todos os requisitos implícitos contidos no modelo de análise, assim como os requisitos explícitos desejados pelo sistema.
• E. No projeto de sistemas, um modelo de projeto é tipicamente gerado a partir dos modelos de análise, com o objetivo de representar o que deverá ser codificado na fase de abstração.

Gabarito: A

Questão 280930

• Banca: INSTITUTO CIDADES
• Órgão: AGECOM
• Ano: 2010
• Provas: INSTITUTO CIDADES - 2010 - AGECOM - Analista de Gestão Administrativa - Analista de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

A depuração é muito importante no desenvolvimento de software. Com relação à depuração, analise as seguintes afirmativas:
I. É um processo de localização e adição de erros.
II. É usado em conjunto com técnicas estáticas e dinâmicas.
III. São testes de regressão – verifica se mudanças no software introduziram novos erros.

Podemos afirmar corretamente que:

• A. Todas as afirmativas estão corretas.
• B. Todas as afirmativas estão incorretas.
• C. Apenas as afirmativas I e II estão corretas.
• D. Apenas as afirmativas II e III estão correta
• E. Apenas as afirmativas I e III estão corretas.

Gabarito: D

Comentários

• II) Técnica Estática:

  O teste de caixa branca, tem sido considerado relevante para as atividades de manutenção, depuração e para a confiabilidade de software. 

  Técnica Dinâmica:

  O próprio teste de regressão (item III) é um aliado a depuração do software.

  Fonte:https://www.agtic.ufpr.br/pds-ufpr/ProcessoDemoisellePlugin/guidances/supportingmaterials/tecnicasTestes_8AB32ED1.html

  III)Algumas pessoas confundem a atividade de depuração (debbuging) com a atividade de teste, mas elas diferem. Pois, a atividade de teste pode demonstrar falhas que são causadas por defeitos enquanto a depuração é uma atividade de desenvolvimento que repara o código e checa se os defeitos foram corrigidos corretamente para então ser feito um teste de confirmação por um testador com a intenção de certificar se o mesmo foi eliminado.

  Segundo PRESSMAN, quando o caso e teste descobre um erro, a depuração é a ação que resulta na reparação do erro, sendo assim a depuração deve ser seguida de alguma técnica que valide a correção do erro, acompanha de alguma técnica, como técnicas dinâmicas, o teste de regressão.

  Nota: Só achei forte o termo "São Testes de Regressão" Não dá para entender se a banca quis afirmar se depuração são testes de regressão, se explica na alternativa III o que são testes de regressão, ou se realmente o intuito é confirmar que os testes de regressão caminham lado a lado.

  Fonte:http://www.linhadecodigo.com.br/artigo/2775/introducao-ao-teste-de-software.aspx

Questão 283726

• Banca: FUNIVERSA
• Órgão: IPHAN
• Ano: 2009
• Provas: FUNIVERSA - 2009 - IPHAN - Analista - Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Conceitos Básicos em Engenharia de Software; Desenvolvimento de Software

A Engenharia de Software resume-se em um conjunto de técnicas utilizadas para o desenvolvimento e manutenção de sistemas computadorizados, visando produzir e manter softwares de forma padronizada e com qualidade. Ela obedece a alguns princípios como (1) Formalidade, (2) Abstração, (3) Decomposição, (4) Generalização e (5) Flexibilização. Assinale a alternativa que apresenta conceito correto sobre os princípios da Engenharia de Software.

• A. A flexibilização é o processo que permite que o software possa ser alterado, sem causar problemas para sua execução.
• B. A formalidade é a maneira usada para resolver um problema, de forma genérica, com o intuito de poder reaproveitar essa solução em outras situações semelhantes.
• C. A generalização preocupa-se com a identificação de um determinado fenômeno da realidade, sem se preocupar com detalhes, considerando apenas os aspectos mais relevantes.
• D. Pelo princípio da decomposição, o software deve ser desenvolvido de acordo com passos definidos com precisão e seguidos de maneira efetiva.
• E. A abstração é a técnica de se dividir o problema em partes, de maneira que cada uma possa ser resolvida de uma forma mais específica.

Gabarito: A

Comentários

• Princípios da Engenharia de Software;
  
  A formalidade é a técnica onde o software deve ser desenvolvido de acordo com passos definidos com precisão e seguidos de maneira efetiva.
  
  A Abstração preocupa-se com a identificação de um determinado fenômeno da realidade, sem se preocupar com detalhes, considerando apenas os aspectos mais relevantes.
  
  A decomposição é a técnica de se dividir o problema em partes, de maneira que cada uma possa ser resolvida de uma forma mais específica.
  
  A generalização é a maneira usada para resolver um problema, de forma genérica, com o intuito de poder reaproveitar essa solução em outras situações semelhantes.
  
  A flexibilização é o processo que permite que o software possa ser alterado, sem causar problemas para sua execução.
  
  
• P/ treinar, as alternativas fornecem os seguintes conceitos
  b) Generalização
  c) Abstração
  d) Formalidade
  e) Decomposição

Questão 308725

• Banca: CESPE / CEBRASPE
• Órgão: TJ-ES
• Ano: 2011
• Provas: CESPE - 2011 - TJ-ES - Técnico de Informática
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

Com referência a engenharia de software e uso de UML para a
modelagem de sistemas, julgue os itens subsecutivos.

Verificação e validação são atividades da análise de software, necessárias para se identificar o que o software precisa executar, seguida de uma avaliação do usuário quanto às atividades definidas.

• C. Certo
• E. Errado

Gabarito: C

Comentários

• Fonte: Engenharia de Software - Roger s. Pressman (Sexta Edição)
  Página: 289
  
  13.1.1 Verificação e Validação
  Verificação e validação abrangem um amplo conjunto de atividades da Garantia da Qualidade de Software (Capítulo 26), que inclui revisões técnicas formais,auditoria de qualidade e configuração, monitoramento de desempenho, simulação, estudo de viabilidade, revisão da documentação, revisão da base de dados, análise de algoritimos, teste de desenvolvimento, teste de usabilidade, teste de qualificação e teste de instalação.
  
  No Capitulo 26 - Gestão da Qualidade no item 26.4 - Revisões Técnicas Formais é descrito um longo processo de verificação e validação das necessidades, requisitos do Software.
  
• Não concordo com o gabarito da questão.
  
  Validação é uma atividade da análise de software, necessária para se identificar o que o software precisa executar, seguida de uma avaliação do usuário quanto às atividades definidas. A Atividade de verificação diz respeito a construção correta do software, de acordo com os requisitos validados. A verificação é uma atividade típica da fase de projeto (ver em Princípios de Análise e projeto de sistemas com UML de Eduardo Bezerra, pág. 27).
  
  Bons estudos a todos,
• Verificação: sistema vs requisitos/especificação
  Validação: sistema vs o que o cliente queria
  
  Verificação: ambiente de desenvolvimento/desenvolvedores
  Validação: ambiente de produção/cliente
  
  Verificação: Did we build the product right?
  Validação:   Did we build the right product?
  
  É isso ai!
  
  (Fonte: TIMasters)
• Acho que a questão foi mal escrita.
  Onde se lê "análise de software" deveria estar "engenharia de software".
  Do jeito que está, parece que essas atividades são da parte da fase de análise do processo de desenvolvimento, mas que na verdade são referentes a teste (até mesmo se considerado teste aplicado aos requisitos).
  Eu interpretei assim na primeira lida.
  Confusa...
• Quanto a validação, podemos engolir que exista a validação dos requisitos na fase de análise: "...dedica-se a mostrar que os requisitos realmente definem o sistema que o usuário deseja"(Sommerville). No entanto, estou até agora procurando uma referência sobre a verificação na parte de análise.
  Se verificação pode ser definida pela pergunta: "estamos contruindo certo o produto?", como vou verificar alguma coisa que ainda não está sendo construída?  
• Imagine a construção de uma casa e use esses conceitos.
  
  Validação: está relacionado ao cliente, a especificação.
  Estamos fazendo casa igualzinha a que o arquiteto desenhou?
  Estamos fazendo o produto correto?
  
  Verificação: verifica a forma como o produto é construído, está mais ligado aos desenvolvedores.
  Estamos fazendo a casa utilizando os materiais que o cliente contratou e não estamos pulando etapas como por exemplo colocando o telhado antes de impermeabilizar?
  Estamos fazendo corretamente o produto?
  
  
  
  
• as questões de requisitos estão muito mal elaboradas!
• Também não concordo com o gabarito.
  Concordo em serem atividades da análise de software e que posteriormente o usuário realiza uma avaliação.
  Mas em "necessárias para se identificar o que o software precisa executar", isso pode
  ser claramente uma definição das tarefas de Especificação de Software.
  
  De acordo com Sommerville: Validação e Verificação é a análise da adequação ao propósito para o qual o software foi projetado.
  De acordo com Pressman: Refere-se ao conjunto de tarefas que garantem que o software implementa corretamente uma função e que está de acordo com os requisitos do cliente.
  
  Nada parecido com a frase "necessárias para se identificar o que o software precisa executar".
• Talvez a definição mais genérica dos termos possa ajudar na questão:
   
  • Verificação - Evidencia objetiva de que um determinado item satisfaz requisitos previamente estabelecidos.
  • Validação - Evidencia objetiva de que um determinado item satisfaz a requisitos previamente estabelecidos para um determnado fim pretendido.

• Pessoal, a questão está realmente correta! Pois, a mesma trata da aspecto do controle de qualidade para a disciplina de Engenharia de Requisitos, que está a fase de análise (entendimento do problema). A questão não está tratando da Verificação e Validação do software, como alguns colegas colocaram nos comentários acima!

  Nos estágios iniciais de um projeto, requisitos têm de ser levantados, entendidos e documentados (atividades de Levantamento, Análise e Documentação de Requisitos). Dada a importância dos requisitos para o sucesso de um projeto, atividades de controle da qualidade devem ser realizadas para verificar, validar e garantir a qualidade dos requisitos, uma vez que os custos serão bem maiores se defeitos em requisitos forem identificados tardiamente. Mesmo quando coletados de forma sistemática, requisitos mudam. Os negócios são dinâmicos e não há como garantir que os requisitos não sofrerão alterações. Assim, é fundamental gerenciar a evolução dos requisitos, bem como manter a rastreabilidade entre os requisitos e os demais artefatos produzidos no projeto (atividade de Gerência de Requisitos).

  Como se pode observar, o tratamento de requisitos envolve atividades de desenvolvimento (Levantamento, Análise e Documentação de Requisitos), gerência (Gerência de Requisitos) e controle da qualidade (Verificação, Validação e Garantia da Qualidade de Requisitos). Ao conjunto de atividades relacionadas a requisitos, dá-se o nome de Processo de Engenharia de Requisitos.

  Espero ter esclarecido! Bons estudos!

• Verificação - Conjunto de atividades que garante que o software implementa corretamente as funções especificadas "seus requisitos".
  

  Validação - Conjunto de atividades que garante que o software construído implementa corretamente o que o cliente realmente deseja.

• Questão muitíssimo mal redigida - nivela quem conhece o assunto com que não o conhece. Lamentável.

• ah mano, que absurdo de questão, desanima até... e tem gente "passando pano" falando que "está realmente correta"... V&V atividades da análise? Avaliação do usuário das atividades definidas? usuário é o quê agora, gerente de projetos?

Questão 315625

• Banca: FCC
• Órgão: TRE-RN
• Ano: 2011
• Provas: FCC - 2011 - TRE-RN - Analista Judiciário - Análise de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

Considere:

I. Cada incremento de software é especificado formalmente e essa especificação é transformada em uma implementação.

II. A correção de software é demonstrada por meio de uma abordagem formal.

III. Não existe teste de defeitos no processo e o teste do sistema concentra-se na avaliação da confiabilidade.

As três características acima pertencem a um processo formal de desenvolvimento de software, denominado

• A. O&M.
• B. CMMI.
• C. Cleanroom.
• D. Cobit.
• E. PMI.

Gabarito: C

Comentários

• Cleanroom é uma metodologia muito utilizada no desenvolvimento de software. É considerada "pesada" pelos padrões da Engenharia de Software, mas muito difundida no desenvolvimento de grandes projetos corporativos.
  O processo é baseado no projeto apurado das funções, que são analisadas pelo método de revisão-par com o objetivo de verificar se fazem realmente o que foram especificadas a fazer.
  
  

  Os princípios básicos do processo de Cleanroom são:

  Desenvolvimento de software baseado nos métodos formais

  o desenvolvimento de Cleanroon faz uso do método caixa estruturada para especificar e projetar um produto de software.A verificação que o projeto implementa corretamente a especificação é realizado pela equipe de revisão.

  Implementação incremental sob controle estatístico da qualidade

  Desenvolvimento Cleanroom usa uma abordagem iterativa, na qual o produto é desenvolvido em incrementos que gradualmente acrescenta novas funcionalidades. A qualidade de cada incremento é medida comparando-se a padrões pré-estabelecidos para verificar que o processo de desenvolvimento é uma conduta aceitável.

  Medição estatística dos testes

  Testes de software em um processo Cleanroom é conduzido como um experimento estatístico. Baseado em especificações formais, um subconjunto representativo das entradas e saídas é selecionado e testado. O exemplo é então analisado estatisticamente para estimar a confiabilidade do software, sendo com isto estimado o nível de segurança.
  
  fonte wikipédia

• Cleanroom (desenvovido pela IBM) se apóia no desenvolvimento incremental do software, em que cada estágio é desenvolvido e sua correção é demonstrada, utilizando-se uma abordagem formal. Não há testes para detectar defeitos no processo, e o teste do sistema é orientado visando medir a confiabilidade do sistema.
  Fonte: Sommerville
• Esta questão poderia ser resolvida por eliminação.
• Exatamente, Leandro Alexandre de Oliveira.
  Mesmo não sabendo o que é Cleanroom, com certeza "processo formal de desenvolvimento de software" não é nenhuma das outras opções!

Questão 319549

• Banca: CESPE / CEBRASPE
• Órgão: INMETRO
• Ano: 2010
• Provas: CESPE - 2010 - INMETRO - Pesquisador - Análise de Requisitos e Qualidade de Software
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

Acerca dos processos para o desenvolvimento de produtos de software de alta qualidade, como a validação e a verificação, assinale a opção correta.

• A. No desenvolvimento de um produto de software, as atividades de validação são normalmente executadas somente sobre o produto final, em ambiente operacional.
• B. A validação, atividade fundamental para a garantia da qualidade de um software, deve ser bem planejada e, durante o desenvolvimento do software, executada com eficácia.
• C. Somente após a codificação de um componente ou de um produto de software é possível validar os requisitos identificados para esse componente ou produto.
• D. Verificação consiste no processo de exame de um produto para a determinação de sua conformidade com as necessidades do usuário, e validação, no exame do resultado de uma atividade para a determinação de sua conformidade com os requisitos estabelecidos para essa atividade.
• E. Revisão por pares é uma técnica de validação que demonstra que o produto correto está sendo desenvolvido.

Gabarito: B

Comentários

• A)O erro está em dizer que a validação é realizada "somente" sobre o produto final...nesse caso seria tarde demais!

  B) Gabarito

  C)Equivalente a alternativa A, o erro está em dizer que somente é possível realizar a validação após a codificação. Validação está relacionada a seguinte pergunta "Está sendo desenvolvido o software correto?". A validação pode ser feito no início e durante o ciclo de vida, quanto antes melhor.

  D)A técnica de revisão não é por pares e sim a Revisão Técnica Formal - RTF.

Questão 334603

• Banca: FCC
• Órgão: TRT - 23ª REGIÃO (MT)
• Ano: 2011
• Provas: FCC - 2011 - TRT - 23ª REGIÃO (MT) - Técnico Judiciário - Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

No processo de desenvolvimento de software, é a atividade que refere-se à garantia de que o sistema de software irá ao encontro de requisitos do produto, como também assegurar que futuros requisitos possam ser atendidos:

• A. Especificação.
• B. Arquitetura de Software.
• C. Análise de Requisitos.
• D. Implementação.
• E. Suporte e Treinamento.

Gabarito: B

Comentários

• a) Especificação - A especificação é a tarefa de descrever precisamente o software que será escrito, preferencialmente de uma forma matematicamente rigorosa. Na prática, somente especificações mais bem sucedidas foram escritas para aplicações bem compreendidas e afinadas que já estavam bem desenvolvidas, embora sistemas de software de missão crítica sejam freqüentemente bem especificados antes do desenvolvimento da aplicação. Especificações são mais importantes para interfaces externas que devem permanecer estáveis.
  
  b) Arquitetura de Software -  A arquitetura de um sistema de software remete a uma representação abstrata daquele sistema. Arquitetura é concernente à garantia de que o sistema de software irá ao encontro de requisitos do produto, como também assegurar que futuros requisitos possam ser atendidos. A etapa da arquitetura também direciona as interfaces entre os sistemas de software e outros produtos de software, como também com o hardware básico ou com o sistema operacional.
  
  c) Análise de Requisitos - A  extração dos requisitos de um desejado produto de software é a primeira tarefa na sua criação. Embora o cliente, provavelmente, acredite saber o que o software deva fazer, esta tarefa requer habilidade e experiência em engenharia de software para reconhecer a incompletude, ambigüidade ou contradição nos requisitos.
  
  d) Implementação - A transformação de um projeto para um código deve ser a parte mais evidente do trabalho da engenharia de software, mas não necessariamente a sua maior porção.
  
  e) Suporte e Treinamento - Uma grande porcentagem dos projetos de software falham pelo fato de o desenvolvedor não perceber que não importa quanto tempo a equipe de planejamento e desenvolvimento irá gastar na criação do software se ninguém da organização irá usá-lo. As pessoas ocasionalmente resistem à mudança e evitam aventurar-se em áreas pouco familiares. Então, como parte da fase de desenvolvimento, é muito importante o treinamento para os usuários de software mais entusiasmados, alternando o treinamento entre usuários neutros e usuários favoráveis ao software. Usuários irão ter muitas questões e problemas de software os quais conduzirão para a próxima fase.
  
  Fonte: http://pt.wikipedia.org/wiki/Processo_de_desenvolvimento_de_software
• A FCC é campeã de retirar na íntegra as questões da wikipedia!
• Eu certamente entraria com recurso nesta questão. A arquitetura de software não pode garantir que os requisitos de um sistema sejam atendidos. Eu posso ter uma arquitetura muito bem projetada, com requisitos implementados de forma totalmente incoerente com o que o usuário quer. Além disso, o enunciado da questão te induz ao erro, uma vez que ele pede uma ATIVIDADE e não um ARTEFATO de engenharia de software.
  
  
• Brincadeira, né?!?!
• "o enunciado da questão te induz ao erro, uma vez que ele pede uma ATIVIDADE e não um ARTEFATO de engenharia de software."
  
  Victor,
  
  O Artefato é o Documento de Arquitetura de Software, Arquitetura de Software é uma atividade sim, e ocorre na etapa de Projeto (Projeto Arquitetural).
  
  Acredito que a questão nos remete a filosofia do RUP de "Arquitetura Executável", ou seja, projetar uma arquitetura robusta que assegure que futuros requisitos possam ser atendidos.
  
  

• wikiCC

Questão 339490

• Banca: COSEAC
• Órgão: DATAPREV
• Ano: 2009
• Provas: COSEAC - 2009 - DATAPREV - Analista de Tecnologia da Informação - Desenvolvimento de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

Emrelação à prática de engenharia de software, identifica as tarefas relacionadas ao processo de comunicação efetiva, que beneficia todo o projeto de engenharia de software:

• A. desenvolver e/ou refinar cenários de usuário / extrair funções e características dos cenários;
• B. revisar a declaração de escopo com o interessado / colaborar com clientes para definir características, funções e comportamento importantes do software;
• C. modelar o domínio da informação / modelar o domínio funcional;
• D. projetar a interface do usuário / especificar todos os algoritmos emumnível de abstração relativamente baixo;
• E. conduzir testes de integração e validação / coordenar testes de aceitação como cliente.

Gabarito: B

Questão 348373

• Banca: FUNCAB
• Órgão: SEMARH-GO
• Ano: 2010
• Provas: FUNCAB - 2010 - SEMARH-GO - Cientista da Computação
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software; Engenharia de Requisitos; Teste de Software

Com relação a aspectos da Engenharia de Software e modelos de desenvolvimento de software, segundo Pfleeger, pode-se afirmar que:

I. durante a etapa de Identificação de Requisitos, obtém-se requisitos que tratam da função e o desempenho do software, a sua interface com outros elementos do sistema, assim como as restrições a qual o software deve atender.

II. durante a etapa de Identificação de Requisitos, o principal foco do analista recai sobre os requisitos que medem a produtividade do sistema, deixando para etapas posteriores a obtenção de requisitos relacionados a qualidade do sistema.

III. na etapa de Definição de Cronograma é que vão ser estabelecidos os critérios que permitirão ao desenvolvedor e ao cliente avaliar a confiabilidade do software construído.

IV. o plano de testes descreve a divisão dos testes em módulos individuais, que tratam as especificidades do sistemas, de modo que se por exemplo um sistema em teste trabalhar com processamento distribuídos em diversas máquinas, os testes de desempenho e funcionais podem ser subdividindo em testes para cada subsistema

Está(estão) correta(s) apenas a(s) afirmativa(s):

• A. somente I.
• B. somente I e IV.
• C. somente II e III.
• D. somente II e IV.
• E. somente II, III e IV.

Gabarito: B

Comentários

• b-

  Identificação dos Requisitos- formação da idéia inicial do sistema e compreensão do domínio do problema. nao faz sentido deixar p/ dopis requisitos relacionados à qualidade do sistema.

Questão 441340

• Banca: FCC
• Órgão: TRE-AP
• Ano: 2011
• Provas: FCC - 2011 - TRE-AP - Analista Judiciário - Análise de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

No V-Model, que mapeia os tipos de teste para cada fase do desenvolvimento de software, Interface Test, Acceptance Test e Release Test correspondem, res- pectivamente, às fases do desenvolvimento

• A. System Specification, Business Case e User Requirements.
• B. System Design, User Requirements e Business Case.
• C. Component Design, User Requirements e Construct Component.
• D. User Requirements, System Specification e Component Design.
• E. Construct Component, User Requirements e Business Case.

Gabarito: B

Comentários

• Business Case<->Release Testing
  Requirements<->Acceptance Testing
  System Specification<->System Testing
  System Design<->Interface Testing
  Component Design<->Component Testing
  <-Construct Component->

Questão 445822

• Banca: COPEVE-UFAL
• Órgão: UNEAL
• Ano: 2009
• Provas: COPEVE-UFAL - 2009 - UNEAL - Analista de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

É um conjunto de aplicações com uma arquitetura comum específica de aplicação. O núcleo comum da família de aplicações é reusado cada vez que uma nova aplicação é necessária. O novo desenvolvimento pode envolver a configuração de componentes específicos, a implementação de componentes adicionais e a adaptação de alguns componentes.

Qual opção abaixo corresponde à descrição anterior?

• A. Modelo de componentes
• B. Componentes de software
• C. Linha de produto de software
• D. Padrão de projeto composite
• E. Padrões de projeto

Gabarito: C

Comentários

• nunca tinha ouvido falar nessa "Linha de produto de software"
  "é um conjunto de sistemas de software que têm um determinado conjunto de funcionalidades em comum, e que satisfazem as necessidades de um determinado segmento de mercado ou missão, e que são desenvolvidos tendo a mesma base (core)."
  
  [1]: http://pt.wikipedia.org/wiki/Linha_de_produtos_de_software

Questão 488665

• Banca: NCE-UFRJ
• Órgão: UFRJ
• Ano: 2008
• Provas: NCE-UFRJ - 2008 - ACAPLAM-PB - Analista de Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

P é um módulo de software que recebe como entrada dois tipos de dados: o primeiro (X) descreve o saldo atual de uma conta corrente e o segundo, (Y) um valor de débito para essa conta. O módulo produz como saída (Z), que descreve o saldo atualizado da conta corrente. As estruturas desses tipos de dados são descritas como:

X=Número+Saldo
Y=Número+Débito
Z=Número+NSaldo

O item que descreve as pré-condições (Pré) e pós- condições (Pós) para essa transação é:

• A. Pré= {X.Número=Y.Número}
  Pós={(Z.NSaldo=X.Saldo-Y.Débito)
  ^ (Z.Número=X.Número)}
• B. Pré={(X.Número?Y.Número)}
  Pós={(Z.NSaldo=X.Saldo+Y.Débito)
  ^(Z.Número=X.Número)}
• C. Pré={(X.Número=Y.Número)}
  Pós={ (Z.NSaldo=X.Saldo-Y.Débito)
  ^(Z.Número?X.Número)}
• D. Pré={X.Número?Y.Número}
  Pós={(Z.NSaldo=X.Número-Y.Débito)
  ^(Z.Número=X.Número)}
• E. Pré={X.Número=Y.Número}
  Pós={(Z.NSaldo=X.Saldo+Y.Saldo)
  ^(Z.Número?X.Número)}

Gabarito: A

Questão 598348

• Banca: CESPE / CEBRASPE
• Órgão: EBC
• Ano: 2011
• Provas: CESPE - 2011 - EBC - Analista - Engenharia de Software
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software; Teste de Software

Julgue os itens seguintes, relativos a testes de software e gerência de projeto.

Nas atividades de desenvolvimento, a validação refere-se ao processo de examinar o resultado de uma atividade para determinar sua conformidade com os requisitos estabelecidos para a mesma atividade, enquanto a verificação se refere ao processo de examinar um produto para determinar sua conformidade com as necessidades do usuário.

• C. Certo
• E. Errado

Gabarito: E

Comentários

• O erro da questão foi inverter os conceitos de verificação e validação de requisitos. As corretas definições seriam:
  
  A verificação tem o objetivo de avaliar se o que foi planejado realmente foi realizado. Ou seja, se os requesitos e funcionalidades documentados foram implementados.
  
  A validação tem o objetivo de avaliar se o que foi entregue atende as expectativas. Ou seja, se os requesitos, independente do que foi planejado, estão implementados para atender ao negócio (cliente).

Questão 616909

• Banca: FCC
• Órgão: MPE-SE
• Ano: 2010
• Provas: FCC - 2010 - MPE-SE - Analista do Ministério Público - Informática II
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

O design de software deve descrever diversos aspectos do software para que, assim, possibilite sua construção. Entre estes aspectos NÃO se inclui

• A. a estrutura estática do sistema e a hierarquia de seus módulos.
• B. a descrição dos dados a serem usados.
• C. as interações entre módulos, incluindo as regras de como elas devem acontecer e porque elas acontecem.
• D. os algoritmos a serem usados.
• E. o desprendimento às restrições e a clareza dos objetivos.

Gabarito: E

Questão 642283

• Banca: FCC
• Órgão: TCE-PR
• Ano: 2011
• Provas: FCC - 2011 - TCE-PR - Analista de Controle - Informática
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

Sobre o processo de revisão de código é correto afirmar:

• A. Desenvolver software, adotando uma prática de revisão de fato, eleva o número de defeitos detectados nas fases iniciais do ciclo de vida, o que auxilia o cumprimento de custo e prazo acordados com o cliente, assim como a aderência aos requisitos definidos e consequente satisfação com o produto entregue.
• B. Revisões constantes sempre impedem uma padronização do código, dificultando uma posterior manutenção.
• C. O esforço gasto para a execução das etapas de revisão é pequeno, podendo chegar no máximo a 5% do desenvolvimento de um software.
• D. É necessário alocar funcionários com alto conhecimento técnico para a realização da revisão de códigos desenvolvidos por programadores inexperientes.
• E. A análise dinâmica de código é um método que visa revisar um código fonte apenas no final de cada fase do projeto para buscar por vulnerabilidades e potenciais defeitos, garantindo que os desenvolvedores programem na próxima etapa de forma correta e segura.

Gabarito: A

Comentários

• a. Desenvolver software, adotando uma prática de revisão de fato, eleva o número de defeitos detectados nas fases iniciais do ciclo de vida, o que auxilia o cumprimento de custo e prazo acordados com o cliente, assim como a aderência aos requisitos definidos e consequente satisfação com o produto entregue.

Questão 642328

• Banca: FCC
• Órgão: TCE-PR
• Ano: 2011
• Provas: FCC - 2011 - TCE-PR - Analista de Controle - Informática
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software; Teste de Software

Sobre o Visual Studio Application Lifecycle Management, considere:

I. É possível criar planos de alto nível que dividem o projeto em incrementos potencialmente entregáveis.

II. É possível criar modelos em diferentes níveis de detalhe e relacioná-los uns aos outros, para testes, e para o seu plano de desenvolvimento.

III. É possível identificar os testes que devem ser executados se você fizer uma mudança em particular.

IV. É possível planejar e acompanhar o seu progresso em relação ao seu planejamento.

Está correto o que se afirma em

• A. I, III e IV, apenas.
• B. I, II, III e IV.
• C. II e III, apenas.
• D. III e IV, apenas.
• E. I e II, apenas.

Gabarito: B

Questão 645355

• Banca: AOCP
• Órgão: BRDE
• Ano: 2012
• Provas: AOCP - 2012 - BRDE - Analista de Sistemas - Desenvolvimento de Sistemas - (Prova TIPO 4)
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

Dentro da Engenharia de Software, encontramos uma gama de conceitos. Embasado nisso, analise as assertivas e assinale a alternativa que aponta a(s) correta(s) sobre Processos de Software.

I. Podemos definir um processo de software como um conjunto de atividades relacionadas que levam à produção de um produto de software.

II. A definição das funcionalidades do software e as restrições a seu funcionamento devem ser definidas na produção de um software. Essa atividade está incluída no processo de software.

III. A validação de software também é uma atividade presente no processo de software.

IV. Os processos de software são complexos e, como todos os processos intelectuais e criativos, dependem de pessoas para tomar decisões e fazer julgamentos. Não existe um processo ideal, a maioria das organizações desenvolve seus próprios processos de desenvolvimento de software.

• A. Apenas I.
• B. Apenas I e III.
• C. Apenas I e IV.
• D. Apenas II, III e IV.
• E. I, II, III e IV.

Gabarito: E

Comentários

• I. Podemos definir um processo de software como um conjunto de atividades relacionadas que levam à produção de um produto de software. 
  
  R.: Este tópico está muito relacionado ao conceito de processo. (entrada --> atividades --> Saída). Fácil de se entender e resolver.
  
  II. A definição das funcionalidades do software e as restrições a seu funcionamento devem ser definidas na produção de um software. Essa atividade está incluída no processo de software. 
  
  R.: Levantamento dos requisitos e restrições faz parte do processo de software. Simples.
  
  III. A validação de software também é uma atividade presente no processo de software. 
  R.: Validação dos requisitos.
  
  IV. Os processos de software são complexos e, como todos os processos intelectuais e criativos, dependem de pessoas para tomar decisões e fazer julgamentos. Não existe um processo ideal, a maioria das organizações desenvolve seus próprios processos de desenvolvimento de software. 
  R.: O processo pode ser adequado a realidade da organização. 
• Um processo de desenvolvimento de software é um conjunto de atividades, parcialmente ordenadas, com a finalidade de obter um produto de software. Os processos de software são atividades complexas e devem se adaptar à realidade da organização.
   
  Atividades genéricas em todos os processos:
   
  - Especificação – o que o sistema deve fazer (funcionalidade) e quais as restrições.
   
  -Verificação – avaliar correção, validação e outros aspectos de qualidade.
   
  Resposta: “E”
   
  http://www.dimap.ufrn.br/~jair/ES/slides/ProcessoDeSoftware.pdf

• Um processo de desenvolvimento de software é um conjunto de atividades, parcialmente ordenadas, com a finalidade de obter um produto de software. É estudado dentro da área de Engenharia de Software, sendo considerado um dos principais mecanismos para se obter software de qualidade e cumprir corretamente os contratos de desenvolvimento, sendo uma das respostas técnicas adequadas para resolver a Crise do software.

  Atividades: Analise Economica, Analise de Requisitos, Especificação, Arquitetura, Implementação, Teste, Documentação, Suporte/Treinamento, Manutenção 

Questão 669604

• Banca: CONSULPLAN
• Órgão: TSE
• Ano: 2012
• Provas: CONSULPLAN - 2012 - TSE - Analista Judiciário - Análise de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software; Gerência de Configuração

O Subversion ou simplesmente SVN é uma ferramenta de controle de versão de projeto muito poderosa que permite, além do desenvolvimento colaborativo a partir de um repositório único, merge de conteúdo, armazenamento de logs e geração de estatísticas diversas. Dentre as boas práticas, toda revisão deve ser comentada para facilitar o entendimento das alterações realizadas. Além disso, o código no diretório trunk deve sempre estar pronto para ser compilado e colocado em produção, se necessário. Nesse sentido, uma ferramenta de Integração Contínua deve ser utilizada para a geração de builds de teste a cada commit em todas as noites ao longo da semana. Uma dessas ferramentas é conhecida por

• A. TestControl.
• B. DataControl.
• C. CruiseControl.
• D. BranchControl.

Gabarito: C

Comentários

• CruiseControl é tanto uma integração contínua da ferramenta e uma estrutura extensível para a criação de um processo de compilação personalizada contínua. Inclui dezenas de plugins para uma variedade de controles de fonte, construir tecnologias e sistemas de notificações, incluindo e-mail e mensagens instantâneas. A interface web fornece detalhes sobre as compilações atuais e anteriores. E a distribuição CruiseControl padrão é aumentada através de uma rica seleção de ferramentas de 3 .

• Quem não tem acesso: --> C

Questão 675484

• Banca: CONSULPLAN
• Órgão: TSE
• Ano: 2012
• Provas: CONSULPLAN - 2012 - TSE - Programador de computador
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software; Engenharia de Requisitos

Um processo de desenvolvimento de software provê uma base para a produção organizada de software, usando uma coleção de técnicas e notações pré-definidas. O desenvolvimento de software apresenta uma sequência de etapas bem definidas, cada uma com uma finalidade, entrada e saída distintas. Nesse processo, duas etapas são sintetizadas a seguir. Observe.

I. Tem por objetivo a especificação de requisitos construindo modelos. É necessário compreender um problema, antes de experimentar uma solução.

II. Tem por objetivo o desenvolvimento e ajuste dos modelos do mundo real da análise, de modo que sejam passíveis de ser implementados no computador. É necessário determinar métodos para realizar as operações.

As duas etapas descritas são denominadas, respectivamente,

• A. análise e projeto de classes.
• B. análise e plano de implantação.
• C. implementação e projeto de classes.
• D. implementação e plano de implantação.

Gabarito: A

Comentários

• É na análise tem por objetivo a especificação de requisitos construindo modelos. É necessário compreender um problema, antes de experimentar uma solução. 
  
  Projeto de classes tem por objetivo o desenvolvimento e ajuste dos modelos do mundo real da análise, de modo que sejam passíveis de ser implementados no computador. É necessário determinar métodos para realizar as operações. 
  
  LETRA A

Questão 675490

• Banca: CONSULPLAN
• Órgão: TSE
• Ano: 2012
• Provas: CONSULPLAN - 2012 - TSE - Programador de computador
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software; Metodologia de desenvolvimento de software

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

• A. projeto.
• B. processo.
• C. implantação.
• D. implementação.

Gabarito: B

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

Questão 677461

• Banca: FEC
• Órgão: DETRAN-RO
• Ano: 2007
• Provas: FEC - 2007 - DETRAN-RO - Analista de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

Todo desenvolvimento de software pode ser caracterizado como um ciclo de solução de problemas, no qual são encontrados quatro estágios distintos. Esses estágios são conhecidos como:

• A. planejamento, execução, controle e ajuste
• B. situação atual, definição do problema, desenvolvimento técnico e integração da solução;
• C. planejamento, desenvolvimento, controle e execução;
• D. situação atual, definição do problema, abordagem técnica e abordagem administrativa;
• E. planejamento, execução, controle e realimentação

Gabarito: B

Questão 697324

• Banca: FCC
• Órgão: TRE-SP
• Ano: 2012
• Provas: FCC - 2012 - TRE-SP - Analista Judiciário - Análise de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

Durante a fase inicial do ciclo de vida do desenvolvimento de sistemas, na etapa de investigação, a tarefa que determina a probabilidade de sucesso do sistema proposto e propicia uma avaliação superficial da área técnica, econômica e comportamental do projeto, sendo decisivamente importante para o processo do desenvolvimento de sistemas é chamada

• A. estudo de caso.
• B. análise de requisitos.
• C. análise de equilíbrio.
• D. estudo de viabilidade.
• E. design lógico do sistema.

Gabarito: D

Comentários

• nesse momento ainda não temos o rpojeto iniciado , uma vez que é necessario primeiramente verificar se ele é exequivel , dentro do prazo , com orçamento e escopo especificado. 
• Eu não entendi dessa forma Valfrido.
  A frase "e propicia uma avaliação superficial da área técnica, econômica e comportamental do projeto" no meu entendimento o enunciado diz  que tanto a avaliação técnica, econômica e comportamental é superficial
  
  Acredito que a palavra chave é "investigação". O estudo de viabilidade tem, segundo Sommerville, 8 Edição, o objetivo de responder questões como:
  - o sistema contribui para os objetivos gerais da organização?
  - o sistema pode ser implementado com a tecnologia atual e dentro das restrições definidas de custo e prazo?
  - o sistema pode ser integrado e a outros sistemas já implantados?
• a palavra "viabilidade" praticamente define a questão.
• Letra D. Inicia-se com o Estudo de Viabilidade, segue para a Identificação dos Requisitos, Análise dos Requisitos (e Negociação), Especificação e Documentação, Validação, e Gestão de Requisitos.
• a)      Estudo de caso é a avaliação de algo que foi implementado, onde informações são coletadas e um veredicto é dado sobre o que esta sendo avaliado.
  b)      Análise de requisitos ocorre depois que o projeto já foi aprovado, ou seja, a viabilidade já foi avaliada
  c)      Esse termo esta mais relacionado ao comportamento de mercado do que do desenvolvimento de software em si.
  d)      Questão correta!
  e)      Essa fase envolve a elaboração de diagramas UML e o projeto arquitetural do sistema, portanto já é uma fase mais avançada do projeto.
• "a tarefa que determina a probabilidade de sucesso do sistema proposto"
  
  Estudo de viabilidade por causa da parte grifada em vermelho.

Questão 700180

• Banca: FUNIVERSA
• Órgão: PC-DF
• Ano: 2012
• Provas: FUNIVERSA - 2012 - PC-DF - Perito Criminal - Informática
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

Em muitos casos, é desejável criar softwares com proteção contra reversão de código, ou seja, desenvolver programas que apliquem técnicas antiengenharia-reversa. Assinale a alternativa que apresenta somente exemplos dessas técnicas.

• A. transformações de dados, confusão de registradores, técnicas ativas de antidebugging.
• B. ofuscação de código, eliminação de informação simbólica, uso de árvores transversais.
• C. transformações no controle de fluxo, transformações de dados, ofuscação e encriptação de código.
• D. encriptação de código, bloqueio de acesso à memória, confusão de disassemblers.
• E. varredura linear recursiva, técnicas ativas de antidebugging, transformações no controle de fluxo.

Gabarito: C

Comentários

• Os métodos abordados para antricracking são: Eliminação de Informação Simbólica, Técnicas Ativas de AntiDebugging, Confundir Disassemblers, Encriptação e Ofuscação de Código e Transformações no Controle de Fluxo.
  3.1 Eliminação de Informação Simbólica (Eliminating Symbolic Information – ESI)
  

  A abordagem mais óbvia para confundir quem está lendo diretamente um código disassemblado é eliminar toda e qualquer informação textual do programa.

  Se as strings no código assembly não estivessem transparentes, ou seja, se fossem diferentes da forma como vemos no programa em execução, o trabalho seria realmente bem mais difícil e demorado.

  Em um binário executável que acessa diretamente o hardware, não-bytecode, podemos simplesmente esconder toda a informação do programa. Já em programas baseados em bytecodes os executáveis muitas vezes contém uma grande quantidade de informação simbólica, como nome de classes, nome de membro de classes e a tabela de objetos instanciados. Estas informações podem ser extremamente úteis para quem disassemblar o código pois com base nelas é possível localizar pontos-chave do código.

  
  http://www.sawp.com.br/blog/?p=131
  
  

• 3.2 Ofuscação e Encriptação de Código (Code Obfuscation and Encryption – COE)

  Encriptação e ofuscação são técnicas utilizadas para reduzir a vulnerabilidade de crackear programas. Normalmente são utilizadas quando a ESI não é suficiente para proteção anticracking.

  Consiste em modificar o layout do programa, a lógica e os dados de forma que reorganize o código, tornando-o menos legível, mas mantendo a funcionalidade para o usuário final.

  COE difere-se da Eliminação Simbólica por alterar a estrutura do código em sí e não dos nomes dos componentes constantes.
  
  3.3 Técnicas Ativas de Antidebuggin (Active AntiDebugger Techniques ? AADT)

  Considerando que as atividades de cracking são feitas em grande parte com o uso de debuggers a possibilidade de incorporar no programa algum código que complique o processo de depuração é desejável para o aumento na proteção do código.

  Técnicas AADT são altamente efetivas quando combinadas com encriptação de código. Pois, ao encriptar o programa, força os crackers executá-lo dentro de um debugger e o código AADT não permite sua depuração.

  Existem dezenas de truques utilizados para antidebuggin. Mas quase todos são dependentes de plataforma ou altamente dependente de sistemas operacionais.

  As implementações de AADT oferecem alguns riscos e algumas vezes costumam gerar exceções não tratáveis e causar mal funcionamento do programa quando detecta um debugger no sistema, mesmo se o programa não estiver anexado ao debugger.
  
  http://www.sawp.com.br/blog/?p=131

• 3.4 Confundindo Disassemblers (Confusing Disassemblers – CD)

  Enganar disassemblers para inibir a atividade de crackers não é uma forma muito resistente de antireversing. Entretanto, é a mais popular.

  A estratégia é simples: Nas arquiteturas de processadores que usam instruções de tamanho variável (como IA-32) é possível enganar o disassembler inserindo dados impróprios no começo da instrução. Isto faz com que o disassembler perca a sincronização e disassemble o resto do código incorretamente (colocando 1 bit a direita ou a esquerda, o conjunto de bits seguintes implicarão na perda da instrução).
  
  3.5 Transformações no Controle de Fluxo (Control Flow Transformations – CFT)

  Transformações no controle de fluxo consistem em alterar a ordem e o fluxo de um programa para reduzir a legibilidade do código ao gerar assembly. Podendo ser definida em 3 categorias: computação de transformações, agregação de transformações e ordenação de transformações.

  A Computação de Transformações modifica a estrutura de fluxo original para trazer uma funcionalidade equivalente ao usuário final, mas tornando mais difícil de se reverter o código. Isso pode ser feito removendo o fluxo de informação do programa e adicionando outra declaração de controle de fluxo que complicaria o entendimento para quem for ler o código em baixo nível.

  A Agregação de Transformações destrói a estrutura de alto nível do programa, quebrando a abstração de linguagem de alto nível em tempo de programação. A idéia básica é desfazer essa abstração de modo que após a compilação ser feita a funcionalidade do programa se mantenha, mas quando o código seja desassemblado a estrutura pareça absurda.

  Por fim Ordenação de Transformadas são as menos poderosas e consistem em randomizar a ordem das operações em um programa na esperança de reduzir a legibilidade do programa.

  3.6 Transformações de Dados ( Data Transformations – DT )

  Transformações de dados focam em encriptar tanto os dados quanto a estrutura do programa. Essa associação é interessante pois identificar uma importante estrutura de dados é um dos passos fundamentais para entender como o programa funciona.
  
  http://www.sawp.com.br/blog/?p=131

Questão 701629

• Banca: FCC
• Órgão: TRE-SP
• Ano: 2012
• Provas: FCC - 2012 - TRE-SP - Técnico Judiciário - Programação de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

NÃO é uma característica do desenvolvimento orientado a comportamento:

• A. Combinar a linguagem ubíqua, usada no processo de desenvolvimento de software com a linguagem nativa usado pelo desenvolvedor.
• B. Utilizar Desenvolvimento de Fora para Dentro, envolvendo as partes interessadas.
• C. Desenvolver os testes com foco nos detalhes técnicos para entender a causa de uma falha.
• D. Exemplificar os requisitos de uma aplicação quebrando-os em cenários, para ilustrar um aspecto específico de comportamento da aplicação.
• E. Os fragmentos do cenário, ou seja, as entradas, eventos e saídas, devem ser suficientemente detalhados para serem representados diretamente no código.

Gabarito: C

Comentários

• Os testes devem ser feitos com base em funcionalidades e não detalhes técnicos

• As práticas de BDD incluem:

  • Envolver as partes interessadas no processo através de Outside-in Development (Desenvolvimento de Fora pra Dentro)
  • Usar exemplos para descrever o comportamento de uma aplicação ou unidades de código
  • Automatizar os exemplos para prover um feedback rápido e testes de regressão
  • Usar deve (should em inglês) na hora de descrever o comportamento de software para ajudar esclarecer responsabilidades e permitir que funcionalidades do software sejam questionadas
  • Usar dublês de teste (mocks, stubs, fakes, dummies, spies) para auxiliar na colaboração entre módulos e códigos que ainda não foram escritos
  http://pt.wikipedia.org/wiki/Behavior_Driven_Development
• Behaviour Driven Development (ou BDD) - Desenvolvimento Orientado por Comportmento
  BDD é técnica de desenvolvimento ágil que visa integrar regras de negócios com linguagem de programação, focando o comportamento do software. Além disso, pode-se dizer também, que BDD é a evolução do TDD. Isto porque, os testes ainda orientam o desenvolvimento, ou seja, primeiro se escreve o teste e depois o código.
  
  O foco em BDD é a linguagem e as interações usadas no processo de desenvolvimento de software. Desenvolvedores que se beneficiam destas técnicas escrevem os testes em sua língua nativa em combinação com a linguagem ubíqua (Ubiquitous Language).
  
  Isso permite que eles foquem em por que o código deve ser criado, ao invés de detalhes técnicos, e ainda possibilita uma comunicação eficiente entre as equipes de desenvolvimento e testes.

Questão 705172

• Banca: UPENET/IAUPE
• Órgão: JUCEPE
• Ano: 2012
• Provas: UPENET - 2012 - JUCEPE - Analista de Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

Para projetar um sistema de maneira que seja robusto face às mudanças de requisitos ou à inserção de novos requisitos, você deve levar em conta como o sistema pode necessitar mudar ao longo de sua vida. Porém, para tal, precisamos de estratégias para nos ajudar a segmentar um sistema em módulos, de tal maneira que eles tenham uma melhor organização, isto é, que eles possam ser divididos em partes que possam ser separadamente desenvolvidas e mantidas. Nesse contexto, a coesão e o acoplamento são formas de se avaliar se a segmentação de um sistema em módulos ou em componentes foi eficiente. Acerca da aplicação desses princípios, assinale a opção CORRETA.

• A. A modularização do programa em partes especializadas pode aumentar a qualidade desses componentes, embora possa prejudicar o seu reaproveitamento em outros programas.
• B. O baixo acoplamento entre módulos resulta em menor propensão a efeitos de propagação.
• C. Os componentes ou os módulos devem apresentar baixa coesão e um alto grau de acoplamento.
• D. Os componentes ou os módulos devem ter coesão baixa e acoplamento alto.
• E. Um benefício da alta coesão é permitir realizar a manutenção em um módulo, sem se preocupar com os detalhes internos dos demais módulos.

Gabarito: B

Questão 705175

• Banca: UPENET/IAUPE
• Órgão: JUCEPE
• Ano: 2012
• Provas: UPENET - 2012 - JUCEPE - Analista de Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

Identifique se são Verdadeiras (V) ou Falsas (F) as afirmativas que seguem com relação a ciclo de vida de software.
( ) Pode-se considerar que o modelo de prototipagem serve como um mecanismo para a identificação dos requisitos de um sistema.
( ) Pode-se considerar que o modelo proposto por Barry Boehm em 1988 apresenta-se como um modelo, em que em cada iteração ocorre uma análise de risco.
( ) Pode-se considerar o modelo cascata (ou clássico) como adequado para controlar riscos e requisitos voláteis durante o desenvolvimento do sistema.
( ) O Desenvolvimento Rápido de Aplicações (RAD – Rapid Application Development) pode fazer uso do processo de desenvolvimento conjunto de aplicações (JAD – Joint Application Development) para coletar dados e analisar requisitos.

Assinale a alternativa que indica a sequência CORRETA.

• A. F; F; F; F.
• B. V; F; F; V.
• C. V; F; V; V.
• D. V; V; F; V.
• E. F; V; V; F.

Gabarito: D

Comentários

• Alguém sabe qual foi esse modelo proposto em 88???

• Modelo Espiral.

• d-

  Espiral é um modelo medroso. Muito foco em risco. Prototipagem produz representação visual das funcionalidades que o software terá, avaliando as características antes de desenvolver e ver usabilidade, com envolvimento direto do usuário. No modelo cascata se fazia um protótipo apenas como mecanismo para identificar ou auxiliar na identificação e elaboração dos requisitos finais do sistema e depois era descartado. Mas por prototipação seu conceito tornou-se evolutivo, e o próprio protótipo passou a ser entregue.

  
  Através deste modelo os desenvolvedores iniciam a especificação (requisitos) e codigo das partes essenciais em um protótipo, adicionando até o final. 

   

  Cascata é sequencial e rígido, improprio para requisitos volateis

Questão 705319

• Banca: CESGRANRIO
• Órgão: Petrobras
• Ano: 2012
• Provas: CESGRANRIO - 2012 - Petrobras - Técnico de Exploração de Petróleo Júnior - Informática
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

Dentre os modelos de Processo de Software, um dos mais conhecidos é o linear sequencial, que pode ser descrito como sendo composto de 4 fases sequenciais:
Análise, Projeto, Codificação e Testes.
A fase de Projeto caracteriza-se por ser onde o(s)

• A. comportamento necessário do software é entendido.
• B. domínio de informação é entendido.
• C. código pode ser gerado automaticamente.
• D. requisitos de sistema e do software são levantados.
• E. requisitos são traduzidos em uma representação do software.

Gabarito: E

Comentários

• a) comportamento necessário do software é entendido Análise
  b) domínio de informação é entendido. Análise
  c) código pode ser gerado automaticamente. Codificação
  d) requisitos de sistema e do software são levantados. Análise
  e) requisitos são traduzidos em uma representação do software. Projeto
• O Modelo Clássico/Linear Sequencial/Cascata possui 6 fases:
  • Levantamento de Requisitos: tem por objetivo propiciar que usuários e desenvolvedores tenham a mesma compreensão do problema a ser resolvido.
  • Análise: tem por objetivo construir modelos que determinam qual é o problema para o qual estamos tentando conceber uma solução de software.
  • Projeto: estágio no qual o modelo de análise terá de ser adaptado de tal modo que possa servir como base para implementação no ambiente alvo.
  • Codificação (implementação): a codificação do sistema é efetivamente executada.
  • Teste: consiste na verificação do software. 
  • Implantação: entrada em produção do sistema.
  
  À Luz do texto acima podemos analisar as opçõpes:
  a) Análise.
  b) O mais indicado seria o levantamento de requisitos, mas como na questão só fala em análise 
  c) Codificação
  d) Levantamento de Requisitos seria o certo, mas como na questão não se falou nisso poderiamos assumir como Análise
  e) Projeto. RESPOSTA DA QUESTÃO

Questão 720556

• Banca: ESAF
• Órgão: CGU
• Ano: 2008
• Provas: ESAF - 2008 - CGU - Tecnologia da Informação - Desenvolvimento de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

A Engenharia de Software é uma disciplina da engenharia que se ocupa de todos os aspectos da produção de software, desde os estágios iniciais de especificação do sistema até a manutenção do mesmo. A Engenharia de Software adota métodos de engenharia de software que

• A. são um conjunto de atividades, cuja meta é o desenvolvimento ou a evolução do software.
• B. são uma representação simplificada de um processo de software, apresentada a partir de uma perspectiva específica.
• C. são abordagens de estruturadas para o desenvolvimento de software, que incluem modelos de sistemas, notações, regras, recomendações de projetos e diretrizes de processos.
• D. se ocupam da teoria e dos fundamentos de desenvolvimento de software.
• E. se ocupam de todos os aspectos relacionados ao desenvolvimento de sistemas com base em computadores, incluindo hardware, software e engenharia de processos.

Gabarito: C

Comentários

• e uma questão que tem que ler com muita calma !!!!!!!!!!!!!

  
  

  Letra C correta
  

•  

  a) são um conjunto de atividades, cuja meta é o desenvolvimento ou a evolução do software. - Processo de Software

  b) são uma representação simplificada de um processo de software, apresentada a partir de uma perspectiva específica.- Modelo de Processo de Software

  c) são abordagens estruturadas para o desenvolvimento de software, que incluem modelos de sistemas, notações, regras, recomendações de projetos e diretrizes de processos. - Método de Engenharia de Software

  d) se ocupam da teoria e dos fundamentos de desenvolvimento de software. - Ciência da Computação

  e) se ocupam de todos os aspectos relacionados ao desenvolvimento de sistemas com base em computadores, incluindo hardware, software e engenharia de processos. - Engenharia de Sistemas

   

• c-

  Ian SOmmerville - Eng. SW é uma disciplina da eng. sistemas e abrange todos os aspectos de producao de software, do levantamento de requisitos ao deploy e manutencao. Sao atividades parcialmente ou totalemnte ordenadas para obter software de qualidade.

Questão 726901

• Banca: INSTITUTO CIDADES
• Órgão: TCM-GO
• Ano: 2012
• Provas: INSTITUTO CIDADES - 2012 - TCM-GO - Auditor de Controle Externo - Informática
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software; Outros modelos de Processo de Software; Processos de Software

De acordo com a engenharia de software, como todo produto industrial, o software possui um ciclo de vida. Cada fase do ciclo de vida possui divisões e subdivisões. Em qual fase avaliamos a necessidade de evolução dos softwares em funcionamento para novas plataformas operacionais ou para a incorporação de novos requisitos?

• A. Fase de operação;
• B. Fase de retirada;
• C. Fase de definição;
• D. Fase de design.
• E. Fase de desenvolvimento;

Gabarito: B

Comentários

• O ciclo de vida de um software descreve as fases pelas quais o software passa desde a sua concepção até ficar sem uso algum. Segue abaixo a classificação de 4 fases que são delimitadas por diversos eventos típicos em diversos ciclos de vida. Fase de definição: Busca - se a identificação de problemas para que possam elaborar propostas de solução de sistemas computacionais que resolvam tais problemas. Fase de desenvolvimento: Inclui todas as atividades que tem por objetivo a construção do produto. Ela inclui principalmente o design, a implementação e a verificação e validação do software. Fase de operação: Envolve diferentes tipos de atividades como (Distribuição e entrega; ;Instalação e configuração; Utilização e Manutenção) Fase de retirada: Trata da substituição de softwares legados por plataformas com tecnologia mais atualFonte: http://engenhariadesoftware.blogspot.com.br/2007/02/ciclo-de-vida-do-software-parte-1.html?m=1
• Seguindo o comentário acima, na fase de RETIRADA o software é substituído.
  Então como vou EVOLUIR o software,segundo o enunciado, se ele será trocado ?
• Na Fase de Retirada o software precisa evoluir para novas plataformas operacionais ou para a incorporação de novos requisitos.
• Até entendi que é durante a fase de retirada que o software será substituído por tecnologias mais modernas etc. Porém, não seria na fase de operação do software que essa necessidade seria avaliada, para na fase de retirada essa substituição necessária ser implementada?

• Concordo com o RWerneck, por isso coloquei a letra A. Fase de retirada nem é uma coisa que existe em todo projeto de software. Muito estranho isso, nunca tinha ouvido falar. Já ouvi falar em fase de melhoria... mas fica o aprendizado

• Onde existem essas definições. Qual fonte?
  

• Isso é o que ocorre quando concursos são realizados por bancas de menor expressão e que não procuram de fato reconhecer as competências de quem faz a prova, e ainda, não se baseiam na literatura consagrada para elaboração de suas questões. Decepcionante!

• A questão está errada. "...avaliamos a necessidade de evolução dos softwares em funcionamento para novas plataformas operacionais ": Fase de Retirada [OK]. "incorporação de novos requisitos": Fase de Operação [NOK]

• Eu ia responder letra B (fase de retirada), mas pensei: "nao eh na fase de operacao que avaliamos a necessidade de melhorias?"
  Acabei errando na letra A tb

• abri uma discussão lá nesse site Marcos..

• Pois eh galera, o software nao foi retirado, mas sim atualizado...nao foi substituido por outro, mas evoluido, e aí?

• Ciclo de vida
  • Fase de definição
  – Análise e Especificação
  – Estudo de Viabilidade
  – Estimativas Planejamento
  • Fase de desenvolvimento
  – Design
  – Implementação e integração
  – Verificação e Validação
  • Fase de operação
  – Distribuição, Instalação e Configuração
  – Utilização e administração
  – Manutenção
  – corretiva, evolutiva e adaptativa
  • Fase de retirada
  – Migração, reengenharia, engenharia reversa

   

  https://www.dimap.ufrn.br/~jair/ES/slides/CiclodeVida.pdf

• Fonte: vozes da cabeça do examinador

Questão 749470

• Banca: VUNESP
• Órgão: TJM-SP
• Ano: 2011
• Provas: VUNESP - 2011 - TJM-SP - Analista de Sistemas - Judiciário
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software; Teste de Software

Considere os seguintes possíveis fatores que afetam a precisão da estimativa de confiabilidade durante os testes estatísticos no processo de desenvolvimento de software.

I. A validade do perfil de uso.

II. O número de casos de teste efetuados.

III. A linguagem de programação usada para implementar o código.

Sobre os fatores, está correto o contido em

• A. I, apenas.
• B. I e II, apenas.
• C. I e III, apenas
• D. Il e III, apenas.
• E. I, II e III.

Gabarito: B

Comentários

• Resposta correta é a letra B, por que?
• Também, gostaria de saber por que a letra B? Pela lógica eu até acertei aqui estudando, mas para mim só a frase nº II está correta...
• PAGINA 401(CAPÍTULO 21) DO LIVRO ENGENHARIA DE SOFTWARE - SOMMERVILLE. SEXTA EDIÇÃO.
  RESPOSTA LETRA "B".
  
• Em [1] fala que existem 4 etapas pra medir a confiabilidade de um sistema, vou dar uma resumida:
  
  1) Estudo de sistemas existentes para estabelecer um perfil operacional.
  2) Constrói um conjunto de dados de teste que reflitam esse perfil.
  3) Testa o sistema usando esses dados.
  4) Depois de observar o número de falhas estatisticamente significativas, você calcula a confiabilidade.
  
  Nas outras páginas ele se aprofunda nesses passos, mas acredito que já dá pra ver que a I e II estão corretas. A III acredito que está errada porque [1] não fala em nenhum momento em linguagem de programação.
  
  [1] Sommerville, Engenharia de Software, 8ª Edição página 375

• Número de casos de testes efetuados?? Depende mais da qualidade do que da quantidade. 

• A linguagem de programação usada para implementar o código não é um fator de confiabilidade

• Prezados,
  
  Essa questão foi feita com base no livro do Pressman.
  Segundo o autor , página 498, o teste estatístico de uso "resume-se no teste do software de maneira que os usuários pretendem usá-lo".
  
  Para esse teste, o autor especifica cinco passos que devem ser utilizados :
  1 - Devem ser criados cenários de uso
  2 - É especificado um perfil de uso
  3 - São gerados os casos de teste com base no perfil
  4 - São executados os testes, os dados de falhas são registrados e analisados.
  5 - A confiabilidade é calculada e certificada.
  
  Vemos que a linguagem da programação que foi utilizada não interfere em nada.
  
  Portanto a alternativa correta é a letra B
  
  

• Perfeito.

Questão 749527

• Banca: VUNESP
• Órgão: TJM-SP
• Ano: 2011
• Provas: VUNESP - 2011 - TJM-SP - Analista de Sistemas - Judiciário
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software; Teste de Software

Considere as seguintes atividades de um processo de desenvolvimento de software:

I. gerência de requisitos;

II. modelagem de classes de projeto;

III. definição de testes de software.

Das atividades citadas, pode-se afirmar que o Enterprise Architect versão 9, na edição Ultimate, fornece suporte direto para a(s) atividade(s) contida(s) em

• A. I, apenas.
• B. II, apenas-
• C. I e II, apenas.
• D. Il e III, apenas.
• E. I, II e III.

Gabarito: E

Comentários

• Correta letra E
  
  Fonte: http://www.sparxsystems.com/products/ea/9/
• Prezados,
  
  Segundo o site do fabricante, a ferramenta trás muitas funcionalidades, entre elas ferramentas de modelagem , análise ,testes , produtividade 
  
  Fonte : http://www.sparxsystems.com/products/ea/9/
  
  Portanto a alternativa correta é a letra E
  
  

Questão 757789

• Banca: FUMARC
• Órgão: TJ-MG
• Ano: 2012
• Provas: FUMARC - 2012 - TJ-MG - Oficial Judiciário - Assistente Técnico De Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

Em relação aos modelos de processos de software, pode-se dizer que os modelos incremental e evolucionário possuem a característica de serem iterativos. Assinale a alternativa que melhor descreve um modelo de produção de software iterativo.

• A. Os incrementos de um software são entregues ao cliente de uma só vez.
  
• B. Um modelo de produção de software iterativo é composto pelas fases de análise de requisitos, projeto, implementação, testes (validação), integração e manutenção de software.
  
• C. A abordagem iterativa possibilita desenvolver um sistema de software de forma incremental, permitindo ao desenvolvedor tirar vantagem daquilo que foi aprendido durante a fase inicial de desenvolvimento de uma versão do sistema. O aprendizado ocorre simultaneamente tanto para o desenvolvedor, quanto para o usuário do sistema.
  
• D. Permite que sejam desenvolvidas versões cada vez mais completas do software.
  

Gabarito: C

Comentários

• Alguém sabe me dizer porque a alternativa D está errada?
  Na minha opinião, tanto a questão C quanto a D estão corretas.
  
  Na verdade a alternativa C até me deixou em dúvida por causa do trecho: "permitindo ao desenvolvedor tirar vantagem daquilo que foi aprendido durante a fase inicial de desenvolvimento de uma versão do sistema"
• a) é o conceito do modelo em cascata que não é iterativo nem incremental
  b) o conceito de modelo iterativo não tem nada a ver com as fases.
  c) é o conceito de iteração. É o feedback, a retroalimentação que faz com que haja um maior aprendizado e que, com esse aprendizado, haja um amadurecimento.
  d) é a definição do modelo evolucionário.

• 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 estrategias de retrabalho. A alternativa ao desenvolvimento incremental é desenvolver todo o sistema com uma integração única.

  Desenvolvimento iterativo é uma estrategia 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 contrario, a saída de uma iteração é examinada para modificação, e especialmente para revisão dos objetivos das iterações sucessivas.
  
  fonte: http://pt.wikipedia.org/wiki/Desenvolvimento_iterativo_e_incremental

• Interpretrei exatamente como o Gabriel Abreu.

  A primeira frase da alternativa C ficou meio estranha. Deveria ter sido "... durante (ou após) a iteração anterior...".

  A opção D também vale para o modelo iterativo, i.e. permite o desenvolvimento de versões de um sistema cada vez mais completas, em termos de atendimento a requisitos e aceitação do cliente. Não imagino interpretação que invalide essa alternativa.

• Concordo que por conceito a letra D tem validade, visto que a cada iteração é entregue uma versão mais completa do software ao cliente.
  

• Letra C NÃO! Durante a fase INICIAL? É durante todo o desenvolvimento

• Por eliminação eu marquei a letra C. Seguindo o raciocínio da Rosana Andrade, a primeira que descartei foi a letra A, depois a D (porque era modelo evolucionário. A letra B não tem nada a ver com o que a questão pede. Sobrou a letra C.  :)

• O Espiral é Iterativo, mas não é incremental... nesse caso... a letra "d" esta errada. 

• Segundo Presman, sétima edição, pág. 62: 

  "Modelos evolucionários são modelos iterativos. Apresentam características que possibilitam desenvolver versões cada vez mais completas do software." 

   d) Permite que sejam desenvolvidas versões cada vez mais completas do software.

  Ou seja, a definição da opção "d" também se aplica a Iteração.

  Pra mim tanto a letra c, quanto a d estão corretas.

  
  

  
  

• Na verdade, a letra D estaria um pouco mais correta do que a C, pois "d) Permite que sejam desenvolvidas versões cada vez mais completas do software." se encaixa também no modelo incremental, pois à medida que vamos entregando os incrementos o software vai se tornando cada vez mais completo!
  Por outro lado, este: "O aprendizado ocorre simultaneamente tanto para o desenvolvedor, quanto para o usuário do sistema." implica que o usuário se encontra presente e aprendendo durante todo o ciclo de vida do software, o que não é verdade, pois ele influencia majoritariamente na fase de planejamento!

• A letra B se refere ao modelo em cascata descrito por Royce

• Mario, a letra D,  se encaixa mais com abordagem evolucionária do que com iterativa,

• Iterativo é gênero. Evolucionário e incremental são tipos desse gênero.

  Sendo assim, o modelo iterativo tem o objetivo de aplicar a repetição das fases de um processo de software de forma cíclica. Isto é feito com o objetivo de melhor especificar os requisitos à medida que o produto vai sendo desenvolvido.

  O modelo evolucionário, de forma abstrata, é que nem um desenho, que vc primeiro faz os contornos e depois vai botando as cores e evoluindo o desenho.

  O modelo incremental é que nem um quebra-cabeças. Vc tem pedaços prontos já com os contornos e cores e vai juntando todos estes pedaços completos a cada iteração.

  Mesmo tendo a letra C como gabarito, eu discordo do trecho: "foi aprendido na fase inicial".

Questão 770092

• Banca: CESPE / CEBRASPE
• Órgão: Banco da Amazônia
• Ano: 2012
• Provas: CESPE - 2012 - Banco da Amazônia - Técnico Científico - Análise de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

A respeito de desenvolvimento e manutenção de sistemas, julgue os
itens consecutivos.

Um programa robusto produz as saídas corretas para todas as entradas previstas pela aplicação do programa.

• C. Certo
• E. Errado

Gabarito: E

Comentários

• Softwar robusto é aquele que é capaz de lidar com entradas não previstas, que não estão explicitamente definidas em sua aplicação. A robustez de um software é a capcidade de um software funcionar mesmo em condições anormais.

• Olha, se o software é capaz de lidar com entradas não previstas, também é capaz de lidar com as previstas. Das duas uma ou a pergunta está mal formulada ou a resposta não é essa.

• Concordo com o Ricardo.

• Pegadinha muito mal formulada...

Questão 773482

• Banca: CESPE / CEBRASPE
• Órgão: MEC
• Ano: 2011
• Provas: CESPE - 2011 - MEC - Gerente de Projetos
• Disciplina: Engenharia de Software
• Assuntos: Conceitos Básicos em Engenharia de Software; Desenvolvimento de Software

Com relação a conceitos gerais da engenharia de software, julgue
os itens seguintes.

A engenharia de software, disciplina relacionada aos aspectos da produção de software, abrange somente os processos técnicos do desenvolvimento de software.

• C. Certo
• E. Errado

Gabarito: E

Comentários

• ERRADO
  A Engenharia de Software é uma atividade de especificação, projeto, implementação, validação, implantação e manutenção de sistemas sociotécnicos. Os engenheiros de sistema são responsáveis pelos softwares, e não somente esses, mas também o hardware, as interações do sistema com os usuários e seu ambiente. Além disso, serviços que o sistema fornece, restrições de operação, criação e utilização, a fim de atingir seu propósito (SOMMERVILLE, 2007).
• A engenharia de software abrange também os métodos e as ferramentas para o desenvolvimento do software.
• O que é Engenharia de Software
  Disciplina de engenharia preocupada com todos os aspectos sobre a produção de software, incluindo:
  
  Processos ou Procedimentos
  Racionalizam o desenvolvimento de Software, ou seja, técnicas de manuseio das ferramentas para aplicação dos métodos;
  Métodos
  Conhecimento técnico; “Como” fazer, são as técnicas/paradigmas para o desenvolvimento de software;
  Ferramentas
  Suporte automatizado para processos e métodos
  Alternativa: Errada
  
  Fonte: Aulas Fernando Pedrosa
• A engenharia de software é uma disciplina de engenharia relacionada a TODOS os aspectos da produção de software, desde os estágios iniciais de especificação dos sistema até sua manutenção, depois que entrar em operação.

•  A engenharia de software não se preocupa apenas com os processos técnicos do desenvolvimento de software. Ela também inclui atividades como gerenciamento de projeto de software e desenvolvimento de ferramentas, métodos e teorias para apoiar a produção de software

  Resposta; Errada 

• e-

  Sommerville (2011) - eng sw é parte da eng de sist e abrange todas as areas da producao de software, do levantamento de requisitos à manutencao. Para Roger Pressman (2006), a Eng SW abrange 4 camadas tecnologicas - ferramentas, metodos, processo, foco na qualidade

• Muito pelo contrário, a Engenharia de Software abrange todo o processo de produção de um projeto de software.

  Resposta: Errado

Questão 784441

• Banca: CESPE / CEBRASPE
• Órgão: MEC
• Ano: 2011
• Provas: CESPE - 2011 - MEC - Analista de Processos
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

Julgue o  item  que se segue,  relativo à modelagem da informação.

Uma das principais características da engenharia de software, cujo foco é a automação dos processos organizacionais, é a modelagem da informação, processo por meio do qual se busca a integração dos sistemas de informação de uma organização.

• C. Certo
• E. Errado

Gabarito: E

Comentários

• Automação de processos organizacionais se refere ao BPM...
  

Questão 790960

• Banca: FCC
• Órgão: TST
• Ano: 2012
• Provas: FCC - 2012 - TST - Analista Judiciário - Análise de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Análise Estruturada; Desenvolvimento de Software; DFD (Diagrama de Fluxo de Dados)

Um desenvolvedor está trabalhando em uma elaboração de um software no qual uma das funções a serem implementadas é o controle do fluxo de dados que serão armazenados em um SGBD. Esta função receberá como entrada uma estrutura de dados contendo uma coleção de registros de pessoas. Ao término da execução da função, deve ser fornecido como saída outra estrutura de dados contendo uma coleção de pessoas com idade igual ou superior a 18 anos extraídos da estrutura de entrada. Considerando a entrada, saída e o objetivo que deve ser alcançado, o desenvolvedor

• A. utilizou comandos para a tomada de decisão, como os comandos condicional e de seleção múltipla. Não foram utilizados comandos que resultassem na repetição de trechos do código desenvolvido.
  
• B. implementou comandos que resultaram na repetição de um trecho do código que realizou um teste de decisão sobre quais dos registros da estrutura de dados de entrada deveriam ser inseridos na estrutura de dados de saída.
  
• C. construiu a função usando um comando de repetição para percorrer os registros da estrutura de dados de entrada sem o uso de um comando condicional aninhado, melhorando o tempo de processamento.
  
• D. desenvolveu uma solução em que os registros da coleção de entrada foram analisados através de um único comando condicional aninhado, sem o uso de comandos de repetição, buscando a otimização do código.
  
• E. criou um comando de repetição para percorrer os registros da estrutura de dados de entrada e, usando comandos de seleção múltipla, separou os registros pela idade, criando diversas estruturas de saída.
  

Gabarito: B

Comentários

• no qual uma das funções a serem implementadas...
  implementou comandos que resultaram na repetição...
  RESPOSTA B
• enquanto <> fim da fila faça
      se fila.elementoatual.idade > 18 então
          InsereSaida(fila.elemento)
      fim se
  fim enquanto
• Questões como essa podiam ficar em um teste psicotécnico.

• Com um IF eu faço o enfileiramento das idades, sempre mantendo na 1ª posição o número 18, e perguntando se a idade é > 18, entra no array.

  A letra D na minha opinião

• Só achei estranho onde diz "repetição de trecho de código" que pra mim é diferente de "comando de repetição". Não deu pra saber se estava se referindo a um comando de repetição ou se as linhas de código estavam sendo replicadas "fisicamente", uma abaixo da outra, para verificar cada registro. Mas achei essa a "menos errada", então fui nela...

  
  

  Renato, a letra D está errada pq é preciso ter o comando de repetição para passar por cada registro da coleção. se não vc vai ter que saber exatamente quantos registros tem na coleção e implementar uma "fila" de IFs, um IF pra cada registro, isso vai gerar muito código desnecessário e caso entre um novo registro ou seja excluído algum, seu código já não vai funcionar.
  

• Questão muito mal elaborada.Para mim a correta seria letra d 

Questão 790984

• Banca: FCC
• Órgão: TST
• Ano: 2012
• Provas: FCC - 2012 - TST - Analista Judiciário - Análise de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

O modelo de planejamento de sistemas de negócio (BSP - business system planning) foi desenvolvido pela IBM e influenciou outros esforços de planejamento. Este modelo conta maciçamente com o uso de métricas na análise dos processos e dados, com o objetivo de desenvolver a arquitetura da informação. O BSP é uma abordagem de cima para baixo que começa com

• A. os processos de negócio.
• B. as estratégias de negócio.
• C. a definição de bancos de dados.
• D. a arquitetura da informação.
• E. as classes de dados.

Gabarito: B

Comentários

• Business System Planning is a method for analyzing, defining and designing an information architecture of organizations. It was first issued by IBM in 1981, though the initial work on BSP began in the early 1970s. At first, it was for IBM internal use only. Later it was made available to customers and this method became an important tool for many organizations. It is a very complex method dealing with data, processes, strategies, aims and organizational departments which are interconnected. BSP brings new approach to design an information architecture and its goals are to:
  understand the issues and opportunities with the current applications and technical architecture
  develop a future state and migration path for the technology that supports the enterprise
  provide business executives with a direction and decision making framework for IT capital expenditures
  provide information system (IS) with a blueprint for development
   
  http://en.wikipedia.org/wiki/Business_System_Planning
• Letra B.
  Método BSP. Planejamento de cima para baixo e a Implementação de baixo para cima.
• Esse assunto está mais para governança do que para engenharia, não?

• Resposta -> 'B'

  As etapas da metodologia BSP são a sequencia de cima para baixo.

  1- Visão Estratégica

  2- Engenharia de Processos de Negócios

  3- Engenharia da Informação

    3.1- Dados Corporativos

    3.2- Modularização

    3.3- Priorização

  4- Plano de Ação

   

Questão 804355

• Banca: CESPE / CEBRASPE
• Órgão: MEC
• Ano: 2011
• Provas: CESPE - 2011 - MEC - Analista de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

A respeito de engenharia de software, julgue o  item  a seguir.

O processo de desenvolvimento de software é uma caracterização descritiva ou prescritiva de como um produto de software deve ser desenvolvido.

• C. Certo
• E. Errado

Gabarito: C

Comentários

• Segundo Sommerville processo de software é uma abordagem sistemática usada pela engenharia de software para a produção de um software.

  Processo de software: Especificação; Desenvolvimento; Validação e Evolução.

  O processo de software é uma caracterização descritiva ou prescritiva de como um produto de software deve ser desenvolvido.

   

  Gabarito: Certo

Questão 806734

• Banca: CESPE / CEBRASPE
• Órgão: MEC
• Ano: 2011
• Provas: CESPE - 2011 - MEC - Analista de Teste de Qualidade
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software; Teste de Software

Julgue o  item  a seguir, relativo  ao  processo  de teste de software.

Na etapa de especificação, ocorrem a elaboração e a revisão dos casos de testes.

• C. Certo
• E. Errado

Gabarito: C

Comentários

• Na etapa de especificação, ocorrem a elaboração e a revisão dos casos de testes. (INCORRETA: O ciclo de vida de testes é composto pelas seguintes etapas: Planejamento que é a etapa onde se estabelece o que vai ser testado, em quanto tempo e em que momento os testes serão interrompidos. Preparação onde o objetivo é preparar toda a estrutura do ambiente de testes como: equipamentos, configuração de hardware e softwares usados (sistemas operacionais, browsers, etc.), criação da massa de dados de teste, pessoal, ferramentas de automação, entre outros. Na etapa de Especificação a atividade principal é elaborar e revisar os cenários e roteiros de testes. Na Execução executa-se os testes planejados e registrar os resultados obtidos e por fim na Entrega é onde arquiva-se toda a documentação e descreve-se todas as ocorrências do projeto relevantes para a melhoria do processo)

  Fonte:: http://www.linhadecodigo.com.br/artigo/2775/introducao-ao-teste-de-software.aspx#ixzz3gOLfH6Cz

Questão 835918

• Banca: FDC
• Órgão: MAPA
• Ano: 2010
• Provas: FUNDAÇÃO DOM CINTRA - 2010 - MAPA - Analista de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software; Engenharia de Requisitos

No tocante ao desenvolvimento de software orientado ao reuso, embora o estágio inicial de especificação de requisitos e o estágio de validação sejam comparáveis com outros processos, os estágios intermediários em um processo orientado a reuso são diferentes. Neste caso, segundo SOMMERVILLE, são processos em estágios intermediários:

• A. projeto de interface, análise de componentes, projeto arquitetural e testes de aceitação;
• B. análise de componentes, modificação de requisitos, projeto de sistemas com reuso, e desenvolvimento e integração;
• C. desenvolvimento de protótipo, projeto arquitetural, análise de componentes e plano de teste;
• D. especificação de sistema, avaliação de mudanças, análise de componentes, e desenvolvimento e integração;
• E. especificação de componentes, especificação de estrutura, projeto de sistemas com reuso e especificação de requisitos.

Gabarito: B

Comentários

• 2.3.1 Desenvolvimento orientado a reuso
  

  Na maioria dos projetos de software é comum a utilização de trechos de 

  códigos que já foram utilizados por outros sistemas. Isso, em geral, acontece 

  informalmente quando as pessoas envolvidas no desenvolvimento de software 

  conhecem projetos ou códigos similares àquele exigido (SOMMERVILLE, 2003). 

  Eles recorrem a estes produtos, fazem as modificações necessárias e as incorporam 

  no novo projeto. O modelo genérico de processo para o desenvolvimento orientado 

  a reuso é mostrado na Fig. 4. Sommerville (2003) mostra que, embora o estágio 

  inicial de especificação de requisitos e o estágio de validação sejam comparáveis 

  com outros processos, os estágios intermediários em um processo orientado a reuso 

  são diferentes. Esses estágios são: análise de componentes: considerando a 

  especificação de requisitos, é feita uma busca de componentes para implementar 

  esta especificação. Em geral não existe uma combinação exata e os componentes 

  que podem ser utilizados fornecem somente parte da funcionalidade requerida;  

  modificação de requisitos: nesse estágio, os requisitos são analisados, utilizando-se

  as informações sobre os componentes que foram encontrados. Eles são então

  modificados para refletir os componentes disponíveis. Quando não forem possíveis

  as modificações, a atividade de análise de componentes poderá ser refeita, a fim de

  procurar soluções alternativas; projeto de sistema com reuso: durante essa fase, a

  infra-estrutura do sistema é projetada ou uma infra-estrutura existente é reutilizada.

  Os projetistas levam em conta os componentes que são reutilizados e organizam a

  infra-estrutura para lidar com esse aspecto. Um novo software poderá ter de ser

  projetado, se os componentes reutilizáveis não estiverem disponíveis;

  desenvolvimento e integração: o software que não puder ser comprado será

  desenvolvido, e os componentes serão integrados, a fim de criar um sistema. A

  integração de sistemas, neste modelo, pode ser parte do processo de

  desenvolvimento, em vez de uma atividade separada.

  
  

  Fonte: http://www2.ufpel.edu.br/prg/sisbi/bibct/acervo/info/2007/mono_juliano_teixeira.pdf

• Especificação de Requisitos -> Analise de Componentes / Alteração de Requisitos -> Desenvolvimento e Integração / Projeto do Sistema com Reuso - > Validação do Sistema ->

Questão 888943

• Banca: CESGRANRIO
• Órgão: EPE
• Ano: 2012
• Provas: CESGRANRIO - 2012 - EPE - Analista de Gestão Corporativa - Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

Quando um projeto de software está atrasado a solução recomendada é adicionar imediatamente mais pessoas à equipe.


PORQUE


O principal recurso no desenvolvimento de software são as pessoas.


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

• A. as duas afirmações são verdadeiras, e a segunda justifica a primeira.
• B. as duas afirmações são verdadeiras, e a segunda não justifica a primeira.
• C. a primeira afirmação é verdadeira, e a segunda é falsa.
• D. a primeira afirmação é falsa, e a segunda é verdadeira.
• E. as duas afirmações são falsas.

Gabarito: D

Questão 895219

• Banca: CESPE / CEBRASPE
• Órgão: CNJ
• Ano: 2013
• Provas: CESPE - 2013 - CNJ - Analista Judiciário - Análise de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

Acerca de conceitos relacionados ao desenvolvimento de software
seguro e segurança para web services, julgue os itens subsecutivos.

O SDL é um processo de desenvolvimento de software seguro, que envolve a adição de produtos e atividades, como o desenvolvimento de modelos de ameaças.

• C. Certo
• E. Errado

Gabarito: C

Comentários

• Ele está falando do processo da Microsoft SDL (Security Development Lifecycle - ciclo de vida do desenvolvimento da segurança).  O processo engloba a adição de uma série de atividades e produtos concentrados na segurança em cada fase do processo de desenvolvimento de software da Microsoft. Essas atividades e esses produtos incluem o desenvolvimento de modelos de ameaças durante o design do software, o uso de ferramentas de verificação de código de análise estática durante a implementação e a realização de revisões de código e testes de segurança durante um "esforço de segurança" direcionado. Referência: http://msdn.microsoft.com/pt-br/library/ms995349.aspx

• Gabarito Certo

  O SDL (Security Development Lifecycle) é um processo de desenvolvimento de software com segurança adotado pela Microsoft e descrito por Howard e Lipner (2006), Lipner e Howard (2005) e Microsoft (2010). O SDL envolve a adição de uma série de atividades e produtos concentrados na produção de software seguro, desenvolvidas em cada fase do processo de desenvolvimento de software. Essas atividades e esses produtos incluem aspectos como: (i) o desenvolvimento de modelos de ameaças durante o design do software, (ii) o uso de ferramentas de verificação de código de análise estática durante a implementação e (iii) a realização de revisões de código e testes de segurança, entre outros. O SDL propõe a modificação dos processos de uma organização de desenvolvimento de software através da integração de medidas que levam ao software seguro, adicionando pontos de verificação e produtos de segurança bem definidos.

   

   

  "Retroceder Nunca Render-se Jamais !"
  Força e Fé !
  Fortuna Audaces Sequitur !

   

   

Questão 897592

• Banca: UNEMAT
• Órgão: CEPROMAT
• Ano: 2012
• Provas: UNEMAT - 2012 - CEPROMAT - Analista de Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

Em relação ao desenvolvimento de software, assinale a alternativa correta.

• A. Métodos Formais é o termo usado para definir o processo de especificação de software fundamentado em linguagens formais.
• B. O modelo de cliente-servidor exige o uso de dois ou mais computadores, sendo um dele servidor.
• C. Qualidade de software é um conceito simples, análogo à qualidade de outros produtos.
• D. As métricas de qualidade de software definem que a sua qualidade é diretamente proporcional ao número de linhas de código do programa gerado.
• E. As métricas de qualidade de software apontam que o número de interações entre usuário final e o desenvolvedor é menor quando o software é de boa qualidade.

Gabarito: A

Comentários

• São técnicas baseadas em formalismos matemáticos para a especificação, desenvolvimento e verificação dos sistemas de softwares e hardwares.
  Fonte: http://pt.wikipedia.org/wiki/M%C3%A9todos_formais
• Geralmente os clientes e servidores comunicam através de uma rede de computadores em computadores distintos, mas tanto o cliente quanto o servidor podem residir no mesmo computador.
  
  http://pt.wikipedia.org/wiki/Cliente-servidor

Questão 898072

• Banca: CESGRANRIO
• Órgão: BNDES
• Ano: 2013
• Provas: CESGRANRIO - 2013 - BNDES - Profissional Básico - Análise de Sistemas - Desenvolvimento
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

Em projetos de desenvolvimento de sistemas de software como, por exemplo, sistemas multimídia, um requisito de tempo não atendido pode significar o fracasso das funções desses sistemas.

Para se evitar esse fato, deve ser realizado, por meio do uso de instrumentos de software e hardware, um tipo específico de teste no qual seja(m)

• A. verificado se os requerimentos de desempenho estão sendo plenamente atendidos para o sistema.
• B. verificado se todo código-fonte dos programas envolvidos no sistema está de acordo com o definido.
• C. verificado se o funcionamento do software não apresenta bugs quando o sistema atinge seu ápice de I/O.
• D. medidas as rotinas de segurança em relação às rotinas de recuperação utilizadas para proteção de dados críticos.
• E. validados os métodos utilizados na programação das estruturas de interfaces definidas para o sistema.

Gabarito: A

Questão 913843

• Banca: FCC
• Órgão: DPE-SP
• Ano: 2013
• Provas: FCC - 2013 - DPE-SP - Programador de computador
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software; Engenharia de Requisitos

Com relação aos conceitos básicos e princípios da engenharia de software, analise:

I. Embora nem sempre seja possível uma definição ampla e estável dos requisitos, uma definição de objetivos ambígua pode ser receita para um desastre.

II. Os requisitos de software mudam, mas o impacto da mudança varia dependendo do momento em que ela for introduzida.

III. Se o cronograma de entrega do software atrasar a solução mais eficiente sempre é a contratação de mais programadores.

IV. Quando diferentes clientes ou usuários propõem necessidades conflitantes é preciso conciliar esses conflitos por meio de um processo de negociação.

Está correto o que se afirma em

• A. I, II, III e IV.
• B. I e IV, apenas.
• C. III e IV, apenas.
• D. II e III, apenas.
• E. I, II e IV, apenas.

Gabarito: E

Comentários

• III. Afirmação INCORRETA: "Se o cronograma de entrega do software atrasar a solução mais eficiente sempre é a contratação de mais programadores."
  Nem sempre a solução mais eficiente é a contratação de mais programadores.  Um ditado popular entre programadores explica este fato: "Nove grávidas não fazem um bebê em 1 mês"

• e-

  Negociação é parte da eng. dos requisitos:

     Concepção. identificam-se os stakeholders e seus pontos de vista

     Elicitação. ...

     Elaboração. ...

     Negociação. ...

     Especificação. ...

     Validação. ...

     Gerenciamento.

Questão 931387

• Banca: CESPE / CEBRASPE
• Órgão: SERPRO
• Ano: 2010
• Provas: CESPE - 2010 - SERPRO - Analista Desenvolvimento de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

Acerca de modelos e abordagens à gestão de empreendimentos de desenvolvimento de software, julgue o item abaixo.

O modelo de gestão bazar, comparado ao modelo catedral, apresenta melhores condições para apoiar o desenvolvimento de software colaborativo, especialmente se este tiver código aberto e for aderente à abordagem de software livre. Tal modelo, comparado ao modelo catedral, apresenta ainda menor previsibilidade acerca da arquitetura do software que emerge da interação entre as pessoas.

• C. Certo
• E. Errado

Gabarito: E

Questão 931453

• Banca: CESPE / CEBRASPE
• Órgão: SERPRO
• Ano: 2010
• Provas: CESPE - 2010 - SERPRO - Analista Desenvolvimento de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

Linhas de produto e software empregam técnicas de engenharia de software para criação de um porta-fólio de sistemas de softwares similares a partir de um conjunto compartilhado de ativos de software, usando meios de produção comunal. 

Internet: <www.softwareproduclines.com> (com adaptações).

Tendo o texto acima como referência inicial, julgue o item a seguir, acerca do conceito de linhas de produto e de sua relação com os componentes de software.

Todo ativo de software é um componente de software de determinado domínio.

• C. Certo
• E. Errado

Gabarito: E

Questão 931456

• Banca: CESPE / CEBRASPE
• Órgão: SERPRO
• Ano: 2010
• Provas: CESPE - 2010 - SERPRO - Analista Desenvolvimento de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

Linhas de produto e software empregam técnicas de engenharia de software para criação de um porta-fólio de sistemas de softwares similares a partir de um conjunto compartilhado de ativos de software, usando meios de produção comunal. 

Internet: <www.softwareproduclines.com> (com adaptações).

Tendo o texto acima como referência inicial, julgue o item a seguir, acerca do conceito de linhas de produto e de sua relação com os componentes de software.

O ciclo de vida de componentes de software, em uma abordagem de linha de produtos, possui foco no reúso preditivo e não no reúso oportunístico.

• C. Certo
• E. Errado

Gabarito: C

Questão 984739

• Banca: CESPE / CEBRASPE
• Órgão: MPOG
• Ano: 2013
• Provas: CESPE - 2013 - MPOG - Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

Com base na norma ISO/IEC 14598-3, julgue os itens abaixo.


A partir dos produtos intermediários obtidos nas fases de desenvolvimento, indicadores que possam ser medidos devem ser registrados para a tomada de decisões.

• C. Certo
• E. Errado

Gabarito: C

Comentários

• 14598-3: Engenharia de software - Avaliação de produto 
  Parte 3: Processo para desenvolvedores

  Esta parte da NBR ISO/IEC 14598 fornece requisitos e recomendações para a implementação de avaliação de produto de software quando a avaliação é conduzida em paralelo com o desenvolvimento e executada pelo desenvolvedor.

  Etapa 'Executar a avaliação': consiste na inspeção, medição e teste dos produtos e seus componentes de acordo com o plano de avaliação.

   

  Fontes: - Descrição da ISO no catálogo ABNT

  http://testelabs.blogspot.com.br/2012/05/isoiec-14598-engenharia-de-software.html

• A norma NBR ISO/IEC 14598-3, que trata do processo de avaliação para desenvolvedores de software, aplica-se a todo software e em todas as fases do ciclo de vida de desenvolvimento. Enfoca a seleção de indicadores, para prever a qualidade do produto final pela medição da qualidade de produtos intermediários. Também enfoca a medição da qualidade do produto final.
  
  FONTE: 
  Qualidade de Produto de Software
  Ana Cervigni Guerra
  Regina Maria Thienne Colombo

Questão 984778

• Banca: CESPE / CEBRASPE
• Órgão: MPOG
• Ano: 2013
• Provas: CESPE - 2013 - MPOG - Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

A respeito das linhas de produtos e componentes relacionados à engenharia de software, julgue o item subsequente.


De acordo com o OMG (Object Management Group), na MDA (model-driven architecture), as especificações e funcionalidades do software devem ser modeladas por meio de um modelo independente de plataforma.

• C. Certo
• E. Errado

Gabarito: C

Comentários

• A MDA é uma visão em como o software pode ser desenvolvido colocando a modelagem no centro do processo de desenvolvimento. A partir de um modelo abstrato do sistema é gerado um modelo mais concreto, através deste processo de refinamento dos modelos podemos gerar o código fonte a ser produzido. O código fonte é considerado como a mais concreta representação do sistema de software. A chave para esse processo é que cada etapa da geração é automatizada o máximo possível.
  

  A MDA pode ser definida em três etapas. A primeira etapa é construção de um modelo com um alto nível de abstração, independente de qualquer...
  

  WIKI: http://pt.wikipedia.org/wiki/Model_Driven_Architecture

Questão 1035274

• Banca: CESPE / CEBRASPE
• Órgão: PEFOCE
• Ano: 2012
• Provas: CESPE - 2012 - PEFOCE - Perito Criminal - Ciências da Computação
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

Acerca da reengenharia e da engenharia direta de sistemas, julgue os itens subsequentes.

Como regra geral, não se deve tentar reestruturar um sistema com o uso da reengenharia se a abordagem inicial do sistema legado for funcional e a versão melhorada desejada for orientada a objetos.

• C. Certo
• E. Errado

Gabarito: C

Comentários

• Alguém sabe de onde saiu isso?

• Não lembro de qual literatura é, mas a reengenharia se propõe a produzir um NOVO produto e não uma versão melhorada.

• "O problema com a reengenharia de software é que existem limites práticos para o quanto você pode melhorar um sistema por meio da reengenharia. Não é possível, por exemplo, converter um sistema escrito por meio de uma abordagem funcional para um sistema orientado a objetos. As principais mudanças de arquitetura ou a reorganiza­ção radical do sistema de gerenciamento de dados não podem ser feitas automaticamente, pois são muito caras. Embora a reengenharia possa melhorara manutenibilidade, o sistema reconstruído provavelmente não será tão manutenível como um novo sistema, desenvolvido por meio de métodos modernos de engenharia de software." SOMMERVILLE, 9ª ED, PG 175.

Questão 1035868

• Banca: CESPE / CEBRASPE
• Órgão: IPEA
• Ano: 2008
• Provas: CESPE - 2008 - IPEA - Analista de Sistemas - Suporte de Banco de Dados
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

Julgue os itens subseqüentes, com relação a processos de desenvolvimento de software.

No modelo de processo de desenvolvimento embasado em entrega incremental, tem-se que o sistema é desenvolvido como uma série de incrementos, sendo que cada incremento provê um conjunto de funcionalidades. É fácil identificar os recursos que são comuns aos incrementos, pois todos os requisitos precisam ser detalhados quando do início do desenvolvimento.

• C. Certo
• E. Errado

Gabarito: E

Comentários

• Errado: "pois todos os requisitos precisam ser detalhados quando do início do desenvolvimento."

  A cada incremento novos requisitos podem surgir e somente os requisitos que estarão presentes no incremento precisam ser detalhados. 

Questão 1044139

• Banca: CETRO
• Órgão: ANVISA
• Ano: 2013
• Provas: CETRO - 2013 - ANVISA - Analista Administrativo - Área 5
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

Assinale a alternativa correta quanto ao processo de desenvolvimento de software.

• A. Após a finalização do programa e sua implantação, o trabalho está terminado.
  
• B. O produto a ser entregue no final do projeto é o programa funcionando.
  
• C. A preocupação com a garantia da qualidade do software deve fazer parte de todas as etapas do desenvolvimento.
  
• D. Os requisitos de projeto mudam continuamente durante o seu desenvolvimento, mas isso não representa um problema, uma vez que o software é flexível e poderá suportar facilmente as alterações.
  
• E. Se o desenvolvimento do software estiver atrasado, aumentando a equipe, pode-se reduzir o tempo de desenvolvimento

Gabarito: C

Comentários

• a) Após a finalização do programa e sua implantação, o trabalho está terminado. (INCORRETO - existe o subsequente trabalho de manutenção)

  
  

  b) O produto a ser entregue no final do projeto é o programa funcionando. (INCORRETO - além do programa, são também componentes do software os diversos tipos de documentação)

  
  

  c) A preocupação com a garantia da qualidade do software deve fazer parte de todas as etapas do desenvolvimento. (CORRETO)

  
  

  d) Os requisitos de projeto mudam continuamente durante o seu desenvolvimento, mas isso não representa um problema, uma vez que o software é flexível e poderá suportar facilmente as alterações. (INCORRETO - o software é flexível mas sempre há um custo em implementar alterações - custo este que aumenta com a progressão do projeto )

  
  

  e) Se o desenvolvimento do software estiver atrasado, aumentando a equipe, pode-se reduzir o tempo de desenvolvimento. (INCORRETO - meu professor de Eng. de Software me ensinou uma excelente frase: "Nove grávidas não fazem um bebê em um mês." A introdução de novos profissionais durante o desenvolvimento implica no treinamento destes pelos profissionais que já estão trabalhando no projeto, o que pode acarretar em ainda mais atrasos.)

  
  

• c-A unica opcao que faz sentido. O deployment do software (transicao) nao significa o fim. Ha suporte e atualizacoes que podem ser necessarias. TODA MUDANÇA É DANOSA AO PROJETO. As estimativas de custo e tempo sofrem com mudanças depois da fase de requisitos; mudanças devem ser discutidas com cliente e gerenciadas efetivamente

   

Questão 1055422

• Banca: CESPE / CEBRASPE
• Órgão: STF
• Ano: 2013
• Provas: CESPE - 2013 - STF - Técnico Judiciário - Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

Julgue os itens subsecutivos, em relação a projetos de desenvolvimento de software.

O design emergente é uma forma de desenvolvimento de software criado para países emergentes, especialmente a Índia, que possui avançada indústria de desenvolvimento de software. A principal característica do design emergente é o desenvolvimento 24 horas, em que, quando uma equipe acaba o turno de trabalho, outra equipe continua em outro ponto do planeta.

• C. Certo
• E. Errado

Gabarito: E

Comentários

• kkkkkkk!!! essa foi a maior besteira que eu já ouvi! boa

• E as estatísticas desta questão mostram que 41 pessoas que marcaram como certa!

• Essa questão faz sentido sim, pois refere-se à metodologia "Follow The Sun", conforme descrito abaixo:

  "Follow-the-sun is a type of global workflow in which tasks are passed around daily between work sites that are many time zones apart. Such a workflow is set up in order to reduce project duration and increase responsiveness. Thus, the work is "following the sun" and never stops.

  For example, at the end of the day, a systems support team in Silicon Valley will pass its work tasks to an Asian support team which, at the end of its day, passes its work to an European support team, which passes it back to Silicon Valley."

   

  FONTE: https://en.wikipedia.org/wiki/Follow-the-sun

• Sugiro aos colegas que vejam o link que o colega enviou ( https://en.wikipedia.org/wiki/Follow-the-sun ) pois não se trata de nenhuma beisteira, pois o Follow The sun existe e o erro da questão é informar que a "EQUIPE"  trabalha em turno de 24 horas quando na realidade trabalho 8 horas, sem contar que a questão também misturou o FOLLOW THE SUN com Design Emergente

  Design emergente quer dizer que, no decorrer do desenvolvimento a equipe irá definir o design baseado nas necessidades reais, e não em hipóteses ou estudos. O que não quer dizer que não é feito planejamento! O planejamento é feito logo no início do projeto, conhecido como iteração 0, a diferença é que esse planejamento não é feito de forma exaustiva, até que todos os membros estejam cansados e aceitem qualquer coisa.

• Follow the Sun também é um tipo de Service Desk definido pela ITIL v3.

   

  Local - atende a unidade de negócio local

  Centralizada - atende todos em um único local

  Virtual - geograficamente distante

  Follow the Sun - combinação de centrais dispersas geograficamente, oferecendo suporte 24h a custo relativamente baixo.

Questão 1055815

• Banca: CESPE / CEBRASPE
• Órgão: STF
• Ano: 2013
• Provas: CESPE - 2013 - STF - Analista Judiciário - Análise de Sistemas de Informação
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

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

Na área de conhecimento ferramentas e métodos, o termo ferramentas se refere à estruturação da atividade de desenvolvimento e manutenção de software com o objetivo de torná-la sistemática; métodos dizem respeito à automação do processo de engenharia de software.

• C. Certo
• E. Errado

Gabarito: E

Comentários

• ERRADO.
  Método está relacionado as atividades enquanto ferramentas relacionam-se com a automaçâo.

• Houve uma inversão dos conceitos.

• A troca de conceitos é marca registrada do CESPE, tem que ficar ligado nesse tipo de questão   

• Ferramentas de desenvolvimento de software são ferramentas criadas para auxiliar no ciclo de vida do software. Essas ferramentas normalmente automatizam algumas atividades do processo de desenvolvimento, fazendo com que o analista concentre-se nas atividades que exigem maior trabalho intelectual (SWEBOK, 2004).

   
  Métodos de Engenharia de Software impõe estrutura sobre a atividade de desenvolvimento e manutenção de software com o objetivo de torná-la sistemática e mais propensa ao sucesso (SWEBOK, 2004).

   

  Fonte: http://www.joinville.udesc.br/portal/professores/claudinei/materiais/SOFT_VISAO_GERAL.pdf

Questão 1112839

• Banca: FCC
• Órgão: AL-PE
• Ano: 2014
• Provas: FCC - 2014 - AL-PE - Analista Legislativo - Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

O ciclo de vida de projeto de um software a ser desenvolvido consiste em fases, cujo nome e número variam, podendo ser definido ou moldado de acordo com aspectos exclusivos da organização ou da tecnologia empregada. O ciclo de vida oferece uma estrutura básica para o gerenciamento do projeto, independentemente do trabalho específico envolvido. Considerando os conceitos relativos ao ciclo de vida e de desenvolvimento de software, é INCORRETO afirmar:

• A. Uma organização pode optar por um ciclo de vida em que mais de uma fase do projeto avança simultaneamente. O início de uma fase é também o momento de revalidar premissas, analisar riscos e definir mais detalhadamente os processos necessários para realizar as entregas da fase.
  
• B. Os níveis de custo e de pessoal são mais baixos nas fases iniciais, atingem um valor médio enquanto o projeto do software é executado e aumentam rapidamente conforme o projeto é finalizado. Os erros têm um custo ainda mais elevado quando são detectados em fases iniciais. O ciclo de vida permite detectar os erros e assim aprimorar a qualidade do software, os prazos da sua realização e os custos associados.
  
• C. O ciclo de vida designa todas as fases do desenvolvimento de um software, da sua concepção até o seu desuso. Os princi- pais objetivos da segmentação em fases é definir pontos intermediários que permitem a validação do desenvolvimento do software, bem como estabelecer a expectativa quanto à necessidade de sua atualização ou descontinuidade.
  
• D. Para haver uma linguagem comum ao cliente e à organização que realiza o desenvolvimento, foram criados modelos de ciclo de vida que definem as fases do desenvolvimento e apontam os principais produtos a serem gerados em cada uma delas.
  
• E. Quando as fases são sequenciais, o encerramento de uma fase termina com alguma forma de transferência ou entrega do produto do trabalho produzido como entrega da fase. O final desta fase representa um ponto natural de reavaliação dos esforços em andamento e de modificação ou término do projeto.

Gabarito: B

Comentários

• Correto opção B.

   Os erros têm um custo ainda mais elevado quando são detectados em fases iniciais .Errado. Na verdade, os custos são normalmente altos quando o processo de desenvolvimento está nas fases medianas e finais [entre o meio e o fim] do projeto.Não há sentido afirmar que há custo elevado quando se está começando a produzir, afinal, o início é a fase mais flexível a mudanças no projeto de sistemas, sendo seu impacto nos custos muito pequeno.

  Os níveis de custo e de pessoal são mais baixos nas fases iniciais .Verdade, no início de todo projeto de software, os custo são baixos visto que pouco foi realizado.  

   atingem um valor médio enquanto o projeto do software é executado e aumentam rapidamente conforme o projeto é finalizado.

  Como foi afirmado anteriormente,os custos são normalmente altos quando o processo de desenvolvimento está nas fases medianas  e finais do projeto.Nessa fase, as mudanças em escopo de projetos podem, e a maioria o fazem, elevar bastante os gastos sobre esse projeto, visto que tal mudança pode acarretar a mudança em outros aspectos do mesmo.Isso costuma ocorrer quando o cliente não sabe o que quer. Ele afirma que quer de um modo, mas pouco depois vai retirando e/ou acrescentando algo pelos mais diversos motivos. 

  O ciclo de vida permite detectar os erros e assim aprimorar a qualidade do software, os prazos da sua realização e os custos associados.  Essa afirmação é correta, pois todo projeto baseado em um ciclo de vida tem como uma de suas prioridades, dentre outras coisas, verificar a ocorrência de erros, afim de que o software produzido esteja sempre de acordo com os níveis máximos de qualidade, sempre dentro dos prazos estabelecidos e custos a ele associados.

• Boa noite! Estou me preparando para o Inss e você?
• Pro TRT, tava em dúvida entre INSS ou TRT, mas me identifiquei mais com o TRT. Você é de onde ?
• Sou de Timóteo/MG e vc?
• Sou de Fortaleza-CE, longe hein kkkk
• Sim! kk Boa sorte com seu concurso!
• Obrigada, pra você também o/

Questão 1115470

• Banca: CESPE / CEBRASPE
• Órgão: SUFRAMA
• Ano: 2014
• Provas: CESPE - 2014 - SUFRAMA - Analista Técnico - Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

Julgue os itens subsequentes, acerca da engenharia de software.

No ciclo de vida de um software, a fase de retirada pode ser menos traumática caso sejam utilizados os processos de reengenharia para a migração do legado do software.

• C. Certo
• E. Errado

Gabarito: C

Comentários

• Não entendi porque esta certo!,,,

• Eu acho que ele quis falar sobre reaproveitar os dados que estão no banco por exemplo para uma nova aplicação...

  Mas não sei, foi meio chute q acertei
  

• Esse trecho "a fase de retirada pode ser menos traumática" acho que seria desativar um software legado no ambiente de produção após uma migração . Nesse contexto a reengenharia é válida.

• No ciclo de vida de um software, a fase de retirada pode ser menos traumática caso sejam utilizados os processos de reengenharia para a migração do legado do software.

  Gabarito: Certo.

  There are two important benefits from reengineering rather than replacement:
  1. Reduced risk There is a high risk in redeveloping business-critical software. Errors may be made in the system specification or there may be development problems. Delays in introducing the new software may mean that business is lost and extra costs are incurred.

  2.Reduced cost The cost of reengineering may be significantly less than the cost of developing new software. Ulrich (1990).

  
  Sommervile também deixa claro que a reengenharia pode não ser viável em alguns casos.
  

  Fonte: Ian Sommervile - Software Engineering - 9 Edição pg 249.
  

• "Software do Legado" são sistemas antigos, e com a reengenharia de software sua retirada (mitigação) seria de forma mais viável e sem muita reestruturação do sistema que irá substitui-lo.

Questão 1120918

• Banca: CESPE / CEBRASPE
• Órgão: TRT - 17ª Região (ES)
• Ano: 2013
• Provas: CESPE - 2013 - TRT - 17ª Região (ES) - Técnico Judiciário - Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

A respeito dos conceitos de práticas ágeis, metodologia RAD (rapid application development), integração contínua, TDD (test-driven development), refactoring e gerência de configuração, julgue os itens seguintes.

TDD consiste em uma técnica de desenvolvimento de software com abordagem embasada em perspectiva evolutiva de seu desenvolvimento. Essa abordagem envolve a produção de versões iniciais de um sistema a partir das quais é possível realizar verificações de suas qualidades antes que ele seja construído.

• C. Certo
• E. Errado

Gabarito: E

Comentários

• "Essa abordagem envolve a produção de versões iniciais de um sistema a partir das quais é possível realizar verificações..."
  
  Não existe a produção inicial do sistema. O primeiro passo é criar um teste.
  

• Prototipagem evolucionária consiste em uma técnica de desenvolvimento de software com abordagem embasada em perspectiva evolutiva de seu desenvolvimento. Essa abordagem envolve a produção de versões iniciais de um sistema a partir das quais é possível realizar verificações de suas qualidades antes que ele seja construído.

   

  Gabarito: Errado

• Acredito que o erro consiste em dizer que A PARTIR da versão inicial será possível realizar as verificações.

  Primeiro é criado o teste, depois é produzida a versão inicial.

Questão 1122040

• Banca: FCC
• Órgão: SABESP
• Ano: 2014
• Provas: FCC - 2014 - SABESP - Tecnólogo - Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

A engenharia de software apresenta um conjunto de princípios que podem ser usados quando um projeto de desenvolvimento de software for realizado, como os descritos abaixo:

I. Decomposição - o software é um produto complexo construído a partir de partes mais simples. A decomposição funcional é uma maneira de conceber o software como um conjunto de funções de alto nível (requisitos) que são decompostas em partes cada vez mais simples até chegar a comandos individuais de linguagem de programação.

II. Abstração - muitas vezes é necessário descrever um elemento em uma linguagem de nível mais alto do que o necessário para sua construção. A abstração ajuda os interessados no processo de desenvolvimento a entenderem estruturas grandes e complexas através de descrições mais abstratas.

III. Composição - a composição deu origem à orientação a objetos, em que um objeto pode ser classificado simultaneamente em mais de uma classe. Por exemplo, um cão, além de ser um mamífero, é animal e vertebrado.

IV. Padronização - a criação de padrões (patterns) de programação, design e análise ajuda a elaborar produtos com qualidade mais previsível. São importantes para a captação de experiências e evitam a repetição de erros que já têm solução conhecida.

Apresentam princípio e descrição corretos o que se afirma APENAS em

• A. I, II e III.
  
• B. IV.
  
• C. II e III.
  
• D. III e IV.
  
• E. I, II e IV.
  

Gabarito: E

Comentários

• "III. Herança - a herança deu origem à orientação a objetos, em que um objeto pode ser classificado simultaneamente em mais de uma classe. Por exemplo, um cão, além de ser um mamífero, é animal e vertebrado."
  Não sei dizer a herança deu origem à orientação objetos mas creio que o restante da assertiva diz respeito ao conceito de herança.

• LETRA E

  Os Princípios da Engenharia de Software são

  FORMALIDADE - Seguir Passos Pré-definidos

  ABSTRAÇÃO

  DECOMPOSIÇÃO

  GENERALIZAÇÃO - Padrões de Projetos são uma forma de Generalização

  FLEXIBILIZAÇÃO - Alterar Soft sem alterar Execução

Questão 1128604

• Banca: CS-UFG
• Órgão: UEAP
• Ano: 2014
• Provas: CS-UFG - 2014 - UEAP - Analista de Tecnologia da Informação - Desenvolvimento de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software; Qualidade de Software

Um sistema acadêmico de graduação vem atendendo às necessidades de uma universidade há oito anos, período em que foi corrigido, adaptado e melhorado várias vezes, sem que as melhores práticas da Engenharia de Software tivessem sido aplicadas. Caracterizado como um sistema de baixa qualidade de manutenção, foi realizada uma
análise de custo-benefício que decidiu pela sua reengenharia

• A. em resposta ao seu alto valor de negócio corrente para a universidade.
  
• B. em função do seu reduzido custo de manutenção atual antes da reengenharia.
  
• C. devido à sua expectativa de vida menor, se comparada a outros sistemas legados.
  
• D. por causa da estimativa de longo prazo para concluir a sua reconstrução.
  

Gabarito: A

Comentários

• Um dos maiores benefícios de se utilizar sistemas de informação é a "adição de valor ao negócio".

  :) 

Questão 1128613

• Banca: CS-UFG
• Órgão: UEAP
• Ano: 2014
• Provas: CS-UFG - 2014 - UEAP - Analista de Tecnologia da Informação - Desenvolvimento de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

O desenvolvimento incremental é baseado na ideia de construir 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. Do ponto de vista do gerenciamento, no desenvolvimento incremental,

• A. o processo é bem visível aos stakeholders.
  
• B. o custo de acomodar as mudanças nos requisitos é alto.
  
• C. a utilização de uma abordagem dirigida a planos é inviável.
  
• D. a estrutura do sistema tende a se degradar.
  

Gabarito: D

Comentários

• Caros,

  No abordagem incremental, há dois problemas do ponto de vista do gerenciamento: o processo não é visível e a degradação da estrutura do sistema.

  Fonte: http://www.danilogiacobo.eti.br/IFPR/ES/ES%20-%2004%20-%20Processos%20de%20Software.pdf

   

• Gab "D"

  a estrutura do sistema tende a se degradar.

Questão 1139434

• Banca: Prefeitura do Rio de Janeiro - RJ
• Órgão: TCM-RJ
• Ano: 2011
• Provas: Prefeitura do Rio de Janeiro - RJ - 2011 - TCM-RJ - Analista de Informação
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

No que diz respeito ao ciclo de vida, a metodologia referenciada como desenvolvimento evolucionário baseia-se em uma implementação inicial, expondo o resultado aos comentários do usuário e refinando esse resultado por meio de várias versões até que seja desenvolvido o sistema como um todo. As atividades de especificação, desenvolvimento e validação são intercaladas, em vez de serem separadas, com feedback rápido que permeia as atividades. Existem dois tipos fundamentais de desenvovimento evolucionário, que são:

• A. Prototipação Throwaway e Projeto Modularizado
  
• B. Desenvolvimento Exploratório e Prototipação Throwaway
  
• C. Projeto Modularizado e Modelagem Incremental
  
• D. Modelagem Incremental e Processo Customizado
  
• E. Processo Customizado e Desenvolvimento Exploratório

Gabarito: B

Comentários

• Protótipo é a primeira versão desenvolvida do software, a qual tem a finalidade de abordar a questão de interface com o usuário, validar requisitos e apresentar a viabilidade do sistema.

  Durante a criação do protótipo, clientes e desenvolvedores ficam em constante interação, facilitando assim o levantamento de requisitos e funcionalidades do sistema.

   

  Alguns desenvolvedores utilizam prototipações que são descartadas, ou seja, o desenvolvimento do sistema somente será iniciado após o término do desenvolvimento do protótipo. Esses métodos de prototipações geralmente elevam o custo do sistema, pois são feitos dois projetos separados, um do protótipo e outro do sistema final.

   

  Essa separação entre o desenvolvimento do protótipo e do sistema final vem diminuindo a cada dia, com o uso da prototipação evolutiva, a qual será o objeto de estudo deste artigo que terá como objetivo mostrar as vantagens e desvantagens da utilização deste método no desenvolvimento de sistemas de informação.

   

  PROTOTIPAÇÃO DE ALTA FIDELIDADE:

   

  Protótipos de alta fidelidade são semelhantes ao produto final. Este tipo de prototipação utiliza à mesma técnica que o sistema final e é indicado quando o objetivo é a venda do sistema ou o teste de problemas técnicos.

   

  Há algumas vantagens em usar a prototipação de alta fidelidade, como: funcionalidades semelhantes as do sistema final, a definição completa do esquema navegacional, um elevado grau de interação com os usuários e a exploração de testes com muito realismo.

   

  No entanto, há algumas desvantagens como, por exemplo: elevado custo e tempo de desenvolvimento, ineficiente para testes de opções de design e levantamento de requisitos.

   

  PROTOTIPAÇÃO THROW-AWAY:

   

  Este método de prototipação é utilizado para encontrar problemas de requisitos em protótipos, e tem como objetivo consistir uma maior qualidade, por meio da validação e definição no documento de requisitos do software.

   

  Ele tem como base os requisitos que não estão bem definidos, e os que já estão bem definidos dificilmente são utilizados no protótipo. Ao construir um protótipo pelo método Throw-Away, os seguintes passos são seguidos: desenvolve-se um documento de requisitos provisório, obtêm-se opiniões dos usuários e reformula-se o documento de requisitos, repetem-se estes passos, até a obtenção de satisfação dos usuários e, consequentemente, a finalização do documento de requisitos.

   

  Depois da finalização do documento de requisitos, o protótipo já não é mais necessário e então é abandonado, para que se inicie o processo de desenvolvimento do software, o que acarreta em um gasto de tempo um pouco maior e na elevação do custo.

   

  PROTOTIPAÇÃO EVOLUTIVA:

   

  A prototipação evolutiva é utilizada em protótipos que evoluirão até tornarem-se sistemas finais.

   

  Fonte: http://www.webartigos.com/artigos/prototipacao-de-software/1896/

   

  Bons estudos!

• ✅Gabarito(B) 

  O Modelo de Desenvolvimento Evolucionário subdivide-se em dois: Programação Exploratória e Prototipagem Descartável. 

  Modelo de Programação Exploratória

  O objetivo desse modelo é o desenvolvimento da primeira versão do sistema o mais rápido possível. Os sistemas desenvolvidos com esse modelo caracterizam-se por não terem o escopo claramente definido, ou seja, a especificação do escopo é feita de forma intercalada ao desenvolvimento. Após o desenvolvimento de cada uma das versões do sistema, ele é mostrado aos usuários para comentários. Modificações sucessivas são feitas no sistema até que o mesmo seja considerado adequado. 

  Modelo de Prototipagem Descartável (Throwaway)

  O objetivo principal desse modelo é entender os requisitos do sistema. Tem sido usado com sucesso para validar partes do sistema (Interface Gráfica e aspectos do sistema relacionados à arquitetura – ex: performance, portabilidade etc.). Como na programação exploratória, a primeira etapa prevê o desenvolvimento de um programa (protótipo) para o usuário experimentar. No entanto, ao contrário da programação exploratória, o protótipo é então descartado e o software deve ser re-implementado na etapa seguinte, usando qualquer modelo de ciclo de vida.

  Fonte: Modelos de Ciclo de Vida do Processo de Software

  http://docente.ifrn.edu.br/elieziosoares/disciplinas/projeto-de-software/aula-06-outros-modelos-prescritivos-1/grupo-2-prototipacao-evolucionaria/texto-2

Questão 1141336

• Banca: FUNRIO
• Órgão: INSS
• Ano: 2014
• Provas: FUNRIO - 2014 - INSS - Analista - Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

No processo de desenvolvimento de software, o modelo de ciclo de vida em que um sistema de software é desenvolvido em vários passos similares e, em cada passo, o sistema é estendido com mais funcionalidades é denominado de modelo

• A. incremental e iterativo.
• B. concorrente.
• C. de prototipação.
• D. em cascata.
• E. de desenvolvimento ágil.

Gabarito: A

Comentários

• O ágil também não cai dentro dessa definição "vários passos similares, e em cada passo o sistema é estendido com mais funcionaliades"? Não caberia recurso?
  

• incremental e interativo - No processo de desenvolvimento de software, o modelo de ciclo de vida em que um sistema de software é desenvolvido em vários passos similares e, em cada passo, o sistema é estendido com mais funcionalidades.
  

  Concorrente - desenvolvimento que fazem uso da execução concorrente (simultânea) de varias tarefas computacionais interativas que podem ser implementados como programas separados ou como um conjunto de threads criadas por um único programa.

  Prototipação - baseada em uma visão evolutiva do desenvolvimento de software, afetando o processo como um todo. Envolve a produção de versões iniciais (prototipos) de um sistema futuro como o qual é possivel realizar verificações e experimentos, com intuito de avalizar algumas caracteristicas antes que o sistema venha realmente a ser construido.
  

  Cascata (top-down) - desenvolvimento de software sequencial no qual o desenvolvimento é visto como um fluir constante para frente (como uma cascata) através das fases de análise de requisitos, projeto, implementação, testes (validação), integração, e manutenção de software.

  Desenvolvimento Agil -  os projetos adotam o modelo iterativo e em espiral. Todas as fases descritas no modelo em cascata são executadas diversas vezes ao longo do projeto, produzindo ciclos curtos que se repetem ao longo de todo o desenvolvimento, sendo que, ao final de cada ciclo, sempre se tem um software funcional, testado e aprovado. Os ciclos são chamados de iterações e crescem em número de funcionalidades a cada repetição, sendo que, no último ciclo, todas as funcionalidades desejadas estarão implementadas, testadas e aprovadas.
  

• Victor, desenvolvimento ágil não é um modelo de ciclo de vida.

   

  Vamos na fé.

Questão 1153846

• Banca: INSTITUTO AOCP
• Órgão: UFGD
• Ano: 2014
• Provas: Instituto AOCP - 2014 - UFGD - Analista de Tecnologia da Informação - Processos
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

Sobre projeto e implementação de software, assinale a alternativa INCORRETA.

• A. Projeto de componente é parte do projeto de implementação de software responsável por projetar as estruturas de dados do sistema.
  
• B. Projeto de arquitetura e Projeto de interface podem fazer parte do processo de projeto de sistemas de informação.
  
• C. A maioria dos softwares interage com outros sistemas de software, incluindo sistema operacional, banco de dados e outros aplicativos.
  
• D. Este estágio sempre envolve processos de projeto e programação de software, porém ser for utilizada uma abordagem incremental para o desenvolvimento, também poderá envolver o refinamento da especificação do software.
  
• E. O estágio de implementação do desenvolvimento de software é o processo de conversão de uma especificação do sistema em um sistema executável.
  

Gabarito: A

Comentários

• RESPOSTA 

   a) Projeto de componente é parte do projeto de implementação de software responsável por projetar as estruturas de dados do sistema.

Questão 1153852

• Banca: INSTITUTO AOCP
• Órgão: UFGD
• Ano: 2014
• Provas: Instituto AOCP - 2014 - UFGD - Analista de Tecnologia da Informação - Processos
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

Sobre Evolução do Software, assinale a alternativa INCORRETA.

• A. A flexibilidade dos softwares é uma das principais razões pelas quais softwares vêm se transformando em sistemas grandes e complexos.
  
• B. Uma vez que a decisão da construção de um hardware foi tomada, é caríssimo fazer alterações em seu projeto. No entanto, mudanças em um software podem ser feitas a qualquer momento durante ou após o desenvolvimento.
  
• C. Distinção entre desenvolvimento e manutenção de software é cada vez mais irrelevante.
  
• D. A mudança é inevitável em todos os grandes projetos de software.
  
• E. Mudanças no desenvolvimento de software não aumentam os custos, isso ocorre porque o trabalho seria feito de qualquer forma. Muda-se apenas a maneira de como determinada função seria feita.
  

Gabarito: E

Comentários

• Questãozinha de M.

• RESPOSTA 

  e) Mudanças no desenvolvimento de software não aumentam os custos, isso ocorre porque o trabalho seria feito de qualquer forma. Muda-se apenas a maneira de como determinada função seria feita.

Questão 1172485

• Banca: CESPE / CEBRASPE
• Órgão: MEC
• Ano: 2014
• Provas: CESPE - 2014 - MEC - Especialista em Processos de Negócios
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

A respeito da engenharia de software e da UML (unified modeling language), julgue os itens subsequentes.

No desenvolvimento de software de grande porte, não se usam, em conjunto, os seguintes modelos de processo de software genéricos: modelo em cascata, desenvolvimento evolucionário e engenharia de software embasada em computador.

• C. Certo
• E. Errado

Gabarito: E

Comentários

• Erro: Engenharia de Software embasada em COMPONENTES e não COMPUTADOR.

  
  

  Os modelos genéricos de processos de software amplamente utilizados são o modelo em cascata, o modelo de desenvolvimento evolucionário e o modelo de desenvolvimento baseado em componentes. Estes, não são mutuamente exclusivos e comumente são utilizados em conjunto, especialmente para desenvolvimento de sistemas de grande porte (SOMMERVILLE, 2007).
  

• Aquele "não se usam" não torna a questão certa? Realmente não se usa  engenharia de software baseada em computador, dado que isso não existe. Alguém raciocinou parecido?

• Botei como certo, achei muito estranho esse 'processo' de engenharia de software embasada em computador.

• Engenharia de software embasada em computador é a tradução para CASE (Computer Aided Software Engineering).

  Em relação à afirmativa, em nenhuma literatura consagrada há restrição quanto à combinação de processos de software diferentes para construção de um produto final. Ademais, pode-se pensar que, em um grande projeto, faz sentido uma abordagem que envolva um ou mais dos processos de software citados.

• Não existe “engenharia de software embasada em computador” – o que existe é “engenharia de software baseada em componentes”.

Questão 1172488

• Banca: CESPE / CEBRASPE
• Órgão: MEC
• Ano: 2014
• Provas: CESPE - 2014 - MEC - Especialista em Processos de Negócios
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

A respeito da engenharia de software e da UML (unified modeling language), julgue os itens subsequentes.

A ciência da computação estuda os aspectos do desenvolvimento e da evolução de software; a engenharia de sistemas estuda as teorias e os métodos de construção; e a engenharia de software estuda o uso de ferramentas e de codificação.

• C. Certo
• E. Errado

Gabarito: E

Comentários

• Que confusão da CESPE!! A ciencia da computação não se limita a software. A engenharia de sistemas é uma abordagem para o estudo de sistemas de alta complexidade. E a engenharia de software não estuda somente ferramentas e linguagens de programação.

• Ciênciada Computação: diz respeito às teorias e aos métodos que constituem a base de computadores e sistemas de software

  Engenharia de Software: dedica-se ao problema práticos da produção de software, alguns conhecimentos da ciência da computação são essenciais à engenharia de software. 

  Engenharia de Sistemas: Diz respeito a todos os aspectos do desenvolvimento de sistemas complexos, não apenas software, mas em sistemas em que o software desempenha uma papel importante, estando mais relacionada ao projetos de hardware, projetos de políticas e de processo de implantação do sistema, com a definição de arquitetura geral e em seguida com a integração de várias partes necessárias à criação do sistema final.

  
  

  fonte: Sommerville, Engenharia de Software - 9ª edição - página: 6

• Ano: 2009

  Banca: FUNIVERSA

  Órgão: IPHAN

  Prova: Analista - Tecnologia da Informação

  A Ciência da Computação tem como objetivo o desenvolvimento de teorias e fundamentações. Já a Engenharia de Software se preocupa com as práticas de desenvolvimento de software.

  b)    A Engenharia de Software trata da criação dos sistemas de computação (softwares) enquanto a Ciência da Computação está ligada ao desenvolvimento e criação de componentes de  hardware.

  c)    A Engenharia de Software trata dos sistemas com base em computadores, que inclui hardware e software, e a Ciência da Computação trata apenas dos aspectos de desenvolvimento de sistemas.

  d)    A Ciência da Computação trata dos sistemas com base em computadores, que inclui hardware e software, e a Engenharia de Software trata apenas dos aspectos de desenvolvimento de sistemas.

  e)    A Ciência da Computação destina-se ao estudo e solução para problemas genéricos das áreas de rede e banco de dados e a Engenharia de Software restringe- se ao desenvolvimento de sistemas.

   

   

  letra A

Questão 1190266

• Banca: FGV
• Órgão: DPE-RJ
• Ano: 2014
• Provas: FGV - 2014 - DPE-RJ - Técnico Superior Especializado - Desenvolvimento de Sistemas; FGV - 2014 - DPE-RJ - Técnico Superior Especializado - Gestão em Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

Uma organização está interessada em definir um processo para orientar a sua equipe de desenvolvimento a executar as atividades necessárias para a criação e disponibilização de novas versões do produto de software que é o carro-chefe da empresa. Esse processo precisa conter explicitamente as etapas comuns de um desenvolvimento de software (por exemplo, levantamento, análise, projeto, construção e testes) e, como o produto de software em questão tem um forte requisito de qualidade, é necessário que as atividades de garantia da qualidade sejam bem explícitas em relação às etapas e/ou documentos relacionados sendo avaliados.

Dentre as opções de modelos de ciclo de vida abaixo, o mais adequado a essa necessidade é :

• A. RAD.
  
• B. modelo em V.
  
• C. cascata.
  
• D. prototipação
  
• E. XP.

Gabarito: B

Comentários

• A resposta correta é o modelo V pois são algumas de suas características: 

  
  

  The V-model provides guidance for the planning and realization of projects. The following objectives are intended to be achieved by a project execution:

  Minimization of project risks: The V-model improves project transparency and project control by specifying standardized approaches and describing the corresponding results and responsible roles. It permits an early recognition of planning deviations and risks and improves process management, thus reducing the project risk.
  Improvement and guarantee of quality: As a standardized process model, the V-Model ensures that the results to be provided are complete and have the desired quality. Defined interim results can be checked at an early stage. Uniform product contents will improve readability, understandability and verifiability.
  Reduction of total cost over the entire project and system life cycle: The effort for the development, production, operation and maintenance of a system can be calculated, estimated and controlled in a transparent manner by applying a standardized process model. The results obtained are uniform and easily retraced. This reduces the acquirers dependency on the supplier and the effort for subsequent activities and projects.
  Improvement of communication between all stakeholders: The standardized and uniform description of all relevant elements and terms is the basis for the mutual understanding between all stakeholders. Thus, the frictional loss between user, acquirer, supplier and developer is reduced.
  
  
  

  FONTE: http://en.wikipedia.org/wiki/V-Model

•  O Modelo em V garante o sistema em todas as fases, através de testes. Até por isso o nome né.

• Prezados,
  
  Alguns modelos de ciclo de vida tem características em comum, entretanto o comando da questão fala em alguns pontos que são bem característicos do modelo V, como conter um forte requisito de qualidade , e o modelo V prevê isso ao atrelar uma etapa de testes para cada evolução dos requisitos.
  
  
  Portanto a alternativa correta é a letra B
  
  

Questão 1190269

• Banca: FGV
• Órgão: DPE-RJ
• Ano: 2014
• Provas: FGV - 2014 - DPE-RJ - Técnico Superior Especializado - Desenvolvimento de Sistemas; FGV - 2014 - DPE-RJ - Técnico Superior Especializado - Gestão em Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software

Considere uma organização desenvolvedora de software que possua um processo de software composto das fases de Levantamento de Requisitos, Análise de Software, Projeto de Software, Codificação, Testes e Entrega do Software e tenha a cultura de estimar seus projetos utilizando Análise de Pontos por Função. Caso essa organização esteja interessada na criação de uma base de estimativas de seus projetos, a contagem de pontos por função seria mais indicada .

• A. na etapa de Análise do Software, pois, assim, o gerente de projetos será capaz de estimar o tempo restante do projeto com maior precisão.
  
• B. no início do projeto, na fase de Levantamento de Requisitos, pois a equipe já terá elementos suficientes para determinar o prazo de entrega do projeto.
  
• C. durante etapa de Projeto de Software, pois já haverá um grande entendimento dos requisitos e, como o software será construído logo em seguida, o valor da contagem obtido pode ser utilizado tanto para estimar o projeto quanto para calibrar a taxa média de produtividade da organização.
  
• D. no início do projeto para poder estimar a duração do projeto e elaborar um cronograma inicial, depois do detalhamento dos requisitos para refinar o cronograma e após o software ter sido concluído para, com base no tamanho real, recalcular a taxa média de produtividade da organização.
  
• E. durante a etapa de Codificação, pois os programadores, por conhecerem o produto e a complexidade de implementar os requisitos, são os mais indicados, dentre os membros da equipe de desenvolvimento, para indicar o prazo para término do projeto e de conclusão das atividades.

Gabarito: D

Comentários

• Prezados,
  
  Se a organização usa basicamente um modelo em cascata, e deseja criar uma base de estimativa para seus projetos, ela deve fazer uma contagem no início do projeto para ter uma estimativa do cronograma, e após o software produzido, fazer uma nova contagem , mais "real" , para efetivamente calcular a taxa média de produtividade da organização.
  
  Portanto a alternativa correta é a letra D
  
  

Questão 1190320

• Banca: FGV
• Órgão: DPE-RJ
• Ano: 2014
• Provas: FGV - 2014 - DPE-RJ - Técnico Superior Especializado - Desenvolvimento de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software; Processos de Software - Desenvolvimento Ágil

Uma empresa que desenvolve projetos no Visual Studio decidiu utilizar o Team Foundation Service. Uma característica relacionada ao desenvolvimento em equipe e outra, relacionada ao controle de código do Team Foundation, são respectivamente :

• A. quadro de tarefas e gerenciamento de conflitos.
  
• B. funcionar com Eclipse e permitir chamadas de função
  
• C. integrar com Microsoft Visual Studio e usar a plataforma .NET.
  
• D. testes de unidade e função de auto completar código.
  
• E. definição de testes e definição de complexidade.

Gabarito: A

Comentários

• http://www.devmedia.com.br/conhecendo-o-team-foundation-service-tfs-na-nuvem/27848

• Gabarito: A

  O Team Foundation Service é um complemento do Visual Studio que permite que uma equipe trabalhe junto em um mesmo projeto. Compartilhando o código, acompanhado o trabalho e as entregas.

  No Team Foundation, também temos a ferramenta de controle de versão de código que permite o gerenciamento de conflitos.