https://www.passeidireto.

com/arquivo/70105511/estudos-disciplinares-unip-qualidade-de-
software

1. Qualidade de software é uma área da engenharia de software que tem como objetivo
garantir a qualidade pela definição e normatização dos processos de desenvolvimento de
sistemas. O grupo de normas técnicas "ISO" define qualidade como o grau em que um
conjunto de características inerentes a um produto, processo ou sistema cumpre os requisitos
inicialmente estipulados para esses. Assinale a alternativa que melhor define "qualidade",
dentro da área de engenharia de software.

A. Conformidade de um sistema com os requisitos levantados no início do processo de

desenvolvimento.
B. Tempo de vida útil de um sistema e sua efetiva utilidade e aplicação.
C. É medida pelo máximo de tempo de uso entre falhas ocorridas no ciclo de vida do
software.
D. Desempenho medido pelo tempo de resposta no processamento e apresentação das
informações.
E. Equilíbrio entre o prazo de entrega do sistema e o atendimento mínimo dos requisitos
levantados.

2. Conforme o Constructive Cost Model, (CoCoMo), analise, assinale a alternativa:

I) É um método que busca medir esforço, prazo, tamanho de equipe e custo necessário para o
desenvolvimento do software, desde que se tenha a dimensão do mesmo, através de um
modelo de estimativa de tamanho de software, como FPA.

II) O modelo CoCoMo foi proposto por BOEHM (1981), tendo sido construído e calibrado
inicialmente a partir de informação de um número pequeno de projetos concluídos, em torno
de 13. Afirma-se que a sua utilização tem permitido estimativas com um erro inferior a 5% em
cerca de 90% dos projetos.

III) O CoCoMo 81 considera três modos de desenvolvimento: Orgânico, Semidestacado e

Geminado.

IV) O Modelo Básico, é um modelo estático de valor simples que computa o esforço e o custo
de desenvolvimento de software como uma função do tamanho de programa expresso em
linhas de código estimadas.

Assinale a alternativa que represente a afirmações:

A. Apenas I é verdadeira.
B. Apenas I e III são verdadeiras.
C. Apenas II e III são verdadeiras.
D. Apenas I e IV são verdadeiras.
E. Apenas I, II e IV são verdadeiras.

3. De acordo com a abordagem Sala Limpa, analise, assinale a alternativa:

I) É desenvolvido um plano de projeto que adota a estratégia incremental. A funcionalidade de

cada incremento, seu tamanho projetado e um cronograma de desenvolvimento sala limpa
são criados. Cuidado especial precisa ser tomado para garantir que incrementos certificados
sejam integrados de modo oportuno.

II) Usando a abordagem de estruturas de caixa, o projeto sala limpa é uma extensão natural, e
sem emendas, da especificação. Apesar de ser possível fazer uma clara distinção entre as duas
atividades, as especificações são refinadas iterativamente para tornarem-se análogas a
projetos arquiteturais e em nível de componentes. São três tipos de caixa que são usados:
Caixa-Preta, Caixa de Estado e Caixa-Clara.

III) A equipe sala limpa conduz uma série de atividades de verificação de correção rigorosas
sobre o projeto e depois sobre o código. A verificação começa com a estrutura de caixa de
mais baixo nível e se move em direção ao macro de projeto e de código. O primeiro nível de
verificação de correção ocorre pela aplicação de um conjunto de questões de correção. Se isso
não demonstrar que a especificação está correta, métodos mais formais de verificação são
usados.

IV) Como o teste de software exaustivo do software é impossível, é sempre necessário um

número finito de casos de teste. Técnicas estatísticas de uso executam uma série de testes
derivada de uma amostra estatística de todas as possíveis execuções do programa por todos
os usuários. Uma vez completados a verificação, a inspeção e o teste de uso, o incremento é
certificado como pronto para integração.

São corretas:

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

4. A difusão do uso da internet na década de 90 introduziu um novo desafio para os

engenheiros de software: projetar e implementar sistemas seguros. Como mais e mais
sistemas foram conectados à internet, uma variedade de diferentes ataques externos foi
inventada, e eles ameaçam esses sistemas. Os problemas de produção de sistemas confiáveis
aumentaram drasticamente. Os engenheiros de sistemas tiveram que considerar ameaças de
agressores maliciosos e tecnicamente experientes, bem como problemas resultantes de erros
acidentais em processos de desenvolvimento. Atualmente, é essencial projetar sistemas para
se defender dos ataques externos e se recuperar desses ataques. Sem precauções de
proteção, é quase inevitável que os agressores comprometam os sistemas em rede. Eles
podem fazer o uso errôneo do sistema de hardware, furtar dados confidenciais ou interromper
os serviços oferecidos pelo sistema. A engenharia de proteção de sistema é,
consequentemente, um aspecto importante em crescimento no processo de engenharia de
sistema.

