Análise e Projeto de Sistemas em TI

Prévia do material em texto

TI EM EXERCÍCIOS P/ INSS 
Conhecimentos específicos - Formação em Tecnologia da Informação (TEINF) 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 1 de 92 
AULA 6 – ANÁLISE E PROJETO DE SISTEMAS 
Olá pessoal, tudo bem! 
Hoje trago para vocês a sexta aula do curso, com um Memorex complementar 
e muitas questões rs.. Espero que aproveitem! 
 
 “Sem o esforço da busca torna-se 
impossível a alegria da conquista”. 
Embora muitos concurseiros o façam, não devemos iniciar um projeto de 
estudo sem algumas ATITUDES BÁSICAS. 
Você até pode seguir adiante sem elas, mas com certeza terá grandes 
chances de desistir no decorrer da caminhada ou de gastar mais tempo do que 
o necessário. 
Então, vamos conhecê-las desde já, e tomar consciência de que são 
importantes para que você alcance o sucesso não só nas provas de concursos, 
mas em qualquer etapa/projeto da sua vida. 
Antes de falar sobre essas atitudes, é preciso que você tenha um 
objetivo claro e visão. O objetivo deve ser OTIMISTA e voltado para a 
realidade. A partir daí é preciso AÇÃO, pois apenas ela transforma a realidade. 
Então, primeiramente, acredite no seu SONHO, no entanto, ele só 
acontece quando agimos, trabalhamos, nos esforçamos para sua 
concretização. Assim, no momento em que temos um objetivo a ser alcançado 
e começarmos a agir, é preciso as cinco qualidades seguintes, já mencionadas 
pelo mestre William Douglas, que são: COMPROMISSO, AUTODISCIPLINA, 
ORGANIZAÇÃO, ACUIDADE (prestar atenção nas coisas) e 
FLEXIBILIDADE (adaptação). 
TI EM EXERCÍCIOS P/ INSS 
Conhecimentos específicos - Formação em Tecnologia da Informação (TEINF) 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 2 de 92 
No próximo post da minha página do Facebook irei detalhar cada uma 
delas (espero vocês por lá!). Continuem firmes nessa caminhada e ótimos 
estudos! 
Um abraço, 
Profa Patrícia Lima Quintão 
Facebook: http://www.facebook.com/professorapatriciaquintao (Todo dia 
com novas dicas, desafios e muito mais, espero vocês por lá para CURTIR a 
página!) 
Instagram: patriciaquintao 
 
Conteúdo desta Aula Página 
 Memorex. 02 
 Lista de Questões Comentadas Nesta Aula. 21 
 Questões Apresentadas na Aula. 74 
 Gabarito. 92 
MEMOREX – Extra – Aproveitem! 
• Uma metodologia de processo genérica para engenharia de 
software estabelece cinco atividades metodológicas básicas, de acordo 
com Pressman, que são: comunicação, planejamento, modelagem, 
construção e entrega. 
Fluxo de Processo 
O fluxo de processo descreve como são organizadas as atividades 
metodológicas, bem como as ações e tarefas que ocorrem dentro de 
cada atividade em relação à sequência e ao tempo, como ilustrado nas 
figuras desta seção. 
1)Fluxo de Processo Linear 
Executa cada uma das cinco atividades metodológicas em sequência, 
começando com a de comunicação e terminando com a entrega (ou 
emprego, ou implantação). 
 
Figura. Fluxo de Processo Linear. Fonte: Pressman (2011) 
 
2)Fluxo de Processo Iterativo 
Repete uma ou mais das atividades antes de prosseguir para a 
seguinte, conforme listado na próxima figura. 
TI EM EXERCÍCIOS P/ INSS 
Conhecimentos específicos - Formação em Tecnologia da Informação (TEINF) 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 3 de 92 
 
Figura. Fluxo de Processo Iterativo. Fonte: Pressman (2011) 
 
3)Fluxo de Processo Evolucionário 
Executa as atividades de forma “circular”. Cada volta pelas cinco atividades 
conduz a uma versão mais completa do software. 
 
Figura. Fluxo de Processo Evolucionário. Fonte: Pressman (2011) 
 
4)Fluxo de Processo Paralelo 
Executa uma ou mais atividades em paralelo com outras atividades (como 
por exemplo a modelagem para um aspecto do software poderia ser 
executada em paralelo com a construção de um outro aspecto do software). 
 
Figura. Fluxo de Processo Paralelo. Fonte: Pressman (2011) 
TI EM EXERCÍCIOS P/ INSS 
Conhecimentos específicos - Formação em Tecnologia da Informação (TEINF) 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 4 de 92 
Modelos de Processo de Software 
Todos os modelos de processo de software, segundo Pressman (2011) podem 
acomodar as atividades metodológicas genéricas, aqui apresentadas, porém, 
cada um deles dá uma ênfase diferente a essas atividades e define um 
fluxo de processo que invoca cada atividade metodológica de forma 
diversa. 
Há vários processos de desenvolvimento propostos. Bezerra (2007) destaca 
que é um consenso na comunidade de desenvolvimento de software o fato de 
que não existe o melhor processo de desenvolvimento, aquele que melhor se 
aplica a todas as situações de desenvolvimento. Segundo o autor, cada 
processo tem suas particularidades em relação ao modo de arranjar e 
encadear as atividades de desenvolvimento. 
Há vários modelos de processo de software propostos, vamos ao estudo dos 
principais, importantes para a prova. 
 
• Modelo em Cascata 
Também chamado de clássico, ou linear, é o mais tradicional processo de 
desenvolvimento de software. 
Esse modelo sugere uma abordagem sequencial e sistemática para o 
desenvolvimento de software, aplicando as atividades de maneira linear. Em 
cada fase desenvolvem-se artefatos (produtos de software) que servem de 
base para as fases seguintes. 
Vide figura proposta por Pressman (2011) para esse modelo. 
 
Figura. Modelo Cascata, segundo Pressman (2011) 
Segundo proposta de Eduardo Bezerra, o modelo do ciclo de vida clássico 
da engenharia de software é dividido em seis atividades. São elas: 
TI EM EXERCÍCIOS P/ INSS 
Conhecimentos específicos - Formação em Tecnologia da Informação (TEINF) 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 5 de 92 
 
Em seguida, a proposta de Kruchten (2003). 
 
O modelo em Cascata possui como vantagem principal a simplicidade para a 
sua aplicação e gerência. 
No entanto, algumas desvantagens podem ser observadas: 
• projetos reais raramente seguem este fluxo sequencial. 
• dificuldade do cliente em declarar todas as suas necessidades no início do 
projeto. 
• demora em apresentar resultados ao cliente. 
 
Uma variação do modelo cascata, destacada por Pressman (2011) é o 
modelo V. Segundo o autor, à medida que a equipe de software desce em 
direção ao lado esquerdo do V, os requisitos básicos do problema são refinados 
em representações progressivamente cada vez mais detalhadas e técnicas do 
problema e de sua solução. Uma vez que o código tenha sido gerado, a equipe 
sobe o V, realizando uma série de testes que validem cada um dos modelos 
criados do outro lado do V. 
TI EM EXERCÍCIOS P/ INSS 
Conhecimentos específicos - Formação em Tecnologia da Informação (TEINF) 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 6 de 92 
Na realidade, segundo Pressman (2011) não existe diferença entre os 
modelos. O modelo V fornece uma maneira para visualizar como a verificação 
e as ações de validação são aplicadas ao trabalho de engenharia do ciclo de 
vida em Cascata. 
 
Figura. Modelo V. Fonte: Pressman (2011) 
 
• Modelo Incremental 
Este modelo foi proposto como uma alternativa ao modelo em cascata, 
aplicando-o iterativamente, tendo como objetivo a elaboração de um 
produto operacional a cada incremento. Os primeiros incrementos são 
versões simplificadas do produto final, mas oferecem capacidades que 
servem ao usuário, além de servir como uma plataforma de avaliação. 
Em cada iteração uma parte é concebida como a menor unidade que pode 
ser implementadae ainda assim fornecer alguma funcionalidade útil para os 
usuários. 
Os modelos incrementais combinam elementos dos fluxos de processos 
lineares e paralelos. 
Na figura seguinte, o modelo incremental aplica sequências lineares, de 
forma escalonada, à medida que o tempo vai avançando. Cada sequência 
linear gera “incrementais” (entregáveis/aprovados/liberados) do software. 
TI EM EXERCÍCIOS P/ INSS 
Conhecimentos específicos - Formação em Tecnologia da Informação (TEINF) 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 7 de 92 
 
Figura. Modelo Incremental. Fonte: Pressman (2011) 
Este modelo possui como vantagem o fato de apresentar constantemente 
novas versões aos usuários. Pode ser aplicado também quando não houver 
mão-de-obra disponível para uma implementação completa, ou quando for 
necessário gerenciar riscos técnicos. 
 
• RAD (Rapid Application Development - Desenvolvimento Rápido 
de Aplicação) 
Trata-se de um modelo de processo de software incremental que 
enfatiza um ciclo de desenvolvimento curto. É uma adaptação “de alta 
velocidade” do modelo em cascata, no qual o desenvolvimento rápido é 
conseguido com o uso de uma abordagem de construção baseada em 
componentes. 
Desvantagens: projetos grandes precisam de muitas equipes; exige 
comprometimento dos clientes e desenvolvedores; sistemas não 
modularizados são problemáticos; não é adequado para projetos com 
grandes riscos técnicos. 
 
TI EM EXERCÍCIOS P/ INSS 
Conhecimentos específicos - Formação em Tecnologia da Informação (TEINF) 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 8 de 92 
 
 
• Modelo Evolutivo (Modelo de Processo Evolucionário) 
Produz uma versão cada vez mais completa do software a cada 
iteração. 
 
