Aula 01 (2)

Questões Comentadas de TI para o ICMS-PR

Exercícios comentados Prof Victor Dalton – Aula 01

Prof. Victor Dalton

www.estrategiaconcursos.com.br 1 de 48

AULA 01: Engenharia de Software

SUMÁRIO PÁGINA

Introdução 1

Cronograma 1

Exercícios 2

Considerações Finais 48

INTRODUÇÃO

Que bom encontrá-los novamente!

Isto significa que você viu a minha aula demonstrativa e julgou a minha

proposta de aula condizente com seus objetivos de estudos. Espero que nós possamos fazer com que seu esforço valha a pena!

Esta primeira aula abrange Engenharia de Software, um assunto

relativamente teórico e, creio eu, um bom conteúdo inicial para a aproximação

com a TI, especialmente se você não for do ramo.

Espero que você tenha lido os referenciais teóricos que indiquei. Uma aula

de exercícios, por mais abrangente que ela tente ser, requer cooperação do

aluno no sentido de buscar o máximo de familiarização com o conteúdo a ser

cobrado. Será o nosso trabalho em equipe que levará você a melhores

resultados na prova que se aproxima! Além disso, ainda mais quando tratamos

de assuntos novos, ler mais de uma vez sempre nos ajuda a memorizar mais. Se

você tiver tempo, leia novamente os referenciais teóricos após os exercícios,

pois esta tarefa auxiliará ainda mais a assimilação do conteúdo. Reforço essa

releitura, em especial sobre Engenharia de Software, em que a UEL mostrou ser

bem receptiva às ideias do nosso autor referência em ES.

Sem mais delongas, vamos começar? Mas, antes, acompanhemos o

cronograma.

CRONOGRAMA

1ª aula (21 de setembro): Gerência de Requisitos de Software:

Conceitos de Requisitos. Requisitos Funcionais e não Funcionais.

Engenharia de requisitos: conceitos básicos. Técnicas de elicitação de

requisitos. Gerenciamento de requisitos. Especificação de requisitos.

Técnicas de validação de requisitos. Gerência de configuração e



Prof. Victor Dalton


mudança: Conceitos de Gerência de Configuração e Mudança de

Software. Solicitações de Mudança. Testes e Avaliação de Qualidade de

Software: Conceitos. Documentos de Teste. Engenharia de Software:

Ciclo de vida do software. Metodologias de desenvolvimento de

software. Análise por pontos de função.

2ª aula (05 de outubro): Gestão e Governança de TI: Planejamento

Estratégico. Alinhamento entre estratégias de tecnologia da informação e de

negócio: conceitos e técnicas. Gerência de Projetos: Conceitos. Processos do

PMBOK. Planejamento e controle de métricas de projeto. Planejamento e

avaliação de iterações. Fundamentos de CMMI (versão 1.2) e MPS-Br. Gestão de

Processos de Negócio: Modelagem de processos. Técnicas de análise e

modelagem de processo. BPM – Business Process Modeling. Workflow e

Gerenciamento Eletrônico de Conteúdo.

3ª aula (12 de outubro): Programação de Sistemas: Lógica de

Programação. Conceitos de Programação orientada a objetos e para web.

Arquitetura de Software: Conceitos. Arquitetura Orientada a Serviço (SOA).

Portais corporativos e colaborativos. Web Services. Segurança da informação:

Conceitos básicos. Plano de continuidade de negócio. Noções sobre Criptografia,

Assinatura Digital e Autenticação. Certificação Digital. Auditoria, vulnerabilidade

e conformidade. Noções sobre norma ISO 27001 e ISO 27002. Redes: Conceito

de rede. Arquitetura de Rede. Noções de administração de redes. Conceitos de

Virtualização.

4ª aula (16 de outubro): Gerência de Serviços de TI: Fundamentos da

ITIL® (Versão 3). Fundamentos de COBIT (Versão 5). Service desk.

Conhecimentos sobre norma ISO/IEC 20000. Banco de Dados: Conceitos.

Modelagem de Dados Relacional. Modelagem de Dados Multidimensional.

Segurança aplicada a Bancos de Dados. Conceitos e estratégias de implantação

de Data Warehouse, OLAP, Data Mining, ETL e Business Intelligence.

EXERCÍCIOS

1ª Questão) (ESAF – Analista de Finanças e Controle –

Desenvolvimento de Sistemas da Informação - 2008) A Engenharia de

Software é uma disciplina da engenharia que se ocupa de todos os aspectos da

produção de software, desde os estágios iniciais de especificação do sistema até

a manutenção do mesmo. A Engenharia de Software adota métodos de

engenharia de software que

a) são um conjunto de atividades, cuja meta é o desenvolvimento ou a

evolução do software.

b) são uma representação simplificada de um processo de software,

apresentada a partir de uma perspectiva específica.



Prof. Victor Dalton


c) são abordagens estruturadas para o desenvolvimento de software, que

incluem modelos de sistemas, notações, regras, recomendações de projetos e

diretrizes de processos.

d) se ocupam da teoria e dos fundamentos de desenvolvimento de

software.

e) se ocupam de todos os aspectos relacionados ao desenvolvimento de

sistemas com base em computadores, incluindo hardware, software e

engenharia de processos.

Nada como começar pela definição!

Engenharia de software é uma área da computação voltada à especificação,

desenvolvimento e manutenção de sistemas de software, com aplicação de

tecnologias e práticas de gerência de projetos e outras disciplinas, visando

organização, produtividade e qualidade.

Os fundamentos científicos para a engenharia de software envolvem o uso

de modelos abstratos e precisos que permitem ao engenheiro especificar,

projetar, implementar e manter sistemas de software, avaliando e garantindo

suas qualidades. Além disso, a engenharia de software adota métodos de

engenharia de software que são abordagens estruturadas para o

desenvolvimento de software, que incluem modelos de sistemas, notações,

regras, recomendações de projetos e diretrizes de processos.

Nossa resposta certa é a letra c).


Desenvolvimento de Sistemas da Informação - 2012) A escolha de um

modelo é fortemente dependente das características do projeto. Os principais

modelos de ciclo de vida podem ser agrupados em três categorias principais:

a) sequenciais, cascata e evolutivos.

b) sequenciais, incrementais e ágeis.

c) sequenciais, incrementais e evolutivos.

d) sequenciais, ágeis e cascata.

e) cascata, ágeis e evolutivos.

Modelos de processos de software! O começo da Engenharia de Software.

Estas classificações variam muito entre autores. Entretanto, esta é a mais

recente cobrada em concursos, e muito próxima da adotada por sua fonte

recomendada para estudos. Vejamos:

Modelos sequenciais: são os modelos “à moda antiga”, como o modelo em

cascata e o modelo em V. Nestes modelos, uma fase só começa após o término

da outra. É um modelo meio ultrapassado de desenvolver software.



Prof. Victor Dalton


Modelo em Cascata

Modelo em V

Modelos incrementais: onde se enquadram o próprio modelo incremental e

o RAD (Rapid Application Development). Partem do princípio que a cada ciclo

uma versão operacional do sistema será produzida e entregue ao cliente para

uso ou avaliação detalhada.

Modelo Incremental



Prof. Victor Dalton


RAD

Modelos evolutivos – É uma forma de desenvolvimento na qual o software é

desenvolvido em ciclos, e a cada ciclo novas funcionalidades são incrementadas

ao sistema. Enquadram-se aqui o modelo espiral e a prototipação.

Modelo em espiral

Prototipação



Prof. Victor Dalton


Observe que “interessante”: na definição de modelos incrementais falamos

em ciclo, e na definição de modelos evolutivos falamos em incrementar

funcionalidades. E aí?

Bem, Pressmann diferencia o incremental do evolutivo afirmando que o

incremental seria “o modelo sequencial aplicado de maneira iterativa”, enquanto

o evolutivo é voltado para “acomodar um produto que evolui com o tempo”.

Pode ser que isso não lhe diga muita coisa, mas a grande verdade é que você

está aqui para acertar questões na prova, e não pra tirar um diploma de Doutor

em Engenharia de Software. Não é verdade? E o Pressmann é um autor de

renome, não sendo incomum suas definições aparecerem Ipsis Literis em

questões de concursos. Na hora da prova, dance conforme a música. Você vai

me ouvir falar isso mais de uma vez nessa apostila.

Resposta certa, alternativa c).

3ª Questão) (ESAF – Analista de Planejamento e Orçamento –

Tecnologia da Informação - 2010) As atividades do modelo espiral de

Engenharia de Software são:

a) Planejamento, Análise dos Componentes, Análise de Hierarquia e

Avaliação feita pelo cliente.

b) Planejamento, Análise dos Riscos, Engenharia e Avaliação feita pelo

cliente.

c) Projeto, Análise dos Benefícios, Engenharia e Avaliação feita pelo gestor.

d) Planejamento, Eliminação dos Riscos, Análise de Contingência e

Avaliação feita pelo cliente.

e) Planejamento, Projeto, Análise dos Riscos e Engenharia.

Se você prestou bem atenção na figura do modelo em espiral, na página

anterior, vai ficar em dúvida para responder esta questão. Já falei antes e falo

novamente, existe o que os autores consagrados pregam e existe o que a sua

banca quer ouvir, que pode vir desses autores OU não. Entretanto, um senso

comum entre os autores sobre o modelo espiral é o reconhecimento explícito do

risco, e a entrega para o cliente validar, aceitar, verificar... etc. E, pessoal, não é

brincadeira: se você sair pesquisando no Google, vai achar umas 10 espirais

diferentes, sem exagero! A própria espiral do Pressmann (reconhecidamente, o

grande autor em Engenharia de Software), que é dividida em Planejamento,

Modelagem, Construção, Implantação e Comunicação, não lhe habilitaria a

responder esta questão.

“Ah, Victor e por que você não nos passa a espiral padrão, aquela que as

bancas sempre cobram?”

Porque se eu ou alguém lhe prometer essa espiral estará mentindo pra

você. Ainda mais a UEL, banca com poucas provas de TI cuja questão exata

sobre esse assunto não encontrei em provas anteriores. Logo, meu objetivo é

lhe preparar da melhor forma para o que pode vir pela frente.



Prof. Victor Dalton


Pesquisando na internet, achei um autor que afirma que o modelo em

espiral possui as seguintes etapas: Comunicação com o cliente, planejamento,

análise de riscos, engenharia, construção e liberação, e avaliação com o cliente.

Foi o conceito mais próximo da alternativa correta da ESAF, a letra b). Se

fôssemos por eliminação, ficaríamos entre a b) e a e), pelo menos.

Já falei em “dançar conforme a música”? Pois é, acho que vou ser muito

repetitivo nesta apostila...


Desenvolvimento de Sistemas de Informação – 2008) No modelo de

desenvolvimento em espiral, cada ciclo da espiral representa uma fase do

processo de software. Nesse modelo, a atividade que obrigatoriamente estará

presente em todos os ciclos é:

a) Planejamento de desenvolvimento.

b) Análise de requisitos.

c) Teste de unidade.

d) Análise, Projeto, Implementação e Teste.

e) Análise de riscos.

Senso comum entre os autores! Você não pode errar! Letra e).

5ª Questão) (ESAF – Analista de Controle Externo – Análise de

Sistemas – 2002) O paradigma do ciclo de vida clássico da engenharia de

software requer uma abordagem sistemática, sequencial ao desenvolvimento do

software, que se inicia no nível do sistema e avança ao longo da análise, projeto,

codificação, teste e manutenção. A etapa deste ciclo, que se apresenta como um

processo de múltiplos passos e se concentra em quatro atributos distintos do

programa: estrutura de dados, arquitetura de software, detalhes procedimentais

e caracterização da interface, é a atividade de

a) codificação.

b) análise de requisitos de software.

c) análise de sistemas.

d) engenharia de sistemas.

e) projeto.

Detalhando o modelo em cascata:

Análise e Definição de Requisitos – Os serviços, restrições e objetivos do

