Prévia do material em texto

Engenharia de Software
 
	
ATIVIDADES:
1) Quando uma equipe de desenvolvimento de software destina algumas horas com questionários, reuniões, apresentações etc., o intuito é fazer um levantamento de requisitos que possibilite abstrair as necessidades do cliente.
Quanto aos requisitos, observe as afirmativas a seguir e assinale (RF) Requisitos Funcionais e (NF) para Requisitos Não Funcionais.
(NF) O sistema deve enviar a solicitação de impressão para o equipamento mais próximo ao computador solicitante.
(NF) O tempo de resposta da consulta de produtos deve ser dada por: quantidade * 0,001. Ou seja, a cada 1000 produtos um segundo.
(NF) A foto do usuário deve ser anexada somente no formato .jpg.
(RF) O aplicativo deve permitir que com no máximo 3 cliques, o usuário chegue a qualquer funcionalidade.
(RF) A recuperação de senha deve ser por meio do link enviado no e-mail.
Assinale a alternativa com a sequência correta
Alternativas:
a) RF – RF – RF – NF – NF.
b) NF – NF – NF – RF – RF. 
c) RF – NF – RF – NF – RF.
d) NF – RF – NF – RF – NF.
e) RF – NF – NF – NF – NF.
2) Um supermercado de grande movimento se prepara para receber muitos clientes devido as compras de Natal. Ocorre que, quando todos os caixas ligaram o seu terminal, a seguinte mensagem foi exibida:
“O programa não pode ser iniciado corretamente”.
Assinale a alternativa com o tipo de degradação de software correta
Alternativas:
a) Falha de software
b) Erro de software
c) Defeito de software 
d) Bug
e) Falta de atualização
3) A garantia da qualidade de software, também conhecida como SQA (Software Quality Assurance), se estende por todo o ciclo de vida do projeto. Quanto as características básicas necessárias, observe as afirmativas a seguir:
I. A metodologia deve possuir formas de se definir as métricas e as devidas aferições.
II. A metodologia deve possuir formas de se controlar as documentações produzidas.
III. A metodologia deve possuir formas de se garantir que boas práticas sejam padronizadas.
Assinale a alternativa CORRETA
Alternativas:
a) Estão corretas apenas as afirmativas I e II.
b) Estão corretas apenas as afirmativas I e III.
c) Está correta apenas a afirmativa III.
d) Estão corretas apenas as afirmativas II e III.
e) Todas as afirmativas estão corretas. 
4) Existe uma nova tendência entre os desenvolvedores de não se especializar em linguagens nativas e muitas vezes que só atendem especificamente uma única plataforma. Isso em desenvolvimento é muito interessante, por exemplo, com um único código a aplicação poderia ser interpretada pelo Android e IOS.
Com base na ISO 9126, assinale a alternativa que demonstra a tratativa da categoria correta
Alternativas:
a) Funcionalidade
b) Confiabilidade
c) Usabilidade
d) Eficiência
e) Portabilidade 
ATIVIDADES:
1) Quando se elabora um produto ou sistema, é importante seguir uma série de passos previsíveis – um roteiro que ajude a criar um resultado de alta qualidade dentro do prazo estabelecido.
Considerando os conceitos de Processos e Atividades e suas aplicações na Engenharia de Software, avalie as afirmações que seguem: 
  I. Um processo de software corresponde a divisão de uma atividade e agrupa ações com um objetivo comum. 
  II. É por meio da execução de uma atividade que a equipe poderá produzir artefatos intermediários do produto.
III. O fluxo dos processos caracteriza a organização das ações que se desenrolam em cada atividade.
É correto o que se afirma em:
Alternativas:
a) III apenas.
b) I e II apenas.
c) I, II e III.
d) II apenas.
e) II e III apenas.
2) No modelo de desenvolvimento Cascata, os sistemas são elaborados em fases ou etapas.
Esta etapa em questão, prevê a entrega de um modelo do sistema, expresso em diagramas e descrições estruturadas de funções, entre outros recursos. Nesta etapa, os profissionais envolvidos estruturam a solução em termos do como o sistema executará as funções levantadas na etapa anterior.
Assinale a alternativa que contém a expressão que sintetiza a etapa do Modelo em Cascata descrita no texto dado
Alternativas:
a) Implantação.
b) Implementação.
c) Requisitos.
d) Projeto.
e) Manutenção.
3) Uma das mais importantes publicações na área de Engenharia de Software a define como uma abordagem sistemática, disciplinada e quantificável de desenvolvimento, operação e manutenção do software, além do estudo dessas abordagens (IEEE, 2004).
A parte da definição da Engenharia de Software que menciona "além do estudo dessas abordagens" revela
Alternativas:
a) a necessidade de que os Engenheiros de Software estudem.
b) a necessidade de se criar metodologias anualmente.
c) a intenção de manter os criadores da Engenharia de Software atualizados.
d) a prerrogativa do Engenheiro de Software de poder estudar quando bem entender.
e) a intenção de manter a disciplina em constante evolução.
4) Ao ingressar em uma empresa de desenvolvimento de software você tomou conhecimento do descontentamento de muitos clientes em relação à interpretação de seus requisitos feita pelos responsáveis por levantá-los e organizá-los.  Com alguma frequência, o que era dito pelo cliente era interpretado incorretamente pelo profissional, o que acabava gerando funções inadequadas para as finalidades do sistema.  A fim de diminuir as interpretações incorretas e aprimorar a comunicação entre equipe e cliente, você decidiu sugerir um procedimento adotado no paradigma ágil de desenvolvimento.
Com base no contexto apresentado, assinale a alternativa que contém a descrição da solução adequada para o caso, segundo o pensamento ágil de desenvolvimento
Alternativas:
a) Adoção das histórias do cliente, prática pela qual o cliente descreve os requisitos desejados em uma ficha e os entrega à equipe.
b) Adoção dos procedimentos de projeto próprios das metodologias ágeis, o que impediria que requisitos mal interpretados virassem funções.
c) Aumento dos membros da equipe que levantam e tratam dos requisitos, o que diminuiria as chances de entendimentos incorretos.
d) Adoção de testes automatizados de unidade para cada um dos requisitos levantados pela equipe de desenvolvimento.
e) Contratação de Coach para atuar diretamente junto ao cliente, capacitando-o para uma melhor exposição de suas necessidades.
ATIVIDADES:
1) Uma equipe de testadores foi designada para aplicar testes em um produto de software recém implementado.  Depois de estabelecer um planejamento que entenderam adequado para o caso, a equipe o executou e, assim que o procedimento foi concluído, fizeram a entrega do produto ao cliente.  Poucos dias depois, o cliente fez contato com a equipe relatando uma série de erros observados durante a execução do produto que acabara de adquirir.  Você, então, foi destacado para descobrir os motivos (ou o motivo) da manifestação destes erros.
Considerando o contexto apresentado, assinale a alternativa que contém a providência adequada para saneamento do problema.
Alternativas:
a) Proposição da revalidação dos requisitos levantados.
b) Troca da linguagem de programação utilizada na implementação.
c) Troca do ambiente integrado de desenvolvimento utilizado na implementação.
d) Checagem dos casos de teste utilizados no procedimento.
e) Proposição de mudança na metodologia de desenvolvimento.
2) Considerando recursos usados para descobrir erros em um programa, complete as lacunas da sentença que segue:
O fato de saber que parte do código não funciona não significa que necessariamente seja conhecido o trecho do código que provoca um ou mais erros.  Assim, enquanto a atividade de ___________ consiste em executar sistematicamente o software para encontrar erros __________, a _______________ é a atividade que consiste em buscar a causa do erro e sua localização no código.
Assinale a alternativa que completa as lacunas corretamente
Alternativas:
a) verificação - desconhecidos - validação.
b) validação - desconhecidos - verificação.
c) teste - recorrentes - depuração
d) teste - desconhecidos - depuração.
e) teste - recorrentes - compilação.
3) Considerando conceitos e aplicações da depuração, avalieas afirmativas que seguem:
I. A necessidade da depuração decorre de um teste mal-sucedido.
II. Um dos recursos da depuração inclui a inspeção de variáveis.
III. A depuração equivale à aplicação de um teste menos complexo.
Considerando o contexto apresentado, assinale a alternativa correta.
Alternativas:
a) Apenas a afirmativa II é correta.
b) Apenas as afirmativas I e II são corretas.
c) Apenas as afirmativas II e III são corretas.
d) As afirmativas I, II e III são corretas.
e) Apenas a afirmativa I é correta.
4) Considerando o conceito e as aplicações do teste estrutural, avalie as afirmativas a seguir:
I.  O teste estrutural dispensa a utilização de ferramenta de teste, já que o desenvolvedor deve estar de posse do código-fonte da ferramenta.
II. O teste estrutural é também chamado caixa branca por sua estrutura e seu código serem previamente conhecidos pelo testados.
III. Em um teste estrutural, o caso de teste mais adequado é aquele capaz de percorrer, em uma única execução, todos os caminhos do código.
Considerando o contexto apresentado, assinale a alternativa correta.
Alternativas:
a) Apenas a afirmativa II é correta.
b) Apenas as afirmativas II e III são corretas.
c) Apenas as afirmativas I e II são corretas.
d) As afirmativas I, II e III são corretas.
e) Apenas a afirmativa I é correta.
DIFERENÇAS ENTRE TESTE E DEPURAÇÃO
Teste :
Teste é o processo de verificar e validar se um software ou aplicativo está livre de bugs, atende aos requisitos técnicos conforme orientado por seu design e desenvolvimento e atende aos requisitos do usuário de forma eficaz e eficiente com o tratamento de todos os casos excepcionais e limites.
Depuração : 
A depuração é o processo de consertar um bug no software. Pode ser definido como a identificação, análise e remoção de erros. Esta atividade começa depois que o software falha em executar corretamente e termina resolvendo o problema e testando o software com sucesso. É considerada uma tarefa extremamente complexa e tediosa porque os erros precisam ser resolvidos em todos os estágios da depuração.
Abaixo está a diferença entre teste e depuração:
	TESTANDO
	DEPURANDO
	O teste é o processo para encontrar bugs e erros.
	A depuração é o processo para corrigir os bugs encontrados durante o teste.
	É o processo de identificação da falha do código implementado.
	É o processo de absolvição da falha do código.
	O teste é a exibição de erros.
	A depuração é um processo dedutivo.
	O teste é feito pelo testador.
	A depuração é feita pelo programador ou desenvolvedor.
	Não há necessidade de conhecimento de design no processo de teste.
	A depuração não pode ser feita sem o conhecimento adequado de design.
	O teste pode ser feito por pessoas de dentro ou de fora.
	A depuração é feita apenas por insider. Outsider não pode fazer depuração.
	O teste pode ser manual ou automatizado.
	A depuração é sempre manual. A depuração não pode ser automatizada.
	É baseado em diferentes níveis de teste, ou seja, teste de unidade, teste de integração, teste de sistema etc.
	A depuração é baseada em diferentes tipos de bugs.
	O teste é um estágio do ciclo de vida de desenvolvimento de software (SDLC).
	A depuração não é um aspecto do ciclo de vida de desenvolvimento de software, ela ocorre como consequência do teste.
	O teste é composto pela validação e verificação do software.
	Enquanto o processo de depuração busca combinar o sintoma com a causa, com isso leva à correção do erro.
	O teste é iniciado depois que o código é escrito.
	A depuração começa com a execução de um caso de teste.