• Prototipação (chamada também como Prototipagem) 
Em algumas situações, o cliente consegue definir apenas um conjunto de 
objetivos gerais do software, não identificando claramente seus requisitos. 
Em uma situação dessas, a prototipagem pode ser empregada em conjunto 
com outros modelos para auxiliar no entendimento do sistema. 
Os objetivos do software são estabelecidos na comunicação com o cliente. A 
partir daí, um protótipo descartável é elaborado com o intuito de facilitar a 
compreensão do sistema por parte dos usuários. 
Apesar da prototipagem poder ser aplicada como um modelo, em geral ela é 
mais utilizada como uma técnica para entendimento do sistema. A próxima 
figura apresenta o esquema deste modelo. 
TI EM EXERCÍCIOS P/ INSS 
Conhecimentos específicos - Formação em Tecnologia da Informação (TEINF) 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 9 de 92 
 
Figura. O Paradigma da Prototipação. Fonte: Pressman (2011) 
 
Vantagens da prototipagem: 
• maior participação e comprometimento dos clientes e usuários; e 
• os resultados são apresentados mais rapidamente. 
Críticas: 
• forte dependência das linguagens e ambientes utilizados, bem como da 
experiência da equipe; 
• o cliente tende a considerar o protótipo como versão final, podendo 
comprometer a qualidade do projeto; e 
• o desenvolvedor tende a fazer concessões na implementação, a fim de 
colocar um protótipo em funcionamento rapidamente. Estas concessões 
podem se tornar parte integrante do sistema. 
 
• Modelo Espiral 
No modelo Espiral, assume-se que o processo de desenvolvimento ocorre em 
ciclos, cada um contendo fases de avaliação e planejamento em que a opção 
de abordagem para a próxima fase (ou ciclo) é determinada. 
Neste modelo acrescenta-se a Análise dos Riscos ao ciclo de vida para 
auxiliar as decisões a respeito da próxima iteração. A figura seguinte 
apresenta o esquema desse modelo. 
TI EM EXERCÍCIOS P/ INSS 
Conhecimentos específicos - Formação em Tecnologia da Informação (TEINF) 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 10 de 92 
 
Figura. O Modelo Espiral Típico. Fonte: Pressman (2011) 
No modelo de processo de desenvolvimento em espiral, cada loop na espiral 
representa uma fase do processo de software. Este modelo exige a 
consideração direta dos riscos técnicos em todos os estágios do projeto e, 
se aplicado adequadamente, deve reduzir os riscos antes que eles se tornem 
problemáticos. 
Apesar desse modelo reunir as melhores características dos outros, algumas 
críticas podem ser feitas: 
• exige gerentes e técnicos experientes; 
• uma vez que o modelo em espiral pode levar ao desenvolvimento em 
paralelo de múltiplas partes do projeto, as tarefas gerenciais para 
acompanhamento e controle do projeto são mais complexas; 
• é necessário o uso de técnicas específicas para estimar e sincronizar 
cronogramas, bem como para determinar os indicadores de custo e 
progresso mais adequados. 
 
• RUP (Rational Unified Process) 
O Rational Unified Process (RUP) é um exemplo de modelo de processo de 
desenvolvimento baseado no Unified Process (Processo Unificado) desenvolvido 
pela Rational. 
O RUP oferece uma abordagem baseada em disciplinas para atribuir tarefas e 
responsabilidades dentro de uma organização de desenvolvimento. Sua meta 
é garantir a produção de software de alta qualidade que atenda às 
necessidades dos usuários dentro de um cronograma e de um orçamento 
previsíveis. 
O Rational Unified Process é um processo de desenvolvimento iterativo e 
incremental, no qual o software não é implementado em um instante no fim 
do projeto, mas é, ao contrário, desenvolvido e implementado em partes. A 
cada iteração deste processo utiliza-se quatro fases, a saber: Concepção, 
Elaboração, Construção e Transição. 
TI EM EXERCÍCIOS P/ INSS 
Conhecimentos específicos - Formação em Tecnologia da Informação (TEINF) 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 11 de 92 
• Durante a Concepção ou Início (Inception), estabelece-se a lógica do 
domínio da aplicação para o projeto e decide o escopo do projeto. É aqui 
que se obtém o comprometimento do patrocinador do projeto para 
seguir adiante. Nesta fase compreende-se o problema da tecnologia 
empregada por meio da definição dos use cases mais críticos. Define-se 
aqui o caso de negócio e escopo do projeto. 
• Na Elaboração (Elaboration) coleta-se requisitos mais detalhados, faz 
uma análise e um projeto de alto nível para estabelecer uma arquitetura 
básica, e cria um plano para a construção do sistema. Deve-se analisar o 
domínio do problema, estabelecer a arquitetura, desenvolver o plano do 
projeto e eliminar elementos de alto risco. 
• A fase de Construção (Construction) consiste de várias iterações, 
nas quais cada iteração constrói software de qualidade de produção, 
testado e integrado, que satisfaz um subconjunto de requisitos de 
projeto. Cada iteração contém todas as fases usuais do ciclo de vida da 
análise, do projeto, da implementação e do teste. Desenvolve-se o 
software e prepara-se o mesmo para a transição para os usuários. Além 
do código, também são produzidos os casos de teste e a documentação. 
• Mesmo com este tipo de processo iterativo, algum trabalho tem que ser 
deixado para ser feito no fim, na fase de Transição (Transition). Nesta 
fase são realizados os treinamentos dos usuários e a transição do 
produto para utilização. Este trabalho pode incluir também testes beta e 
ajuste de performance. 
Os projetos variam de acordo com o volume de formalidade que eles têm. 
Projetos de muita formalidade têm muitos documentos formais a serem 
entregues, reuniões formais, encerramentos formais. Projetos de pouca 
formalidade podem ter uma fase de concepção que consiste de um bate-papo 
de uma hora com o patrocinador do projeto e um plano que cabeem uma 
folha de papel. Naturalmente quanto maior o projeto, mais formalidade 
precisa. O fundamental de cada fase ainda acontece, mas de formas bem 
diferentes. 
Após a fase de Transição de uma iteração completa, o produto pode voltar a 
percorrer cada uma das fases para se produzir uma nova versão do produto. 
Cada uma das quatro fases do RUP é dividida em iterações, onde cada 
uma delas é um ciclo completo de desenvolvimento resultando em uma versão 
de um produto executável que constitui um subconjunto do produto final. 
Cada iteração é organizada em fluxos de trabalho (workflows) de 
processo, com uma ênfase diferente em cada fase. 
Os fluxos de trabalho de processo do RUP são: 
• Gerenciamento de Projeto (Project Management); 
• Modelagem Comercial ou de Negócio (Business Modeling); 
• Requisitos ou Exigências (Requirements); 
• Análise e Projeto (Analisys & Design); 
• Implementação (Implementation); 
TI EM EXERCÍCIOS P/ INSS 
Conhecimentos específicos - Formação em Tecnologia da Informação (TEINF) 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 12 de 92 
• Testes (Test); 
• Distribuição ou Entrega (Deployment); 
• Gerência de Configuração e Mudanças (Configuration and Change 
Management); e 
• Ambiente (Enviroment). 
 
A figura ilustrada a seguir apresenta o relacionamento entre as fases e o 
esforço de desenvolvimento em cada fluxo de trabalho de processo. 
 
O RUP é composto por nove disciplinas e quatro fases!!!! 
 
Figura. Fases e disciplinas do RUP. Fonte: (KRUCHTEN, 2003) 
 
Na figura, o eixo horizontal representa o tempo e mostra os aspectos do ciclo 
de vida do processo como se desdobra. Já o eixo vertical representa os fluxos 
essenciais do processo, que agrupa logicamente as atividades por natureza. 
 
• Processo Ágil 
A Engenharia de Software vem há anos criando técnicas de modelagem, 
projeto e desenvolvimento de sistemas. Dentre os desafios dos pesquisadores 
da área, pode-se citar a preocupação em desenvolver softwares com qualidade 
garantida, no prazo estabelecido e sem alocar recursos além do previsto. No 
entanto, muitas das metodologias criadas são consumidoras de muitos 
recursos, aplicando-se principalmente a grandes sistemas. 
TI EM EXERCÍCIOS P/ INSS 
Conhecimentos específicos - Formação em Tecnologia da Informação (TEINF) 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 13 de 92 
Como a Engenharia de Software ainda está evoluindo, novos modelos estão 
sendo apresentados, como: desenvolvimento ágil; dentre outros. Aqui 
merecem destaque o SCRUM e eXtreme Programming 
 
SCRUM 
O Scrum é um processo de desenvolvimento ágil de software baseado em 
grupos de práticas e papeis pré-definidos. Ele é um processo iterativo e 
incremental para gerenciamento de projetos e desenvolvimento de 
sistemas, em que cada sprint é uma iteração que segue um ciclo PDCA (Plan, 
Do, Check, Act) e entrega um incremento de software pronto. 
Os principais papéis do Scrum são: Product Owner, Scrum Master e 
Scrum Team (equipe do projeto). 
Não há como fazermos um mapeamento direto entre os papéis do Scrum e os 
papéis convencionais conhecidos. Não existe a figura única do Gerente de 
Projetos. Suas responsabilidades estão diluídas entre os papéis citados. Cada 
um conhece sua participação frente ao projeto e trabalha em conjunto para 
conseguir alcançar o goal definido. 
Seus artefatos principais são: o Product Backlog (Produto Backlog) e 
Sprint Backlog – artefatos que representam seus requisitos/atividades, além 
de Burndown charts e impediment backlogs. 
 
