Aula 01 (2)
-
Upload
antonio-jailson-silveira -
Category
Documents
-
view
231 -
download
2
Transcript of 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
Questões Comentadas de TI para o ICMS-PR
Exercícios comentados Prof Victor Dalton – Aula 01
Prof. Victor Dalton
www.estrategiaconcursos.com.br 2 de 48
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.
Questões Comentadas de TI para o ICMS-PR
Exercícios comentados Prof Victor Dalton – Aula 01
Prof. Victor Dalton
www.estrategiaconcursos.com.br 3 de 48
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).
2ª Questão) (ESAF – Analista de Finanças e Controle –
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.
Questões Comentadas de TI para o ICMS-PR
Exercícios comentados Prof Victor Dalton – Aula 01
Prof. Victor Dalton
www.estrategiaconcursos.com.br 4 de 48
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
Questões Comentadas de TI para o ICMS-PR
Exercícios comentados Prof Victor Dalton – Aula 01
Prof. Victor Dalton
www.estrategiaconcursos.com.br 5 de 48
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
Questões Comentadas de TI para o ICMS-PR
Exercícios comentados Prof Victor Dalton – Aula 01
Prof. Victor Dalton
www.estrategiaconcursos.com.br 6 de 48
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.
Questões Comentadas de TI para o ICMS-PR
Exercícios comentados Prof Victor Dalton – Aula 01
Prof. Victor Dalton
www.estrategiaconcursos.com.br 7 de 48
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...
4ª Questão) (ESAF – Analista de Finanças e Controle –
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
Questões Comentadas de TI para o ICMS-PR
Exercícios comentados Prof Victor Dalton – Aula 01
Prof. Victor Dalton
www.estrategiaconcursos.com.br 8 de 48
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
Questões Comentadas de TI para o ICMS-PR
Exercícios comentados Prof Victor Dalton – Aula 01
Prof. Victor Dalton
www.estrategiaconcursos.com.br 9 de 48
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.
Questões Comentadas de TI para o ICMS-PR
Exercícios comentados Prof Victor Dalton – Aula 01
Prof. Victor Dalton
www.estrategiaconcursos.com.br 10 de 48
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
Questões Comentadas de TI para o ICMS-PR
Exercícios comentados Prof Victor Dalton – Aula 01
Prof. Victor Dalton
www.estrategiaconcursos.com.br 11 de 48
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.
Questões Comentadas de TI para o ICMS-PR
Exercícios comentados Prof Victor Dalton – Aula 01
Prof. Victor Dalton
www.estrategiaconcursos.com.br 12 de 48
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;
Questões Comentadas de TI para o ICMS-PR
Exercícios comentados Prof Victor Dalton – Aula 01
Prof. Victor Dalton
www.estrategiaconcursos.com.br 13 de 48
d)um requisito funcional e outro não-funcional;
e)requisitos não-funcionais.
Podemos seguir em frente?
10ª Questão) (ESAF – Analista de Planejamento e Orçamento –
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.
Questões Comentadas de TI para o ICMS-PR
Exercícios comentados Prof Victor Dalton – Aula 01
Prof. Victor Dalton
www.estrategiaconcursos.com.br 14 de 48
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.
Questões Comentadas de TI para o ICMS-PR
Exercícios comentados Prof Victor Dalton – Aula 01
Prof. Victor Dalton
www.estrategiaconcursos.com.br 15 de 48
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.
Questões Comentadas de TI para o ICMS-PR
Exercícios comentados Prof Victor Dalton – Aula 01
Prof. Victor Dalton
www.estrategiaconcursos.com.br 16 de 48
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:
Questões Comentadas de TI para o ICMS-PR
Exercícios comentados Prof Victor Dalton – Aula 01
Prof. Victor Dalton
www.estrategiaconcursos.com.br 17 de 48
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.
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.
Questões Comentadas de TI para o ICMS-PR
Exercícios comentados Prof Victor Dalton – Aula 01
Prof. Victor Dalton
www.estrategiaconcursos.com.br 18 de 48
e) Somente as afirmativas II, III e IV estão corretas.
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
Questões Comentadas de TI para o ICMS-PR
Exercícios comentados Prof Victor Dalton – Aula 01
Prof. Victor Dalton
www.estrategiaconcursos.com.br 19 de 48
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).
Questões Comentadas de TI para o ICMS-PR
Exercícios comentados Prof Victor Dalton – Aula 01
Prof. Victor Dalton
www.estrategiaconcursos.com.br 20 de 48
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.
Questões Comentadas de TI para o ICMS-PR
Exercícios comentados Prof Victor Dalton – Aula 01
Prof. Victor Dalton
www.estrategiaconcursos.com.br 21 de 48
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.
Questões Comentadas de TI para o ICMS-PR
Exercícios comentados Prof Victor Dalton – Aula 01
Prof. Victor Dalton
www.estrategiaconcursos.com.br 22 de 48
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).
18ª Questão) (ESAF – Analista de Planejamento e Orçamento –
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:
Questões Comentadas de TI para o ICMS-PR
Exercícios comentados Prof Victor Dalton – Aula 01
Prof. Victor Dalton
www.estrategiaconcursos.com.br 23 de 48
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
Questões Comentadas de TI para o ICMS-PR
Exercícios comentados Prof Victor Dalton – Aula 01
Prof. Victor Dalton
www.estrategiaconcursos.com.br 24 de 48
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.
Questões Comentadas de TI para o ICMS-PR
Exercícios comentados Prof Victor Dalton – Aula 01
Prof. Victor Dalton
www.estrategiaconcursos.com.br 25 de 48
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.
Assinale a alternativa correta.
a) Somente as afirmativas I e III estão corretas.
b) Somente as afirmativas III e IV estão corretas.
Questões Comentadas de TI para o ICMS-PR
Exercícios comentados Prof Victor Dalton – Aula 01
Prof. Victor Dalton
www.estrategiaconcursos.com.br 26 de 48
c) Somente as afirmativas I e II 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.
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).
Questões Comentadas de TI para o ICMS-PR
Exercícios comentados Prof Victor Dalton – Aula 01
Prof. Victor Dalton
www.estrategiaconcursos.com.br 27 de 48
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
Questões Comentadas de TI para o ICMS-PR
Exercícios comentados Prof Victor Dalton – Aula 01
Prof. Victor Dalton
www.estrategiaconcursos.com.br 28 de 48
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
Questões Comentadas de TI para o ICMS-PR
Exercícios comentados Prof Victor Dalton – Aula 01
Prof. Victor Dalton
www.estrategiaconcursos.com.br 29 de 48
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
Questões Comentadas de TI para o ICMS-PR
Exercícios comentados Prof Victor Dalton – Aula 01
Prof. Victor Dalton
www.estrategiaconcursos.com.br 30 de 48
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
Questões Comentadas de TI para o ICMS-PR
Exercícios comentados Prof Victor Dalton – Aula 01
Prof. Victor Dalton
www.estrategiaconcursos.com.br 31 de 48
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
Questões Comentadas de TI para o ICMS-PR
Exercícios comentados Prof Victor Dalton – Aula 01
Prof. Victor Dalton
www.estrategiaconcursos.com.br 32 de 48
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.
Assinale a alternativa correta.
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.
e) Somente as afirmativas II, III e IV 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.
Questões Comentadas de TI para o ICMS-PR
Exercícios comentados Prof Victor Dalton – Aula 01
Prof. Victor Dalton
www.estrategiaconcursos.com.br 33 de 48
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.
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.
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.
Questões Comentadas de TI para o ICMS-PR
Exercícios comentados Prof Victor Dalton – Aula 01
Prof. Victor Dalton
www.estrategiaconcursos.com.br 34 de 48
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
Questões Comentadas de TI para o ICMS-PR
Exercícios comentados Prof Victor Dalton – Aula 01
Prof. Victor Dalton
www.estrategiaconcursos.com.br 35 de 48
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
Questões Comentadas de TI para o ICMS-PR
Exercícios comentados Prof Victor Dalton – Aula 01
Prof. Victor Dalton
www.estrategiaconcursos.com.br 36 de 48
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:
Questões Comentadas de TI para o ICMS-PR
Exercícios comentados Prof Victor Dalton – Aula 01
Prof. Victor Dalton
www.estrategiaconcursos.com.br 37 de 48
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.
Assinale a alternativa correta.
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.
d) Somente as afirmativas I, II e IV estão corretas.
e) Somente as afirmativas II, III 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:
Questões Comentadas de TI para o ICMS-PR
Exercícios comentados Prof Victor Dalton – Aula 01
Prof. Victor Dalton
www.estrategiaconcursos.com.br 38 de 48
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.
a) Somente as afirmativas I e II estão corretas.
b) Somente as afirmativas I e III estão corretas.
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).
28ª Questão) (ESAF – Analista de Planejamento e Orçamento –
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
Questões Comentadas de TI para o ICMS-PR
Exercícios comentados Prof Victor Dalton – Aula 01
Prof. Victor Dalton
www.estrategiaconcursos.com.br 39 de 48
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.
Questões Comentadas de TI para o ICMS-PR
Exercícios comentados Prof Victor Dalton – Aula 01
Prof. Victor Dalton
www.estrategiaconcursos.com.br 40 de 48
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
Questões Comentadas de TI para o ICMS-PR
Exercícios comentados Prof Victor Dalton – Aula 01
Prof. Victor Dalton
www.estrategiaconcursos.com.br 41 de 48
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).
30ª Questão) (ESAF – Analista de Finanças e Controle –
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:
Questões Comentadas de TI para o ICMS-PR
Exercícios comentados Prof Victor Dalton – Aula 01
Prof. Victor Dalton
www.estrategiaconcursos.com.br 42 de 48
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:
Questões Comentadas de TI para o ICMS-PR
Exercícios comentados Prof Victor Dalton – Aula 01
Prof. Victor Dalton
www.estrategiaconcursos.com.br 43 de 48
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,
Questões Comentadas de TI para o ICMS-PR
Exercícios comentados Prof Victor Dalton – Aula 01
Prof. Victor Dalton
www.estrategiaconcursos.com.br 44 de 48
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!
Questões Comentadas de TI para o ICMS-PR
Exercícios comentados Prof Victor Dalton – Aula 01
Prof. Victor Dalton
www.estrategiaconcursos.com.br 45 de 48
(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
Questões Comentadas de TI para o ICMS-PR
Exercícios comentados Prof Victor Dalton – Aula 01
Prof. Victor Dalton
www.estrategiaconcursos.com.br 46 de 48
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,
Questões Comentadas de TI para o ICMS-PR
Exercícios comentados Prof Victor Dalton – Aula 01
Prof. Victor Dalton
www.estrategiaconcursos.com.br 47 de 48
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.
Questões Comentadas de TI para o ICMS-PR
Exercícios comentados Prof Victor Dalton – Aula 01
Prof. Victor Dalton
www.estrategiaconcursos.com.br 48 de 48
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