EXE - ANA - DESENV - Aula 03

INFORMÁTICA EM EXERCÍCIOS PARA BNDES
FORMAÇÃO: ANÁLISE DE SISTEMAS - DESENVOLVIMENTO
Aula 3 – Engenharia de Software e Tópicos Relacionados
Olá queridos(as) amigos (as)!
“Quem acredita sempre alcança”. Importante acreditar em si mesmo, e

seguir firme no grande propósito, com muita energia, persistência, garra, e fé
em DEUS, SEMPRE!!!
Tópicos do Edital a Serem Abordados na Aula

II - ENGENHARIA DE SOFTWARE:
1. Conceitos: Gerência e desenvolvimento de Requisitos. Solução Técnica.
Integração do Produto; Verificação (Teste de Software e Revisão por Pares).
Validação. Modelos de ciclo de vida.
2. Análise e projeto de sistemas: Análise e projeto estruturado de sistemas;
Análise e projeto orientado a objetos com notação UML; Acoplamento e
coesão. CMMI (Capability Maturity Model Integration) para desenvolvimento
versão 1.2.
3. Processos de Software: Scrum; eXtremme Programming (XP); Processo de
desenvolvimento de software unificado - Unified Process.
IV - PROGRAMAÇÃO E ARQUITETURA:
10. Testes: Conceitos (verificação e validação); Tipos de Testes (Unidade,
Integração, Funcional, Aceitação, Carga, Desempenho, Vulnerabilidade,
Usabilidade).
Abraços.
Profa Patrícia Lima Quintão
patricia@pontodosconcursos.com.br
Twitter: http://www.twitter.com/pquintao
Facebook: http://www.facebook.com/patricia.quintao
Roteiro da Aula
-Notas de Aula.
- Questões de provas comentadas.
- Bibliografia.
- Considerações finais.
- Lista das questões apresentadas na aula.
- Gabarito.
-NOTAS DE AULA-
Antes de partir para as questões, vamos a algumas observações importantes!
Visão geral do CMMI e seus objetivos gerais
Definição e Objetivos
O Instituto de Engenharia de Software (SEI – Software Engineering Institute)
foi criado para aumentar a capacitação da indústria de software dos EUA. Em
meados da década de 1980, o SEI iniciou um estudo de formas de avaliação de
capacitação de fornecedores. O resultado dessa avaliação de capacitação foi o
Modelo de Maturidade de Capacitação (CMM – Capability Maturity Model) do
SEI. Esse modelo exerceu forte influência no convencimento da comunidade de
engenharia de software em considerar seriamente o aprimoramento de
processos.
O modelo CMM que tem sido largamente adotado pela comunidade de software
internacional é focado na capacidade organizacional e categoriza as
organizações em cinco níveis de maturidade, desde um processo ad hoc e
desorganizado (nível 1), até um estágio altamente gerenciado de melhoria
contínua (nível 5).
Esses níveis de maturidade são definidos em áreas-chave de processo, que
por sua vez, possuem metas que devem ser atingidas por meio da
implementação de práticas-chaves, categorizadas no que o modelo chama de
características comuns (VASCONCELOS, 2006).
O CMM para software foi seguido por uma variedade de outros modelos de
maturidade de capacitação. Assim, no mercado, existem vários modelos e não
apenas “um CMM”. Existe o SW-CMM (software-CMM), voltado ao
desenvolvimento e manutenção de software; o SECM (Systems Engineering
Capability Model), voltado à engenharia de sistemas; o SACMM (Software
Acquisition Capability Maturity Model), voltado ao processo de compras ou
aquisição; entre outros.
Outras organizações desenvolveram modelos de maturidade de processos
semelhantes. A abordagem do SPICE para avaliação de capacitação e o
aprimoramento de processos é mais flexível do que o modelo do SEI. Ele inclui
níveis de maturidade comparáveis aos níveis do SEI, mas também identifica
processos, como processos cliente-fornecedor, que atravessam esses níveis. À
medida que a maturidade aumenta, o desempenho dos processos principais
deve melhorar.
Assim, em uma tentativa de integrar a grande quantidade de modelos que
foram desenvolvidos (entre eles os seus próprios modelos), o SEI embarcou
em um novo programa para desenvolver um Modelo Integrado de
Maturidade e de Capacidade (CMMI - Capability Maturity Model
Profa. Patrícia Lima Quintão www.pontodosconcursos.com.br 2
Integration). Este substitui os CMMs de Engenharia de Sistemas e o de

Software e integra outros modelos de engenharia.
O CMMI (Capability Maturity Model Integration) é um modelo de

maturidade de melhoria de processos para desenvolvimento de produtos e
serviços (CMMI, 2006). Seu principal propósito é fornecer diretrizes baseadas
nas melhores práticas voltadas para atividades de desenvolvimento e
manutenção, abrangendo todo o ciclo de vida do produto, desde a concepção,
desenvolvimento, aquisição até a entrega e manutenção.
As abordagens do CMMI envolvem a avaliação da maturidade da organização
ou a capacitação das suas áreas de processo, o estabelecimento de prioridades
e a implementação de ações de melhorias (FERNANDES, 2008).
O modelo CMMI tem a intenção de ser um framework de aprimoramento de
processos que tem aplicabilidade ampla por meio de uma variedade de
empresas. O CMMI possibilita abordar melhoria e avaliação de
processos utilizando duas representações diferentes: contínua e por
estágios.
A representação contínua permite que a organização escolha uma
determinada área de processo (ou grupo de áreas de processo) e melhore
processos relacionados a ela. Essa representação utiliza níveis de capacidade
para caracterizar a melhoria associada a uma área de processo em particular
(CMMI, 2006).
A representação por estágios utiliza conjuntos predefinidos de áreas de
processo para definir um caminho de melhoria para uma organização. Esse
caminho de melhoria é caracterizado por níveis de maturidade. Cada nível de
maturidade contém um conjunto de áreas de processos que caracterizam
diferentes comportamentos organizacionais (CMMI, 2006).
Conceitos Básicos
Segundo destaca a revista “Engenharia de Software Magazine”, na edição 21,
o modelo CMMI possui duas abordagens: contínua e por estágios,
permitindo à organização optar pela mais adequada a seu contexto.
Atendendo a requisitos de “componentização”, a versão 1.2 do CMMI
apresenta tais abordagens reunidas em um mesmo documento, dentro do
escopo de cada constelação.
Uma constelação é uma coleção de componentes do CMMI que
compreende um modelo, seus materiais de treinamento e documentos
relacionados à avaliação para uma área de interesse. “Adições” podem
ser usadas para expandir constelações com conteúdos específicos adicionais.
Atualmente, três constelações (ou modelos) são suportadas pela versão 1.2 do
CMMI:
• CMMI for Development (CMMI-DEV) – fornece diretivas para monitoração,

medição e gerenciamento de processos de desenvolvimento. Pode ser
estendido através da adição para o Desenvolvimento Integrado de Produto e
Processo (IPPD);
• CMMI for Services (CMMI-SVC) – fornece diretivas para entrega de serviços
dentro das organizações e para clientes externos;
• CMMI for Acquisition (CMMI-ACQ) – fornece diretivas para suporte às
decisões relacionadas à aquisição de produtos e serviços.
Testes de Software
O teste é somente um elemento de um conceito mais amplo da engenharia de
software, conhecido como Verificação e Validação.
• A verificação refere-se ao conjunto de atividades que garante que o
software realiza corretamente uma função específica.
• A validação refere-se a um conjunto diferente de atividades que
garante que o software que foi construído e é rastreável às exigências do
cliente. Sob outro ponto de vista, proposto por Boehm:
• Verificação: "Estamos construindo certo o produto?"
• Validação: "Estamos construindo o produto certo?"
Teste Caixa Preta e Teste Caixa Branca

A divisão mais genérica para testes é provavelmente a divisão entre caixa
preta e caixa branca. Basicamente existem dois tipos testes: caixa branca e
caixa preta.
Nenhuma delas é completa, na realidade elas se completam e devem ser
aplicadas em conjunto a fim de garantir um teste de boa qualidade.
Os testes dinâmicos são aqueles que para a sua execução dependem da

execução de programas. Podem ser Testes de Caixa Preta e Teste de Caixa
Branca.
Os Testes de Caixa Preta são conhecidos por serem mais simples de se
implantar do que os testes de caixa branca. Na verdade, ambos são complexos
e exigem grande esforço de planejamento e automação dos procedimentos,
porém os testes de caixa preta são frequentemente encontrados nas
organizações, em forma de testes manuais executados por profissionais ou
mesmo usuários do sistema, o que facilita a introdução desse conceito nas

organizações. A aplicação de testes de caixa preta não exclui a necessidade de

aplicarmos os testes de caixa branca e vice-versa.
Teste Caixa-branca
O teste estrutural é também chamado de teste de caixa-branca ou
orientado à lógica. A técnica de caixa-branca avalia o comportamento
interno do componente de software, trabalhando diretamente sobre o código
fonte do componente de software para avaliar aspectos tais como: teste de
condição, teste de fluxo de dados, teste de ciclos, teste de caminhos lógicos,
códigos nunca executados. Podemos dizer que os testes caixa-branca são
baseados em um exame rigoroso do detalhe procedimental e que caminhos
lógicos e colaborações entre componentes são testadas.
Técnicas de Teste Caixa-Branca

Usando métodos de teste caixa-branca, podemos derivar casos de teste que:
1. Garantam que todos os caminhos independentes de um módulo sejam
executados pelo menos uma vez.
2. Exercitem todas as decisões lógicas de seu lado verdadeiro e falso.
3. Executem todos os ciclos (loops) nos seus limites e dentro de seus
intervalos operacionais.
4. Exercitem as estruturas de dados internas.
Tipos de teste caixa-branca:

– Teste de Caminho Básico
– Teste de Estrutura de Controle
Teste Caixa Preta (funcional)

É o tipo de teste onde o programa é considerado uma entidade fechada e a sua
estrutura interna não é considerada. Apenas as especificações do programa e
os requisitos do software são considerados no momento da execução dos
testes.

O teste caixa preta é também chamado de teste funcional. O nome “caixa

preta” é usado também na engenharia, no problema de identificação de
sistemas, e advém do fato de que ao analisar o comportamento de um objeto,
ignora-se totalmente sua construção interna.
O teste de caixa preta é baseado nos requisitos funcionais do software. Como
não há conhecimento sobre a operação interna do programa, o avaliador se
concentra nas funções que o software deve desempenhar. A partir da
especificação são determinadas as saídas esperadas para certos conjuntos de
entrada de dados.
Esse tipo de teste reflete, de certa forma, a ótica do usuário, que está
interessado em se servir do programa sem considerar os detalhes de sua
construção.
Comparado a outros tipos de teste, este é relativamente mais simples. Um
exemplo simples de aplicação é verificar a consistência de dados de interface.
Um exemplo de aplicação do teste é fazer entradas de dados e observar o
comportamento do programa.
O Teste de Caixa Preta é executado tomando-se como base os requisitos e
funcionalidades do software. Uma atividade que muitas vezes precede a
execução desse tipo de teste é a criação de uma massa de testes. Planejam-se
determinados tipos de entrada e definem-se quais os resultados esperados
após o programa processar aquelas entradas, ou seja, determinam-se tipos de
entrada, é esperado que o programa produza determinado tipo de saída.
A realização de testes visa principalmente:

• Executar um programa com a intenção de descobrir erros;
• Um bom caso de teste é aquele que tem uma elevada probabilidade de
revelar um erro ainda não descoberto; e
• Um teste bem-sucedido é aquele que revela um erro ainda não
descoberto ou inesperado.
Os objetivos apontados acima apresentam uma visão diferente daquela que se
costuma possuir com relação à atividade de testes, que seria a de que um
teste bem-sucedido não apontaria erros. O objetivo na verdade é projetar
testes que encontrem sistematicamente diferentes classes de erros e façam-no
com uma quantidade de tempo e esforço mínimos.
Se a atividade de testes for conduzida com sucesso, ela descobrirá erros no

software. Como um benefício secundário, a atividade de teste demonstra que
as funções de software aparentemente estão trabalhando de acordo com as
especificações, que os requisitos de desempenho aparentemente foram
cumpridos. Além disso, os dados compilados quando a atividade de testes é
levada a efeito, proporcionam uma boa indicação da confiabilidade de software
e alguma indicação da qualidade do software como um todo.
Testes de Integração
O teste de integração é uma técnica sistemática para a construção da
estrutura do programa, realizando testes para descobrir erros associados a
interface. O objetivo deste teste é construir a estrutura de programa que foi
determinada pelo projeto a partir dos testes realizados em unidades.
Mesmo que todos os módulos estejam funcionando individualmente, não se
pode garantir que eles funcionarão em conjunto.
– Dados podem ser perdidos na interface
– Imprecisão aceitável individualmente pode ser amplificada
– Estruturas de dados globais podem apresentar problemas
O Teste de integração é uma técnica sistemática para construir a arquitetura
do software enquanto se conduz testes para descobrir erros.
Abordagens de Integração
• Abordagem big-bang
– Todos os componentes são combinados com antecedência.
– O programa inteiro é testado de uma vez.
– Usualmente resulta em caos!
• A correção é difícil, porque fica complicado isolar as causas dos erros.
• Uma vez corrigidos os erros, novos erros aparecem.
• Integração incremental
– É a antítese da abordagem big-bang.
– O programa é construído e testado em pequenos incrementos.
– Erros são mais fáceis de isolar e corrigir.
– Pode ser aplicada uma interface sistemática de testes.
– Há várias estratégias incrementais de integração.
• Integração descendente
• Integração ascendente
• Teste de regressão
• Teste fumaça
Integração Descendente
– Na integração descendente (top-down) os módulos são integrados
movendo-se de cima para baixo na hierarquia de controle.
– Começa pelo módulo de controle principal.
– Os módulos subordinados são incorporados à estrutura de uma de duas
maneiras:
• Primeiro-em-profundidade (depth-first)
• Primeiro-em-largura (breadth-first)
Integração Descendente Primeiro-em-profundidade
Integração Descendente Primeiro-em-largura
Passos de Integração Descendente

1. O módulo de controle principal é usado como pseudocontrolador do teste.
Pseudocontrolados substituem todos os componentes diretamente
subordinados ao principal.
2. Os pseudocontrolados são substituídos, um de cada vez, pelos componentes

reais.
3. Testes são conduzidos à medida que cada componente é integrado.
4. Ao término de cada conjunto de testes, outro pseudocontrolado é
substituído pelo componente real.
5. O teste de regressão pode ser conduzido para garantir que novos erros não
tenham sido introduzidos.
Desvantagem da Integração Descendente

O processamento nos níveis baixos da hierarquia pode ser necessário para
testar adequadamente os níveis superiores.
– Como são usados pseudocontrolados, nenhum dado significativo flui para
cima na estrutura do programa.
Três soluções são possíveis:
– Adiar alguns testes
– Desenvolver pseudocontrolados mais complexos
– Integrar o software de baixo para cima: integração ascendente.
Integração Ascendente
• Na integração ascendente (bottom-up) os módulos são integrados movendo-
se de baixo para cima na hierarquia de controle.
– Inicia a construção e teste pelos módulos atômicos.
– Elimina a necessidade de pseudocontrolados complexos.
Passos da Integração Ascendente

1. Componentes de baixo nível são combinados em agregados (clusters), que
realizam uma subfunção específica.
2. Um pseudocontrolador é escrito para coordenar a entrada e a saída do caso
de teste.
3. O agregado é testado.
4. Pseudocontroladores são removidos e agregados são combinados movendo-
se para cima na estrutura.

Integração Ascendente vs. Descendente

Integração Descendente
– Desvantagem: necessidade de pseudocontrolados.
– Vantagem: testar logo as principais funções de controle.
Integração Ascendente
– Desvantagem: o programa como um todo não é testado até o final.
– Vantagem: ausência de pseudocontrolados e projeto de casos de teste
facilitados.
Outros tipos de testes

• Testes de integração: executados em uma combinação de
componentes para verificar se eles funcionam corretamente juntos,
conforme as especificações.
• Testes unitários (teste de unidade): estágio mais baixo da escala de
testes e são aplicados nos menores componentes de código criados. Os
testes unitários verificam o funcionamento de um pedaço do sistema ou
software isoladamente ou que possam ser testados separadamente.
• Testes de regressão: visam a garantir que o software permaneça
intacto depois de novos testes serem realizados.
• Testes de carga: visam a avaliar a resposta de um software sob uma
pesada carga de dados ou uma grande quantidade de usuários
simultâneos para verificar o nível de escalabilidade, ou seja, o momento

em que o tempo de resposta começa a degradar ou a aplicação começa

a falhar. Estes testes devem ser aplicados durante os testes de sistema e
são chamados de testes de estresse.
• Testes de usabilidade: verificam o nível de facilidade de uso do
software pelos usuários.
• Testes de Segurança: validam a capacidade de proteção do software
contra acesso interno ou externo não autorizado.
• Testes de Desempenho (testes de performance): visam garantir
que o sistema atende aos níveis de desempenho e tempo de resposta
acordados com os usuários e definidos nos requisitos.
DIMENSÕES DO TESTE
A realização de testes é, quase sempre, limitada por restrições de cronograma
e orçamento; eles determinam quantos testes será possível executar. É
importante que os testes sejam bem planejados e desenhados, para conseguir-
se o melhor proveito possível dos recursos alocados para eles.
No planejamento temos que nos preocupar com:
• Quando testar?
• O que testar?
• Como testar?
• Qual Ambiente do teste executar o teste?
Devemos:
• Planejar os testes de forma organizada
• Testar a aplicação com bastante precisão.
“Afinal, mesmo que você não esteja vendo os “bugs”, eles estarão lá na
aplicação, esperando para ser encontrado e aguardando o momento certo para
aparecer...”. (SQA User Mailing List)

Primeira Dimensão: Estado do teste (“o momento”)

Momento onde haverá teste e o responsável por sua execução.
• Teste de Unidade
• Teste de Integração
• Teste de Sistema
• Teste de Aceitação
Segunda dimensão: Técnica do teste (“como vou testar”)

Fazer uma análise da aplicação e dizer qual técnica é mais apropriado para ser
seguida:
• Técnica de Teste Estrutural
• Técnica de Teste Funcional
De acordo com a técnica escolhemos os testes que serão executados:
• Teste Operacional
• Teste Negativo-Positivo
• Teste de Regressão
• Teste de Caixa-Preta
• Teste de Caixa-Branca
• Teste Beta
• Teste de Verificação de Versão
Terceira dimensão: Metas do Teste (“o que tenho de testar”)

Fazer uma análise do projeto e informar quais tipos de testes será executado.
É uma das mais fortes das três dimensões, mais conhecida como “tipo de
teste”.
• Teste Funcional
• Teste de Interface
• Teste de Performance e Teste de carga
• Teste de Aceitação do Usuário
• Teste de Estresse
• Teste de Volume
• Teste de Configuração
• Teste de Instalação
• Teste de Documentação
• Teste de Integridade
• Teste de Segurança
Quarta dimensão: Onde será o teste (“o ambiente do teste”)

Nessa dimensão definimos o ambiente onde as outras três dimensões irão
rodar, observando as evoluções tecnológicas e fazendo um bom planejamento
da fase de teste. Os testes que utilizamos são:
• Teste de Aplicações Mainframe
• Teste de Aplicações Client
• Teste de Aplicações Server
• Teste de Aplicações Network
• Teste de Aplicações Web
Bem, após essa revisão inicial, vamos às questões!
Questões de Provas Comentadas
1. (Cesgranrio/2008/Petrobrás/Analista) O CMMI define níveis

crescentes de capacidade (capability) para as áreas de processos e de
maturidade (maturity) organizacional. Sobre os níveis de maturidade, é
correto afirmar que, no nível
a). 1, a disciplina de processo alcançada ajuda a garantir que as práticas

existentes serão mantidas, mesmo em situações de crise e stress.
b). 2, os projetos são monitorados, controlados, revisados e avaliados
quanto à sua aderência à descrição do processo que utilizaram.
c). 3, a performance dos processos é controlada usando estatística e outras
técnicas quantitativas, sendo portanto quantitativamente previsível.
d). 4, a organização está focada no aperfeiçoamento contínuo da
performance dos processos através de melhorias incrementais no processo
e na tecnologia.
e). 5, a organização atingiu o nível máximo de otimização dos processos e
passa a se concentrar nos aspectos operacionais e na manutenção das
métricas que atestam sua condição.
Comentários

Existem 5 níveis de maturidade, numerados de 1 a 5. Cada um é uma