sistema são definidos por meio de consulta aos usuários do sistema. Eles são,

portanto, definidos detalhadamente e servem como uma especificação de

sistema.

Projeto de sistema e software – O processo de projeto de sistema divide os

requisitos em sistemas de hardware ou de software. Ele estabelece uma



Prof. Victor Dalton


arquitetura geral do sistema. O projeto de software envolve a identificação e a

descrição das abstrações fundamentais do sistema de software e suas relações.

Implementação e teste de unidade – Durante esse estágio, o projeto de

software é realizado como um conjunto de programas ou unidades de programa.

O teste unitário envolve a verificação de que cada unidade atende à sua

especificação.

Integração e testes de sistema – As unidades individuais de programa ou

os programas são integrados e testados como um sistema completo para

garantir que os requisitos de software foram atendidos. Após os testes, o

sistema de software é liberado para o cliente.

Operação e manutenção – Geralmente (embora não necessariamente) esta

é a fase mais longa do ciclo de vida. O sistema é instalado e colocado em

operação. A manutenção envolve a correção de erros não detectados nos

estágios anteriores ao ciclo de vida, no aprimoramento da implementação das

unidades de sistema e na ampliação dos serviços de sistema À medida que

novos requisitos são identificados.

O segredo para acertar a questão é conhecer bem os nomes das etapas,

para não ser ludibriado pelas alternativas. Pela explicação da etapa, que consta

do enunciado, não cabe marcar outra alternativa que não seja a letra e).

6ª Questão) (UEL – POSCOMP 2010) Sobre o Ciclo de Desenvolvimento

de Software, é correto afirmar:

I. O desenvolvimento em cascata tem como base a ideia de desenvolver

uma implementação inicial, mostrar e discutir tal implementação com o usuário

e fazer seu aprimoramento por meio de versões subsequentes, até que um

sistema adequado tenha sido desenvolvido.

II. no modelo de processo de desenvolvimento em espiral, cada loop na

espiral representa uma fase do processo de software. Este modelo exige a

consideração direta dos riscos técnicos em todos os estágios do projeto e, se

aplicado adequadamente, deve reduzir os riscos antes que eles se tornem

problemáticos.

III. O Rapid Application Development (Desenvolvimento Rápido de

Aplicação) é um modelo de processo se software incremental que enfatiza um

ciclo de desenvolvimento rápido. Este modelo é uma adaptação de modelo

cascata, no qual o desenvolvimento rápido é conseguido com o uso de uma

abordagem de construção baseada em componentes.

IV. O modelo incremental combina elementos do modelo em cascata

aplicado de maneira iterativa. Em um processo de desenvolvimento incremental,

os clientes identificam (esboçam) as funções a serem fornecidas pelo sistema e



Prof. Victor Dalton


a importância das mesmas. Em seguida, é definida uma série de estágios de

entrega, com cada estágio fornecendo um subconjunto das funcionalidades do

sistema.

Assinale a alternativa correta.

a) Somente as afirmativas I e II estão corretas.

b) Somente as afirmativas I e III estão corretas.

c) Somente as afirmativas III e IV estão corretas.

d) Somente as afirmativas I, II e IV estão corretas.

e) Somente as afirmativas II, III e IV estão corretas.

Questão da UEL sobre o assunto! Coisa rara, viu? Mas analisemos com o

conhecimento já transmitido:

I. Errado! Analisamos o modelo em cascata na questão anterior, e, no início

da apostila, afirmei que este modelo estava ultrapassado. No modelo em

cascata, o cliente pede o software, levantam-se os requisitos e, depois de um

bom tempo, o cliente recebe o programa “pronto”;

II. Eu afirmei que o reconhecimento do risco é senso comum entre os

autores, quando falamos do modelo espiral! Certa;

III. Observando a figura do RAD, na 2ª questão, percebe-se facilmente que

ele é uma adaptação do modelo em cascata, com o uso de uma abordagem

baseada em componentes. Diga-se de passagem, este item é uma cópia do

Pressmann. Certa;

IV. “O modelo incremental combina elementos do modelo em cascata

aplicado de maneira iterativa”. Se eu conhecesse o Pressmann pessoalmente,

poderia imaginá-lo falando essa frase. Certa.

Dessa forma, nossa alternativa correta é a letra e).

7ª Questão) (ESAF – Agência Nacional de Águas – Analista de

Sistemas – 2009) Analise as seguintes afirmações sobre requisitos de sistemas

de software:

I. Requisitos funcionais declaram as funções que o sistema deve fornecer,

seu comportamento, e ainda, o que o sistema não deve fazer.

II. Requisitos de domínio são, exclusivamente, funcionais, pois exibem as

características do domínio de aplicação do sistema.

III. Requisitos não-funcionais compreendem restrições sobre serviços ou

funções do sistema.

Assinale a opção correta.

a) Apenas as afirmações I e II são verdadeiras.



Prof. Victor Dalton


b) Apenas as afirmações I e III são verdadeiras.

c) Apenas as afirmações II e III são verdadeiras.

d) As afirmações I, II e III são verdadeiras.

e) Nenhuma das afirmações é verdadeira.

O conceito de requisito, na Engenharia de Software refere-se à definição de

uma característica, atributo, habilidade ou qualidade que um sistema deve

necessariamente prover para ser útil a seus usuários. Creio que, a esta altura do

campeonato, isso não seja mais novidade para você. Contudo, os requisitos

podem ser classificados de diversas formas. A saber:

Requisito funcional: Define uma função de um sistema de software ou seu

componente. Uma função é descrita como um conjunto de entradas, seu

comportamento e as saídas. Os requisitos funcionais podem ser cálculos,

detalhes técnicos, manipulação de dados e de processamento e outras

funcionalidades específicas que definem o que um sistema, idealmente, será

capaz de realizar. Em suma, dizem o que o sistema deve fazer, mas também

pode ser uma declaração explícita do que o sistema não deve fazer. Ex: “o

usuário deve ser capaz de pesquisar todos os livros da biblioteca”, “o usuário

não pode cautelar dois exemplares do mesmo livro”.

Requisito não-funcional: É o requisito relacionado ao uso da aplicação em

termos de desempenho, usabilidade, confiabilidade, segurança, disponibilidade,

manutenibilidade e tecnologias envolvidas. Em geral, requisitos não-funcionais

podem constituir restrições aos requisitos funcionais e não é preciso o cliente

dizer sobre eles, pois eles são características mínimas de um software de

qualidade, ficando a cargo do desenvolvedor optar por atender esses requisitos

ou não. Ex: “o sistema deve suportar o uso simultâneo por cem usuários, sem

apresentar lentidão ou perda de performance”.

Requisito de domínio: É um requisito proveniente do domínio da aplicação

do sistema e que reflete as características e as restrições desse domínio. Pode

acabar produzindo requisitos funcionais ou não funcionais. Ex: “esse aplicativo

deverá ser executado tanto em IPhone quanto em celulares Android”. É um

requisito de domínio que demandará uma série de requisitos funcionais e não

funcionais em cada plataforma a ser desenvolvido o sistema.

Requisito de usuário: O requisito de usuário de um sistema deve descrever

os requisitos funcionais e não funcionais de modo que ele seja compreensível

pelos usuários do sistema que não possuem conhecimento técnico detalhado.

Eles devem especificar apenas o comportamento externo do sistema e evitar,

sempre que possível, descrever características de projeto do sistema. Os

exemplos de requisitos funcionais que eu passei são bons exemplos de requisitos

de usuário.

Requisito de sistema: É uma versão expandida do requisito de usuário,

usado pelos engenheiros de software como ponto de partida para o projeto do

sistema. Podem ser escritas em linguagem natural e/ou linguagens de notação

de projetos e notações gráficas. Por exemplo: “Uma chamada a um arquivo



Prof. Victor Dalton


externo não deverá repassar parâmetros a esse arquivo. O tratamento das

variáveis deverá se local.”

Especificação de interface (ou de projeto):É uma especificação técnica que

auxilia o sistema em desenvolvimento a operar junto a outros sistemas já

existentes. Por exemplo, um sistema que eventualmente use uma impressora

em ambiente Windows deverá saber como “interfacear” com uma impressora

nesse sistema operacional.

Feita essa explanação, voltemos aos itens da questão:

I. Correta;

II.Errada, pois os requisitos de domínio podem ser também não-funcionais;

III.Correta. Um requisito não-funcional pode afetar um requisito funcional.

Ex:Um sistema que opere em uma máquina que não permita a inserção de

pendrives pode restringir o salvamento de arquivos neste tipo de mídia,

permitindo apenas o envio de dados pela internet;

Logo, nossa resposta certa é a letra b).

(FCC – Agente Fiscal de Rendas – Tecnologia da Informação - 2009)

Para responder as questões de 8 e 9, considere:

“É necessário que o software calcule os salários dos diaristas e mensalistas

e emita relatórios mensais sumariados por tipo de salário. Entretanto, a base de

dados deve estar protegida e com acesso restrito aos usuários autorizados. De

qualquer forma, o tempo de resposta das consultas não deve superar os quinze

segundos, pois inviabilizaria todo o investimento nesse sistema. Devo lembrar

que os relatórios individuais dos departamentos, nos quais constam os salários

dos funcionários, devem ser emitidos quinzenalmente em razão dos

adiantamentos e vales que recebem. É fundamental que o software seja

operacionalizado usando código aberto.

Necessito, ainda, forte gerenciamento de risco, prazo e custo, porque a

entrega do produto final não pode ultrapassar o prazo de oito meses a contar da

data de início do projeto.”

A frase acima, expressa por um funcionário do cliente, aborda alguns

requisitos de software especificados para um sistema de gestão de pessoal.

8ª Questão) No texto, são requisitos não-funcionais:

a) não pode ultrapassar o prazo de oito meses e necessário que o software

calcule os salários dos diaristas e mensalistas.

b) os relatórios individuais dos departamentos, nos quais constam os

salários dos funcionários, devem ser emitidos quinzenalmente e em razão dos

adiantamentos e vales que recebem.



Prof. Victor Dalton


c) É fundamental que o software seja operacionalizado usando código

aberto e os relatórios individuais dos departamentos, nos quais constam os

salários dos funcionários, devem ser emitidos quinzenalmente.

d) tempo de resposta das consultas não deve superar os quinze segundos e

entrega do produto final não pode ultrapassar o prazo de oito meses.

e) pois inviabilizaria todo o investimento nesse sistema e em razão dos

adiantamentos e vales que recebem.

Pois bem, após trabalharmos bastante os conceitos dos diversos tipos de

requisitos, nada como usarmos um pouco do raciocínio para responder esta

questão da famosa prova da FCC, cujo edital é “muito similar” ao da prova de

vocês. Não se preocupem, brincaremos bastante com esta prova.

Definimos requisitos não-funcionais como “requisitos relacionados ao uso

da aplicação em termos de desempenho, usabilidade, confiabilidade, segurança,

disponibilidade, manutenibilidade e tecnologias envolvidas”. Vejamos os itens:

a) fala em cálculo de salários. Errada;

b) fala em emissão de relatórios. Errada;

c) idem à b). Errada;

d) tempo de resposta de consultas e prazo para entrega. Certa!

e) item nonsense. Errada.

Mesmo que você não estivesse confiante em marcar a alternativa d),

seria possível trabalhar por eliminação.

9ª Questão) No texto, são requisitos funcionais:

a) calcule os salários dos diaristas e mensalistas e os relatórios individuais

dos departamentos, nos quais constam os salários dos funcionários, devem ser

emitidos quinzenalmente.

b) Necessito, ainda, forte gerenciamento de risco, prazo e custo e a base

de dados deve estar protegida e com acesso restrito aos usuários autorizados.

c) é fundamental que o software seja operacionalizado usando código

aberto e emita relatórios mensais sumariados por tipo de salário.

d) emita relatórios mensais sumariados por tipo de salário e Necessito,

ainda, forte gerenciamento de risco, prazo e custo.

e) a base de dados deve estar protegida e com acesso restrito aos usuários

