Questões de TI para o ICMS-SP 2013: Engenharia de Software e Gestão de Projetos

Questes Comentadas de TI para o ICMS-SP 2013- rea:
Tecnologia da Informao
Prof Victor Dalton Aula 00

Prof. Victor Dalton
www.estrategiaconcursos.com.br 1 de 82

AULA 00: Engenharia de Software

SUMRIO PGINA
Apresentao 1
Proposta de Trabalho 2
Cronograma 3
Mural do Aluno 4
Exerccios 5
Consideraes Finais 64
Lista de Exerccios 65
Gabarito 82

Antes de mais nada, peo que voc preste bastante ateno na nossa
PROPOSTA DE TRABALHO e nas CONSIDERAES FINAIS, para que voc tenha
a exata noo do nosso objetivo, ao realizar este curso em exerccios. Tenho
certeza que voc ir se debruar sobre o contedo, mas no deixe de observar
estes itens, em especial.

APRESENTAO

Ol a todos! E sejam bem-vindos ao projeto Questes Comentadas de TI
para Agente Fiscal de Rendas da Secretaria de Fazenda do Estado de So Paulo
(ICMS-SP/2013) Especialidade Tecnologia da Informao.
Permitam-me primeiro que eu me apresente.
Eu sou Victor Dalton Teles Jesus Barbosa. Minha experincia em concursos
comeou aos 15 anos, quando consegui ingressar na Escola Preparatria de
Cadetes do Exrcito, em 1999. Cursei a Academia Militar das Agulhas Negras,
me tornando Bacharel em Cincias Militares, 1 Colocado em Comunicaes, da
turma de 2003.
Em 2005, prestei novamente concurso para o Instituto Militar de
Engenharia, aprovando em 3 lugar. No final de 2009, me formei em Engenharia
da Computao, sendo o 2 lugar da turma no Curso de Graduao. Decidi ento
mudar de ares.
Em 2010, prestei concursos para Analista do Banco Central (rea 1
Tecnologia da Informao) e para Analista de Planejamento e Oramento
(Especializao em TI). Respectivamente, as bancas examinadoras foram a
Cesgranrio e ESAF.

Prof. Victor Dalton
Felizmente, fui aprovado nesses certames, e hoje, aps uma passagem
pelo Ministrio do Planejamento, optei por trabalhar no Banco Central do Brasil.
Ainda, recentemente, passei para o cargo de Analista Legislativo da Cmara dos
Deputados, cuja banca examinadora foi o CESPE, e estarei migrando para esta
Casa nos prximos dias.
Com esta feliz experincia em concursos pblicos, tive a honra de ser
convidado para o Estratgia Concursos. Elaborei o simulado de Auditoria de TI
para o concurso da CGU, e, uma vez aprovado, fui intimado a participar de
forma mais efetiva. Conheo a equipe do Estratgia, sei da competncia e da
capacidade desse pessoal, e estou me esforando para manter o gabarito dos
cursos aqui ministrados. J ministrei cursos para os concursos da Receita
Federal e para o ICMS-PR, cujo feedback dos alunos tem me impulsionado a
continuar cada vez mais a ministrar aulas.
PROPOSTA DE TRABALHO
A nossa proposta de trabalho apresentar questes de TI comentadas,
com total orientao para o concurso de Agente Fiscal de Rendas (ICMS-
SP/2013). Nosso objetivo, ao trmino desse curso, cobrir toda a matria de
Tecnologia da Informao do edital do certame.
Pois bem, e como alcanaremos este objetivo?
Semanalmente, traremos uma apostila, contendo em torno de 40
exerccios comentados abrangendo todo o edital, com nfase na FCC.
Contudo, tambm traremos exerccios de outras bancas, como ESAF, CESPE,
FGV, UEL e Cesgranrio, cujo contedo seja relevante, e tambm elaborarei
algumas questes, com o objetivo de chamar a ateno do futuro auditor para
alguns tpicos importantes, bem como despertar formas diferentes de enxergar
determinado assunto. Tudo isso, claro, com o objetivo de melhor capacit-lo
para a prova. Atualmente, o curso j contm 314 questes, e certamente
ultrapassar 400 questes comentadas. Que tal?
Ainda, agregarei a este curso outro diferencial: irei divulgar diversas
fontes online e livros para que voc possa reforar seus estudos. A Tecnologia
da Informao, com certeza, a matria cuja bibliografia ideal para concursos
pblicos no consolidada, e, inclusive, motivo de divergncias entre estudiosos
do assunto. Por isso, desde o incio do curso, postarei no Mural do Aluno
diversos links cujo contedo eu considere relevante, alm de vrias indicaes
de livros e comentrios sobre os mesmos (pois os tenho comigo). A web possui
muito lixo eletrnico, e at mesmo os mais ntimos do ramo correm o risco de
estudarem por fontes inadequadas. Usarei minha experincia e meu
conhecimento para direcion-lo pelo caminho certo. De certa forma, estas
indicaes funcionaro como uma consultoria.

Vamos l?

Prof. Victor Dalton
CRONOGRAMA

Nosso cronograma trar os exerccios na seguinte sequncia:

Aula 00 (29/10/2012) Engenharia de Software: Ciclo de vida do
software. Processos de Desenvolvimento de Software. Gerncia de
Requisitos de Software: Conceitos de Requisitos. Requisitos Funcionais
e No-Funcionais. Gerncia de Configurao e Mudana. Conceitos de
Gerncia de Configurao e Mudana de Software. Solicitaes de
Mudana.Testes e Avaliao de Qualidade de Software: Conceitos.
Documentos de Teste.

Aula 01 (01/11/2012) Gesto e Governana de TI: Planejamento Estratgico.
Alinhamento entre estratgias de tecnologia da informao e de negcio:
conceitos e tcnicas. Gerncia de Projetos: Conceitos Bsicos. Processos do
PMBOK. Planejamento e controle de mtricas de projeto. Planejamento e
avaliao de iteraes. CMMI (verso 1.2): conceitos e formas de representao.
Disciplinas e Processos.

Aula 02 (09/11/2012)Gerncia de servios de TI: Fundamentos da ITIL
(verso 3). Fundamentos de CobiT (verso 4.1). Service desk. Conhecimentos
sobre norma ISO/IEC 20000. MPS/Br. Anlise por Pontos de Funo. Processo
unificado(RUP): disciplinas, fases, papis e atividades.

Aula 03 (13/11/2012) Vrus de computador: tipos de vrus, danos causados
por vrus, antivrus, cavalo de tria, Spoofing, Phishing e negao de servio.
Criptografia, assinatura digital e autenticao: conceitos bsicos de criptografia,
sistemas criptogrficos simtricos e assimtricos, PKI (infraestrutura de chaves
pblicas), assinatura e certificao digital, protocolos criptogrficos,
caractersticas do RSA, DES, 3DES, e AES, das funes hash, e do MD5 e SHA-1.
Conhecimentos sobre norma ISO 27001.

Aula 04 (16/11/2012) Redes: Conceito de rede. Tipos e meios de
transmisso. Topologias de redes de computadores. Arquitetura de rede.
Elementos de interconexo de redes de computadores (hubs, bridges, switches,
roteadores, gateways). Noes de Sniffing. Arquitetura e protocolos de redes de
comunicao: modelo de referncia OSI e arquitetura TCP/IP. Acesso remoto e
Rede Wireless. Noes de administrao de redes. Noes de mobilidade.

Aula 05 (20/11/2012) Bancos de dados: Conceitos Bsicos. Conceitos de
desenvolvimento em bancos de dados SQL Server e Oracle. Modelagem de
Dados Relacional. Business Intelligence: Modelagem de Dados Multidimensional.

Prof. Victor Dalton
Conceitos de Datawarehouse, e ETL. Modelagem e otimizao de bases de dados
multidimensionais. Conceitos de Data Mining.

Aula 06 (24/11/2012) Programao de Sistemas: Fundamentos de lgica de
programao, estrutura de dados e arquivos. Paradigmas de programao:
programao estruturada, programao orientada a objetos. Linguagem de
programao Java: conceitos bsicos e aplicaes. Arquitetura de Software:
Conceitos Bsicos, Arquitetura em Camadas. Arquitetura Orientada a Servios
(SOA). Portais Corporativos e Colaborativos. Web Services.

Aula 07 (02/02/2013) Gesto de Processos de Negcio: Modelagem de
processos. Tcnicas de anlise de processo. Conceitos de Arquitetura
Corporativa (TOGAF). BPM (Business Process Management) e gerenciamento
eletrnico de documentos. Planejamento estratgico de TI (PETI). Anlise SWOT.
BSC Balanced Scorecard. Responsabilidade e papis de TI. Processos de
definio, implantao e gesto de polticas organizacionais. Gesto de riscos.

Aula 08 (16/02/2013) Sistemas Operacionais: Conceitos de administrao de
servidores em plataforma Windows. Conceitos de administrao de servidores
em plataforma Linux. Conceitos de virtualizao. Active Directory. Auditoria de
TI: controles internos, procedimentos de controles internos gerais e aplicados
TI. Vulnerabilidade e conformidade. Backup e recuperao de dados.

MURAL DO ALUNO
Observao: O contedo presente neste trecho, a partir das prximas
aulas, somente estar presente no Mural do Aluno, e no nas apostilas.

Engenharia de Software um dos ramos da TI cuja bibliografia talvez seja
a mais consolidada. Dois so os autores referncia, tanto para aprender
Engenharia de Software quanto para concursos: Pressman e Sommerville.
Se eu fosse indicar apenas um livro, indicaria Pressman, Engenharia de
Software: Uma Abordagem Profissional, atualmente em sua stima edio,
no Brasil. Pressman mais adotado para a parte de Modelos de Processo,
Qualidade de Software e Teste de Software.
J na parte de Engenharia de Requisitos e Mtricas de Software, vejo um
meio a meio entre Pressman e Sommerville, Engenharia de Software.
Inclusive, vrias bancas adotam ambas as propostas dos autores, cobrando-as
simultaneamente em prova. Portanto, quem puder se dar ao luxo de ter os dois
livros, vale a pena adquirir ambos.

Prof. Victor Dalton
No livro do Pressman, interessante ler toda a Parte 1, captulos 5 e 6 da
Parte 2, captulos 14, 15, 16, 17 e 23 da Parte 3. Existem outros captulos
interessantes, que complementam outras matrias de TI. Sero citados em
outras aulas.
Quem tem o Sommerville deveria ler os captulos 4, 6, 7, 11, 13, 14, 17,
18, 19, 22, 23, 27 e 29. Outros captulos tambm complementam outras
matrias.
Temos abaixo, um link quebra-galho para ES:
http://conhecimentovaleouro.blogspot.com.br/2011/08/engenharia-de-
software-de-roger-s.html
Testes de software tambm pode ser visto aqui:
http://tcclatex.googlecode.com/svn/trunk/infra/material/10/ES_Rodolfo_VI
I_Teste.pdf
http://pt.wikipedia.org/wiki/Teste_de_software
Para o estudo da UML, eu recomendo o livro Princpios de Anlise e Projeto
de Sistemas com UML, do Eduardo Bezerra. um livro bastante completo e fcil
de entender. Captulos 1, 2, 4, 5, 7, 8, 9, 10 e 11 so interessantes
(praticamente o livro todo).
Ainda, achei um trabalho da PUC muito interessante sobre Scrum:
ftp://ftp.inf.puc-rio.br/pub/docs/techreports/09_07_varaschim.pdf
Lembro, ainda, que o Mural do Aluno pode ser constantemente atualizado,
com novas dicas e informaes, medida que novas boas fontes apaream.

EXERCCIOS

1 Questo) (ESAF Analista de Finanas e Controle
Desenvolvimento de Sistemas da Informao - 2008) A Engenharia de
Software uma disciplina da engenharia que se ocupa de todos os aspectos da
produo de software, desde os estgios iniciais de especificao do sistema at
a manuteno do mesmo. A Engenharia de Software adota mtodos de
engenharia de software que
a) so um conjunto de atividades, cuja meta o desenvolvimento ou a
evoluo do software.
b) so uma representao simplificada de um processo de software,
apresentada a partir de uma perspectiva especfica.

Prof. Victor Dalton
c) so abordagens estruturadas para o desenvolvimento de software, que
incluem modelos de sistemas, notaes, regras, recomendaes 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 comear pela definio!

Engenharia de software uma rea da computao voltada especificao,
desenvolvimento e manuteno de sistemas de software, com aplicao de
tecnologias e prticas de gerncia de projetos e outras disciplinas, visando
organizao, produtividade e qualidade.
Os fundamentos cientficos 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. Alm disso, a engenharia de software adota mtodos de
engenharia de software que so abordagens estruturadas para o
desenvolvimento de software, que incluem modelos de sistemas, notaes,
regras, recomendaes de projetos e diretrizes de processos.

Nossa resposta certa a letra c).

Desenvolvimento de Sistemas da Informao - 2012) A escolha de um
modelo fortemente dependente das caractersticas do projeto. Os principais
modelos de ciclo de vida podem ser agrupados em trs 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 comeo da Engenharia de Software.
Estas classificaes variam muito entre autores. Entretanto, esta a mais
recente cobrada em concursos, e muito prxima da adotada por sua fonte
recomendada para estudos. Vejamos:
Modelos sequenciais: so os modelos moda antiga, como o modelo em
cascata e o modelo em V. Nestes modelos, uma fase s comea aps o trmino
da outra. um modelo meio ultrapassado de desenvolver software.

Prof. Victor Dalton

Modelo em Cascata

Modelo em V

Modelos incrementais: onde se enquadram o prprio modelo incremental e
o RAD (Rapid Application Development). Partem do princpio que a cada ciclo
uma verso operacional do sistema ser produzida e entregue ao cliente para
uso ou avaliao detalhada.

Modelo Incremental


Prof. Victor Dalton

RAD
Modelos evolutivos uma forma de desenvolvimento na qual o software
desenvolvido em ciclos, e a cada ciclo novas funcionalidades so incrementadas
ao sistema. Enquadram-se aqui o modelo espiral e a prototipao.

Modelo em espiral

Prototipao

Prof. Victor Dalton
Observe que interessante: na definio de modelos incrementais falamos
em ciclo, e na definio 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 no lhe diga muita coisa, mas a grande verdade que voc
est aqui para acertar questes na prova, e no pra tirar um diploma de Doutor
em Engenharia de Software. No verdade? E o Pressmann um autor de
renome, no sendo incomum suas definies aparecerem Ipsis Literis em
questes de concursos. Na hora da prova, dance conforme a msica. Voc vai
me ouvir falar isso mais de uma vez nessa apostila.

Resposta certa, alternativa c).

3 Questo) (ESAF Analista de Planejamento e Oramento
Tecnologia da Informao - 2010) As atividades do modelo espiral de
Engenharia de Software so:
a) Planejamento, Anlise dos Componentes, Anlise de Hierarquia e
Avaliao feita pelo cliente.
b) Planejamento, Anlise dos Riscos, Engenharia e Avaliao feita pelo
cliente.
c) Projeto, Anlise dos Benefcios, Engenharia e Avaliao feita pelo gestor.
d) Planejamento, Eliminao dos Riscos, Anlise de Contingncia e
e) Planejamento, Projeto, Anlise dos Riscos e Engenharia.

Se voc prestou bem ateno na figura do modelo em espiral, na pgina
anterior, vai ficar em dvida para responder esta questo. 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 no. Entretanto, um senso
comum entre os autores sobre o modelo espiral o reconhecimento explcito do
risco, e a entrega para o cliente validar, aceitar, verificar... etc. E, pessoal, no
brincadeira: se voc sair pesquisando no Google, vai achar umas 10 espirais
diferentes, sem exagero! A prpria espiral do Pressmann (reconhecidamente, o
grande autor em Engenharia de Software), que dividida em Planejamento,
Modelagem, Construo, Emprego e Comunicao, no lhe habilitaria a
responder esta questo.
Ah, Victor e por que voc no nos passa a espiral padro, aquela que as
bancas sempre cobram?
Porque se eu ou algum lhe prometer essa espiral estar mentindo pra
voc. Logo, meu objetivo lhe preparar da melhor forma para o que pode vir
pela frente.

Prof. Victor Dalton
Pesquisando na internet, achei um autor que afirma que o modelo em
espiral possui as seguintes etapas: Comunicao com o cliente, planejamento,
anlise de riscos, engenharia, construo e liberao, e avaliao com o cliente.
Foi o conceito mais prximo da alternativa correta da ESAF, a letra b). Se
fssemos por eliminao, ficaramos entre a b) e a e), pelo menos.
J falei em danar conforme a msica? Pois , acho que vou ser muito
repetitivo nesta apostila...

4 Questo) (FCC Ministrio Pblico do Estado do Rio Grande do
Norte Analista de Tecnologia da Informao Especialidade Engenharia
de Software/Desenvolvimento de Sistemas - 2010) No modelo de
desenvolvimento de software em espiral, cada loop na espiral representa
a) a necessidade de retornar ao incio da fase em que se encontra.
b) um processo de reengenharia.
c) uma disciplina de software.
d) uma fase do processo de software.
e) uma atividade paralela.

Segundo Pressman, o primeiro circuito em volta da espiral pode resultar
no desenvolvimento de uma especificao de produto; passagens subsequentes
em torno da espiral podem ser usadas para desenvolver um prottipo, e, ento,
progressivamente, verses cada vez mais sofisticadas do software.

Desse modo, percebemos que a nica alternativa aplicvel a letra d).
Veremos, ao longo do curso, que a FCC gosta muito de questes de raciocnio,
alternadas com questes de simples definio de conceitos.

Norte - Analista de Tecnologia da Informao Especialidade
Engenharia de Software/Desenvolvimento de Sistemas - 2010) O modelo
em espiral difere principalmente dos outros modelos de processo de software por
a) no contemplar o prottipo.
b) reconhecer explicitamente o risco.
c) no ter fases.
d) possuir uma fase nica evolucionria.
e) no contemplar o projeto do produto.

Esta questo didtica por mostrar exatamente o ponto comum entre os
autores, ao tratarem do modelo em espiral. Lembra que eu expliquei isso
questes atrs?

Resposta certa, alternativa b).