camada que representa a base para as atividades de melhoria contínua de
processo:
1. Inicial.
2. Gerenciado.
3. Definido.
4. Gerenciado Quantitativamente.
5. Em Otimização ou Otimizado.
Vamos aos comentários de cada item:
Item A. No nível de maturidade 1 (Inicial), geralmente os processos são ad

hoc e caóticos. Não existem KPAs nesse nível, portanto não existem metas,
nem práticas genéricas ou específicas oriundas. Esse tipo de organização não
fornece um ambiente estável para apoiar os processos. O sucesso depende da
competência e do heroísmo das pessoas e não do uso dos processos
comprovados. Apesar deste caos, organizações no nível de maturidade 1
frequentemente produzem produtos e serviços que funcionam. Entretanto, com
frequência, eles extrapolam seus orçamentos e não cumprem seus prazos. As
organizações no nível de maturidade 1 são caracterizadas pela tendência de se
comprometer além da sua capacidade, por abandonar o processo em um
momento de crise, e por serem incapazes de repetir os próprios sucessos
(CMMI, 2006). Item ERRADO.
Item B. É no nível de maturidade 2 (Gerenciado) que os projetos

são monitorados, controlados, revisados e avaliados quanto à sua aderência. A
disciplina de processo refletida pelo nível de capacidade 2 contribui para
assegurar que as práticas existentes sejam mantidas durante períodos de
stress. Item CERTO.
Item C. É no nível de maturidade 4 (Gerenciado Quantitativamente) que

temos um processo definido, controlado por meio de técnicas estatísticas e
outras técnicas quantitativas. Nesse nível, objetivos quantitativos para
qualidade e para desempenho de processo são estabelecidos e utilizados como
critérios na gestão de processo. A qualidade e o desempenho de processo são
entendidos em termos estatísticos e gerenciados ao longo da vida do processo.
Item ERRADO.
Item D. O nível de maturidade 5 (Em Otimização ou Otimizado) é que

deveria ter sido especificado na alternativa D! Esse nível destaca que a

organização está focada na melhoria contínua do desempenho dos processos

tanto por meio de melhorias incrementais quanto de inovação. Item ERRADO.
Item E. Não há teto, ou nível máximo de otimização dos processos. Essa

otimização ou melhoria é contínua! Além disso, a organização passa a se
concentrar nos aspectos estratégicos, e não operacionais, e na manutenção
das métricas que atestam sua condição. Item ERRADO.
Gabarito: letra B.
2. (ESAF/2008/Controladoria-Geral da União/Analista de finanças e

Controle) O nível de maturidade é uma maneira de prever o futuro
desempenho de uma organização dentro de cada disciplina ou conjunto de
disciplinas. Um nível de maturidade é uma etapa evolucionária definida de
melhoria de processos. No modelo CMMI com representação em estágios
existem os seguintes níveis:
a) inicial, gerenciado, definido, gerenciado quantitativamente e otimizado.

b) inicial, parcialmente gerenciado, executado, gerenciado qualitativamente
e otimizado.
c) inicial, parcialmente gerenciado, definido, gerenciado quantitativamente e
otimizado.
d)parcialmente gerenciado, gerenciado, definido, gerenciado
quantitativamente e otimizado.
e)inicial, incompleto, executado, gerenciado, definido, gerenciado
Comentários
Para dar suporte àqueles que utilizam a abordagem por estágios, todos os
modelos CMMI trazem níveis de maturidade em seu desenho e conteúdo (vide
figura a seguir).

Um nível de maturidade pode ser considerado um degrau evolucionário para a

melhoria do processo organizacional como um todo e consiste em práticas
específicas e genéricas que integram um conjunto predefinido de áreas de
processo. O cumprimento das metas específicas e genéricas correspondentes a
estas áreas de processo é um pré-requisito para o alcance do nível de
maturidade correspondente (FERNANDES, 2008).
A seguir são descritas as principais características de cada nível de maturidade

e as áreas de processo pertencentes aos mesmos. Fonte: (Engenharia de
Software Magazine, Ed. 21) e CMMI (2006).
• Nível 1 – Inicial
É o nível de maturidade CMMI mais baixo. Em geral, as organizações
desse nível têm processos imprevisíveis que são pobremente controlados
e reativos. Nesse nível de maturidade os processos são normalmente “ad
hoc” e caóticos. A organização geralmente não fornece um ambiente
estável.
Áreas de Processo: Não há.
• Nível 2 – Gerenciado
Neste nível, o foco é o gerenciamento básico de projetos da organização,
proporcionando-lhes a garantia de que os requisitos são gerenciados,
planejados, executados, medidos e controlados. Quando essas práticas
são adequadas, os projetos são executados e controlados de acordo com
o planejado.
Áreas de Processo: Gestão de Requisitos (REQM), Planejamento do

Projeto (PP), Controle e Monitoração do Projeto (PMC), Gestão do Acordo
com o Fornecedor (SAM), Medição e Análise (MA), Garantia da Qualidade
de Processo e do Produto (PPQA) e Gestão da Configuração (CM).
• Nível 3 – Definido
Neste nível, processos são bem caracterizados, compreendidos e
descritos em padrões, procedimentos, ferramentas e métodos. O
conjunto de processos padrão da organização, que é a base para o nível
3 de maturidade, é estabelecido e melhorado ao longo do tempo. Esses
processos padronizados são usados para estabelecer consistência em
toda a organização. Todos os projetos utilizam uma versão de um desses
processos padrão adaptando-a às suas características específicas.

Áreas de Processo: Desenvolvimento de Requisitos (RD), Solução Técnica

(TS), Integração do Produto (PI), Verificação (VER), Validação (VAL),
Foco no Processo Organizacional (OPF), Definição do Processo
Organizacional (OPD), Treinamento Organizacional (OT), Gestão
Integrada do Projeto (IPM), Gestão de Riscos (RSKM), Análise de
Decisões e Resolução (DAR).
• Nível 4 – Gerenciado Quantitativamente

A gestão quantitativa baseada em medições e indicadores cobre, de
forma integrada, todo o conjunto de processos organizacionais, assim
como os projetos e respectivos produtos, como instrumento de suporte
para o atendimento dos objetivos de desempenho de processo e de
qualidade. Os projetos e seus produtos assim como o processo
organizacional, são controlados estatisticamente.
Áreas de Processo:
- Desempenho do Processo Organizacional (OPP) – tem como objetivos
estabelecer e manter uma visão quantitativa do desempenho dos
processos padrões, e prover modelos e baselines de desempenho,
visando melhorar a gestão dos projetos através de métricas de processo
e produto.
- Gestão Quantitativa do Projeto (QPM) – tem por objetivo gerenciar
quantitativamente (através de métricas) o processo definido do projeto,
visando o alcance dos objetivos preestabelecidos de desempenho de
qualidade e processo.
• Nível 5 – Em Otimização ou Otimizado

Neste nível, os processos são continuamente aperfeiçoados com base em
um entendimento quantitativo no qual a variação de um processo existe
devido às interações, normais e presumidas, entre seus componentes.
Esse nível de maturidade tem como objetivo a melhoria contínua do
processo.
Áreas de Processo:
- Inovação e Desenvolvimento Organizacional (OID) – tem por objetivo
selecionar e implantar melhorias incrementais e inovações nos processos
e nas tecnologias que promovam, quantitativamente, o aumento da
habilidade da organização para cumprir os seus objetivos de
desempenho de processos e qualidade.

- Análise e Resolução de Causas (CAR) – tem por objetivo identificar

causas de defeitos e outros problemas e tomar ações corretivas para
prevenir a sua ocorrência futura.
Gabarito: letra A.
3. (CESGRANRIO/Petrobrás/Analista de Sistemas Júnior/2010) Testar

é uma disciplina de suma importância para a engenharia de software. A
literatura divide os tipos de testes em duas grandes categorias: teste de
caixa preta e teste de caixa branca. Sobre esta classificação, pode-se
afirmar que
I - testes de interfaces são classificados como de caixa branca;
II - testes de caixa preta são também chamados de teste comportamental,
onde o foco são os requisitos funcionais do software;
III - testes de caixa preta são complementares aos testes de caixa branca,
uma vez que contemplam diferentes classes de erros.
É correto o que se afirma em

a) I, apenas.
b) I e II, apenas.
c) I e III, apenas.
d) II e III, apenas.
e) I, II e III.
Comentários
I – Os testes de interface são classificados de caixa preta, pois não avaliam a
estrutura interna do que foi implementado.
II – Está correto. Os testes caixa preta são chamados de comportamentais.
Além disso, focam na verificação se os requisitos foram atendidos.
III - Correto. Os testes de caixa preta abrangem classes diferentes dos de
caixa branca.
Portanto, estão certos apenas os itens II e III.
Gabarito: letra D.
4. (CESGRANRIO/BNDES - Profissional Básico - Especialidade - Análise

de Sistemas – Suporte/2008) No contexto de engenharia de software,
testes de software podem ser decompostos numa série de passos que
devem ser executados seqüencialmente. Considerando a arquitetura de
software convencional, o primeiro passo deve ser o teste de
a) estresse.
b) integração.

c) sistema.
d) unidade.
e) validação.
Comentários
Segundo Pressman uma estratégia de teste de software segue a sequência:
teste unitário, teste de integração, teste de validação e teste de sistema.
Gabarito: letra D.
5. (FCC/TRT - 15ª Região - Analista Judiciário - Tecnologia da

Informação/2009) Os testes de integração têm por objetivo verificar se
a) os módulos testados produzem os mesmos resultados que as unidades
testadas individualmente.
b) os módulos testados suportam grandes volumes de dados.
c) as funcionalidades dos módulos testados atendem aos requisitos.
d) os valores limites entre as unidades testadas individualmente são
aceitáveis.
e) o tempo de resposta dos módulos testados está adequado.
Comentários
Os testes de integração têm por objetivo verificar se as funcionalidades dos
módulos testados atendem aos requisitos.
Gabarito: letra C.
6. (ESAF/Prefeitura de Natal - RN - Auditor do Tesouro Municipal -

Tecnologia da Informação/2008) Com relação aos tipos de testes que
podem ser considerados e executados em um projeto de software, é correto
afirmar que o objetivo principal do Teste Funcional é assegurar que
a) a interface forneça ao usuário o acesso e a navegação adequados através
das funções do software.
b) os objetos contidos na interface funcionam conforme o esperado e
estejam em conformidade com padrões estabelecidos.
c) foram exercitados um conjunto de funcionalidades para avaliar a
navegação pelo software e a facilidade de uso do mesmo.
d) houve uma correta implementação dos requisitos do sistema, como, por
exemplo, regras de negócio, através da interface do usuário.
e) foram executadas transações, variando as cargas de trabalho, para
observar e registrar o comportamento do sistema.

Comentários
O teste caixa preta é também chamado de teste funcional e é baseado nos
requisitos funcionais do software.
Gabarito: letra D.
7. (Cesgranrio/2010/IBGE/Análise de Sistemas/Desenvolvimento de
Aplicações) O XP (Extreme Programming) usa uma abordagem orientada a
objetos como seu paradigma de desenvolvimento predileto. Nessa
perspectiva, analise as afirmativas abaixo.
I - A atividade de Codificação começa com a criação de um conjunto de

histórias que descreve as características e as funcionalidades requeridas
para o software a ser construído.
II - O XP encoraja o uso de cartões CRC (Class- Responsibility-Colaborator)
como um mecanismo efetivo para raciocinar sobre o software no contexto
orientado a objetos.
III - O XP emprega a técnica de refactoring na codificação, mas
desaconselha a utilização da programação por pares.
IV - A criação de testes unitários antes da codificação começar é uma
prática do XP.
V - Se um difícil problema de projeto é encontrado como parte do projeto
de uma história, o XP recomenda a criação imediata de um protótipo
operacional daquela parte do projeto.
Estão corretas APENAS as afirmativas

(A) I, II e IV.
(B) I, III e IV.
(C) I, IV e V.
(D) II, III e V.
(E) II, IV e V.
Comentários
Item I. Item FALSO. Segundo Beck e Fowler (2001), o XP procura assegurar
que o cliente tome todas as decisões de negócio, enquanto a equipe de
desenvolvimento cuida das questões técnicas. Teles (2004) destaca que todas
as funcionalidades do sistema são levantadas através de estórias, que são
registradas em pequenos cartões. Essas estórias devem ser escritas sempre
pelo próprio cliente, com suas próprias palavras. A equipe de desenvolvimento
utiliza os cartões para saber quais são as funcionalidades desejadas pelo

cliente, e, então, os desenvolvedores escolhem as estórias que irão

implementar em cada dia de trabalho.
Item II. Item VERDADEIRO. A Extreme Programming é orientada a

objetos, sendo muito usada com sucesso por grandes empresas do mercado de
software. Para implantar a XP é necessário que se norteie o trabalho baseado
em valores, podendo ser destacado o valor Coragem, em que é necessário
mudanças na maneira pela qual desenvolvem-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.
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. É por isto que as estórias do usuário, os cartões nos
quais os requisitos do sistema são passados pelo cliente, têm apenas tópicos
sobre o que deve ser feito, e não uma descrição detalhada das tarefas, algo
que será feito pelo cliente durante o andamento do projeto (SOMMERVILLE,
2007).
Cartões Classe-Responsabilidade-Colaboração (Class-Responsability-

Collaboration - CRC) é uma técnica de modelagem popular orientada a texto,
criada por Kent Beck e Ward Cunningham, inicialmente, para apoiar o ensino
da modelagem orientada a objetos. Entretanto se mostrou uma técnica
bastante útil para, de uma forma dinâmica e interativa, identificar as
abstrações chave do sistema, realizar a modelagem OO conceitual e mesmo a
modelagem de design OO. Podendo esta técnica ser empregada por qualquer
processo de desenvolvimento OO, a mesma vem sendo adotada principalmente
pelos processos ágeis, pela grande convergência existente entre suas
características (p. ex., interatividade).
Larman (2008) destaca que os Cartões CRC são cartões de indexação em
papel sobre os quais se escrevem as responsabilidades e os colaboradores de
classes. Cada cartão representa uma classe. Uma sessão de modelagem CRC
envolve um grupo sentado em volta de uma mesa, discutindo e escrevendo
nos cartões enquanto montam cenários (“o que acontece se”) com os objetos,
considerando o que eles precisam fazer e com que outros objetos eles
precisam colaborar.

Figura. Gabarito de um cartão CRC, fonte: Larman (2008)
Figura. Ilustra quatro exemplos de cartões CRC, Fonte: Larman (2008)
Item III. Item FALSO. O XP emprega a técnica de refactoring na codificação.

Refatoração é 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. 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 (SOMMERVILLE, 2007).
Item IV. Item VERDADEIRO. Segundo Teles (2004), teste é a parte do

desenvolvimento de software que todo mundo sabe que precisa ser feita, mas
ninguém quer fazer!! Para o XP, adotar o desenvolvimento guiado por testes é
seguir o caminho da PREVENÇÃO. Você incorpora alguns hábitos que irão
assegurar que o seu software tenha uma probabilidade menor de contrair uma
doença. A ideia da prevenção é diminuir as chances de que um problema
ocorra.

O XP trabalha com dois tipos de testes: testes de unidade e testes de

aceitação.
• Teste de unidade: realizado sobre cada classe do sistema para verificar
se os resultados gerados são corretos.
• Teste de aceitação: efetuados sobre cada funcionalidade, ou estória do
sistema. Verificam não apenas uma classe em particular, mas a
interação entre um conjunto de classes que implementam uma dada
funcionalidade.
Em ambos os casos, os testes devem ser gerados em primeiro lugar, isto é, no
caso dos testes de unidade, eles devem ser escritos ANTES das classes do
sistema; os testes de aceitação, por sua vez, devem ser criados antes das
estórias serem implementadas. Além disso, ambos os testes devem ser
automatizados, de modo que possam ser executados uma infinidade de vezes
ao longo do desenvolvimento.
Complementando, para um melhor entendimento da questão...

Para testar uma classe, é necessária a compreensão de quais são as suas
características (conhecer os parâmetros que seus métodos podem receber e os
que não podem; conhecer as respostas corretas, as incorretas e as que não
poderiam ocorrer em nenhuma circunstância). É preciso, portanto, conhecer
bem o problema e que tipo de solução é adequada para ele.
Quando o desenvolvedor pensa no teste ANTES DE PENSAR NA
IMPLEMENTAÇÃO, ele é forçado a compreender melhor o problema!!
Item V. Item VERDADEIRO. Um protótipo é uma versão inicial de um sistema

de software, utilizado para demonstrar conceitos, experimentar opções de
projeto e, geralmente, conhecer mais sobre o problema e suas possíveis
soluções. Desenvolvimento rápido e iterativo do protótipo é essencial, de modo
que os custos são controlados e os stakeholders do sistema podem
experimentar o protótipo mais cedo no processo de software (SOMMERVILLE,
2007).
Gabarito: letra E.
Vamos aos comentários adicionais, também importantes, sobre XP!!!

XP - Extreme Programming
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.
A eXtreme Programming faz parte 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 a 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.
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.
Há diversos relatos em que se afirma a obtenção de melhores resultados com
a utilização de métodos ágeis do que com os métodos tradicionais. No entanto,
por terem estes métodos, em sua maioria, uma publicação recente, é ainda
incipiente a pesquisa e a comprovação acadêmica sobre o assunto.

Surgimento
A eXtreme Programming foi criada por Kent Beck baseada em seus vários anos
de prática em desenvolvimento de softwares orientados a objetos, juntamente
com Ward Cunningham seu parceiro de programação, sendo muito usada com
sucesso por grandes empresas do mercado de software.
Ela baseia-se em permanente revisão do código, testes frequentes,
participação do usuário final, refinação contínua da arquitetura e
planejamento, design e redesign a qualquer hora.
A XP não é novidade, ela é baseada nas conclusões atingidas após mais de
uma década de pesquisas e aplicações de diversas práticas em projetos de
software; na verdade XP é uma recombinação das melhores práticas de
engenharia de software que comprovadamente contribuem para o sucesso dos
projetos.
O nome “eXtreme Programming” vem trazendo a idéia de maximizar as
práticas e técnicas de sucesso, como por exemplo:
• Se revisar o código é bom, revisaremos código o tempo inteiro
(programação em par, pair programming);
• Se testar é bom, todos vão testar o tempo inteiro (testes de unidade,
unit testing), até mesmo os clientes (testes funcionais, functional
testing);
• Se o projeto é bom, ele fará parte do dia-a-dia de todos (refinamento,
refactoring).
A eXtreme Programming trabalha com quatro valores básicos, sendo eles

Comunicação, Objetividade, Feedback e Coragem. Com a maior
comunicação e contatos frequentes com o cliente permite-se reduzir o risco de
não aderência do produto à necessidade final, o foco é realizar o serviço de
modo mais simples e eficaz possível, com o feedback constante do cliente os
erros são mais identificados mais cedo logo mais barato e rápido é o seu
conserto, mas tem que se ter bastante coragem para assumir uma postura
proativa frente ao desenvolvimento do sistema, assumindo a responsabilidade
pelo sucesso do projeto como um todo.
Podemos definir a XP com vários adjetivos porém ela é um processo de
desenvolvimento que possibilita a criação de software de alta qualidade, de
maneira ágil, econômica e flexível uma vez que prima pela satisfação do
cliente e pela qualidade do software final. Sendo uma metodologia voltada
para projetos cujos requisitos são vagos e mudam com frequência, onde se
utiliza orientação a objetos, com equipes pequenas, preferencialmente até 12
desenvolvedores e o desenvolvimento seja incremental (ou iterativo), isto é, o

sistema começa a ser implementado logo no início do projeto e vai ganhando

novas funcionalidades ao longo do tempo.
Em 1981, o Dr. Barry Boehm um dos profissionais mais influentes e mais
frequentemente citados na indústria de software, em seu livro clássico
Software Engineering Economics sugeriu que o custo de uma mudança em um
projeto cresce exponencialmente “à medida que se avança nas fases de
desenvolvimento. Um problema que pode custar R$ 1,00 durante a anáise de
requisitos pode custar R$100,00 quando o software estiver em produção”.
Atualmente a comunidade de desenvolvimento de software tem feito um
enorme esforço para diminuir o custo das mudanças, melhorando linguagens
de programação, melhorando banco de dados, utilizando melhores práticas de
programação e melhores ferramentas e ambientes.
Uma das premissas da XP, uma premissa técnica, é que o custo das mudanças
se mantenha linear ao longo de todo o projeto independente do ponto onde o
projeto esteja.
Em XP você deixará as grandes decisões para o final, desta maneira diminui a
chance de tomar uma decisão errada, pois quanto mais a equipe de
desenvolvimento e principalmente o cliente aprendem com o sistema, mais
condições eles têm de acertar na decisão. Você só implementará o que se tem
certeza que é necessário, e da forma mais simples possível.
Valores
Para implantar a XP é necessário que se norteie o trabalho baseado em quatro
valores:
o 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. Uma equipe deve ter meios de se comunicar de maneira
rápida e eficiente com o cliente, com o gerente do projeto e com os
outros desenvolvedores envolvidos.
o Simplicidade: a XP está fazendo uma aposta. Ela está apostando
que é melhor fazer algo simples e de desenvolvimento rápido hoje,
e ter de gastar um pouco mais no futuro se for necessário
remodelar um processo. 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.
o 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. Quanto mais cedo o cliente tiver