autorizados e entrega do produto final não pode ultrapassar o prazo de oito

meses.

Aqui eu já quero você mais confiante! De cara, a alternativa a) já parece

correta. Vejamos as demais.

b)apenas requisitos não funcionais;

c)um requisito não-funcional e um funcional;



Prof. Victor Dalton


d)um requisito funcional e outro não-funcional;

e)requisitos não-funcionais.

Podemos seguir em frente?


Tecnologia da Informação – 2008) Os requisitos de um sistema são

descrições dos serviços fornecidos pelo sistema e as suas restrições

operacionais. Indique a opção que corretamente se relaciona com a análise ou

gerenciamento de requisitos.

a) Requisitos de sistema são declarações do usuário que definem,

detalhadamente, as funções, os serviços e as restrições operacionais do sistema.

b) As representações de dados usadas nas interfaces de sistemas são

exemplos de requisitos funcionais.

c) A exigência de que o sistema deva fornecer telas apropriadas para o

usuário ler os documentos no repositório de documentos é um exemplo de

requisito funcional.

d) A exigência de que o sistema não deva revelar quaisquer informações

pessoais sobre os usuários do sistema ao pessoal de vendas que o utiliza, com

exceção do nome e cargo, é um exemplo de requisito funcional.

e) Avaliar se os requisitos associados ao desempenho, ao comportamento e

às características operacionais do sistema foram explicitamente declaradas é

uma tarefa de especificação de requisitos.

Vamos analisar as alternativas com o conhecimento já adquirido?

a) Descreve o que são requisitos de usuário. Errada;

b) Especificações de interface. Errada;

c) Correta;

d) Requisito não-funcional, pois está relacionado à segurança da aplicação.

Errada;

e) Tarefa da validação de requisitos, mas este conteúdo será visto mais

adiante. Errada;

Espero que você já esteja dominando este tópico. Alternativa c).

11ª Questão) (Formulação pessoal) É uma técnica de elicitação de

Requisitos:

a) Entrevista com stakeholder, por meio de formulários predefinidos

(entrevista fechada) ou não (entrevista aberta). Por meio dela procura-se saber

o que o interessado espera ou deseja no sistema.

b) Descrição de cenários, na qual começa-se com um esboço da interação

e, durante a elicitação, adicionam-se detalhes para uma descrição completa

dessa interação.



Prof. Victor Dalton


c) Elaboração de casos de uso, que são cenários descritos em um diagrama

UML, visual, também discutidos com os interessados.

d) Etnografia, que é uma técnica na qual o analista insere-se no ambiente

de trabalho como um observador, procurando levantar os requisitos do sistema.

e) Todas as alternativas estão corretas.

Este tópico consta em seu edital, embora a cobrança em provas seja

raríssima. Elicitar requisitos nada mais é do que descobrir, elucidar os requisitos.

Todas as técnicas acima são técnicas de elicitação de requisitos. Perceba que

nada mais são do que formas práticas de procurar saber dos interessados o que

eles esperam do sistema que estão solicitando.

Utilize a questão como subsídio de conteúdo. Alternativa e).

12ª Questão) (FCC – Agente Fiscal de Rendas – Tecnologia da

Informação - 2009) Quanto aos requisitos de software, considere:

I. É importante que se estabeleçam práticas para encontrar, documentar,

organizar e rastrear os requisitos variáveis de um sistema.

II. Etnografia (observação e análise dos fluxos de trabalho) e sessões de

JAD são práticas que podem ser aplicadas na elicitação.

III. Elicitar significa descobrir os requisitos de um sistema por meio de

entrevistas, de documentos do sistema existente, de análise do domínio do

problema ou de estudos do mercado.

Está correto o que se afirma em

a) I, apenas.

b) I e II, apenas.

c) I, II e III.

d) II e III, apenas.

e) III, apenas.

Utilizando os conhecimentos adquiridos até então, acredito que sua única

dúvida na questão a respeito de JAD. Vamos lá:

O JAD (Joint Application Design) é uma técnica de levantamento interativo,

criada por dois profissionais da IBM do Canadá na década de 1970 onde, em

uma ou mais sessões, são reunidos todos os interessados no assunto para tomar

as decisões sobre o mesmo. A técnica tem uma abordagem voltada para o

trabalho em equipe e visa definir um modelo de solução de problemas baseado

em consenso.



Prof. Victor Dalton


A dinâmica do JAD: São feitas reuniões participativas, chamadas de

sessões, envolvendo representantes de todas as áreas relacionadas com os

assuntos em discussão.

As regras da sessão:

Todos os participantes são iguais. Nas sessões JAD, a estrutura

hierárquica e de poder são deixadas do lado de fora. Todas as posições

tem o mesmo peso e serão avaliadas pelo grupo sem levar em conta qual

é a origem da mesma.

Apenas uma pessoa fala de cada vez. Assim todos terão chance de

expressar a sua opinião e de ouvir as opiniões do restante do grupo.

Todas as opiniões são válidas. É preciso não ter uma posição pré-

concebida sobre as opiniões dadas.

Hora para começar, interromper e terminar. É necessário definir uma

agenda para as sessões e cumpri-la à risca.

Celular desligado. Durante a sessão não devem acontecer interrupções

externas.

Recursos visuais. Utilizar intensivamente recursos visuais para tornar o

projeto do sistema mais palpável e permitir que ele seja entendido pelos

diversos participantes. Uma fotografia é mais explicativa e rica em

detalhes do que 1000 palavras para a descrição de um fato.

Os papéis na sessão:

Sponsor (Patrocinador). É o executivo responsável pelo projeto, o dono

do sistema. Ele precisa ter autonomia para tomar decisões, definir

estratégias e direcionar o trabalho.

Facilitador. É o responsável por conduzir a sessão. Ele não precisa ser

um especialista no assunto que está sendo tratado. Ele deverá estar

focado em organizar a dinâmica, dando a palavra a cada participante,

obtendo o consenso sobre os assuntos tratados, organizando o registro

das decisões e intermediando os conflitos.

Escriba. É a pessoa responsável por registrar todas as discussões e

decisões em um local que todos possam visualizar, como um quadro ou

flip-chart.

Documentador. É o responsável por registrar todas as decisões em um

documento formal, como uma ata de reunião ou uma especificação de

requisitos, que será assinado por todos ao final das sessões.

Especialistas. São as pessoas que tem conhecimento do assunto que

está sendo discutido e que podem efetivamente contribuir para a

discussão e na tomada de decisões.

Observadores. São pessoas que estão na sessão apenas para conhecer

mais do assunto que está sendo tratado ou para assimilar a técnica da

reunião. Os observadores não podem se manifestar durante a sessão.



Prof. Victor Dalton


Os fatores de sucesso:

A sessão precisa ter presente as pessoas que tem poder de decisão sobre

o assunto tratado, pois, não adianta tomar decisões durante a reunião que

poderão ser contestadas quando todos voltarem para o escritório.

As decisões precisam ser tomadas por consenso, pois, todos os

participantes da sessão precisam sair de lá comprometidos com as

definições registradas.

As sessões devem ocorrer fora do ambiente de trabalho dos participantes

para evitar interrupções e prevenir que os participantes se vejam tentados

a tratar de assuntos ligados a sua rotina diária.

Não deixar que os participantes imponham suas opiniões em função do

seu nível hierárquico, para evitar que pessoas de nível hierárquico mais

baixo fiquem constrangidas em debater ou discordar.

Definir claramente qual será o produto gerado no final das sessões.

Os benefícios esperados em relação aos métodos tradicionais:

Maior produtividade. Estudos relatam aumentos de 20 a 60% na

produtividade, em relação aos métodos tradicionais.

Maior qualidade. Usuários e analistas de sistemas costumam citar “projeto

de softwares de alta qualidade” como sendo o maior benefício do método.

Trabalho em equipe. Promove o espírito de cooperação, entendimento e

trabalho em equipe.

Custos mais baixos. O projeto de alta qualidade, obtido através do JAD,

possibilita uma grande economia de tempo e dinheiro mesmo após a

entrega do sistema.

Bem, apesar de parecer mais com uma reunião do AA (não que eu já tenha

ido em uma, rs), você pôde notar que o JAD também é uma técnica de Elicitação

de requisitos.

Assim sendo, todos os itens estão corretos e nossa alternativa certa é a

letra c).

13ª Questão) (UEL – Secretaria do Estado da Administração e da

Previdência – Analista de Sistemas - 2009) Um dos seus principais

objetivos é melhorar a modelagem de sistemas e a capacidade de analisá-los,

possibilitando maior entendimento de suas características antes da

Implementação. É seu papel realizar a interação entre “o que” deve ser feito e

“como” deve ser feito.

Esta afirmação refere-se a:



Prof. Victor Dalton


a) Arquitetura do Software.

b) Planejamento do Software.

c) Engenharia de Requisitos.

d) Estimativas do Projeto.

e) Processo de desenvolvimento de Software.

A Engenharia de Requisitos ajuda os engenheiros de software a

compreender melhor o problema que eles vão trabalhar para resolver. Ela inclui

o conjunto de tarefas que levam a um entendimento de qual será o impacto do

software sobre o negócio, do que o cliente quer e de como os usuários finais vão

interagir com o software. Seu objetivo é fornecer a todas as partes um

entendimento escrito do problema.

Resposta certa, letra c).

14ª Questão) (UEL – POSCOMP 2010) A Engenharia de Requisitos é um

processo que envolve todas as atividades exigidas para criar e manter o

documento de requisitos do sistema.

Sobre a Engenharia de Requisitos, considere as afirmativas a seguir.

I. A Engenharia de Requisitos, como todas as outras atividades de

Engenharia de Software, precisa ser adaptada às necessidades do processo, do

projeto, do produto e do pessoal que está fazendo o trabalho.

II. No estágio de levantamento e análise dos requisitos, os membros da

equipe técnica de desenvolvimento do software trabalham com o cliente e os

usuários finais do sistema para descobrir mais informações sobre o domínio da

aplicação, que serviços o sistema deve fornecer, o desempenho exigido do

sistema, as restrições de hardware, entre outras informações.

III. Na medida em que a informação de vários pontos de vista é coletada,

os requisitos emergentes são consistentes.

IV. A validação de requisitos se ocupa de mostrar que estes realmente

definem o sistema que o cliente deseja. Ela é importante porque a ocorrência de

erros em um documento de requisitos pode levar a grandes custos relacionados

ao retrabalho.








Prof. Victor Dalton



Aproveitaremos esta questão da UEL para destrinchar todas as etapas da

Engenharia de Requisitos.

A engenharia de requisitos fornece o mecanismo apropriado para entender

o que o cliente deseja, analisando as necessidades, avaliando a exequibilidade,

negociando uma condição razoável, especificando a solução de modo não

ambíguo, validando a especificação e gerindo os requisitos à medida que eles

são transformados em um sistema operacional (não confundir com Windows ou

Linux – sistema operacional, neste contexto, significa um sistema pronto para

operar). O processo de engenharia de requisitos é realizado por meio da

execução de sete funções distintas: concepção, levantamento, elaboração,

negociação, especificação, validação e gestão.

Concepção - Concepção inicial do software. O objetivo desta etapa é

entender o problema, quais os envolvidos, a natureza da solução e iniciar o

processo de comunicação entre clientes e colaboradores.

Levantamento e análise - Perguntar aos envolvidos no projeto:

Qual o objetivo do produto?;

Como o produto se enquadra nas necessidades do

negócio?;

Como o produto será utilizado?

O que o produto deve oferecer?

Entretanto, podem existir diversos problemas nesse ponto do projeto:

Problemas de escopo: Não se identifica corretamente os

limites do que o Software deve ou não fazer, muitas vezes requisitos

técnicos desnecessários confundem o entendimento da solução

esperada;

Problemas de entendimento: O cliente não tem domínio

suficiente do problema, não conhece o potencial de uma solução

computacional, omite informações óbvias, entre outros;