Prof. Victor Dalton
6 Questo) (FCC Companhia do Metropolitano de So Paulo -
Analista Desenvolvimento Gesto Jnior Cincias da Computao -
2012) O processo de desenvolvimento em cascata um exemplo de processo
dirigido a planos, pois, em princpio, necessrio planejar e programar todas as
atividades do processo antes de comear a trabalhar nelas. So exemplos de
estgios desse modelo:
a) Integrao de Produto, Definio de Processo Organizacional e
Gerenciamento de Riscos.
b) Anlise e Definio de Requisitos, Implementao de Teste Unitrio e
Integrao e Teste de Sistema.
c) Inicial, Gerenciado e Em Otimizao.
d) Engenharia de Requisitos, Ciclo de Vida de Projetos e Gesto de
Incidentes.
e) Acompanhamento e Controle de Projeto, Medio e Anlise e
Desenvolvimento de Requisitos.

Detalhando o modelo em cascata:

Anlise e Definio de Requisitos Os servios, restries e objetivos do
sistema so definidos por meio de consulta aos usurios do sistema. Eles so,
portanto, definidos detalhadamente e servem como uma especificao 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
arquitetura geral do sistema. O projeto de software envolve a identificao e a
descrio das abstraes fundamentais do sistema de software e suas relaes.
Implementao e teste de unidade Durante esse estgio, o projeto de
software realizado como um conjunto de programas ou unidades de programa.
O teste unitrio envolve a verificao de que cada unidade atende sua
especificao.
Integrao e testes de sistema As unidades individuais de programa ou
os programas so integrados e testados como um sistema completo para
garantir que os requisitos de software foram atendidos. Aps os testes, o
sistema de software liberado para o cliente.
Operao e manuteno Geralmente (embora no necessariamente) esta
a fase mais longa do ciclo de vida. O sistema instalado e colocado em
operao. A manuteno envolve a correo de erros no detectados nos
estgios anteriores ao ciclo de vida, no aprimoramento da implementao das
unidades de sistema e na ampliao dos servios de sistema medida que
novos requisitos so identificados.

O segredo para acertar a questo conhecer bem os nomes das etapas,
para no ser ludibriado pelas alternativas. Pela explicao da etapa, que consta
do enunciado, no cabe marcar outra alternativa que no seja a letra b).


Prof. Victor Dalton
P.S.:Apenas para desencargo de conscincia, Pressman, na ltima edio
de seu livro, renomeou as etapas do modelo em cascata. Nunca vi cobrana
dessa nova nomenclatura em provas, mas segue, de brinde, pra voc.

2012) A engenharia de software baseada em reuso uma estratgia da
engenharia em que o processo de desenvolvimento orientado para o reuso de
softwares existentes. Dentre os benefcios do reuso de software, INCORRETO
afirmar:
a) Preencher uma biblioteca de componentes reusveis e garantir que
desenvolvedores de software possam utilizar essa biblioteca so aes no
onerosas, pois processos de desenvolvimento no precisam ser adaptados para
utilizar essa biblioteca.
b) Devido ao custo do software existente j ser conhecido, o risco de
processo reduzido.
c) Especialistas em aplicaes podem desenvolver softwares reusveis que
encapsulem seu conhecimento, tornando seu uso mais eficaz.
d) Muitas vezes os custos gerais de desenvolvimento no so to
importantes quanto entregar um sistema ao mercado o mais rpido possvel. O
reuso de um software pode acelerar a produo do sistema.
e) Alguns padres, como os de interface de usurio, podem ser
implementados como um conjunto de componentes reusveis. O uso de
interfaces de usurio-padro melhora a confiana, pois os usurios cometem
menos erros quando so apresentados a interfaces familiares.

Reuso de software faz parte da Engenharia de Software baseada em
componentes. No muito explorada na bibliografia, e as definies contidas
entre as alternativas b) e e) so bom subsdio terico. A alternativa a)
facilmente detectada como falsa, uma vez que montar uma biblioteca de
componentes reusveis para utilizao por parte de desenvolvedores certamente
uma tarefa onerosa.

8 Questo) (ESAF Agncia Nacional de guas Analista de
Sistemas 2009) Analise as seguintes afirmaes sobre requisitos de sistemas
de software:

Prof. Victor Dalton
I. Requisitos funcionais declaram as funes que o sistema deve fornecer,
seu comportamento, e ainda, o que o sistema no deve fazer.
II. Requisitos de domnio so, exclusivamente, funcionais, pois exibem as
caractersticas do domnio de aplicao do sistema.
III. Requisitos no-funcionais compreendem restries sobre servios ou
funes do sistema.

Assinale a opo correta.

a) Apenas as afirmaes I e II so verdadeiras.
b) Apenas as afirmaes I e III so verdadeiras.
c) Apenas as afirmaes II e III so verdadeiras.
d) As afirmaes I, II e III so verdadeiras.
e) Nenhuma das afirmaes verdadeira.

O conceito de requisito, na Engenharia de Software refere-se definio de
uma caracterstica, atributo, habilidade ou qualidade que um sistema deve
necessariamente prover para ser til a seus usurios. Creio que, a esta altura do
campeonato, isso no seja mais novidade para voc. Contudo, os requisitos
podem ser classificados de diversas formas. A saber:
Requisito funcional: Define uma funo de um sistema de software ou seu
componente. Uma funo descrita como um conjunto de entradas, seu
comportamento e as sadas. Os requisitos funcionais podem ser clculos,
detalhes tcnicos, manipulao de dados e de processamento e outras
funcionalidades especficas que definem o que um sistema, idealmente, ser
capaz de realizar. Em suma, dizem o que o sistema deve fazer, mas tambm
pode ser uma declarao explcita do que o sistema no deve fazer. Ex: o
usurio deve ser capaz de pesquisar todos os livros da biblioteca, o usurio
no pode cautelar dois exemplares do mesmo livro.
Requisito no-funcional: o requisito relacionado ao uso da aplicao em
termos de desempenho, usabilidade, confiabilidade, segurana, disponibilidade,
manutenibilidade e tecnologias envolvidas. Em geral, requisitos no-funcionais
podem constituir restries aos requisitos funcionais e no preciso o cliente
dizer sobre eles, pois eles so caractersticas mnimas de um software de
qualidade, ficando a cargo do desenvolvedor optar por atender esses requisitos
ou no. Ex: o sistema deve suportar o uso simultneo por cem usurios, sem
apresentar lentido ou perda de performance.
Requisito de domnio: um requisito proveniente do domnio da aplicao
do sistema e que reflete as caractersticas e as restries desse domnio. Pode
acabar produzindo requisitos funcionais ou no funcionais. Ex: esse aplicativo
dever ser executado tanto em IPhone quanto em celulares Android. um
requisito de domnio que demandar uma srie de requisitos funcionais e no
funcionais em cada plataforma a ser desenvolvido o sistema.
Requisito de usurio: O requisito de usurio de um sistema deve descrever
os requisitos funcionais e no funcionais de modo que ele seja compreensvel

Prof. Victor Dalton
pelos usurios do sistema que no possuem conhecimento tcnico detalhado.
Eles devem especificar apenas o comportamento externo do sistema e evitar,
sempre que possvel, descrever caractersticas de projeto do sistema. Os
exemplos de requisitos funcionais que eu passei so bons exemplos de requisitos
de usurio.
Requisito de sistema: uma verso expandida do requisito de usurio,
usado pelos engenheiros de software como ponto de partida para o projeto do
sistema. Podem ser escritas em linguagem natural e/ou linguagens de notao
de projetos e notaes grficas. Por exemplo: Uma chamada a um arquivo
externo no dever repassar parmetros a esse arquivo. O tratamento das
variveis dever se local.
Especificao de interface (ou de projeto): uma especificao tcnica 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 explanao, voltemos aos itens da questo:
I. Correta;
II.Errada, pois os requisitos de domnio podem ser tambm no-funcionais;
III.Correta. Um requisito no-funcional pode afetar um requisito funcional.
Ex:Um sistema que opere em uma mquina que no permita a insero de
pendrives pode restringir o salvamento de arquivos neste tipo de mdia,
permitindo apenas o envio de dados pela internet;

Logo, nossa resposta certa a letra b).

(FCC Agente Fiscal de Rendas Tecnologia da Informao - 2009)
Para responder as questes de 9 e 10, considere:

necessrio que o software calcule os salrios dos diaristas e mensalistas
e emita relatrios mensais sumariados por tipo de salrio. Entretanto, a base de
dados deve estar protegida e com acesso restrito aos usurios autorizados. De
qualquer forma, o tempo de resposta das consultas no deve superar os quinze
segundos, pois inviabilizaria todo o investimento nesse sistema. Devo lembrar
que os relatrios individuais dos departamentos, nos quais constam os salrios
dos funcionrios, devem ser emitidos quinzenalmente em razo dos
adiantamentos e vales que recebem. fundamental que o software seja
operacionalizado usando cdigo aberto.
Necessito, ainda, forte gerenciamento de risco, prazo e custo, porque a
entrega do produto final no pode ultrapassar o prazo de oito meses a contar da
data de incio do projeto.


Prof. Victor Dalton
A frase acima, expressa por um funcionrio do cliente, aborda alguns
requisitos de software especificados para um sistema de gesto de pessoal.

9 Questo) No texto, so requisitos no-funcionais:

a) no pode ultrapassar o prazo de oito meses e necessrio que o software
calcule os salrios dos diaristas e mensalistas.
b) os relatrios individuais dos departamentos, nos quais constam os
salrios dos funcionrios, devem ser emitidos quinzenalmente e em razo dos
adiantamentos e vales que recebem.
c) fundamental que o software seja operacionalizado usando cdigo
aberto e os relatrios individuais dos departamentos, nos quais constam os
salrios dos funcionrios, devem ser emitidos quinzenalmente.
d) tempo de resposta das consultas no deve superar os quinze segundos e
entrega do produto final no pode ultrapassar o prazo de oito meses.
e) pois inviabilizaria todo o investimento nesse sistema e em razo dos

Definimos requisitos no-funcionais como requisitos relacionados ao uso
da aplicao em termos de desempenho, usabilidade, confiabilidade, segurana,
disponibilidade, manutenibilidade e tecnologias envolvidas. Vejamos os itens:

a) fala em clculo de salrios. Errada;
b) fala em emisso de relatrios. Errada;
c) idem b). Errada;
d) tempo de resposta de consultas e prazo para entrega. Certa!
e) item nonsense. Errada.

Mesmo que voc no estivesse confiante em marcar a alternativa d),
seria possvel trabalhar por eliminao.

10 Questo) No texto, so requisitos funcionais:

a) calcule os salrios dos diaristas e mensalistas e os relatrios individuais
dos departamentos, nos quais constam os salrios dos funcionrios, 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 usurios autorizados.
aberto e emita relatrios mensais sumariados por tipo de salrio.
d) emita relatrios mensais sumariados por tipo de salrio e Necessito,
ainda, forte gerenciamento de risco, prazo e custo.
e) a base de dados deve estar protegida e com acesso restrito aos usurios
autorizados e entrega do produto final no pode ultrapassar o prazo de oito
meses.

Prof. Victor Dalton

De cara, a alternativa a) j parece correta. Vejamos as demais.
b)apenas requisitos no funcionais;
c)um requisito no-funcional e um funcional;
d)um requisito funcional e outro no-funcional;
e)requisitos no-funcionais.

Podemos seguir em frente?

Tecnologia da Informao 2008) Os requisitos de um sistema so
descries dos servios fornecidos pelo sistema e as suas restries
operacionais. Indique a opo que corretamente se relaciona com a anlise ou
gerenciamento de requisitos.
a) Requisitos de sistema so declaraes do usurio que definem,
detalhadamente, as funes, os servios e as restries operacionais do sistema.
b) As representaes de dados usadas nas interfaces de sistemas so
exemplos de requisitos funcionais.
c) A exigncia de que o sistema deva fornecer telas apropriadas para o
usurio ler os documentos no repositrio de documentos um exemplo de
requisito funcional.
d) A exigncia de que o sistema no deva revelar quaisquer informaes
pessoais sobre os usurios do sistema ao pessoal de vendas que o utiliza, com
exceo do nome e cargo, um exemplo de requisito funcional.
e) Avaliar se os requisitos associados ao desempenho, ao comportamento e
s caractersticas operacionais do sistema foram explicitamente declaradas
uma tarefa de especificao de requisitos.

Vamos analisar as alternativas com o conhecimento j adquirido?
a) Descreve o que so requisitos de usurio. Errada;
b) Especificaes de interface. Errada;
c) Correta;
d) Requisito no-funcional, pois est relacionado segurana da aplicao.
Errada;
e) Tarefa da validao de requisitos, mas este contedo ser visto mais
adiante. Errada;

Espero que voc j esteja dominando este tpico. Alternativa c).

12 Questo) (Formulao pessoal) uma tcnica de elicitao de
Requisitos:

Prof. Victor Dalton
a) Entrevista com stakeholder, por meio de formulrios predefinidos
(entrevista fechada) ou no (entrevista aberta). Por meio dela procura-se saber
o que o interessado espera ou deseja no sistema.
b) Descrio de cenrios, na qual comea-se com um esboo da interao
e, durante a elicitao, adicionam-se detalhes para uma descrio completa
dessa interao.
c) Elaborao de casos de uso, que so cenrios descritos em um diagrama
UML, visual, tambm discutidos com os interessados.
d) Etnografia, que uma tcnica na qual o analista insere-se no ambiente
de trabalho como um observador, procurando levantar os requisitos do sistema.
e) Todas as alternativas esto corretas.

A cobrana em provas acerca de tcnicas de elicitao de requisitos
rarssima, apesar de comumente aparecer em editais de concursos. Elicitar
requisitos nada mais do que descobrir, elucidar os requisitos. Todas as
tcnicas acima so tcnicas de elicitao de requisitos. Perceba que nada mais
so do que formas prticas de procurar saber dos interessados o que eles
esperam do sistema que esto solicitando.

Utilize a questo como subsdio de contedo. Alternativa e).

de Software/Desenvolvimento de Sistemas - 2010) Na engenharia de
software, etnografia
a) uma fase do processo de software aplicada no modelo em cascata.
b) uma fase do processo de software aplicada no modelo em espiral.
c) uma tcnica de observao que pode ser usada para compreender os
requisitos sociais e organizacionais.
d) uma tcnica aplicada na engenharia de requisitos cujo objetivo definir,
a priori, as classes que contm elementos grficos (BLOB).
e) um projeto cujo principal objetivo criar interfaces grficas, que
facilitam o acesso do usurio (GUI).

Exemplo tpico da FCC que exige, simplesmente, que voc conhea uma
definio. Alternativa c).

14 Questo) (FCC Agente Fiscal de Rendas Tecnologia da
Informao - 2009) Quanto aos requisitos de software, considere:

I. importante que se estabeleam prticas para encontrar, documentar,
organizar e rastrear os requisitos variveis de um sistema.

Prof. Victor Dalton
II. Etnografia (observao e anlise dos fluxos de trabalho) e sesses de
JAD so prticas que podem ser aplicadas na elicitao.
III. Elicitar significa descobrir os requisitos de um sistema por meio de
entrevistas, de documentos do sistema existente, de anlise do domnio 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 ento, acredito que sua nica
dvida na questo a respeito de JAD. Vamos l:

O JAD (Joint Application Design) uma tcnica de levantamento interativo,
criada por dois profissionais da IBM do Canad na dcada de 1970 onde, em
uma ou mais sesses, so reunidos todos os interessados no assunto para tomar
as decises sobre o mesmo. A tcnica tem uma abordagem voltada para o
trabalho em equipe e visa definir um modelo de soluo de problemas baseado
em consenso.

A dinmica do JAD: So feitas reunies participativas, chamadas de
sesses, envolvendo representantes de todas as reas relacionadas com os
assuntos em discusso.

As regras da sesso:

Todos os participantes so iguais. Nas sesses JAD, a estrutura
hierrquica e de poder so deixadas do lado de fora. Todas as posies
tem o mesmo peso e sero avaliadas pelo grupo sem levar em conta qual
a origem da mesma.
Apenas uma pessoa fala de cada vez. Assim todos tero chance de
expressar a sua opinio e de ouvir as opinies do restante do grupo.
Todas as opinies so vlidas. preciso no ter uma posio pr-
concebida sobre as opinies dadas.
Hora para comear, interromper e terminar. necessrio definir uma
agenda para as sesses e cumpri-la risca.
Celular desligado. Durante a sesso no devem acontecer interrupes
externas.
Recursos visuais. Utilizar intensivamente recursos visuais para tornar o
projeto do sistema mais palpvel e permitir que ele seja entendido pelos

Prof. Victor Dalton
diversos participantes. Uma fotografia mais explicativa e rica em
detalhes do que 1000 palavras para a descrio de um fato.

Os papis na sesso:

Sponsor (Patrocinador). o executivo responsvel pelo projeto, o dono
do sistema. Ele precisa ter autonomia para tomar decises, definir
estratgias e direcionar o trabalho.
Facilitador. o responsvel por conduzir a sesso. Ele no precisa ser
um especialista no assunto que est sendo tratado. Ele dever estar
focado em organizar a dinmica, dando a palavra a cada participante,
obtendo o consenso sobre os assuntos tratados, organizando o registro
das decises e intermediando os conflitos.
Escriba. a pessoa responsvel por registrar todas as discusses e
decises em um local que todos possam visualizar, como um quadro ou
flip-chart.
Documentador. o responsvel por registrar todas as decises em um
documento formal, como uma ata de reunio ou uma especificao de
requisitos, que ser assinado por todos ao final das sesses.
Especialistas. So as pessoas que tem conhecimento do assunto que
est sendo discutido e que podem efetivamente contribuir para a
discusso e na tomada de decises.
Observadores. So pessoas que esto na sesso apenas para conhecer
mais do assunto que est sendo tratado ou para assimilar a tcnica da
reunio. Os observadores no podem se manifestar durante a sesso.

Os fatores de sucesso:

Prof. Victor Dalton

A sesso precisa ter presente as pessoas que tem poder de deciso sobre
o assunto tratado, pois, no adianta tomar decises durante a reunio que
podero ser contestadas quando todos voltarem para o escritrio.
As decises precisam ser tomadas por consenso, pois, todos os
participantes da sesso precisam sair de l comprometidos com as
definies registradas.
As sesses devem ocorrer fora do ambiente de trabalho dos participantes
para evitar interrupes e prevenir que os participantes se vejam tentados
a tratar de assuntos ligados a sua rotina diria.
No deixar que os participantes imponham suas opinies em funo do
seu nvel hierrquico, para evitar que pessoas de nvel hierrquico mais
baixo fiquem constrangidas em debater ou discordar.
Definir claramente qual ser o produto gerado no final das sesses.

Os benefcios esperados em relao aos mtodos tradicionais:

Maior produtividade. Estudos relatam aumentos de 20 a 60% na
produtividade, em relao aos mtodos tradicionais.
Maior qualidade. Usurios e analistas de sistemas costumam citar projeto
de softwares de alta qualidade como sendo o maior benefcio do mtodo.
Trabalho em equipe. Promove o esprito de cooperao, entendimento e
trabalho em equipe.
Custos mais baixos. O projeto de alta qualidade, obtido atravs do JAD,
possibilita uma grande economia de tempo e dinheiro mesmo aps a
entrega do sistema.

Bem, apesar de parecer mais com uma reunio do AA (no que eu j tenha
ido em uma, rs), voc pde notar que o JAD tambm uma tcnica de Elicitao
de requisitos.

Assim sendo, todos os itens esto corretos e nossa alternativa certa a
letra c).

15 Questo) (UEL Secretaria do Estado da Administrao e da
Previdncia 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 caractersticas antes da
Implementao. seu papel realizar a interao entre o que deve ser feito e
como deve ser feito.
Esta afirmao refere-se a:

a) Arquitetura do Software.
b) Planejamento do Software.

Prof. Victor Dalton
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 vo trabalhar para resolver. Ela inclui
o conjunto de tarefas que levam a um entendimento de qual ser o impacto do
software sobre o negcio, do que o cliente quer e de como os usurios finais vo
interagir com o software. Seu objetivo fornecer a todas as partes um
entendimento escrito do problema.

Resposta certa, letra c).

16 Questo) (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 estgio de levantamento e anlise dos requisitos, os membros da
equipe tcnica de desenvolvimento do software trabalham com o cliente e os
usurios finais do sistema para descobrir mais informaes sobre o domnio da
aplicao, que servios o sistema deve fornecer, o desempenho exigido do
sistema, as restries de hardware, entre outras informaes.

III. Na medida em que a informao de vrios pontos de vista coletada,
os requisitos emergentes so consistentes.

IV. A validao de requisitos se ocupa de mostrar que estes realmente
definem o sistema que o cliente deseja. Ela importante porque a ocorrncia 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 esto corretas.
b) Somente as afirmativas I e III esto corretas.
c) Somente as afirmativas III e IV esto corretas.
d) Somente as afirmativas I, II e IV esto corretas.
e) Somente as afirmativas II, III e IV esto corretas.


Prof. Victor Dalton

Aproveitaremos esta questo da UEL para destrinchar todas as etapas da
Engenharia de Requisitos, segundo Pressman.

A engenharia de requisitos fornece o mecanismo apropriado para entender
o que o cliente deseja, analisando as necessidades, avaliando a exequibilidade,
negociando uma condio razovel, especificando a soluo de modo no
ambguo, validando a especificao e gerindo os requisitos medida que eles
so transformados em um sistema operacional (no 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
execuo de sete funes distintas: concepo, levantamento, elaborao,
negociao, especificao, validao e gesto.
Concepo - Concepo inicial do software. O objetivo desta etapa
entender o problema, quais os envolvidos, a natureza da soluo e iniciar o
processo de comunicao entre clientes e colaboradores.
Levantamento e anlise - Perguntar aos envolvidos no projeto:
Qual o objetivo do produto?;
Como o produto se enquadra nas necessidades do
negcio?;
Como o produto ser utilizado?
O que o produto deve oferecer?

Entretanto, podem existir diversos problemas nesse ponto do projeto:
Problemas de escopo: No se identifica corretamente os
limites do que o Software deve ou no fazer, muitas vezes requisitos
tcnicos desnecessrios confundem o entendimento da soluo
esperada;
Problemas de entendimento: O cliente no tem domnio
suficiente do problema, no conhece o potencial de uma soluo
computacional, omite informaes bvias, entre outros;
Problemas de volatilidade: Os requisitos mudam ao longo
do tempo.
Por experincia prpria, posso afirmar o quanto difcil levantar requisitos,
principalmente quanto a problemas de entendimento. Sempre que partimos para
a prxima etapa, a elaborao, uma das coisas mais comuns o cliente afirmar
que aquele cenrio elaborado no condiz com o que ele mesmo descreveu e
documentou na reunio anterior. As etapas de elaborao e levantamento
formam um loop parte, at que se consiga avanar no projeto.

Prof. Victor Dalton
Elaborao - Refinamento das informaes obtidas na etapa anterior com a
incluso de modelagens de cenrios de interao do usurio com o sistema e
modelagem das classes envolvidas tanto como a relao entre elas.
Negociao - frequente que aps a etapa de elaborao muitos requisitos
no estejam de acordo com a disponibilidade de recursos disponveis ou ainda
sejam conflitantes entre si. Nesse ponto os requisitos so avaliados junto ao
cliente e podem ser excludos, combinados ou ainda serem acrescentados novos
requisitos.
Especificao - A especificao a apresentao formal dos dados obtidos
at o momento podendo incluir grficos, textos em linguagem natural,
modelagem de cenrios ou um prottipo. O principal que a especificao possa
guiar o desenvolvimento futuro indicando os limites do software com as suas
possibilidades e limitaes.
Validao - Nesse ponto, todos os envolvidos (clientes, colaboradores e
usurios) avaliam os requisitos em busca de erros de interpretao,
ambiguidade e omisses. Pode ser usado um modelo de questes checklist para
validar os requisitos.
Gesto - A gesto de requisitos o processo que visa identificar, controlar
e rastrear requisitos e modificaes 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 dependncias. Para projetos menores esse
processo pode ser feito de forma mais informal.

Voc ainda se lembra da questo? Ento volte aos itens dela e tente
responder sem a minha explicao abaixo.

I. uma afirmativa bem genrica e verdadeira. Todas as atividades da
Engenharia de Software devem ser adaptadas organizao que a realiza;
II. Correta. A descoberta, elicitao ou levantamento dos requisitos (isso
mesmo, 10 questo) a etapa em que ocorre essa obteno de informaes
sobre o domnio da aplicao;
III. No necessariamente. Inclusive, o mais comum, medida que se
coletam diferentes pontos de vista, encontrarmos requisitos conflitantes. E
por isso que a fase de negociao indispensvel;
IV. Correta. Aps a negociao e a especificao, a validao uma espcie
de reunio final em que todos avalizam os requisitos definidos. Aps isto,
temos apenas a gesto, que rastreia a evoluo dos requisitos ao longo do
tempo.

Entendidas estas sete etapas? Certamente este assunto ser cobrado em
sua prova. Alternativa d).


Prof. Victor Dalton
17 Questo) (FGV Senado Federal - Analista Sistemas 2012) O
processo de Engenharia de Requisitos realizado por meio da execuo de sete
funes distintas: concepo, levantamento, elaborao, negociao,
especificao, validao e gesto. Nesse contexto, observe a lista abaixo, que
representa um conjunto de questes a serem utilizadas como checklist dentro de
uma dessas funes.

A funo :

a) Elaborao
b) Negociao
c) Especificao
d) Validao
e) Gesto

Opa! Voc j sabe qual a etapa que rene clientes, colaboradores e
usurios para avaliar os requisitos acordados, inclusive por meio de um
checklist, no sabe? a validao.
Ainda, se lhe restar alguma dvida, confirme que o checklist apresentado
procura erros de interpretao, ambiguidade e omisses. At mesmo pelo
contedo das perguntas mostradas, razovel que estejamos em uma etapa
posterior concepo, levantamento e elaborao dos requisitos. Tambm no
so perguntas referentes a uma eventual negociao. Na especificao no cabe
checklist, pois esta um detalhamento formal dos requisitos ps-negociao,
auxiliada por prottipos e diagramas. E, por fim, no cabe ser gesto de
requisitos, pois tambm no cabe checklist na gesto. Nesta etapa, os requisitos
j esto claros, sendo apenas rastreados em caso de modificao ou evoluo ao
longo do tempo.

Nossa resposta correta, alternativa d).


Prof. Victor Dalton

18 Questo) (ESAF Analista de Finanas e Controle Tecnologia
da Informao 2003 - adaptada) Analise as seguintes afirmaes relativas
Engenharia de Software:
I. A anlise de requisitos responsvel pela especificao dos requisitos de
software e hardware que sero utilizados durante o processo de
desenvolvimento de um sistema.
II. A anlise de requisitos define a metodologia de programao a ser
utilizada no desenvolvimento do sistema.
III. A especificao de requisitos fornece ao desenvolvedor e ao cliente os
parmetros para avaliar a qualidade logo que o sistema for construdo.
IV. A anlise de requisitos possibilita que o engenheiro de software
compreenda o sistema que ir desenvolver.

Esto corretos os itens:

a) I e II
b) II e III
c) III e IV
d) I e III
e) II e IV

Utilizo esta questo porque quero chamar a sua ateno para as etapas de
Engenharia de Requisitos, segundo Sommerville! Ela tambm pode ser cobrada.

Na Especificao do software, tambm chamada de Engenharia de
Requisitos, ocorrem quatro etapas(segundo Sommerville):
Estudo de viabilidade verifica se as necessidades dos usurios podem ser
satisfeitas pelas tecnologias atuais de software/hardware;
Elicitao e anlise de requisitos compreenso, por parte dos analistas,
dos requisitos do sistema, por meio de discusses com os usurios potenciais e
observao de sistemas existentes. Alm disso, ajuda os analistas a
compreender o sistema a ser especificado;
Especificao de requisitos Traduo das informaes obtidas na anlise
em um documento de defina um conjunto de requisitos;
Validao de requisitos verificao junto ao cliente da correo e escopo
dos requisitos.


Prof. Victor Dalton

Engenharia de Requisitos, segundo Sommerville

Pois , danar conforme a msica. Quando uma questo aparece sobre
requisitos, voc precisa identificar se a abordagem utilizada a do Pressman ou
a do Sommerville, para poder responder corretamente.
Os itens III e IV esto corretos, e nossa resposta certa a alternativa c).

Tecnologia da Informao - 2005) Analise as seguintes afirmaes
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 ento este ter alcanado um ndice de
qualidade de 100%.
III. O controle de qualidade utiliza inspees para provar a existncia de
qualidade dentro de um produto final do projeto.
IV. Um ambiente de desenvolvimento de software, no processo de evoluo
da qualidade dos seus produtos e servios, deve substituir o processo de
Controle da Qualidade pelo processo de Garantia da Qualidade.

Indique a opo que contenha todas as afirmaes 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 questo
conceitual apenas para desencargo de conscincia.
O gerenciamento da qualidade de software pode ser estruturado em trs
grandes atividades:

Prof. Victor Dalton
Garantia de qualidade estabelecimento de um framework de
procedimentos organizacionais e padres que conduzem a um software de alta
qualidade;
Planejamento de qualidade seleo de procedimentos e padres
apropriados deste framework, adaptados para um projeto de software
especfico; e
Controle de qualidade Definio e aprovao de processos que assegurem
que a equipe de desenvolvimento de software tenha seguido os procedimentos e
os padres 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 padres de processo, que definem os processos que devem
ser seguidos durante o desenvolvimento do software (como documentos
obrigatrios que devam ser gerados, estabelecimento de reunies peridicas), e
o estabelecimento de padres de produto(exigncia de determinada
nomenclatura a ser adotada no cdigo, padronizao de comentrios no cdigo,
padronizao do formato da documentao, etc.).

Feita esta introduo, vejamos as alternativas:
I. Est razoavelmente certa. Garantir que o projeto foi concludo sem
desvios tambm 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, apenas para lembrar, o diagrama da lei do
80/20. Por exemplo, 20% dos defeitos do software so responsveis
por 80% das reclamaes. Ele um diagrama que ajuda a estabelecer
prioridades, logo, no garante nada;
III. Certssimo. Controle -> inspees!
IV. Esta substituio no existe, as trs tarefas so necessrias.

Logo, ficamos com a alternativa d).

20 Questo)(FCC Tribunal de Contas do Estado do Paran -
Analista de Controle Informtica - 2011) Mtricas de software podem ser
divididas em medidas diretas e indiretas, sob o ponto de vista de medio, e em
mtricas de produtividade e de qualidade, sob o ponto de vista de aplicao.
Nesse contexto, as mtricas que se concentram na sada do processo de
engenharia de software e as mtricas que indicam o quanto o software atende
aos requisitos definidos pelo usurio, podem ser classificadas, respectivamente,
como mtricas de
a) custo e de complexidade, em medidas indiretas.
b) esforo e de confiabilidade, em medidas diretas.
c) produtividade e de qualidade, em medidas indiretas.

Prof. Victor Dalton
d) qualidade e de eficincia, em medidas diretas.
e) velocidade de execuo e tcnica, em medidas diretas.

A medio de software um recurso que tem como objetivo avaliar, de
forma automatizada o projeto de software, para poder fazer previses gerais
sobre um sistema e/ou identificar componentes anmalos. Para tal, so
utilizadas as mtricas de software.

As mtricas de produto dividem-se em duas classes:
Mtricas estticas ajudam a avaliar a complexidade, a facilidade de
compreenso e a facilidade de manuteno de um sistema de software; e
Mtricas dinmicas mais relacionadas com a eficincia e a confiabilidade
de um programa.
Ainda, pode se enxergar a medio pela tica das medidas diretas e
indiretas.
Medida direta no envolve a medio de outro atributo alm do atributo
considerado, como linhas de cdigo, nmero de erros, etc.; e
Medida indireta alm do atributo considerado, medidas de outros
atributos so levadas em considerao. So exemplos, qualidade, complexidade,
eficincia, etc.

Tambm podemos dividir as mtricas de software, sob o ponto de vista de
aplicao, em duas categorias: mtricas de produtividade e de qualidade. As
mtricas de produtividade se concentram na sada do processo de engenharia de
software e mtricas de qualidade indicam o quanto o software atende aos
requisitos definidos pelo usurio.

Diante do exposto acima, percebe-se que a alternativa correta a letra c).

P.S.:Caso deseje uma rpida e til sobre medidas de software, veja em
http://pt.wikipedia.org/wiki/Mtrica_de_software. Nem tudo que est na
Wikipedia lixo, e veremos mais links teis ao longo do curso.

Tecnologia da Informao - 2005)As mtricas de produtos de software
dividem-se em classes: mtricas dinmicas coletadas por meio de medies
realizadas em um programa em execuo, e mtricas estticas coletadas por
meio de medies realizadas em representaes do sistema. Indique a opo
que descreve corretamente uma mtrica esttica do produto de software.
a) ndice de fog uma medida da complexidade de controle de um
programa.
b) Complexidade ciclomtica uma medida da extenso mdia das
palavras e das sentenas em documentos, ponderada por complexidade.

Prof. Victor Dalton
c) Extenso de identificadores o nmero de mtodos includos em uma
classe, relacionada com a facilidade de compreenso do programa.
d) Extenso de cdigo uma medida de extenso mdia de um programa
e est associada complexidade da lgica de controle do programa.
e) Fan-in/Fan-out uma medida do nmero de funes ou mtodos que
chamam alguma outra funo ou mtodo.

Esta questo da ESAF excelente, por nos chamar a ateno para 5
mtricas que, no raro, aparecem em provas. Todas as 5 definies de mtricas
citadas realmente so de mtricas estticas, mas a questo faz um troca-troca
nas descries, para confundir sua cabea. Segue gabarito abaixo:
a) ndice de fog uma medida da extenso mdia das palavras e das
sentenas em documentos, ponderada por complexidade.
b) Complexidade ciclomtica uma medida da complexidade de controle
de um programa.
c) Extenso de identificadores uma medida da extenso mdia de
identificadores distintos em um programa.
d) Extenso de cdigo medida do tamanho de um programa.
e) Correta.

22 Questo) (UEL Analista de Informtica Jnior
Desenvolvimento de Sistemas - 2009) A norma ISO 9126 (Caractersticas
de Qualidade de Software define 6 caractersticas (requisitos) de qualidade
desejveis para um produto de software.
Considere os itens a seguir:

I. Evidencia o conjunto de funes que atendem s necessidades explcitas
e implcitas para a finalidade a que se destina o produto e suas propriedades
especficas

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

III. Evidencia a facilidade de uso do produto, bem como o julgamento
individual desse uso, por um conjunto de usurios estabelecido ou subentendido.

IV. Evidencia a compatibilidade entre os recursos e os tempos envolvidos,
assim como o nvel de desempenho requerido para o produto, sob condies
estabelecidas.

V. Evidencia a possibilidade de se utilizar o produto em diversas
plataformas, com pequeno esforo para adaptao.

VI. Evidencia a facilidade para fazer modificaes especficas no software.

Prof. Victor Dalton

Assinale a alternativa que apresenta a sequncia correta em relao aos
itens colocados anteriormente.

a) Funcionalidade; Eficincia; Usabilidade; Confiabilidade; Portabilidade;
Manutenibilidade.
b) Funcionalidade; Confiabilidade; Portabilidade; Eficincia; Usabilidade;
Manutenibilidade.
c) Confiabilidade; Usabilidade; Eficincia; Portabilidade; Manutenibilidade;
Funcionalidade.
d) Funcionalidade; Confiabilidade; Usabilidade; Eficincia; Portabilidade;
Manutenibilidade.
e) Confiabilidade; Funcionalidade; Usabilidade; Eficincia; Portabilidade;
Manutenibilidade.

Esses conceitos so pea-chave da norma ISO 8126, que versa sobre
qualidade de software.

Em questes nesse estilo, alguns itens podem amarrar a alternativa
correta com maior facilidade. Evidenciar se um conjunto de funes 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, graas 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 questo. Por fim, modificar o software, seja para correes
ou evoluo est diretamente relacionado manutenibilidade do mesmo.
Logo, a dvida reside apenas entre as alternativas a) e d), em que as
definies de confiabilidade e eficincia talvez no estejam to explcitas em
suas descries. Ento vejamos abaixo as seis caractersticas descritas
corretamente:
Funcionalidade - Evidencia o conjunto de funes que atendem s
necessidades explcitas e implcitas para a finalidade a que se destina o produto
e suas propriedades especficas.
Confiabilidade - Evidencia o desempenho do produto, verificado ao longo do
tempo e em condies estabelecidas.
Usabilidade - Evidencia a facilidade de uso do produto, bem como o
julgamento individual desse uso, por um conjunto de usurios estabelecido ou
subentendido.
Eficincia - Evidencia a compatibilidade entre os recursos e os tempos
envolvidos, assim como o nvel de desempenho requerido para o produto, sob
Portabilidade - Evidencia a possibilidade de se utilizar o produto em
diversas plataformas, com pequeno esforo para adaptao.