com o sistema em produção, mais rápido podem ser feitos os

ajustes para que o mesmo fique de acordo com o que o cliente
realmente quer. Geralmente o cliente tende a aprender mais sobre
o sistema desejado à medida que este utiliza-se de protótipos para
teste.
o 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
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)

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. É por isto que as estórias do usuário, os cartões nos
quais os requisitos do sistema são passados pelo cliente, têm apenas tópicos
sobre o que deve ser feito, e não uma descrição detalhada das tarefas, algo
que será feito pelo cliente durante o andamento do projeto.
Esta técnica encontra resistência no fato de que muitas vezes as empresas
acham que é muito caro afastar um membro de sua equipe de suas tarefas,
para que ele possa ficar acompanhando o desenvolvimento de um software.
Por isto é recomendável que seja provida para estes clientes estrutura para
que eles possam continuar fazendo algum trabalho enquanto acompanham a
equipe de desenvolvimento.
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
representar o cliente. Alguém que, preferencialmente, já tenha algum
conhecimento na área em que o software está sendo desenvolvido e que possa
centralizar a comunicação com o cliente real, absorvendo os questionamentos
dos desenvolvedores e repassando-os ao cliente real. Assim, esta pessoa vai

acabar conhecendo bem o processo como um todo e vai passar a poder

responder a maior parte das dúvidas dos desenvolvedores.
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.
O jogo do planejamento é o coração do desenvolvimento e acompanhamento
de projetos na XP. É nele que o software é efetivamente planejado pela equipe
de desenvolvimento e pela equipe do cliente. Nesta atividade, cada equipe tem
o seu papel bem claro e definido: a equipe do cliente é responsável por definir
escopo e prioridades; e a equipe de desenvolvimento por fornecer estimativas.
Estando os papéis das duas equipes bem claros, pode-se entender o que
efetivamente ocorre no jogo do planejamento. O cliente deve ter as estórias já
definidas, pois é sobre elas que está baseada esta atividade. A figura a seguir
mostra um exemplo de cartão de estórias do usuário, que é utilizado nesta
tarefa para que se faça o planejamento.
Como vemos na figura seguinte este é um cartão de estórias do usuário, nele o
usuário indica as funcionalidades que deseja do sistema. Com o cliente
escrevendo suas estórias fazemos com que ele pense melhor na funcionalidade
desejada. É recomendável que esta estória seja curta, pois será usada como
um lembrete e na hora de desenvolver será feito um detalhamento desta
funcionalidade através da comunicação com o cliente presente.
Baseados em sua experiência ou conhecimentos anteriores, os
desenvolvedores devem fornecer estimativas de desenvolvimento para cada
estória. Se uma estória for muito grande para entrar em uma iteração ou não
puder ser estimada adequadamente, significa que a mesma está muito
complexa e deve ser segmentada em estórias menores.

Por outro lado, se for muito pequena, deve ser agregada a outras para formar
uma estória de tamanho adequado. Normalmente, entende-se por adequadas
estórias que possam ser desenvolvidas em dois ou três dias ideais de
programação. A relação entre as funcionalidades entregues e as
funcionalidades solicitadas por um cliente para uma iteração é chamada de
velocity (velocidade) da equipe de desenvolvimento.
De posse dos cartões com as estórias do usuário e das estimativas da equipe
de desenvolvimento, os clientes devem definir o escopo da próxima iteração,
selecionando aquelas que desejam que sejam implementadas. Para tanto,
devem levar em consideração o princípio de que devem receber antes o que
vai gerar mais retorno para o negócio. Desta forma, busca-se que o retorno
sobre o investimento comece a vir já nos primeiros releases.
Este é um ponto importante: caso não seja possível cumprir tudo o que havia
sido planejado para a data de entrega de cada iteração, deve-se negociar com
o cliente quais estórias devem ficar para a próxima, e não atrasada a data de
entrega da iteração.
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)

Um release é um conjunto de funcionalidades implementadas que representam
um valor bem definido para o cliente e que é colocado em produção para que
todos os usuários possam se beneficiar dele. 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.
Também interessantes são as principais unidades de tempo utilizadas no

método XP:
• Liberação (release): o cliente escolhe o menor conjunto de estórias
possível o qual faz sentido estando juntas. Estas estórias são
implementadas em primeiro lugar, e colocadas em produção. As demais
estórias são implementadas posteriormente. Um conjunto de estórias é
selecionado para ser desenvolvido e forma uma liberação do sistema
para a produção, que poderá ser medida na escala de semanas ou
meses, de acordo com a próxima figura. Isto é feito através da
negociação entre os clientes e o time de desenvolvimento, levando-se
em consideração a prioridade de valor para o negócio – definida pelos
clientes – e o risco técnico – definido pelos desenvolvedores.
• Iteração: uma iteração inicia com um planejamento simples de quais
serão as estórias a serem implementadas e quais as tarefas que cada
programador deverá realizar. O objetivo da iteração é implementar
algumas poucas estórias em um espaço curto de tempo, e
disponibilizá-las em produção. Enquanto as funcionalidades estão sendo
implementadas pelo time de desenvolvimento, o cliente especifica um
conjunto de testes funcionais, os quais serão aplicados para verificar se o
objetivo da iteração, ao seu final, foi devidamente atingido. Durante a
iteração as estórias são divididas em tarefas. Uma tarefa é uma unidade
básica de trabalho no projeto, sendo que um programador deve poder
realizá-la em alguns poucos dias. Após a realização de cada tarefa, o par
de programadores integra o código com o repositório principal do projeto
e roda testes unitários para verificar se seu trabalho está completo e não
afetou outras porções da aplicação. Ao final da iteração, todos os testes
unitários e funcionais devem rodar com sucesso.
• Tarefa: as tarefas são implementadas por pares de programadores. Se
for necessário, uma pequena reunião de 15 minutos pode ser realizada
com o cliente para esclarecer detalhes da implementação, ou outros

programadores que conheçam o código que vai ser alterado, em maior

detalhe. Em seguida o par define quais serão os casos de teste
necessários para verificar que a tarefa esteja completa. A partir de
então, estes repetem um ciclo em que escolhem um caso de testes da
lista e implementam o código necessário para atendê-lo. Idealmente
todos os casos de teste são implementados sem problemas, mas pode
ser que o par de programadores detecte que precisa fazer um
refinamento no código para conseguir fazer com que o teste funcione.
Neste caso, o refinamento é feito de forma que todo o conjunto de teste
passe. Após todos os testes passarem, se houver ainda oportunidade
para refinamento, este é feito.
• Teste: a técnica de testes unitários é uma das mais importantes no
método XP. Os testes não somente fazem parte do dia-a-dia de cada
programador, como também estes são escritos ainda antes de o código
ser escrito. Segundo Beck, se programação é um eterno aprendizado,
então o melhor é que o aprendizado ocorra o mais cedo possível. Os
testes fazem com que os programadores recebam feedback sobre o
código que foi implementado por outros o mais rápido possível, e muitos
destes aprendem a partir disto.
A principal diferença entre as liberações e as iterações é que as liberações são
ditadas pelo ritmo do negócio, enquanto que as iterações são ditadas pelo
ritmo do desenvolvimento. A figura a seguir apresenta o relacionamento entre
os conceitos.
Para definir uma liberação, é necessário que haja negociação entre os clientes
e os programadores. Os clientes escolhem as estórias que são mais
importantes de serem implementadas e que façam sentido estarem juntas. A
quantidade de estórias que poderá ser implementada durante uma liberação
deve ser definida considerando-se o histórico de velocidade do time de
desenvolvimento. Cada estória deve ser estimada da melhor forma possível,
conforme descrito anteriormente, utilizando comparações com estórias
semelhantes implementadas no passado, sempre que possível.
• Desenvolvimento Guiado pelos testes (Test First Design)

Testar é uma parte muito importante em um projeto de software, porém a
maioria dos programadores acha esta atividade muito chata e que gasta muito
tempo, geralmente os testes são deixados para o final do projeto, só que, a
maioria dos projetos atrasam ficando o tempo destinado a testes prejudicado.
Normalmente os testes só são valorizados quando o software entra em
produção e apresentam muitos erros, estes que poderiam ser sanados com
testes. Para fazer com que os testes não sejam a parte “chata” do
desenvolvimento é necessário que estes não tomem muito tempo, sejam
simples de serem executados e principalmente façam parte natural do ato de
programar.
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. É muito difícil saber previamente que métodos possam vir a
falhar, a fim de que não se esqueça de ter um teste automatizado para
métodos que sejam importantes e também não se perca tempo escrevendo
testes para rotinas que não tem como conter erro, por serem extremamente
simples. Apenas com a experiência se vai conseguindo distinguir o que deve
ter um teste automatizado.
O XP trabalha com dois tipos de testes: os testes de unidade e os testes de
aceitação.
O teste de unidade é aquele realizado sobre cada classe do sistema
para verificar se os resultados gerados são corretos.
Já os testes de aceitação são efetuados sobre cada funcionalidade,
ou estória do sistema. Eles verificam não apenas uma classe em
particular, mas a iteração entre um conjunto de classes que
implementam uma dada funcionalidade.
• 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)

A técnica de manter o projeto simples (Simple Design) é uma grande quebra
de paradigma para quem está acostumado a trabalhar em desenvolvimento de
sistemas e é muitas vezes difícil de se acostumar a projetar apenas “a coisa
mais simples que possa funcionar”.
Como dito anteriormente uma das premissas técnicas do XP é de que o custo
de uma alteração cresce lentamente ao longo do projeto, por isso você pode
deixar as grandes decisões para o futuro, ou seja, deixe os problemas do
futuro para o futuro. A equipe deve implementar apenas os problemas de hoje,
e fazendo isso da maneira mais simples possível. Dessa forma, evitamos o
trabalho especulativo que ocorre quando não se tem certeza sobre uma
determinada funcionalidade e mesmo assim ela é implementada, geralmente
esta é implementada de forma errônea, fazendo com que se tenha um alto
grau de retrabalho ou over-engineering causando desperdício de tempo e
dinheiro do cliente.
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. Em nosso
entendimento atual de desenvolvimento de software nós acreditamos que
projetamos e então codificamos. Um bom projeto vem primeiramente, e a

codificação vem posteriormente. A todo o tempo o código será modificado, e a

integridade do sistema, sua estrutura de acordo com esse projeto,
gradualmente diminui.
Refinamento do projeto é o contrário desta prática. Com o refinamento
pode-se pegar um projeto ruim, mesmo que esteja um caos, e retrabalhar ele
para que se torne um código bem-projetado e robusto. Cada passo é simples,
pode-se mover um campo de uma classe para outra, retirar algum código para
fora de um método, deslocar algum código para cima ou para baixo em uma
hierarquia ou até mesmo renomear métodos e classes. Mas o efeito cumulativo
destas pequenas mudanças pode radicalmente melhorar o projeto. É o
contrário exato da noção normal de deterioração de software.
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.
• 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.
Esta visão de “propriedade” de código é muito perigosa, pois cria “ilhas de
conhecimento” dentro de um projeto. Uma “ilha de conhecimento” pode ser
compreendida como sendo uma pessoa que possui um domínio sobre uma área
do projeto.

• Padrões de Codificação (Coding Standards)

Como vimos anteriormente a comunicação é um valor fundamental do XP, e
tem que ser não apenas verbal, mas também através do código produzido.
Para que um código fale por si só ele deve ser simples, legível e principalmente
deve seguir um padrão.
O 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.
Relacionamento entre Práticas

Através da próxima figura podemos ver o relacionamento entre as práticas do
XP.

Relacionando as práticas com valores da XP podemos “casá-las” da seguinte

forma:
1.Com o cliente sempre presente reforçamos a necessidade de comunicação

entre as partes, ajudando assim a fazer a coisa mais simples possível e isto
pode ser feito por causa do feedback constante que o cliente proporciona.
Lembrando que para manter o cliente presente é necessária muita coragem
uma vez que serão visualizadas pelo cliente todas as dificuldades que a equipe
enfrentará.
2.A comunicação é sempre exaltada pela XP, inclusive e principalmente no

jogo do planejamento onde são definidos os escopos das iterações. Nesta
definição entra a simplicidade para garantir que a equipe trabalhe sempre
naquilo que ira gerar maior valor para o cliente. Com este planejamento pode-
se obter um rápido feedback para o cliente, que terá suas prioridades
atendidas mais rapidamente.
3. Utilizando-se de pequenos lançamentos o feedback tanto do cliente para a

equipe de desenvolvimento como da equipe para o cliente é extremamente
rápido o que ajuda a sempre trabalhar de forma mais simples possível.
4. Para se utilizar do desenvolvimento guiado pelos testes é necessária

coragem, pois muda a cultura do programador que está acostumado a testar
somente no término do software isso quando testa. Escrevendo os testes
primeiro ajuda a se tornar o código mais claro e simples, além de passar a

idéia do código mais facilmente.
5. A integração contínua estimula a simplicidade, uma vez que expõe o estado

atual do desenvolvimento e oferece feedback sobre todo o sistema. Além de
necessária coragem para estar sempre integrando, pois integrando sempre há
o medo de entrar com bugs no sistema.
6. Antes de tudo para se refinar um código é preciso ter muita coragem,

porque você estará modificando um código que já funciona, arriscando a
“estragar” o software. Alterando o código ele se torna muito mais simples,
passando a sua idéia mais claramente.
7. Programando em duplas a comunicação fica muito mais evidente entre os

pares, cada integrante da dupla vai fornecer feedback para o outro o tempo
todo, ajudando na simplicidade do código.
8. Como o código é coletivo todos irão visitar alguma parte do código algum
dia o que força o desenvolvedor a escrever o código da maneira mais simples
possível para que outra pessoa possa entender. Outro ponto a ponderar é que
o código coletivo demanda coragem, pois o desenvolvedor terá que mexer em
partes do código que não foram construídas por ele.
9.Com a utilização de padrões de codificação fica muito mais fácil a

comunicação, pois todo o código escrito será simples o suficiente e entendido
por todos.
10. É necessário coragem para se manter um ritmo sustentável, indicadas 40h

semanais, uma vez que a maioria dos projetos de software passam por
dificuldades de cumprimento de cronograma e possuem gerentes de projetos
com mentalidade industrialistas expondo seus funcionários a excessivas cargas
de trabalho.
11. É possível começar o desenvolvimento com apenas metáforas apenas se o

feedback for concreto e rápido. O uso de metáforas ajuda a comunicação entre
os desenvolvedores e facilita a disseminação do conhecimento entre a equipe,
ajudando a tornar o design simples.
8. (Cesgranrio/BNDES/Desenvolvimento/2008) Que situação favorece a

escolha do uso de XP para um projeto de desenvolvimento de software, em
oposição à escolha do RUP ou do modelo Cascata?

(A) Equipe do projeto localizada em diferentes cidades e com poucos

recursos de colaboração.
(B) Equipe do projeto formada por pessoas com alto grau de

competitividade.
(C) Cliente do projeto trabalhando em parceria com a equipe do projeto e

sempre disponível para retirar dúvidas.
(D) Requisitos do software com pequena probabilidade de mudanças.
(E) Presença de um processo organizacional que exige a elaboração de

vários documentos específicos para cada projeto.
Comentários
cliente. Com o cliente sempre presente reforçamos a necessidade de
comunicação entre as partes.
Gabarito: letra C.
9. (CESPE/2010/BANCO DA AMAZÔNIA/Técnico Científico — Área:

Tecnologia da Informação — Arquitetura de Tecnologia) O Scrum é
utilizado, como função primária, para o gerenciamento de projetos de
desenvolvimento de software, mas também tem sido usado como extreme
programming e outras metodologias de desenvolvimento. Teoricamente, o
Scrum pode ser aplicado em qualquer contexto no qual um grupo de
pessoas necessite trabalhar juntas para atingir um objetivo comum.
Comentários
Define-se Scrum como uma metodologia para desenvolvimento ágil e
Gerenciamento de Projetos. Esta metodologia foi concebida como uma
forma de gerência de projetos em empresas automobilísticas e de produtos de
consumo, a partir da observação de que projetos usando equipes pequenas e
multidisciplinares produziram os melhores resultados, e associaram estas
equipes altamente eficazes à formação Scrum do Rugby.
De acordo com o artigo apresentado no site http://improveit.com.br/scrum, na

metodologia Scrum, os projetos são divididos em ciclos (tipicamente mensais)
chamados de Sprints. O Sprint representa um intervalo de tempo no qual uma
série de atividades deve ser executada. Como toda metodologia ágil de
desenvolvimento de software, ele é iterativo, e cada iteração, é chamada de
Sprint.
A utilização do Scrum ocorre da seguinte forma:

• As funcionalidades de um projeto são mantidas em uma lista chamada

Product Backlog;
• Ao iniciar-se um Sprint, faz-se uma reunião de planejamento (Sprint
Planning Meeting) na qual o Product Owner prioriza as funcionalidades do
Product Backlog e a equipe seleciona as atividades que ela será capaz de
implementar;
• As tarefas do respectivo Sprint são transferidas do Product Backlog para
o Sprint Backlog.
• Diariamente, a equipe faz uma breve reunião (Daily Scrum), em geral
pela manhã, visando disseminar conhecimento sobre o trabalho realizado
no dia anterior, identificar impedimentos e priorizar o trabalho do dia; e
• No término de um Sprint, a equipe apresenta as funcionalidades
implementadas em uma Sprint Review Meeting. Após isso, faz-se uma
Sprint Retrospective e a equipe parte para o planejamento do próximo
Sprint.
• Reinicia-se assim o ciclo.
Gabarito: item correto.
Mais sobre Scrum

O Scrum é um framework de processo ágil utilizado para gerenciar e controlar
o desenvolvimento de um produto de software através de práticas iterativas e
incrementais. É composto por um conjunto de boas práticas de gestão que
admite ajustes rápidos, acompanhamento e visibilidade constantes e planos
realísticos.
• Scrum é um processo bastante leve para gerenciar e controlar

projetos de desenvolvimento de software e para a criação de
produtos.
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.
Inicialmente um requisito deve fazer parte do Product Backlog (Produto

Backlog), que possui descrições de necessidades de clientes de alto nível
levantadas.
• A tarefa de manter a descrição e refinamento destes requisitos é do
Product Owner. Ele é responsável por definir, para cada nova release
de um produto, o objetivo (Release Goal ou Vision). Ele interage a
todo momento com seu cliente final e, dessa forma, conhece suas
expectativas e as do mercado.
Esta lista de demandas nunca acaba e de tempos em tempos (a cada nova

release), um item de Product backlog é promovido a Release backlog para
integrar ao escopo de uma ou mais Releases. O Product Owner deve comunicar
e discutir o novo goal com todos os envolvidos em reuniões chamadas de
Release Planning.

Figura – Estrutura do scrum
Portanto, a primeira reunião oficial de Release que ocorre é a Release Planning.

Nesta reunião, são discutidos os recursos envolvidos – tanto computacionais
quanto humanos, riscos identificados, prazo acertado e requisitos previstos
acordados junto ao cliente e coerentes com a demanda de mercado. Seu
propósito principal é definir e comunicar as funcionalidades macro de uma
Release do produto e fazer com que os envolvidos no projeto entendam e se
comprometam com o Release Goal definido. As funcionalidades não devem ser
discutidas em detalhes.
Isso será feito em cada Iteração durante reuniões de Sprint Planning

(Planejamento da Sprint). Ela pode ter a presença de diversos papéis: seja
cliente externo, desenvolvedor, área comercial, etc. Cada release é
composta de iterações curtas, chamadas de Sprints.
Conforme dito, a primeira reunião é a Release Planning. Cada Sprint tem

reuniões de planejamento, Sprint Planning, que detalham o requisito
apresentado durante o Release Planning e ainda possuem seu Sprint Goal.
Semelhante ao goal do Release, tem o mesmo cunho de comunicar a todos os

envolvidos o objetivo maior de Sprint corrente. É realizado de forma iterativa,
através de ciclos de “tempo fechado” (Time-Boxed) em 30 dias corridos. Ainda
sobre a reunião, são conhecidos os requisitos do Release Backlog que serão