Problemas de volatilidade: Os requisitos mudam ao longo

do tempo.

Por experiência própria, posso afirmar o quanto é difícil levantar requisitos,

principalmente quanto a problemas de entendimento. Sempre que partimos para

a próxima etapa, a elaboração, uma das coisas mais comuns é o cliente afirmar

que aquele cenário elaborado não condiz com o que ele mesmo descreveu e



Prof. Victor Dalton


documentou na reunião anterior. As etapas de elaboração e levantamento

formam um loop à parte, até que se consiga avançar no projeto.

Elaboração - Refinamento das informações obtidas na etapa anterior com a

inclusão de modelagens de cenários de interação do usuário com o sistema e

modelagem das classes envolvidas tanto como a relação entre elas.

Negociação - É frequente que após a etapa de elaboração muitos requisitos

não estejam de acordo com a disponibilidade de recursos disponíveis ou ainda

sejam conflitantes entre si. Nesse ponto os requisitos são avaliados junto ao

cliente e podem ser excluídos, combinados ou ainda serem acrescentados novos

requisitos.

Especificação - A especificação é a apresentação formal dos dados obtidos

até o momento podendo incluir gráficos, textos em linguagem natural,

modelagem de cenários ou um protótipo. O principal é que a especificação possa

guiar o desenvolvimento futuro indicando os limites do software com as suas

possibilidades e limitações.

Validação - Nesse ponto, todos os envolvidos (clientes, colaboradores e

usuários) avaliam os requisitos em busca de erros de interpretação,

ambiguidade e omissões. Pode ser usado um modelo de questões checklist para

validar os requisitos.

Gestão - A gestão de requisitos é o processo que visa identificar, controlar

e rastrear requisitos e modificações nos requisitos ao longo de um projeto. Em

projetos de grande porte com centenas de requisitos é essencial um modelo

formal, muitas vezes baseado em tabelas que cruzam estes requisitos com os

aspectos do sistema como interface e dependências. Para projetos menores esse

processo pode ser feito de forma mais informal.

Você ainda se lembra da questão? Então volte aos itens dela e tente

responder sem a minha explicação abaixo.

I.É uma afirmativa bem genérica e verdadeira. Todas as atividades da

Engenharia de Software devem ser adaptadas à organização que a realiza;

II. Correta. A descoberta, elicitação ou levantamento dos requisitos (isso

mesmo, 10ª questão) é a etapa em que ocorre essa obtenção de informações

sobre o domínio da aplicação;

III. Não necessariamente. Inclusive, o mais comum, à medida que se

coletam diferentes pontos de vista, é encontrarmos requisitos conflitantes. E é

por isso que a fase de negociação é indispensável;

IV. Correta. Após a negociação e a especificação, a validação é uma espécie

de “reunião final” em que todos avalizam os requisitos definidos. Após isto,

temos apenas a gestão, que rastreia a evolução dos requisitos ao longo do

tempo.

Entendidas estas sete etapas? Certamente este assunto será cobrado em

sua prova. Alternativa d).



Prof. Victor Dalton


15ª Questão) (ESAF – Analista de Finanças e Controle – Tecnologia

da Informação – 2012 - adaptada) Assinale a opção correta.

a) Gestão de requisitos preocupa-se com a documentação, atualização e

controle de stakeholders envolvidos na fase de identificação da demanda.

b) Engenharia de requisitos compreende: identificar, analisar, especificar e

definir as necessidades de negócio que um aplicativo deve prover para solução

do problema levantado.

c) Engenharia de requisitos compreende: planejar, especificar e

desenvolver as necessidades de negócio que um aplicativo deve prover para

minimização dos problemas levantados.

d) Engenharia de requisitos compreende: identificar, analisar, programar e

testar os programas das necessidades de solução de problemas que um negócio

deve prover para satisfazer usuários.

e) Gestão de requisitos preocupa-se com a documentação, direcionamento,

controle de definição e acesso aos requisitos levantados na fase de planejamento

de escopo.

Agora que você compreende os conceitos de Engenharia de Requisitos pode

responder bem uma questão que mistura e confunde conceitos.

As alternativas a) e e) afirmam coisas sem sentido; você já sabe que, após

a consolidação dos requisitos, a gestão de requisitos atua no sentido de rastrear

e acompanhar os requisitos ao longo do tempo.

Quanto às questões que definem engenharia de requisitos, não é difícil

encontrar verbos absurdos atribuídos nas alternativas c) e d), como

“desenvolver as necessidades do negócio” e “programar e testar os programas”.

Você já domina esse conceito.

Logo, a alternativa correta é a letra b).

16ª Questão) (FGV – Senado Federal - Analista Sistemas – 2012) O

processo de Engenharia de Requisitos é realizado por meio da execução de sete

funções distintas: concepção, levantamento, elaboração, negociação, especi

validação e gestão. Nesse contexto, observe a lista abaixo, que representa um

conjunto de questões a serem utilizadas como checklist dentro de uma dessas

funções.



Prof. Victor Dalton


A função é:

a) Elaboração

b) Negociação

c) Especificação

d) Validação

e) Gestão

Opa! Você já sabe qual a etapa que reúne clientes, colaboradores e

usuários para avaliar os requisitos acordados, inclusive por meio de um

checklist, não sabe? É a validação.

Ainda, se lhe restar alguma dúvida, confirme que o checklist apresentado

procura erros de interpretação, ambiguidade e omissões. Até mesmo pelo

conteúdo das perguntas mostradas, é razoável que estejamos em uma etapa

posterior à concepção, levantamento e elaboração dos requisitos. Também não

são perguntas referentes a uma eventual negociação. Na especificação não cabe

checklist, pois esta é um detalhamento formal dos requisitos pós-negociação,

auxiliada por protótipos e diagramas. E, por fim, não cabe ser gestão de

requisitos, pois também não cabe checklist na gestão. Nesta etapa, os requisitos

já estão claros, sendo apenas rastreados em caso de modificação ou evolução ao

longo do tempo.

Nossa resposta correta, alternativa d).

17ª Questão) (Formulação pessoal) É uma técnica de Validação de

Requisitos:

a) Revisões de requisitos, na qual os requisitos são analisados

sistematicamente por uma equipe de revisores.

b) Prototipação, na qual um modelo executável do sistema é apresentado

para usuários finais e clientes.



Prof. Victor Dalton


c) Geração de casos de teste, no qual código de testes é produzido para

analisar se os requisitos são testáveis, e se passam nos testes.

d) As alternativas a, b e c estão corretas.

e) Nenhuma alternativa está correta.

Quero chamar a sua atenção para esse tópico, uma vez que técnicas de

validação de requisitos está em seu edital, apesar de não ser comum sua

cobrança em provas. Além disso, nossa fonte recomendada não contém este

conteúdo com essas exatas palavras.

As alternativas a,b e c são as três técnicas de validação de requisitos

segundo Sommerville, em seu Livro Engenharia de Software. É a outra

referência forte no ramo de ES.

Portanto, utilize esta questão como fonte de estudo. Alternativa d).


Tecnologia da Informação - 2005) Analise as seguintes afirmações

relacionadas a conceitos gerais de gerenciamento e controle de qualidade:

I. O gerenciamento de qualidade é o processo que permite garantir que o

projeto foi completado sem desvio dos requisitos.

II. O diagrama de Pareto está relacionado às regras de Pareto para a

Qualidade de Software, que afirma que se forem solucionados 80% dos

problemas ou desvios de um software então este terá alcançado um índice de

qualidade de 100%.

III. O controle de qualidade utiliza inspeções para provar a existência de

qualidade dentro de um produto final do projeto.

IV. Um ambiente de desenvolvimento de software, no processo de evolução

da qualidade dos seus produtos e serviços, deve substituir o processo de

Controle da Qualidade pelo processo de Garantia da Qualidade.

Indique a opção que contenha todas as afirmações verdadeiras.

a) I e II

b) II e III

c) III e IV

d) I e III

e) II e IV

Qualidade de software está estreitamente relacionada a testes de software

(testar software faz parte da busca pela qualidade), faremos uma questão

conceitual apenas para desencargo de consciência.

O gerenciamento da qualidade de software pode ser estruturado em três

grandes atividades:



Prof. Victor Dalton


Garantia de qualidade – estabelecimento de um framework de

procedimentos organizacionais e padrões que conduzem a um software de alta

qualidade;

Planejamento de qualidade – seleção de procedimentos e padrões

apropriados deste framework, adaptados para um projeto de software

específico; e

Controle de qualidade – Definição e aprovação de processos que assegurem

que a equipe de desenvolvimento de software tenha seguido os procedimentos e

os padrões de qualidade de projeto.

Aconselha-se que a equipe de qualidade seja diferente da equipe de

desenvolvimento do software.

Por fim, destaco que o gerenciamento da qualidade envolve o

estabelecimento de padrões de processo, que definem os processos que devem

ser seguidos durante o desenvolvimento do software (como documentos

obrigatórios que devam ser gerados, estabelecimento de reuniões periódicas), e

o estabelecimento de padrões de produto(exigência de determinada

nomenclatura a ser adotada no código, padronização de comentários no código,

padronização do formato da documentação, etc.).

Feita esta introdução, vejamos as alternativas:

I. Está razoavelmente certa. Garantir que o projeto foi concluído sem

desvios também é um objetivo do gerenciamento de qualidade,

embora a maneira como a frase está escrita possa dar a entender que

é o único objetivo;

II. O diagrama de Pareto não faz parte do edital, mas, apenas para lembrar,

este é o diagrama da lei do 80/20. Por exemplo, 20% dos defeitos do

software são responsáveis por 80% das reclamações. Ele é um

diagrama que ajuda a estabelecer prioridades, logo, não garante nada;

III. Certíssimo. Controle -> inspeções!

IV. Esta substituição não existe, as três tarefas são necessárias.

Logo, ficamos com a alternativa c).

19ª Questão) (UEL – Analista de Informática Júnior –

Desenvolvimento de Sistemas - 2009) A norma ISO 9126 (Características

de Qualidade de Software define 6 características (requisitos) de qualidade

desejáveis para um produto de software.

Considere os itens a seguir:

I. Evidencia o conjunto de funções que atendem às necessidades explícitas

e implícitas para a finalidade a que se destina o produto e suas propriedades

específicas



Prof. Victor Dalton


II. Evidencia o desempenho do produto, verificado ao longo do tempo e em

condições estabelecidas.

III. Evidencia a facilidade de uso do produto, bem como o julgamento

individual desse uso, por um conjunto de usuários estabelecido ou subentendido.

IV. Evidencia a compatibilidade entre os recursos e os tempos envolvidos,

assim como o nível de desempenho requerido para o produto, sob condições

estabelecidas.

V. Evidencia a possibilidade de se utilizar o produto em diversas

plataformas, com pequeno esforço para adaptação.

VI. Evidencia a facilidade para fazer modificações específicas no software.

Assinale a alternativa que apresenta a sequência correta em relação aos

itens colocados anteriormente.

a) Funcionalidade; Eficiência; Usabilidade; Confiabilidade; Portabilidade;

Manutenibilidade.

b) Funcionalidade; Confiabilidade; Portabilidade; Eficiência; Usabilidade;

Manutenibilidade.

c) Confiabilidade; Usabilidade; Eficiência; Portabilidade; Manutenibilidade;

Funcionalidade.

d) Funcionalidade; Confiabilidade; Usabilidade; Eficiência; Portabilidade;

Manutenibilidade.

e) Confiabilidade; Funcionalidade; Usabilidade; Eficiência; Portabilidade;

Manutenibilidade.

Você não leu a ISO 9126 e está se sentindo inseguro frente à questão?

Nada disso. Ela vai servir para medir o seu grau de intimidade com o vocabulário

técnico da TI. Se você conseguir associar os itens às características de forma

correta, parabéns, você já está ficando íntimo da TI! Tente resolver a questão

antes de ver a minha explicação abaixo, tudo bem?

Alguns itens podem “amarrar” a alternativa correta com maior facilidade.