Prof. Victor Dalton
Manutenibilidade - Evidencia a facilidade para fazer modificaes
especficas no software.

Assimilados os conceitos? Alternativa d).

23 Questo) (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 tcnica utilizada para se projetar casos de teste no
qual o programa ou sistema considerado uma caixa preta e, para test-lo, so
fornecidas entradas e avaliadas as sadas geradas para verificar se esto em
conformidade com os objetivos especificados.

II. A tcnica estrutural estabelece os requisitos de teste com base em uma
dada implementao, requerendo a execuo de partes ou de componentes
elementares do programa.

III. Teste um conjunto de atividades que no pode ser planejado
antecipadamente, porm deve ser realizado sistematicamente.

IV. Um mdulo driver chama o mdulo que est sendo testado, devendo
conter apenas as inicializaes das variveis globais e dos parmetros que sero
utilizados para a chamada do mdulo testado.

a) Somente as afirmativas I e III esto corretas.
b) Somente as afirmativas III e IV esto corretas.
c) Somente as afirmativas I e II esto corretas.

Teste de software uma atividade realizada para descobrir erros que foram
produzidos inadvertidamente no momento em que o software foi projetado e
construdo. Pode ser planejado antecipadamente e conduzido sistematicamente.
Ainda, podem ser testes de baixo nvel, no qual so verificados se pequenos
segmentos de cdigo-fonte foram corretamente implementados, bem como
testes de alto nvel, que validam as principais funes do sistema com base nos
requisitos do cliente.
O teste de software um elemento de um aspecto mais amplo, que
frequentemente referido como Verificao e Validao (V&V).
Verificao se refere ao conjunto de atividades que garante que o software
implementa corretamente uma funo especfica (estamos construindo o produto
corretamente?), enquanto a Validao se certifica que o software construdo
corresponde aos requisitos do cliente (estamos construindo o produto certo?).

Prof. Victor Dalton
A partir de agora, vamos utilizar as alternativas e as questes seguintes
para mergulharmos naquilo que for mais importante dentro deste assunto.

I. Teste funcional um outro nome o teste caixa preta. Sua descrio
combina com aquilo que, intuitivamente, vem sua cabea: um este que se
preocupa apenas em saber se o programa funciona. Aplica-se uma entrada e
verifica-se se a sada a esperada. Falaremos mais dele adiante. Certa;

II. A tcnica estrutural um outro nome para o teste caixa branca. Nele,
alm do resultado, preocupa-se com o caminho percorrido ao longo do
programa, e com quais partes foram executadas. Tambm ser discutido mais
adiante. Correta;

III. Pressman, copiado e modificado. Retire o no da frase, troque
porm por e e ela fica correta. Errada;

IV. Os testes, quando realizados de forma automatizada, so coordenados
por esse mdulo chamado de mdulo driver; sua tarefa exatamente a descrita
no item. Uma vez inicializadas as variveis globais e chamados os parmetros do
mdulo que ser testado, ser possvel verificar se o mdulo est funcionando
corretamente, ou seja, se a sada do mdulo a esperada, com base nos
parmetros utilizados. Certa;

Portanto, nossa alternativa correta a letra d).

24 Questo) (FCC TJ/RJ Analista Judicirio - Analista de
Sistemas - 2012) No que se refere a testes de software, correto afirmar
que
a) o teste de operao a fase onde testada a ergonomia da interface de
uso do software.
b) o teste da caixa preta (teste funcional), baseia-se em analisar os
arquivos de log do sistema procurando por mensagens de funcionamento
inconsistente.
c) um teste bem sucedido um teste que no encontra nenhum erro no
software.
d) o teste da caixa branca (teste estrutural), baseia-se em testar as
estruturas do cdigo fonte, como comandos condicionais e de repetio.
e) um caso de teste uma categoria de possveis resultados na execuo
de testes.

Na questo anterior j frisamos a definio de testes. Agora, veremos
algumas das tcnicas de testes mais comuns e as fases em que eles podem ser
empregados.


Prof. Victor Dalton
Tcnicas de teste

Caixa-Branca - Tambm chamada de teste estrutural ou orientado lgica,
a tcnica de caixa-branca avalia o comportamento interno do componente de
software. Essa tcnica trabalha diretamente sobre o cdigo fonte do componente
de software para avaliar aspectos tais como: teste de condio, teste de fluxo de
dados, teste de ciclos, teste de caminhos lgicos, cdigos nunca executados.
Os aspectos avaliados nesta tcnica de teste dependero da complexidade
e da tecnologia que determinarem a construo do componente de software,
cabendo portanto avaliao de mais aspectos que os citados anteriormente. O
testador tem acesso ao cdigo fonte da aplicao e pode construir cdigos para
efetuar a ligao de bibliotecas e componentes. Este tipo de teste desenvolvido
analisando o cdigo fonte e elaborando casos de teste que cubram todas as
possibilidades do componente de software. Dessa maneira, todas as variaes
relevantes originadas por estruturas de condies so testadas.
Um exemplo bem prtico desta tcnica de teste o uso da ferramenta livre
JUnit para desenvolvimento de classes de teste para testar classes ou mtodos
desenvolvidos em Java. Tambm se enquadram nessa tcnica testes manuais ou
testes efetuados com apoio de ferramentas para verificao de aderncia a boas
prticas de codificao reconhecidas pelo mercado de software. A aderncia a
padres e boas prticas visa principalmente a diminuio da possibilidade de
erros de codificao e a busca de utilizao de comandos que gerem o melhor
desempenho de execuo possvel. Apesar de muitos desenvolvedores alegarem
que no h ganhos perceptveis com essa tcnica de teste aplicada sobre
unidades de software, devemos lembrar que, no ambiente produtivo, cada
programa pode vir a ser executado milhares ou milhes de vezes em intervalos
de tempo pequenos. na realidade de produo que a soma dos aparentes
pequenos tempos de execuo e consumo de memria de cada programa poder
levar o software a deixar de atender aos objetivos esperados. A tcnica de teste
de caixa-branca recomendada para as fases de teste de unidade e teste de
integrao, cuja responsabilidade principal fica a cargo dos desenvolvedores do
software, que por sua vez conhecem bem o cdigo fonte produzido.

Caixa-Preta - Tambm chamada de teste funcional, orientado a dado ou
orientado a entrada e sada, a tcnica de caixa-preta avalia o comportamento
externo do componente de software, sem se considerar o comportamento
interno do mesmo. Dados de entrada so fornecidos, o teste executado e o
resultado obtido comparado a um resultado esperado previamente conhecido.
Como detalhes de implementao no so considerados, os casos de teste so
todos derivados da especificao.
Quanto mais entradas so fornecidas, mais rico ser o teste. Numa situao
ideal todas as entradas possveis seriam testadas, mas na ampla maioria dos
casos isso impossvel. Outro problema que a especificao pode estar
ambgua em relao ao sistema produzido, e como resultado as entradas
especificadas podem no ser as mesmas aceitas para o teste. Uma abordagem

Prof. Victor Dalton
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
possveis que so 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 possveis pode gerar pelo menos dezenas de milhares de
casos de testes distintos. Entretanto, a partir da especificao do sistema, pode-
se encontrar um subconjunto de inteiros que maximizem a qualidade do teste.
Depende do propsito do sistema, mas casos possveis incluem inteiros pares,
inteiros mpares, zero, inteiros positivos, inteiros negativos, o maior inteiro, o
menor inteiro.
Essa tcnica aplicvel a todas as fases de teste teste unitrio, teste de
integrao, teste de sistema e teste de aceitao. A aplicao de tcnicas de
teste leva o testador a produzir um conjunto de casos de teste (ou situaes de
teste). A aplicao combinada de outra tcnica tcnica de particionamento de
equivalncia (ou uso de classes de equivalncia) permite avaliar se a quantidade
de casos de teste produzida coerente. A partir das classes de equivalncia
identificadas, o testador construir casos de teste que atuem nos limites
superiores e inferiores destas classes, de forma que um nmero mnimo de
casos de teste permita a maior cobertura de teste possvel.
Uma abordagem no desenvolvimento do teste de caixa-preta o teste
baseado na especificao, de forma que as funcionalidades so testadas de
acordo com os requisitos. Apesar de necessrio, esse tipo de teste insuficiente
para identificar certos riscos num projeto de software.

Regresso - Essa uma tcnica de teste aplicvel a uma nova verso de
software ou necessidade de se executar um novo ciclo de teste durante o
processo de desenvolvimento. Consiste em se aplicar, a cada nova verso do
software ou a cada ciclo, todos os testes que j foram aplicados nas verses ou
ciclos de teste anteriores do sistema. Inclui-se nesse contexto a observao de
fases e tcnicas de teste de acordo com o impacto de alteraes provocado pela
nova verso ou ciclo de teste. Para efeito de aumento de produtividade e de
viabilidade dos testes, recomendada a utilizao de ferramentas de automao
de teste, de forma que, sobre a nova verso ou ciclo de teste, todos os testes
anteriores possam ser executados novamente com maior agilidade.

Tcnicas nofuncionais - Outras tcnicas de teste existem para testar
aspectos no-funcionais do software, como por exemplo, a adequao a
restries de negcio, adequao a normas, ou restries tecnolgicas. Em
contraste s tcnicas funcionais mencionadas acima, que verificam a produo
pelo sistema de respostas adequadas de suas operaes, de acordo com uma
especificao, as tcnicas no funcionais verificam atributos de um componente
ou sistema que no se relacionam com a funcionalidade (por exemplo,
confiabilidade, eficincia, usabilidade, manutenibilidade e portabilidade).

Prof. Victor Dalton
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 especificaes de tempo de processamento
exigidas, o que determina a escalabilidade do software. O teste de usabilidade
necessrio para verificar se a interface de usurio fcil de se aprender e
utilizar. Entre verificaes cabveis esto a relao da interface com
conhecimento do usurio, 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 recuperao usado para verificar a
robustez do software em retornar a um estado estvel de execuo aps estar
em um estado de falha.

Teste de Domnio - Pode ser aplicado em um campo, uma assinatura, um
I/O, ou qualquer tipo de local que receba valores externos ao sistema. Todo
domnio deve realizar consistncias de dados validos e invlidos. Um domnio s
permite dados com a formatao igual ao que ser armazenado.
Ex.: Campo DDD dever permitir nmeros de at quatro casas no
negativas ou a base de dados deve impedir a entrada de valores invlidos.
Uma tcnica de teste comumente empregada em testes de domnio a
Anlise do Valor Limite na qual so testados valores nas fronteiras de um
domnio. Por exemplo: se determinado campo s permite o preenchimento com
nmeros de 1 a 100, aplicam-se nos testes os valores 0,1,100 e 101.

Fases (Tipos de Teste)

Uma prtica comum testar o software aps uma funcionalidade ser
desenvolvida, e antes dela ser implantada no cliente, por um grupo de
profissionais diferente da implementao. Essa prtica pode resultar na fase de
teste ser usada para compensar atrasos do projeto, comprometendo o tempo
devotado ao teste. Outra prtica comear o teste no mesmo momento que o
projeto, num processo contnuo at o fim do projeto.
Em contrapartida, algumas prticas emergentes como a programao
extrema e o desenvolvimento gil focam o modelo de desenvolvimento orientado
ao teste. Nesse processo, os testes de unidade so escritos primeiro ( TDD ), por
engenheiros de software. Antes da implementao da unidade em questo, o
teste falha. Ento o cdigo escrito, passando incrementalmente em pores
maiores dos casos de teste. Os testes so mantidos junto com o resto do cdigo
fonte do software, e geralmente tambm integra o processo de construo do
software.

Teste de unidade - Tambm conhecida como teste unitrio ou teste de
mdulo, a fase em que se testam as menores unidades de software
desenvolvidas (pequenas partes ou unidades do sistema). O universo alvo desse

Prof. Victor Dalton
tipo de teste so as subrotinas ou mesmo pequenos trechos de cdigo. Assim, o
objetivo o de encontrar falhas de funcionamento dentro de uma pequena parte
do sistema funcionando independentemente do todo.

Teste de integrao - Na fase de teste de integrao, o objetivo encontrar
falhas provenientes da integrao interna dos componentes de um sistema.
Geralmente os tipos de falhas encontradas so de transmisso de dados. Por
exemplo, um componente A pode estar aguardando o retorno de um valor X ao
executar um mtodo do componente B; porm, B pode retornar um valor Y,
gerando uma falha. No faz parte do escopo dessa fase de teste o tratamento de
interfaces com outros sistemas (integrao entre sistemas). Essas interfaces so
testadas na fase de teste de sistema, apesar de, a critrio do gerente de projeto,
estas interfaces podem ser testadas mesmo antes de o sistema estar
plenamente construdo.

Teste de sistema - Na fase de teste de sistema, o objetivo executar o
sistema sob ponto de vista de seu usurio final, varrendo as funcionalidades em
busca de falhas em relao aos objetivos originais. Os testes so executados em
condies similares de ambiente, interfaces sistmicas e massas de dados
quelas que um usurio utilizar no seu dia-a-dia de manipulao do sistema.
De acordo com a poltica de uma organizao, podem ser utilizadas condies
reais de ambiente, interfaces sistmicas e massas de dados.

Teste de aceitao - Geralmente, os testes de aceitao so realizados por
um grupo restrito de usurios finais do sistema, que simulam operaes 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
no seus critrios de aceitao e para permitir ao cliente determinar se aceita ou
no o sistema. Validao de um software pelo comprador, pelo usurio ou por
terceira parte, com o uso de dados ou cenrios especificados ou reais. Pode
incluir testes funcionais, de configurao, de recuperao de falhas, de
segurana e de desempenho.

Teste de operao - 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 aplicvel somente a sistemas de informao
prprios de uma organizao, cujo acesso pode ser feito interna ou
externamente a essa organizao. Nessa fase de teste devem ser feitas
simulaes para garantir que a entrada em produo do sistema ser bem
sucedida. Envolve testes de instalao, simulaes com cpia de segurana dos
bancos de dados, etc.. Em alguns casos um sistema entrar em produo para
substituir outro e necessrio garantir que o novo sistema continuar
garantindo o suporte ao negcio.


Prof. Victor Dalton
Destaco que as tcnicas de testes e as fases so pontos de vista distintos
para se observar um determinado teste. Por exemplo, uma inspeo detalhada
na execuo de um cdigo especfico pode ser um teste caixa-branca e um teste
de unidade. Assim como um teste de Stress, no ambiente final do sistema,
tambm pode ser um teste de operao. Compreendido?

Voltando questo, nossa alternativa correta a letra d).

25 Questo) )(FCC Tribunal de Contas do Estado do Paran -
Analista de Controle Informtica - 2011) Segundo Sommerville, aps um
sistema ser completamente integrado, possvel testar propriedades como a de
desempenho do sistema. Neste contexto, considere:
I. Testes de desempenho devem ser produzidos de forma a garantir que o
sistema possa processar a sua carga prevista, sendo que tais testes geralmente
so planejados para que a carga seja continuamente aumentada at que o
sistema apresente desempenho fora do aceitvel.
II. Os testes de desempenho devem determinar se um sistema corresponde
s suas exigncias, sendo que a descoberta de defeitos ou problemas no sistema
no enfoque desta etapa.
III. Para determinar se o desempenho est sendo atingido, pode ser
necessrio a construo de um perfil operacional, que a listagem de todo o
grupo de operadores/usurios que faro uso deste sistema.
a) I, apenas.
b) I, II, III.
c) III, apenas.
d) I e II, apenas.
e) II e III, apenas.

Apesar de testes de desempenho ser um assunto contemplado pelo
Pressman, perceba que a FCC foi no Sommerville pegar a referida definio.
Nesse sentido, o item I verdadeiro.
Sommerville tambm cita que o teste de desempenho, como qualquer
outro teste, tambm pode ser usado para descobrir problemas e defeitos no
sistema. Logo, item II falso.
Por fim, Sommervile versa o seguinte sobre perfis operacionais:se 90%
das transaes de um sistema forem do tipo A, 5% do tipo B e o restante dos
tipos C, D e E, voc dever projetar o perfil operacional de modo que a maioria
dos testes seja do tipo A. Logo, percebe-se que perfil operacional um
conjunto de testes, e no de usurios. Item III errado.

Resposta correta, alternativa a).


Prof. Victor Dalton
26 Questo) (UEL POSCOMP 2011) Tendo em vista a complexidade
envolvida no desenvolvimento de um sistema de software, importante
assegurar que ele cumpra com suas especificaes e atenda s necessidades dos
usurios.
Sobre o desenvolvimento de software, considere as afirmativas a seguir.

I. A Validao tem como objetivo responder. Estamos construindo o
produto certo? J a Verificao busca responder: Estamos construindo o
produto corretamente?

II. Em um cadastro, encontra-se um campo de entrada solicitando o ano de
nascimento, sendo vlidos valores entre 1900 e 2011. Os casos de teste para
este campo, considerando a tcnica de anlise de valor limite, so:
1899,1900,1901,2010,2011,2012 e 0.

III. As atividades de Verificao e Validao envolvem atividades de anlise
esttica e de anlise dinmica do produto em desenvolvimento, e apenas as
atividades de anlise dinmica envolvem a execuo do produto.

IV. Um dos objetivos dos mtodos de teste de caixa preta garantir que
todos os caminhos de um programa tenham sido exercitados pelo menos uma
vez, podendo-se aplicar a tcnica do teste do caminha bsico para este fim.


Uma questo mais abrangente sobre testes, cujo conhecimento voc j
possui para responder. Revisando:
I. Certa. Esta diferena dentre Verificao e Validao estendida a todos
os ramos da TI, ento assimile-a bem;
II. Na anlise 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. Anlise esttica envolve apenas a anlise de cdigos e
modelos, enquanto a dinmica compreende a anlise do programa em execuo;
IV. Teste de caminho! Errada.

Portanto, a alternativa correta a letra b).


Prof. Victor Dalton
27 Questo) (Formulao pessoal) Segundo Pressmann, cada um dos
elementos de informao que so criados durante o desenvolvimento de um
produto de software, que so identificados de maneira nica e cuja evoluo
passvel de rastreamento, refere-se a
a) Item de software
b) Componente de software
c) Item de configurao
d) Componente de dados
e) Componente de programa

Vamos falar um pouco sobre Gerncia de Configurao.