promovidos como Selected Backlog. Eles são discutidos em maiores detalhes e

servem para elucidar O QUE se espera como resultado final.
Em um Sprint, portanto, são executadas atividades de refinamento de

requisitos, análise, projeto, desenvolvimento e testes pelo Scrum Team,
devendo resultar em um incremento de produtos funcionando e demonstrável
para o Product Owner ao final do Sprint, na reunião de Sprint Review.
O Scrum Master tem o papel de liderança muito importante para o processo.

Ele deve remover todo e qualquer obstáculo que surgir durante o
desenvolvimento, garantindo que o Scrum Team possa focar no real objetivo
definido. Além disso, ele é responsável por fazer com que a equipe siga e
pratique o processo e ainda por criar uma atmosfera de ajuda mútua entre a
equipe (o resultado é sempre da equipe e não individual).
O Scrum Team é responsável por se organizar e determinar a melhor

estratégia de se entregar as funcionalidades de maior prioridade. Interessante
observar que iterações curtas garantem ritmo à equipe e facilita o
entendimento do processo, além de proporcionar visibilidade ao cliente sobre o
andamento do projeto.
Diariamente são executadas reuniões de acompanhamento e monitoramente

do Sprint através da reunião de Daily Scrum. Esta reunião deve ter a
presença do Scrum Team e Scrum Master obrigatoriamente.
Deve ter a duração máxima de 15 minutos (é interessante até utilizar

um cronômetro para isso) e são permitidas somente 3 perguntas:
- O que você fez hoje?

- O que fará amanhã?
- Que impedimentos surgiram e que atrapalharam sua produtividade?
Outros assuntos deverão ser discutidos em outras reuniões, como Follow-Up

Meetings para detalhamentos e elucidações relativas aos requisitos e
Reestimate Meetings para aplicação de técnicas como o Poker Planning para
estimativa de requisitos.
Há uma reunião de Sprint Planning 2 que promove o desdobramento do

Selected Backlog em Sprint Backlog onde aspectos técnicos são discutidos. É a
hora do COMO as coisas devem ser feitas. Neste momento, pode-se discutir

sobre a arquitetura do produto, reuso de componentes, mudança em

interfaces, etc.
Ao final do Sprint, é feita uma reunião final de apresentação do trabalho

executado ao Product Owner chamada Sprint Review. Ele será responsável
por validar a apresentação e concluir se o Sprint Goal foi atingido. Após esta,
reuniões de debrief são executadas, chamadas Retrospective Meetings.
Reuniões de retrospectiva levam a reflexão acerca do que passou e quais

atitudes devem ser tomadas para o correto atingimento dos objetivos. São
levantados aspectos positivos (WWW – what went well) e negativos (WCBI -
what can be improved) tanto organizacionais quanto relativos a Release.
Todos os envolvidos devem estar presentes e são responsáveis por minimizar
todo e qualquer risco ao projeto e também por manter os aspectos positivos
levantados.
E o mesmo se repete por todos os Sprints planejados, com a diferença de que
o último Sprint possui uma reunião de Release Review, que tem como guia o
Release Goal definido. Nunca é demais lembrar que o planejamento é feito
durante toda a Release e, portanto, alterações podem ser feitas. Se constitui
em uma boa prática poder refazer o planejamento durante cada Sprint
Planning, mas durante o Sprint, o Scrum Master deve procurar “blindar” o
Scrum Team de grandes modificações.
As estimativas de tamanho de cada funcionalidade/requisito são executadas
obrigatoriamente pelo Scrum Team. Dessa forma, todos sabem para onde ir
(goal) e é desta forma que se obtém o comprometimento da equipe para com
o projeto.
A viabilidade de continuidade dos planos é constantemente verificada. A
comunicação de um projeto que utiliza o Scrum é mais efetiva e direta, além
de informações estarem sempre à tona com a utilização de quadros brancos
(Agile Radiator). A figura seguinte exemplifica um Agile Radiator
monitorando um projeto real. Eles garantem visibilidade do projeto a todos os
envolvidos.

Figura. Agile Radiator
Não há como mascarar o real andamento. O goal fica afixado e os requisitos –

através de Post-its - (Selected backlogs) e seus desdobramentos (Sprint
backlogs) são posicionados na situação onde se encontram (se ainda não
iniciados - planejados, se sendo executados no momento - em andamento e se
terminados – 100% concluídos). Eles devem ser posicionados de acordo com a
prioridade dos mesmos – Business Value declarado pelo Product Owner.
Post-its localizados no topo nos dizem ser de maior prioridade que os

posicionados no rodapé do quadro branco. Impedimentos (Impediment
Backlog) que ocorrem durante o Sprint também são evidenciados.
O Scrum tem um gráfico, de nome BurnDown Chart, que é a principal

ferramenta de gerenciamento do processo de desenvolvimento de software.
Ele representa o trabalho restante sobre tempo, ou seja, permite visualizar o
progresso e/ou a evolução do trabalho executado pela equipe e a quantidade
trabalho x tempo que ainda faltam para completar a Sprint. A atualização do
Burndown deve ser diária, isto facilita a tomada de decisão, pois, poderemos
decidir em melhorar a produtividade da equipe e/ou para mitigar risco da
Sprint.
Figura. BurnDown Chart
O Scrum Team diariamente, através de reuniões chamadas Daily Scrum,

atualiza o Agile Radiator com a situação atual, movendo post-its e indicando o
trabalho executado durante o período.
Vale destacar que a granularidade de cada Sprint Backlog deve ser pequena.
Sua estimativa não deve ultrapassar 8 horas de trabalho e isso se constitui em

uma boa prática no gerenciamento do andamento das atividades. Através

desta reunião, o time consegue avaliar se é necessário mudar o plano para
acertar o rumo, se deve priorizar alguma outra atividade, se muitos
impedimentos estão ocorrendo e como minimizá-los, se há algum recurso que
está necessitando de ajuda, etc. É real! Isso tudo sempre à luz do goal
definido. Além de todas estas vantagens, ainda proporciona visibilidade a todos
os envolvidos.
Durante cada reunião de Daily Scrum, post-its são “movimentados”pelo Scrum

Team contemplando cada uma das perguntas associadas a esta reunião.
Atividades executadas (o que foi feito hoje) são movidas para a seção
“Concluídos”. Atividades planejadas (o que será feito amanhã) são colocadas
na seção “Em Andamento” e impedimentos são registrados (que impedimentos
surgiram? Repare a seção em vermelho no rodapé a direita).
Além destes artefatos, o Burndown Chart deve ser atualizado ao final da

reunião contabilizando o tamanho total entregue pelo Scrum Team no dia a ser
representado. O Burndown possui duas retas: uma que exibe o planejado e
outra que reflete o realizado. Ele está registrado no topo à esquerda. Ele
contém o total de trabalho restante e só de “batermos o olho” no gráfico
conseguimos verificar a evolução do trabalho. Todo o Agile Radiator tem esta
característica. Se estivermos vendo muitos impedimentos, temos que verificar
o que está sendo feito para prevenir novos e se estes estão sendo
corretamente removidos. Se atividades de maior prioridade estão sendo
deixadas para trás, a própria equipe pode verificar o que está havendo. O que
foi bom (WWW) e o que pode ser melhorado (WCBI) também ficam afixados
no quadro branco.

A cada novo Sprint, o Agile Radiator deve ser modificado para retratar a
situação atual novamente. E este ciclo se inicia: planejamento, execução,
controle e avaliação do que foi feito para cada nova Release necessária.
É necessária muita disciplina para seguir esta abordagem. Seus princípios e

valores são baseados em dedicação e bom senso de todos os envolvidos.
Suas práticas pregam inspeções constantes - para o feedback rápido – e
aceitação das mudanças e adaptações que o processo deva passar. O
comprometimento entre todos os envolvidos também se constitui como um
grande diferencial do framework. O processo de gestão está permeado entre
os diversos papéis existentes como falado anteriormente.
10. (Cesgranrio/IBGE/Análise de Sistemas/Desenvolvimento de

Aplicações/2010) A figura abaixo apresenta alguns dos principais
artefatos do RUP (Rational Unified Process) e o fluxo de informações
existentes entre eles.
Qual é o nome do artefato identificado, na figura, pela palavra ARTEFATO e por

um círculo?
(A) Projeto do Sistema
(B) Lista de Riscos
(C) Especificação Suplementar
(D) Plano de Teste
(E) Modelo de Casos de Uso
Comentários
Artefatos são produtos de trabalho tangíveis e bem definidos consumidos,
produzidos ou modificados por tarefas. Artefatos podem ser compostos por
outros artefatos. São exemplos de artefatos: um modelo, como o Modelo de

Casos de Uso ou o Modelo de Design.
O Caso de Negócio fornece as informações necessárias do ponto de vista de
um negócio, para determinar se vale ou não a pena investir no projeto.
O Plano de Desenvolvimento de Software é um artefato composto e
abrangente que reúne todas as informações necessárias ao gerenciamento do
projeto. Ele inclui vários artefatos separados, desenvolvidos durante a Fase de
Iniciação, e é mantido durante todo o projeto.
O Documento de Arquitetura de Software fornece uma visão geral de
arquitetura abrangente do sistema, usando diversas visões de arquitetura para
descrever diferentes aspectos do sistema.
Então podemos concluir que o artefato que fica entre o fluxo de informações
dos artefatos indicados é o Lista de Riscos, que oferece uma lista de riscos
conhecidos e perigosos para o projeto, classificada em ordem decrescente de
importância e associada a ações específicas de contingência ou diminuição de
riscos (IBM RUP, 2010).
Fonte: (Victorino, 2009)

Gabarito: letra B.

11. (Cesgranrio/Casa da Moeda do Brasil/Analista de Nível Superior

/Desenvolvimento de Sistemas/2009) A fase do RUP, em que são
implementados os cenários críticos dos casos de uso arquiteturalmente
significativos, se chama
a) Concepção
b) Elaboração
c) Mitigação
d) Construção
e) Transição
Comentários
Observe bem essa questão, pois você pode confundi-la na hora da resposta. A
pergunta menciona a fase do RUP em que são implementados os cenários
críticos dos casos de uso, e não onde são identificados. Caso fosse a
identificação, a resposta seria na fase de Concepção. Porém a questão destaca
que é durante a sua implementação, esta é realizada na fase de Elaboração.
Ao analisar a figura que destaca as fases e disciplinas do RUP, observe que na
fase de Elaboração já temos o INÍCIO da implementação e testes dos cenários
críticos (Esse detalhe pode ser visualizado no fluxo de trabalho/disciplina
Implementação).
Resumindo, na fase de elaboração já temos parte da implementação dos
casos de uso mais críticos, conforme visto na figura. Veja no texto da aula que
um dos resultados da fase de elaboração é um protótipo arquitetônico
executável, e não a implementação por completo!!
Gabarito: letra B.
12. (Cesgranrio/Petrobrás/Processo de Negócios/2010) Existem

vários Modelos de Ciclo de Vida do Processo de Software. O
desenvolvimento em espiral é um modelo
(A) iterativo.
(B) para modificar requisitos.
(C) para analisar componentes.
(D) para analisar interface gráfica.
(E) para modularizar o sistema.
Comentários
Um modelo de ciclo de vida do software deve conter a descrição precisa
dos produtos de software gerados e dos critérios de término para cada fase,
pois sem os mesmos o modelo em questão é considerado de pouca utilidade
prática.
A escolha de um modelo de processo de software deve considerar as
características do sistema, os métodos e as ferramentas a serem utilizados, os

prazos e custos e ainda, os produtos de software a serem entregues. Alguns

exemplos de modelos de ciclo de vida: Modelo em Cascata, Modelo
Incremental, Modelo Espiral, etc.
O Modelo Espiral foi proposto por Boehm, em 1988, como forma de
integrar os diversos modelos existentes, eliminando suas dificuldades
e explorando seus pontos fortes. Combina a natureza iterativa da
prototipagem com os aspectos controlados e sistemáticos do modelo cascata.
Iterações sucessivas constroem um conjunto de artefatos a partir do
estado em que estes foram deixados ao término da iteração passada.
Um projeto que usa o desenvolvimento iterativo tem um ciclo de vida que

consiste em várias iterações. Uma iteração incorpora um conjunto quase
seqüencial de atividades em modelagem de negócios, requisitos, análise e
projeto, implementação, teste e implantação, em várias proporções,
dependendo do local em que ela está localizada no ciclo de desenvolvimento.
No modelo Espiral, assume-se que o processo de desenvolvimento ocorre

em ciclos, cada um contendo fases de avaliação e planejamento onde 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 próxima figura apresenta o
esquema deste modelo.
Planejamento
Análise de
Risco
Comunicação com o
cliente
Engenharia
Implantação Construção e Entrega
Apesar deste 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.
Gabarito: letra A.
13. (Cesgranrio/Petrobrás/Engenharia de Software/2008) Um

princípio fundamental do Processo Unificado é
(A) ser centrado em arquitetura.
(B) empregar times auto-dirigidos e auto-organizados.
(C) o desenvolvimento em cascata.
(D) a programação em pares.
(E) a propriedade coletiva do código fonte.
Comentários
Importante O Processo Unificado possui características específicas, como
ser orientado a casos de uso, ser centrado na arquitetura, ser iterativo e
incremental. Quanto ao princípio “ser centrado em arquitetura” cabe
destacar:
• A arquitetura é a visão de todos os modelos que juntos representam o
sistema como um todo.
• O conceito de arquitetura de software engloba os aspectos estáticos e
dinâmicos mais significantes do sistema. A arquitetura cresce além das
necessidades do empreendimento, como percebido pelos usuários e
suporte, e refletido nos casos de uso.
• “Significante” em um sistema depende do ponto de vista de cada
desenvolvedor
• A arquitetura também é influenciada por muitos outros fatores, como a
plataforma na qual o software será implantado, os blocos de construção
reutilizáveis, requisitos de desenvolvimento e requisitos não funcionais.
• A arquitetura é a visão do projeto do sistema como um todo, destacando
suas características mais importantes, mas sem entrar em detalhes.
• O processo ajuda o arquiteto a concentrar-se nas metas corretas, como
inteligibilidade, poder de recuperação para mudanças futuras e
reutilização.
• A relação existente entre casos de uso e a arquitetura é que os casos de
uso estão ligados à funcionalidade de um sistema e a arquitetura, por
sua vez está ligada à forma deste.
• Funcionalidade e forma devem estar balanceadas para se alcançar um
produto final de qualidade, ou seja, casos de uso e arquitetura devem
estar ligados a tal ponto que o primeiro seja desenvolvido de acordo com
a arquitetura, e esta por sua vez, forneça um ambiente para a realização

de todos os requisitos dos casos de uso.
• A arquitetura de um sistema deve ser projetada a ponto de permitir que
o sistema evolua, não apenas durante o início de seu desenvolvimento,
mas através de gerações futuras.
• Para alcançar este objetivo, os arquitetos devem trabalhar com as
funções chaves de um sistema, ou seja, os casos de uso chaves de um
sistema.
Gabarito: letra A.
14. (Cesgranrio/Petrobras/Engenharia de Software/2006) Sobre a

Análise Estruturada são feitas as afirmativas a seguir.
I – Uma condição necessária para que um DFD esteja em equilíbrio com um
DER é que cada depósito do DFD deve corresponder a um tipo de objeto ou
a um relacionamento ou à combinação de um tipo de objeto e de um
relacionamento do DER.
II – A especificação de processos de um DFD pode ser feita através de
tabelas de decisão, linguagem estruturada, condições pré-pós, fluxogramas
e diagramas de Nassi-Shneiderman.
III – O DTE representa o comportamento de um sistema, descrevendo seus
estados e os eventos que fazem com que o sistema mude de estado,
devendo apresentar um único estado inicial e um único estado final.
Está(ão) correta(s) a(s) afirmativa(s):
(A) I, apenas.
(B) II, apenas.
(C) III, apenas.
(D) I e II, apenas.
(E) I, II e III.
Comentários
Item I. Item correto. O DFD é uma representação em rede dos processos
(funções) do sistema e dos dados que ligam esses processos. Ele mostra “o
que” o sistema faz e não “como” é feito. É a ferramenta central da análise
estruturada, descrevendo o modelo funcional. Na elaboração de um DFD
utilizaremos quatro símbolos que nos permitirão debater e apresentar ao
usuário todo o processo, sem assumir nenhum compromisso com
implementações e sem a preocupação com a hierarquização e tomadas de
decisão. Cada um desses símbolos tem um nome e possivelmente um rótulo
associado:

Figura. Símbolos do DFD
• O processo mostra uma parte do sistema que realiza um

processamento. Os sinônimos mais conhecidos são bolha e função.
• Podemos associar cada fluxo de dados com um “tubo” por onde passam
pacotes de dados. O fluxo é utilizado para mostrar o movimento de
informações de um ponto a outro do sistema.
• O depósito é usado para modelar uma coleção de dados em repouso.
Normalmente o nome escolhido para identificar o depósito é colocado no
plural.
• Identificamos como entidade, na maioria das vezes, categorias lógicas
de coisas ou pessoas que representam uma origem ou destino de
transações (Clientes, Fornecedores, Empregados, etc.). Também
podemos identificar como Entidades fontes ou destinos específicos tais
como Departamentos da empresa, Receita Federal, Almoxarifado. É
comum adotarmos a terminologia Entidade Externa, já que estão sendo
representados objetos que estão fora do controle do sistema que está
sendo modelado. Quando um sistema recebe dados resultantes de outro
sistema, ou gera informações que servirão como dados de entrada para
outro sistema, esse outro sistema também é identificado como uma
Entidade Externa.
Quanto ao equilíbrio entre DFD e DER, cabe destacar que todos os depósitos
de dados que aparecem no DFD devem corresponder a um tipo de objeto ou a
um relacionamento ou à combinação de um tipo de objeto e de um
Item II.Item correto. As principais técnicas de especificação de processos de

um DFD são: tabelas de decisão, linguagem estruturada, condições pré-pós,
fluxogramas e diagramas de Nassi-Shneiderman.

Figura. Exemplo de especificação em linguagem estruturada
Figura. Tabela de decisão
Figura. Árvore de decisão
Item III. Item errado. O DTE (Diagrama de Transição de Estados)