TESTE DE SOFTWARE ESTRUTURAL
O teste estrutural é um tipo de teste de software que utiliza o design interno do software para teste ou, em outras palavras, o teste de software que é realizado pela equipe que conhece a fase de desenvolvimento do software, é conhecido como teste estrutural.
O teste estrutural está basicamente relacionado ao design interno e implementação do software, ou seja, envolve os membros da equipe de desenvolvimento na equipe de teste. Basicamente, testa diferentes aspectos do software de acordo com seus tipos. O teste estrutural é exatamente o oposto do teste comportamental.
Tipos de teste estrutural:
Existem 4 tipos de teste estrutural:
Teste de fluxo de controle: o teste de fluxo de controle é um tipo de teste estrutural que usa o fluxo de controle do programa como modelo. Todo o código, design e estrutura do software devem ser conhecidos para este tipo de teste. Freqüentemente, esse tipo de teste é usado pelos desenvolvedores para testar seu próprio código e implementação. Este método é usado para testar a lógica do código para que o resultado requerido possa ser obtido.
Teste de fluxo de dados:
usa o gráfico de fluxo de controle para explorar as coisas irracionais que podem acontecer com os dados.
A detecção de anomalias no fluxo de dados é baseada nas associações entre valores e variáveis. Sem ser inicializado o uso de variáveis. Variáveis ​​inicializadas não são usadas uma vez.
Teste baseado em fatias:
foi originalmente proposto por Weiser e Gallagher para a manutenção do software. É útil para depuração de software, manutenção de software, compreensão de programa e quantificação de coesão funcional. Ele divide o programa em diferentes fatias e testa aquela fatia que pode afetar principalmente todo o software.
Teste de mutação: Teste de
mutação é um tipo de teste de software que é executado para projetar novos testes de software e também avaliar a qualidade dos testes de software já existentes. O teste de mutação está relacionado à modificação de um programa em pequenas maneiras. Ele se concentra em ajudar o testador a desenvolver testes eficazes ou localizar pontos fracos nos dados de teste usados ​​para o programa.
Vantagens do teste estrutural:
· Ele fornece testes completos do software.
· Ajuda a descobrir defeitos em um estágio inicial.
· Ajuda na eliminação de código morto.
· Não é demorado, pois é quase sempre automatizado.
Desvantagens dos testes estruturais:
· Requer conhecimento do código para realizar o teste.
· Requer treinamento na ferramenta usada para teste.
· Às vezes é caro.
Ferramentas de teste estrutural:
· JBehave
· Pepino
· Junit
· Cfix
Saiba a diferença entre Teste, Validação e Verificação de Software
Testar um software antes que ele seja entregue ao cliente, ou disponibilizado ao consumidor final, é fundamental para que ele apresente o mínimo possível de falhas e problemas. Além disso, essa fase é crucial para verificar se ele realmente cumpre o papel para o qual foi desenvolvido.
Ao longo desse artigo você entenderá a importância dos processos de validação, teste e verificação de software. Além disso, você entenderá porque é vital realizar um teste de segurança de software sempre que possível. Continue lendo e lembre-se que nossa equipe está à disposição para tirar todas as suas dúvidas!
Validação (o software é adequado?)
Durante o processo de validação, os engenheiros de software devem entender se as especificações do que foi desenvolvido — seja de uma fase ou do sistema como um todo — são apropriadas e seguem os pré-requisitos estabelecidos durante o planejamento.
Entender se o produto realmente é capaz de atender às expectativas do cliente é o principal objetivo do processo de validação. Para que você entenda melhor, responda à pergunta: “Estamos construindo o produto certo?”. A busca por essa conclusão resume bem o processo.
Verificação (o software foi feito da forma correta?)
Existem diversas maneiras, metodologias, processos e linguagens de programação para se construir um software. Assim como no tópico anterior, nesse caso também podemos utilizar uma pergunta para entender melhor o processo de verificação de software: “estamos construindo o produto de forma correta?”
De maneira simples, a verificação consiste em avaliar se existem falhas e problemas com o software (seja no código, nas funcionalidades, interface, dentre muitos outros detalhes) antes que ele seja entregue ao cliente ou disponibilizado para o público final.
Validação eVerificação (V&V)
Quando juntamos os dois conceitos de Validação e Verificação de Software é possível avaliar se ele atende à demanda que o fez necessário em primeiro lugar e, posteriormente, se ele foi construído corretamente, sem apresentar falhas, problemas e possíveis bugs.
Para isso são realizados, dentre outras tarefas, a revisão dos requisitos, de modelos, inspeção do código e outras revisões e inspeções técnicas em geral. Uma vez que os processos de V&V estejam validados é possível passar para a parte final do desenvolvimento de um software: os testes.
Testes
O teste de segurança software é o momento em que o produto é executado (por isso a necessidade de uma versão beta) para que os engenheiros possam avaliar como será a interação do programa com o consumidor final.
Dentre os principais modelos de teste de software podemos destacar seis principais:
Teste Unitário – analisa as menores unidades possíveis de um software para garantir que cada parte funciona como deve;
Teste de integração – confere se todas (ou algumas) partes estão dialogando e funcionando corretamente em conjunto;
Teste de sistemas – avalia se o sistema atende aos pré-requisitos estabelecidos na concepção do projeto;
Teste de aceitação – esse é, normalmente, o último teste realizado e tem como premissa verificar se o software está perfeito para uso pelo consumidor final;
Homologação – esse processo é feito pelo cliente ou outras partes interessadas e visa garantir, uma vez mais, que o programa atende às especificidades e funciona perfeitamente;
Teste de regressão – garante que novos componentes de um software dialoguem sem falhas com os antigos. Fundamental para novas versões.
Compilador
.
Uma captura de tela do compilador GCC versão 4.0.2 rodando em uma janela xterm. Um programa simples está sendo compilado e então executado.
Um compilador é um programa de computador (ou um grupo de programas) que, a partir de um código fonte escrito em uma linguagem compilada, cria um programa semanticamente equivalente, porém escrito em outra linguagem, código objeto.[1] Classicamente, um compilador traduz um programa de uma linguagem textual facilmente entendida por um ser humano para uma linguagem de máquina , específica para um processador e sistema operacional. Atualmente, porém, são comuns compiladores que geram código para uma máquina virtual que é, depois, interpretada por um interpretador. Ele é chamado compilador por razões históricas; nos primeiros anos da programação automática, existiam programas que percorriam bibliotecas de sub-rotinas e as reunia, ou compilava,[Nota 1] as subrotinas necessárias para executar uma determinada tarefa.[2][3]
O nome "compilador" é usado principalmente para os programas que traduzem o código fonte de uma linguagem de programação de alto nível para uma linguagem de programação de baixo nível (por exemplo, Assembly ou código de máquina). Contudo alguns autores citam exemplos de compiladores que traduzem para linguagens de alto nível como C.[4] Para alguns autores um programa que faz uma tradução entre linguagens de alto nível é normalmente chamado um tradutor, filtro[5] ou conversor de linguagem. Um programa que traduz uma linguagem de programação de baixo nível para uma linguagem de programação de alto nível é um descompilador.[6] Um programa que faz uma tradução entre uma linguagem de montagem e o código de máquina é denominado montador (assembler).[5] Um programa que faz uma tradução entre o código de máquina e uma linguagem de montagem é denominado desmontador (disassembler).[6] Se o programa compilado pode ser executado em um computador cuja CPU ou sistema operacional é diferente daquele em que o compilador é executado, o compilador é conhecido como um compilador cruzado.[7]
História
Grace Hopper em 1984.
Os softwares para os primeiros computadores foram escritos principalmente em linguagem assembly por muitos anos. As linguagens de alto nível de programação não foram inventadas até que os benefícios de ser capaz de reutilizar software em diferentes tipos de CPUs passassem a ser significativamente maiores do que o custo de se escrever um compilador. A capacidade de memória muito limitada dos primeiros computadores também criava muitos problemas técnicos na implementação de um compilador.
No final da década de 1950, as linguagens de programação independentes de máquina foram propostas. Posteriormente, vários compiladores experimentais foram desenvolvidos. O primeiro compilador foi escrito por Grace Hopper,[8] em 1952, para a linguagem de programação A-0.[9] Antes de 1957, foram desenvolvidos esforços e várias contribuições ao desenvolvimento de linguagens de alto nível foram feitas. Entre estes, o desenvolvimento da Short Code (UNIVAC), Speedcoding no IBM 701,[10][11] o Whirlwind, o BACAIC e o PRINT.[12] A equipe de desenvolvimento do FORTRAN liderada por John Backus na IBM é geralmente creditada como tendo introduzido o primeiro compilador completo em 1957 (embora tenha ocorrido simultaneamente o desenvolvimento do algebraic translator de Laning e Zierler[9]). O COBOL é um exemplo de uma linguagem da primeira geração que compilava em múltiplas arquiteturas, em 1960.[13]
Em muitos domínios de aplicação a ideia de usar uma linguagem de alto nível rapidamente ganhou força. Por causa da funcionalidade de expansão apoiada por linguagens de programação recentes e a complexidade crescente de arquiteturas de computadores, os compiladores tornaram-se mais e mais complexos.
Os primeiros compiladores foram escritos em linguagem assembly. O primeiro compilador de auto-hospedagem - capaz de compilar seu próprio código-fonte em uma linguagem de alto nível - foi criado para o Lisp por Tim Hart e Levin Mike no MIT em 1962.[14]
Características
O processo da compilação.
Normalmente, o código fonte é escrito em uma linguagem de programação de alto nível, com grande capacidade de abstração, e o código objeto é escrito em uma linguagem de baixo nível,[15] como uma sequência de instruções a ser executada pelo microprocessador.
O processo de compilação é composto de análise e síntese.[16] A análise tem como objetivo entender o código fonte e representá-lo em uma estrutura intermediária. A síntese constrói o código objecto a partir desta representação intermediária.
A análise pode ser subdividida ainda em análise léxica, análise sintática, análise semântica e geração de código intermediário. É também conhecida como front end.[16] A síntese pode ter mais variações de um compilador a outro, podendo ser composta pelas etapas de optimização de código e geração de código final (ou código de máquina), sendo somente esta última etapa é obrigatória. É também conhecida como back end.[16]
Em linguagens híbridas, o compilador tem o papel de converter o código fonte em um código chamado de byte code, que é uma linguagem de baixo nível. Um exemplo deste comportamento é o do compilador da linguagem Java que, em vez de gerar código da máquina hospedeira (onde se está executando o compilador), gera código chamado Java Bytecode.[17]
Um compilador é chamado de Just-in-time compiler (JIT) quando seu processo de compilação acontece apenas quando o código é chamado.[18] Um JIT pode fazer otimizações às instruções a medida que as compila.[18]
Muitos compiladores incluem um pré-processador. Que é um programa separado, ativado pelo compilador antes do início do processo de tradução.[19] Normalmente é responsável por mudanças no código fonte destinadas de acordo com decisões tomadas em tempo de compilação. Por exemplo, um programa em C permite instruções condicionais para o pré-processador que podem incluir ou não parte do código caso uma assertiva lógica seja verdadeira ou falsa, ou simplesmente um termo esteja definido ou não. Tecnicamente, pré-processadores são muito mais simples que compiladores e são vistos, pelos desenvolvedores, como programas à parte, apesar dessa visão não ser necessariamente compartilhada pelo usuário.
Outra parte separada do compilador que muitos usuários vêem como integrada é o linker, cuja função é unir váriosprogramas já compilados de uma forma independente e unificá-los em um programa executável.[20] Isso inclui colocar o programa final em um formato compatível com as necessidades do sistema operacional para carregá-lo em memória e colocá-lo em execução.
Fases da compilação
Análise léxica
A análise léxica é a primeira fase do compilador.[21] A função do analisador léxico, também denominado scanner, é ler o código-fonte, caractere a caractere, buscando a separação e identificação dos elementos componentes do programa-fonte, denominados símbolos léxicos ou tokens.[22] É também de responsabilidade desta fase a eliminação de elementos "decorativos" do programa, tais como espaços em branco, marcas de formatação de texto e comentários.[23] Existem disponíveis uma série de geradores automáticos de analisadores léxicos, como por exemplo, o lex. O objetivo dos geradores automáticos é limitar o esforço de programação de um analisador léxico especificando-se apenas os tokens a ser reconhecidos.[24]
Análise sintática
A análise sintática, ou análise gramatical é o processo de se determinar se uma cadeia de símbolos léxicos pode ser gerada por uma gramática.[25] O analisador sintático é o cerne do compilador, responsável por verificar se os símbolos contidos no programa fonte formam um programa válido, ou não.[26] No caso de analisadores sintáticos top-down, temos a opção de escrevê-los à mão ou gerá-los de forma automática, mas os analisadores bottom-up só podem ser gerados automaticamente.[27] A maioria dos métodos de análise sintática, cai em uma dessas duas classes denominadas top-down e bottom-up.[28] Entre os métodos top-down os mais importantes são a análise sintática descendente recursiva e a análise sintática preditiva não-recursiva. Entre os métodos de análise sintática bottom-up os mais importantes são a análise sintática de precedência de operadores, análise sintática LR canônico, análise sintática LALR e análise sintática SLR.[25] Existem disponíveis uma série de geradores automáticos de analisadores sintáticos,[29] como por exemplo, o Yacc, o Bison e o JavaCC.
Análise semântica
As análises léxica e sintática não estão preocupadas com o significado ou semântica dos programas que elas processam. O papel do analisador semântico é prover métodos pelos quais as estruturas construídas pelo analisador sintático possam ser avaliadas ou executadas.[30] As gramáticas livres de contexto não são suficientemente poderosas para descrever uma série de construções das linguagens de programação, como por exemplo regras de escopo, regras de visibilidade e consistência de tipos.[31] É papel do analisador semântico assegurar que todas as regras sensíveis ao contexto da linguagem estejam analisadas e verificadas quanto à sua validade. Um exemplo de tarefa própria do analisador semântico é a checagem de tipos de variáveis em expressões.[32] Um dos mecanismos comumente utilizados por implementadores de compiladores é a Gramática de Atributos, que consiste em uma gramática livre de contexto acrescentada de um conjunto finito de atributos e um conjunto finito de predicados sobre estes atributos.[33]
Geração de código intermediário
Exemplo de código de três endereços e um DAG correspondente para uma expressão aritmética.
Na fase de geração de código intermediário, ocorre a transformação da árvore sintática em uma representação intermediária do código fonte. Esta linguagem intermediária é mais próxima da linguagem objeto do que o código fonte, mas ainda permite uma manipulação mais fácil do que se código assembly ou código de máquina fosse utilizado.[34] Um tipo popular de linguagem intermediária é conhecido como código de três endereços.[35] Neste tipo de código uma sentença típica tem a forma X := A op B, onde X, A e B são operandos e op uma operação qualquer. Uma forma prática de representar sentenças de três endereços é através do uso de quádruplas (operador, argumento 1, argumento 2 e, resultado). Este esquema de representação de código intermediário é preferido por diversos compiladores, principalmente aqueles que executam extensivas otimizações de código, uma vez que o código intermediário pode ser rearranjado de uma maneira conveniente com facilidade.[36] Outras representações de código intermediário comumente usadas são as triplas, (similares as quádruplas exceto pelo fato de que os resultados não são nomeados explicitamente) as árvores, os grafos acíclicos dirigidos(DAG) e a notação polonesa.[37]
Otimização de código
A otimização de código é a estratégia de examinar o código intermediário, produzido durante a fase de geração de código com objetivo de produzir, através de algumas técnicas, um código que execute com bastante eficiência.[32] O nome optimizador deve sempre ser encarado com cuidado, pois não se pode criar um programa que leia um programa P e gere um programa P´ equivalente sendo melhor possível segundo o critério adotado.[23] Várias técnicas e várias tarefas se reúnem sob o nome de Optimização. Estas técnicas consistem em detectar padrões dentro do código produzido e substituí-los por códigos mais eficientes.[36] Entre as técnicas usadas estão a substituição de expressões que podem ser avaliadas durante o tempo de compilação pelos seus valores calculados, eliminação de subexpressões redundantes, desmembramento de laços, substituição de operações (multiplicação por shifts), entre outras.[32] Uma das técnicas de optimização mais eficazes e independente de máquina é a otimização de laços, pois laços internos são bons candidatos para melhorias. Por exemplo, em caso de computações fixas dentro de laços, é possível mover estas computações para fora dos mesmos reduzindo processamento.[38]
Geração de código final
A fase de geração de código final é a última fase da compilação. A geração de um bom código objeto é difícil devido aos detalhes particulares das máquinas para os quais o código é gerado. Contudo, é uma fase importante, pois uma boa geração de código pode ser, por exemplo, duas vezes mais rápida que um algoritmo de geração de código ineficiente.[36] Nem todas as técnicas de optimização são independentes da arquitetura da máquina-alvo. Optimizações dependentes da máquina necessitam de informações tais como os limites e os recursos especiais da máquina-alvo a fim de produzir um código mais compacto e eficiente. O código produzido pelo compilador deve se aproveitar dos recursos especiais de cada máquina-alvo.[32] Segundo Aho, o código objeto pode ser uma sequência de instruções absolutas de máquina, uma sequência de instruções de máquina relocáveis, um programa em linguagem assembly ou um programa em outra linguagem.[39]
Tratamento de erros
Tratamento de erro de execução em uma aplicação Java no Eclipse.
O tratamento de erros está voltado a falhas devido a muitas causas: erros no compilador, erros na elaboração do programa a ser compilado, erros no ambiente (hardware, sistema operacional), dados incorretos, etc. As tarefas relacionadas ao tratamento de erros consistem em detectar cada erro, reportá-lo ao usuário e possivelmente fazer algum reparo para que o processamento possa continuar.[40]
Os erros podem ser classificados em erros léxicos, erros sintáticos, erros não independentes de contexto (semânticos), erros de execução e erros de limite.[41] Os erros léxicos ocorrem quando um token identificado não pertence a gramática da linguagem fonte. Os erros sintáticos ocorrem quando alguma estrutura de frase não está de acordo com a gramática, como por exemplo parênteses sem correspondência. Os erros não independentes de contexto em geral são associados a não declaração de objetos como variáveis e erros de tipos. Os erros de execução ocorrem após a compilação, quando o programa já está sendo executado. Um exemplo típico é o da divisão por zero. Os erros de limite, ocorrem durante a execução e estão relacionados as características da máquina na qual o programa está sendo executado, como por exemplo, estouro de pilha.[41]
Alguns compiladores encerram o processo de tradução logo ao encontrar o primeiro errodo programa-fonte. Esta é uma política de fácil implementação. Compiladores mais sofisticados, porém, detectam o maior número possível de erros visando diminuir o número de compilações.[42]
A recuperação de erros em analisadores sintáticos top-down é mais fácil de implementar do que em analisadores bottom-up.[43] O problema é que diferente de um analisador top-down, este último não sabe quais símbolos são esperados na entrada, somente os que já foram processados. Pode-se usar neste caso técnicas como, por exemplo, a técnica de panic-mode que procura em tabelas sintáticas em busca de símbolos válidos na entrada.[43] Nesta técnica se descartam símbolos da entrada até que um delimitador (como um ponto e vírgula, por exemplo) seja encontrado. O analisador apaga as entradas da pilha até que encontre uma entrada que permita que o processo de análise prossiga em diante.[44]
ATIVIDADES:
1) Os métodos da Engenharia de Software fornecem as informações técnicas para desenvolver softwares, que envolvem tarefas de comunicação, análise de requisitos, modelagem de projeto e construção de programas, entre outras.  Os métodos da Engenharia de Software se baseiam em princípios que governam cada área da tecnologia.
Considerando os conceitos apresentados, o objetivo final da Engenharia de Software é
a) o aprimoramento da comunicação entre a equipe de desenvolvimento e cliente, como forma de aumentar as chances de sucesso.
b) a criação e desenvolvimento de estratégias para cumprimento de prazos, com base nas melhores técnicas de gestão de projetos.
c) a criação de um produto de software de qualidade, adequado ao seu propósito e nos limites de prazo e orçamento.
d) o compartilhamento das técnicas de programação entre equipes, aumentando assim seu conhecimento técnico.
e) o fortalecimento da união da equipe de desenvolvedores, o que aumentará as chances de todos mirem um só objetivo.
2) Em seu conceito formal, um software apresenta mais elementos do que aqueles com os quais estamos acostumados a defini-lo.  Assim, com o devido rigor na forma, um software consiste de _______________ que, ao serem executadas, desempenham as funções desejadas.  Além disso, um software é formado por ____________ que permitem o armazenamento e a recuperação de dados.  O componente final de um software é formado por ________________ relacionadas ao funcionamento, geralmente registradas em meio eletrônico.
Assinale a alternativa que contém as expressões que corretamente completam a sentença dada
Alternativas:
a) instruções, estruturas de dados, informações descritivas.
b) instruções, informações descritivas, estruturas de dados.
c) parametrizações, mídias eletrônicas, soluções.
d) instruções, mídias eletrônicas, estruturas de dados.
e) soluções, informações descritivas, parametrizações.
3) Durante os anos 1970 e 1980 foi desenvolvida uma série de técnicas e métodos de Engenharia de Software, como a Programação Estruturada, a Ocultação de Informação e o desenvolvimento Orientado a Objetos.  Foram desenvolvidas ferramentas e notações que compõem a base da Engenharia de Software atual.
Considerando circunstâncias e características da Crise do Software, analise as afirmações que seguem:
I. A expressão "Crise do Software" representa um período recente da existência da Engenharia de Software em que o desenvolvimento de software passou por uma crise técnica, e que foi sanada pelo advento do paradigma de Orientação a Objetos.
II. Trata-se de um período de crise que a atividade de desenvolvimento de software passou e que se caracterizou por fracassos nos projetos, produtos fora das especificações, clientes insatisfeitos e extrapolação de prazos e de orçamentos.
III. Trata-se de eventuais desentendimentos entre desenvolvedores de software relacionados à estilo de codificação, paradigma de programação, entendimento do projeto e demais elementos que caracterizam a atividade de desenvolvimento de software.
É verdadeiro o que se afirma em:
Alternativas:
a) I e II apenas.
b) II apenas.
c) I apenas.
d) II e III apenas.
e) I, II e III.
4) A necessidade de desenvolvimento rápido de software e de processos que possam lidar com requisitos que mudam foi reconhecida há muitos anos.  Entretanto, o desenvolvimento mais rápido de software só decolou no final dos anos 1990.  O desenvolvimento rápido de software passou a ser conhecido como desenvolvimento ágil, ou método ágil.
Assinale a alternativa que contém a correta conceituação de Manifesto Ágil
Alternativas:
a) Manifestação rápida e objetiva feita pelos criadores do Modelo em Cascata defendendo a efetividade da sua metodologia.
b) Documento elaborado pelos criadores do pensamento ágil de desenvolvimento, no qual estabelecem as bases deste novo paradigma.
c) Documento elaborado por usuários do Extreme Programming no qual sugerem mudanças estruturais na metodologia.
d) Manifestação dos criadores do pensamento ágil na qual estabelecem mudanças no Modelo em Cascata.
e) Pequena lista de pontos positivos e pontos negativos das metodologias ágeis, criada pelos seus usuários.
ATIVIDADES:
1)
Erros e falhas em software podem ter consequências drásticas para empresas, pessoas e governo. Imagine que, o programa de declaração de imposto de renda efetue cálculo errado, e gere mais restituição aos contribuintes do que deveria. Isso poderia quebrar a economia do país.
A engenharia de software, possui uma área do conhecida como ______________________________. Que tem como finalidade de fornecer _________________ para que os desenvolvimentos de software sejam produzidos dentro da _______________________.
Assinale a alternativa que complete as lacunas corretamente.
Alternativas:
· a)
qualidade de processo – ISO – conformidade.
· b)
qualidade de software – métodos – conformidade.
Alternativa assinalada
· c)
qualidade de produto – leis – conformidade.
· d)
qualidade de software – leis – organização.
· e)
qualidade de software – NBR – disponibilidade.
2)
Uma empresa de logística necessita de um software especifico para controlar o estoque, as entradas e saídas de material. Ocorre que, apesar de estar utilizando a aplicação a mais de um ano, os produtos nunca passaram de 700 unidades de registro.
Devido as vendas de final de ano houve a necessidade de ter estoque maior de alguns produtos, que acabaram passando de mil unidades. O operador percebeu que ao passar as mil unidades o contador voltava a zero e reiniciava a contagem. Como no exemplo: havia 900 peças x no estoque, foram adicionadas mais 200 peças x, e o estoque está marcando apenas 100 peças.
Assinale a alternativa com o tipo de degradação de software correta
Alternativas:
· a)
Falha de software
· b)
Erro de software
Alternativa assinalada
· c)
Defeito de software
· d)
Bug
· e)
Travamento
3)
Ao se desenvolve um software, a equipe de levantamento de requisitos (funcionais e não funcionais), deve abstrair ideias, necessidades, pensamentos e convergir isso em código. Além disso, existe o aspecto qualitativo que é de grande importância.
Quanto aos benefícios em se utilizar ferramentas para a garantia da qualidade de software, observe as afirmativas a seguir.
I. Maior lucratividade, uma vez que com menor número de colaboradores a produção será maior.
II. Padronização de algumas atividades, a fim de se agregar processos com qualidade.
III. Adquirir computadores com menor custo, uma vez que o código está otimizado.
Assinale a alternativa CORRETA
Alternativas:
· a)
Está correta apenas a afirmativa I.
· b)
Está correta apenas a afirmativa II.
Alternativa assinalada
· c)
Está correta apenas a afirmativa III.
· d)
Estão corretas apenas as afirmativas I e II.
· e)
Estão corretas apenas as afirmativas II e III.
4)
Ao se utilizar uma aplicação seja ela em desktop ou mobile, é esperado que esse possua o mínimo da qualidade esperada, e que gere o retorno conforme o prometido. Imagine que, se tenha um software que prometa remover o áudio de uma filmagem, porém além de não remover, ainda adiciona um chiado.
Para resolver tais problemas em desenvolvimentos, a engenharia de software possuiuma área conhecida por _______________________________ de software. Onde existe uma ___________________ da qualidade do desenvolvimento, a fim de se gerar _________________ para que a equipe possa proceder com os ajustes e correções.
Assinale a alternativa que complete as lacunas corretamente.
Alternativas:
· a)
qualidade de software – simplificação – reclamação.
· b)
qualidade de processo – abandono – insights.
· c)
qualidade de processo – rejeição – denúncia.
· d)
qualidade de produto – avaliação – insights.
Alternativa assinalada
· e)
qualidade de produto – rejeição – reclamações.
ATIVIDADES:
1)
O planejamento do teste se preocupa com o cronograma e a definição dos recursos para todas as atividades do processo de teste, levando em conta desde a definição do processo até as pessoas envolvidas.
Testar não se resume a executar o programa em busca de defeitos.  Para sua efetivação, um procedimento de teste precisa de planejamento e, nesta etapa, deverão ser definidos elementos para o momento de se executar o programa em busca de defeitos.  Tais elementos compõem um conjunto finito de  entradas selecionadas e as respectivas saídas esperadas.  A estes elementos dá-se o nome de
Alternativas:
· a)
simuladores de teste.
· b)
resultados de teste.
· c)
casos de teste.
Alternativa assinalada
· d)
entradas de teste.
· e)
saídas de teste.
2)
Considerando conceitos e aplicações das atividades de Verificação e Validação (V&V), complete as lacunas da sentença que segue:
 