Gerncia de Configurao
Durante seu ciclo de vida, o software passa por uma srie de modificaes,
desde sua concepo implantao.
Sob este aspecto, a Gerncia de Configurao de Software (CGS) vem a
definir critrios que permitam realizar tais modificaes mantendo-se a
consistncia e a integridade do software com as especificaes.
Ela permite minimizar os problemas decorrentes ao processo de
desenvolvimento, atravs de um controle sistemtico sobre as modificaes. No
objetivo da GCS evitar modificaes, mas permitir que elas ocorram sempre
que possvel, 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, constitudas
por objetivos bem definidos e documentados. Neste contexto, GCS atua como
um suporte sobre o qual as fases do desenvolvimento so conduzidas e os
produtos controlados.
Aplicar um plano de gerncia de configurao consiste em estabelecer
normas, ferramentas e templates que permitam gerenciar de maneira
satisfatria os itens de configurao de um sistema.
Entende-se como item de configurao Cada um dos elementos de
informao que so criados durante o desenvolvimento de um produto de
software, ou que para este desenvolvimento sejam necessrios, que so
identificados de maneira nica e cuja evoluo passvel de rastreamento
(Pressman).
Itens de configurao podem ser:
Servidores
Estaes de trabalho dos usurios
Banco de dados
Plano de negcio
Acordos com clientes
Softwares
Manuais de instruo
Outros, desde que sejam itens correlatos ao software entregue

Prof. Victor Dalton
Se o item de configurao for composto exclusivamente de software, ele
ento caracterizado como Item de Configurao de Software (ICSW).
Qualquer IC constitui uma unidade funcional que possui um ciclo de
desenvolvimento e acompanhamento de GCS prprios. Qualquer sistema em
desenvolvimento deve ser particionado em itens de configurao, 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 no particionveis, que
so desenvolvidos segundo um ciclo de vida propriamente definido.
A configurao de um sistema de software passa a ser definida pela
configurao do conjunto dos ICSW que o constitui.
importante salientar que a diviso de um sistema ou produto de software
em ICs, bem como a definio do ciclo de vida de cada IC, so decises de
projeto e no de GCS.
Em cada fase do processo de desenvolvimento, um conjunto bem definido
de itens de configurao deve ser estabelecido. Tal conjunto representa um
estgio do desenvolvimento, o qual passvel de modificaes apenas mediante
um mecanismo formal de alteraes. A este conjunto dado o nome de
Baselines, ou Configuraes Base do sistema.
Em princpio, 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 configuraes base pode, ento, ser resumido nos
seguintes pontos:
Caracterizao 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.
Definio do conjunto de baselines. Para cada baseline planejada, deve-se
estabelecer quais sero os ICs que a iro compor e quais as condies
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 modificao de uma configurao-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;

Prof. Victor Dalton
O estabelecimento de cada baseline somente realizado aps ser
aprovada por procedimentos de consistncia interna, verificao e
validao;
Desta forma possvel ter um controle sistemtico sobre todos os itens de
configurao abordados em cada fase do ciclo de vida do software, assim como
possvel avaliar mais facilmente o seu grau de evoluo.

O Gerenciamento de Configurao e o Gerenciamento de Mudanas pode
ser visto com mais detalhes no ITIL. Entretanto, por ter sido citado em
Engenharia de Software, tambm estamos vendo-o aqui.

Resposta certa, letra c).

28 Questo) (Formulao Pessoal) Procedimentos de gerenciamento de
mudana dizem respeito anlise de custo e benefcio das mudanas propostas,
aprovao das mudanas viveis e rastreabilidade de quais componentes do
sistema foram alterados. O processo de gerenciamento de mudana deve surtir
efeito quando o software ou a documentao associada so colocados em
baseline pela equipe de gerenciamento de configuraes.
O primeiro estgio para a solicitao de uma mudana para o sistema
a) Modificar o item de configurao envolvido e notificar equipe de
gerenciamento de mudana
b) Preencher uma Requisio de Mudana, ou Formulrio de Solicitao de
Mudana, e encaminhar ao Comit de Controle de Mudanas
c) Modificar o item de configurao envolvido e preencher o formulrio para
envio ao Comit de Controle de Mudanas
d) Notificar o Gerenciamento de Problema que deseja fazer uma mudana
no sistema
e) Aguardar uma falha no sistema para preencher uma Requisio de
Mudana

A ITIL define que o Gerenciamento de Mudanas e o Gerenciamento de
Configurao so processos distintos. Entretanto, reconhece-se que,
principalmente em pequenas organizaes, estes processos podem ser
executados pelas mesmas pessoas. No confunda pessoas com papis, nem
papis com processos; uma pessoa pode exercer vrios papeis (como Gerente
de Mudana e Gerente de Configurao). Entretanto, os processos continuam
sendo distintos.
Mudanas so um fato da vida para sistemas de software.
Nesse contexto, o Gerenciamento de Mudana tem por objetivo assegurar
que as mudanas sejam feitas de uma forma controlada, e sejam avaliadas,
priorizadas, planejadas, testadas, implantadas e documentadas.
O primeiro estgio no processo de gerenciamento de mudanas completar
um formulrio de solicitao de mudana (destaco que este formulrio ser um

Prof. Victor Dalton
item de configurao!), que descreva a mudana necessria para o sistema. Ao
longo do processo, este formulrio registrar as recomendaes para a
mudana, os custos estimados e as datas de quando ela foi solicitada, aprovada,
implementada e validada, bem como seu nvel de prioridade.
O Comit de Controle de Mudanas um grupo importante que toma as
decises de mudana. Apesar do nome pomposo, em pequenos e mdios
projetos, o CCM pode ser apenas o gerente de projeto e um ou dois
engenheiros. Em condies ideais, o CCM uma equipe exclusiva, e que conta
com representantes do negcio. Naturalmente, caber ao CCM analisar quais so
as mudanas dentro de seu nvel de autorizao, e quais mudanas exigem
cincia ou autorizao de outros stakeholders.

Logo, nossa resposta certa a letra b).

29 Questo) (Formulao Pessoal) Sobre o Gerenciamento de
Mudanas, analise as afirmativas abaixo:
I. As mudanas em um sistema podem ser levantadas proativamente, para
resolver erros ou adaptar-se a circunstncias de mudana, ou reativamente,
para gerar benefcios ao negcio, como reduzir custos e melhorar os servios.
II. Gerenciar mudanas no fazer mudanas que no ofeream risco:
fazer mudanas de forma que os riscos sejam mapeados e gerenciados.
III. Mudanas de alto custo e mudanas de risco so mudanas tpicas cuja
autoridade de mudana a gerncia de TI.
IV. Mudanas urgentes sempre devem passar pela autoridade do negcio.


a) Somente a afirmativa II est correta.
b) Somente as afirmativas II e III esto corretas.
c) Somente as afirmativas II e IV esto corretas.

Vamos utilizar estas afirmativas para captar mais algumas ideias acerca do
Gerenciamento de Mudana:
I. Proativamente e reativamente esto trocadas na afirmativa. Errada;
II. Correta;
III. Naturalmente, para cada nvel de importncia da mudana existem
autoridades que podem autorizar a mudana ou no. Mudanas de alto custo e
mudanas de risco so mudanas que exigem que o Comit Executivo de
Negcio autorize, enquanto mudanas de menor relevncia podem ficar a cargo
do prprio CCM. Destaco que a presidncia do CCM, apesar de poder conter
representantes de negcio, sempre do Gerente de Mudana, que algum da
TI. Errada;

Prof. Victor Dalton
IV. Mudanas urgentes no devem ser confundidas com mudanas
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. No preciso uma autoridade de negcio para toda
mudana urgente. Errada;

P.S.: Destaco ainda que existe o Comit de Controle de Mudanas
Emergencial, ou Comit Consultivo de Mudanas Emergencial (CCME), que
uma verso reduzida do CCM, que pode ser reunido quando da necessidade de
uma mudana urgente.

Voltando s alternativas, nossa resposta certa a letra a).

30 Questo) (Formulao Pessoal) responsabilidade da Gerncia de
Configurao:
I. Definir e controlar os componentes de servios e infraestrutura do
sistema, mantendo informaes precisas sobre os estados dos servios e
infraestrutura atual e planejada.
II. Manter um banco de dados de configurao (Configuration Management
Data Base) com todas as informaes relevantes sobre as configuraes do
sistema e os itens de configurao.
III. Avaliar o impacto de uma mudana no sistema.

c) Somente as afirmativas II e III esto corretas.
d) Todas as afirmativas esto corretas.
e) Apenas a afirmativa II est correta.

Quero chamar a sua ateno para uma pegadinha que as bancas gostam de
armar para seus candidatos, que confundir as atribuies da Gerncia de
Configurao e a Gerncia de Mudana.
Os itens I e II so de responsabilidade da Gerncia de Configurao. O item
III, entretanto, responsabilidade do Gerenciamento de Mudana! Apesar do
estreito relacionamento entre esses processos ( natural que a equipe de
mudana consulte a equipe de configurao para avaliar os itens de configurao
que sero afetados), no ser a Gerncia de Configurao que avaliar o
impacto de uma mudana, seno o prprio Gerenciamento de Mudana. Porm,
no ato da implantao da mudana, a Gerncia de Configurao rastrear os
itens modificados, para manter o banco de dados de configurao atualizado.

Prof. Victor Dalton
Estamos entendidos? Alternativa a).

Para ajudar os estudos, veja um comparativo abaixo, extrado da ITIL,
entre Gerenciamento de Configurao e Gerenciamento de Mudana. Maiores
detalhes sero vistos no estudo da ITIL.

Gerenciamento de Configurao Gerenciamento de Mudana
M
e
t
a
s

Suportar de forma eficiente e eficaz
os processos de Gerenciamento de
Servio

Otimizar os ativos de servios,
configuraes de TI, habilidades e
recursos
Responder s mudanas de
requisitos de negcio do cliente
enquanto se maximiza o valor e se
reduzem incidentes, interrupes e
retrabalhos

Responder ao negcio e requisies
de TI para mudanas que iro alinhar
os servios s necessidades do
negcio
O
b
j
e
t
i
v
o
s

Definir e controlar os componentes
de servios e infraestrutura, e
manter informaes precisas no
histrico sobre configurao, estado
dos servios e infraestrutura atual e
planejada.
Assegurar que as mudanas sejam
feitas de uma forma controlada, e
sejam avaliadas, priorizadas,
planejadas, testadas, implantadas e
documentadas.
A
t
i
v
i
d
a
d
e
s

Manter informaes sobre os Itens
de Configurao (ICs) no Banco de
Dados do Gerenciamento de
Configurao (BDGC)
Criar a Requisio De Mudana, ou
registrar a RDM (quando a solicitao
for originada em outra rea)
Manter o BDGC atualizado, por meio
do SGC (Sistema de Gerenciamento
da Configurao)
Avaliar o impacto de mudanas no
sistema
Manter a Biblioteca de Mdia
Definitiva (softwares licenciados,
documentao, etc)
Autorizar a mudana (quando dentro
do seu escopo de autorizao)
Realizao de auditorias para
conferncia do BDGC
Coordenar a implantao da
mudana

Como um mantm controle sobre os itens de configurao e outro os
modifica, natural um relacionamento estreito entre eles. Mas no confunda o
que cada um faz!

31 Questo) (FCC Ministrio Pblico do Estado de Sergipe
Analista do Ministrio Pblico Gesto e Anlise de Projeto de Sistema

Prof. Victor Dalton
2010) Em relao anlise e ao projeto orientados a objetos, correto
afirmar:
a) A orientao a objetos no leva em conta a utilizao da prototipao,
dada as restries desse modelo de desenvolvimento de software quanto
reusabilidade.
b) Uma das regras de normalizao aplicada s tabelas de objetos de dados
especifica que uma instncia de um objeto pode ter diversos valores para cada
atributo.
c) Se a informao sobre um objeto em potencial precisar ser lembrada
para que o sistema possa funcionar, esse objeto no poder ser utilizado
durante a anlise.
d) Representar os objetos e suas relaes o principal objetivo do
Diagrama Entidade-Relacionamento (E-R).
e) Um Diagrama de Fluxo de Dados (DFD) deve, alm do fluxo da
informao, descrever detalhadamente a lgica procedimental do sistema.

Na anlise e projeto estruturados, o processo a ser informatizado visto
como um conjunto de funes com dados de entrada, processamento e dados de
sada, ou seja, a nfase esta em funes que agem sobre dados. Estas funes
podem ser decompostas em subfunes (decomposio funcional). As principais
caractersticas so:
preocupao com a modularidade e coeso;
desenvolvimento em diferentes nveis de abstrao (top-down).

O Diagrama de Fluxo de Dados (DFD) o principal diagrama utilizado nessa
metodologia.

Em um DFD, representam-se entidades externas por caixas, processos (ou
tarefas) por circunferncias (tambm podem ser elipses ou elipses achatadas), o
fluxo dos dados por setas e depsitos de dados por traos duplos. Veja abaixo:


Prof. Victor Dalton
Na anlise orientada a projetos, o processo a ser informatizado
visto como um conjunto de objetos que interagem para realizar as
funes, como no diagrama de classes abaixo:

As principais vantagens do modelo OO so:
maior grau de abstrao;
maior encapsulamento;
modelos apoiados em conceitos do mundo real;
reutilizao (reusabilidade).

A anlise e projeto orientada a objetos lana mo da diagramao UML
para modelagem e anlise nas diversas etapas do projeto.

Quanto questo, a resposta certa a alternativa d).

Desenvolvimento de Sistemas de Informao 2008) A linguagem de
Modelagem Unificada (UML) emergiu como notao de diagramao de padro,
de fato e de direito, para a modelagem orientada a objetos. Desta forma, a
sentena que conceitua apropriadamente a UML, segundo o OMG-Object
Management Group,
a) um mtodo para especificar e modelar os artefatos dos sistemas.
b) um processo de especificao e modelagem de sistemas orientados a
objeto.

Prof. Victor Dalton
c) uma linguagem para implementar os conceitos da orientao a objetos.
d) uma linguagem visual para especificar, construir e documentar os
artefatos dos sistemas.
e) um mtodo comum para a representao da orientao a objetos.

UML um assunto trivial em provas de concursos que exijam
desenvolvimento de sistemas.
Segundo nossa fonte recomendada, a modelagem de sistemas de software
consiste na utilizao de notaes grficas e textuais com o objetivo de construir
modelos que representam as partes essenciais de um sistema, considerando-se
vrias perspectivas diferentes e complementares.
Exigir a sentena exata que conceitua a UML, segundo o OMG foi exagero
por parte da banca. Contudo, quem j trabalhou no desenvolvimento de um
sistema e j precisou de um diagrama UML sabe que uma caracterstica
importante dela a comunicao entre as pessoas envolvidas. Voc pode tentar
descrever um caso de uso simples de um sistema e perder 20 minutos
Entretanto, ao mostrar um diagrama de caso de uso ou um diagrama de
sequncia, o entendimento comum quase que imediato.
A UML uma ferramente poderosa de comunicao, alm da construo e
documentao de artefatos de um sistema.

Portanto, mesmo sem conhecer a exata sentena da OMG sobre o assunto,
perceptvel que a letra d) a alternativa mais completa e livre de incorrees.

33 Questo) (ESAF Analista de Controle Externo Anlise de
Sistemas 2002)Analise as seguintes afirmaes relativas UML:
I. Ao uma abstrao representativa de entidades externas que
interagem com um produto ou sistema;
II. Atributo a descrio de um espao com nome e tipo, dentro de uma
classe, onde cada objeto desta classe mantm um valor deste tipo;
III. Classe o descritor para um conjunto de objetos que partilham os
mesmos atributos, operaes, relacionamentos e comportamento;
IV. Evento a condio ou situao de vida de um objeto durante a qual
ele executa uma atividade.


a) I e II
b) II e III
c) III e IV
d) I e III
e) II e IV

Analisando conceitos:

Prof. Victor Dalton
I. Ator uma abstrao representativa de entidades externas que
interagem com um produto ou sistema. Ao uma expresso que pode ser
definida em termos dos atributos, das operaes ou das associaes da classe,
realizada pelo objeto quando transita de um estado para outro. Errada;
II. Correta;
III. Correta;
IV. Estado a condio ou situao de vida de um objeto durante a
qual ele executa uma atividade. Evento alguma ocorrncia no ambiente do
sistema para o qual este sistema deve realizar alguma ao quando da
ocorrncia do evento. Errada;

Portanto, a alternativa b) a correta.

34 Questo) (ESAF Agncia Nacional de guas Tecnologia da
Informao e Comunicao Desenvolvimento de Sistemas - 2009) Em
UML, o relacionamento utilizado para expressar herana entre classes e
interfaces a
a) multiplicidade.
b) dependncia.
c) agregao.
d) associao.
e) generalizao.

Mais reviso de conceitos:

a) Multiplicidades so os limites, superior e inferior, de associaes que um
objeto pode possuir. Errada;
b) Dependncia uma conexo semntica entre dois elementos, um
independente e outro dependente. Errada;
c) Agregao e composio so variantes da associao, que o
estabelecimento de um relacionamento entre objetos. Na agregao, a
parte pode existir sem o todo, e na composio isso no possvel.
Exemplos: jogador e time de futebol (agregao), Captulo, Seo e
Pargrafo (composio). Errada;
e) Generalizao/especializao so dois pontos de vista do mesmo
relacionamento utilizado para expressar herana entre classes e
interfaces. Correta.

Nosso estudo de UML continua. Alternativa e).

2012) Sobre Programao Orientada a Objetos e UML, considere:

Prof. Victor Dalton
I. Os diagramas de classe so usados no desenvolvimento de um modelo
de sistema orientado a objetos para mostrar as classes de um sistema e as
associaes entre essas classes.
II. A UML tem um tipo especfico de associao para denotar a
generalizao. Em uma generalizao, os atributos e operaes associados com
as classes de nvel alto (superclasses) tambm esto associados com as de nvel
baixo (subclasses).
III. A UML fornece um tipo especial de associao entre classes chamada
agregao, que significa que um objeto (todo) composto de outros objetos (as
partes).
IV. Os modelos comportamentais descrevem o modelo esttico do domnio
e qual a reao comportamental de interao entre as classes. Eles mostram o
que acontece ou deve acontecer quando o sistema responde a um estmulo de
seu ambiente.
Est correto o que consta APENAS em
a) I e II.
b) I, III e IV.
c) I, II e III.
d) II, III e IV.
e) III e IV.

A definio de diagramas de classe da questo bastante adequada.

Exemplo de diagrama de classe UML.

Os itens II e III, conforme a explicao anterior, tambm esto corretos.