representa o comportamento de um sistema, descrevendo seus
devendo apresentar um único estado inicial e 0 ou vários estados finais!!!
Gabarito: letra D.
15. (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.
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.

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

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.
16. (Cesgranrio/BR Distribuidora/Infraestrutura/2008) Considere a

seqüência de atividades e eventos apresentada a seguir.
• Projeto de concepção de um novo software de prateleira
• Projeto de desenvolvimento do novo software
• Projeto de marketing de lançamento do software
• Distribuição do software por dois anos
• Projeto de alteração das funcionalidades do software
• Projeto de marketing do software ampliado para atingir novos segmentos
de mercado
Esta seqüência de atividades é conhecida como
(A) ciclo de vida do produto.
(B) ciclo de vida de projetos.
(C) ciclo de projetos.
(D) projetos de ciclo de vida.
(E) projetos de produtos.
Comentários
A sequência de atividades e eventos apresentada está relacionada ao ciclo de
vida do PRODUTO. No ciclo de vida do projeto seriam mencionadas atividades
do PMBOK, a abordagem XP utiliza Scrum para gerenciamento, etc.
Gabarito: letra A.
17. (Cesgranrio/BR Distribuidora/Desenvolvimento/2008) Uma

diferença entre o modelo incremental e o modelo evolucionário por
prototipagem é que somente o modelo incremental
(A) é iterativo.
(B) é recomendado quando os requisitos dos sistemas estão totalmente
definidos a priori.
(C) pode gerar um incremento com objetivo de minimizar o risco de
operação do sistema final.
(D) objetiva entregar um sistema que seja operacional em cada incremento.
(E) projeta testes antes da implementação do sistema.
Comentários
Vamos às considerações da questão:
Item a. Não temos uma diferença nesse quesito, os 2 modelos apresentados
são iterativos.
Item B. Nenhum dos 2 modelos apresentados partem do princípio de que
precisamos conhecer todos os requisitos a priori.
Item C. Não temos uma diferença nesse quesito, ambos fazem isso!
Item D. A banca considerou essa assertiva como a correta. No entanto, a
questão dá margens a recursos!! A entrega não será de um sistema em cada
incremento, entregará um conjunto de funcionalidades (uma parte do
software) em cada incremento.
Item E. Nenhum dos 2 modelos apresentados irão projetar os testes antes da
implementação do sistema.

Gabarito: letra D.
Algumas observações complementares:

Modelo Incremental
Este modelo foi proposto como uma alternativa ao modelo em cascata,
aplicando-o iterativamente, visando à 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
implementada e ainda assim fornecer alguma funcionalidade útil para os
usuários. A próxima figura apresenta o esquema deste modelo.
F Incremento n
u
Comunicação
n Planejamento
c Modelagem
i Construção
o Implantação
n
a
Incremento 2
Comunicação
...
Planejamento
l
Modelagem
i Incremento 1 Construção
d Comunicação Implantação
a Planejamento
d Modelagem
Construção
e Implantação
Tempo Decorrido
Em cada iteração do ciclo acrescentam-se novas funcionalidades ao software.
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. No entanto, algumas críticas podem ser
feitas:
• sem uma estrutura de gerenciamento e controle eficaz, o modelo pode
deteriorar-se; e
• a premissa de que o sistema em desenvolvimento será flexível bastante
para acomodar todas as evoluções, pode não ser realista em muitas
circunstâncias.
Prototipagem
O paradigma de prototipagem começa com a definição dos requisitos. Um
projeto rápido é realizado e concentra-se na representação daqueles aspectos
que ficarão visíveis pelo cliente. O protótipo é criado e avaliado e é ajustado

para satisfazer as necessidades do cliente.
Idealmente, o protótipo serve como um mecanismo para identificação dos
requisitos do software. A prototipagem pode ser problemática, pois o cliente vê
o que parece ser uma versão executável do software, ignorando que o
protótipo apenas consegue funcionar precariamente.
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 de a 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.
Comunicação
Implantação e Feedback Plano Rápido
Construção do Protótipo Modelagem
Benefícios
• Equívocos entre os usuários de software e desenvolvedores são
expostos.
• Serviços esquecidos podem ser detectados e serviços confusos podem
ser identificados.
• Um sistema funcionando está disponível nos primeiros estágios no
processo de desenvolvimento.
• O protótipo pode servir como uma base para derivar uma especificação
do sistema com qualidade de produção.
• O protótipo pode ser usado para treinamento do usuário e teste de
sistema
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.
O paradigma de prototipagem começa com a definição dos requisitos. Um

projeto rápido é realizado e concentra-se na representação daqueles aspectos
que ficarão visíveis pelo cliente. O protótipo é criado e avaliado e é ajustado
para satisfazer as necessidades do cliente.
Idealmente, o protótipo serve como um mecanismo para identificação dos
requisitos do software. A prototipagem pode ser problemática, pois o cliente vê
o que parece ser uma versão executável do software, ignorando que o
protótipo apenas consegue funcionar precariamente.
Processo de desenvolvimento de protótipo
Prototipação no processo de software
Prototipação Evolucionária
Uma abordagem para o desenvolvimento do sistema em que um protótipo
inicial é produzido e refinado através de vários estágios até atingir o sistema
final.
Na Prototipação Evolucionária, o protótipo evolui até se transformar no
próprio produto entregue ao cliente, enquanto na Prototipação Descartável
o protótipo é utilizado para esclarecer requisitos e avaliar riscos, sendo
descartado ao final do processo.
O objetivo da prototipação evolucionária é fornecer aos usuários finais um
sistema funcionando. O desenvolvimento começa com aqueles requisitos que
são melhores compreendidos.

Prototipação Descartável
Um protótipo o qual é usualmente uma implementação prática do sistema é
produzida para ajudar a levantar os problemas com os requisitos e depois
descartado. O sistema é então desenvolvido usando algum outro processo de
desenvolvimento.
O objetivo da prototipação descartável é validar ou derivar os requisitos do
sistema. O processo de prototipação começa com aqueles requisitos que não
são bem compreendidos.
Pontos-chave
• Um protótipo de sistema pode ser usado para dar aos usuários finais uma
impressão concreta das capacidades desse sistema.
• A prototipação está se tornando cada vez mais comum para o
desenvolvimento de sistema onde o desenvolvimento rápido é essencial.
• Protótipos descartáveis são usados para a compreensão dos requisitos do
sistema.
• Na prototipação evolucionária, o sistema é desenvolvido pela evolução de
uma versão inicial em uma versão final do sistema.
• O desenvolvimento rápido é importante na prototipação de sistemas. Isso
pode levar à exclusão de algumas funcionalidades do sistema ou na
diminuição dos requisitos não funcionais.
• Entre as técnicas de prototipação estão o uso de linguagens de nível muito
elevado, a programação de bando de dados e a construção de protótipos a
partir de componentes reutilizáveis.
• A prototipação é essencial para o desenvolvimento de interfaces com o
usuário, as quais são difíceis de serem especificadas usando um modelo
estático. Os usuários deveriam estar envolvidos na avaliação e na evolução
do protótipo.
18. (Cesgranrio/Eletrobrás/Engenharia de Software/2010) O termo

Modelo de Ciclo de Vida é utilizado para descrever um grupo de atividades e
a forma como elas se relacionam. Considerando o Modelo de Ciclo de Vida

de Sistemas por Prototipagem Evolucionária, afirma-se que
(A) os clientes não têm acesso a uma visualização dos progressos do
desenvolvimento.
(B) é possível determinar com exatidão o tempo que o projeto irá demorar.
(C) não deve ser utilizado quando os requisitos mudam rapidamente e o
cliente está relutante em aceitar um conjunto de requisitos.
(D) não há uma forma de saber de antemão o número de iterações que
serão necessárias.
(E) apenas a fase final gera um produto que não é um documento.
Comentários
Item a. Item errado. Criarei um protótipo para entender melhor o problema,
assim os clientes teriam acesso a uma visualização dos progressos do
desenvolvimento.
Item b. Item errado. Nesse caso, ainda não conhecemos o problema direito.
Item c. Item errado. Posso ter requisitos variáveis, e, nesse caso, a todo
momento o protótipo vai variando.
Item d. Item correto. Esse número de iterações pode variar de acordo com o
sistema a ser desenvolvido.
Item e. Item errado. Posso gerar protótipos a qualquer momento.

Gabarito: letra D.
19. (Cesgranrio/BR Distribuidora/Desenvolvimento/2008) Considere

os seguintes elementos:
I - baseados em cenários – como diagramas de casos de uso e de
atividades;
II - orientados a fluxos – como diagramas de fluxo de dados e de controle;
III - baseados em classes – como diagramas de classes e de colaboração;
IV - baseados em comportamentos – como diagramas de estado e de
seqüência.
São elementos do modelo de análise de desenvolvimento de um sistema:

(A) II e III, somente.
(B) I, II e III, somente.
(C) I, III e IV, somente.
(D) II, III e IV, somente.
(E) I, II, III e IV.
Comentários
Cabe destacar que a banca misturou elementos da análise estruturada com a
análise orientada a objetos, mas todas as respostas estão corretas já que são

elementos do modelo de análise e que podem fazer parte da análise de

desenvolvimento de um sistema.
Gabarito: letra E.
20. (Cesgranrio/Funasa/2009) À luz da Engenharia de Software, o ciclo

de vida clássico, também chamado de modelo sequencial linear ou modelo
em cascata, é um paradigma aplicável ao desenvolvimento de sistemas de
informações que
(A) enfatiza a análise de riscos, que é feita no início do projeto e revisada a

cada fase, incluindo um plano de ataque e ações de mitigação dos riscos,
aumentando as chances de sucesso do projeto.
(B) prevê uma sequência (ou cascata) de entregas de versões do sistema
ao longo do desenvolvimento do mesmo, o que proporciona uma avaliação
de progresso baseada em código funcionando, em vez de quantidade de
documentação gerada.
(C) exige que todos os requisitos sejam conhecidos e corretamente
especificados no início do ciclo de vida, dificultando a acomodação de
mudanças que surjam nas fases posteriores.
(D) foi sempre pouco utilizado na prática, pois se apoia em analogias com
práticas de engenharia convencional que não se aplicam bem ao
desenvolvimento de sistemas de informação.
(E) utiliza a estratégia dividir para conquistar (divide to conquer), prevendo
que cada fase do ciclo de vida seja desdobrada em um miniciclo de vida
sequencial completo, formando uma cascata de ciclos de vida até o limite
adequado para lidar com a complexidade do sistema.
Comentários
O modelo em Cascata (Waterfall), também chamado de Clássico, é o mais
tradicional processo de desenvolvimento de software. Este modelo sugere uma
abordagem seqüencial para o desenvolvimento de software, aplicando as
atividades de maneira linear. Esse modelo 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 seqüencial.
• dificuldade do cliente em declarar todas as suas necessidades no início do
projeto, dificultando a implementação de mudanças que surjam nas fases
posteriores;
• demora em apresentar resultados ao cliente.
Gabarito: letra C.
21. (Cesgranrio/MD/2009) A fase que deve acontecer primeiro no

desenvolvimento de sistemas de uma empresa que utiliza o modelo de ciclo
de vida em cascata é a de
(A) testes.
(B) análise e projeto.
(C) especificação de requisitos.

(D) implantação.
(E) implementação.
Comentários
Em cada fase do modelo de ciclo de vida em cascata desenvolvem-se artefatos
(produtos de software) que servem de base para as fases seguintes.
A figura seguinte, proposta por Eduardo Bezerra, mostra o modelo do ciclo
de vida clássico da engenharia de software, que é dividido em seis
atividades. São elas:
A figura a seguir apresenta outra possibilidade de esquema deste modelo,

apresentada pelo Pressman.
Com unicação
Planejam ento
Modelagem
Construção
Im plantação
Em seguida, a proposta de Kruchten (2003).

Dentre as fases apresentadas na questão, conforme visto na explicação acima,

é a especificação de requisitos que deve acontecer primeiro no
desenvolvimento de sistemas de uma empresa que utiliza o modelo de ciclo de
vida em cascata.
Gabarito: letra C.
22. (Cesgranrio/Petrobrás/Processo de Negócio/2010) No Ciclo de

Vida Clássico, também chamado de Modelo Sequencial Linear ou Modelo
Cascata, é apresentada uma abordagem sistemática composta pelas
seguintes atividades:
(A) Análise de Requisitos de Software, Projeto, Geração de Código, Teste e

Manutenção.
(B) Modelagem e Engenharia do Sistema/Informação, Análise de Requisitos de
Software, Projeto, Geração de Código, Teste e Manutenção.
(C) Modelagem e Engenharia do Sistema/Informação, Projeto, Geração de
Código, Teste e Manutenção.
(D) Levantamento de Requisitos de Software, Projeto, Geração de Código e
Manutenção e Análise de Requisitos de Software.
(E) Levantamento de Requisitos de Software, Projeto, Geração de Código,
Teste Progressivo e Manutenção.
Comentários
Dentre as assertivas, a B é a que destaca as principais atividades do modelo
em Cascata. Uma especificação das fases desse modelo pode ser vista na
questão anterior.
Gabarito: letra B.
23. (Cesgranrio/Petrobrás/Engenharia de Software/2010) O modelo

de ciclo de vida em cascata
(A) enfatiza a realização sequencial das atividades do desenvolvimento de

um produto de software.

(B) enfatiza a comunicação estreita com o cliente durante o

desenvolvimento do produto de software.
(C) envolve a ideia principal de criar um protótipo executável e, por meio de
transformações sucessivas, chegar ao sistema completamente
implementado.
(D) envolve a análise dos riscos envolvidos no desenvolvimento dos
requisitos identificados para produto de software.
(E) recomenda a geração de versões incompletas do sistema, que podem
ser passadas para o usuário final, o que permite a retroalimentação do
Comentários
O modelo de ciclo de vida em cascata enfatiza a progressão seqüencial entre
uma fase e a seguinte.
Gabarito: letra A.
24. (Cesgranrio/BNDES/Desenvolvimento/2009) No ciclo de vida em

cascata, o custo de correção é menor na fase de
(A) testes.
(B) transição.
(C) implementação.
(D) requisitos.
(E) manutenção.
Comentários
Se eu detectar um erro no início do projeto, ou seja, na fase de requisitos,
melhor. Quanto mais tarde eu detectar um problema, pior será.
Gabarito: letra D.
25. (Cesgranrio/Petrobrás/Processos de Negócios/2008) Analise as

afirmativas a seguir, sobre requisitos em projetos de software.
I - O rastreamento de requisitos é de grande importância para conduzir
análises de impacto quando há mudanças em requisitos.
II - O acrônimo FURPS+ se refere aos requisitos não funcionais das
categorias de Feasibility, Usability, Reliability, Performance e Supportability.
III - Um requisito pode conter, além da especificação, atributos que sirvam
ao seu gerenciamento.
IV - Casos de uso são descrições da interação entre um ator e o sistema e,
portanto, especificam apenas requisitos funcionais.
(A) I e II.
(B) I e III.
(C) II e III.
(D) II e IV.
(E) III e IV.

Comentários
Item I. Item correto. A rastreabilidade de requisitos é essencial para que o
controle de mudanças possa avaliar o impacto de uma solicitação de mudança.
Importante
Define-se rastreabilidade dentro de um ambiente de desenvolvimento como
a capacidade de relacionar um elemento a outros correlatos, especialmente
àqueles relacionados a requisitos. Os elementos do projeto envolvidos em
rastreabilidade são chamados de itens de rastreabilidade. Os itens típicos
de rastreabilidade incluem diferentes tipos de requisitos, elementos de modelo
de projeto e de análise, artefatos de testes, entre outros. Para que o controle
de mudanças avalie o impacto de uma solicitação é necessário identificar,
portanto, seus itens de rastreabilidade.
Item II. Item errado. O acrônimo FURPS+ é um sistema para a classificação

de requisitos. Representa categorias que podem ser usadas na definição de
requisitos, assim como representa atributos de Qualidade de Software, sendo
ele parte do Rational Unified Process (RUP):
• Functionality (Funcionalidade): representa todo aspecto funcional do

software, ou seja, seus requisitos. É uma categoria com diversas
subcategorias que variam de acordo com a aplicação. Sua medição
considera, principalmente, o cumprimento dos requesitos especificados.
• Usability (Usabilidade): é o atributo que avalia a interface com o usuário.
Possui diversas subcategorias, entre elas: prevenção de erros; estética e
design; ajudas (Help) e documentação; consistência e padrões.
• Reliability (Confiabilidade): refere-se à integridade, conformidade e
interoperabilidade do software. Os requisitos a serem considerados são:
freqüência e gravidade de falha; possibilidade de recuperação;
possibilidade de previsão; exatidão; tempo médio entre falhas (MTBF).
• Performance (Desempenho): avalia os requisitos de desempenho do
software. Podendo usar como medida diversos aspectos, entre eles:
tempo de resposta, consumo de memória, utilização da CPU, capacidade
de carga e disponibilidade da aplicação.
• Supportability (Suportabilidade): os requisitos de suportabilidade
agrupam várias características, como: testabilidade, adaptabilidade,
manutenibilidade, compatibilidade, configurabilidade, instalabilidade,
escalabilidade, localizabilidade entre outros.

O + engloba também outros requisitos não-funcionais que devem ser

lembrados:
• Requisitos de design (desenho): freqüentemente chamado de uma

restrição de design, especifica ou restringe o design de um sistema.
Exemplos: linguagens de programação, processo de software, uso de
ferramentas de desenvolvimento, biblioteca de classes, etc.
• Requisitos de implementação: especificam ou restringem o código ou
a construção de um sistema. Exemplos: padrões obrigatórios; linguagens
de implementação; políticas de integridade de banco de dados; limites
de recursos; ambientes operacionais.
• Requisitos de interface: especifica ou restringe as funcionalidades
inerentes à interface do sistema com usuário.
• Requisitos físicos: especifica uma limitação física pelo hardware
utilizado, por exemplo: material, forma, tamanho ou peso. Podendo
representar requisitos de hardware, como as configurações físicas de
rede obrigatórias.
Fonte: http://qualidadebr.wordpress.com/2008/07/10/furps/.
Figura. FURPS+ (Fonte:

http://www.ibm.com/developerworks/rational/library/content/04March/3073/3
073_fig3.jpg)
Item III. Item correto. Na fase de gestão de requisitos é feita a administração

dos requisitos, bem como o acompanhamento dos mesmos quanto a
alterações, com as tabelas de rastreamento. Nesse contexto, um requisito
pode conter, além da especificação, atributos que sirvam ao seu
gerenciamento.
Item IV. Item errado. Um caso de uso pode especificar requisitos não-
funcionais. Exemplo de requisito: ao clicar em um botão, o sistema deverá
responder em menos de um segundo, mostrando a resposta em uma página
diferente e de forma gráfica.
Gabarito: letra B.

Análise e o Gerenciamento de Requisitos, é FALSO afirmar que:
(A) quanto mais tarde for identificado um problema na análise de requisitos,
maior será o custo com o retrabalho.
(B) a elicitação é o processo de identificação e entendimento das
necessidades e restrições dos usuários, enquanto que a especificação é o
processo de formalização das necessidades e restrições dos usuários em
requisitos funcionais de software.
(C) na análise de requisitos o cliente utiliza as melhores práticas de
engenharia de requisitos na tarefa de descrever suas necessidades.
(D) o gerenciamento de requisitos corresponde ao conjunto de atividades
que auxilia a equipe do projeto a identificar, controlar e rastrear os
requisitos, bem como a fazer as alterações nos requisitos durante o projeto.
(E) o gerenciamento de requisitos implica a alteração, inclusão e/ou
exclusão de requisitos ao produto de software, o que pode levar a
alterações de prazos, de recursos humanos, de equipamentos e de
tecnologia.
Comentários
Dentre as assertivas apresentadas, a única falsa é a letra C, já que é o analista
que irá utilizar as melhores práticas de engenharia de requisitos na tarefa de
descrever as necessidades do cliente.
Algumas observações:
Engenharia de Requisitos
É o uso sistemático de princípios, técnicas, linguagens e ferramentas
comprovadas para análise, documentação, evolução continuada das
necessidades dos usuários e especificação do comportamento externo de um
sistema para satisfazer as necessidades do usuário, que sejam efetivas em
termos de custos. Visa, principalmente, o entendimento escrito do problema.
Algumas considerações importantes:

• é uma abordagem sistemática, ou seja, constituída por um conjunto

de processos estruturados para extrair, validar e manter os requisitos
de um sistema;
• composta principalmente por atividades de Análise (identificar) e
Documentação (validar); e
• constitui a ponte entre a comunicação com o cliente, a documentação
gerada, o projeto e o desenvolvimento.
A Engenharia de Requisitos é composta pelos seguintes passos:

• Concepção;
• Levantamento (Especificação);
• Elaboração;
• Negociação;
• Especificação;
• Validação;
• Gestão de Requisitos.
Concepção
O primeiro passo da Engenharia de requisitos é a Concepção, onde é realizada
a definição do escopo e a natureza do problema, a análise da sua viabilidade, o
reconhecimento dos interessados (stakeholders).
Observação: Stakeholders são as pessoas que têm interesse direto no sistema
a ser desenvolvido ou que se beneficie dele. Deve-se observar que para cada
classe de interessados, podem ser definidos diferentes pontos de vista,
gerando requisitos conflitantes.
Na literatura, é sugerido que, nesta fase, os engenheiros de software adotem a
estratégia do P&R (pergunta e resposta), empregando questões de livre
contexto. As perguntas não são fixas, podendo surgir novas perguntas durante
a realização das entrevistas. As perguntas são elaboradas e respondidas a
partir das seguintes fontes de informação:
• Interessados (stakeholders), como clientes, usuários e desenvolvedores;
• Documentos;
• Livros;
• Sistemas de Software;
• Livros relacionados à aplicação em discussão; e
• Documentos mais referenciados pelos atores.
Levantamento de Requisitos
Neste passo busca-se descobrir, tornar explícito (elicitar), obter o máximo de
informações para o conhecimento do software em questão. Para tanto, é
necessário:

• Identificar as fontes de informação;

• Coletar os fatos;
• Comunicação.
Pretende-se, portanto, conhecer o domínio de aplicação do software,

identificando e coletando os requisitos (funcionais e não-funcionais) de forma
organizada. Este passo deve ser realizado em conjunto com todos os
envolvidos, inclusive e de forma especial, os interessados.
Alguns problemas são comuns durante a execução destas atividades:
• Problemas de entendimento
o Interessados não compreendem o domínio
o Interessados omitem informações
o Interessados possuem visões conflitantes
o Interessados definem requisitos ambíguos
o Interessados definem requisitos impossíveis de serem
tratados (economicamente ou tecnologicamente)
• Problema de escopo
• Problemas de volatilidade
Em um levantamento de requisitos, geralmente um engenheiro de software se
depara com duas importantes questões:
• Entre os muitos relatórios, formulários e documentos gerados pelos
membros de uma organização, quais deverão ser objeto de
investigação?
• Pode haver um grande número de pessoas afetadas pelo sistema de
informação proposto. Quais delas devem ser entrevistadas,
observadas ou questionadas?
Elaboração do Documento de Requisitos

O documento de requisitos do sistema deve ser composto por sentenças em
linguagem natural, seguindo determinados padrões, como o padrão IEEE-830,
que contém os seguintes itens:
1. Introdução
1.1. Propósito
1.2. Escopo
1.3. Definições
1.4. Referências
1.5. Visão Geral
2. Descrição Geral
2.1 Perspectivas do Produto
2.2. Funções do Produto
2.3. Características do Usuário

2.4. Restrições
2.5. Dependências
3. Requisitos Específicos
3.1. Requisitos Funcionais
3.2. Requisitos Não-Funcionais
Deve-se ressaltar que nem todos os itens serão sempre necessários. Com
relação aos requisitos funcionais, algumas regras devem ser observadas:
Iniciar os requisitos com “O sistema deverá...”
Os requisitos devem estar organizados logicamente. Por exemplo, inicialmente
todos os requisitos de entrada depois os de processamento e por último os
requisitos de saída.
Cada requisito deve ter um identificador único, por exemplo, um número, para
posterior referência, e deve conter sempre uma única ação.
Gabarito: letra C.
27. (Cesgranrio/Petrobrás/Engenharia de Software/2006) Analise as

afirmativas abaixo a respeito de técnicas de levantamento de requisitos:
I - Uma entrevista não estruturada deve “fluir” entre o entrevistado e o
entrevistador e, para isso, as questões a serem feitas não se devem ser
definidas previamente.
II - A Implantação da Função de Qualidade (IFQ) é uma técnica que traduz
as necessidades do cliente para requisitos técnicos de software,
identificando três tipos de requisitos: normais, esperados e excitantes.
III - Amostragem é o processo de seleção sistemática de elementos
representativos de uma população, que permite revelar informações úteis
acerca da população como um todo.
IV - Uma técnica importante no levantamento de requisitos é observar o
comportamento e o ambiente do indivíduo tomador de decisões, já que
muitas informações passam desapercebidas com a utilização de outras
técnicas.
Estão corretas apenas as afirmativas:
(A) I e II.
(B) III e IV.
(C) I, II e III.
(D) I, II e IV.
(E) II, III e IV.
Comentários
Dentre as assertivas, a incorreta é a letra I. Uma entrevista não estruturada
deve “fluir” entre o entrevistado e o entrevistador e, para isso, questões a
serem feitas podem ser definidas previamente.

Cabe um complemento nesta questão quanto às técnicas para Levantamento

de Requisitos.
Servindo de base para todas as técnicas de levantamento de requisitos,
entre elas investigação, entrevistas e observação, estão as decisões cruciais
dizendo respeito ao que examinar e a quem questionar ou observar. Estas
decisões podem ser apoiadas por uma abordagem estruturada chamada
amostragem.
A amostragem é o processo de seleção sistemática de elementos

representativos de uma população. Quando os elementos selecionados em
uma amostragem são analisados, pode-se assumir que esta análise revelará
informações úteis acerca da população como um todo.
Por que usar amostragem?

• diminuir custos;
• acelerar o processo de levantamento de informações;
• eficiência: a informação tende a ser mais apurada, já que menos
elementos podem ser analisados, mas estes podem ser analisados
com mais detalhes;
• reduzir tendências.
A investigação de documentos é uma técnica que auxilia no levantamento

de requisitos, pois nos documentos podem-se identificar os temos comuns do
sistema que se pretende desenvolver e as informações necessárias para a
empresa.
A técnica de estudos etnográficos é proveniente das disciplinas de

Antropologia, que consiste no estudo de um objeto por vivência direta da
realidade onde este se insere. Permitindo analisar a componente social das
tarefas desempenhadas numa dada organização tornam-se, no âmbito da
Engenharia de Requisitos, extremamente úteis para ultrapassar a dificuldade
que existe na recolha dos requisitos derivados de formas rotineiras e tácitas de
trabalhar.
O objetivo deste estudo é identificar o modo como realmente as pessoas
executam as suas funções que muitas vezes difere da forma como as
definições dos processos sugerem que elas devem fazer; como ocorre a
cooperação e conhecimento das atividades entre as pessoas.
Esta técnica se refere a uma análise da componente social das tarefas
desempenhadas numa dada organização. Quando um dado conjunto de tarefas
se torna rotineiro para uma pessoa, é de esperar que esta sinta dificuldade em
articular todos os passos que segue ou todas as pessoas com as quais
interage. Através de uma observação direta das atividades realizadas durante

um período de trabalho de um funcionário é possível encontrar requisitos que
não seriam observáveis usando técnicas convencionais. Esta observação pode
ser acompanhada de registros áudio/vídeo, porém não convém usá-los em
demasia visto que o tempo necessário para os processar pode ser demasiado.
Nesta técnica assume-se que o interessado observado desempenha as suas
funções "corretamente“. Portanto, é necessário ter cuidado na escolha do(s)
interessado(s) a observar.
Outra alternativa para levantamento de requisitos é a utilização de Cenários.

Esta técnica pode ser definida como uma forma de levar as pessoas a imaginar
o comportamento de um sistema. Através de exemplos práticos descritivos do
comportamento de um sistema, os seus usuários podem comentar acerca do
seu comportamento e da interação que esperam ter com ele. Trata-se de uma
abordagem informal, prática e aplicável a qualquer tipo de sistema. De um
modo geral, os cenários devem incluir os seguintes elementos:
• Estado do sistema no início do cenário;
• Sequência de eventos esperada (na ausência de erros) no cenário;
• Listagem de erros que podem ocorrer no decorrer dos eventos do
cenário e de como estes erros serão tratados;
• Outras atividades que podem ser executadas ao mesmo tempo que as
deste cenário;
• Estado do sistema depois de o cenário terminar.
Pode-se, também, aplicar entrevistas com representantes dos usuários do
sistema. Nestas entrevistas, em geral, são aplicados os seguintes tipos de
questões:
• Questões subjetivas: permitem respostas “abertas”
o O que você acha de ...?
o Explique como você ...?
• Questões objetivas: limitam as respostas possíveis

o Ex: Quantos ...? Quem ...?
o Quanto tempo ...? Qual das seguintes informações ...?
Estas entrevistas podem ser estruturadas de diferentes formas:
• Estrutura de Pirâmide - inicia com questões bastante detalhadas,
geralmente objetivas, e, à medida que a entrevista progride, questões
mais gerais, subjetivas, são colocadas;
• Estrutura de Funil - inicia com questões gerais subjetivas e, à medida
que a entrevista avança, perguntas mais específicas, usando questões
objetivas, são feitas;

• Estrutura de Diamante - combinação das duas estruturas anteriores,

começa com questões objetivas (específicas), passa para questões
gerais e fecha com questões específicas; e
• Não estruturada.
Quanto à questão, como os itens II, III e IV são verdadeiros, a resposta é a

letra E.
Gabarito: letra E.
28. (Cesgranrio/Petrobrás/Engenharia de Software/2008) Estudos

baseados na análise de diversos projetos de desenvolvimento de software
sugerem que tais projetos têm maior chance de sucesso quando empregam
metodologia e gerenciamento alinhados ao paradigma de desenvolvimento
de novos produtos, em contraponto ao paradigma de produção industrial.
Com base nessas observações, a maioria das metodologias modernas de
desenvolvimento de software recomenda:
(A) concluir o trabalho de especificações dos requisitos do sistema, antes de

iniciar as atividades de projeto e implementação.
(B) planejar detalhadamente no início do projeto todas as fases e atividades
do mesmo, de forma que seja possível estimar com precisão o esforço
necessário e os prazos de cada atividade.
(C) providenciar, desde o início do projeto, mecanismos para prevenir e
bloquear solicitações de mudanças de forma a garantir que será entregue
exatamente o que foi especificado.
(D) dividir o trabalho em iterações curtas, com prazos fixos, e não permitir
que as mesmas avancem sobre os prazos, reduzindo o escopo da iteração,
se necessário.
(E) não produzir documentação técnica para o sistema, tendo em vista que
a mesma já nasce condenada a ficar desatualizada, investindo melhor o
tempo em atividades de implementação e testes exaustivos.
Comentários
Item a. Item errado. Abordagem antiga, que apresenta inconvenientes, usada
no modelo em Cascata.
Item b. Item errado. Realizar essa estimativa com precisão logo no início é
bastante difícil.
Item c. Item errado. Não se tem essa exigência de providenciar, desde o início
do projeto, mecanismos para prevenir e bloquear solicitações de mudanças.
Isso contradiz com metodologias de desenvolvimento modernas.
Item d. Item correto. A maioria das metodologias modernas de
desenvolvimento de software recomenda a divisão do trabalho em iterações
curtas, com prazos fixos, e não permitir que as mesmas avancem sobre os
prazos, reduzindo o escopo da iteração, em caso de necessidade.
Item e. Item errado Recomenda-se documentar pelo menos o essencial!
Gabarito: letra D.

29. (Cesgranrio/IBGE/Desenvolvimento/2009) Os processos de

desenvolvimento de software utilizam, muitas vezes, procedimentos
estatísticos para, por exemplo, apoiar a tomada de decisão. Dentro desse
contexto, o Diagrama de Pareto é baseado na clássica regra de que
(A) 20% das ocorrências causam 80% dos problemas.
(B) 60% das amostras de um processo normal encontram-se nos limites do
desvio padrão.
(C) pontos fora dos limites de um desvio padrão revelam a ocorrência de
problemas aleatórios.
(D) três pontos consecutivos abaixo da média indicam um processo em
melhoria contínua.
(E) um índice de erro acima dos cinco sigmas indica um processo que
alcançou a qualidade.
Comentários
Importante A Lei de Pareto (também conhecido como princípio 80-20),
afirma que para muitos fenômenos, 80% das consequências advém de 20%
das causas.
Na questão, tem-se a Lei do Pareto na letra A, que destaca que 20% das
ocorrências causam 80% dos problemas.
Uma outra adaptação do princípio de Pareto: 80% de uma aplicação pode ser
entregue em 20% do tempo total do projeto.
Gabarito: letra A.

gerente de projeto decidiu utilizar o Processo Unificado (RUP – rational
unified process) como seu processo de desenvolvimento de software. Com
base no RUP, quais os objetivos que o gerente deve direcionar para a fase
de Elaboração?
(A) Produzir Documento Visão completo e estável; detalhar os atores e
casos de uso chave; determinar pelo menos uma solução possível para o
problema.
(B) Produzir Documento Visão completo e estável; fazer o design dos casos
de uso críticos; obter um entendimento mais detalhado dos requerimentos.
(C) Fazer o design dos casos de uso críticos; obter um entendimento mais
detalhado dos requerimentos; implementar e testar cenários críticos.
(D) Fazer o design do Banco de Dados; implementar e testar cenários
críticos; liberar uma versão beta do produto.
(E) Detalhar os atores e casos de uso chave; fazer o design,
implementação, validação e estabelecer uma linha de base para a
arquitetura; determinar pelo menos uma solução possível para o problema.
Comentários

O Rational Unified Process (RUP) é um exemplo de modelo de processo de

desenvolvimento baseado no Unified Process (Processo Unificado) desenvolvido
pela Rational.
Segundo Philippe, Kruchten, no seu livro Introdução ao RUP – Rational Unified
Process O RUP (Rational Unified Process) é um processo de engenharia de
software, o qual implementa as melhores práticas comerciais a fim de obter
um processo de desenvolvimento de software bem definido. Tem o objetivo de
assegurar a produção de sistemas de qualidade, de forma repetível e previsível
e também que satisfaça as necessidades de seus usuários finais dentro de
prazo e orçamento previsíveis. O RUP consiste em um processo de
desenvolvimento Orientado a Objetos, utilizando-se da UML como padrão para
representação dos modelos.
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.
• 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) coletam-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 cabe em 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.
Gabarito: letra C.
Complementando….
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);
• 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.
Concepção
A meta da fase de concepção é alcançar o consentimento de todos os
interessados no objetivo do ciclo de vida para o projeto. Os objetivos primários
da fase de concepção incluem:
• Estabelecer a extensão de software do projeto limitar condições,
inclusive um conceito operacional, critérios de aceitação e descrições do
que é e não é pretendido estar no produto;
• Discriminar os casos de uso críticos do sistema, quer dizer, os cenários
primários do comportamento que dirigirá a funcionalidade do sistema e
amoldará os intercâmbios de projeto principais;
• Exibir, e talvez demonstrar, pelo menos uma arquitetura candidata
contra alguns dos cenários primários;
• Estimar o custo global e programar o projeto inteiro, e fornecer as
estimativas detalhadas para a fase de elaboração que se seguirá
imediatamente; e
• Estimar os riscos e as fontes de imprevisibilidade.
As atividades essenciais da fase de concepção são:

• Formular a extensão do projeto, quer dizer, captar o contexto e as

exigências mais importantes e sujeições de forma que você pode derivar
critérios de aceitação para o produto final;
• Planejar e prepara um caso empresarial e avaliar alternativas para
gerenciamento de risco, fornecendo pessoal, plano de projeto e
intercâmbios entre custo, prazo e rentabilidade; e
• Sintetizar uma arquitetura candidata, avaliar intercâmbios em projeto e
avaliar decisões de fazer/comprar/reutilizar, de forma que custo, prazo e
recursos possam ser calculados;
O resultado da fase de concepção é a criação destes artefatos:

• Um documento de visão, ou seja, uma visão geral das exigências
centrais do projeto, características fundamentais e principais sujeições;
• A pesquisa do modelo de caso de uso que lista todos os casos de uso e
atores que podem ser identificados nesta fase prematura;
• Um glossário de projeto inicial;
• Um caso empresarial inicial que inclui:
• Contexto empresarial;
• Critérios de sucesso (projeção de renda, reconhecimento de mercado,
etc); e
• Previsão financeira;
• Uma avaliação de risco inicial; e
• Um plano de projeto que mostra as fases e iterações.
A fase de concepção também pode produzir os artefatos:
• Um modelo de caso de uso inicial (10% a 20% completo) ao lidar com
um ciclo de desenvolvimento inicial;
• Um modelo de domínio mais sofisticado que um glossário;
• Um modelo empresarial, se necessário;
• Uma descrição preliminar de caso de desenvolvimento para especificar o
processo usado; e
• Um ou vários protótipos.
Objetivo do ciclo de vida: ao término da fase de concepção está o primeiro

marco de projeto principal, o marco objetivo ciclo de vida.
Os critérios de avaliação para a fase de concepção são:

• Consentimento de interessados na definição de extensão e custo e
estimativas de prazo;
• Compreensão das exigências como comprovado pela fidelidade dos casos
de uso primários;

• Credibilidade do custo e estimativas de prazo, prioridades, riscos e

processos de desenvolvimento;
• Profundidade e amplitude de qualquer protótipo arquitetônico que tenha
sido desenvolvido; e
• Despesas atuais contra despesas planejadas.
Conclusão: se o projeto falhar ao passar pelo marco da fase de concepção,

pode ser cancelado ou consideravelmente repensado.
Elaboração
O propósito da fase de elaboração é analisar o domínio de problema,
estabelecer uma fundação arquitetônica sadia, desenvolver o plano de projeto
e eliminar os elementos de alto risco do projeto. Devem ser tomadas decisões
arquitetônicas com uma compreensão do sistema inteiro: sua extensão,
funcionalidade principal e exigências não funcionais, como exigências de
desempenho.
Objetivos primários da fase de elaboração:

• Definir, validar e delinear a arquitetura tão rápida quanto necessária;
• Delinear a visão do sistema a ser construído;
• Delinear um plano de alta-fidelidade para a fase de construção; e
• Demonstrar que a arquitetura de linha de base suportará esta visão, a
um custo razoável num tempo razoável.
As atividades essenciais da fase de elaboração são:
• A visão é elaborada, e é estabelecida uma compreensão sólida dos casos
de uso mais críticos, que dirigem as decisões arquitetônicas e o
planejamento;
• São elaborados o processo, a infraestrutura e o ambiente de
desenvolvimento, e são postos no lugar o processo, ferramentas e
suporte de automatização; e
• A arquitetura é elaborada e os componentes são selecionados. São
avaliados componentes potenciais, e as decisões de
fazer/comprar/reutilizar são suficientemente entendidas para determinar
o custo da fase de construção e agendar com confiança. Os componentes
arquitetônicos selecionados são integrados e avaliados contra os cenários
primários. Lições aprendidas destas atividades podem resultar num
redesenho da arquitetura, levando em conta projetos alternativos ou
reconsideração das exigências.
Os resultados da fase de elaboração são:
• Um modelo de caso de uso (pelo menos 80% completo) no qual todos os
casos de uso foram identificados na pesquisa de modelo de caso de uso,
todos os atores foram identificados e a maioria das descrições do caso de

uso foi desenvolvida;
• Requisitos adicionais que captam as exigências não funcionais e qualquer
requisito que não esteja associada com um caso de uso específico;
• Uma descrição de arquitetura de software;
• Um protótipo arquitetônico executável;
• Uma lista de riscos revisada e um caso empresarial revisado; e
• Um plano de desenvolvimento para o projeto global, inclusive o plano de
projeto grosseiro que mostra iterações e critérios de avaliação para cada
iteração.
Ao término da fase de elaboração, está o segundo marco importante do

projeto: marco da arquitetura de ciclo de vida.
Neste momento, examinam-se os objetivos detalhados do sistema e a
extensão, a escolha da arquitetura e a resolução dos riscos principais.
Os critérios de avaliação principais para a fase de elaboração envolvem as

respostas às perguntas:
• A visão do produto é estável?
• A arquitetura é estável?
• A demonstração executável mostra elementos de risco principais que
foram endereçados e solucionamos com confiança?
• O plano de fase de construção é suficientemente detalhado e preciso? É
suportado com uma base crível para as estimativas?
• Todos os interessados concordam que a visão atual pode ser alcançada
para desenvolver o sistema completo, se o plano corrente for executado
no contexto da arquitetura atual?
• A despesa de recurso atual versus a despesa planejada é aceitável?
Se o projeto não passa por este marco, pode ser abortado ou repensado.
Construção
Durante a fase de construção, todos os componentes restantes e
características da aplicação são desenvolvidos e integrados ao produto, e todas
as características são completamente testadas. A fase de construção é, de
certo modo, um processo industrial no qual é colocada ênfase em gerenciar
recursos e controlar operações para aperfeiçoar custos, prazos e qualidade. De
certo modo, o quebra-cabeça do gerenciamento sofre uma transição do
desenvolvimento de propriedade intelectual durante a concepção e a
elaboração para desenvolvimento de produtos para distribuição durante a
construção e a transição.

Os objetivos primários da fase de construção incluem:

• Minimizar custos de desenvolvimento, aperfeiçoando recursos e evitando
fragmentar e refazer desnecessário;
• Alcançar a qualidade adequada do software o mais rápido possível; e
• Alcançar versões úteis (alfa, beta e outros lançamentos de teste)
também o mais rápido possível.
• As atividades essenciais da fase de construção são:
• Administração de recursos, controle de recursos e otimização de
processo;
• Desenvolvimento de componente completo e teste contra os critérios de
avaliação definidos; e
• Avaliação de lançamento de produto contra critérios de aceitação para a
visão.
O resultado da fase de construção é um produto pronto para seus usuários
finais. No mínimo, consiste em:
• O produto de software integrado nas plataformas adequadas;
• Os manuais de usuário; e
• Uma descrição do lançamento atual.
No final da fase de construção está o terceiro marco de projeto principal:
capacidade operacional inicial. Neste momento, deve-se decidir se o software,
os locais e os usuários estão prontos a tornarem-se operacionais sem expor o
projeto a riscos altos. Este lançamento é chamado frequentemente de
lançamento beta. Os critérios de avaliação para a fase de construção envolvem
responder as seguintes perguntas:
• Este produto lançado é estável e está amadurecido o bastante para ser
distribuído na comunidade de usuários?
• Todos os interessados estão prontos para a transição na comunidade de
usuários?
• As despesas de recursos atuais versus despesas planejadas continuam
aceitáveis?
A transição pode ter que ser adiada antes do lançamento, se o projeto não
alcançar este marco.
Transição
O propósito da fase de transição é levar o produto de software à comunidade
de usuários. Depois do produto ser dado ao usuário final, normalmente surgem
questões exigindo-lhe que desenvolva novos lançamentos, corrija alguns
problemas ou as características finais que foram adiadas.
Esta fase inclui:

• Teste de beta para validar o sistema novo contra expectativas de