eXtreme Programming 
A eXtreme Programming faz parte também de uma série de métodos 
denominados ágeis (agile). Estes métodos foram inicialmente considerados 
leves (lightweight) para diferenciá-los dos métodos tradicionais de 
desenvolvimento considerados pesados (heavyweight), os quais seriam 
baseados na produção de uma grande quantidade de documentação e modelos 
para guiar a programação. 
Ao contrário dos métodos tradicionais que são orientados ao planejamento, 
previsibilidade e ao controle, os métodos ágeis são orientados à construção, 
testes e principalmente, às pessoas. As metodologias ágeis enfatizam 
os aspectos humanos, as relações pessoais, uma vez que buscam 
valorizar o pensamento criativo dos indivíduos envolvidos no projeto, 
em que o conhecimento é fator importante para o sucesso do projeto. 
No desenvolvimento ágil a metodologia deve produzir conhecimento e não 
apenas documentação. Mas isto não significa que nos ambientes ágeis não 
exista documentação, apenas deixa de existir a filosofia de que “tudo tem que 
ser documentado” e sim documentar apenas o necessário uma vez que a 
documentação apenas auxilia e não guia o desenvolvimento. 
Na próxima figura podemos comparar a XP ao modelo tradicional de 
desenvolvimento de software. 
TI EM EXERCÍCIOS P/ INSS 
Conhecimentos específicos - Formação em Tecnologia da Informação (TEINF) 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 14 de 92 
 
Como se vê na figura, o modelo em cascata estabelece uma ordenação linear 
no que diz respeito à realização das diferentes etapas, já o modelo iterativo 
é um modelo de processo de desenvolvimento que busca contornar algumas 
das limitações existentes no modelo cascata. Já a XP trabalha com 
iterações de menor tamanho possível, contendo os requisitos de maior 
valor para o negócio, sendo assim, a equipe produz um conjunto 
reduzido de funcionalidades e coloca em produção rapidamente de 
modo que o cliente já possa utilizar o software no dia-a-dia e se 
beneficiar dele. 
 
Valores 
Para implantar a XP é necessário que se norteie o trabalho baseado em quatro 
valores: 
• Comunicação: é o principal valor da XP. Grande parte das técnicas da XP 
está baseada na comunicação, e se esta não for eficiente, pode causar 
problemas e atrasos no desenvolvimento do sistema. 
• Simplicidade: a XP utiliza-se da simplicidade para implementar apenas 
aquilo que é suficiente para o cliente, não se procura fazer especulações 
sobre necessidades futuras, pois quase sempre são especulações errôneas, 
deixamos os problemas do futuro para o futuro. 
• Feedback: o cliente deve receber o sistema o quanto antes, a fim de poder 
dar um feedback rápido, guiando assim o desenvolvimento do software. 
• Coragem: é preciso muita coragem para mudar a maneira pela qual 
desenvolve-se sistemas. Colocar um sistema em produção assim que ele 
tenha valor para o cliente, fazer apenas o que se precisa para o momento e 
calcar o processo de análise principalmente na comunicação não é fácil, e 
precisa que a equipe esteja realmente decidida a mudar o seu processo de 
desenvolvimento. 
 
Práticas 
A XP é baseada em um conjunto de técnicas fundamentais (práticas), que 
podem ser aplicadas individualmente, cada uma delas gerando melhorias no 
processo de desenvolvimento, mas que funcionam melhor em conjunto, uma 
TI EM EXERCÍCIOS P/ INSS 
Conhecimentos específicos - Formação em Tecnologia da Informação (TEINF) 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 15 de 92 
vez que uma técnica reforça o resultado da outra. Apresenta-se a seguir uma 
descrição de cada prática. 
• Cliente Presente (On-site customer) 
Na XP todas as decisões sobre o rumo do projeto devem ser tomadas pelo 
cliente. Ele deve priorizar as tarefas, ser responsável pelos testes de aceitação, 
e, acima de tudo, orientar e tirar dúvidas dos desenvolvedores durante o 
processo de programação. 
Se o cliente não puder estar junto dos desenvolvedores, algumas técnicas 
podem ser utilizadas, como, por exemplo, nomear um membro da equipe para 
representaro cliente. Também se podem agendar reuniões de 
acompanhamento com o cliente, pelo menos uma vez por semana. Nestas 
reuniões haverá muita discussão sobre prioridades, mas deve-se destinar uma 
parte significativa da mesma para que os programadores possam saber o que 
e como desenvolver. 
• Jogo do Planejamento (The Planning Game) 
O XP utiliza o planejamento para assegurar que a equipe de desenvolvimento 
esteja sempre trabalhando naquilo que irá gerar maior valor para o cliente a 
cada dia de trabalho. Este planejamento é feito diversas vezes ao longo do 
projeto, para que todos tenham a oportunidade de revisar as prioridades. 
Na XP o planejamento é um processo contínuo, e o mesmo é constantemente 
refinado pelo cliente e pela equipe de desenvolvimento, deixando assim a 
metodologia bastante flexível e entregando para o cliente sempre o máximo 
valor pelo investimento dele. 
• Pequenos Lançamentos (Small Releases) 
Para que o cliente possa fornecer constantemente feedback sobre o andamento 
do sistema, fazendo possível que o jogo do planejamento (planning game) seja 
executado, é importante que o sistema tenha releases pequenos, a fim de 
ajustar o desenvolvimento às necessidades que vão surgindo no decorrer do 
processo. 
Normalmente, trabalha-se com pequenas iterações gerando releases mais 
curtos, mas algumas empresas vêm suprimindo a etapa das iterações, 
lançando direto um release por semana. 
Quanto menor o intervalo de tempo entre cada versão que o cliente recebe, 
mais fácil será corrigir eventuais problemas, pois não terá sido entregue uma 
quantidade muito grande de funcionalidades, e mais fácil será fazer algum 
ajuste no software para atender a uma mudança de requisitos. Além disso, o 
XP recomenda que o cliente busque selecionar as funcionalidades que mais vão 
gerar valor para ele, com isso fazemos com que o cliente tenha um retorno de 
investimento o mais cedo possível. 
• Desenvolvimento Guiado pelos testes (Test First Design) 
O desenvolvimento guiado pelos testes define que qualquer método de um 
objeto que possa falhar deve ter um teste automatizado que garanta o seu 
funcionamento. 
TI EM EXERCÍCIOS P/ INSS 
Conhecimentos específicos - Formação em Tecnologia da Informação (TEINF) 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 16 de 92 
• Integração Contínua (Continuous Integration) 
Quando uma equipe desenvolve um software é comum que o software seja 
“quebrado” em algumas partes a fim de que cada desenvolvedor implemente a 
sua parte, esta visão é interessante porque assim cada desenvolvedor tende a 
se preocupar só com a sua parte do sistema o que reduz a complexidade do 
problema. Neste caso são definidas interfaces para comunicação entre estas 
partes para posterior agrupamento e formação de um software coeso. Porém é 
muito comum acontecerem erros na integração, estes erros acontecem 
geralmente por que: 
� As interfaces definidas não foram respeitadas; 
� Não houve compreensão por parte de um desenvolvedor da 
interface do outro; 
� O sistema como um todo é pouco coeso. 
Devido a estes erros e também da instabilidade das interfaces, por estarem 
sempre em constante mudança, a integração contínua se faz necessária para 
amenizar e até suprimir esses erros, uma vez que expõe todo o estágio atual 
de desenvolvimento, oferece feedback constante e estimula agilidade no 
desenvolvimento do software. 
A técnica de integração contínua diz que o código desenvolvido por cada par de 
desenvolvedores deve ser integrado ao código base constantemente. 
• Projeto Simples (Simple Design) 
Kent Beck utiliza quatro regras básicas para definir simplicidade, são elas em 
ordem de prioridade: 
1. O sistema (código e testes em conjunto) deve expressar tudo aquilo que 
você deseja comunicar. 
2. O sistema não deve conter nenhum código duplicado. 
3. O sistema deve ter o menor número de classes possível. 
4. O sistema deve ter o menor número de métodos possível. 
• Refatoração (Refactoring) 
É o processo de mudar um sistema de software de tal forma que não se altera 
o comportamento externo do código, mas melhora sua estrutura interna. É um 
meio disciplinado de limpar o código e que reduz as possibilidades de introduzir 
erros. Em essência quando você refina o código, você melhora o projeto depois 
que este foi escrito. "Melhorar o projeto depois que foi escrito" é uma premissa 
do XP. 
A técnica de refinamento do design é utilizada sempre com o intuito de 
simplificar o código. Refactoring significa reescrever o código, melhorando e 
simplificando o mesmo, sempre que se tiver oportunidade. O projeto do código 
vai sendo aos poucos melhorado através de modificações que o aprimorem. 
Estas modificações partem de um código fonte o qual passa em todos os 
testes, e devem levar a um código-fonte que continue passando em todos os 
testes. 
TI EM EXERCÍCIOS P/ INSS 
Conhecimentos específicos - Formação em Tecnologia da Informação (TEINF) 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 17 de 92 
• Programação em pares (Pair Programming) 
Todo o código que vai para a produção é escrito por um par de programadores 
que utilizam uma mesma estação de trabalho ao mesmo tempo, ou seja, um 
computador, um teclado e dois desenvolvedores. 
Na XP todo o código deve ser produzido por duas pessoas utilizando o mesmo 
computador. Enquanto um dos parceiros se preocupa com detalhes da 
implementação, ficando responsável pela digitação do código, o outro deve 
tentar ter uma visão mais ampla da rotina, imaginando as suas peculiaridades. 
Não apenas o código deve ser produzido por duas pessoas, como também todo 
o projeto da classe na qual vai se trabalhar. 
• Propriedade Coletiva (Collective Ownership) 
O código deve ser de propriedade de todos e todos devem ter permissão para 
alterar o que for necessário para que seu trabalho possa ser desenvolvido. Em 
estruturas onde determinadas rotinas são de “propriedade” de algumas 
pessoas, podem ocorrer atrasos no desenvolvimento devido à necessidade de 
que seja alterado algo nestas rotinas para que outras pessoas possam 
continuar com o seu trabalho. 
• Padrões de Codificação (Coding Standards) 
XP recomenda a utilização de padrões de codificação, que devem ser adotados 
no início do projeto com o consentimento de todos os desenvolvedores. Desta 
forma, qualquer desenvolvedor poderá ler o código com velocidade, sem se 
preocupar em compreender estilos de formatação especiais. 
• Ritmo Sustentável (40 Hour Week) 
Um dos grandes problemas que projetos de desenvolvimento de software 
enfrentam é o curto prazo de entrega do sistema. Com um prazo cada vez 
mais curto e sistemas cada vez mais complexos uma das alternativas dos 
desenvolvedores é o trabalho em excesso. As pessoas passam a trabalhar 
diariamente até mais tarde invadindo também finais de semana e feriados, 
porém trabalhar por longos períodos é contraproducente, e normalmente tende 
a piorar a situação. 
• Metáfora (Metaphor) 
Equipes XP mantêm uma visão compartilhada do funcionamento do sistema. 
Isto é feito através do uso de metáforas. Fazendo uso de metáforas podemos 
facilitar a explicação de qualquer aspecto dentro do projeto e ao mesmo tempo 
fixá-la com mais força na mente do ouvinte. 
Utilizam-se metáforas para vários aspectos na XP, dentre eles procura-se criar 
uma visão comum sobre todo o projeto de forma simples e objetiva facilitando 
assim a comunicação entre toda a equipe, uma vez que serve de base para os 
padrões de codificação e entre a equipe e o cliente, visto que o cliente, na 
maioria das vezes, não entende os termos técnicos relacionados ao 
desenvolvimento e usados diversas vezes pelos desenvolvedores e equipe. 
 
 
 