Evidenciar se um conjunto de funções atende à finalidade desejada está

diretamente relacionado à Funcionalidade. Por sua vez, Usabilidade é a medida

de facilidade de uso de um software, e existe todo um ramo da TI orientado a

esse assunto, chamado Engenharia da Usabilidade.

Ainda, graças ao aparecimento da “Portabilidade”, no âmbito da telefonia,

você já deve estar familiarizado com a palavra, e ter notado que ela só pode se

aplicar ao item V da questão. Por fim, modificar o software, seja para correções

ou evolução está diretamente relacionado à manutenibilidade do mesmo.



Prof. Victor Dalton


Logo, a dúvida reside apenas entre as alternativas a) e d), em que as

definições de confiabilidade e eficiência talvez não estejam tão explícitas em

suas descrições. Então vejamos abaixo as seis características descritas

corretamente:

Funcionalidade - Evidencia o conjunto de funções que atendem às

necessidades explícitas e implícitas para a finalidade a que se destina o produto

e suas propriedades específicas.

Confiabilidade - Evidencia o desempenho do produto, verificado ao longo do

tempo e em condições estabelecidas.

Usabilidade - Evidencia a facilidade de uso do produto, bem como o

julgamento individual desse uso, por um conjunto de usuários estabelecido ou

subentendido.

Eficiência - Evidencia a compatibilidade entre os recursos e os tempos

envolvidos, assim como o nível de desempenho requerido para o produto, sob

condições estabelecidas.

Portabilidade - Evidencia a possibilidade de se utilizar o produto em

diversas plataformas, com pequeno esforço para adaptação.

Manutenibilidade - Evidencia a facilidade para fazer modificações

específicas no software.

Assimilados os conceitos? Alternativa d).

20ª Questão) (UEL – Estrada de Ferro Paraná Oeste S.A – Analista de

Sistemas - 2008) Considere as afirmativas a seguir, sobre Teste de software:

I. Teste funcional é uma técnica utilizada para se projetar casos de teste no

qual o programa ou sistema é considerado uma caixa preta e, para testá-lo, são

fornecidas entradas e avaliadas as saídas geradas para verificar se estão em

conformidade com os objetivos especificados.

II. A técnica estrutural estabelece os requisitos de teste com base em uma

dada implementação, requerendo a execução de partes ou de componentes

elementares do programa.

III. Teste é um conjunto de atividades que não pode ser planejado

antecipadamente, porém deve ser realizado sistematicamente.

IV. Um módulo driver chama o módulo que está sendo testado, devendo

conter apenas as inicializações das variáveis globais e dos parâmetros que serão

utilizados para a chamada do módulo testado.


a) Somente as afirmativas I e III estão corretas.

b) Somente as afirmativas III e IV estão corretas.



Prof. Victor Dalton


c) Somente as afirmativas I e II estão corretas.



Vamos conversar um pouco sobre teste de software.

Teste de software é uma atividade realizada para descobrir erros que foram

produzidos inadvertidamente no momento em que o software foi projetado e

construído. Pode ser planejado antecipadamente e conduzido sistematicamente.

Ainda, podem ser testes de baixo nível, no qual são verificados se pequenos

segmentos de código-fonte foram corretamente implementados, bem como

testes de alto nível, que validam as principais funções do sistema com base nos

requisitos do cliente.

O teste de software é um elemento de um aspecto mais amplo, que é

frequentemente referido como Verificação e Validação (V&V).

Verificação se refere ao conjunto de atividades que garante que o software

implementa corretamente uma função específica (estamos construindo o produto

corretamente?), enquanto a Validação se certifica que o software construído

corresponde aos requisitos do cliente (estamos construindo o produto certo?).

A partir de agora, vamos utilizar as alternativas e as questões seguintes

para mergulharmos naquilo que for mais importante dentro deste assunto.

I. Teste funcional é um outro nome o teste “caixa preta”. Sua descrição

combina com aquilo que, intuitivamente, vem à sua cabeça: é um este que se

preocupa apenas em saber se o programa funciona. Aplica-se uma entrada e

verifica-se se a saída é a esperada. Falaremos mais dele adiante. Certa;

II. A técnica estrutural é um outro nome para o teste “caixa branca”. Nele,

além do resultado, preocupa-se com o caminho percorrido ao longo do

programa, e com quais partes foram executadas. Também será discutido mais

adiante. Correta;

III. Página 289 da nossa fonte, copiada e modificada. Retire o “não” da

frase, troque “porém” por “e” e ela fica correta. Errada;

IV. Os testes, quando realizados de forma automatizada, são coordenados

por esse módulo chamado de módulo driver; sua tarefa é exatamente a descrita

no item. Uma vez inicializadas as variáveis globais e chamados os parâmetros do

módulo que será testado, será possível verificar se o módulo está funcionando

corretamente, ou seja, se a saída do módulo é a esperada, com base nos

parâmetros utilizados. Certa;

Portanto, nossa alternativa correta é a letra d).



Prof. Victor Dalton


21ª Questão) (UEL – Analista de Informática Júnior –

Desenvolvimento de Sistemas - 2009) O método de teste, que tem por

finalidade determinar se os requisitos dos usuários foram total ou parcialmente

satisfeitos pelo produto, preocupando-se também em verificar como ocorre o

processamento, ou seja, preocupando-se com o caminho percorrido pelo dado

de entrada, é conhecido como:

a) Caixa preta.

b) Teste de domínio.

c) Caixa branca.

d) Teste de Stress.

e) Teste de Atividade.

Na questão anterior já frisamos a definição de testes. Agora, veremos

algumas das técnicas de testes mais comuns e as fases em que eles podem ser

empregados.

Técnicas de teste

Caixa-Branca - Também chamada de teste estrutural ou orientado à lógica,

a técnica de caixa-branca avalia o comportamento interno do componente de

software. Essa técnica trabalha diretamente sobre o código fonte do componente

de software para avaliar aspectos tais como: teste de condição, teste de fluxo de

dados, teste de ciclos, teste de caminhos lógicos, códigos nunca executados.

Os aspectos avaliados nesta técnica de teste dependerão da complexidade

e da tecnologia que determinarem a construção do componente de software,

cabendo portanto avaliação de mais aspectos que os citados anteriormente. O

testador tem acesso ao código fonte da aplicação e pode construir códigos para

efetuar a ligação de bibliotecas e componentes. Este tipo de teste é desenvolvido

analisando o código fonte e elaborando casos de teste que cubram todas as

possibilidades do componente de software. Dessa maneira, todas as variações

relevantes originadas por estruturas de condições são testadas.

Um exemplo bem prático desta técnica de teste é o uso da ferramenta livre

JUnit para desenvolvimento de classes de teste para testar classes ou métodos

desenvolvidos em Java. Também se enquadram nessa técnica testes manuais ou

testes efetuados com apoio de ferramentas para verificação de aderência a boas

práticas de codificação reconhecidas pelo mercado de software. A aderência a

padrões e boas práticas visa principalmente a diminuição da possibilidade de

erros de codificação e a busca de utilização de comandos que gerem o melhor

desempenho de execução possível. Apesar de muitos desenvolvedores alegarem

que não há ganhos perceptíveis com essa técnica de teste aplicada sobre

unidades de software, devemos lembrar que, no ambiente produtivo, cada

programa pode vir a ser executado milhares ou milhões de vezes em intervalos

de tempo pequenos. É na realidade de produção que a soma dos aparentes

pequenos tempos de execução e consumo de memória de cada programa poderá

levar o software a deixar de atender aos objetivos esperados. A técnica de teste



Prof. Victor Dalton


de caixa-branca é recomendada para as fases de teste de unidade e teste de

integração, cuja responsabilidade principal fica a cargo dos desenvolvedores do

software, que por sua vez conhecem bem o código fonte produzido.

Caixa-Preta - Também chamada de teste funcional, orientado a dado ou

orientado a entrada e saída, a técnica de caixa-preta avalia o comportamento

externo do componente de software, sem se considerar o comportamento

interno do mesmo. Dados de entrada são fornecidos, o teste é executado e o

resultado obtido é comparado a um resultado esperado previamente conhecido.

Como detalhes de implementação não são considerados, os casos de teste são

todos derivados da especificação.

Quanto mais entradas são fornecidas, mais rico será o teste. Numa situação

ideal todas as entradas possíveis seriam testadas, mas na ampla maioria dos

casos isso é impossível. Outro problema é que a especificação pode estar

ambígua em relação ao sistema produzido, e como resultado as entradas

especificadas podem não ser as mesmas aceitas para o teste. Uma abordagem

mais realista para o teste de caixa-preta é escolher um subconjunto de entradas

que maximize a riqueza do teste. Pode-se agrupar subconjuntos de entradas

possíveis que são processadas similarmente, de forma que testar somente um

elemento desse subconjunto serve para averiguar a qualidade de todo o

subconjunto. Por exemplo, em um sistema que aceita um inteiro como entrada,

testar todos os casos possíveis pode gerar pelo menos dezenas de milhares de

casos de testes distintos. Entretanto, a partir da especificação do sistema, pode-

se encontrar um subconjunto de inteiros que maximizem a qualidade do teste.

Depende do propósito do sistema, mas casos possíveis incluem inteiros pares,

inteiros ímpares, zero, inteiros positivos, inteiros negativos, o maior inteiro, o

menor inteiro.

Essa técnica é aplicável a todas as fases de teste – teste unitário, teste de

integração, teste de sistema e teste de aceitação. A aplicação de técnicas de

teste leva o testador a produzir um conjunto de casos de teste (ou situações de

teste). A aplicação combinada de outra técnica – técnica de particionamento de

equivalência (ou uso de classes de equivalência) permite avaliar se a quantidade

de casos de teste produzida é coerente. A partir das classes de equivalência

identificadas, o testador construirá casos de teste que atuem nos limites

superiores e inferiores destas classes, de forma que um número mínimo de

casos de teste permita a maior cobertura de teste possível.

Uma abordagem no desenvolvimento do teste de caixa-preta é o teste

baseado na especificação, de forma que as funcionalidades são testadas de

acordo com os requisitos. Apesar de necessário, esse tipo de teste é insuficiente

para identificar certos riscos num projeto de software.

Regressão - Essa é uma técnica de teste aplicável a uma nova versão de

software ou à necessidade de se executar um novo ciclo de teste durante o

processo de desenvolvimento. Consiste em se aplicar, a cada nova versão do

software ou a cada ciclo, todos os testes que já foram aplicados nas versões ou



Prof. Victor Dalton


ciclos de teste anteriores do sistema. Inclui-se nesse contexto a observação de

fases e técnicas de teste de acordo com o impacto de alterações provocado pela

nova versão ou ciclo de teste. Para efeito de aumento de produtividade e de

viabilidade dos testes, é recomendada a utilização de ferramentas de automação

de teste, de forma que, sobre a nova versão ou ciclo de teste, todos os testes

anteriores possam ser executados novamente com maior agilidade.

Técnicas não–funcionais - Outras técnicas de teste existem para testar

aspectos não-funcionais do software, como por exemplo, a adequação a

restrições de negócio, adequação a normas, ou restrições tecnológicas. Em

contraste às técnicas funcionais mencionadas acima, que verificam a produção

pelo sistema de respostas adequadas de suas operações, de acordo com uma

especificação, as técnicas não funcionais verificam atributos de um componente

ou sistema que não se relacionam com a funcionalidade (por exemplo,

confiabilidade, eficiência, usabilidade, manutenibilidade e portabilidade).

Uma delas é o uso conjunto de teste de desempenho e teste de carga

(testes de Stress), que verifica se o software consegue processar grandes

quantidades de dados, e nas especificações de tempo de processamento

exigidas, o que determina a escalabilidade do software. O teste de usabilidade é

necessário para verificar se a interface de usuário é fácil de se aprender e

utilizar. Entre verificações cabíveis estão a relação da interface com

conhecimento do usuário, a compreensibilidade das mensagens de erro e a