usuário;
• Operação paralela com o sistema de legado que o projeto está
substituindo;
• Treinamento de usuários e mantenedores; e
• Saída do produto para o marketing, distribuição e equipes de vendas.
A fase de transição se conclui quando a linha base de desenvolvimento alcança
a visão completa. Para alguns projetos, este ponto final de ciclo de vida pode
coincidir com o ponto de partida do próximo ciclo, conduzindo à próxima
geração ou versão do produto. Pode coincidir com uma entrega dos artefatos a
terceiros responsáveis pela operação, manutenção e acréscimos do sistema
entregue para outros projetos.
Os objetivos primários da fase de transição incluem:
• Alcançar auto-suporte do usuário;
• Alcançar o consentimento do interessado nas linhas de base de
desenvolvimento que estão completas e consistentes com os critérios de
avaliação da visão; e
• Alcançar a linha de base do produto final tão rapidamente e com custo
efetivo, como praticamente.
As atividades essenciais da fase de transição são:

• Engenharia de desenvolvimento específico, ou seja, roçado, pacote
comercial e produção, saída de vendas e treinamento de pessoal de
campo;
• Afinar atividades, inclusive fixar bug e aprimoramento para desempenho
e utilidade; e
• Avaliar as linhas bases de desenvolvimento contra a visão e os critérios
de aceitação para o produto.
Ao término da fase de transição está o quarto marco de projeto importante: o
marco de lançamento de produto. Neste momento, decide-se se os objetivos
foram satisfeitos e se deveria começar outro ciclo de desenvolvimento. Em
alguns casos, este marco pode coincidir com o fim da fase de concepção para o
próximo ciclo.
O critério de avaliação primário para a fase de transição envolve as respostas
às perguntas seguintes:
• O usuário está satisfeito?
• As despesas de recursos atuais versus as despesas planejadas ainda
estão aceitáveis?

Fluxos do Rational Unified Process
Fluxo de Gerenciamento de Projeto

O gerenciamento de projeto de software é a arte de equilibrar os objetivos
concorrentes, gerenciar o risco e superar sujeições para entregar um produto
que satisfaça as necessidades dos clientes e dos usuários finais. O fato de que
poucos projetos são 100% bem-sucedidos é um indicador da dificuldade da
tarefa.
Nossa meta com o fluxo de gerenciamento de projeto de software do Rational
Unified Process é tornar a tarefa tão fácil quanto possível, fornecendo
orientação nesta área. Não é uma receita para o sucesso, mas apresenta uma
abordagem para gerenciar o projeto que melhorará notavelmente as
vantagens de entregar-se o software com êxito.
O fluxo de gerenciamento de projeto tem as três seguintes propostas:
• Fornecer uma estrutura para gerenciar projetos de software intensivos;
• Fornecer diretrizes práticas para planejar, prover pessoal, executar e
monitorar projetos; e
• Fornecer uma estrutura para gerenciar risco.
Porém, este fluxo do Rational Unified Process não tenta cobrir todos os
aspectos de gerenciamento de projeto. Por exemplo, não cobre questões
como:
• Administrar pessoal: contratando, treinando, instruindo;
• Administrar orçamentos: definindo, alocando; e
• Administrar contratos com os provedores e clientes.
Este fluxo focaliza os aspectos específicos de um processo de desenvolvimento

iterativo:
• Planejamento de um projeto iterativo pelo ciclo de vida e planejamento
de uma iteração em particular; e
• Administração de risco.
Fluxo de Modelagem Comercial (modelagem de negócios)

As metas da modelagem comercial são:
• Entender a estrutura e a dinâmica da organização na qual um sistema
será distribuído (a organização alvo);
• Entender os problemas atuais na organização e identificar potenciais
melhorias;
• Assegurar que os clientes, usuários finais e desenvolvedores tenham um
entendimento comum da organização alvo; e
• Derivar as exigências de sistema necessárias para o suporte da

organização alvo.
Para alcançar estas metas, o fluxo de modelagem comercial descreve como
desenvolver uma visão da nova organização alvo e, baseando-se nesta visão,
definir os processos, papéis e responsabilidades daquela organização num
modelo de negócio. Este modelo inclui um modelo de caso de uso empresarial
e um modelo de objeto de negócio. Devemos modelar o negócio para cumprir
melhor as necessidades dos clientes e usuários do novo sistema, tentando
entender o domínio empresarial antes de, ou em paralelo com, um projeto de
engenharia de software.
Fluxo de Requisitos
As metas do fluxo de requisitos (exigências) são:
• Estabelecer e manter acordo com os clientes e outros interessados no
que o sistema deveria fazer – e por que!
• Proporcionar ao desenvolvedor de sistemas um entendimento melhor das
exigências de sistema;
• Definir os limites do sistema (delimitar);
• Fornecer uma base para planejamento dos conteúdos técnicos de
iterações;
• Fornecer uma base para cálculo do custo e do tempo para desenvolver o
sistema; e
• Definir uma interface do usuário para o sistema, focalizado nas
necessidades e metas dos usuários.
Para atingir estas metas, o fluxo de exigências descreve como definir uma
visão do sistema e traduzi-lo num modelo de caso de uso que, com
especificações adicionais, define as exigências de software detalhadas do
sistema. Além disso, o fluxo de exigências descreve como usar atributos de
exigências para ajudá-lo a administrar a extensão e as mudanças de
exigências de seu sistema.
Tradicionalmente, as exigências são vistas com especificações textuais
detalhadas que se ajustam numa das categorias mencionadas acima,
expressar na forma de “O sistema deve...”.
Para administrar efetivamente o processo é útil obter uma compreensão do
usuário atual e outras necessidades do interessado que estão para serem
cumpridas pelo sistema que estiver sendo desenvolvido. Esta compreensão
arma a equipe de desenvolvimento com o por que (“Por que este sistema
precisa operar com 99,3% de precisão?”) e o que. Sabendo disso, a equipe
poderá fazer um trabalho melhor de interpretação das exigências (“Precisa
também operar com 99,3% de precisão enquanto a rotina de manutenção

estiver acontecendo?”), além de ser capaz de fazer intercâmbios e tomar

decisões de projetos que aperfeiçoam o processo de desenvolvimento (“Se
pudermos alcançar 92% precisão com metade do trabalho, isso é um
intercâmbio razoável?”).
Definimos um interessado como qualquer pessoa ou representante de uma
organização que tenha uma aposta – um interesse adquirido – no resultado de
um projeto. O interessado mais óbvio, é claro, é o usuário final, mas temos
que nos lembrar de considerar outros interessados importantes: um
comprador, um contratante, um desenvolvedor, um gerente de projeto ou
qualquer outro que se preocupe bastante ou de quem as necessidades devam
ser satisfeitas pelo projeto. Por exemplo, um interessado não-usuário poderia
ser um administrador de sistema cuja carga de trabalho dependerá de certas
condições default impostas pelo software de um sistema no usuário. Outros
interessados não-usuários poderiam representar o beneficiário econômico do
sistema.
Usando esta definição, parece óbvio que a equipe de desenvolvimento tem que
entender as necessidades específicas dos interessados fundamentais do
sistema. Mas como identificamos essas necessidades? É importante que
juntemos ativamente todos os tipos de solicitações de interessados (os dados
de entrada brutos usados para calcular as necessidades) ao longo do ciclo de
vida do desenvolvimento.
Fluxo de Análise e Projeto

A proposta do fluxo de análise e projeto é traduzir as exigências numa
especificação que descreva como implementar o sistema. Para fazer esta
tradução, tem que entender as exigências e transformá-las num projeto de
sistema, selecionando a melhor estratégia de implementação. Cedo no projeto,
tem que estabelecer uma arquitetura robusta, de forma que possa projetar um
sistema fácil de entender, construir e evoluir. Então é necessário ajustar o
projeto para combinar com o ambiente de implementação, projetando-o para
desempenho, robustez, escalabilidade e teste, entre outras qualidades.
O propósito da análise é transformar as exigências do sistema numa forma que
mapeie a área do projetista do software de interesse – quer dizer, para um
conjunto de classes e subsistemas. Esta transformação é dirigida pelos casos
de uso e amoldada mais adiante pelas exigências não funcionais do sistema. A
análise focaliza-se em assegurar que as exigências funcionais do sistema
sejam controladas. Por causa da simplicidade, ignora muitas das exigências
não funcionais do sistema e também as restrições do ambiente de
implementação. Como resultado, a análise expressa uma imagem quase ideal
do sistema.

Por outro lado, o propósito do projeto é adaptar os resultados da análise às

restrições impostas pelas exigências não funcionais, o ambiente de
implementação, as exigências de desempenho e assim sucessivamente. O
projeto é um refinamento da análise. Focaliza-se em aperfeiçoar o projeto do
sistema assegurando a cobertura completa das exigências.
Fluxo de Implementação
O fluxo de implementação tem quatro propostas principais:
• Definir a organização do código em termos de subsistemas de
implementação organizados em camadas;
• Implementar classes e objetos em termos de componentes (arquivos-
fonte, binários, executáveis e outros);
• Testar os componentes desenvolvidos como unidades; e
• Integrar num sistema executável os resultados produzidos por
implementadores individuais ou equipes.
Fluxo de Testes
A proposta do teste é avaliar a qualidade do produto, o que não só envolve o
produto final como inicia logo no projeto com a avaliação da arquitetura e
continua pela avaliação do produto final entregue aos clientes. O fluxo de teste
envolve:
• Verificar as interações de componentes;
• Verificar a própria integração de componentes;
• Verificar que todas as exigências tenham sido implementadas
corretamente; e
• Identificar e assegurar que todos os defeitos descobertos estejam
endereçados antes do software ser distribuído.
Fluxo de Entrega
Os desenvolvedores de software às vezes declaram vitória muito cedo. Eles
esquecem que a vontade do cliente em usar o produto terminado, em lugar de
uma compilação limpa, é que é a marca de um projeto de desenvolvimento
bem sucedido.
O propósito da distribuição é voltar o produto de software terminado aos seus
usuários. O fluxo de desenvolvimento envolve os seguintes tipos de atividades:
• Testar o software em seu ambiente operacional final (teste beta);
• Empacotar o software para a entrega;
• Distribuir o software;
• Instalar o software;
• Treinar os usuários finais e a força de vendas (saída do produto); e
• Migrar o software existente ou converter bancos de dados.

• Os caminhos pelos quais estas atividades são levadas a cabo variam

muito na indústria de software, dependendo do tamanho do projeto, do
modo da entrega e do contexto empresarial.
Fluxo de Gerência de Configuração e Mudanças

A proposta deste fluxo é localizar e manter a integridade dos recursos durante
a evolução do projeto. Dentro do ciclo de desenvolvimento, são criados muitos
artefatos valiosos. Este desenvolvimento demanda trabalho intensivo, e os
artefatos representam um investimento significante.
Como tal, esses artefatos são recursos importantes que devem ser
salvaguardados e disponíveis para reutilização. Eles evoluem e, especialmente
no desenvolvimento iterativo, são repetidamente atualizados.
Embora um trabalhador normalmente seja responsável por um artefato, não
podemos confiar na memória do indivíduo (ou na gaveta superior esquerda da
escrivaninha) para manter o rastro destes recursos do projeto. Os membros da
equipe de projeto devem poder identificar e localizar artefatos, para selecionar
a versão apropriada de um artefato,
olhar sua história para entender seu estado atual e as razões de terem
mudado, e para averiguar quem é atualmente responsável por isto.
Ao mesmo tempo, a equipe de projeto tem que rastrear a evolução do
produto, captar e administrar as solicitações de mudanças, não importa donde
venham, e então implementar as mudanças de um jeito consistente, através
de conjuntos de artefatos.
Finalmente, para suportar o fluxo de gerenciamento de projeto, temos que
fornecer a informação do estado dos artefatos fundamentais do projeto e
reunir as medidas relacionadas às suas mudanças.
Fluxo de Ambiente
A proposta do fluxo de ambiente é suportar a organização do desenvolvimento
com processos e ferramentas. Este suporte inclui:
• Seleção de ferramenta e sua aquisição;
• Configuração de ferramentas para harmonizar a organização;
• Configuração de processo;
• Melhoria de processo; e
• Serviços técnicos para suportar o processo: a infraestrutura da
tecnologia da informação (IT), administração de conta, backup e assim
por diante.
31. (Cesgranrio/Petrobrás/Infraestrutura/2008) Um fluxo de trabalho

de Engenharia de Software é distribuído ao longo de todas as fases do
Processo Unificado (PU). No contexto do PU, um fluxo de trabalho é análogo
a um conjunto de tarefas, isto é, um fluxo de trabalho identifica as tarefas
exigidas para realizar uma ação importante de Engenharia de Software e os

produtos de trabalho que são produzidos em conseqüência da conclusão
bem sucedida dessas tarefas. Relacione os produtos produzidos pelo PU
com a sua respectiva fase.
Produto
I – Relatório de teste beta.
II – Documento de visão.
III – Protótipo arquitetural executável.
IV – Plano e procedimento de teste.
Fase
P – Concepção
Q – Construção
R – Elaboração
As associações corretas são:

(A) I – Q, II – R e III – P
(B) I – Q, II – P e III – R
(C) I – P, III – Q e IV – R
(D) II – P, III – R e IV – Q
(E) II – R, III – P e IV – Q
Comentários
Produto Fase
I – Relatório de teste beta. T – Transição (não está listada aqui)
II – Documento de visão. P – Concepção
III – Protótipo arquitetural executável. R – Elaboração
IV – Plano e procedimento de teste. Q – Construção
Gabarito: letra D.
Considerações Finais

Bem, por hoje é só!! Espero ter conseguido passar de forma bem didática a
resolução das questões e seus fundamentos que são muito importantes para a
prova. Fiquem com Deus. A parte de MPS-Br será disponibilizada na próxima
aula.
Um abraço.
Profa Patrícia Lima Quintão
Referências Bibliográficas
a
Notas de aula, prof Patrícia Lima Quintão.2011.
http://www.deinf.ufma.br/~acmo/MOO_PUintro.pdf
PRESSMAN, R. S. Engenharia de Software. 6ª edição. Rio de Janeiro: Ed Mc
GrawHill, 2006.
Artigo: “Get Ready for Agile Methods, with Care”, Computer, 35, 1 (January
2002) 64-69 escrito por Boehm, B.
Agile Software Development with Scrum, Prentice Hall, (October 2001).
Revista de Engenharia de Software. Diversas.
Schwaber, K; Beedle, M, Agile Software Development, Cockburn Highsmith
Series Editors, Alistair Cockburn 2000
http://improveit.com.br/scrum
TELES, V. M. Extreme Programming. Novatec, 2004.
BEZERRA, E. Princípios de Análise e Projeto de Sistemas com UML - 2ª edição,
LTC Editora, 2003.
IBM, R., Rational Unified Process, 2010. Disponível em: <http://www-
01.ibm.com/software/br/rational/rup.shtml>. Acesso em: jun. 2011
.
KRUCHTEN, P., Introdução ao RUP Rational Unified Process, 2. ed., Rio de
Janeiro: Ciência Moderna, 2003.
Non-Functional Requirements in Software Engineering. Disponível em:
<http://www.utdallas.edu/~chung/BOOK/book.html>. Acesso em fev. 2011.
PRESSMAN, R. S., Engenharia de Software, 5a Ed. Makron Books do Brasil ,
2002.
SANTOS, R., Introdução à Programação Orientada a Objetos usando
JAVA , 4. ed., Rio de Janeiro: Elsevier, 2003.
SOMMERVILLE, I., Engenharia de Software, 8. ed., São Paulo: Pearson
Addison - Wesley, 2007.
UFMG, Desenvolvimento de Sistemas Baseados em Arquiteturas, 2006.
Disponível em: < homepages.dcc.ufmg.br/~mgoncalv/fsi06-
1/DesenvolvimentoSistemasBaseadoArquitetura.ppt>. Acesso em: nov. 2011.
Lista das Questões Apresentadas na Aula
1. (Cesgranrio/2008/Petrobrás/Analista) O CMMI define níveis

crescentes de capacidade (capability) para as áreas de processos e de
maturidade (maturity) organizacional. Sobre os níveis de maturidade, é
correto afirmar que, no nível
a). 1, a disciplina de processo alcançada ajuda a garantir que as práticas

existentes serão mantidas, mesmo em situações de crise e stress.
b). 2, os projetos são monitorados, controlados, revisados e avaliados
quanto à sua aderência à descrição do processo que utilizaram.
c). 3, a performance dos processos é controlada usando estatística e outras
técnicas quantitativas, sendo portanto quantitativamente previsível.
d). 4, a organização está focada no aperfeiçoamento contínuo da
performance dos processos através de melhorias incrementais no processo
e na tecnologia.
e). 5, a organização atingiu o nível máximo de otimização dos processos e
passa a se concentrar nos aspectos operacionais e na manutenção das
métricas que atestam sua condição.
2. (ESAF/2008/Controladoria-Geral da União/Analista de finanças e

Controle) O nível de maturidade é uma maneira de prever o futuro
desempenho de uma organização dentro de cada disciplina ou conjunto de
disciplinas. Um nível de maturidade é uma etapa evolucionária definida de
melhoria de processos. No modelo CMMI com representação em estágios
existem os seguintes níveis:
a) inicial, gerenciado, definido, gerenciado quantitativamente e otimizado.

b) inicial, parcialmente gerenciado, executado, gerenciado qualitativamente
e otimizado.
c) inicial, parcialmente gerenciado, definido, gerenciado quantitativamente e
otimizado.
d)parcialmente gerenciado, gerenciado, definido, gerenciado
e)inicial, incompleto, executado, gerenciado, definido, gerenciado
3. (CESGRANRIO/Petrobrás/Analista de Sistemas Júnior/2010) Testar

é uma disciplina de suma importância para a engenharia de software. A
literatura divide os tipos de testes em duas grandes categorias: teste de
caixa preta e teste de caixa branca. Sobre esta classificação, pode-se
afirmar que

I - testes de interfaces são classificados como de caixa branca;

II - testes de caixa preta são também chamados de teste comportamental,
onde o foco são os requisitos funcionais do software;
III - testes de caixa preta são complementares aos testes de caixa branca,
uma vez que contemplam diferentes classes de erros.
É correto o que se afirma em

a) I, apenas.
b) I e II, apenas.
c) I e III, apenas.
d) II e III, apenas.
e) I, II e III.
4. (CESGRANRIO/BNDES - Profissional Básico - Especialidade - Análise

de Sistemas – Suporte/2008) No contexto de engenharia de software,
testes de software podem ser decompostos numa série de passos que
devem ser executados seqüencialmente. Considerando a arquitetura de
software convencional, o primeiro passo deve ser o teste de
a) estresse.
b) integração.
c) sistema.
d) unidade.
e) validação.
5. (FCC/TRT - 15ª Região - Analista Judiciário - Tecnologia da

Informação/2009) Os testes de integração têm por objetivo verificar se
a) os módulos testados produzem os mesmos resultados que as unidades
testadas individualmente.
b) os módulos testados suportam grandes volumes de dados.
c) as funcionalidades dos módulos testados atendem aos requisitos.
d) os valores limites entre as unidades testadas individualmente são
aceitáveis.
e) o tempo de resposta dos módulos testados está adequado.
6. (ESAF/Prefeitura de Natal - RN - Auditor do Tesouro Municipal -

Tecnologia da Informação/2008) Com relação aos tipos de testes que
podem ser considerados e executados em um projeto de software, é correto
afirmar que o objetivo principal do Teste Funcional é assegurar que

a) a interface forneça ao usuário o acesso e a navegação adequados através

das funções do software.
b) os objetos contidos na interface funcionam conforme o esperado e
estejam em conformidade com padrões estabelecidos.
c) foram exercitados um conjunto de funcionalidades para avaliar a
navegação pelo software e a facilidade de uso do mesmo.
d) houve uma correta implementação dos requisitos do sistema, como, por
exemplo, regras de negócio, através da interface do usuário.
e) foram executadas transações, variando as cargas de trabalho, para
observar e registrar o comportamento do sistema.
7. (Cesgranrio/2010/IBGE/Análise de Sistemas/Desenvolvimento de
Aplicações) O XP (Extreme Programming) usa uma abordagem orientada a
objetos como seu paradigma de desenvolvimento predileto. Nessa
perspectiva, analise as afirmativas abaixo.
I - A atividade de Codificação começa com a criação de um conjunto de

histórias que descreve as características e as funcionalidades requeridas
para o software a ser construído.
II - O XP encoraja o uso de cartões CRC (Class- Responsibility-Colaborator)
como um mecanismo efetivo para raciocinar sobre o software no contexto
orientado a objetos.
III - O XP emprega a técnica de refactoring na codificação, mas
desaconselha a utilização da programação por pares.
IV - A criação de testes unitários antes da codificação começar é uma
prática do XP.
V - Se um difícil problema de projeto é encontrado como parte do projeto
de uma história, o XP recomenda a criação imediata de um protótipo
operacional daquela parte do projeto.