Analise as afirmativas a seguir:

I) A engenharia de proteção enfoca como desenvolver e manter sistemas de software que

possam resistir a ataques maliciosos com a intenção de danificar um sistema baseado em
computadores ou seus dados. As ameaças de proteção podem ser ameaças à confiabilidade,
integridade ou disponibilidade de um sistema e a seus dados.
II) O gerenciamento de riscos de proteção envolve a avaliação de perdas que podem resultar
de um ataque em um sistema e a derivação de requisitos de proteção que tem como objetivo
a eliminação ou a redução dessas perdas. O projeto para proteção envolve o projeto de uma
arquitetura se sistema protegida, seguindo boas práticas de projeto de sistemas protegidos e
incluindo funcionalidades para minimizar a possibilidade de introdução de vulnerabilidades de
proteção quando o sistema for implantado.

III) As questões principais ao projetar uma arquitetura de sistemas protegida incluem a

organização de uma estrutura de sistema para proteger os ativos principais e a distribuição dos
ativos de sistemas para minimizar as perdas de um ataque bem-sucedido. As diretrizes gerais
de projetos de proteção sensibilizam os projetistas de sistemas quanto a questões de proteção
que eles podem não ter considerado. As diretrizes fornecem uma base para criar checklists
para revisão de proteção.

IV) Para apoiar a implantação de proteção, você deve prover um meio de apresentar e analisar
as configurações do sistema, localizar os parâmetros de configurações de modo que
configurações importantes não sejam esquecidas, minimizar privilégios default definidos para
usuários de sistema e fornecer meios para reparar as vulnerabilidades de proteção. A
capacidade de sobrevivência de sistemas reflete a habilidade do sistema em continuar a
fornecer os serviços de negócio essenciais ou de missão crítica para usuários legítimos quando
sob ataque ou após uma parte do sistema ter sido danificada.

Assinale a alternativa verdadeira:

A. Somente I e II são verdadeiras.

B. Somente I e III são verdadeiras.
C. Somente I, II e III são verdadeiras.
D. Somente I, III e IV são verdadeiras.
E. I, II, III e IV são verdadeiras.

5. Segundo a Engenharia de Software orientada a serviços, analise as afirmativas:

I) Serviços podem ser classificados como serviços de utilidades que fornecem alguma
funcionalidade de propósito geral, serviços de negócios que implementam parte de um
processo de negócio ou serviços de coordenação que coordenam a execução de outros
serviços. O processo da engenharia de serviços, envolve a identificação de serviços candidatos
para implementação, definição de interface de serviços e implementação, teste e implantação
dos serviços.

II) Interfaces de serviços podem ser definidas para sistemas legados de software que
continuem sendo úteis para uma organização. A funcionalidade do sistema legado pode,
portanto, ser reusada em outras aplicações. O desenvolvimento do software que usa serviços
baseia-se na idéia de que os programas são criados pela composição e configuração de
serviços para criar novos serviços compostos.

III) A engenharia de software orientada a serviços baseia-se na noção de que os programas

podem ser construídos pela composição de serviços independentes que englobam
funcionalidade reusável. Os serviços são dependentes da linguagem e sua implementação
fundamenta-se em padrões amplamente adotados baseados em XML. Interfaces de serviços
são definidas em uma linguagem baseada em XML chamada WSDL. Uma especificação WSDL
inclui uma definição de tipos de interface e operações, o protocolo de ligação usado pelo
serviço e a localização do serviço.

IV) Modelos de processo de negócio (Figura 01) definem as atividades e troca de informações
que ocorrem em algum processo de negócio. As atividades em um processo de negócio podem
ser implementadas por serviços e, desse modo, o modelo de processo de negócio representa
uma composição de serviço. Técnicas de teste de software baseadas na análise de código-
fonte não podem ser usadas em sistemas orientados a serviços que contam com serviços
fornecidos externamente.

Pode-se concluir que somente:

A. As afirmativas I e II são falsas.

B. As afirmativas II e III são verdadeiras.
C. As afirmativas I, II e IV, são verdadeiras.
D. As afirmativas II, III e IV são verdadeiras.
E. As afirmativas I, II e III são falsas.