A verificação preocupa-se com a comprovação de que um certo fluxo de trabalho foi corretamente executado e sua aplicação se dá ______________ destes fluxos.  Já a validação consiste em determinar se o artefato ____________ está alinhada com a perspectiva   _________.
Assinale a alternativa que completa as lacunas corretamente.
Alternativas:
· a)
ao final - inicial - do desenvolvedor.
· b)
ao final - acabado - do cliente.
Alternativa assinalada
· c)
no início - acabado - do cliente.
· d)
no início - intermediário - do cliente.
· e)
ao final - acabado - da equipe.
3)
Por melhores que sejam as técnicas de modelagem e especificação de software, por mais disciplinada e experiente que seja a equipe de desenvolvimento, sempre haverá um fator que torna o teste de software necessário: o erro humano.
 
Fonte: WAZLAWICK, R. S. Engenharia de software: conceitos e práticas. Rio de Janeiro: Elsiever, 2013.
 
Tomando como refere^ncia conceitos e aplicações relacionadas a teste de software, julgue as afirmativas a seguir em (V) Verdadeiras ou (F) Falsas.
 
(  ) O processo de teste de um software deve ser executado sem a presença ou orientação do desenvolvedor, já que o responsável pela inserção do erro não deve ser o responsável pela sua correção.
(  ) O teste é executado por meio da verificação dinâmica de um programa, o que significa que o procedimento deve ser executado de forma ágil e breve, visando liberação da equipe para outro projeto.
(  ) Um teste executado após a correta seleção dos casos de teste, da designação dos testadores e da definição clara de etapas do procedimento tenderá a não revelar defeitos no código.
Assinale a alternativa que apresenta a seque^ncia CORRETA.
Alternativas:
· a)
F - F - V.
· b)
F - F - F.
Alternativa assinalada
· c)
V - F - F.
· d)
F - V - F.
· e)
V - F - V.
4)
Considerando o conceito e as aplicações do teste funcional, avalie as afirmativas a seguir:
 