TI EM EXERCÍCIOS P/ INSS 
Conhecimentosespecíficos - Formação em Tecnologia da Informação (TEINF) 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 18 de 92 
• Modelo Concorrente 
Esse modelo, algumas vezes denominado engenharia concorrente, 
possibilita à equipe de software representar elementos concorrentes e 
iterativos de qualquer um dos modelos de processos aqui descritos. Como 
exemplo, a atividade de modelagem definida para o modelo espiral pode ser 
realizada invocando uma ou mais das seguintes ações de engenharia de 
software: prototipagem, análise e projeto (Pressman, 2011). 
 
• Desenvolvimento Baseado em Componentes 
Desenvolve aplicações a partir de componentes de software pré-empacotados 
(faz reuso de componentes de softwares já existente, para conseguir redução 
no tempo do ciclo de desenvolvimento, bem como redução no custo do 
projeto) (Pressman, 2011). 
 
• Modelo de Métodos Formais 
Engloba um conjunto de atividades que conduzem à especificação 
matemática formal do software. 
 
APF – Análise de Ponto de Função 
Técnica que permite medir a funcionalidade de um software ou 
aplicativo, sob a visão do usuário, a partir da descrição dos requisitos 
do usuário. 
• É uma técnica de medição das funcionalidades fornecidas por um 
software do ponto de vista do usuário. 
• Trata-se de um método padrão para MEDIR desenvolvimento de software 
de acordo com a perspectiva do USUÁRIO. 
• Faz medição das funcionalidades fornecidas por um software do ponto de 
vista do usuário (Tamanho funcional). 
 
Objetivos 
• Medir o tamanho das funcionalidades requisitadas e recebidas pelo usuário 
• Medir desenvolvimento e manutenção de software independente da 
tecnologia. Por buscar independência da tecnologia utilizada para a 
construção do software, a APF independe da linguagem de programação 
utilizada. 
 
Visão do Usuário 
• Usuário – qualquer pessoa ou coisa que interaja com a aplicação ou 
especifique seus requisitos, como: Pessoa física; outra aplicação; Hardware; 
Ator em um caso de uso; Gestores de negócio que o software irá atender. 
• Uma visão do usuário representa uma descrição formal das necessidades do 
negócio do usuário, na linguagem do usuário. 
• É uma descrição das funções do negócio. 
• É aprovada pelo usuário. 
TI EM EXERCÍCIOS P/ INSS 
Conhecimentos específicos - Formação em Tecnologia da Informação (TEINF) 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 19 de 92 
• Pode ser usada para contar pontos de função. Pode variar na forma física 
(ex., catálogo de transações, propostas, documento de requisitos, 
especificações externas, especificações detalhadas, manuais do usuário). 
 
Componentes dos Pontos de Função (Importante) 
De acordo com o Manual de Práticas do IFPUG 4.2.1 temos cinco tipos de 
funções: 
• Arquivo Lógico Interno (ALI) 
• Arquivo de Interface Externa (AIE) 
• Entrada Externa (EE) 
• Saída Externa (SE) 
• Consulta Externa (CE) 
 
Etapas para Avaliação 
� Etapa I - Identificação do TIPO DE CONTAGEM a ser utilizado - O 
quê vou medir? 
Projeto de Desenvolvimento/Projeto de Manutenção/Projeto de 
Aplicação 
 
� Etapa II - Definição da FRONTEIRA da aplicação - Quais os limites 
do que vou medir? => Escopo do sistema objeto da avaliação. 
 
� Etapa III - Contagem de pontos de função não ajustados - Como 
vou medir? Reflete o conjunto de funções disponibilizadas ao 
usuário. 
� O resultado da contagem nessa etapa são pontos de função brutos! 
 
� Grupos de funções do tipo DADOS: 
Arquivo Lógico Interno (ALI) 
Arquivo de Interface Externa 
(AIE) 
 
� Grupos de funções tipo TRANSAÇÕES: 
Entrada Externa (EE) 
Saída Externa (SE) 
Consulta Externa (CE) 
 
� Etapa IV - Cálculo do fator de ajuste 
(Fatores relacionados com características da aplicação que afetam 
o tamanho funcional de um sistema). 
� O fator de ajuste é responsável pela correção das distorções da etapa 
anterior. 
� A metodologia de pontos de função considera que outros fatores 
afetam o tamanho funcional de um sistema. 
 
Estes fatores estão relacionados com características da aplicação: 
1. Comunicação de dados 8.Atualização on-line 
2. Funções distribuídas 9. Processamento complexo 
3. Performance 10. Reusabilidade 
TI EM EXERCÍCIOS P/ INSS 
Conhecimentos específicos - Formação em Tecnologia da Informação (TEINF) 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 20 de 92 
4. Configuração do equipamento 11. Facilidade de implantação 
5. Volume de transações 12. Facilidade operacional 
6. Entrada de dados on-line 13.Múltiplos locais 
7. Interface com o usuário 14. Facilidade de mudanças 
 
� Processo de Cálculo: 
� Avaliar o impacto de cada uma das 14 características em relação 
ao sistema que está sendo avaliado, atribuindo pontuação de 0 a 5 
para cada característica. 
 
� Calcular o nível de influência geral a partir da soma dos pontos 
obtidos em cada uma das 14 características. 
� Aplica-se a seguinte fórmula: 
Fator de Ajuste = (NI * 0,01) + 0,65 
� Atualmente o fator de ajuste não tem sido muito utilizado, 
pois grande parte das características não se aplica a 
sistemas em plataformas web ou distribuídas. 
 
� Etapa V - Contagem de pontos de função ajustados 
� Correção das possíveis distorções acometidas durante o cálculo dos 
pontos de função não ajustados 
� Trata-se do processo que realiza a correção das possíveis 
distorções acometidas durante o cálculo dos pontos de função 
não- ajustados, aproximando as medidas à situação real com base 
no fator de ajuste. 
� Aplica-se a seguinte fórmula: PF = (PF não-ajustado) * (Fator 
de ajuste) O cálculo de Pontos de Função ajustados também 
não tem sido muito usado, pelos motivos relacionados ao 
fator de ajuste. 
 
Cálculo dos Pontos de Função 
 
• Cada tipo de função (ALI, entrada, saída etc.) é classificada de 
acordo com sua complexidade: Simples; Média; Alta/Complexa. 
• Cada complexidade funcional recebe uma pontuação. 
Rumo às questões!! 
TI EM EXERCÍCIOS P/ INSS 
Conhecimentos específicos - Formação em Tecnologia da Informação (TEINF) 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 21 de 92 
LISTA DE QUESTÕES COMENTADAS NESTA AULA 
1. (CEPERJ/2010/IPEM-RJ/Analista de Sistemas) No que tange aos 
paradigmas da Orientação a Objetos (OO), um princípio está diretamente 
relacionado às operações realizadas por um objeto e ao modo como as 
operações são executadas, constituindo uma forma de restringir o acesso 
ao comportamento interno de um objeto. Nesse processo, um objeto que 
precise da colaboração de outro para realizar alguma tarefa deve enviar 
uma mensagem a este último. Além disso, separa os aspectos externos de 
um objeto dos detalhes internos da implementação. Considerando esse 
contexto, observe a figura abaixo. 
 
O princípio da OO é conhecido por: 
A) Compartilhamento 
B) Acoplamento 
C) Herança 
D) Polimorfismo 
E) Encapsulamento 
 