integridade visual entre diferentes componentes. Já o teste de confiabilidade é

usado para verificar se o software é seguro em assegurar o sigilo dos dados

armazenados e processados. O teste de recuperação é usado para verificar a

robustez do software em retornar a um estado estável de execução após estar

em um estado de falha.

Teste de Domínio - Pode ser aplicado em um campo, uma assinatura, um

I/O, ou qualquer tipo de local que receba valores externos ao sistema. Todo

domínio deve realizar consistências de dados validos e inválidos. Um domínio só

permite dados com a formatação igual ao que será armazenado.

Ex.: Campo DDD deverá permitir números de até quatro casas não

negativas ou a base de dados deve impedir a entrada de valores inválidos.

Uma técnica de teste comumente empregada em testes de domínio é a

Análise do Valor Limite – na qual são testados valores nas fronteiras de um

domínio. Por exemplo: se determinado campo só permite o preenchimento com

números de 1 a 100, aplicam-se nos testes os valores 0,1,100 e 101.

Fases (Tipos de Teste)

Uma prática comum é testar o software após uma funcionalidade ser

desenvolvida, e antes dela ser implantada no cliente, por um grupo de

profissionais diferente da implementação. Essa prática pode resultar na fase de



Prof. Victor Dalton


teste ser usada para compensar atrasos do projeto, comprometendo o tempo

devotado ao teste. Outra prática é começar o teste no mesmo momento que o

projeto, num processo contínuo até o fim do projeto.

Em contrapartida, algumas práticas emergentes como a programação

extrema e o desenvolvimento ágil focam o modelo de desenvolvimento orientado

ao teste. Nesse processo, os testes de unidade são escritos primeiro ( TDD ), por

engenheiros de software. Antes da implementação da unidade em questão, o

teste falha. Então o código é escrito, passando incrementalmente em porções

maiores dos casos de teste. Os testes são mantidos junto com o resto do código

fonte do software, e geralmente também integra o processo de construção do

software.

Teste de unidade - Também conhecida como teste unitário ou teste de

módulo, é a fase em que se testam as menores unidades de software

desenvolvidas (pequenas partes ou unidades do sistema). O universo alvo desse

tipo de teste são as subrotinas ou mesmo pequenos trechos de código. Assim, o

objetivo é o de encontrar falhas de funcionamento dentro de uma pequena parte

do sistema funcionando independentemente do todo.

Teste de integração - Na fase de teste de integração, o objetivo é encontrar

falhas provenientes da integração interna dos componentes de um sistema.

Geralmente os tipos de falhas encontradas são de transmissão de dados. Por

exemplo, um componente A pode estar aguardando o retorno de um valor X ao

executar um método do componente B; porém, B pode retornar um valor Y,

gerando uma falha. Não faz parte do escopo dessa fase de teste o tratamento de

interfaces com outros sistemas (integração entre sistemas). Essas interfaces são

testadas na fase de teste de sistema, apesar de, a critério do gerente de projeto,

estas interfaces podem ser testadas mesmo antes de o sistema estar

plenamente construído.

Teste de sistema - Na fase de teste de sistema, o objetivo é executar o

sistema sob ponto de vista de seu usuário final, varrendo as funcionalidades em

busca de falhas em relação aos objetivos originais. Os testes são executados em

condições similares – de ambiente, interfaces sistêmicas e massas de dados –

àquelas que um usuário utilizará no seu dia-a-dia de manipulação do sistema.

De acordo com a política de uma organização, podem ser utilizadas condições

reais de ambiente, interfaces sistêmicas e massas de dados.

Teste de aceitação - Geralmente, os testes de aceitação são realizados por

um grupo restrito de usuários finais do sistema, que simulam operações de

rotina do sistema de modo a verificar se seu comportamento está de acordo com

o solicitado. Teste formal conduzido para determinar se um sistema satisfaz ou

não seus critérios de aceitação e para permitir ao cliente determinar se aceita ou

não o sistema. Validação de um software pelo comprador, pelo usuário ou por

terceira parte, com o uso de dados ou cenários especificados ou reais. Pode



Prof. Victor Dalton


incluir testes funcionais, de configuração, de recuperação de falhas, de

segurança e de desempenho.

Teste de operação - Nessa fase o teste é conduzido pelos administradores

do ambiente final em que o sistema ou software entrará em ambiente produtivo.

Vale ressaltar que essa fase é aplicável somente a sistemas de informação

próprios de uma organização, cujo acesso pode ser feito interna ou

externamente a essa organização. Nessa fase de teste devem ser feitas

simulações para garantir que a entrada em produção do sistema será bem

sucedida. Envolve testes de instalação, simulações com cópia de segurança dos

bancos de dados, etc.. Em alguns casos um sistema entrará em produção para

substituir outro e é necessário garantir que o novo sistema continuará

garantindo o suporte ao negócio.

Destaco que as técnicas de testes e as fases são pontos de vista distintos

para se observar um determinado teste. Por exemplo, uma inspeção detalhada

na execução de um código específico pode ser um teste caixa-branca e um teste

de unidade. Assim como um teste de Stress, no ambiente final do sistema,

também pode ser um teste de operação. Compreendido?

Voltemos à questão, nossa alternativa correta é a letra c).

22ª Questão) (UEL – Secretaria do Estado da Administração e da

Previdência – Analista de Sistemas - 2009) Sobre teste de software,

considere as afirmativas a seguir:

I. A Atividade de teste de software é um elemento crítico da garantia de

qualidade de software e representa a última revisão de especificação, projeto e

codificação. O objetivo principal do projeto de casos de teste é originar um

conjunto de testes que tenha a maior probabilidade de detectar erros no

software.

II. O teste de caixa preta usa a estrutura de controle do projeto

procedimental para derivar casos de teste. O engenheiro de software pode

derivar os casos de teste que: garantem que todos os caminhos independentes

dentro de um módulo tenham sido exercitados pelo menos uma vez; exercitem

todas as decisões lógicas para valores falsos ou verdadeiros; executem todos os

laços em suas fronteiras e dentro de seus limites operacionais; e exercitem as

estruturas de dados internas para garantir a sua validade.

III. Os métodos de caixa branca concentram-se nos requisitos funcionais do

software. O teste de caixa preta procura descobrir erros nas seguintes

categorias: funções incorretas ou ausentes; erros de interface; erros nas



Prof. Victor Dalton


estruturas de dados ou no acesso a bancos de dados externos; erros de

desempenho e erros de inicialização e término.

IV. O teste de caminho básico é uma técnica de caixa branca e possibilita

que o projetista do caso de teste derive uma medida da complexidade lógica de

um projeto procedimental e use essa medida como guia para definir um

conjunto básico de caminhos de execução.


a) Somente as afirmativas I e III estão corretas.

b) Somente as afirmativas I e IV estão corretas.

c) Somente as afirmativas II e IV estão corretas.

d) Somente as afirmativas I, II e III estão corretas.


Depois de uma dose teórica na questão anterior, podemos analisar

diretamente os itens desta.

I. Este item está correto. Interessante deixar essa ideia bem frisada: o

objetivo dos testes é fazer o programa falhar! Fazer o programa funcionar é o

objetivo de quem desenvolve. O testador é um “sabotador”, no bom sentido,

que busca sempre fazer com que o programa falhe. É por isso que os testes

sempre procuram ser os mais “maldosos” possível;

II.Descrição do teste caixa-branca, ou , mais especificamente, do teste de

caminho, que é uma variação do teste caixa branca.. Errado;

III. Essa descrição é plenamente do teste caixa preta, estando errada

apenas a primeira frase. Errada;

IV. Outra definição para o teste de caminho, desta vez correta.

Desta forma, nossa alternativa correta é a letra b).

23ª Questão) (UEL – POSCOMP 2011) Tendo em vista a complexidade

envolvida no desenvolvimento de um sistema de software, é importante

assegurar que ele cumpra com suas especificações e atenda às necessidades dos

usuários.

Sobre o desenvolvimento de software, considere as afirmativas a seguir.

I. A Validação tem como objetivo responder. “Estamos construindo o

produto certo?” Já a Verificação busca responder: “Estamos construindo o

produto corretamente?”

II. Em um cadastro, encontra-se um campo de entrada solicitando o ano de

nascimento, sendo válidos valores entre 1900 e 2011. Os casos de teste para

este campo, considerando a técnica de análise de valor limite, são:

1899,1900,1901,2010,2011,2012 e 0.



Prof. Victor Dalton


III. As atividades de Verificação e Validação envolvem atividades de análise

estática e de análise dinâmica do produto em desenvolvimento, e apenas as

atividades de análise dinâmica envolvem a execução do produto.

IV. Um dos objetivos dos métodos de teste de caixa preta é garantir que

todos os caminhos de um programa tenham sido exercitados pelo menos uma

vez, podendo-se aplicar a técnica do teste do caminha básico para este fim.







Uma questão mais abrangente sobre testes, cujo conhecimento você já

possui para responder. Revisando:

I. Certa. Esta diferença dentre Verificação e Validação é estendida a todos

os ramos da TI, então assimile-a bem;

II. Na análise de Valor Limite, segundo Pressmann, cabe apenas testar os

valores das fronteiras e valores imediatamente acima e abaixo. Logo, seriam

apenas 1899,1900,2011 e 2012. Errada;

III. Correta. Análise estática envolve apenas a análise de códigos e

modelos, enquanto a dinâmica compreende a análise do programa em execução;

IV. Teste de caminho! Errada.

Portanto, a alternativa correta é a letra b).

24ª Questão) (Formulação pessoal) Segundo Pressmann, “cada um dos

elementos de informação que são criados durante o desenvolvimento de um

produto de software, que são identificados de maneira única e cuja evolução é

passível de rastreamento”, refere-se a

a) Item de software

b) Componente de software

c) Item de configuração

d) Componente de dados

e) Componente de programa

Vamos falar um pouco sobre Gerência de Configuração.

Gerência de Configuração

Durante seu ciclo de vida, o software passa por uma série de modificações,

desde sua concepção à implantação.



Prof. Victor Dalton


Sob este aspecto, a Gerência de Configuração de Software (CGS) vem a

definir critérios que permitam realizar tais modificações mantendo-se a

consistência e a integridade do software com as especificações.

Ela permite minimizar os problemas decorrentes ao processo de

desenvolvimento, através de um controle sistemático sobre as modificações. Não

é objetivo da GCS evitar modificações, mas permitir que elas ocorram sempre

que possível, sem que hajam falhas inerentes ao processo.

Em geral a GCS é aplicada apenas quando existe um processo de

desenvolvimento bem definido, com atividades agrupadas em fases, constituídas

por objetivos bem definidos e documentados. Neste contexto, GCS atua como

um suporte sobre o qual as fases do desenvolvimento são conduzidas e os

produtos controlados.

Aplicar um plano de gerência de configuração consiste em estabelecer

normas, ferramentas e templates que permitam gerenciar de maneira

satisfatória os itens de configuração de um sistema.

Entende-se como item de configuração “Cada um dos elementos de

informação que são criados durante o desenvolvimento de um produto de

software, ou que para este desenvolvimento sejam necessários, que são

identificados de maneira única e cuja evolução é passível de rastreamento”

(Pressman).

Itens de configuração podem ser:

Servidores

Estações de trabalho dos usuários

Banco de dados

Plano de negócio

Acordos com clientes

Softwares

Manuais de instrução

Outros, desde que sejam itens correlatos ao software entregue

Se o item de configuração for composto exclusivamente de software, ele é

então caracterizado como Item de Configuração de Software (ICSW).

Qualquer IC constitui uma unidade funcional que possui um ciclo de

desenvolvimento e acompanhamento de GCS próprios. Qualquer sistema em

desenvolvimento deve ser particionado em itens de configuração, e o seu

desenvolvimento é visto como o desenvolvimento de cada um dos ICs. Cada IC,

por sua vez pode ser particionado em outro conjunto de ICs e assim