(A) I, II e IV.
(B) I, III e IV.
(C) I, IV e V.
(D) II, III e V.
(E) II, IV e V.
8. (Cesgranrio/BNDES/Desenvolvimento/2008) Que situação favorece a

escolha do uso de XP para um projeto de desenvolvimento de software, em
oposição à escolha do RUP ou do modelo Cascata?

(A) Equipe do projeto localizada em diferentes cidades e com poucos

recursos de colaboração.
(B) Equipe do projeto formada por pessoas com alto grau de

competitividade.
(C) Cliente do projeto trabalhando em parceria com a equipe do projeto e

sempre disponível para retirar dúvidas.
(D) Requisitos do software com pequena probabilidade de mudanças.
(E) Presença de um processo organizacional que exige a elaboração de

vários documentos específicos para cada projeto.
9. (CESPE/2010/BANCO DA AMAZÔNIA/Técnico Científico — Área:

Tecnologia da Informação — Arquitetura de Tecnologia) O Scrum é
utilizado, como função primária, para o gerenciamento de projetos de
desenvolvimento de software, mas também tem sido usado como extreme
programming e outras metodologias de desenvolvimento. Teoricamente, o
Scrum pode ser aplicado em qualquer contexto no qual um grupo de
pessoas necessite trabalhar juntas para atingir um objetivo comum.
10. (Cesgranrio/IBGE/Análise de Sistemas/Desenvolvimento de

Aplicações/2010) A figura abaixo apresenta alguns dos principais
artefatos do RUP (Rational Unified Process) e o fluxo de informações
existentes entre eles.
Qual é o nome do artefato identificado, na figura, pela palavra ARTEFATO e por

um círculo?
(A) Projeto do Sistema
(B) Lista de Riscos
(C) Especificação Suplementar

(D) Plano de Teste

(E) Modelo de Casos de Uso
11. (Cesgranrio/Casa da Moeda do Brasil/Analista de Nível Superior

/Desenvolvimento de Sistemas/2009) A fase do RUP, em que são
implementados os cenários críticos dos casos de uso arquiteturalmente
significativos, se chama
a) Concepção
b) Elaboração
c) Mitigação
d) Construção
e) Transição
12. (Cesgranrio/Petrobrás/Processo de Negócios/2010) Existem

vários Modelos de Ciclo de Vida do Processo de Software. O
desenvolvimento em espiral é um modelo
(A) iterativo.
(B) para modificar requisitos.
(C) para analisar componentes.
(D) para analisar interface gráfica.
(E) para modularizar o sistema.

princípio fundamental do Processo Unificado é
(A) ser centrado em arquitetura.
(B) empregar times auto-dirigidos e auto-organizados.
(C) o desenvolvimento em cascata.
(D) a programação em pares.
(E) a propriedade coletiva do código fonte.

Análise Estruturada são feitas as afirmativas a seguir.
I – Uma condição necessária para que um DFD esteja em equilíbrio com um
DER é que cada depósito do DFD deve corresponder a um tipo de objeto ou
a um relacionamento ou à combinação de um tipo de objeto e de um
II – A especificação de processos de um DFD pode ser feita através de
tabelas de decisão, linguagem estruturada, condições pré-pós, fluxogramas
e diagramas de Nassi-Shneiderman.

III – O DTE representa o comportamento de um sistema, descrevendo seus

devendo apresentar um único estado inicial e um único estado final.
Está(ão) correta(s) a(s) afirmativa(s):
(A) I, apenas.
(B) II, apenas.
(C) III, apenas.
(D) I e II, apenas.
(E) I, II e III.
15. (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.
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.
16. (Cesgranrio/BR Distribuidora/Infraestrutura/2008) Considere a

seqüência de atividades e eventos apresentada a seguir.
• Projeto de concepção de um novo software de prateleira
• Projeto de desenvolvimento do novo software
• Projeto de marketing de lançamento do software
• Distribuição do software por dois anos
• Projeto de alteração das funcionalidades do software
• Projeto de marketing do software ampliado para atingir novos segmentos
de mercado
Esta seqüência de atividades é conhecida como
(A) ciclo de vida do produto.
(B) ciclo de vida de projetos.
(C) ciclo de projetos.
(D) projetos de ciclo de vida.
(E) projetos de produtos.
17. (Cesgranrio/BR Distribuidora/Desenvolvimento/2008) Uma

diferença entre o modelo incremental e o modelo evolucionário por
prototipagem é que somente o modelo incremental
(A) é iterativo.
(B) é recomendado quando os requisitos dos sistemas estão totalmente
definidos a priori.
(C) pode gerar um incremento com objetivo de minimizar o risco de
operação do sistema final.
(D) objetiva entregar um sistema que seja operacional em cada incremento.
(E) projeta testes antes da implementação do sistema.
18. (Cesgranrio/Eletrobrás/Engenharia de Software/2010) O termo

Modelo de Ciclo de Vida é utilizado para descrever um grupo de atividades e

a forma como elas se relacionam. Considerando o Modelo de Ciclo de Vida

de Sistemas por Prototipagem Evolucionária, afirma-se que
(A) os clientes não têm acesso a uma visualização dos progressos do
desenvolvimento.
(B) é possível determinar com exatidão o tempo que o projeto irá demorar.
(C) não deve ser utilizado quando os requisitos mudam rapidamente e o
cliente está relutante em aceitar um conjunto de requisitos.
(D) não há uma forma de saber de antemão o número de iterações que
serão necessárias.
(E) apenas a fase final gera um produto que não é um documento.
19. (Cesgranrio/BR Distribuidora/Desenvolvimento/2008) Considere

os seguintes elementos:
I - baseados em cenários – como diagramas de casos de uso e de
atividades;
II - orientados a fluxos – como diagramas de fluxo de dados e de controle;
III - baseados em classes – como diagramas de classes e de colaboração;
IV - baseados em comportamentos – como diagramas de estado e de
seqüência.
São elementos do modelo de análise de desenvolvimento de um sistema:

(A) II e III, somente.
(B) I, II e III, somente.
(C) I, III e IV, somente.
(D) II, III e IV, somente.
(E) I, II, III e IV.
20. (Cesgranrio/Funasa/2009) À luz da Engenharia de Software, o ciclo

de vida clássico, também chamado de modelo sequencial linear ou modelo
em cascata, é um paradigma aplicável ao desenvolvimento de sistemas de
informações que
(A) enfatiza a análise de riscos, que é feita no início do projeto e revisada a

cada fase, incluindo um plano de ataque e ações de mitigação dos riscos,
aumentando as chances de sucesso do projeto.
(B) prevê uma sequência (ou cascata) de entregas de versões do sistema
ao longo do desenvolvimento do mesmo, o que proporciona uma avaliação
de progresso baseada em código funcionando, em vez de quantidade de
documentação gerada.
(C) exige que todos os requisitos sejam conhecidos e corretamente
especificados no início do ciclo de vida, dificultando a acomodação de
mudanças que surjam nas fases posteriores.
(D) foi sempre pouco utilizado na prática, pois se apoia em analogias com
práticas de engenharia convencional que não se aplicam bem ao
desenvolvimento de sistemas de informação.
(E) utiliza a estratégia dividir para conquistar (divide to conquer), prevendo
que cada fase do ciclo de vida seja desdobrada em um miniciclo de vida

sequencial completo, formando uma cascata de ciclos de vida até o limite

adequado para lidar com a complexidade do sistema.
21. (Cesgranrio/MD/2009) A fase que deve acontecer primeiro no

desenvolvimento de sistemas de uma empresa que utiliza o modelo de ciclo
de vida em cascata é a de
(A) testes.
(B) análise e projeto.
(C) especificação de requisitos.
(D) implantação.
(E) implementação.
22. (Cesgranrio/Petrobrás/Processo de Negócio/2010) No Ciclo de

Vida Clássico, também chamado de Modelo Sequencial Linear ou Modelo
Cascata, é apresentada uma abordagem sistemática composta pelas
seguintes atividades:
(A) Análise de Requisitos de Software, Projeto, Geração de Código, Teste e

Manutenção.
(B) Modelagem e Engenharia do Sistema/Informação, Análise de Requisitos de
Software, Projeto, Geração de Código, Teste e Manutenção.
(C) Modelagem e Engenharia do Sistema/Informação, Projeto, Geração de
Código, Teste e Manutenção.
(D) Levantamento de Requisitos de Software, Projeto, Geração de Código e
Manutenção e Análise de Requisitos de Software.
(E) Levantamento de Requisitos de Software, Projeto, Geração de Código,
Teste Progressivo e Manutenção.
23. (Cesgranrio/Petrobrás/Engenharia de Software/2010) O modelo

de ciclo de vida em cascata
(A) enfatiza a realização sequencial das atividades do desenvolvimento de

um produto de software.
(B) enfatiza a comunicação estreita com o cliente durante o
desenvolvimento do produto de software.
(C) envolve a ideia principal de criar um protótipo executável e, por meio de
transformações sucessivas, chegar ao sistema completamente
implementado.
(D) envolve a análise dos riscos envolvidos no desenvolvimento dos
requisitos identificados para produto de software.
(E) recomenda a geração de versões incompletas do sistema, que podem
ser passadas para o usuário final, o que permite a retroalimentação do
24. (Cesgranrio/BNDES/Desenvolvimento/2009) No ciclo de vida em

cascata, o custo de correção é menor na fase de
(A) testes.

(B) transição.
(C) implementação.
(D) requisitos.
(E) manutenção.
25. (Cesgranrio/Petrobrás/Processos de Negócios/2008) Analise as

afirmativas a seguir, sobre requisitos em projetos de software.
I - O rastreamento de requisitos é de grande importância para conduzir
análises de impacto quando há mudanças em requisitos.
II - O acrônimo FURPS+ se refere aos requisitos não funcionais das
categorias de Feasibility, Usability, Reliability, Performance e Supportability.
III - Um requisito pode conter, além da especificação, atributos que sirvam
ao seu gerenciamento.
IV - Casos de uso são descrições da interação entre um ator e o sistema e,
portanto, especificam apenas requisitos funcionais.
(A) I e II.
(B) I e III.
(C) II e III.
(D) II e IV.
(E) III e IV.

Análise e o Gerenciamento de Requisitos, é FALSO afirmar que:
(A) quanto mais tarde for identificado um problema na análise de requisitos,
maior será o custo com o retrabalho.
(B) a elicitação é o processo de identificação e entendimento das
necessidades e restrições dos usuários, enquanto que a especificação é o
processo de formalização das necessidades e restrições dos usuários em
requisitos funcionais de software.
(C) na análise de requisitos o cliente utiliza as melhores práticas de
engenharia de requisitos na tarefa de descrever suas necessidades.
(D) o gerenciamento de requisitos corresponde ao conjunto de atividades
que auxilia a equipe do projeto a identificar, controlar e rastrear os
requisitos, bem como a fazer as alterações nos requisitos durante o projeto.
(E) o gerenciamento de requisitos implica a alteração, inclusão e/ou
exclusão de requisitos ao produto de software, o que pode levar a
alterações de prazos, de recursos humanos, de equipamentos e de
tecnologia.
27. (Cesgranrio/Petrobrás/Engenharia de Software/2006) Analise as

afirmativas abaixo a respeito de técnicas de levantamento de requisitos:
I - Uma entrevista não estruturada deve “fluir” entre o entrevistado e o
entrevistador e, para isso, as questões a serem feitas não se devem ser
definidas previamente.

II - A Implantação da Função de Qualidade (IFQ) é uma técnica que traduz

as necessidades do cliente para requisitos técnicos de software,
identificando três tipos de requisitos: normais, esperados e excitantes.
III - Amostragem é o processo de seleção sistemática de elementos
representativos de uma população, que permite revelar informações úteis
acerca da população como um todo.
IV - Uma técnica importante no levantamento de requisitos é observar o
comportamento e o ambiente do indivíduo tomador de decisões, já que
muitas informações passam desapercebidas com a utilização de outras
técnicas.
Estão corretas apenas as afirmativas:
(A) I e II.
(B) III e IV.
(C) I, II e III.
(D) I, II e IV.
(E) II, III e IV.
28. (Cesgranrio/Petrobrás/Engenharia de Software/2008) Estudos

baseados na análise de diversos projetos de desenvolvimento de software
sugerem que tais projetos têm maior chance de sucesso quando empregam
metodologia e gerenciamento alinhados ao paradigma de desenvolvimento
de novos produtos, em contraponto ao paradigma de produção industrial.
Com base nessas observações, a maioria das metodologias modernas de
desenvolvimento de software recomenda:
(A) concluir o trabalho de especificações dos requisitos do sistema, antes de

iniciar as atividades de projeto e implementação.
(B) planejar detalhadamente no início do projeto todas as fases e atividades
do mesmo, de forma que seja possível estimar com precisão o esforço
necessário e os prazos de cada atividade.
(C) providenciar, desde o início do projeto, mecanismos para prevenir e
bloquear solicitações de mudanças de forma a garantir que será entregue
exatamente o que foi especificado.
(D) dividir o trabalho em iterações curtas, com prazos fixos, e não permitir
que as mesmas avancem sobre os prazos, reduzindo o escopo da iteração,
se necessário.
(E) não produzir documentação técnica para o sistema, tendo em vista que
a mesma já nasce condenada a ficar desatualizada, investindo melhor o
tempo em atividades de implementação e testes exaustivos.
29. (Cesgranrio/IBGE/Desenvolvimento/2009) Os processos de

desenvolvimento de software utilizam, muitas vezes, procedimentos
estatísticos para, por exemplo, apoiar a tomada de decisão. Dentro desse
contexto, o Diagrama de Pareto é baseado na clássica regra de que
(A) 20% das ocorrências causam 80% dos problemas.
(B) 60% das amostras de um processo normal encontram-se nos limites do
desvio padrão.

(C) pontos fora dos limites de um desvio padrão revelam a ocorrência de

problemas aleatórios.
(D) três pontos consecutivos abaixo da média indicam um processo em
melhoria contínua.
(E) um índice de erro acima dos cinco sigmas indica um processo que
alcançou a qualidade.

gerente de projeto decidiu utilizar o Processo Unificado (RUP – rational
unified process) como seu processo de desenvolvimento de software. Com
base no RUP, quais os objetivos que o gerente deve direcionar para a fase
de Elaboração?
(A) Produzir Documento Visão completo e estável; detalhar os atores e
casos de uso chave; determinar pelo menos uma solução possível para o
problema.
(B) Produzir Documento Visão completo e estável; fazer o design dos casos
de uso críticos; obter um entendimento mais detalhado dos requerimentos.
(C) Fazer o design dos casos de uso críticos; obter um entendimento mais
detalhado dos requerimentos; implementar e testar cenários críticos.
(D) Fazer o design do Banco de Dados; implementar e testar cenários
críticos; liberar uma versão beta do produto.
(E) Detalhar os atores e casos de uso chave; fazer o design,
implementação, validação e estabelecer uma linha de base para a
arquitetura; determinar pelo menos uma solução possível para o problema.
31. (Cesgranrio/Petrobrás/Infraestrutura/2008) Um fluxo de trabalho

de Engenharia de Software é distribuído ao longo de todas as fases do
Processo Unificado (PU). No contexto do PU, um fluxo de trabalho é análogo
a um conjunto de tarefas, isto é, um fluxo de trabalho identifica as tarefas
exigidas para realizar uma ação importante de Engenharia de Software e os
produtos de trabalho que são produzidos em conseqüência da conclusão
bem sucedida dessas tarefas. Relacione os produtos produzidos pelo PU
com a sua respectiva fase.
Produto
I – Relatório de teste beta.
II – Documento de visão.
III – Protótipo arquitetural executável.
IV – Plano e procedimento de teste.
Fase

P – Concepção
Q – Construção
R – Elaboração
As associações corretas são:

(A) I – Q, II – R e III – P
(B) I – Q, II – P e III – R
(C) I – P, III – Q e IV – R
(D) II – P, III – R e IV – Q
(E) II – R, III – P e IV – Q
Gabarito
1. Letra B. 20. Letra C.

2. Letra A. 21. Letra C.
3. Letra D. 22. Letra B.
4. Letra D. 23. Letra A.
5. Letra C. 24. Letra D.
6. Letra D. 25. Letra B.
7. Letra E. 26. Letra C.
8. Letra C. 27. Letra E.
9. Item correto. 28. Letra D.
10. Letra B. 29. Letra A.
11. Letra B. 30. Letra C.
12. Letra A. 31. Letra D.
13. Letra A.
14. Letra D.
15. Letra B.
16. Letra A.
17. Letra D.
18. Letra D.
19. Letra E.

EXE - ANA - DESENV - Aula 03

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

EXE - ANA - DESENV - Aula 03

Enviado por

Direitos autorais:

Formatos disponíveis

INFORMÁTICA EM EXERCÍCIOS PARA BNDES

FORMAÇÃO: ANÁLISE DE SISTEMAS - DESENVOLVIMENTO

Aula 3 – Engenharia de Software e Tópicos Relacionados

Olá queridos(as) amigos (as)!

“Quem acredita sempre alcança”. Importante acreditar em si mesmo, e

Tópicos do Edital a Serem Abordados na Aula

Visão geral do CMMI e seus objetivos gerais

Integration). Este substitui os CMMs de Engenharia de Sistemas e o de

O CMMI (Capability Maturity Model Integration) é um modelo de

• CMMI for Development (CMMI-DEV) – fornece diretivas para monitoração,

Teste Caixa Preta e Teste Caixa Branca

Os testes dinâmicos são aqueles que para a sua execução dependem da

Profa. Patrícia Lima Quintão www.pontodosconcursos.com.br 4

organizações. A aplicação de testes de caixa preta não exclui a necessidade de

Técnicas de Teste Caixa-Branca

Tipos de teste caixa-branca:

Teste Caixa Preta (funcional)

Profa. Patrícia Lima Quintão www.pontodosconcursos.com.br 5

O teste caixa preta é também chamado de teste funcional. O nome “caixa

A realização de testes visa principalmente:

Se a atividade de testes for conduzida com sucesso, ela descobrirá erros no

Integração Descendente Primeiro-em-profundidade

Integração Descendente Primeiro-em-largura

Passos de Integração Descendente

2. Os pseudocontrolados são substituídos, um de cada vez, pelos componentes

Desvantagem da Integração Descendente

Passos da Integração Ascendente

Profa. Patrícia Lima Quintão www.pontodosconcursos.com.br 9

Integração Ascendente vs. Descendente

Outros tipos de testes

Profa. Patrícia Lima Quintão www.pontodosconcursos.com.br 10

em que o tempo de resposta começa a degradar ou a aplicação começa

Profa. Patrícia Lima Quintão www.pontodosconcursos.com.br 11

Primeira Dimensão: Estado do teste (“o momento”)

Segunda dimensão: Técnica do teste (“como vou testar”)

Terceira dimensão: Metas do Teste (“o que tenho de testar”)

Quarta dimensão: Onde será o teste (“o ambiente do teste”)

Bem, após essa revisão inicial, vamos às questões!

Questões de Provas Comentadas

1. (Cesgranrio/2008/Petrobrás/Analista) O CMMI define níveis

a). 1, a disciplina de processo alcançada ajuda a garantir que as práticas

Profa. Patrícia Lima Quintão www.pontodosconcursos.com.br 13

Existem 5 níveis de maturidade, numerados de 1 a 5. Cada um é uma

Vamos aos comentários de cada item:

Item A. No nível de maturidade 1 (Inicial), geralmente os processos são ad

Item B. É no nível de maturidade 2 (Gerenciado) que os projetos

Item C. É no nível de maturidade 4 (Gerenciado Quantitativamente) que

Item D. O nível de maturidade 5 (Em Otimização ou Otimizado) é que

Profa. Patrícia Lima Quintão www.pontodosconcursos.com.br 14

organização está focada na melhoria contínua do desempenho dos processos

Item E. Não há teto, ou nível máximo de otimização dos processos. Essa

2. (ESAF/2008/Controladoria-Geral da União/Analista de finanças e

a) inicial, gerenciado, definido, gerenciado quantitativamente e otimizado.

Profa. Patrícia Lima Quintão www.pontodosconcursos.com.br 15

Um nível de maturidade pode ser considerado um degrau evolucionário para a

A seguir são descritas as principais características de cada nível de maturidade

Áreas de Processo: Não há.

Áreas de Processo: Gestão de Requisitos (REQM), Planejamento do

Profa. Patrícia Lima Quintão www.pontodosconcursos.com.br 16

Áreas de Processo: Desenvolvimento de Requisitos (RD), Solução Técnica

• Nível 4 – Gerenciado Quantitativamente

• Nível 5 – Em Otimização ou Otimizado