Comentários 
Encapsular é colocar em uma cápsula. Por mais estranho que pareça, pense 
que você poderia colocar todos os itens desejados em uma cápsula (como em 
um remédio) e proteger os componentes internos da ação externa. 
Em Orientação a Objetos é bem semelhante. A ideia de encapsular é criar uma 
proteção para os itens do objeto de forma que somente por meio das 
interfaces criadas possa ocorrer o acesso às estruturas internas. Isto cria uma 
proteção para os itens do objeto, que passam a ter o acesso controlado por 
meio da interface. 
O objetivo é separar os aspectos externos (o que faz) dos aspectos internos 
(como faz): 
• Aspectos externos = interface, contrato; 
• Aspectos internos = implementação. 
O encapsulamentopode ser visto como um complemento da abstração: 
• A abstração foca o comportamento observável de um objeto. 
TI EM EXERCÍCIOS P/ INSS 
Conhecimentos específicos - Formação em Tecnologia da Informação (TEINF) 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 22 de 92 
• Encapsulamento enfoca a implementação que origina este 
comportamento. 
Além disso, ele – o encapsulamento – promove uma maior estabilidade, uma 
vez que clientes do objeto só conhecem sua interface e que podemos alterar a 
implementação de uma operação sem afetar o restante do sistema. 
Gabarito: letra E. 
 
2. (CESPE/BANCO DA AMAZÔNIA/Técnico Científico — Área: 
Tecnologia da Informação — ANÁLISE DE SISTEMAS/2010) Objetos 
têm identidade própria. Isso garante que, mesmo tendo os mesmos 
valores de variáveis e pertencendo à mesma classe, dois objetos sejam 
considerados diferentes. 
 
Comentários 
Na orientação a objetos, o conceito de identidade define que um objeto é 
uma instância única de uma classe, ocupando uma posição de memória 
específica. Então, podemos ter dois objetos não-idênticos (ocupam posições de 
memória distintas), mas iguais (são da mesma classe e possuem os mesmos 
valores para os atributos). 
Além disso, cada objeto ao ser criado, aloca espaço de memória para si e 
possui seus dados armazenados em estrutura própria. Não há confusão entre 
os objetos, especialmente quanto à identidade. Para simplificar o 
entendimento, podemos pensar em cada objeto como uma variável 
estruturada contendo os atributos. 
Gabarito: item correto. 
 
3. (CESPE/2010/TRE-MT/Técnico Judiciário/Programação de 
Sistemas) A estrutura interna de um objeto possui dois componentes 
básicos: atributos, que descrevem o estado do objeto; e métodos, que são 
responsáveis pela comunicação entre objetos. 
 
Comentários 
Em orientação a objeto, um método é uma subrotina que é executada por um 
objeto ao receber uma mensagem. Os métodos determinam o comportamento 
dos objetos de uma classe e são análogos à funções ou procedimentos da 
programação estruturada. A comunicação entre os objetos é realizada por 
mensagens que um objeto envia a outro. 
Gabarito: item errado. 
 
4. (ESAF/SEFAZ-CE/2007) A representação de classes em diagramas UML 
contempla os seguintes tipos básicos de informação: 
a) o nome da instância da classe e os seus objetos. 
TI EM EXERCÍCIOS P/ INSS 
Conhecimentos específicos - Formação em Tecnologia da Informação (TEINF) 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 23 de 92 
b) o nome da classe, os seus atributos e os seus métodos. 
c) o nome da instância da classe e os seus relacionamentos. 
d) o nome da classe, os seus atributos e suas exceções. 
e) o nome da classe e suas visibilidades. 
 
Comentários 
A UML (Unified Modeling Language - Linguagem Unificada para 
Modelagem) normalmente é definida como uma linguagem de modelagem e 
não um método propriamente dito. A UML apresenta uma série de diagramas 
para a modelagem de sistemas orientados a objetos. 
De todos os diagramas da UML, é o diagrama de classes o mais comumente 
utilizado pelas empresas. Esse diagrama, de forma simplificada, descreve os 
“tipos” de objetos do software e os vários tipos de relacionamentos estáticos 
que existem entre eles. Uma proposta de processo de desenvolvimento que 
pode ser utilizada em conjunto é o RUP (Rational Unified Process), definido por 
Booch, Jacobson e Rumbaugh. 
 
Objetos 
 
• Representam elementos do mundo real. 
• É uma abstração de conjunto de coisas do 
mundo real. 
• Possuem: 
Atributos (estado) 
Operações (comportamento). 
• O único acesso aos dados desse objeto é através de suas operações. 
 
Classes 
• Permitem que sejam representados no mundo computacional elementos 
do mundo real, ou seja, do problema para o qual o software está sendo 
desenvolvido. 
• Elas permitem descrever um conjunto de objetos que compartilhem os 
mesmos atributos, operações, relacionamentos e semântica, e 
representam o principal bloco de construção de um 
software orientado a objetos. 
 
• Representam os tipos de objetos existentes no 
modelo, e são descritas a partir de seus atributos, métodos e 
restrições. 
 
TI EM EXERCÍCIOS P/ INSS 
Conhecimentos específicos - Formação em Tecnologia da Informação (TEINF) 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 24 de 92 
A figura seguinte apresenta a simbologia para uma CLASSE chamada 
ContaBancaria, utilizando a UML. 
 
Figura. Classe ContaBancaria 
 
Com as classes definidas, precisam-se especificar quais são seus 
ATRIBUTOS (propriedades que caracterizam um objeto). Por 
exemplo, uma entidade conta bancária possui como atributos o número e 
o saldo. É bastante simples identificar os atributos de cada classe, basta 
identificar as características que descrevam sua classe no domínio 
do problema em questão. Cabe destacar que os atributos identificados 
devem estar alinhados com as necessidades do usuário para o problema. 
A figura seguinte apresenta a classe ContaBancaria com alguns de seus 
atributos. 
 
Figura. Classe ContaBancaria com alguns atributos 
 
Identificadas as classes e seus atributos, o próximo passo é a 
identificação das OPERAÇÕES de cada classe, também chamadas de 
métodos ou serviços. 
Fazendo um paralelo com objetos do mundo real, operações são ações 
que o objeto é capaz de efetuar. Dessa forma, ao procurar por 
operações, devem-se identificar ações que o objeto de uma classe é 
responsável por desempenhar dentro do escopo do sistema que será 
desenvolvido. 
 
A figura seguinte apresenta algumas operações da classe ContaBancaria. 
Ao contrário dos atributos, normalmente operações são públicas, 
permitindo sua utilização por outras classes e objetos. 
 
Figura. Classe ContaBancaria com seus atributos e operações 
 
Finalizando, a UML (Unified Modeling Language - Linguagem Unificada para 
TI EM EXERCÍCIOS P/ INSS 
Conhecimentos específicos - Formação em Tecnologia da Informação (TEINF) 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 25 de 92 
Modelagem) nos permite representar graficamente as classes, conforme nos 
mostrou a figura anterior, dando ênfase às partes mais importantes de uma 
abstração: seu nome, atributos e operações. 
Gabarito: letra B. 
 
5. (CESPE/2009/CEHAP PB/Analista de Sistemas) O projeto orientado a 
objetos encapsula atributos e serviços ou operações (comportamentos) em 
objetos. Os objetos comunicam-se entre si por meio de associações e os 
relacionamentos entre classes se dão por meio de interfaces. 
 
Comentários 
Os objetos comunicam-se por meio de mensagens (interface) e os 
relacionamentos acontecem por meio de associações. 
Gabarito: item errado. 
 
6. (ESAF/2008/AFC-STN/INFRAESTRUTURA DE TI) A habilidade para 
uso de uma mesma mensagem para invocar comportamentos distintos de 
um determinado objeto é denominada 
a) Interface. 
b) Polimorfismo. 
c) Herança. 
d) Encapsulamento. 
e) Abstração. 
 
Comentários 
Item a. Coleção de métodos que indica que uma classe possui algum 
comportamento além do que herda de suas superclasses. Os métodos incluídos 
em uma interface não definem esse comportamento; essa tarefa é definida nas 
classes que implementam a interface. ITEM FALSO. 
Item b. Permite que referências de tipos de classes mais abstratas 
representem o comportamento das classes concretas que referenciam. Assim, 
é possível tratar vários tipos de maneira homogênea (através da interface do 
tipo mais abstrato). O termo polimorfismo é originário do grego e significa 
"muitas formas" (poli = muitas, morphos = formas).ITEM VERDADEIRO. 
Item c. É o mecanismo pelo qual uma classe (sub-classe) pode estender outra 
classe (super-classe), aproveitando seus comportamentos (métodos) e 
variáveis possíveis (atributos). Um exemplo: Mamífero é super-classe de 
Humano. Logo, um Humano é um mamífero. Há herança múltipla quando uma 
sub-classe possui mais de uma super-classe. ITEM FALSO. 
Item d. Consiste na separação de aspectos internos e externos de um objeto. 
Este mecanismo é utilizado amplamente para impedir o acesso direto ao 
TI EM EXERCÍCIOS P/ INSS 
Conhecimentos específicos - Formação em Tecnologia da Informação (TEINF) 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 26 de 92 
estado de um objeto (seus atributos), disponibilizando externamente apenas 
os métodos que alteram estes estados. Exemplo: Não é necessário conhecer os 
detalhes dos circuitos de um telefone para utilizá-lo. A carcaça do telefone 
encapsula esses detalhes, provendo uma interface mais amigável (os botões, o 
monofone e os sinais de tom). ITEM FALSO. 
e) É a habilidade de concentrar nos aspectos essenciais de um contexto 
qualquer, ignorando características menos importantes ou acidentais. Em 
modelagem orientada a objetos, uma classe é uma abstração de entidades 
existentes no domínio do sistema de software. ITEM FALSO. 
Gabarito: letra B. 
 
7. (CESPE - 2009 - ANAC - Técnico Administrativo - Informática) A 
técnica conhecida como refactoring é constantemente aplicada no 
desenvolvimento baseado no método ágil extreme programming. 
 