sucessivamente, até que se resulte um conjunto de ICs não particionáveis, que

são desenvolvidos segundo um ciclo de vida propriamente definido.

A configuração de um sistema de software passa a ser definida pela

configuração do conjunto dos ICSW que o constitui.

É importante salientar que a divisão de um sistema ou produto de software

em ICs, bem como a definição do ciclo de vida de cada IC, são decisões de

projeto e não de GCS.

Em cada fase do processo de desenvolvimento, um conjunto bem definido

de itens de configuração deve ser estabelecido. Tal conjunto representa um



Prof. Victor Dalton


estágio do desenvolvimento, o qual é passível de modificações apenas mediante

um mecanismo formal de alterações. A este conjunto é dado o nome de

Baselines, ou Configurações Base do sistema.

Em princípio, baselines poderiam ser estabelecidas em qualquer ponto do

desenvolvimento. Entretanto, a grande vantagem do conceito está em se fazer

coincidir o estabelecimento de baselines com os finais de fase do ciclo de vida do

produto.

O desenvolvimento com configurações base pode, então, ser resumido nos

seguintes pontos:

Caracterização do ciclo de vida, identificando-se as fases pelas quais o

desenvolvimento do software irá passar e, dentro delas, as atividades a

serem realizadas e os produtos a serem desenvolvidos.

Definição do conjunto de baselines. Para cada baseline planejada, deve-se

estabelecer quais serão os ICs que a irão compor e quais as condições

impostas para seu estabelecimento;

Baselines representam marcos no processo de desenvolvimento: uma

nova baseline é estabelecida no final de cada fase do ciclo de vida do

software;

Durante cada fase, o desenvolvimento dos ICs a ela referentes está sob

total controle de seus desenvolvedores, e realiza-se com ampla liberdade,

podendo os ICs serem criados e modificados com bastante facilidade;

Durante cada fase, entretanto, a modificação de uma configuração-base

anteriormente estabelecida somente pode ser feita de forma controlada,

mediante um processo bem definido;

Ao ser estabelecida, cada baseline incorpora integralmente a anterior.

Desta forma, em qualquer instante do desenvolvimento, a última baseline

estabelecida representa o estado atual do desenvolvimento como um

todo;

O estabelecimento de cada baseline somente é realizado após ser

aprovada por procedimentos de consistência interna, verificação e

validação;

Desta forma é possível ter um controle sistemático sobre todos os itens de

configuração abordados em cada fase do ciclo de vida do software, assim como é

possível avaliar mais facilmente o seu grau de evolução.

O Gerenciamento de Configuração e o Gerenciamento de Mudanças pode

ser visto com mais detalhes no ITIL. Entretanto, por ter sido citado em

Engenharia de Software, também estamos vendo-o aqui.

Resposta certa, letra c).

25ª Questão) (Formulação Pessoal) Procedimentos de gerenciamento de

mudança dizem respeito à análise de custo e benefício das mudanças propostas,

à aprovação das mudanças viáveis e à rastreabilidade de quais componentes do



Prof. Victor Dalton


sistema foram alterados. O processo de gerenciamento de mudança deve surtir

efeito quando o software ou a documentação associada são colocados em

baseline pela equipe de gerenciamento de configurações.

O primeiro estágio para a solicitação de uma mudança para o sistema é

a) Modificar o item de configuração envolvido e notificar à equipe de

gerenciamento de mudança

b) Preencher uma Requisição de Mudança, ou Formulário de Solicitação de

Mudança, e encaminhar ao Comitê de Controle de Mudanças

c) Modificar o item de configuração envolvido e preencher o formulário para

envio ao Comitê de Controle de Mudanças

d) Notificar o Gerenciamento de Problema que deseja fazer uma mudança

no sistema

e) Aguardar uma falha no sistema para preencher uma Requisição de

Mudança

A ITIL define que o Gerenciamento de Mudanças e o Gerenciamento de

Configuração são processos distintos. Entretanto, reconhece-se que,

principalmente em pequenas organizações, estes processos podem ser

executados pelas mesmas pessoas. Não confunda pessoas com papéis, nem

papéis com processos; uma pessoa pode exercer vários papeis (como Gerente

de Mudança e Gerente de Configuração). Entretanto, os processos continuam

sendo distintos.

Mudanças são um fato da vida para sistemas de software.

Nesse contexto, o Gerenciamento de Mudança tem por objetivo assegurar

que as mudanças sejam feitas de uma forma controlada, e sejam avaliadas,

priorizadas, planejadas, testadas, implantadas e documentadas.

O primeiro estágio no processo de gerenciamento de mudanças é completar

um formulário de solicitação de mudança (destaco que este formulário será um

item de configuração!), que descreva a mudança necessária para o sistema. Ao

longo do processo, este formulário registrará as recomendações para a

mudança, os custos estimados e as datas de quando ela foi solicitada, aprovada,

implementada e validada, bem como seu nível de prioridade.

O Comitê de Controle de Mudanças é um grupo importante que toma as

decisões de mudança. Apesar do nome “pomposo”, em pequenos e médios

projetos, o CCM pode ser apenas o gerente de projeto e um ou dois

engenheiros. Em condições ideais, o CCM é uma equipe exclusiva, e que conta

com representantes do negócio. Naturalmente, caberá ao CCM analisar quais são

as mudanças dentro de seu nível de autorização, e quais mudanças exigem

ciência ou autorização de outros stakeholders.

Logo, nossa resposta certa é a letra b).

26ª Questão) (Formulação Pessoal) Sobre o Gerenciamento de

Mudanças, analise as afirmativas abaixo:



Prof. Victor Dalton


I. As mudanças em um sistema podem ser levantadas proativamente, para

resolver erros ou adaptar-se a circunstâncias de mudança, ou reativamente,

para gerar benefícios ao negócio, como reduzir custos e melhorar os serviços.

II. Gerenciar mudanças não é fazer mudanças que não ofereçam risco: é

fazer mudanças de forma que os riscos sejam mapeados e gerenciados.

III. Mudanças de alto custo e mudanças de risco são mudanças típicas cuja

autoridade de mudança é a gerência de TI.

IV. Mudanças urgentes sempre devem passar pela autoridade do negócio.


a) Somente a afirmativa II está correta.

b) Somente as afirmativas II e III estão corretas.

c) Somente as afirmativas II e IV estão corretas.



Vamos utilizar estas afirmativas para captar mais algumas ideias acerca do

Gerenciamento de Mudança:

I. Proativamente e reativamente estão trocadas na afirmativa. Errada;

II. Correta;

III. Naturalmente, para cada nível de importância da mudança existem

autoridades que podem autorizar a mudança ou não. Mudanças de alto custo e

mudanças de risco são mudanças que exigem que o Comitê Executivo de

Negócio autorize, enquanto mudanças de menor relevância podem ficar a cargo

do próprio CCM. Destaco que a “presidência” do CCM, apesar de poder conter

representantes de negócio, é sempre do Gerente de Mudança, que é alguém da

TI. Errada;

IV. Mudanças urgentes não devem ser confundidas com mudanças

importantes. Mudar o sistema de pagamento de um site pode ser importante

sem ser urgente, assim como trocar um servidor que deu defeito pode ser

urgente sem ser importante. Não é preciso uma autoridade de negócio para toda

mudança urgente. Errada;

P.S.: Destaco ainda que existe o Comitê de Controle de Mudanças

Emergencial, ou Comitê Consultivo de Mudanças Emergencial (CCME), que é

uma versão reduzida do CCM, que pode ser reunido quando da necessidade de

uma mudança urgente.

Voltando às alternativas, nossa resposta certa é a letra a).

27ª Questão) (Formulação Pessoal) É responsabilidade da Gerência de

Configuração:



Prof. Victor Dalton


I. Definir e controlar os componentes de serviços e infraestrutura do

sistema, mantendo informações precisas sobre os estados dos serviços e

infraestrutura atual e planejada.

II. Manter um banco de dados de configuração (Configuration Management

Data Base) com todas as informações relevantes sobre as configurações do

sistema e os itens de configuração.

III. Avaliar o impacto de uma mudança no sistema.



c) Somente as afirmativas II e III estão corretas.

d) Todas as afirmativas estão corretas.

e) Apenas a afirmativa II está correta.

Quero chamar a sua atenção para uma pegadinha que as bancas gostam de

armar para seus candidatos, que é confundir as atribuições da Gerência de

Configuração e a Gerência de Mudança.

Os itens I e II são de responsabilidade da Gerência de Configuração. O item

III, entretanto, é responsabilidade do Gerenciamento de Mudança! Apesar do

estreito relacionamento entre esses processos (é natural que a equipe de

mudança consulte a equipe de configuração para avaliar os itens de configuração

que serão afetados), não será a Gerência de Configuração que avaliará o

impacto de uma mudança, senão o próprio Gerenciamento de Mudança. Porém,

no ato da implantação da mudança, a Gerência de Configuração rastreará os

itens modificados, para manter o banco de dados de configuração atualizado.

Estamos entendidos? Alternativa c).


Tecnologia da Informação – 2005 - adaptada) A Análise de Pontos de

Função quantifica a funcionalidade do sistema sob o ponto de vista do usuário e

a) oferece uma medida da quantidade de linhas de código do software ou

sistema solicitado.

b) por isso, uma contagem de pontos de função deve ser realizada

utilizando uma terminologia exclusiva para o usuário, o que significa dizer que os

requisitos devem estar definidos em uma linguagem que represente de forma

única o entendimento dos stakeholders do projeto.

c) utiliza os requisitos não-funcionais como a base para o cálculo dos

pontos de função não ajustados e alguns requisitos funcionais são integrantes



Prof. Victor Dalton


das Características Gerais de Sistema utilizadas na fase de determinação do

fator de ajuste utilizado no cálculo do número de pontos de função ajustados.

d) mede o tamanho funcional do software. Este tamanho, em conjunto com

outras variáveis, pode ser usado para estimar esforço, prazo e custo, não sendo

a APF a responsável direta por estes parâmetros.

e) fornece um valor que especifica a quantidade de funções e

procedimentos e, em alguns casos como o desenvolvimento orientado a objetos,

métodos e classes que serão implementados no código do software ou sistema

solicitado.

A partir deste ponto, temos as mesmas questões de APF que você viu em

sua aula demonstrativa. Se você já estiver confiante no assunto, pule para as

questões 32 e 33 da aula, onde eu apresento questões bônus sobre o assunto.

Vale a pena vê-las!

Análise de Pontos de Função é uma técnica de medição das funcionalidades

fornecidas por um software do ponto de vista do usuário. Por buscar

independência da tecnologia utilizada para a construção do software, a APF

independe da linguagem de programação utilizada.

Portanto, o processo de medição, ou a contagem dos pontos de função, é

baseada em uma avaliação padronizada dos requisitos lógicos do uauário.

Ressalta-se que pontos de função não medem diretamente esforço,

produtividade ou custo. É exclusivamente uma medida de tamanho funcional do

software. Este tamanho, em conjunto com outras variáveis, é que poderá ser

usado para derivar produtividade, estimar esforço e custo.

Portanto, nossa resposta correta é a letra d). Acho importante este

entendimento. A APF não calcula esforço, produtividade e custos, mas o valor

dos pontos de função calculados são utilizados pela desenvolvedora do software

em questão para estimar estas variáveis, com base na sua equipe disponível,

tecnologias, etc.

29ª Questão) (ESAF – Ministério do Planejamento – Analista de

Sistemas – 2006) Na utilização das técnicas de Análise de Pontos de Função

para métricas de software, as funções do tipo dados são classificadas em

a) ALI (Arquivo Lógico Interno) e AIE (Arquivo de Interface Externa). A

principal intenção do ALI é armazenar dados mantidos através de uma ou mais

transações da aplicação sendo contada, como, por exemplo, tabelas de banco de

dados atualizadas pela aplicação.

b) EE (Entrada Externa) e AIE (Arquivo de Interface Externa). A principal

intenção do EE é armazenar dados mantidos através de uma ou mais transações