I. Pode ser executado independentemente do conhecimento dos testadores em relação ao código-fonte e à estrutura do programa.
II. A identificação das funções que o programa deve desempenhar deve ser um dos itens levantados na fase de planejamento.
III. Um teste funcional não deve ser aplicado simultaneamente em todas as funções do sistema e nem em apenas uma única ocasião.
Considerando o contexto apresentado, assinale a alternativa correta:
Alternativas:
· a)
Apenas a afirmativa III é correta.
· b)
Apenas a afirmativa II é correta.
· c)
Apenas as afirmativas I e III são corretas.
· d)
Apenas as afirmativas II e III são corretas.
· e)
As afirmativas I, II e III são corretas.
Alternativa assinalada
Teste funcional
9 línguas
· Artigo
· Discussão
· Ler
· Editar
· Ver histórico
Origem: Wikipédia, a enciclopédia livre.
Teste funcional é um processo de garantia de qualidade[1] e um tipo de teste de caixa preta que baseia seus casos de teste nas especificações do componente de software sob teste. As funções são testadas alimentando-as com entrada e examinando a saída, e a estrutura interna do programa raramente é considerada (ao contrário do teste de caixa branca).[2] O teste funcional é realizado para avaliar a conformidade de um sistema ou componente com os requisitos funcionais especificados.[3] O teste funcional geralmente descreve o que o sistema faz.
Como o teste funcional é um tipo de teste de caixa preta, a funcionalidade do software pode ser testada sem conhecer o funcionamento interno do software. Isso significa que os testadores não precisam conhecer linguagens de programação ou como o software foi implementado. Isso, por sua vez, pode levar à redução do viés do desenvolvedor (ou viés de confirmação) nos testes, uma vez que o testador não esteve envolvido no desenvolvimento do software.[4]
O teste funcional não implica que você está testando uma função (método) de seu módulo ou classe. O teste funcional testa uma fatia da funcionalidade de todo o sistema.
O teste funcional difere do teste de sistema no sentido de que o teste funcional "verifica um programa comparando-o com ... documento(s) ou especificação(ões) de design", enquanto o teste de sistema "valida um programa comparando-o com o usuário publicado ou requisitos de sistema."[5]
Tipos
O teste funcional tem muitos tipos:[2]
· Teste de fumaça
· Teste de sanidade
· Teste de regressão
· Teste de usabilidade
Seis etapas
O teste funcional normalmente envolve seis etapas:
1. A identificação das funções que se espera que o software execute
2. A criação de dados de entrada com base nas especificações da função
3. A determinação da produção com base nas especificações da função
4. A execução do caso de teste
5. A comparação dos resultados reais e esperados
6. Verificar se o aplicativo funciona de acordo com a necessidade do cliente.
ATIVIDADES:
1)
Uma empresa de desenvolvimento de software vem encontrando problemas que se repetem em diversos projetos. Isso tem causado atrasos nas entregas dos mesmos, uma vez que é necessário mais tempo para efetuar os ajustes em cada um dos projetos.
Assinale a alternativa que descreva qual ponto deve ser observado em um processo de auditoria.
Alternativas:
a)
Os clientes.
b)
Os requisitos.
c)
Os gerentes de projetos.
d)
Os colaboradores.
e)
Os processos.
Alternativa assinalada
2)
A utilização de auditoria, facilita a compreensão de falhas que muitas vezes não são percebidas em atividades cotidianas. Porém, não é somente essa função que os processos de auditoria têm como objetivo. Com base desse contexto, observe as afirmativas a seguir:
I. Verificar se existe brechas ou falhas de segurança nos sistemas.
II. Propor a utilização de tecnologias mais modernas e atuais.
III. Auxiliar no desenvolvimento dos problemas apontados.
Assinale a alternativa CORRETA:
Alternativas:
a)
Está correta apenas a afirmativa I.
Alternativa assinalada
b)
Está correta apenas a afirmativa II.
c)
Está correta apenas a afirmativa III.
d)
Estão corretas apenas as afirmativas I e II.
e)
Estão corretas apenas as afirmativas II e III.
3)
O ataque de SQL Injection é uma técnica de intrusão de sistemas na qual o agressor utiliza as instruções SQL em campos de formulário e URL, a fim de se obter dados ou apenas danificar o banco de dados e consequentemente o sistema.
Figura 01 – Exemplo de ataque SQL Injection.
Fonte: elaborado pelo autor.
Com base nos conhecimentos acerca de auditoria em sistemas computacionais, assinale a alternativa com a atribuição da auditoria quanto a esse caso de SQL Injection.
Alternativas:
a)
Fazer testes de uso apenas.
b)
Fazer teste de uso, análise documental e verificação de script.Alternativa assinalada
c)
Fazer análise documental apenas.
d)
Fazer a verificação de script apenas.
e)
Fazer testes de uso, ajuste de scripts e reunião com gerente de projetos.
4)
O controle geral está relacionado as políticas da empresa, costumes e demais particularidades. Isso, impacta diretamente como o software deve ser desenvolvido. Permitindo em um segundo momento que se realize os processos de auditoria a fim de saber se os requisitos foram atendidos.
 
Quanto ao controle geral, assinale (V) verdadeiro ou (F) falso nas afirmativas a seguir:
(   ) O sistema de gestão pode ser acessado em computadores fora da empresa.
(   ) A senha de login deve ter 6 dígitos alfanuméricos.
(   ) O sistema deve ser responsivo pois, será acessado também a partir de smartphones.
(   ) O vendedor tem uma margem de até 10% de desconto para as vendas registradas no sistema.
(   ) A cultura interna da empresa não permite nenhum colaborador trabalhar aos sábados.
Assinale a alternativa com a sequência correta.
Alternativas:
a)
F – V – F – V – F.
b)
V – F – V – F – V.
c)
V – V – V – V – V.
d)
V – F – F – V – V.
Alternativa assinalada
e)
F – F – F – F – F
ATIVIDADES:
1)O Manifesto Ágil é o embasamento filosófico de todos os métodos ágeis e diversos métodos de desenvolvimento de software estão alinhados a ele.
 
Fonte: GOMES, André Faria. Agile: desenvolvimento de software com entregas frequentes e foco no valor do negócio. Edição Eletrônica: Casa do Código, 2013
 
Considerando o conteúdo do Manifesto Ágil e as intenções de seus autores ao elaborá-lo, avalie as afirmativas a seguir:
I. A metodologia ágil deve proporcionar meios de tornar efetiva e colaborativa a participação do cliente no projeto, bem como incentivar a motivação dos membros da equipe.
II. A disponibilização de uma parte executável de um software terá eficácia maior em promover o aprendizado do cliente em relação ao sistema do que teria uma farta documentação a respeito dele.
III. Alterações nos requisitos não devem ser encaradas como um retrocesso no projeto.  Ao invés disso, a equipe pode extrair dessas alterações oportunidades de construir um produto melhor.
IV. As equipes devem manter um ritmo de desenvolvimento que seja regular e que proporcione ao cliente entregas em períodos igualmente regulares, viabilizando o feedback contínuo entre as partes.
Considerando o contexto apresentado, assinale a alternativa correta.
Alternativas:
a)
Apenas as afirmativas I e IV são corretas.
b)
Apenas as afirmativas II e IV são corretas.
c)
As afirmativas I, II, III e IV são corretas.
Alternativa assinalada
d)
Apenas as afirmativas III e IV são corretas.
e)
Apenas as afirmativas I, II e IV são corretas.
2)
A Programação Extrema era controversa, já que introduziu uma série de práticas ágeis muito diferentes do desenvolvimento tradicional da época, incluindo a de que o envolvimento do cliente seria apoiado por seu engajamento contínuo no time de desenvolvimento.
 
Fonte: adaptado de  SOMMERVILLE, Ian. Engenharia de Software. 10. ed. São Paulo: Pearson Prentice Hall, 2018. 
 
I. O surgimento das metodologias ágeis representou o rompimento com certas ideias do modelo tradicional e uma das grandes inovações apresentadas pelo pensamento ágil foi a efetiva inclusão do cliente no processo de desenvolvimento.
 
PORQUE
 
II. Com a adoção desta prática, seus criadores previram que muitas atividades próprias de um projeto experimentariam aprimoramentos, principalmente a codificação das funções e a escolha da plataforma de desenvolvimento do produto.
A respeito dessas asserc¸o~es, assinale a alternativa correta.
Alternativas:
a)
As asserc¸o~es I e II sa~o proposic¸o~es verdadeiras e a II justifica a I.
b)
As asserc¸o~es I e II sa~o proposic¸o~es verdadeiras e a II na~o justifica a I.
c)
A asserc¸a~o I e´ uma proposic¸a~o verdadeira e a II, falsa.
Alternativa assinalada
d)
A asserc¸a~o I e´ uma proposic¸a~o falsa e a II, verdadeira.
e)
As asserc¸o~es I e II sa~o proposic¸o~es falsas.
3)
O CVS é uma ferramenta open source, que implementa as principais funções relacionadas ao processo de controle de versões. O CVS armazena em seu repositório as modificações realizadas num arquivo ao longo do tempo; cada modificação é identificada por um número chamado revisão. Toda revisão armazena as modificações realizadas, quem realizou as modificações, quando foram realizadas, entre outras informações.
 
A figura que segue representa operações realizadas pelo CVS e os números nela colocados substituem o nome dessas operações.
 
 
 
De acordo com o funcionamento do CVS expresso na figura, fac¸a a associac¸a~o dos números contidos na Coluna A com suas respectivas descrições na Coluna B.   Coluna A Coluna B [1] - I I - Trata-se da recuperação (ou download) de um módulo inteiro a partir de um repositório, sem os arquivos administrativos CVS. [2] - R II - Função que efetiva a criação de um módulo completo no âmbito de um repositório CVS, feita por meio de um upload de uma estrutura de diretórios. [3] - S III - Função que realiza o envio do artefato modificado ao repositório do CVS. [4] - E IV - Função que realiza a primeira recuperação (ou download) de um módulo do sistema vindo do repositório do CVS.
Assinale a alternativa que apresenta a associac¸a~o CORRETA entre as colunas.
Alternativas:
a)
1 - II;  2 - III; 3 - IV; 4 - I.
Alternativa assinalada
b)
1 - I;  2 - II; 3 - III; 4 - IV.
c)
1 - II;  2 - IV; 3 - III; 4 - I.
d)
1 - IV;  2 - III; 3 - II; 4 - I.
e)
1 - II;  2 - I; 3 - IV; 4 - III.
4)
Considerando o tratamento dado pelo CVS às versões de um programa geradas a cada alteração, avalie as afirmativas que seguem:
 