Comentários 
"Melhorar o projeto depois que foi escrito" é uma premissa do XP. 
 “É o processo de mudar um sistema de software de tal forma que não se 
altera o comportamento externo do código, mas melhora sua estrutura 
interna. É um meio disciplinado de limpar o código e que reduz as 
possibilidades de introduzir erros. Em essência quando você refina o código, 
você melhora o projeto depois que este foi escrito”. 
Gabarito: item correto. 
 
8. (FUNRIO/Analista – Área S4/MPOG/2009) Na terminologia da UML, 
a participação é uma característica importante de uma associação, 
relacionada à necessidade, ou não, da existência dessa associação entre 
objetos. Por exemplo, numa associação com conectividade “um para 
muitos” entre as classes Departamento e Empregado, em que a 
multiplicidade do lado de Departamento é 1 e do lado de Empregado é 
1..*, a participação dos objetos de ambas as classes na associação é 
A) opcional. 
B)obrigatória. 
C) total. 
D) parcial. 
E) completa. 
 
Comentários 
A participação dos objetos de ambas as classes na associação é obrigatória 
porque o valor mínimo da multiplicidade é 1 em ambos os lados, e deve ser 
lembrado que a participação é uma característica da associação que está 
TI EM EXERCÍCIOS P/ INSS 
Conhecimentos específicos - Formação em Tecnologia da Informação (TEINF) 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 27 de 92 
relacionada com a obrigatoriedade ou não da existência da associação entre 
todos os objetos das duas classes envolvidas nela. 
Gabarito: letra B. 
 
9. (FUNRIO/Analista – Área S4/MPOG/2009) Na modelagem de classes 
da UML, que tipo de associação entre objetos das classes “pedidos” e 
“itens de pedido” é identificado na sentença “pedidos são formados por 
itens de pedido”? 
A) Generalização. 
B) Especialização. 
C) Restrição. 
D) Composição. 
E) Classificação. 
 
Comentários 
Como a composição é um tipo de relacionamento que expressa a ação de fazer 
parte de algo, quando se fala que pedidos são formados por itens de pedido, 
este tipo de relacionamento seria o que expressaria melhor o que esta frase 
exprime. 
Gabarito: letra D. 
 
10. (FUNRIO/Analista – Área S4/MPOG/2009) Suponha um diagrama 
de casos de uso de um sistema de caixa bancário eletrônico, em que os 
casos de uso “Obter extrato”, “Realizar saque” e “Realizar transferência” 
têm uma sequência de interações comum para validar a senha do 
cliente, representada pelo caso de uso “Fornecer identificação”. Qual o tipo 
de relacionamento dos três primeiros casos de uso com o caso de uso 
“Fornecer identificação”? 
A) Extensão. 
B) Agregação. 
C) Distribuição. 
D) Colaboração. 
E) Inclusão. 
 
Comentários 
A resposta correta seria inclusão, porque o caso de uso "Fornecer 
identificação" inclui o comportamento de validar a senha do cliente no caso de 
uso “Realizar transferência”, sendo assim podemos dizer que “Realizar 
transferência” usa o caso de uso "Fornecer identificação". 
Gabarito: letra E. 
TI EM EXERCÍCIOS P/ INSS 
Conhecimentos específicos - Formação em Tecnologia da Informação (TEINF) 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 28 de 92 
11. (ESAF/2005/UML) O modo para descrever os vários aspectos de 
modelagem ela UML é por meio do uso da notação definida pelos seus 
vários tipos de diagramas. Segundo as características desses diagramas, é 
correto afirmar que um diagrama de classe 
a) mostra a interação de um caso de uso organizada em torno de objetos e 
classes e seus vínculos mútuos, evidenciando a sequência de mensagens. 
b) denota a estrutura estática de um sistema. 
c) descreve a funcionalidade do sistema. 
d) descreve a interação de sequência de tempo dos objetos e classes 
percebida por atores externos. 
e) mostra as sequências de estados que uma classe e objetos assumem em 
sua vida em resposta a estímulos recebidos, juntamente com suas 
respostas e ações. 
 
Comentários 
Item a. O Diagrama de Classe mostra as diferentes classes que fazem um 
sistema e como elas se relacionam. Os diagramas de classe são chamados 
diagramas “estáticos” porque mostram as classes, com seus métodos e 
atributos bem como os relacionamentos estáticos entre elas: quais classes 
“conhecem” quais classes ou quais classes “são parte” de outras classes, mas 
não mostram a troca de mensagens entre elas. ITEM FALSO. 
Item b. Como foi mencionada na letra anterior, os Diagramas de Classe são 
chamados diagramas “estáticos” porque mostram as classes, com seus 
métodos e atributos bem como os relacionamentos estáticos entre elas. ITEM 
VERDADEIRO. 
 
Item c. O diagrama de caso de uso descreve a funcionalidade proposta para 
um novo sistema, que será projetado, ou seja, não está relacionado com o 
diagrama de classes. ITEM FALSO. 
 
Item d. A interação de sequência de tempo dos objetos e classes está 
relacionada ao diagrama de sequência. É representando pela sequência de 
processos (mais especificamente, de mensagens passadas entre objetos). O 
diagrama de sequência descreve a maneira como os grupos de objetos 
colaboram em algum comportamento ao longo do tempo. ITEM FALSO. 
Item e. O diagrama de estados mostra como um único objeto se comporta 
através de muitos casos de uso; mostra sequências de estados que um objeto 
ou uma interação assume em sua vida em resposta a eventos, juntamente 
com suas respostas e ações; é um complemento de uma classe relacionando 
os possíveis estados que objetos da classe podem ter e quais eventos podem 
causar a mudança de estado (transição). Este então não está relacionado ao 
diagrama de classes. ITEM FALSO. 
Gabarito: letra B. 
TI EM EXERCÍCIOS P/ INSS 
Conhecimentos específicos - Formação em Tecnologia da Informação (TEINF) 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 29 de 92 
 
12. (FUNRIO/Analista de Sistemas/FURB/2010) Com base no 
Diagrama de Classe do Anexo II, indique a alternativa correta. 
 
 A) Os atributos da Classe A podem ser alterado indistintamente por qualquer 
outra classediretamente. 
B) A classe A possui um método que pode ser usado por outros métodos de 
qualquer classe. 
C) Todos os métodos da Classe A podem ser usados pelas suas classes 
derivadas. 
D) O mecanismo de mensagem deverá ser usado por outra classe para 
alteração de pelo menos 1 atributo da classe A. 
E) Os atributos da Classe A não podem ser herdados. 
 
Comentários 
Uma subclasse (ou classe derivada) é uma classe que herda comportamentos 
de outra classe, podendo sobrecarregar funcionalidades e adicionar novas a 
uma classe base (ou classe pai), construtores e destrutores não são herdados, 
e somente métodos e atributos públicos e protegidos são herdados. Métodos 
públicos e protegidos podem ser visíveis por outras classes. 
Gabarito: letra C. 
 
13. (CEPERJ/2010/IPEM-RJ/Analista de Sistemas) Um modelo é uma 
abstração de algo com a finalidade de entendê-lo antes de construí-lo. 
Todo sistema desenvolvido deve ser modelado e, nesse sentido, existem 
pontos de vista distintos, porém relacionados, cada qual capturando 
aspectos importantes e necessários para uma descrição completa. 
Enquanto o modelo de interações representa a colaboração de objetos 
individuais, os aspectos de “interações” de um sistema representam os 
aspectos estáticos, estruturais de “dados” e também podem representar os 
aspectos temporais e comportamentais, de “controle” desse mesmo 
sistema. Esses dois últimos são denominados, respectivamente, modelos 
de: 
TI EM EXERCÍCIOS P/ INSS 
Conhecimentos específicos - Formação em Tecnologia da Informação (TEINF) 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 30 de 92 
A) Classes e Estados 
B) Dados e Controle 
C) Eventos e Estados 
D) Dados e Estados 
E) Classes e Controle 
 
Comentários 
Os dois últimos modelos “dados” e “controle” correspondem aos modelos de 
Classes e Estados, letra A. 
Classificação significa que os objetos com a mesma estrutura de dados 
(chamados atributos) e o mesmo comportamento (chamados operações ou 
métodos) são agrupados em uma classe. Classe é uma abstração que descreve 
propriedades importantes para uma aplicação e ignora o restante. O objetivo 
de um diagrama de classes é descrever os vários tipos de objetos no sistema e 
o relacionamento entre eles. 
Um diagrama de classes pode oferecer três perspectivas, cada uma para um 
tipo de observador diferente. São elas: 
• Conceitual 
o Representa os conceitos do domínio em estudo. 
o Perspectiva destinada ao cliente. 
• Especificação 
o Tem foco nas principais interfaces da arquitetura, nos principais 
métodos, e não como eles irão ser implementados. 
o Perspectiva destinada as pessoas que não precisam saber detalhes 
de desenvolvimento, tais como gerentes de projeto. 
• Implementação - a mais utilizada de todas 
o Aborda vários detalhes de implementação, tais como 
navegabilidade, tipo dos atributos, etc. 
 o Perspectiva destinada ao time de desenvolvimento. 
Um diagrama de classes contém: 
 * Entidades 
 * Relacionamentos 
Os Diagramas de Máquinas de Estados, ou simplesmente Diagramas de 
Estados, descrevem o comportamento dinâmico do sistema, representando os 
estados que um objeto passa durante a execução do sistema e como ele 
muda de estado em respostas aos eventos. Cada diagrama representa uma 
classe única. 
Em um diagrama de estado, um objeto possui um comportamento e um 
estado. O estado de um objeto depende da atividade na qual ele está 
TI EM EXERCÍCIOS P/ INSS 
Conhecimentos específicos - Formação em Tecnologia da Informação (TEINF) 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 31 de 92 
processando. Um diagrama de estado mostra os possíveis estados de um 
objeto e as transações responsáveis pelas suas mudanças de estado. 
Gabarito: letra A. 
 