da aplicação sendo contada, como, por exemplo, tabelas de banco de dados

atualizadas pela aplicação.



Prof. Victor Dalton


c) EE (Entrada Externa), SE (Saída Externa) e CE (Consulta Externa). A

principal intenção do CE é armazenar dados mantidos através de uma ou mais

transações da aplicação sendo contada, como, por exemplo, tabelas de banco de

dados consultadas pela aplicação.

d) ALI (Arquivo Lógico Interno), AIE (Arquivo de Interface Externa), EE

(Entrada Externa), SE (Saída Externa) e CE (Consulta Externa). A principal

intenção de todas essas funções é armazenar dados mantidos através de uma

ou mais transações da aplicação sendo contada, como, por exemplo,

manutenção, pela aplicação, de tabelas de banco.

e) AIE (Arquivo de Interface Externa), SE (Saída Externa) e CE (Consulta

Externa). A principal intenção de todas essas funções é apresentar informações

aos usuários por meio de simples recuperação de dados.

Vejamos estes conceitos:

• Arquivo lógico interno (ALI) – “grupo de dados ou informação de controle

logicamente relacionados, reconhecido pelo usuário, mantido dentro da fronteira

de aplicação”. É um grupo de dados lógico, podendo ser tanto um arquivo como

uma parte de um banco de dados maior. Exemplos: cadastros, dados de

segurança, dados de auditoria e dados que sofrem manutenção da aplicação,

mesmo que sejam acessados por outra. Também são ALIs os dados de

mensagens de auxílio e mensagens de erros. Atenção: índices alternativos para

recuperação de informação e dados temporários não são ALI!

• Arquivo de interface externa (AIE) – também é um arquivo lógico, só que

está fora da fronteira da aplicação, sendo, portanto, um ALI de um outro

aplicativo. Não sofrem manutenção pela aplicação. Exemplos: dados de

referência, mensagens de auxílio, mensagens de erro.

• Saída externa (SE) – processo lógico do negócio que gera dados para um

usuário ou para outro aplicativo externo ao software. Às vezes é fácil confundir

com as consultas externas, então é importante ressaltar que para ser

considerado SE, deve haver cálculo. Exemplos: telas e relatórios, como os que

mostram uma nota fiscal, calculando o subtotal por item e o total geral da

compra. Repare também que os dados que são formatados e processados para

uso por outra aplicação também são saídas externas.

• Entrada externa (EE) – são os dados que entram no sistema e são usados

para incluir, alterar ou excluir dados nos arquivos lógicos internos (ALI). Cada

adição, alteração ou remoção é contada como uma entrada externa. Também o

é cada formato de tela de entrada de dados. Importante: dados utilizados pela

aplicação, mas que não atualizam dados nos ALIs não são entradas externas.

Isto parece simples, mas às vezes confunde – telas de logon e de menu, por

exemplo, não são EE, a não ser que alimentem logs de segurança.

• Consulta externa (CE) – é um par pergunta-resposta, cuja pergunta vem

de um usuário ou de outro aplicativo. Os dados são recuperados para atender à

solicitação e então são enviados para fora. Uma consulta é definida como uma

entrada que resulta na geração de alguma resposta imediata. São consultas



Prof. Victor Dalton


externas as consultas simples, realizadas no banco de dados, sem modificá-lo, e

mostradas na tela. As telas de ajuda são exemplos. Diferencia-se da Saída

Externa por não envolver lógica em seu processamento.

ALI e AIE são agrupados como sendo funções de dados, enquanto EE, SE e CE

são funções do tipo transação.

A cobrança em torno destes cinco elementos é comum. Nossa resposta

correta, alternativa a).


Desenvolvimento de Sistemas da Informação - 2012) Cada Arquivo Lógico

Interno e cada Arquivo de Interface Externa devem ser classificados com relação

à sua complexidade funcional com base em:

a) Número de Tipos de Dados, Número de Tipos de Registros.

b) Número de Tipos de Arquivos, Número de Tipos de Registros.

c) Número de Tipos de Dados, Número de Tipos de Consultas.

d) Número de Tipos de Campos, Número de Tipos de Arquivos.

e) Número de Tipos de Tabelas, Número de Tipos de Campos.

O cálculo da complexidade funcional é uma etapa necessária para a

determinação do número de pontos de função.

Mais algumas tabelinhas para a compreensão do cálculo da complexidade:



Prof. Victor Dalton


Nas funções do tipo dados, o nº de itens de dados e o nº de arquivos

referenciados determina o nível de complexidade, enquanto nas funções do tipo

transação o nº de itens de dados e o nº de arquivos referenciados são os itens

utilizados.

Posteriormente, estes pontos são computados em uma tabela, como a que

segue:



Prof. Victor Dalton


Os valores obtidos nesta tabela, na sequência, serão utilizados nas

fórmulas mostradas na próxima questão.

Quanto a esta questão, estamos entendidos? A bibliografia fala em número

de Itens de Dados, mas a ESAF teimou em número de Tipos de Dados, e não

aceitou recurso. Fazer o quê? Adivinha? Dançar conforme a música...

alternativa a).

31ª Questão) (ESAF – Comissão de Valores Mobiliários – Analista de

Sistemas – 2010) O cálculo dos pontos de função de um projeto de

desenvolvimento consiste dos componentes de funcionalidade:

a) reusabilidade de aplicação; reusabilidade de conversão; fator de ajuste

da aplicação.

b) funcionalidade de aplicação; funcionalidade de compressão; fator de

ponderação da aplicação.

c) reusabilidade de aplicação; funcionalidade de programação; fator de

ajuste da aplicação.

d) funcionalidade de aplicação; funcionalidade de conversão; fator de

ajuste da aplicação.

e) funcionalidade de programação; funcionalidade de conversão;

funcionalidade de manutenção.

A APF, via de regra, possuirá metodologias de cálculo distintas para duas

situações: ou desenvolvimento de um software novo, ou melhoria de um

software (manutenção e/ou evolução).

Utilizando as fórmulas do IFPUG, que são as mais simples, temos que:

Fórmula do Projeto de Desenvolvimento:

DFP = (UFP + CFP)x VAF

Em que DFP é o número total dos pontos de função de um projeto de

desenvolvimento,

UFP é o número de pontos de função da aplicação, não ajustados,

CFP é o número de pontos de pontos de função não ajustados das funções

de conversão, e

VAF é o valor do fator de ajuste.

Fórmula do Projeto de Melhoria:

EFP = [(ADD + CHGA + CFP)x VAFA] + (DEL x VAFB)]

Em que EFP é o número total dos pontos de função de um projeto de

melhoria,



Prof. Victor Dalton


ADD é o número de pontos de função da aplicação, não ajustados, das

funções incluídas no projeto de melhoria,

CHGA é o número de pontos de função da aplicação, não ajustados, das

funções modificadas no projeto de melhoria,

CFP é o número de pontos de pontos de função não ajustados das funções

de conversão,

VAFA é o valor do fator de ajuste depois da aplicação do projeto de

melhoria,

DEL é o é o número de pontos de função da aplicação, não ajustados, das

funções excluídas no projeto de melhoria, e

VAFB é o valor do fator de ajuste antes da aplicação do projeto de

melhoria.

As fórmulas fazem bastante sentido, você percebe o bom senso no

estabelecimento dos critérios. Pontos de função, para quem faz concursos de TI

com frequência, merecem um estudo aprofundado pelo menos uma vez, para

depois ser apenas revisado antes de um concurso.

Gosto do livro do Adriano Vazquez, Análise de Pontos de Função. Ai ai ai,

quem me dera ganhar um extra pelo merchan!

Voltando à questão, e depois de entender as fórmulas, dá pra eliminar

todas as alternativas e ficar com a letra d). Continuemos na próxima página!



Prof. Victor Dalton


(FCC – Agente Fiscal de Rendas – Tecnologia da Informação - 2009)

Para responder as questões 32 e 33, considere os dados de referência

para os cálculos de pontos de função.

33ª Questão) Durante o levantamento de requisitos de um sistema, foram

apuradas as seguintes informações, base para o cálculo de pontos de função:

Complexidade de:

Entrada: 2 complexas, 4 médias e 5 simples.

Saída: 10 médias e 3 simples.

Arquivo mantido dentro da fronteira do sistema: 1 complexo e 2 médios.

Sem nenhuma influência, o resultado apurado foi

a) 133

b) 138

c) 140

d) 149

e) 161



Prof. Victor Dalton


Uma bela oportunidade de colocar em prática o conhecimento adquirido nas

questões teóricas anteriores, não?

Neste primeiro momento, não há muitas exigências. Você apenas precisa

pegar os valores correspondentes às complexidades nas tabelas e multiplicar

pelo número de ocorrências.

Entrada (EE) = 2x6 + 4x4 +5x3 = 43

Saída (SE) = 10x5 + 3x4 = 62

Arquivo mantido dentro da fronteira do sistema(ALI): 1x15 + 2x10 = 35

Total, 140 pontos de função, correspondendo à letra c).

33ª Questão) Mantida a pontuação bruta obtida na questão de número 32

e considerando que as influências por características gerais do sistema foram

estimadas como:

Forte em performance;

Significante em entrada de dados online e em processamento distribuído;

Demais características sem influência.

O resultado final mais aproximado, após o ajuste, foi

a) 98,0

b) 107,8

c) 110,6

d) 109,2

e) 116,0

Para fazer o cálculo do Fator de Ajuste (o VAF das fórmulas), você vai

precisar aplicar a fórmula VAF = (NI*0,01) + 0,65, mostrada no material que eu

te indiquei sobre APF (você leu?)

Caso não tenha lido, ou não se lembre, farei um rápido resumo.

Consideram-se 14 itens para o fator de ajuste, fornecidos para você nos

dados da questão.

Para cada um destes fatores, existe um nível de influência de 0 a 5,

também fornecidos na questão para você.

Então, faz-se necessário somar todos os níveis de influência dos itens,

multiplica-los por 0,01 e soma-los a 0,65. Mas por que isso?

O VAF, como você deve ter percebido nas fórmulas de cálculo da APF, pode

aumentar ou diminuir significativamente o valor dos pontos de função. Foi

estipulada uma margem de 35% para cima ou para baixo, na criação da

fórmula. Se todas as 14 características do sistema forem fortemente influentes,



Prof. Victor Dalton


14*5 será 70 e seu VAF será de 1,35. Em contrapartida, sendo nenhum item

influente, seu VAF será de 0,65.

Conseguiu captar? Não é um cálculo complexo, e em caso de cair na prova,

creio eu que todos os dados serão fornecidos a você, assim como na questão

que estamos trabalhando.

Aos cálculos:

1 influência forte (5) + 2 influências significantes (4) + demais sem

influência (0);

VAF = (13*0,01) + 0,65 = 0,78.

140 x 0,78 = 109,2. Se você trouxer o valor incorreto da questão anterior,

vai errar aqui também. Atenção!

Portanto, temos a letra d) como resposta correta.



Prof. Victor Dalton


CONSIDERAÇÕES FINAIS

Companheiros,

Encerramos a primeira de quatro aulas de exercícios. Espero, sinceramente,

que além de “decorar” o que eu estou passando através das questões, você

esteja rompendo o hiato entre o vocabulário que possui e o vocabulário de TI.

Compreender essa nova terminologia facilitará o aprendizado nas próximas

aulas.

Este, inclusive, é um dos motivos pelo qual optei por fazer um curso com

um número moderado de exercícios e com recomendação de teoria em paralelo.

Pra quem não é de TI, ler apenas uma apostila seca e 100% orientada a

concurso é uma tarefa perigosa. Leia a teoria nas fontes recomendadas, que

explica as coisas um pouco mais devagar. O risco de “branco” na hora da prova

é bem menor.

Nossa segunda aula já está no forno. Mantenha a pegada, pois é possível

entrar nas 100 vagas.

Estude!

Victor Dalton

Aula 01 (2)

Documents

Transcript of Aula 01 (2)