6. (ENADE-2011- Adaptado) Uma empresa vem desenvolvendo um programa de melhoria de

seus processos de software utilizando o modelo de qualidade CMMI. O programa envolveu a
definição de todos os processos padrão da organização, implementação de técnicas de
controle estatístico de processos e métodos de melhoria contínua. Após a avaliação SCAMPI,
foi detectado que a área de processo de gestão de requisitos não estava aderente ao modelo.
Nesse contexto, considerando a representação por estágios do CMMI, a empresa seria
classificada em que nível de maturidade?

Assinale a alternativa correta:

A. Nível 1;
B. Nível 2;
C. Nível 3;
D. Nível 4;
E. Nível 5;

7. Segundo o modelo MPS-BR, analise as afirmativas:

I) Possui 08 níveis de maturidade;

II) O nível “G” é considerado o maior nível de maturidade;

III) A atividade de Gestão de Configuração faz parte do nível “F”;

IV) É originado a partir da ISSO/IEC 12.207, ISSO/IEC 15.504 e o CMMI.

Assinale a alternativa correta:

A. Apenas I é verdadeira.
B. Apenas I e II são verdadeiras.
C. Apenas II e III são falsas.
D. Apenas III e IV são verdadeiras.
E. Apenas a IV é verdadeira.

8. Sobre as características e subcaracterísticas da qualidade do produto de software, analise as

afirmativas, relacione e assinale a alternativa correta:

I) Refere-se ao relacionamento entre o nível de desempenho do software e a quantidade dos

recursos

II) Refere-se à capacidade de o software manter seu nível de desempenho, sob condições
estabelecidas, por um período de tempo.

III) Refere-se a capacidade de o software ser transferido de um ambiente para outro.

IV) Refere-se ao esforço necessário para usar um produto de software, bem como o
julgamento individual de tal uso por um conjunto explícito ou implícito de usuários.

utilizados sob as condições estabelecidas.

V) Refere-se à existência de um conjunto de funções, que satisfazem as necessidades explícitas

ou implícitas e suas propriedades específicas.

VI) Refere-se ao esforço necessário para fazer modificações específicas de software.

Associe:

( ) Funcionalidade

( ) Confiabilidade

( ) Usabilidade

( ) Eficiência

( ) Manutenibilidade

( ) Portabilidade

Pode-se concluir que estão corretas somente as afirmativas:

A. III, II, IV, I, VI e V.

B. V, II, IV, I, VI e III.
C. III, IV, II, I, VI e V.
D. V, II, III, VI, I e IV.
E. V, II, III, I, VI e IV.
9. No fim dos anos 60 um jovem engenheiro de olhar brilhante foi escolhido para “escrever”
um programa de computador para uma aplicação de fabricação automatizada. O motivo dessa
seleção era simples. Ele era a única pessoa do seu grupo técnico que assistiu a um seminário
sobre programação de computador. Sabia detalhes da linguagem de máquina e Fortran, mas
não sabia nada sobre Engenharia de Software e ainda menos sobre cronogramação e
acompanhamento de projeto. Seu chefe deu-lhe os manuais adequados e uma descrição
verbal do que tinha de ser feito. Foi informado de que o seu projeto deveria ser completado
em dois meses. Leu os manuais, considerou sua abordagem e começou a escrever códigos.
Depois de duas semanas, o chefe chamou-o a sua sala e perguntou como as coisas estavam
caminhando. “Muito bem”, disse o jovem engenheiro com o entusiasmo da juventude. “É
muito mais simples do que pensei, já fiz praticamente 75% do trabalho”. O chefe sorriu e
encorajou o jovem engenheiro a continuar o seu bom trabalho. Planejaram encontrar-se
novamente em uma semana. Uma semana depois o chefe chamou o engenheiro a sua sala e
perguntou: “Em que pé estamos?”. “Está tudo indo bem”, disse o jovem, “mas tive algumas
pequenas dificuldades, que pretendo superar e voltar aos trilhos brevemente”. “E a data de
entrega como fica?”, o chefe perguntou. “Nenhum problema”, disse o engenheiro. “Estou
perto de completar 90% do trabalho”. Se você trabalha e/ou estuda o mundo do software há
alguns anos, pode terminar a história. Não será surpresa para você que o jovem engenheiro
tenha ficado nos 90% durante o resto do prazo e terminou apenas um mês depois. Essa
história tem se repetido dezenas de milhares de vezes por desenvolvedores de software
durante as últimas quatro décadas. A grande questão é por quê?