14. (CEPERJ/2010/IPEM-RJ/Analista de Sistemas) A Engenharia de 
Requisitos fornece o mecanismo apropriado para entender o que o cliente 
deseja, analisando as necessidades, avaliando a exequibilidade, 
negociando uma condição razoável, especificando a solução de forma clara, 
validando a especificação e gerindo os requisitos à medida que eles são 
transformados em um sistema operacional. Considerando esse contexto, 
observe a figura abaixo, utilizada no levantamento de requisitos. 
 
 
 
Essa figura é conhecida por Diagrama: 
A) Funcional 
B) De Classes 
C) De Contexto 
D) De Atividades 
TI EM EXERCÍCIOS P/ INSS 
Conhecimentos específicos - Formação em Tecnologia da Informação (TEINF) 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 32 de 92 
E) Comportamental 
 
Comentários 
O objetivo do diagrama de atividades é mostrar o fluxo de atividades em um 
único processo. O diagrama mostra como uma atividade depende uma da 
outra. 
 
Um diagrama de atividade pode ser regiões denominadas swimlanes. Estas 
regiões estão associadas a um objeto do modelo. Desta forma, dentro de cada 
região, encontram-se as atividades relativas ao objeto da região. As atividades 
são conectadas através de arcos (transições), que mostram as dependências 
entre elas. 
 
Gabarito: letra D. 
 
15. (CEPERJ/2010/IPEM-RJ/Analista de Sistemas) A UML é uma 
linguagem de modelagem visual, podendo ser definida como um conjunto 
de notações e semântica correspondente para representar visualmente 
uma ou mais perspectivas de um sistema. Dentre os diagramas da UML, 
um diagrama foca os requisitos funcionais de um sistema, forçando os 
TI EM EXERCÍCIOS P/ INSS 
Conhecimentos específicos - Formação em Tecnologia da Informação (TEINF) 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 33 de 92 
desenvolvedores a moldarem o sistema de acordo com o usuário, e não o 
usuário de acordo com o sistema, representando as especificações de uma 
sequência de interações entre um sistema e os agentes externos que 
utilizam esse sistema, por meio dos atores e relacionamentos entre eles. 
Esse diagrama é denominado: 
A) Casos de uso 
B) Casos de negócios 
C) Processos e funções 
D) Entidades e relacionamentos 
E) Processos e relacionamentos 
 
Comentários 
O diagrama que foca os requisitos funcionais de um sistema é o diagrama de 
casos de uso. 
Os casos de uso descrevem funcionalidades do sistema percebidas por atores 
externos. Um ator é uma pessoa (ou dispositivo, ou outro sistema) que 
interage com o sistema. 
 
 
Gabarito: letra A. 
 
16. (ESAF/2008/AFC/STN/ TI – Desenvolvimento de Sistemas) Em 
UML (Unified Modeling Language), o diagrama cujo foco é a organização 
estrutural de objetos que enviam e recebem mensagens, exibindo assim, 
tais objetos e as ligações entre eles, bem como as respectivas mensagens, 
é o diagrama de 
a) componentes. 
b) colaboração. 
c) objetos. 
d) atividades. 
e) caso de uso. 
 
 
 
 
TI EM EXERCÍCIOS P/ INSS 
Conhecimentos específicos - Formação em Tecnologia da Informação (TEINF) 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 34 de 92 
Comentários 
Item a. Ilustra como as classes deverão se encontrar organizadas através da 
noção de componentes de trabalho. Por exemplo, pode-se explicitar, para cada 
componente, qual das classes que ele representa. Item FALSO. 
Item b. Exibe uma interação, consistindo de um conjunto de objetos e seus 
relacionamentos, incluindo as mensagens que podem ser trocadas entre eles. 
Item VERDADEIRO. 
Item c. É uma variação do diagrama de classes e utiliza quase a mesma 
notação. A diferença é que o diagrama de objetos mostra os objetos que foram 
instanciados das classes. O diagrama de objetos é como se fosse o perfil do 
sistemaem um certo momento de sua execução. Item FALSO. 
Item d. Representa os fluxos conduzidos por processamentos. É 
essencialmente um gráfico de fluxo, mostrando o fluxo de controle de uma 
atividade para outra. Isso envolve a modelagem das etapas sequenciais em 
um processo computacional. Item FALSO. 
Item e. Descreve a funcionalidade proposta para um novo sistema, que será 
projetado. Representa uma unidade discreta da interação entre um usuário 
(humano ou máquina) e o sistema. São tipicamente relacionados a "atores". 
Um ator é um humano ou entidade máquina que interage com o sistema para 
executar uma determinada tarefa. Item FALSO. 
Gabarito: letra B. 
 
17. (ESAF/2008/AFC/STN/TI/Infraestrutura) O diagrama UML que 
apresenta objetos e suas ligações mútuas, evidenciando a sequência das 
mensagens trocadas por meio de números de sequência, é o 
a) Diagrama de sequência. 
b) Diagrama de estado. 
c) Diagrama de colaboração. 
d) Diagrama de caso de uso. 
e) Diagrama de atividade. 
 
Comentários 
Item a. O Diagrama de Sequência representa a sequência de processos 
(mais especificamente, de mensagens passadas entre objetos) num programa 
de computador. Como um projeto pode ter uma grande quantidade de 
métodos em classes diferentes, pode ser difícil determinar a sequência global 
do comportamento. O diagrama de sequência representa essa informação de 
uma forma simples e lógica. Este descreve a maneira como os grupos de 
objetos colaboram em algum comportamento ao longo do tempo. Ele registra o 
comportamento de um único caso de uso e exibe os objetos e as mensagens 
passadas entre esses objetos no caso de uso. Item FALSO. 
TI EM EXERCÍCIOS P/ INSS 
Conhecimentos específicos - Formação em Tecnologia da Informação (TEINF) 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 35 de 92 
Item b. O Diagrama de Estado mostra o ciclo de vida de um objeto os 
eventos pelos quais ele passa, as suas transições e os estados em que ele está 
entre estes eventos. Um estado de um objeto é um conjunto de circunstâncias 
ou atributos que caracterizam o objeto em determinado momento. Item 
FALSO. 
Item c. O Diagrama de Colaboração exibe uma interação, consistindo de um 
conjunto de objetos e seus relacionamentos, incluindo as mensagens que 
podem ser trocadas entre eles. O Diagrama de colaboração mostra, de 
maneira semelhante ao diagrama de sequência, a colaboração dinâmica entre 
os objetos. Se a ênfase do diagrama for o contexto do sistema, o diagrama de 
colaboração é o utilizado. Item VERDADEIRO. 
Item d. Tem o objetivo de auxiliar a comunicação entre os analistas e o cliente. 
Descreve um cenário que mostra as funcionalidades do sistema do ponto de 
vista do usuário. O cliente deve ver no diagrama de casos de uso as principais 
funcionalidades de seu sistema. Item FALSO. 
Item e. Uma atividade é o estado de estar fazendo algo: tanto um processo 
de mundo real, tal como datilografar uma carta, ou a execução de uma rotina 
de software, tal como um método em uma classe. Este descreve a sequência 
de atividades, com suporte para comportamento condicional e paralelo. Um 
Diagrama de Atividades é uma variante de um diagrama de estados no qual 
a maioria, se não todos, dos estados é estado de atividade. Portanto, muito da 
terminologia segue a mesma terminologia de estados. Item FALSO. 
Gabarito: letra C. 
 
18. (ESAF/2008/AFC/STN/TI/Infraestrutura) Considere o seguinte 
contexto: “Um cliente pode comprar vários livros”. Em um diagrama de 
classes, este é um exemplo de relacionamento do tipo 
a) Agregação. 
b) Generalização. 
c) Especialização. 
d) Associação. 
e) Dependência. 
 
Comentários 
Item a. Item FALSO. Agregação é uma forma especializada de associação na 
qual um todo é relacionado com suas partes. Também conhecida como relação 
de conteúdo. É representada como uma linha de associação com um diamante 
junto à Classe agregadora. A multiplicidade é representada da mesma maneira 
que nas associações. 
Complementando, a agregação é um caso particular da associação. A 
agregação indica que uma das classes do relacionamento é uma parte, ou está 
contida em outra classe. As palavras chaves usadas para identificar uma 
agregação são: “consiste em”, “contém”, “é parte de”. 
TI EM EXERCÍCIOS P/ INSS 
Conhecimentos específicos - Formação em Tecnologia da Informação (TEINF) 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 40 de 92 
Comentários 
Item a. Adornos são detalhes da especificação adicionados às extremidades 
das linhas que representam os relacionamentos, usados na notação gráfica. 
Item FALSO. 
Item b. Permite estender o vocabulário da linguagem, criando novos elementos 
de modelagem. O estereótipo estende a semântica mas não a estrutura do 
elemento. Podem-se criar novos ícones para representar esses elementos 
numa forma gráfica individualizada. Item VERDADEIRO. 
Item c. Uma restrição estende a semântica de um elemento UML, permitindo 
a definição de novas regras ou modificação de regras existentes. Item FALSO. 
Item d. A UML não é só uma linguagem gráfica, por trás de toda parte gráfica 
há uma especificação que define a sintaxe e semântica de um elemento. A 
especificação pode ser construída de forma incremental e estará sempre por 
trás, valendo, para qualquer tipo de exibição utilizado. As especificações UML 
proveem um pano de fundo que envolve todas as partes de um modelo. Item 
FALSO. 
Item e. São relacionamentos de utilização no qual uma mudança na 
especificação de um elemento pode alterar a especificação do elemento 
dependente. A dependência entre classes indica que os objetos de uma classe 
usam serviços dos objetos de outra classe. Item FALSO. 
Gabarito: letra B. 
 