I. A cada alteração feita no programa corresponde um novo número de versão gerado pelo CVS.
II. A geração de uma nova versão pelo CVS está sujeita a alteração de, ao menos, uma unidade completa do programa.
III. A cada checkout feito pelo CVS corresponde uma nova versão do produto criada automaticamente.
Considerando o contexto apresentado, assinale a alternativa correta.
Alternativas:
a)
As afirmações I, II e III são corretas.
b)
Apenas as afirmativas I e III são corretas.
c)
Apenas a afirmativa I é correta.
Alternativa assinalada
d)
Apenas as afirmativas I e II são corretas.
e)
Apenas a afirmativa II é correta.
5)
Quando uma versão de pré-lançamento do software está pronta, o time de desenvolvimento à entrega ao time de gerenciamento da qualidade, que verifica se a qualidade do sistema é aceitável.  A aprovação do setor de qualidade deve ser a etapa final antes de qualquer liberação de produto ao cliente.
Assinale a alternativa que contém a correta descrição de release.
Alternativas:
a)
Trata-se da versão do software enviada ao time de controle de qualidade.
b)
Versão do sistema que foi lançada para utilização do cliente em sua organização.
Alternativa assinalada
c)
O mesmo que versão de software, só que com numeração diferente.
d)
Sistema ou unidade ainda não completa o suficiente para se tornar uma versão.
e)
Nome que se dá a primeira versão de qualquer produto de software.
ATIVIDADES:
1)
Um auditor em tecnologia da informação possuí algumas atribuições que visam atender as mais diversas demandas. Muitas vezes são necessários especialistas a fim de se conseguir fazer as devidas análises.
Quanto as atribuições dos auditores de desenvolvimento de sistemas, assinale (V) verdadeiro ou (F) falso nas afirmativas a seguir.
(   )  O auditor tem atribuição de inspeção, onde deve fazer a análise de colaboradores de gestores de projetos.
(   )  O auditor tem atribuição de controle, onde são verificados os processos e contratos.
(   )  O auditor tem atribuição de análise de risco, onde são verificados os pontos que podem de alguma forma prejudicar o sistema.
(   )  O auditor tem atribuição de análises pessoais, pautados em experiências anteriores.
(   )  O auditor tem atribuição de consultor, pois é um profissional especializado e experiente.
Assinale a alternativa com a sequência correta.
Alternativas:
a)
V – V – F – F – V.
b)
V – F – V – F – F.
c)
F – F – V – F – F.
Alternativaassinalada
d)
F – F – F – V – V.
e)
V – F – V – F – V.
2)
O profissional de tecnologia da informação que busca vulnerabilidades em sistemas é conhecido por "pentest". Este profissional tem habilidades e competências para verificar se os sistemas estão suscetíveis a intrusão.
Assinale a alternativa com o tipo auditoria que esse profissional pode realizar.
Alternativas:
a)
Intrusão.
b)
Vulnerabilidade de dados.
c)
Segurança e proteção dos dados.
Alternativa assinalada
d)
Bug.
e)
Falta de atualização.
3)
Quando uma empresa de desenvolvimento contrata uma auditoria, é iniciado um ciclo de vida, que trata de um período de convívio entre colaboradores da empresa e auditores, mas sempre com o intuito de promover melhorias.
 
Quanto as características do ciclo de vida da auditoria, observe as afirmativas a seguir:
I. Pode ter variação de tempo de um projeto para outro.
II. Possui 4 etapas em seu ciclo de vida.
III. Não contempla a geração de insights.
Assinale a alternativa CORRETA
Alternativas:
a)
Estão corretas apenas as afirmativas I e II.
Alternativa assinalada
b)
Estão corretas apenas as afirmativas I e III.
c)
Está correta apenas a afirmativa III.
d)
Estão corretas apenas as afirmativas II e III.
e)
Estão corretas as afirmativas I, II e III.
4)
Existem algumas regras, costumes e politicas administrativas que são peculiares de cada empresa. E esses pontos moldam a forma como as funcionalidades devem ser desenvolvidas. E com isso, são passiveis de análises por meio de auditoria.
Com base no exposto, assinale a alternativa da área que trata das estruturas internas das organizações.
Alternativas:
a)
Controle ajustado
b)
Controle distribuído
c)
Controle centralizado
d)
Controle especifico
e)
Controle geral
Alternativa assinalada
PROCESSO DE SOFTWARE
Processo de software. Um processo de software é um conjunto de atividades relacionadas, que levam à produção de um produto de software (SOMMERVILLE, 2011). 4 etapas fundamentais:
Especificação de software (validação de requisitos).
Projeto e implementação de software (projeto de arquitetura).
Validação de software (testes unitários).
Evolução de software (manutenção de software).
Produtos (ou artefatos): são o resultado de determinada atividade do processo.
Papéis: trabalho dos envolvidos em uma ou mais etapas do processo.
Condições preliminares e as condições posteriores aos resultados das etapas. Por exemplo: uma etapa prevê a criação de uma lista de funcionalidades do software a ser construído, o que constitui a condição preliminar. Após a criação dessa lista, apura-se e descreve-se o resultado como condição posterior.
MODELOS DE PROCESSOS
Entendemos que o modelo em cascata é um processo de software, pois se utiliza de uma sequência de etapas (ao invés de uma única ação) para o atingimento de seu objetivo. Os processos contêm divisões em sua estrutura e, a fim de entendermos melhor um processo de software, convém analisarmos duas delas, de acordo com Wazlawick (2013).
FASES
Um conjunto de atividades afins e com objetivos bem definidos são realizados em uma fase do processo. O modelo em cascata, por exemplo, apresenta fases bem definidas, quais sejam a fase dos requisitos, a fase do projeto, a da implementação e assim por diante.
ATIVIDADES OU TAREFAS
Em suas regras processuais, a organização pode determinar que seja adotado um documento que descreva a atividade. Por meio dele, a equipe tomará conhecimento da tarefa, de seus responsáveis, dos objetivos, dos recursos a serem utilizados e de tudo o que a caracteriza por completo.
Sabemos até o momento que um processo é um conjunto disciplinado e articulado de tarefas que serve para sistematizar o desenvolvimento de um software.
Há certos modelos de processos ditos prescritivos, que contêm descrições de como as atividades são realizadas. O modelo cascata, também conhecido como modelo tradicional, é o mais conhecido e ainda bastante utilizado para desenvolvimento de produtos de software. Ele descreve, por meio de etapas bem definidas, o ciclo que o software cumprirá durante o período compreendido entre sua concepção e sua descontinuidade.
CONTROLE DE VERSÃO COM GITHUB BRANCH Um branch representa uma linha independente de desenvolvimento em um projeto com seu próprio histórico de confirmações (ou commits). No GitHub é possível visualizar os branches do repositório local ao executar a sequência: $ git branch * master $ git branch - - remote origin/HEAD -> origin/máster origin/master [JN1] REMOTE A opção --remote mostra a cópia do repositório local no repositório remoto do GitHub. BRANCH MASTER Todos os projetos possuem o branch Master por padrão e se considerarmos um projeto como uma árvore, ele seria o tronco, do qual se pode criar linhas independentes de desenvolvimento. Histórico de um repositório as linhas que representam as ramificações. Os círculos que representam confirmações (commits) individuais em cada branch. A seta simboliza o ponteiro que chamamos Head (cabeça), o qual representa a ramificação atualmente em uso. VERSÕES DE UM ARQUIVO EM UM PROJETO GIT A versão do diretório de trabalho corresponde àquele que está sendo usado para edição. A versão staged corresponde à versão alterada, mas que não foi incluída de forma definitiva no repositório. Trata-se, portanto, de uma versão transitória e que está aguardando o próximo commit para se tornar efetiva. As versões permanentes, ou seja, aquelas que receberam o comando commit.
PROJETO SCRUM
Em meados dos anos 1980, Hirotaka Takeuchi e Ikujiro Nonaka definiram uma estratégia flexível e abrangente de criação de um produto, na qual a equipe de desenvolvimento trabalhava como uma unidade para atingir um objetivo comum. Eles descreveram uma abordagem inovadora para o desenvolvimento de artefatos, a qual eles chamaram de "abordagem rugby". A partir dela, uma equipe tenta percorrer a distância como uma unidade, passando a bola para frente e para trás. 
Os pesquisadores japoneses propuseram que o desenvolvimento do produto não deveria ser como uma corrida de revezamento sequencial, mas análogo ao jogo de rúgbi, no qual a equipe trabalha junto, passando a bola para frente e para trás enquanto se move como uma unidade pelo campo. O conceito de rugby de um "Scrum" (momento em que um grupo de jogadores se forma para reiniciar o jogo) foi introduzido para descrever a proposta feita pelos pesquisadores.
Ken Schwaber e Jeff Sutherland desenvolveram o conceito Scrum e sua aplicabilidade no desenvolvimento de software em uma apresentação na conferência Programação Orientada a Objetos, Sistemas, Linguagens e Aplicações (OOPSLA) realizada em 1995, em Austin, Texas. Desde então, vários praticantes, especialistas e autores de Scrum continuaram a refinar seu conceito e sua estrutura. Nos últimos anos, o Scrum cresceu em popularidade e agora é a abordagem de desenvolvimento de projeto preferida para muitas organizações em todo o mundo (A GUIDE..., 2015).
A seguir veja uma síntese sobre o fluxo de um projeto Scrum.
VISÃO GERAL SCRUM.
1. CICLO SCRUM: o ciclo Scrum começa com a compreensão do caso que deve ser resolvido pelo projeto e passa, na etapa seguinte, para uma reunião das partes interessadas, durante a qual a visão do projeto é criada. 
2. PRODUCT OWNER (PO): o Product Owner então desenvolve um Backlog Priorizado do Produto, que contém uma lista priorizada de requisitos de negócios e projetos escritos na forma de Estórias de Usuário.
BACKLOG DO PRODUTO: Priorização das funcionalidades do produto desejadas pelo cliente.
3. PLANNING: cada Sprint começa com uma reunião de planejamento, durante a qual as Estórias de Usuário de alta prioridade são consideradas para inclusão nela. Uma Sprint geralmente dura entre uma e seis semanas e envolve a equipe do Scrum trabalhando para criar artefatos entregáveis ou incrementos de produtos.
BACKLOG DA SPRINT: Funcionalidade(s) atribuída(s) à Sprint.
SPRINT: 30 DIAS.
4. DAILY: ao longo da Sprint, são realizadas reuniões diárias curtas e com alto nível de foco, nas quais os membros da equipe discutem o progresso diário do projeto.DAILY: Scrum: reuniões diárias de 15 minutos. Os membros da equipe respondem às questões básicas:
1. O que você realizou desde a última Scrum?
2. Você está tendo alguma dificuldade?
3. O que você vai fazer antes da próxima reunião?
5. REVIEW: perto do final da Sprint, uma Reunião de Revisão da Sprint é realizada. Nela o Product Owner e as partes interessadas relevantes recebem uma demonstração dos entregáveis. O Product Owner aceita os entregáveis somente se eles atenderem aos critérios de aceitação predefinidos. 
6. RETROPESCTIVA: o ciclo da Sprint termina com uma Reunião de Retrospectiva da Sprint, na qual a equipe discute maneiras de melhorar os processos e o desempenho à medida que avançam para a Sprint subsequente.
PRODUTO: A nova funcionalidade é demonstrada no final da Sprint.
 1 CICLO SCRUM
O ciclo Scrum começa com a compreensão do caso que deve ser resolvido pelo projeto e passa, na etapa seguinte, para uma reunião das partes interessadas, durante a qual a visão do projeto é criada.
BACKLOG DO PRODUTO
Priorização das funcionalidades do produto desejadas pelo cliente.
2 PRODUCT OWNER
O Product Owner então desenvolve um Backlog Priorizado do Produto, que contém uma lista priorizada de requisitos de negócios e projetos escritos na forma de Estórias de Usuário.
3 PLANNING
Cada Sprint começa com uma reunião de planejamento, durante a qual as Estórias de Usuário de alta prioridade são consideradas para inclusão nela. Uma Sprint geralmente dura entre uma e seis semanas e envolve a equipe do Scrum trabalhando para criar artefatos entregáveis ou incrementos de produtos.
BACKLOG DA SPRINT
Funcionalidade(s) atribuída(s) à Sprint.
4 DAILY
Ao longo da Sprint, são realizadas reuniões diárias curtas e com alto nível de foco, nas quais os membros da equipe discutem o progresso diário do projeto.
 