Diante disso, analise quais afirmativas abaixo mitigariam os riscos inerentes as atividades do
jovem profissional, quando deparada com os prazos impostos pelo cliente. Assinale a
alternativa correta:

I) Faça uma estimativa que descreva os tópicos gerais, com a finalidade de atender a
expectativa do cliente e assinar o contrato de desenvolvimento do software.

II) Usando o modelo incremental de processo, desenvolva uma estratégia de engenharia de

software que entregue a funcionalidade crítica na data de entrega imposta, mas adie a
funcionalidade restante para depois.

III) Reúna-se com o cliente e explique porque a data de entrega imposta é impraticável.

IV) Ofereça uma estratégia de desenvolvimento waterfall como alternativa.

Pode-se concluir que estão corretas somente as afirmativas:

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

10. A engenharia de software tem trilhado um longo caminho, mas ainda tem muito a
prosseguir até ser considerada madura, como outras disciplinas de engenharia. Diversos
estados do EUA estão insistindo em que os ‘engenheiros’ de software sejam treinados e
certificados, assim como são os outros engenheiros. Há diversos grupos reunidos para
determinar o que pertence ao corpo de conhecimento da engenharia de software, um
currículo universitário e um exame de licenciamento. Esses esforços deverão responder a
questões difíceis, como em que grau a engenharia de software é uma mistura de criatividade e
engenharia?

Para tratar desses problemas, devemos estudar como somos semelhantes aos engenheiros, de
modo que possamos aprender com as experiências dos outros. E devemos estudar de que
maneira somo diferentes, para podermos ajustar a nossa estratégia, nossas técnicas e
ferramentas aos problemas singulares que encontramos. De modo mais geral, devemos
garantir que visualizamos a engenharia de software em um cenário mais amplo, reconhecendo
que produtos e processos de software de qualidade são gerados por pessoas criativas
trabalhando em equipes, e não por um processo que torna a produção mecânica, repetitiva.
Para esse fim, devemos conhecer outras disciplinas, incluindo as ciências sociais, de modo que
os nossos processos sejam moldados para aproveitar o melhor de cada setor que a engenharia
possa oferecer, e que os nossos produtos sejam tão úteis quanto for possível para os nossos
clientes. Por fim, devemos prestar mais atenção às consequências das decisões em engenharia
de software. Quem é o responsável quando o nosso software falha? Que papel deve ter a
certificação e o ensino nessa área? Quem assume a responsabilidade ética e jurídica de
defeitos nos requisitos, no projeto, na implementação e nos testes? Assim como ocorre com
outras disciplinas ‘maduras’, devemos aprender a ter responsabilidade sobre as nossas ações e
os nossos produtos.

Portanto, analise as afirmativas sobre o futuro e a adoção da engenharia de software e

assinale a alternativa correta:

I) São consideradas etapas para a maturidade: Abstração, Métodos e notações de análise e

projeto, A prototipagem da interface com o usuário, Arquitetura de software, Processo de
Software, Reutilização, Medição e Ferramentas e ambientes integrados.

II) Quando falamos sobre transferência de tecnologia, queremos dizer que os produtores
específicos criam e utilizam novas tecnologias, e que os consumidores adotam e empregam
essas tecnologias em seus produtos e serviços.

III) No estudo sobre tomada de decisão sobre tecnologia, notou que existem padrões distintos
quanto ao modo e a velocidade com que as tecnologias são adotadas. As primeiras pessoas a
adotarem uma tecnologia são os inovadores; eles compreendem somente 2,5% do público
total provável. Os inovadores são “aventureiros”: eles são guiados pelo desejo de serem
rápidos e fazerem algo audacioso. Um inovador geralmente lança uma ideia nova trazida de
fora dos limites normais do sistema. Nesse sentido, um inovador é um “embaixador” de sua
organização. Os inovadores são também pessoas incentivadoras, que confiam no contato
pessoal para convencer colegas a aceitarem riscos e a experimentarem uma nova tecnologia.

IV) Por fim, os retardatários, que frequentemente são contrários a adotar algo novo adotando
uma justificativa pessoal ou econômica. Eles aderem a uma nova tecnologia somente quando
estão certos de que a nova ideia não irá falhar ou quando são forçados a mudar, por exigência
de gerentes ou clientes. As regras impostas por uma organização, um comitê de padrões ou
um cliente podem encorajar os retardatários a utilizar uma nova tecnologia, quando os outros
modelos falharam. Assim, a transferência de tecnologia bem-sucedida requer não somente
uma ideia nova, mas também um público receptivo, com um estilo de adoção específico.

São corretas:

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