20. (FUNRIO/Analista – Área S4/MPOG/2009) Os modelos ágeis de 
desenvolvimento de software foram projetados para atender a quatro 
tópicos-chave. Qual das alternativas NÃO É um tópico-chave? 
 
A) Importância de equipes auto-organizadas que têm controle sobre o trabalho 
que executam. 
B) Automatização da documentação dos sistemas em bases de conhecimento. 
C) Comunicação e colaboração entre os membros da equipe e entre os 
profissionais e seus clientes. 
D) Reconhecimento de que modificações representam uma oportunidade. 
E) Ênfase na entrega rápida de softwares que satisfaçam ao cliente. 
 
Comentários 
Ágil é uma nova forma de gestão e desenvolvimento de Software que usa uma 
abordagem de planejamento e execução iterativa e incremental voltado para 
processos empíricos que divide o problema em produtos menores e que visa 
entregar software funcionando regularmente, visa a aproximação e maior 
colaboração do time de desenvolvimento com os experts de negócios, 
comunicação face-to-face, redução dos riscos associados as incertezas dos 
projetos, abraçar e responder as mudanças de forma mais rápida e natural e é 
TI EM EXERCÍCIOS P/ INSS 
Conhecimentos específicos - Formação em Tecnologia da Informação (TEINF) 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 41 de 92 
claro a satisfação final dos clientes por meio da adoção de práticas de gestão e 
de engenharia de software com foco nos valores e princípios do Lean e do 
agile, resumindo, seu principal objetivo é entregar o produto que o cliente 
realmente deseja e que será útil e com qualidade. 
Gabarito: letra B. 
 
Com relação a conceitos gerais de engenharia de software, julgue os itens a 
seguir. 
21. (CESPE/TRT - 10ª REGIÃO (DF e TO) - Analista Judiciário - 
Tecnologia da Informação/2013) As atividades fundamentais 
relacionadas ao processo de construção de um software incluem a 
especificação, o desenvolvimento, a validação e a evolução do software. 
 
ComentáriosUm processo de software é um conjunto de atividades e resultados associados 
que levam à produção de um produto de software. 
Nesse contexto, Sommerville (2007, p. 43) destaca as quatro atividades 
fundamentais do processos de software, comuns a todos eles, que são: 
especificação de software, projeto e implementação de software, 
validação de software e evolução do software. 
 
Especificação de Software São definidas as funcionalidades do 
software e restrições para sua operação. 
Projeto e Implementação de 
Software 
O software que atenda à especificação 
deve ser produzido. 
Validação de Software O software deve ser avaliado para 
garantir que ele faça o que o cliente 
deseja. 
Evolução do Software O software evolui para atender às 
necessidades de mudança do cliente. 
Segundo o autor, essas atividades são organizadas de modo diferente nos 
diversos processos de desenvolvimento. Como exemplo, no modelo em cascata 
são organizadas em sequência, ao passo que, no desenvolvimento 
evolucionário, elas são intercaladas. Como essas atividades serão organizadas 
dependerá do tipo de software, pessoas e estruturas organizacionais 
envolvidas. 
Com algumas variações de nomes entre os principais autores da área 
(Pressman e Sommerville), é correto destacar que as quatro atividades 
básicas do processo de software são: especificação, desenvolvimento, 
validação e evolução. 
Gabarito: item correto. 
TI EM EXERCÍCIOS P/ INSS 
Conhecimentos específicos - Formação em Tecnologia da Informação (TEINF) 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 42 de 92 
22. (CESPE/ 2013 /TRT - 10ª REGIÃO (DF e TO)/Analista Judiciário 
- Tecnologia da Informação) O ciclo de vida de um software, entre 
outras características, está relacionado aos estágios de concepção, projeto, 
criação e implementação. 
 
Comentários 
Sommerville (2007, p. 43) destaca as quatro atividades fundamentais do 
processos de software, comuns a todos eles, que são: especificação de 
software, projeto e implementação de software, validação de software 
e evolução do software. Segundo o autor, essas atividades são organizadas 
de modo diferente nos diversos processos de desenvolvimento. 
Pressman (2011) destaca que uma metodologia de processo genérica para 
Engenharia de Software compreende cinco atividades: 
• Comunicação – Antes de iniciar o trabalho, é de vital importância 
comunicar-se e colaborar com o cliente (e outros interessados, como: 
executivos, usuários finais, engenheiros de software, o pessoal de suporte, 
etc.). A intenção aqui é compreender os objetivos das partes interessadas 
para com o projeto e fazer o levantamento das necessidades que ajudarão a 
definir as funções e características do software. 
• Planejamento – Estabelecimento do plano de projeto de software, que 
descreve as tarefas técnicas a ser conduzidas, os riscos prováveis, os 
recursos que serão necessários, os produtos resultantes a ser produzidos e 
um cronograma de trabalho. 
• Modelagem – Criação de modelos representativos do software (para 
melhor entender as necessidades do software e o projeto que irá atender a 
essas necessidades). 
• Construção – Essa atividade combina geração de código (manual ou 
automatizada) e testes necessários para revelar erros na codificação. 
• Entrega (Implantação) – Entrega do produto ao cliente, que irá avalia-lo 
e fornecer feedback baseado na avaliação. 
Essas cinco atividades metodológicas genéricas podem ser utilizadas para o 
desenvolvimento de programas pequenos e simples, para a criação de grandes 
aplicações para a Internet e para a engenharia de grandes e complexos 
sistemas baseados em computador (Pressman, 2011). 
As atividades metodológicas são complementadas pelas atividades de apoio 
(umbrella activities), como: controle e acompanhamento do projeto, 
administração de riscos, garantia da qualidade, gerenciamento da configuração 
de software, dentre outras. 
Observe que os 2 autores trabalham com um modelo genérico de processo de 
software, e não com o ciclo de vida do software. No entanto, conceitualmente 
falando, o modelo de processo de software não se diferencia do modelo de 
ciclo de vida, ambos trazem uma descrição, em alto nível, das atividades 
envolvidas na construção de um software e suas dependências. Ainda, cabe 
destacar que as sequências de atividades trazidas pelo Pressman e 
TI EM EXERCÍCIOS P/ INSS 
Conhecimentos específicos - Formação em Tecnologia da Informação (TEINF) 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 43 de 92 
Sommerville são essencialmente iguais e estão falando do mesmo processo: o 
desenvolvimento de um software. 
Assim, pode-se destacar que o ciclo de vida de um software, entre outras 
características, estará relacionado aos estágios de concepção, projeto, criação 
e implementação. 
Gabarito: item correto. 
 
23. (CESPE/TRE-BA/Analista de Sistemas/2010) Com relação à 
engenharia de software, julgue o item a seguir. Entre os desafios 
enfrentados pela engenharia de software estão lidar com sistemas legados, 
atender à crescente diversidade e atender às exigências quanto a prazos 
de entrega reduzidos. 
 
Comentários 
A proposta da Engenharia de software é possibilitar o desenvolvimento 
adequado do software, frente a inúmeros desafios, como: lidar com sistemas 
legados (sistemas de software mais velhos que permanecem vital para uma 
organização), atender à crescente diversidade e atender às exigências quanto 
a prazos de entrega limitados. 
Gabarito: item correto. 
 
24. (ESAF/MPOG/2008) O processo da engenharia de sistemas possui 
importantes diferenças em relação ao processo de desenvolvimento de 
software, principalmente no que se refere às suas fases. Indique a opção 
que representa as fases do processo da engenharia de sistemas. 
a) Comunicação, Planejamento, Modelagem, Construção e Implantação. 
b) Análise de requisitos, Projeto do sistema, Projeto do programa, 
Codificação, Testes de Unidades e de Integração, Teste do sistema, Teste 
de Aceitação, Operação e Manutenção. 
c) Definição de Requisitos, Projeto de sistemas e de software, 
Implementação e testes de unidades, Integração e testes de sistemas, 
Operação e manutenção. 
d) Análise dos requisitos do sistema, Projeto da arquitetura do sistema, 
Codificação e testes do sistema, Integração e teste do sistema, Teste de 
qualificação do sistema, Instalação do sistema e Descontinuação do 
sistema. 
e) Definição de requisitos, Projeto do sistema, Desenvolvimento de 
subsistemas, Integração do sistema, Instalação do sistema, Evolução do 
sistema e Desativação do sistema. 
 
 
 
TI EM EXERCÍCIOS P/ INSS 
Conhecimentos específicos - Formação em Tecnologia da Informação (TEINF) 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 44 de 92 
Comentários 
A engenharia de sistemas é uma atividade de especificação, projeto, 
implementação, validação, implantação e manutenção de sistemas 
sociotécnicos. 
Os engenheiros de sistema são responsáveis pelos softwares, e não somente 
esses, mas também o hardware, as interações do sistema com os usuários e 
seu ambiente. Além disso, serviços que o sistema fornece, restrições de 
operação, criação e utilização, a fim de atingir seu propósito (SOMMERVILLE, 
2007). 
 
Figura. Fonte: (SOMMERVILLE, 2007) 
Gabarito: letra E. 
 
25. (CESPE/2013/TRT - 10ª REGIÃO (DF e TO)/Analista Judiciário - 
Tecnologia da Informação) Com relação a conceitos gerais de 
engenharia de software, julgue os itens a seguir. 
A engenharia de software engloba processos, métodos e ferramentas. Um de 
seus focos é a produção de software de alta qualidade a custos adequados. 
 
Comentários 
• Processo