Prof. Victor Dalton
Apenas o item IV incorreto. So os Diagramas Estruturais que
representam modelos estticos, enquanto os Diagramas Comportamentais, por
sua vez, modelam os aspectos dinmicos de um sistema. Veremos estes
diagramas mais adiante.

Resposta certa, alternativa c).

Sistemas 2002 - adaptada) Um gerente de projeto sabe que o modo para
descrever os vrios aspectos de modelagem pela UML por meio da notao
definida pelos seus vrios tipos de diagramas. Em um determinado projeto, ele
necessita de um diagrama esttico onde a estrutura descrita sempre vlida em
qualquer ponto do ciclo de vida do sistema. O diagrama UML recomendado para
suprir esta necessidade deste gerente o
a) diagrama de componente.
b) diagrama de comunicao.
c) diagrama de sequencia.
d) diagrama de classe.
e) diagrama de implantao.

Vamos revisar estes diagramas?

Diagrama de Componente - Um Diagrama de Componentes mostra como os
diferentes subsistemas de software formam a estrutura total de um sistema,
sistema este que est construdo sobre um banco de dados centralizado que
contm dados histricos de locaes, detalhes dos veculos, registros de
manuteno, dados de clientes e funcionrios. muito importante que estas
informaes estejam centralizadas em um banco de dados, pois os nveis de
estoque podero sofrer alteraes a cada hora, e todos os participantes do
processo comercial precisam ter acesso s informaes mais recentes. Manter os
dados atualizados uma tarefa que requer atualizaes em tempo real por parte
de todos os integrantes do processo.

Diagrama de Componente


Prof. Victor Dalton
Diagrama de Comunicao - Um Diagrama de Comunicao outro tipo de
diagrama de interao. Assim como no Diagrama de Sequncia, o Diagrama de
Comunicao mostra como um grupo de objetos num caso de uso interage com
os demais. Cada mensagem numerada para documentar a ordem na qual ela
ocorre. Observao: na UML 1.5, este diagrama chamava-se Diagrama de
Colaborao, e na 2.0 passou a chamar-se Diagrama de Comunicao.

Diagrama de Comunicao

Diagrama de Sequncia - Um Diagrama de Sequncia oferece uma viso
detalhada de um caso de uso. Ele mostra uma interao organizada em forma
de uma sequncia, dentro de um determinado perodo de tempo, e contribui
para a que se processe a documentao do fluxo de lgica dentro da aplicao.
Os participantes so apresentados dentro do contexto das mensagens que se
transitam entre eles. Num sistema de software abrangente, um Diagrama de
Sequncia pode ser bastante detalhado, e pode incluir milhares de mensagens.

Diagrama de Sequncia

Diagrama de Classe O Diagrama de Classe um diagrama de estrutura
esttica, que modela as classes de objetos, mostrando a estrutura geral do
sistema e tambm as suas propriedades relacionais e de comportamento.


Prof. Victor Dalton

Diagrama de Classe

Diagrama de Implantao Modela o uso fsico do sistema, considerando
computadores, dispositivos e suas interconexes.

Diagrama de Implantao

Diagrama de caso de uso(bnus) No poderamos no falar deste
diagrama. Um Caso de Uso especifica uma interao entre um usurio e o
sistema, no qual o usurio tem um objetivo muito claro a atingir.

Prof. Victor Dalton

Diagrama de Caso de Uso

Dentre todos esses diagramas, os Diagramas de Comunicao e de
Sequncia so o que chamamos de Diagramas Dinmicos, por refletirem o
comportamento do sistema. Pertencem a esse rol:
Diagrama de Estado
Diagrama de Sequncia
Diagrama de Colaborao
Diagrama de Atividade

Os Diagramas Funcionais, por sua vez, so diagramas que mostram o
sistema por um lado funcional, expondo as relaes entre seus componentes e a
organizao de seus mdulos durante sua execuo. So eles o Diagrama de
Componentes e o Diagrama de Implantao.

Os Diagramas Estticos, por fim, so os que retratam o sistema de uma
forma estrutural, e que so vlidos durante todo o ciclo de vida. o caso dos
Diagramas de Classes e de Objetos.

Portanto, o Diagrama de Classe atende nossa questo.

Resposta certa, letra d).

Desenvolvimento de Sistemas de Informao 2008) Diagramas de
pacotes UML so usados para ilustrar a arquitetura lgica de um sistema.
Assinale a opo correta a respeito da aplicao de diagramas de pacotes UML.
a) No permitem agrupar classes, outros pacotes e casos de uso.

Prof. Victor Dalton
b) Camadas de Interface de Usurio-UI no podem ser modeladas como
pacotes.
c) A dependncia (acoplamento) entre pacotes representada por uma
Associao.
d) Na UML, as associaes so definidas como o relacionamento semntico
entre dois pacotes.
e) Representam as camadas, subsistemas e pacotes (no significado Java).

Esta uma segunda abordagem para perguntar sobre diagramas UML. Ou
eles descrevem o diagrama e pedem para voc identific-lo ou apresentam 5
descries e pedem pra voc acertar a que tem relao com o diagrama
solicitado.

Diagrama de pacotes Descreve como os elementos so organizados
dentro de pacotes e suas dependncias, mostrando, inclusive, pacotes
importados (o import do Java) e extenses de pacotes, alm de pacotes
contidos em outros. Tem por objetivo representar de uma forma clara os
subsistemas englobados por um sistema de forma a determinar as partes que o
compem, oferecendo uma viso geral das camadas do sistema.

Diagrama de Pacotes

Responder este estilo de pergunta mais difcil, e provavelmente vai exigir
que voc trabalhe por eliminao.

A letra a), por exemplo, absurda;
Para a letra b), o prprio diagrama dado como exemplo, uma
contraprova, pois mostra a view dentro de um pacote;
A letra c) mistura conceitos, pois dependncia e associao so conceitos
paralelos. A dependncia representada por uma seta tracejada, como as
mostradas no exemplo;

Prof. Victor Dalton
A letra d) tambm mistura conceitos pois so as dependncias que so
definidas como o relacionamento semntico entre dois pacotes. As associaes,
por sua vez, estabelecem relacionamento entre objetos.

Nossa resposta correta, portanto, a letra e).

de Software/Desenvolvimento de Sistemas - 2010) Na taxonomia dos
diagramas de estrutura (S) e de comportamento (C) da UML, os diagramas de
Pacote, Classe, Sequncia e Objeto so, respectivamente, de
a) S, S, C e S.
b) S, S, C e C.
c) S, C, S e C.
d) C, S, C e S.
e) C, C, S e C.

Aps resolver as duas questes anteriores, esta fica fcil. Entretanto, para
lembrar na hora da prova, voc precisar ter assimilado visualmente cada
diagrama. Por isso, cada diagrama acima possui um exemplo visual.

Resposta certa, alternativa a).

2010) Dentre as etapas para o desenvolvimento de software em que a UML
pode ser aplicada, aquela em que sero modeladas somente classes que
pertenam ao domnio principal do problema do software, deixando de lado
classes tcnicas que gerenciem banco de dados, interface, comunicao,
concorrncia e outras, a etapa de
a) anlise de requisitos.
b) anlise sistmica.
c) projeto.
d) implementao.
e) testes/implantao.

Questo inteligente de FCC envolvendo UML e Engenharia de Software.
Ora, para que serve um diagrama de classes, como este?

Prof. Victor Dalton

Fique vontade para pensar e analisar as alternativas, se for o caso. Mas
perceba que, de imediato, este diagrama lhe fornece uma viso geral do
sistema. No cabe falar em anlise de requisitos ou testes. Forando a barra,
poderamos falar em projeto ou implementao, mas o enunciado frisou que
detalhes tcnicos esto excludos. Portanto, este diagrama serve para anlise
sistmica, e a alternativa b) a correta.

40 Questo) (FCC Assemblia Legislativa do Estado de So Paulo
Agente Tcnico Legislativo Tecnologia da Informao 2010) So
consideradas metodologias geis de desenvolvimento de software:
a) XP e UP.
b) SCRUM e DSDM.
c) SCRUM e RUP.
d) DSDM e Cascata.
e) Cascata e PRINCE2.

Ao falar de metodologias geis, certamente Scrum e XP vieram sua
cabea.
XP, oriunda de eXtreme Programming, uma filosofia de programao que
segue algumas prticas genricas, cujo conhecimento considero vlido. So
elas:
Jogo de Planejamento (Planning Game): O desenvolvimento feito em
iteraes semanais. No incio da semana, desenvolvedores e cliente renem-se
para priorizar as funcionalidades. Essa reunio recebe o nome de Jogo do

Prof. Victor Dalton
Planejamento. Nela, o cliente identifica prioridades e os desenvolvedores as
estimam. O cliente essencial neste processo e assim ele fica sabendo o que
est acontecendo e o que vai acontecer no projeto. Como o escopo reavaliado
semanalmente, o projeto regido por um contrato de escopo negocivel, que
difere significativamente das formas tradicionais de contratao de projetos de
software. Ao final de cada semana, o cliente recebe novas funcionalidades,
completamente testadas e prontas para serem postas em produo.
Pequenas Verses (Small Releases): A liberao de pequenas verses
funcionais do projeto auxilia muito no processo de aceitao por parte do cliente,
que j pode testar uma parte do sistema que est comprando. As verses
chegam a ser ainda menores que as produzidas por outras metodologias
incrementais, como o RUP.
Metfora (Metaphor): Procura facilitar a comunicao com o cliente,
entendendo a realidade dele. O conceito de rpido para um cliente de um
sistema jurdico diferente para um programador experiente em controlar
comunicao em sistemas em tempo real, como controle de trfego areo.
preciso traduzir as palavras do cliente para o significado que ele espera dentro
do projeto.
Projeto Simples (Simple Design): Simplicidade um princpio da XP.
Projeto simples significa dizer que caso o cliente tenha pedido que na primeira
verso apenas o usurio "teste" possa entrar no sistema com a senha "123" e
assim ter acesso a todo o sistema, voc vai fazer o cdigo exato para que esta
funcionalidade seja implementada, sem se preocupar com sistemas de
autenticao e restries de acesso. Um erro comum ao adotar essa prtica a
confuso por parte dos programadores de cdigo simples e cdigo fcil. Nem
sempre o cdigo mais fcil de ser desenvolvido levar a soluo mais simples
por parte de projeto. Esse entendimento fundamental para o bom andamento
do XP. Cdigo fcil deve ser identificado e substitudo por cdigo simples.
Time Coeso (Whole Team): A equipe de desenvolvimento formada por
pessoas engajadas e de forma multidisclipinar (no sentido de incluir pessoas
com cada uma das habilidades necessrias para o projeto).
Testes de Aceitao (Customer Tests): So testes construdos pelo
cliente e conjunto de analistas e testadores, para aceitar um determinado
requisito do sistema.
Ritmo Sustentvel (Sustainable Pace): Trabalhar com qualidade,
buscando ter ritmo de trabalho saudvel (40 horas/semana, 8 horas/dia), sem
horas extras. Horas extras so permitidas quando trouxerem produtividade para
a execuo do projeto. Outra prtica que se verifica neste processo a prtica
de trabalho energizado, onde se busca trabalho motivado sempre. Para isto o
ambiente de trabalho e a motivao da equipe devem estar sempre em
harmonia.
Reunies em p (Stand-up Meeting): Reunies em p para no se
perder o foco nos assuntos, produzindo reunies rpidas, apenas abordando
tarefas realizadas e tarefas a realizar pela equipe.

Prof. Victor Dalton
Posse Coletiva (Collective Ownership): O cdigo fonte no tem dono e
ningum precisa solicitar permisso para poder modificar o mesmo. O objetivo
com isto fazer a equipe conhecer todas as partes do sistema.
Programao em Pares (Pair Programming): a programao em
par/dupla num nico computador. Geralmente a dupla formada por um
iniciante na linguagem e outra pessoa funcionando como um instrutor. Como
apenas um computador, o novato que fica frente fazendo a codificao, e o
instrutor acompanha ajudando a desenvolver suas habilidades. Desta forma o
programa sempre revisto por duas pessoas, evitando e diminuindo assim a
possibilidade de defeitos. Com isto busca-se sempre a evoluo da equipe,
melhorando a qualidade do cdigo fonte gerado.
Padres de Codificao (Coding Standards): A equipe de
desenvolvimento precisa estabelecer regras para programar e todos devem
seguir estas regras. Desta forma parecer que todo o cdigo fonte foi editado
pela mesma pessoa, mesmo quando a equipe possui 10 ou 100 membros.
Desenvolvimento Orientado a Testes (Test Driven Development):
Primeiro crie os testes unitrios (unit tests) e depois crie o cdigo para que os
testes funcionem. Esta abordagem complexa no incio, pois vai contra o
processo de desenvolvimento de muitos anos. S que os testes unitrios so
essenciais para que a qualidade do projeto seja mantida.
Refatorao (Refactoring): um processo que permite a melhoria
continua da programao, com o mnimo de introduo de erros e mantendo a
compatibilidade com o cdigo j existente. Refabricar melhora a clareza (leitura)
do cdigo, divide-o em mdulos mais coesos e de maior reaproveitamento,
evitando a duplicao de cdigo-fonte;
Integrao Contnua (Continuous Integration): Sempre que produzir
uma nova funcionalidade, nunca esperar uma semana para integrar verso
atual do sistema. Isto s aumenta a possibilidade de conflitos e a possibilidade
de erros no cdigo fonte. Integrar de forma contnua permite saber o status real
da programao.

Entretanto, existem outras metodologias geis, como:
Desenvolvimento de Software Adaptativo (ASD): O apoio filosfico do
ASD concentra-se na colaborao humana e na auto-organizao. A
auto-organizao aparece quando agentes individuais independentes
cooperam para criar resultados emergentes. Um resultado
emergente uma propriedade alm da capacidade de qualquer
agente individual. Ciclo de vida: Especulao: iniciao do projeto e
planejamento adaptativo. Colaborao: pessoal motivado trabalha
junto de um modo que multiplica seus talentos e resultados criativos.
Aprendizagem que pode ocorrer de trs modos: foco nos grupos;
reviso tcnicas formais; ps-concluso.

Prof. Victor Dalton

ASD

Mtodo de Desenvolvimento de Sistemas Dinmicos: uma
metodologia de desenvolvimento de software originalmente baseada
em "Desenvolvimento Rpido de Aplicao" (RAD). DSDM uma
metodologia de desenvolvimento iterativo e incremental que enfatiza
o envolvimento constante do usurio.

DSDM

Seu objetivo entregar softwares no tempo e com custo estimados
atravs do controle e ajuste de requisitos ao longo do
desenvolvimento. DSDM um dos modelos de Metodologia gil de
desenvolvimento de software, e seu formato propriedade da Agile
Alliance.
Processo Unificado gil (AUP):Verso simplificada do RUP, adaptada
metodologia gil.

Portanto, nossa resposta correta a letra b).


Prof. Victor Dalton

41 Questo) (FCC INFRAERO Analista de Sistemas/Arquitetura
de Software 2011) Um dos principais conceitos do Scrum para atacar a
complexidade do desenvolvimento e gerenciamento de software a implantao
de um controle descentralizado, capaz de lidar mais eficientemente com
contextos pouco previsveis. Para tanto, o gerenciamento distribudo por meio
de trs agentes independentes que so:
a) Product Owner, Scrum Team e Scrum Master.
b) Product Owner, Product Backlog e Planning Meeting.
c) Product Owner, Sprint e Planning Meeting.
d) Sprint, Scrum Master e Planning Meeting.
e) Sprint, Scrum Team e Product Backlog.

O Scrum uma metodologia de desenvolvimento iterativo e
incremental para gerenciamento de projetos e desenvolvimento gil de software.
Scrum no um processo nem descreve o que se deve fazer em cada
situao. Ele usado para trabalhos complexos nos quais difcil predizer tudo o
que ir ocorrer.
O Scrum um conjunto de passos que contm grupos de prticas e papis
pr-definidos. Os nicos papis so:
1. O Proprietrio do Produto, ou Product Owner, que representa os
stakeholders e o negcio;
2. o Scrum Master, que mantm os processos (normalmente no lugar de um
gerente de projeto);
3. a Equipe, ou Team, um grupo multifuncional com cerca de 7 pessoas e
que fazem a anlise, projeto, implementao, teste, etc.

Sprint

Um sprint a unidade bsica de desenvolvimento em Scrum. Sprints
tendem a durar entre uma semana e um ms, e so um esforo dentro de uma
"caixa de tempo" (ou seja, restrito a uma durao especfica) de comprimento
constante.
Cada sprint precedido por uma reunio de planejamento, onde as tarefas
para o sprint so identificadas e um compromisso estimado para o objetivo do
sprint definido e seguido por uma reunio de reviso ou de retrospectiva, onde
o progresso revisto e lies para os prximos sprints so identificadas.
Durante cada sprint, a equipe cria um incremento de produto
potencialmente entregvel (por exemplo, software funcional e testado). O
conjunto de funcionalidades que entram em um sprint vm do backlog do
produto, que um conjunto de prioridades de requisitos de alto nvel do trabalho
a ser feito. Quais itens do backlog entram para o sprint so determinados
durante a reunio de planejamento do sprint. Durante esta reunio, o Product
Owner informa a equipe dos itens no backlog do produto que ele ou ela quer

Prof. Victor Dalton
concludos. A equipe ento determina quantos eles podem se comprometer a
concluir durante o prximo sprint, e registram isso no backlog do sprint. Durante
um sprint, ningum est autorizado a alterar o backlog do sprint, o que significa
que os requisitos so congelados para esse sprint. O desenvolvimento de cada
sprint deve terminar na "caixa de tempo" prevista. Se os requisitos no so
completados por qualquer motivo, eles so deixados de fora e voltam para o
backlog do produto. Depois que um sprint completado, a equipe demonstra
como usar o software.
O Scrum permite a criao de equipes auto organizadas, encorajando a
cooperao de todos os membros da equipe e a comunicao verbal entre todos
os membros e disciplinas da equipe no projeto.

Artefatos