DAILY
Scrum: reuniões diárias de 15 minutos.
Os membros da equipe respondem às questões básicas:
1. O que você realizou desde a última Scrum?
2. Você está tendo alguma dificuldade?
3. O que você vai fazer antes da próxima reunião?
5 REVIEW
Perto do final da Sprint, uma Reunião de Revisão da Sprint é realizada. Nela o Product Owner e as partes interessadas relevantes recebem uma demonstração dos entregáveis. O Product Owner aceita os entregáveis somente se eles atenderem aos critérios de aceitação predefinidos. 
RETROSPECTIVA
O ciclo da Sprint termina com uma Reunião de Retrospectiva da Sprint, na qual a equipe discute maneiras de melhorar os processos e o desempenho à medida que avançam para a Sprint subsequente.
INCREMENTO DE PRODUTO
A nova funcionalidade é demonstrada no final da Sprint.
O Framework Scrum representa o conjunto de princípios e de práticas do Scrum voltado a promover o desenvolvimento de um produto de software de forma ágil e unitária. O Product Owner, o Scrum Master e os eventos do Scrum são exemplos de partes integrantes desse Framework. A Parte II da obra de Fábio Cruz (2018) detalha todos os elementos do Scrum.
QUALIDADE DE PRODUTO
ISO 9000
A ISO da família 9000 é de grande importância para as atividades relacionadas ao desenvolvimento de softwares. Temos, por exemplo:
ISO 9126-1 de 2001
Trata das características, subcaracterísticas e métricas da qualidade de produto de software.
ISO 9126-2 de 2003
Trata das métricas externas e de controle de falhas.
ISO 9126-3 de 2003
O seu objetivo é verificar a quantidade de ocorrências de falhas e estimar o tempo de recuperação.
ISO 9126-4 de 2004
Faz as tratativas de User Experience, produtividade, eficácia e segurança.
Compreender a sua trajetória evolutiva é muito interessante para entender como as novas necessidades foram moldando a estrutura que utilizamos hoje em dia. No site da ABNT, é possível ir acessando os links para verificar essa evolução histórica. 
Observe a ISO 9000:2000 a seguir.
DEFEITO DE SOFTWARE
Sabe aquele programa que você baixou e que prometia resolver determinado problema, mas que sequer funcionou? E aquele lanche que na foto parecia ser muito bom, mas que não tinha sabor de nada? Ou, ainda, sabe aquele serviço que você contratou, mas que só foi perda de tempo e dinheiro? 
Certamente, um ou mais exemplos iguais a esses já aconteceram com a maioria de nós.
Vamos observar alguns tipos de ocorrências que degradam os serviços.
No exemplo a seguir, ao efetuar determinada operação, a tela de erros retornou.
Fonte: captura de tela de um software em desenvolvimento elaborada pelo autor.
FALHA DE SOFTWARE
No exemplo a seguir, as observações não foram carregadas. Ruim tanto do ponto de vista do usuário quanto do ponto de vista do desenvolvedor de software.
Fonte: captura de tela de um software em desenvolvimento elaborada pelo autor.
Mas como evitar que isso ocorra?
Existe uma área do conhecimento que trata somente dos aspectos relacionados à qualidade e que pode ser mobilizada para softwares, serviços, produtos, processos, etc.
QUALIDADE DE SOFTWARE
Mas, enfim, o que é qualidade? 
Qualidade diz respeito aos métodos, às ferramentas, às metodologias e aos processos os quais garantirão que determinada entrega seja feita dentro dos padrões de qualidade estabelecidos entre as partes.
Todo esse processo se inicia no levantamento de requisitos, quando o cliente passa para a equipe de desenvolvimento todas as suas necessidades.
REQUISITOS FUNCIONAIS
Refletem a visão do usuário quanto ao funcionamento de determinada função dentro do software.
REQUISITOS NÃO FUNCIONAIS
Refletem a visão do desenvolvedor. A partir deles são determinados tanto o funcionamento técnico das funcionalidades quanto os mecanismos e os desempenhos esperados.
Em todo o ciclo de vida do projeto, podem ser utilizadas as ferramentas de garantia da qualidade, ou seja, nos processos de desenvolvimento, teste, validações, correções, enfim, em qualquer parte que venha a compor um projeto de desenvolvimento. É importante lembrar também que essas metodologias de garantia da qualidade necessitam de parâmetros, de métricas, que podem variar conforme métodos, necessidades, recursos etc.
TERMOS
Vamos ver os termos comuns no contexto dos testes de software frequentemente confundidos.
Testes de software. Que expressão você usa quando um programa simplesmente trava ou não produz o resultado que se espera dele? Tudo o que acontece de incomum em um programa pode ser chamado de erro? Observe os conceitos: 
Erro: ocorre quando o resultado obtido em um processamento e o que se esperava dele não são coincidentes. Um erro também está associado a uma violação nas próprias especificações do programa. 
Por exemplo, um usuário não autorizado consegue acessar determinado módulo do programa (esse é o resultado obtido), sendo que seu nível de privilégio não deveria permitir que o fizesse (esse era o resultado esperado).
Defeito: trata-se de deficiência algorítmica que, se ativada, pode levar a uma falha. 
Por exemplo: observe o trecho que segue, escrito em pseudocódigo:
a igual a menos 1 ponto e vírgula. b igual a 0 ponto e vírgula. enquanto a menor que 0. faça b igual a b mais 1 ponto e vírgula. imprima (b) ponto e vírgula. imprima (a) ponto e vírgula.
fim enquanto ponto e vírgula. 
Em algum momento o valor da variável “a” deixará de ser menor que zero? Estamos diante de um defeito, mais precisamente de um laço infinito. Se o caso de teste escolhido for capaz de exercitar esse trecho do código, o defeito se manifestará e então teremos uma falha observável. O programa provavelmente será interrompido. 
Falha: é tida como um não funcionamento do programa, provavelmente provocada por um defeito. No entanto, uma falha também pode ser atribuída a uma queda na comunicação ou a um erro na leitura do disco, por exemplo. 
Erro (Error)
Trata-se da diferença detectada entre o resultado de uma operação e o resultado correto que se pretendia obter com ela.
Defeito (Defaut)
Trata-se de uma linha de código, bloco ou conjunto de dados incorretos que provocam um erro.
Falha (Failure)
Trata-se de um não funcionamento do software, possivelmente provocada por um defeito, embora possa haveroutras causas.
Engano (Mistake)
É a ação humana que produziu o defeito no código.
DESENVOLVIMENTO ORIENTADO A TESTES
E FERRAMENTAS CASE
TESTES DE UNIDADE
· Um teste é apenas uma classe Java simples.
· A classe testada geralmente aparece como uma variável de instância da classe Teste.
· Vários métodos de teste, anotados com @Test, usarão as funcionalidades da classe testada e então confrontarão os resultados esperados com os resultados obtidos.
Vamos ver como escrever um teste de unidade com o Junit?
Primeiro, precisamos de um exemplo de classe em teste, ou seja, uma classe implementando alguma funcionalidade que desejamos testar.
O exemplo a seguir é de uma classe calculadora, que retorna a soma entre dois valores inteiros:
Classe Calculator
class Calculator { 
  int add(int a, int b){ 
 return a+b; 
  }
}
Fonte: elaborado pelo autor.
A seguir a classe que testará a classe Calculator: 
Classe que testará Calculator
class CalculatorTest { 
  private Calculator calc = new Calculator(); 
  @Test 
  void testAdd() { 
 int x = 2; 
 int y = 1; 
 int result = calc.add(x, y); 
 Assertions.assertEquals(3, result); 
  } 
}
Fonte: elaborado pelo autor.
O funcionamento dessa classe inclui a inicialização de duas variáveis de entrada (x e y) e da chamada do método add, que desejamos testar com a entrada fornecida. O resultado da operação é armazenado em uma variável e, por fim, o resultado esperado é confrontado com o obtido (o valor 3, neste caso).
ANOTAÇÕES JUNIT
Vamos ver agora algumas anotações do JUnit úteis para a organização e para a execução dos procedimentos de teste em classes Java.
@Test
Usada para sinalizar que o método anotado é um método de teste.
@AfterAll
Usada para sinalizar que o método anotado deve ser executado após todos os testes na classe de teste atual.
@AfterEach
para sinalizar que o método anotado deve ser executado após cada método @Test, @RepeatedTest, @ParameterizedTest, @TestFactory e @TestTemplate na classe de teste atual.
@BeforeAll
Usada para sinalizar que o método anotado deve ser executado antes de todos os testes na classe de teste atual.
@BeforeEach
Usada para sinalizar que o método anotado deve ser executado antes de cada método @Test, @RepeatedTest, @ParameterizedTest, @TestFactory e @TestTemplate na classe de teste atual.
@RepeatTest
Usada para sinalizar que o método anotado é um método de modelo de teste que deve ser repetido um número específico de vezes com um nome de exibição configurável.
TIPOS DE
TESTES
Os testes de sistema e de usuário são executados nas etapas finais de seus respectivos níveis e são considerados de elevada importância na apuração consolidada de qualidade.
TESTES DE SISTEMA
O teste de sistema deve ser apresentado como uma etapa em que o sistema, já completamente integrado, passa pelo procedimento do teste.
Para que a equipe consiga chegar ao teste de sistema, todas as unidades e as integrações entre elas devem ter sido testadas previamente. Os erros encontrados devem ter sido também sanados.
Mesmo depois de testada cada unidade isoladamente e a comunicação entre as unidades, é necessário ainda testar o funcionamento do sistema de modo global, adotando o ponto de vista de quem usará o sistema.
O objetivo do teste de sistema é o de apurar se o programa é capaz de executar processos completos, como se estivesse em uso pleno.
TESTES DE USUÁRIO
Aplicado o teste de sistema, o produto final deve ser aceito pelo usuário. Como o nome sugere, esse teste é executado pelo usuário e não pela equipe de testadores ou desenvolvedores. 
Em relação ao planejamento e à execução, o teste de usuário se equipara ao teste de sistema, com a diferença de que ele será executado pelo usuário. Se considerarmos que o teste de sistema ainda é parte da verificação do produto, o teste de aceitação serve para sua validação.
O teste de usuário tem objetivo e metodologia de aplicação semelhantes ao teste de sistema, com a diferença de que ele é executado pelo usuário, como se estivesse operando-o em situação normal de uso. É aconselhada a elaboração de um roteiro de funções a serem testadas.
VISÃO DE UMA AUDITORIA DE SISTEMAS EM UMA EMPRESA DE DESENVOLVIMENTO DE APLICATIVOS PARA MOBILE
EQUIPES DE DESENVOLVIMENTO
· Front end e User Experience.
· Banco de dados.
· Desenvolvimento back end Android.
· Desenvolvimento back end IOS.
· Desenvolvimento back end Híbrido.
PROCESSOS DE INTEGRAÇÃO ENTRE AS EQUIPES
Para que sejam minimizados os erros e as falhas entre as equipes de desenvolvimento, existem processos bem definidos de coexistência entre as ilhas de produção de aplicativos mobile. 
ERROS DE PROCESSOS DE INTEGRAÇÃO ENTRE AS EQUIPES
Ultimamente vêm ocorrendo erros de integração de projetos entre a equipe de front end e a de banco de dados e desenvolvimento back end.
PROCESSO DE AUDITORIA
· Gerentes de projetos - se reuniram com a direção da empresa e estabeleceram que seria contratada uma empresa para fazer a auditoria dos processos de desenvolvimento.
· Auditores - passaram um tempo na empresa fazendo reuniões, análises documentais, entrevistas, observações, entre outras atividades. No dia a dia, os desenvolvedores notaram a mudança na rotina com a presença dos auditores.
· Desenvolvedores - no dia a dia, notaram a mudança na rotina com a presença dos auditores.
DEVOLUTIVA DA AUDITORIA
Após um tempo, os auditores marcaram uma reunião com gerentes de projetos e colaboradores. Nela o relatório foi disponibilizado para todos e, em seguida, os resultados foram apresentados.
MAS O QUE FAZER COM ESSAS DEVOLUTIVAS?
A auditoria aponta falhas, erros, melhorias e potencialidades dos processos. Com as devolutivas, os gerentes de projetos devem traçar planos para que cada apontamento feito pela equipe de auditoria receba a devida tratativa.
FERRAMENTAS DE MANUTENÇÃO
INDENTAÇÃO
Caro aluno, muito foi falado da classificação das ferramentas de manutenção e, dentre elas, pode-se destacar a indentação, que, quando bem feita, auxilia a equipe de desenvolvimento no processo de compreensão das partes que compõem o sistema.
Encontrar um código-fonte indentado e comentado pode ser um grande diferencial no momento da manutenção. Esse processo pode ser encontrado tanto na reengenharia de software quanto nos processos de engenharia reversa, para entender a estrutura das aplicações.
Existem algumas situações que nos permitem entender o correto apenas quando visualizamos a forma incorreta de se fazer. Dito isso, a seguir um trecho de código sem nenhuma indentação. Para facilitar o entendimento da função, acompanhe o que está sendo executado linha a linha.
A imagem mostra um captura de tela de um trecho de código sem indentação. 
Na Linha 134 há o código: function pesquisa cep(valor) { . Explicação: é criada a função chamada “pesquisacep”, na qual o usuário passará, via formulário web, o valor do CEP.
Linha 135: há o código: var cep igual valor.replace(/\D/g, ‘ ‘); . Explicação: a variável cep recebe o valor do CEP digitado.
Linha 136: há o código: if (cep !== “”) { . Explicação: faz a condição para verificar se o campo do CEP digitado pelo usuário não está vazio.
Linha 137: há o código: var validacep = /^[0-9]{8}$/; . Explicação: faz a validação do CEP para que só sejam aceitos números.
Linha 138: há o código: if(validacep.test(cep)) { . Explicação: faz a validação do cep por meio de uma consulta a uma base pública (viacep).
Linha 139: há o código: document.getElementById (‘endereço’).value = “...” ; . Explicação: carrega o endereço pelo CEP digitado.
Linha 140: há o código: document.getElementById (‘bairro’).value = “...” ; . Explicação: carrega o bairro pelo CEP digitado.
Linha 141: há o código: document.getElementById (‘cidade’).value = “...” ; . Explicação: carrega a cidade pelo CEP digitado.
Linha 142: há o código: document.getElementById (‘esado’).value = “...” ; . Explicação: carrega o estado pelo CEP digitado.
Linha 143: há o código: var script = document.createElement(‘script’); . Explicação: cria a variável script 
Linha 144: há o código: script.src =‘//viacep.com.br/ws’+ cep + ‘json/?call-back=meu_call-back’;. Explicação: direciona o documento de consulta (script) para a consulta a base de CEPs (viacep).
Linha 145: há o código: document.body.appendchild; . Explicação: carrega as informações do documento.
Independentemente se você conhece a linguagem, percebeu como fica confuso entender a estrutura da aplicação?    
A título de análise comparativa, observe a seguir o mesmo trecho de código, só que dessa vez com as devidas indentações.
CONTROLES GERAIS DE AUDITORIA DE SISTEMAS
EM UMA LOJA DE DEPARTAMENTO
Os controles gerais tratam das estruturas internas das organizações, as políticas administrativas operacionalizadas e os procedimentos utilizados em atividades operacionais nas empresas. Ou seja, as políticas internas da empresa, que são um guia para o desenvolvimento do sistema.
COMO ISSO FUNCIONA NA PRÁTICA
Exemplo:
Uma loja de departamento necessita de um software para gerenciar as vendas realizadas. Para isso, a empresa que vai desenvolver o software precisa entender as suas políticas internas, pois elas, de algum modo, interferem na forma de funcionamento dos sistemas ou em alguma funcionalidade específica.
Vamos analisar apenas uma funcionalidade do sistema em questão: a alteração do valor dos produtos. 
Para elas existem duas possibilidades:
1
O gerente de loja tem autonomia de alterar os valores dos produtos, dessa forma o sistema deve ter uma funcionalidade para permitir essa alteração.
2
A alteração de valores é feita pela administração, logo o gerente de lojas não tem essa autonomia. Dessa forma, no sistema não haverá a funcionalidade de alteração do valor dos produtos.
Percebeu como a política da empresa guia como a funcionalidade deve ser desenvolvida dentro do sistema?  
DE QUE FORMA A AUDITORIA PODE AGIR QUANTO AOS CONTROLES GERAIS DOS SISTEMAS?
De maneira geral, a auditoria deve analisar se a construção do sistema está alinhada aos controles gerais e se atende aos requisitos. Isso é feito por meio de análise documental, análise de script, testes de uso, entre outros recursos. 
Vamos supor que o gerente de loja não tenha autonomia para alterar o valor dos produtos.
A auditoria deve efetuar uma análise e gerar relatórios nos quais seja possível ver se, de fato, a funcionalidade de alteração de valor de produto não está acessível. Ainda é possível gerar relatórios que apontem a origem das alterações de valores, a fim de gerar insights que comprovem que o sistema está funcionando de acordo com o esperado.
QUAL CONTRIBUIÇÃO A AUDITORIA PODE GERAR QUANTO À ANÁLISE DOS CONTROLES GERAIS DOS SISTEMAS?
O gerente da loja não tem autonomia para alterar os valores dos produtos, porém, ao utilizar o sistema, percebeu que consegue alterar o valor dos produtos via url. Como o gerente é uma pessoa mal intencionada, ele altera os valores dos produtos, adicionando determinada porcentagem, depois volta ao valor normal e, no fim do dia, pega a diferença de caixa para si.
Fase do desenvolvimento do software
Teste de funcionalidade
Teste de interface 
Teste de desempenho
Teste de carga (estresse)
Teste de usabilidade
Teste de volume 
Teste de segurança
O que testar
Tipo de teste 
	2		
					Critérios
Quando testar
	
1																			
Níveis de teste
Teste de unidade 
Teste de integração
Teste de sistema
Teste de aceitação 
Teste de regressão
Teste funcional
Teste estrutural 
Particionamento de equivalência
Análise de valores-limite
Baseado em casos de uso
 Técnica de testeComo testar
Teste de caminhos
Teste de comandos 
Teste de ramos
Teste de condições 
Teste de cond múltiplas
3
 TDD 
	
WORKBENCH
TESTE DE WEBAPP
ATIVIDADES:
1Tomando como refere?ncia as especificidades da realização de um teste de unidade, julgue as afirmativas a seguir em (V) Verdadeiras ou (F) Falsas.
 
(  ) Pela localização da sua aplicação, este teste é conhecido como intra-método.
(  ) Este procedimento deve se concentrar em testar as funcionalidades do método.
(  ) Este teste consiste em chamadas para as rotinas da unidade com diferentes parâmetros.
Assinale a alternativa que apresenta a seque?ncia CORRETA.
Alternativas:
a)
F - V - F.
b)
F - V - V.
c)
V - V - F.
d)
V - F - V.
e)
V - V - V.
Alternativa assinalada
2)
Considerando os conceitos e as aplicações de testes de sistema, avalie as afirmativas as seguir:
 
I. Os testes de sistema devem se concentrar em testar as interações entre os componentes e os objetos que compõem um sistema.
II. Uma das justificativas para a aplicação de um teste de sistema é que alguns componentes se tornam evidentes apenas quando os componentes são unidos.
III. Um teste de sistema é executado pela checagem de métodos aos pares, ou seja, a interação entre dois métodos escolhidos ao acaso.
Considerando o contexto apresentado, assinale a alternativa correta.
Alternativas:
a)
Apenas as afirmativas I e III são corretas.
b)
Apenas as afirmativas I e II são corretas.
Alternativa assinalada
c)
Apenas a afirmativa I é correta.
d)
Apenas a afirmativa II é correta.
e)
As afirmativas I, II e III são corretas.
3)
Considerando as características de operacionalização do TDD, complete as lacunas da sentença a seguir.
 
Durante o TDD, o co?digo e? desenvolvido em incrementos __________ e nenhum co?digo e? escrito enquanto na?o houver um ________ para experimenta?-lo. Cada iterac?a?o resulta em um ou mais novos testes, os quais sa?o acrescentados a um conjunto de testes de ___________ que e? executado a cada mudanc?a. Isso e? feito para garantir que o novo co?digo na?o tenha gerado efeitos colaterais que causem erros no co?digo anterior.
Assinale a alternativa que completa as lacunas corretamente.
Alternativas:
a)
grandes - desenvolvedor - regressão.
b)
pequenos - teste - regressão.
c)
médios - teste - refatoração.
d)
grandes - cliente - regressão.
Alternativa assinalada
e)
pequenos - teste - refatoração.
4)
Considerando características de testes automatizados e da ferramenta de teste JUnit, avalie as afirmativas a seguir:
 
I. O JUnit é uma ferramenta que realiza testes unitários, com recursos para a aplicação de Desenvolvimento Orientado a Testes.
II. Apesar de ser conhecida como uma ferramenta de automação de teste, o JUnit não é capaz de validar a saída do teste.
III. Os testes de unidade são automatizados em um formato em que de classes são criadas para testar outras classes.
Considerando o contexto apresentado, assinale a alternativa correta.
Alternativas:
a)
Apenas as afirmativas II e III são corretas.
b)
Apenas as afirmativas I e III são corretas.
Alternativa assinalada
c)
Apenas a afirmativa III é correta.
d)
As afirmativas I, II e III são corretas.
e)
Apenas a afirmativa I é correta.
5)
No desenvolvimento guiado por teste (TDD), requisitos para um componente de software servem de base para a criac?a?o de uma se?rie de casos de teste que exercitam a interface e tentam encontrar erros nas estruturas de dados e na funcionalidade fornecida pelo componente.
 
Fonte: PRESSMAN, Roger; MAXIM, Bruce, Engenharia de Software: uma abordagem profissional. 8. ed. Porto Alegre: AMGH, 2016.
 
Com base no tipo de teste viável para a aplicação do TDD, avalie as seguintes asserc?o?es e a relac?a?o proposta entre elas.
 
I. Embora seja a forma mais usual, a efetivação da prática do TDD não está relacionada, necessariamente, apenas aos testes de unidade
 
PORQUE
 