Product Backlog
Um backlog uma lista de itens priorizados a serem desenvolvidos para um
software. O Product Backlog mantido pelo Product Owner e uma lista de
requisitos que tipicamente vm do cliente. O Product Backlog pode ser alterado
a qualquer momento pelo Product Owner ou por deciso deste.
Sprint backlog
O Sprint backlog uma lista de itens selecionados do Product backlog e
contm tarefas concretas que sero realizadas durante o prximo sprint para
implementar tais itens selecionados. O Sprint Backlog uma representao em
tempo real do trabalho que o Development Team planeja concluir
na sprint corrente, e ele pertence unicamente ao Development Team.
Planejamento de sprint
Antes de todo sprint, o Product Owner, o Scrum Master e a Equipe decidem
no que a equipe ir trabalhar durante o prximo sprint. O Product Owner
mantm uma lista priorizada de itens de backlog, o backlog do produto, o que
pode ser repriorizado durante o planejamento do sprint. A Equipe seleciona itens
do topo do backlog do produto. Eles selecionam somente o quanto de trabalho
eles podem executar para terminar. A Equipe ento planeja a arquitetura e o
design de como o backlog do produto pode ser implementado. Os itens
do backlog do produto so ento destrinchados em tarefas que se tornam
o backlog do sprint.

Reunies

Daily Scrum
Cada dia durante o sprint, uma reunio de status do projeto ocorre. Isso
chamado de "scrum dirio". Esta reunio tem diretrizes especficas:
A reunio comea precisamente no horrio marcado.
Todos so bem-vindos, mas apenas "poucos" podem falar.
O encontro tem durao determinada (TimeBox) e dura 15 minutos.
A reunio deve acontecer no mesmo local e mesma hora todos os dias

Prof. Victor Dalton
Durante a reunio, cada membro da equipe responde a trs perguntas:
O que voc tem feito desde ontem?
O que voc est planejando fazer hoje?
Voc tem algum problema impedindo voc de realizar seu objetivo?
papel do Scrum Master para facilitar a resoluo desses impedimentos.
Normalmente, isso deve ocorrer fora do contexto do Daily Scrum para que a
reunio possa durar menos de 15 minutos.
Reunio de Planejamento da Sprint (Sprint Planning Meeting)
No incio do ciclo de sprint (a cada 7-30 dias), um Sprint Planning Meeting
realizado.
Selecione o trabalho que est a ser feito.
Prepare o Sprint Backlog que detalha o tempo que levar para fazer esse
trabalho, com toda a equipe.
Identificar e comunicar o quanto o trabalho susceptvel de ser feito
durante o sprint atual.
Dividida em duas partes:
Parte 1 (Primeiras quatro horas): Team Product Owner: dilogo para
priorizar o Product Backlog.
Parte 2 (Prximas quatro horas): Team apenas: hash de um plano para a
Sprint, resultando na Sprint Backlog.

No final de um ciclo de sprint, so realizadas duas reunies: a "Sprint Review" e
do "Sprint Retrospective".

Reunio de Reviso da Sprint (Sprint Review)
Rever o trabalho que foi concludo e no concludo.
Apresentar o trabalho realizado para os interessados (ou "a demo"). Um
trabalho incompleto no pode ser demonstrado.
Retrospectiva da Sprint (Sprint Retrospective)
Todos os membros da equipe refletem sobre a sprint passada.
Trs questes principais so feitas na retrospectiva sobre o sprint: O que
deu errado? O que deu certo? O que poderia ser melhorado para o prximo
sprint?


Prof. Victor Dalton

Se voc achou o Scrum um pouco utpico, eu posso garantir que no .
Utilizamos ele no Banco Central pra valer, e os projetos andam! Com reunies
dirias, sprints e tudo o mais!

Nossa resposta correta, letra a).

42 Questo) (FCC TRT 6 Regio Analista Judicirio Tecnologia
da Informao 2012) Na metodologia Scrum, NO faz parte de uma reviso
do sprint (sprint review) o seguinte procedimento:
a) Todo o time colabora no que deve ser feito em seguida, de modo que
esta reviso contribua para reunies de planejamento subsequentes.
b) O proprietrio do produto identifica o que est pronto e o que ainda est
por fazer.
c) O time de desenvolvimento discute quais fatores positivos e negativos
ocorreram durante o sprint e como os problemas foram resolvidos.
d) O time de desenvolvimento apresenta o trabalho que foi desenvolvido e
responde questes sobre o incremento.
e) Todo o time cria um plano para implementar melhorias no modo como o
time efetua seu trabalho.

Veja que, apesar de uma carga terica relativamente forte sobre Scrum na
questo anterior, a FCC foi mais fundo ainda, pedindo pra voc dizer qual das
atividades acima no da Sprint Review. Por questes como essa que eu
valorizo a leitura complementar.
No caso, a letra e), cuja atividade da Sprint Retrospective.

Prof. Victor Dalton
CONSIDERAES FINAIS

Espero que vocs tenham compreendido minha metodologia de trabalho.
Vejo este conjunto de apostilas com as seguintes finalidades.
1) Serve para familiarizao com questes de concursos, para aqueles que
ainda so novatos neste ambiente;
2) Serve para dar um rpido ganho de conhecimento sobre um assunto
que seja novo, ou que voc domine muito pouco;
3) Serve tambm para autodiagnostico. Determinada aula que voc sinta
muita dificuldade para responder aos exerccios, ou que voc erre muitas
questes, pode ser um sinal de que necessrio adquirir ou ler as fontes
recomendadas, para sanar esse ponto falho;
4) Ainda, nas proximidades da prova, a lista de exerccios servir como
reviso. Certamente teremos mais de 350 questes para reviso da matria, ao
trmino das aulas.
Como vocs j devem ter percebido, no tenho inteno de substituir
bibliografias consagradas de estudo. Honestamente, no acredito em apostilas
milagrosas, no estilo aqui tem tudo que voc precisa para gabaritar
determinado assunto. Mesmo porque as bancas esto sempre inventando novas
questes, justamente para derrubar os concurseiros de planto, que vivem
APENAS de mementos e mapas mentais. necessrio SIM ler os autores e
bibliografias consagrados, para fazer aquele algo mais na sua pontuao.
Tenho certeza que os concurseiros mais experientes concordam comigo.
Por isso, resolvi divulgar fontes de estudo, em um verdadeiro trabalho de
consultoria, e estou aberto a debat-las. Nossa principal meta a sua
aprovao.
E digo mais: caso voc no consiga aprovao neste certame (toc toc toc,
vira essa boca para l), dificilmente voc far outro curso comigo, uma vez que
as dicas debatidas serviro para que voc, tranquilamente, estude por conta
prpria para outros certames.
Espero rev-lo como meu aluno efetivo.
Grande abrao, e fora nos estudos!

Victor Dalton


Prof. Victor Dalton
LISTA DE EXERCCIOS

Desenvolvimento de Sistemas da Informao - 2008) A Engenharia de
Software uma disciplina da engenharia que se ocupa de todos os aspectos da
produo de software, desde os estgios iniciais de especificao do sistema at
a manuteno do mesmo. A Engenharia de Software adota mtodos de
engenharia de software que
a) so um conjunto de atividades, cuja meta o desenvolvimento ou a
evoluo do software.
b) so uma representao simplificada de um processo de software,
apresentada a partir de uma perspectiva especfica.
c) so abordagens estruturadas para o desenvolvimento de software, que
incluem modelos de sistemas, notaes, regras, recomendaes 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.

Desenvolvimento de Sistemas da Informao - 2012) A escolha de um
modelo fortemente dependente das caractersticas do projeto. Os principais
modelos de ciclo de vida podem ser agrupados em trs 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.

Tecnologia da Informao - 2010) As atividades do modelo espiral de
Engenharia de Software so:
a) Planejamento, Anlise dos Componentes, Anlise de Hierarquia e
b) Planejamento, Anlise dos Riscos, Engenharia e Avaliao feita pelo
cliente.
c) Projeto, Anlise dos Benefcios, Engenharia e Avaliao feita pelo gestor.
d) Planejamento, Eliminao dos Riscos, Anlise de Contingncia e
e) Planejamento, Projeto, Anlise dos Riscos e Engenharia.

Prof. Victor Dalton
de Software/Desenvolvimento de Sistemas - 2010) No modelo de
desenvolvimento de software em espiral, cada loop na espiral representa
a) a necessidade de retornar ao incio da fase em que se encontra.
b) um processo de reengenharia.
c) uma disciplina de software.
d) uma fase do processo de software.
e) uma atividade paralela.

Norte - Analista de Tecnologia da Informao Especialidade
Engenharia de Software/Desenvolvimento de Sistemas - 2010) O modelo
em espiral difere principalmente dos outros modelos de processo de software por
a) no contemplar o prottipo.
b) reconhecer explicitamente o risco.
c) no ter fases.
d) possuir uma fase nica evolucionria.
e) no contemplar o projeto do produto.

2012) O processo de desenvolvimento em cascata um exemplo de processo
dirigido a planos, pois, em princpio, necessrio planejar e programar todas as
atividades do processo antes de comear a trabalhar nelas. So exemplos de
estgios desse modelo:
a) Integrao de Produto, Definio de Processo Organizacional e
Gerenciamento de Riscos.
b) Anlise e Definio de Requisitos, Implementao de Teste Unitrio e
Integrao e Teste de Sistema.
c) Inicial, Gerenciado e Em Otimizao.
d) Engenharia de Requisitos, Ciclo de Vida de Projetos e Gesto de
Incidentes.
e) Acompanhamento e Controle de Projeto, Medio e Anlise e
Desenvolvimento de Requisitos.

2012) A engenharia de software baseada em reuso uma estratgia da
engenharia em que o processo de desenvolvimento orientado para o reuso de
softwares existentes. Dentre os benefcios do reuso de software, INCORRETO
afirmar:

Prof. Victor Dalton
a) Preencher uma biblioteca de componentes reusveis e garantir que
desenvolvedores de software possam utilizar essa biblioteca so aes no
onerosas, pois processos de desenvolvimento no precisam ser adaptados para
utilizar essa biblioteca.
b) Devido ao custo do software existente j ser conhecido, o risco de
processo reduzido.
c) Especialistas em aplicaes podem desenvolver softwares reusveis que
encapsulem seu conhecimento, tornando seu uso mais eficaz.
d) Muitas vezes os custos gerais de desenvolvimento no so to
importantes quanto entregar um sistema ao mercado o mais rpido possvel. O
reuso de um software pode acelerar a produo do sistema.
e) Alguns padres, como os de interface de usurio, podem ser
implementados como um conjunto de componentes reusveis. O uso de
interfaces de usurio-padro melhora a confiana, pois os usurios cometem
menos erros quando so apresentados a interfaces familiares.

8 Questo) (ESAF Agncia Nacional de guas Analista de
Sistemas 2009) Analise as seguintes afirmaes sobre requisitos de sistemas
de software:
I. Requisitos funcionais declaram as funes que o sistema deve fornecer,
seu comportamento, e ainda, o que o sistema no deve fazer.
II. Requisitos de domnio so, exclusivamente, funcionais, pois exibem as
caractersticas do domnio de aplicao do sistema.
III. Requisitos no-funcionais compreendem restries sobre servios ou
funes do sistema.

Assinale a opo correta.

a) Apenas as afirmaes I e II so verdadeiras.
b) Apenas as afirmaes I e III so verdadeiras.
c) Apenas as afirmaes II e III so verdadeiras.
d) As afirmaes I, II e III so verdadeiras.
e) Nenhuma das afirmaes verdadeira.

(FCC Agente Fiscal de Rendas Tecnologia da Informao - 2009)
Para responder as questes de 9 e 10, considere:

necessrio que o software calcule os salrios dos diaristas e mensalistas
e emita relatrios mensais sumariados por tipo de salrio. Entretanto, a base de
dados deve estar protegida e com acesso restrito aos usurios autorizados. De
qualquer forma, o tempo de resposta das consultas no deve superar os quinze
segundos, pois inviabilizaria todo o investimento nesse sistema. Devo lembrar
que os relatrios individuais dos departamentos, nos quais constam os salrios

Prof. Victor Dalton
dos funcionrios, devem ser emitidos quinzenalmente em razo dos
adiantamentos e vales que recebem. fundamental que o software seja
operacionalizado usando cdigo aberto.
Necessito, ainda, forte gerenciamento de risco, prazo e custo, porque a
entrega do produto final no pode ultrapassar o prazo de oito meses a contar da
data de incio do projeto.

A frase acima, expressa por um funcionrio do cliente, aborda alguns
requisitos de software especificados para um sistema de gesto de pessoal.

9 Questo) No texto, so requisitos no-funcionais:

a) no pode ultrapassar o prazo de oito meses e necessrio que o software
calcule os salrios dos diaristas e mensalistas.
b) os relatrios individuais dos departamentos, nos quais constam os
salrios dos funcionrios, devem ser emitidos quinzenalmente e em razo dos
aberto e os relatrios individuais dos departamentos, nos quais constam os
salrios dos funcionrios, devem ser emitidos quinzenalmente.
d) tempo de resposta das consultas no deve superar os quinze segundos e
entrega do produto final no pode ultrapassar o prazo de oito meses.
e) pois inviabilizaria todo o investimento nesse sistema e em razo dos

10 Questo) No texto, so requisitos funcionais:

a) calcule os salrios dos diaristas e mensalistas e os relatrios individuais
dos departamentos, nos quais constam os salrios dos funcionrios, 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 usurios autorizados.
aberto e emita relatrios mensais sumariados por tipo de salrio.
d) emita relatrios mensais sumariados por tipo de salrio e Necessito,
ainda, forte gerenciamento de risco, prazo e custo.
e) a base de dados deve estar protegida e com acesso restrito aos usurios
autorizados e entrega do produto final no pode ultrapassar o prazo de oito
meses.

Tecnologia da Informao 2008) Os requisitos de um sistema so
descries dos servios fornecidos pelo sistema e as suas restries

Prof. Victor Dalton
operacionais. Indique a opo que corretamente se relaciona com a anlise ou
gerenciamento de requisitos.
a) Requisitos de sistema so declaraes do usurio que definem,
detalhadamente, as funes, os servios e as restries operacionais do sistema.
b) As representaes de dados usadas nas interfaces de sistemas so
exemplos de requisitos funcionais.
c) A exigncia de que o sistema deva fornecer telas apropriadas para o
usurio ler os documentos no repositrio de documentos um exemplo de
requisito funcional.
d) A exigncia de que o sistema no deva revelar quaisquer informaes
pessoais sobre os usurios do sistema ao pessoal de vendas que o utiliza, com
exceo do nome e cargo, um exemplo de requisito funcional.
e) Avaliar se os requisitos associados ao desempenho, ao comportamento e
s caractersticas operacionais do sistema foram explicitamente declaradas
uma tarefa de especificao de requisitos.

12 Questo) (Formulao pessoal) uma tcnica de elicitao de
Requisitos:
a) Entrevista com stakeholder, por meio de formulrios predefinidos
(entrevista fechada) ou no (entrevista aberta). Por meio dela procura-se saber
o que o interessado espera ou deseja no sistema.
b) Descrio de cenrios, na qual comea-se com um esboo da interao
e, durante a elicitao, adicionam-se detalhes para uma descrio completa
dessa interao.
c) Elaborao de casos de uso, que so cenrios descritos em um diagrama
UML, visual, tambm discutidos com os interessados.
d) Etnografia, que uma tcnica na qual o analista insere-se no ambiente
de trabalho como um observador, procurando levantar os requisitos do sistema.
e) Todas as alternativas esto corretas.

de Software/Desenvolvimento de Sistemas - 2010) Na engenharia de
software, etnografia
a) uma fase do processo de software aplicada no modelo em cascata.
b) uma fase do processo de software aplicada no modelo em espiral.
c) uma tcnica de observao que pode ser usada para compreender os
requisitos sociais e organizacionais.
d) uma tcnica aplicada na engenharia de requisitos cujo objetivo definir,
a priori, as classes que contm elementos grficos (BLOB).
e) um projeto cujo principal objetivo criar interfaces grficas, que
facilitam o acesso do usurio (GUI).


Prof. Victor Dalton
14 Questo) (FCC Agente Fiscal de Rendas Tecnologia da
Informao - 2009) Quanto aos requisitos de software, considere:

I. importante que se estabeleam prticas para encontrar, documentar,
organizar e rastrear os requisitos variveis de um sistema.
II. Etnografia (observao e anlise dos fluxos de trabalho) e sesses de
JAD so prticas que podem ser aplicadas na elicitao.
III. Elicitar significa descobrir os requisitos de um sistema por meio de
entrevistas, de documentos do sistema existente, de anlise do domnio do
problema ou de estudos do mercado.


a) I, apenas.
b) I e II, apenas.
c) I, II e III.
d) II e III, apenas.
e) III, apenas.

15 Questo) (UEL Secretaria do Estado da Administrao e da
Previdncia 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 caractersticas antes da
Implementao. seu papel realizar a interao entre o que deve ser feito e
como deve ser feito.
Esta afirmao refere-se a:

a) Arquitetura do Software.
b) Planejamento do Software.
c) Engenharia de Requisitos.
d) Estimativas do Projeto.
e) Processo de desenvolvimento de Software.

16 Questo) (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.


Prof. Victor Dalton
II. No estgio de levantamento e anlise dos requisitos, os membros da
equipe tcnica de desenvolvimento do software trabalham com o cliente e os
usurios finais do sistema para descobrir mais informaes sobre o domnio da
aplicao, que servios o sistema deve fornecer, o desempenho exigido do
sistema, as restries de hardware, entre outras informaes.

III. Na medida em que a informao de vrios pontos de vista coletada,
os requisitos emergentes so consistentes.

IV. A validao de requisitos se ocupa de mostrar que estes realmente
definem o sistema que o cliente deseja. Ela importante porque a ocorrncia de
erros em um documento de requisitos pode levar a grandes custos relacionados
ao retrabalho.



17 Questo) (FGV Senado Federal - Analista Sistemas 2012) O
processo de Engenharia de Requisitos realizado por meio da execuo de sete
funes distintas: concepo, levantamento, elaborao, negociao, especi
validao e gesto. Nesse contexto, observe a lista abaixo, que representa um
conjunto de questes a serem utilizadas como checklist dentro de uma dessas
funes.

A funo :

Prof. Victor Dalton

a) Elaborao
b) Negociao
c) Especificao
d) Validao
e) Gesto

18 Questo) (ESAF Analista de Finanas e Controle Tecnologia
da Informao 2003 - adaptada) Analise as seguintes afirmaes relativas
Engenharia de Software:
I. A anlise de requisitos responsvel pela especificao dos requisitos de
software e hardware que sero utilizados durante o processo de
desenvolvimento de um sistema.
II. A anlise de requisitos define a metodologia de programao a ser
utilizada no desenvolvimento do sistema.
III. A especificao de requisitos fornece ao desenvolvedor e ao cliente os
parmetros para avaliar a qualidade logo que o sistema for construdo.
IV. A anlise de requisitos possibilita que o engenheiro de software
compreenda o sistema que ir desenvolver.