II. É possível que o TDD seja aplicado também em procedimentos que testem o sistema segundo o ponto de vista do usuário, numa averiguação direta do seu atendimento aos requisitos do cliente.
A respeito dessas asserc?o?es, assinale a alternativa correta.
Alternativas:
a)
As asserc?o?es I e II sa?o proposic?o?es verdadeiras e a II e? uma justificativa da I.
b)
As asserc?o?es I e II sa?o proposic?o?es verdadeiras, mas a II na?o e? uma justificativa da I.
c)
A asserc?a?o I e? uma proposic?a?o verdadeira, e a II e? uma proposic?a?o falsa.
Alternativa assinalada
d)
A asserc?a?o I e? uma proposic?a?o falsa, e a II e? uma proposic?a?o verdadeira.
e)
As asserc?o?es I e II sa?o proposic?o?es falsas.
Framework
Um framework em desenvolvimentode software, é uma abstração que une códigos comuns entre vários projetos de software provendo uma funcionalidade genérica. Um framework pode atingir uma funcionalidade específica, por configuração, durante a programação de uma aplicação. Ao contrário das bibliotecas, é o framework quem dita o fluxo de controle da aplicação, chamado de Inversão de Controle.[1]
Conceito
Um framework ou arcabouço conceitual, é um conjunto de conceitos usado para resolver um problema de um domínio específico. Framework conceitual não se trata de um software executável, mas sim de um modelo de dados para um domínio. Framework de software compreende de um conjunto de classes implementadas em uma linguagem de programação específica, usadas para auxiliar o desenvolvimento de software.
O framework atua onde há funcionalidades em comum a várias aplicações, porém para isso as aplicações devem ter algo razoavelmente grande em comum para que o mesmo possa ser utilizado em várias aplicações.
Padrões de projeto de software não se confundem com frameworks, pois padrões possuem um nível maior de abstração. Um framework inclui código, diferentemente de um padrão de projeto. Um framework pode ser modelado com vários padrões de projeto, e sempre possuem um domínio de uma aplicação particular, algo que não ocorre nos padrões de projeto de software.
Framework é um conjunto de classes que colaboram para realizar uma responsabilidade para um domínio de um subsistema da aplicação.
— Fayad e Schmidt[1]
Frameworks possuem vantagens, tais como: maior facilidade para a detecção de erros, por serem peças mais concisas de software; concentração na abstração de soluções do problema que estamos tratando; eficiência na resolução dos problemas e otimização de recursos.
Partes
Frozenspots são as partes fixas de um framework, também conhecidos como hook points. São serviços já implementados pelo framework. Normalmente realizam chamadas indiretas aos hotspots.
Hotspots são as partes flexíveis de um framework. São pontos extensíveis, necessitam de complementação por funcionalidades/serviços que devem ser implementados. Hotspots são partes nas quais os programadores que usam o framework adicionam o seu código para especificar uma funcionalidade de sua aplicação. São invocados pelo framework, ou seja, classes (implementadas pelo programador da aplicação) recebem mensagens de uma classe do framework (frozenspot). Isso geralmente é implementado através de herança e de métodos abstratos.
Tipos
Frameworks verticais são confeccionados através da experiência obtida em um determinado contexto específico. Esses são mais comumente chamados de frameworks especialistas. Tentam resolver problemas de um domínio e são usados em vários softwares do mesmo domínio. Exemplos: framework financeiro, recursos humanos.
Após alguns projetos em um domínio específico, serão percebidos pontos semelhantes entre estes projetos; E é com base nesses pontos que será construído o framework vertical (especialista).
Frameworks horizontais não dependem do domínio da aplicação e podem ser usados em diferentes domínios. Exemplos: Interfaces gráficas, persistência, transação.
Orientação a objetos
Especificamente em orientação a objetos, framework é um conjunto de classes com objetivo de reutilização de arquitetura de software, provendo um guia para uma solução em um domínio específico de software. Framework se diferencia de uma simples biblioteca, pois esta se concentra apenas em oferecer implementação de funcionalidades, sem definir a reutilização de uma solução de arquitetura.
Muitos engenheiros acreditam que a arquitetura é determinada pelos requisitos e por isso esperam que a fase de engenharia de requisitos esteja finalizada para então iniciar sua. Porém, apenas uma fração dos requisitos específicos do sistema têm influência na arquitetura. A identificação dos requisitos que são significantes para a arquitetura pode ser respondida através de um framework conceitual desenvolvido especialmente para um domínio específico, uma vez que esta resposta é muito dependente do domínio. Avançar para a fase de projeto ou mesmo iniciar a implementação do sistema não quer dizer que a definição da arquitetura esteja finalizada. Isto significa que o detalhamento obtido até então já é suficiente para prosseguir com o projeto de uma parte do sistema.
Administração de empresas
Em administração, um framework é uma estrutura conceitual básica que permite o manuseio homogêneo de diferentes objetos de negócio. Serve para incrementar a disciplina de gestão e predefinir entregáveis comuns para cada objeto de negócio.
Pode ser visto também como uma tática bem definida para manipular com destreza ambientes organizacionais complexos. Um framework deve prover sugestões de solução para uma família de problemas semelhantes.
Exemplos de frameworks para gestão: ISO 9000, ISO 14000, OHSAS 18000, ITIL, COBIT, CMM, HACCP, SCRUM.
Avaliação 
Questão 1
Completa as lacunas:
No final dos anos 1960, o termo Engenharia de Software surgiu, mais precisamente em uma conferência em que se discutir a " ______ do software".
Essa _______ , que ficou conhecida como " _______ do software", teve origem na evolução tecnológica empregada na fabricação do hardware de computador, baseado em circuitos integrados.
O termo, palavra, ou frase que completa as lacunas é:
A) divisão
B) crise
C) transformação
D) fusão
E) evolução
Questão 2
Com base nas estórias do cliente, o _____________ cria uma lista de funcionalidades do sistema chamada Product Backlog. Quando a equipe se reúne para o ciclo de desenvolvimento, conhecido como ___________, o Product Owner cria a lista de funcionalidades que serão desenvolvidas naquele ciclo. Essa lista é derivada da primeira, leva o nome de Sprint Backlog e é criada durante a reunião chamada Sprint Planning Meeting. O Sprint dura poucas semanas e, enquanto acontece, nenhuma outra funcionalidade é enviada à equipe.
Assinale a alternativa que contém as palavras que completam as lacunas corretamente e na ordem:
A) Scrum Team; Product Backlog.
B) Product Sprint; Sprint.
C) Scrum Master; Sprint.
D) Scrum Master; Product Backlog.
E) Product Owner; Sprint.
Questão 3
Em relação às técnicas de teste, existem duas grandes famílias, os testes estruturais (teste de caixa branca) e os testes funcionais (testes de caixa pretas). Sobre essas técnicas, analise as afirmativas a seguir:
I- Os testes funcionais são executados com conhecimento do código implementado, ou seja, que testam a estrutura do programa em si.
II- Os testes estruturais são executados sobre as entradas e saídas do programa sem que se tenha necessariamente conhecimento do seu código-fonte.
III- Os testes funcionais podem ser utilizados para encontrar erros de comportamento e desempenho;
Agora, assinale a alternativa que apresenta a resposta CORRETA: 
A) Apenas as afirmativas I e II estão corretas;
B) Apenas as afirmativas I e III estão corretas;
C) As afirmativas I, II e III estão corretas.
D) Apenas a afirmativa I está correta;
E) Apenas a afirmativa III está correta;
Questão 4
Garantir que o produto de software está sendo construído com um bom nível de qualidade para a gerente de projetos KOYAMA é uma meta constante.
Embora você possa não encontrar uma definição universal e definitiva para a qualidade aplicada a um software, vários fatores são utilizados como medidas e indicadores da qualidade do produto.
Analise as asserções:
I. Entende-se por confiabilidade a capacidade do software de se manter em funcionamento e com o desempenho esperado/estabelecido.
ENQUANTO QUE
II. a Interoperabilidade trata-se da "capacidade de diversos sistemas e organizações trabalharem em conjunto de modo a garantir que pessoas, organizações e sistemas computacionais troquem informações de maneira eficaz e eficiente"
Escolha a alternativa correta:
A) As duas asserções são verdadeiras.
B) A primeira asserção é verdadeira e a segunda é falsa.
C) As duas asserções são verdadeiras e a segunda justifica a primeira.
D) As duas asserções são falsas.
E) A primeira asserção é falsa ea segunda é verdadeira.
Questão 5
Sobre o gerenciamento de configuração, analise as afirmativas a seguir:
I- O item de configuração é um elemento unitário ou um grupo de elementos para efeito de controle de versão.
II- O gerenciamento de configuração de software é um conjunto de atividades que foi desenvolvido para administrar as mudanças em todo o ciclo de vida do software.
III- O gerenciamento de configuração nem sempre se faz necessário, pois muitas vezes o projeto possui uma versão única e não ocorrem mudanças;
Agora, assinale a alternativa que apresenta a resposta CORRETA: 
A) Apenas a afirmativa II está correta;
B) As afirmativas I, II e III estão corretas.
C) Apenas as afirmativas I e III estão corretas;
D) Apenas a afirmativa I está correta;
E) Apenas as afirmativas I e II estão corretas;
Questão 6
Fases são um conjunto de atividades afins e com objetivos bem definidos são realizados em uma fase do processo. O modelo cascata de desenvolvimento, por exemplo, apresenta fases bem definidas, quais sejam a fase dos requisitos, a fase do projeto, da programação e assim por diante (WAZLAWICK, 2013).
Assinale a alternativa que contempla as fases do modelo Cascata:
A) Requisitos, projeto, implementação, teste e manutenção.
B) Requisitos, codificação, implementação, validação e manutenção.
C) Requisitos, projeto, codificação, validação e feedback.
D) Entrevistas, projeto, codificação e verificação de conformidade.
E) Entrevistas, divisão de atividades, implementação e verificação de conformidade.
Questão 7
Qual é a técnica ou filosofia de programação que incorpora o teste ao processo de produção de código. Assinale a alternativa correta:
A) Testes de caixa preta
B) Teste de validação
C) Desenvolvimento Orientado a Testes (TDD)
D) Teste de aplicações orientados a objeto
E) Testes de caixa branca
Questão 8
Relacione o resultado do caso de teste com a sua respectiva descrição:
I- Passou;
II- Falhou;
III- Bloqueado;
1- o teste não pode ser executado, pois o seu ambiente não pode ser configurado.
2- nem todos os passos foram executados com sucesso para uma ou mais entradas;
3- todos os passos do caso de teste foram executados com sucesso para todas as entradas;
A seguir, assinale a alternativa que contém a sequência correta da associação:
A) I-1; II-2; III-3;
B) I-2; II-1; III-3;
C) I-3; II-2; III-1;
D) I-3; II-1; III-2;
E) I-2; II-3; III-1;
Questão 9
Todos os esforços para o desenvolvimento de um software devem estar baseados em metodologias e ferramentas adequadas para produzir um aplicativo de ótima qualidade. Sendo assim, entende-se que uma das fases do ciclo de vida de um software é a manutenção.
Em relação à manutenção de software, assinale a afirmação verdadeira:
A) A manutenção deve ser evitada a todo custo, já que os produtos são entregues sempre em seu estado final.
B) A manutenção de software é definida como modificações em um produto de software após a entrega ao cliente.
C) A manutenção aplicada para que o software passe por melhorias se chama manutenção corretiva.
D) Não se pode considerar a manutenção parte do ciclo de vida de um software, já que ela é aplicada em todas as fases, de forma independente.
E) A necessidade de manutenção em um software revela que ele não foi bem construído.
Questão 10
Sobre a abordagem através do computador, analise as afirmativas a seguir:
I- Esta abordagem não deixa evidências documentais através dos controles dos programas.
II- Se for realizada incorretamente pode levar a grandes perdas;
III- Esta abordagem é baseada em confrontar documentos fontes com os resultados esperados;
Agora, assinale a alternativa que apresenta a resposta CORRETA: 
A) Apenas as afirmativas I e III estão corretas;
B) Apenas a afirmativa I está correta;
C) As afirmativas I, II e III estão corretas.
D) Apenas a afirmativa II está correta;
E) Apenas as afirmativas I e II estão corretas;
Questão 11
A concepção inicial do SCRUM se deu na indústria automobilística em meados da década de 1980 e que tem o Sprint como o conceito mais importante. Com nomes diferentes, mas com ideias semelhantes, suas práticas se aproximam conceitualmente das práticas do XP e tornam essa metodologia bastante aceita entre as empresas de desenvolvimento de software.
Assinale a alternativa com o documento que contém as funcionalidades a serem implementadas no projeto:
A) Id Scrum.
B) Sprint Functions.
C) Product Functions.
D) Product Backlog.
E) Sprint Meetins.
Questão 12
O modelo Cascata é um modelo dito prescritivo, pois contêm descrições de como as atividades são realizadas.
Estas atividades são organizadas conforme as etapas do ciclo de vida do modelo, e as etapas possuem uma ordem determinada.
1- Teste.
2- Projeto.
3- Requisitos.
4- Manutenção.
5- Implementação.
Assinale a alternativa que compreende à ordem correta das etapas no modelo Cascata:
A) 3; 2; 1; 4; 5.
B) 4; 2; 1; 5; 3. 
C) 5; 2; 1; 3; 4.
D) 3; 2; 5;1; 4.
E) 4; 2; 3; 1; 5.
Questão 13
Sobre o teste de unidade, analise as afirmativas a seguir:
I- O teste de unidade focaliza o esforço de verificação na menor unidade de projeto do software, componente ou módulo de software.
II- O teste de unidade focaliza em ações visíveis ao usuário e saídas do sistema reconhecíveis pelo usuário;
III- Normalmente o teste de unidade é executado pelo próprio desenvolvedor;
Agora, assinale a alternativa que apresenta a resposta CORRETA: 
A) Apenas a afirmativa II está correta;
B) Apenas as afirmativas I e II estão corretas;
C) Apenas a afirmativa I está correta;
D) As afirmativas I, II e III estão corretas.
E) Apenas as afirmativas I e III estão corretas;
Questão 14
Antes da aplicação de uma entrevista há o planejamento: seus objetivos devem ser fixados, seu local e roteiro definidos e os entrevistados criteriosamente escolhidos. A interação entre entrevistado (especialista do conhecimento) e entrevistador (engenheiro de requisitos) deve buscar revelar conceitos, objetos e a organização do domínio do problema, além de buscar soluções ou projeções de soluções que comporão o domínio da solução (SCHACH, 2008).
Assinale a alternativa que apresenta a fase no ciclo de vida do software em que ocorre a entrevista:
A) Validação de Requisitos.
B) Avaliação de Requisitos.
C) Análise de Requisitos.
D) Levantamento de Requisitos.
E) Especificação de Requisitos.
Questão 15
A empresa KURIKI Software está adotando um determinado modelo de processo para a gestão do Desenvolvimento de software. Com base neste novo modelo, o gerente OTAWA garante a melhoria da qualidade do software, tanto em funcionalidades aderentes aos negócios quanto em qualidade dos requisitos não funcionais.
A maioria dos modelos permitem o incremento da qualidade, como previsto na engenharia de software.
Escolha a alternativa que adota um processo iterativo denominado sprint, com entregas incrementais do software:
A) SCRUM.
B) DSDM.
C) Crystal.
D) eXtreme Programming.
E) FDD.
Questão 16
O ____________ é um modelo de referência voltado às empresas brasileiras, criado no ano de 2003 pela SOFTEX, em parceria com o Governo Federal e pesquisadores.
Agora, assinale a alternativa que completa corretamente as lacunas:
A) SPICE
B) MPS.BR
C) ISO 25010:2011
D) ISO 9001
E) CMMI
image28.png
image4.jpeg
image5.png
image6.png
image7.png
image8.png
image9.wmf
image1.png
image10.png
image11.jpeg
image2.png
image12.png
image13.png
image14.png
image15.png
image16.png
image17.png
image18.png
image19.png
image3.png
image20.png
image21.png
image22.png
image23.png
image24.png
image25.png
image26.png
image27.png