Esto corretos os itens:

a) I e II
b) II e III
c) III e IV
d) I e III
e) II e IV

Tecnologia da Informao - 2005) Analise as seguintes afirmaes
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 ento este ter alcanado um ndice de
qualidade de 100%.
III. O controle de qualidade utiliza inspees para provar a existncia de
qualidade dentro de um produto final do projeto.
IV. Um ambiente de desenvolvimento de software, no processo de evoluo
da qualidade dos seus produtos e servios, deve substituir o processo de
Controle da Qualidade pelo processo de Garantia da Qualidade.


Prof. Victor Dalton

a) I e II
b) II e III
c) III e IV
d) I e III
e) II e IV

20 Questo)(FCC Tribunal de Contas do Estado do Paran -
Analista de Controle Informtica - 2011) Mtricas de software podem ser
divididas em medidas diretas e indiretas, sob o ponto de vista de medio, e em
mtricas de produtividade e de qualidade, sob o ponto de vista de aplicao.
Nesse contexto, as mtricas que se concentram na sada do processo de
engenharia de software e as mtricas que indicam o quanto o software atende
aos requisitos definidos pelo usurio, podem ser classificadas, respectivamente,
como mtricas de
a) custo e de complexidade, em medidas indiretas.
b) esforo e de confiabilidade, em medidas diretas.
c) produtividade e de qualidade, em medidas indiretas.
d) qualidade e de eficincia, em medidas diretas.
e) velocidade de execuo e tcnica, em medidas diretas.

Tecnologia da Informao - 2005)As mtricas de produtos de software
dividem-se em classes: mtricas dinmicas coletadas por meio de medies
realizadas em um programa em execuo, e mtricas estticas coletadas por
meio de medies realizadas em representaes do sistema. Indique a opo
que descreve corretamente uma mtrica esttica do produto de software.
a) ndice de fog uma medida da complexidade de controle de um
programa.
b) Complexidade ciclomtica uma medida da extenso mdia das
palavras e das sentenas em documentos, ponderada por complexidade.
c) Extenso de identificadores o nmero de mtodos includos em uma
classe, relacionada com a facilidade de compreenso do programa.
d) Extenso de cdigo uma medida de extenso mdia de um programa
e est associada complexidade da lgica de controle do programa.
e) Fan-in/Fan-out uma medida do nmero de funes ou mtodos que
chamam alguma outra funo ou mtodo.

22 Questo) (UEL Analista de Informtica Jnior
Desenvolvimento de Sistemas - 2009) A norma ISO 9126 (Caractersticas

Prof. Victor Dalton
de Qualidade de Software define 6 caractersticas (requisitos) de qualidade
desejveis para um produto de software.
Considere os itens a seguir:

I. Evidencia o conjunto de funes que atendem s necessidades explcitas
e implcitas para a finalidade a que se destina o produto e suas propriedades
especficas

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

III. Evidencia a facilidade de uso do produto, bem como o julgamento
individual desse uso, por um conjunto de usurios estabelecido ou subentendido.

IV. Evidencia a compatibilidade entre os recursos e os tempos envolvidos,
assim como o nvel de desempenho requerido para o produto, sob condies
estabelecidas.

V. Evidencia a possibilidade de se utilizar o produto em diversas
plataformas, com pequeno esforo para adaptao.

VI. Evidencia a facilidade para fazer modificaes especficas no software.

Assinale a alternativa que apresenta a sequncia correta em relao aos
itens colocados anteriormente.

a) Funcionalidade; Eficincia; Usabilidade; Confiabilidade; Portabilidade;
Manutenibilidade.
b) Funcionalidade; Confiabilidade; Portabilidade; Eficincia; Usabilidade;
Manutenibilidade.
c) Confiabilidade; Usabilidade; Eficincia; Portabilidade; Manutenibilidade;
Funcionalidade.
d) Funcionalidade; Confiabilidade; Usabilidade; Eficincia; Portabilidade;
Manutenibilidade.
e) Confiabilidade; Funcionalidade; Usabilidade; Eficincia; Portabilidade;
Manutenibilidade.

23 Questo) (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 tcnica utilizada para se projetar casos de teste no
qual o programa ou sistema considerado uma caixa preta e, para test-lo, so
fornecidas entradas e avaliadas as sadas geradas para verificar se esto em
conformidade com os objetivos especificados.

Prof. Victor Dalton

II. A tcnica estrutural estabelece os requisitos de teste com base em uma
dada implementao, requerendo a execuo de partes ou de componentes
elementares do programa.

III. Teste um conjunto de atividades que no pode ser planejado
antecipadamente, porm deve ser realizado sistematicamente.

IV. Um mdulo driver chama o mdulo que est sendo testado, devendo
conter apenas as inicializaes das variveis globais e dos parmetros que sero
utilizados para a chamada do mdulo testado.

a) Somente as afirmativas I e III esto corretas.
b) Somente as afirmativas III e IV esto corretas.
c) Somente as afirmativas I e II esto corretas.

24 Questo) (FCC TJ/RJ Analista Judicirio - Analista de
Sistemas - 2012) No que se refere a testes de software, correto afirmar
que
a) o teste de operao a fase onde testada a ergonomia da interface de
uso do software.
b) o teste da caixa preta (teste funcional), baseia-se em analisar os
arquivos de log do sistema procurando por mensagens de funcionamento
inconsistente.
c) um teste bem sucedido um teste que no encontra nenhum erro no
software.
d) o teste da caixa branca (teste estrutural), baseia-se em testar as
estruturas do cdigo fonte, como comandos condicionais e de repetio.
e) um caso de teste uma categoria de possveis resultados na execuo
de testes.

25 Questo) )(FCC Tribunal de Contas do Estado do Paran -
Analista de Controle Informtica - 2011) Segundo Sommerville, aps um
sistema ser completamente integrado, possvel testar propriedades como a de
desempenho do sistema. Neste contexto, considere:
I. Testes de desempenho devem ser produzidos de forma a garantir que o
sistema possa processar a sua carga prevista, sendo que tais testes geralmente
so planejados para que a carga seja continuamente aumentada at que o
sistema apresente desempenho fora do aceitvel.

Prof. Victor Dalton
II. Os testes de desempenho devem determinar se um sistema corresponde
s suas exigncias, sendo que a descoberta de defeitos ou problemas no sistema
no enfoque desta etapa.
III. Para determinar se o desempenho est sendo atingido, pode ser
necessrio a construo de um perfil operacional, que a listagem de todo o
grupo de operadores/usurios que faro uso deste sistema.
a) I, apenas.
b) I, II, III.
c) III, apenas.
d) I e II, apenas.
e) II e III, apenas.

26 Questo) (UEL POSCOMP 2011) Tendo em vista a complexidade
envolvida no desenvolvimento de um sistema de software, importante
assegurar que ele cumpra com suas especificaes e atenda s necessidades dos
usurios.
Sobre o desenvolvimento de software, considere as afirmativas a seguir.

I. A Validao tem como objetivo responder. Estamos construindo o
produto certo? J a Verificao busca responder: Estamos construindo o
produto corretamente?

II. Em um cadastro, encontra-se um campo de entrada solicitando o ano de
nascimento, sendo vlidos valores entre 1900 e 2011. Os casos de teste para
este campo, considerando a tcnica de anlise de valor limite, so:
1899,1900,1901,2010,2011,2012 e 0.

III. As atividades de Verificao e Validao envolvem atividades de anlise
esttica e de anlise dinmica do produto em desenvolvimento, e apenas as
atividades de anlise dinmica envolvem a execuo do produto.

IV. Um dos objetivos dos mtodos de teste de caixa preta garantir que
todos os caminhos de um programa tenham sido exercitados pelo menos uma
vez, podendo-se aplicar a tcnica do teste do caminha bsico para este fim.



Prof. Victor Dalton
27 Questo) (Formulao pessoal) Segundo Pressmann, cada um dos
elementos de informao que so criados durante o desenvolvimento de um
produto de software, que so identificados de maneira nica e cuja evoluo
passvel de rastreamento, refere-se a
f) Item de software
g) Componente de software
h) Item de configurao
i) Componente de dados
j) Componente de programa

28 Questo) (Formulao Pessoal) Procedimentos de gerenciamento de
mudana dizem respeito anlise de custo e benefcio das mudanas propostas,
aprovao das mudanas viveis e rastreabilidade de quais componentes do
sistema foram alterados. O processo de gerenciamento de mudana deve surtir
efeito quando o software ou a documentao associada so colocados em
baseline pela equipe de gerenciamento de configuraes.
O primeiro estgio para a solicitao de uma mudana para o sistema
a) Modificar o item de configurao envolvido e notificar equipe de
gerenciamento de mudana
b) Preencher uma Requisio de Mudana, ou Formulrio de Solicitao de
Mudana, e encaminhar ao Comit de Controle de Mudanas
c) Modificar o item de configurao envolvido e preencher o formulrio para
envio ao Comit de Controle de Mudanas
d) Notificar o Gerenciamento de Problema que deseja fazer uma mudana
no sistema
e) Aguardar uma falha no sistema para preencher uma Requisio de
Mudana

29 Questo) (Formulao Pessoal) Sobre o Gerenciamento de
Mudanas, analise as afirmativas abaixo:
I. As mudanas em um sistema podem ser levantadas proativamente, para
resolver erros ou adaptar-se a circunstncias de mudana, ou reativamente,
para gerar benefcios ao negcio, como reduzir custos e melhorar os servios.
II. Gerenciar mudanas no fazer mudanas que no ofeream risco:
fazer mudanas de forma que os riscos sejam mapeados e gerenciados.
III. Mudanas de alto custo e mudanas de risco so mudanas tpicas cuja
autoridade de mudana a gerncia de TI.
IV. Mudanas urgentes sempre devem passar pela autoridade do negcio.


a) Somente a afirmativa II est correta.
b) Somente as afirmativas II e III esto corretas.

Prof. Victor Dalton
c) Somente as afirmativas II e IV esto corretas.

30 Questo) (Formulao Pessoal) responsabilidade da Gerncia de
Configurao:
IV. Definir e controlar os componentes de servios e infraestrutura do
sistema, mantendo informaes precisas sobre os estados dos servios e
infraestrutura atual e planejada.
V. Manter um banco de dados de configurao (Configuration Management
Data Base) com todas as informaes relevantes sobre as configuraes do
sistema e os itens de configurao.
VI. Avaliar o impacto de uma mudana no sistema.

c) Somente as afirmativas II e III esto corretas.
d) Todas as afirmativas esto corretas.
e) Apenas a afirmativa II est correta.

2010) Em relao anlise e ao projeto orientados a objetos, correto
afirmar:
a) A orientao a objetos no leva em conta a utilizao da prototipao,
dada as restries desse modelo de desenvolvimento de software quanto
reusabilidade.
b) Uma das regras de normalizao aplicada s tabelas de objetos de dados
especifica que uma instncia de um objeto pode ter diversos valores para cada
atributo.
c) Se a informao sobre um objeto em potencial precisar ser lembrada
para que o sistema possa funcionar, esse objeto no poder ser utilizado
durante a anlise.
d) Representar os objetos e suas relaes o principal objetivo do
Diagrama Entidade-Relacionamento (E-R).
e) Um Diagrama de Fluxo de Dados (DFD) deve, alm do fluxo da
informao, descrever detalhadamente a lgica procedimental do sistema.

Desenvolvimento de Sistemas de Informao 2008) A linguagem de
Modelagem Unificada (UML) emergiu como notao de diagramao de padro,
de fato e de direito, para a modelagem orientada a objetos. Desta forma, a

Prof. Victor Dalton
sentena que conceitua apropriadamente a UML, segundo o OMG-Object
Management Group,
a) um mtodo para especificar e modelar os artefatos dos sistemas.
b) um processo de especificao e modelagem de sistemas orientados a
objeto.
c) uma linguagem para implementar os conceitos da orientao a objetos.
d) uma linguagem visual para especificar, construir e documentar os
artefatos dos sistemas.
e) um mtodo comum para a representao da orientao a objetos.

Sistemas 2002)Analise as seguintes afirmaes relativas UML:
I. Ao uma abstrao representativa de entidades externas que
interagem com um produto ou sistema;
II. Atributo a descrio de um espao com nome e tipo, dentro de uma
classe, onde cada objeto desta classe mantm um valor deste tipo;
III. Classe o descritor para um conjunto de objetos que partilham os
mesmos atributos, operaes, relacionamentos e comportamento;
IV. Evento a condio ou situao de vida de um objeto durante a qual
ele executa uma atividade.


a) I e II
b) II e III
c) III e IV
d) I e III
e) II e IV

34 Questo) (ESAF Agncia Nacional de guas Tecnologia da
Informao e Comunicao Desenvolvimento de Sistemas - 2009) Em
UML, o relacionamento utilizado para expressar herana entre classes e
interfaces a
a) multiplicidade.
b) dependncia.
c) agregao.
d) associao.
e) generalizao.

2012) Sobre Programao Orientada a Objetos e UML, considere:

Prof. Victor Dalton
I. Os diagramas de classe so usados no desenvolvimento de um modelo
de sistema orientado a objetos para mostrar as classes de um sistema e as
associaes entre essas classes.
II. A UML tem um tipo especfico de associao para denotar a
generalizao. Em uma generalizao, os atributos e operaes associados com
as classes de nvel alto (superclasses) tambm esto associados com as de nvel
baixo (subclasses).
III. A UML fornece um tipo especial de associao entre classes chamada
agregao, que significa que um objeto (todo) composto de outros objetos (as
partes).
IV. Os modelos comportamentais descrevem o modelo esttico do domnio
e qual a reao comportamental de interao entre as classes. Eles mostram o
que acontece ou deve acontecer quando o sistema responde a um estmulo de
seu ambiente.
Est correto o que consta APENAS em
a) I e II.
b) I, III e IV.
c) I, II e III.
d) II, III e IV.
e) III e IV.

Sistemas 2002 - adaptada) Um gerente de projeto sabe que o modo para
descrever os vrios aspectos de modelagem pela UML por meio da notao
definida pelos seus vrios tipos de diagramas. Em um determinado projeto, ele
necessita de um diagrama esttico onde a estrutura descrita sempre vlida em
qualquer ponto do ciclo de vida do sistema. O diagrama UML recomendado para
suprir esta necessidade deste gerente o
a) diagrama de componente.
b) diagrama de comunicao.
c) diagrama de sequencia.
d) diagrama de classe.
e) diagrama de implantao.

Desenvolvimento de Sistemas de Informao 2008) Diagramas de
pacotes UML so usados para ilustrar a arquitetura lgica de um sistema.
Assinale a opo correta a respeito da aplicao de diagramas de pacotes UML.
a) No permitem agrupar classes, outros pacotes e casos de uso.
b) Camadas de Interface de Usurio-UI no podem ser modeladas como
pacotes.
c) A dependncia (acoplamento) entre pacotes representada por uma
Associao.

Prof. Victor Dalton
d) Na UML, as associaes so definidas como o relacionamento semntico
entre dois pacotes.
e) Representam as camadas, subsistemas e pacotes (no significado Java).

de Software/Desenvolvimento de Sistemas - 2010) Na taxonomia dos
diagramas de estrutura (S) e de comportamento (C) da UML, os diagramas de
Pacote, Classe, Sequncia e Objeto so, respectivamente, de
a) S, S, C e S.
b) S, S, C e C.
c) S, C, S e C.
d) C, S, C e S.
e) C, C, S e C.

2010) Dentre as etapas para o desenvolvimento de software em que a UML
pode ser aplicada, aquela em que sero modeladas somente classes que
pertenam ao domnio principal do problema do software, deixando de lado
classes tcnicas que gerenciem banco de dados, interface, comunicao,
concorrncia e outras, a etapa de
a) anlise de requisitos.
b) anlise sistmica.
c) projeto.
d) implementao.
e) testes/implantao.

40 Questo) (FCC Assemblia Legislativa do Estado de So Paulo
Agente Tcnico Legislativo Tecnologia da Informao 2010) So
consideradas metodologias geis de desenvolvimento de software:
a) XP e UP.
b) SCRUM e DSDM.
c) SCRUM e RUP.
d) DSDM e Cascata.
e) Cascata e PRINCE2.

41 Questo) (FCC INFRAERO Analista de Sistemas/Arquitetura
de Software 2011) Um dos principais conceitos do Scrum para atacar a
complexidade do desenvolvimento e gerenciamento de software a implantao
de um controle descentralizado, capaz de lidar mais eficientemente com

Prof. Victor Dalton
contextos pouco previsveis. Para tanto, o gerenciamento distribudo por meio
de trs agentes independentes que so:
a) Product Owner, Scrum Team e Scrum Master.
b) Product Owner, Product Backlog e Planning Meeting.
c) Product Owner, Sprint e Planning Meeting.
d) Sprint, Scrum Master e Planning Meeting.
e) Sprint, Scrum Team e Product Backlog.

42 Questo) (FCC TRT 6 Regio Analista Judicirio Tecnologia
da Informao 2012) Na metodologia Scrum, NO faz parte de uma reviso
do sprint (sprint review) o seguinte procedimento:
a) Todo o time colabora no que deve ser feito em seguida, de modo que
esta reviso contribua para reunies de planejamento subsequentes.
b) O proprietrio do produto identifica o que est pronto e o que ainda est
por fazer.
c) O time de desenvolvimento discute quais fatores positivos e negativos
ocorreram durante o sprint e como os problemas foram resolvidos.
d) O time de desenvolvimento apresenta o trabalho que foi desenvolvido e
responde questes sobre o incremento.
e) Todo o time cria um plano para implementar melhorias no modo como o
time efetua seu trabalho.

GABARITO

1.c 2.c 3.b 4.d 5.b 6.b 7.a 8.b 9.d 10.a
11.c 12.e 13.c 14.c 15.c 16.d 17.d 18.c 19.d 20.c
21.e 22.d 23.d 24.d 25.a 26.b 27.c 28.b 29.a 30.a
31.d 32.d 33.b 34.e 35.c 36.d 37.e 38.a 39.b 40.b
41.a 42.e

Questões de TI para o ICMS-SP 2013: Engenharia de Software e Gestão de Projetos

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Questões de TI para o ICMS-SP 2013: Engenharia de Software e Gestão de Projetos

Uploaded by

Copyright:

Available Formats

Questes Comentadas de TI para o ICMS-SP 2013- rea:

You might also like