AULAS 02 e 03: Noções sobre processo de
desenvolvimento de software e Papéis e
Responsabilidades em Projetos de Software
SUMÁRIO
Análise e Projeto de Software
Implementação, testes e implantação
Papéis e responsabilidades em projetos de software
Metodologias ágeis
Exercícios
Gabarito
Exercícios Comentados
Simulado
PÁGINA
1
13
19
24
32
40
41
54
ANÁLISE E PROJETO DE SOFTWARE
O levantamento de requisitos, a análise de requisitos e o projeto do
software não são fases isoladas entre si. Ao elaborar diagramas e confeccionar
documentos para buscar a melhor compreensão e entendimento dos requisitos
de um sistema, já começa ali a fase de análise de requisitos.
Tal imiscuidade entre fases também ocorrerá entre a análise e o projeto.
O modelo de requisitos: entre a descrição do sistema e o projeto. Fonte: Pressman, 2011.
Prof. Victor Dalton
1 de 55
ANÁLISE
A fase de análise de requisitos, no contexto do desenvolvimento de um
sistema, é aquela na qual são construídos modelos para representar o sistema a
ser construído.
Esta fase tem como característica não levar com conta o ambiente
tecnológico a ser utilizado. Nesta atividade, o foco de interesse é tentar
construir uma estratégia de solução sem se preocupar com a maneira como essa
estratégia será realizada. Em resumo, a prioridade é saber o que o sistema
proposto deve fazer, para, posteriormente (no projeto), definir como o sistema
irá fazê-lo.
A modelagem de requisitos possui duas visões clássicas: a análise
estruturada e a análise orientada a objetos.
A análise estruturada considera os dados e os processos que transformam
os dados em entidades separadas. Esta técnica descreve o fluxo de informação e
transformações que são aplicadas à medida que os dados se movimentam da
entrada para a saída. O diagrama que melhor ilustra a análise estruturada é o
Diagrama de Fluxo de Dados (DFD), que será visto adiante.
A análise orientada a objetos, por sua vez, lança mão da abstração para
representar coisas do mundo real, sob a forma de objetos.
Os objetos podem ser uma entidade externa, uma coisa, uma ocorrência,
um evento, uma unidade organizacional, um local, enfim, qualquer elemento que
possa ser representado por um conjunto de atributos. Por exemplo, uma
pessoa pode ser definida por um nome, endereço, telefone, número de CPF. Um
pedido, por sua vez, pode ser definido pelo seu número, comprador, produtos,
quantidade e preço total. Objetos serão exemplificados no diagrama de classes,
visto adiante.
PRINCIPAIS DIAGRAMAS DA FASE DE ANÁLISE
Modelos baseados em cenários
São os casos de usos e histórias de usuários, já detalhados na Engenharia
de Requisitos.
Prof. Victor Dalton
2 de 55
Modelos de Fluxo
A modelagem orientada a fluxos considera os dados e os processos que os
transformam entidades distintas. É a representação da análise estruturada, e
seu principal diagrama é o Diagrama de Fluxo de Dados, ou DFD.
Em um DFD, representam-se entidades externas por caixas, processos (ou
tarefas) por circunferências (também podem ser elipses ou elipses achatadas), o
fluxo dos dados por setas e depósitos de dados por traços duplos. Veja abaixo:
Diagrama de Fluxo de Dados: meramente ilustrativo.
Diagrama de Fluxos de Dados: meramente ilustrativo.
Prof. Victor Dalton
3 de 55
Modelos de Comportamento
Os modelos comportamentais indicam como o software irá responder a
estímulos ou eventos externos. Os diagramas de estado e de sequência
representam este tipo de modelo.
Diagrama de estados: um exemplo.
Diagrama de sequência: um exemplo.
Prof. Victor Dalton
4 de 55
Modelos de classe
A modelagem baseada em classes representa os objetos que o sistema irá
manipular, as operações (também denominada métodos ou serviços) que serão
aplicados aos objetos para efetuar a manipulação, alguns relacionamentos entre
os objetos e as colaborações que ocorrem entre as classes definidas.
Os elementos de um modelo baseado em classes são: classes e objetos,
atributos, operações, modelos CRC (classe-responsabilidade-colaborador),
diagramas de colaboração e pacotes.
Diagrama de classes: exemplo
Como dito anteriormente, não existe uma fronteira clara entre o término da
fase de análise e o início da fase de projeto. Teoricamente, ao término da
análise, os requisitos estão suficientemente detalhados para que modelagens
mais refinadas possam ser empregadas.
Prof. Victor Dalton
5 de 55
PROJETO
O foco principal da análise são os aspectos lógicos e independentes de
implementação de um sistema, ou seja, os requisitos. Na fase de projeto,
determina-se o “como” o sistema funcionará, para atender aos requisitos.
Os modelos de requisitos, apresentados por elementos baseados em
cenários, baseados em classes, orientado a fluxos e comportamentais,
alimentam a tarefa de projeto.
A atividade de projeto engloba o conjunto de princípios, conceitos e
práticas que conduzem ao desenvolvimento de um sistema ou produto com alta
qualidade. Lembro que, lato sensu, este também é o objetivo de todo o
processo de desenvolvimento de software.
Para buscar a qualidade do software, o projeto deve possuir algumas
características:

O projeto deve implementar todos os requisitos explícitos
contidos no modelo de requisitos e deve acomodar todos os
requisitos implícitos desejados pelos interessados;

O projeto deve ser um guia legível, compreensível para aqueles que
geram código e para aqueles que testam, e, subsequentemente, dão
suporte ao software;

O projeto deve dar uma visão completa do software, trabalhando
os domínios de dados, funcional e comportamental sob a perspectiva
de implementação.
Ainda, cabe destacar alguns conceitos que devem ser ponderados quando
da elaboração de um projeto:
Abstração: À medida que o nível de abstração migra de um nível mais alto
para um nível mais baixo, a solução deixa de ser expressa na linguagem do
domínio do problema para ser expressa em uma terminologia técnica.
Arquitetura: Uma meta do projeto de software é derivar um quadro da
arquitetura de um sistema, que representará a organização a partir da qual
atividades mais detalhadas do projeto são conduzidas.
Prof. Victor Dalton
6 de 55
Padrões: Os padrões de projeto são soluções comprovadamente eficazes
que podem ser aproveitados em projetos de problemática recorrente. Por
exemplo, um sistema de vendas online provavelmente possuirá um padrão de
projeto consolidado. P.S.: não confundir o aproveitamento de um padrão de
projeto com o aproveitamento de código (reuso de software).
Separação por interesses (por afinidades): Esse conceito afirma que
qualquer problema complexo pode ser tratado mais facilmente se decomposto
em trechos a ser resolvidos e ou otimizados independentemente. Esse conceito
aparece em outros conceitos, como modularidade, aspectos, independência
funcional e refinamento.
Modularidade: Dividir um software em poucos módulos o torna fácil de
integrar, mas difícil de desenvolver e manutenir. Dividir demais o torna difícil de
integrar, embora o custo do módulo seja baixo. O desafio do projeto é
modularizar o problema da melhor forma possível, minimizando custos.
Diagrama de classes ilustrando a modularidade. Modularizar “na medida certa” traz uma série de
benefícios ao projeto e ao software.
Encapsulamento de informações: O princípio do encapsulamento diz
que os módulos devem ser capazes de ocultar suas características uns dos
outros, disponibilizando apenas os itens que interessam aos outros módulos.
Independência funcional: A independência funcional é atingida
desenvolvendo-se módulos com função única e que pouco interagem com outros
módulos. É medida qualitativamente pela coesão e pelo acoplamento. Um
Prof. Victor Dalton
7 de 55
módulo coeso realiza poucas tarefas, interagindo o mínimo necessário com
outros módulos. Quanto ao acoplamento, é desejável que ele seja fraco, ou seja,
que cada módulo se comunique o mínimo possível com os demais.
Refinamento: O refinamento gradual é uma estratégia top-down. Um
programa é desenvolvido refinando-se níveis procedurais sucessivamente.
Refatoração: Técnica de reorganização que simplifica o projeto ou código,
sem mudar sua função ou comportamento. Em projetos de refabricação de
software, deve-se examinar o projeto antigo, eliminar redundâncias, corrigir
algoritmos eficientes ou desnecessários.
Refatoração: um exemplo. Um atributo que estava mal esclarecido, “nome2”, agora passa a se
chamar “mae”, explicitando a sua funcionalidade.
Usando a notação, princípios e métodos adequados, o projeto produz um
projeto de dados/classes, um projeto de arquitetura, um projeto de
interfaces e um projeto de componentes.
Prof. Victor Dalton
8 de 55
Projeto de dados/classes
O projeto de dados/classes transforma os modelos de classes em
realizações de classes de projeto e nas estruturas de dados dos requisitos
necessários para implementar o software.
Projeto de dados: um exemplo.
Prof. Victor Dalton
9 de 55
Projeto de arquitetura
O projeto arquitetural define os relacionamentos entre os principais
elementos estruturais do software, os estilos arquiteturais e os padrões de
projeto que podem ser usados para satisfazer os requisitos definidos para o
sistema e as restrições que o afetam. Diagramas de implantação podem mostrar
os componentes físicos de um sistema, assim como diagramas de componentes
pode mostrar os principais componentes de um software.
Diagrama de Implantação, materializando a arquitetura de um sistema
Diagrama de Componentes, materializando a arquitetura de um sistema
Prof. Victor Dalton
10 de 55
Projeto de componentes
O projeto de componentes destrincha elementos estruturais da arquitetura,
em uma descrição procedural dos componentes de software.
Diagrama de classes, detalhando cada componente de um software
Projeto de interface de usuário
Conjunto de desenhos detalhados que representa fluxos de informação que
entram em saem do sistema, como o sistema de comunica com sistemas
externos e com as pessoas que o utilizam. Devem ser buscadas algumas
características como:
Familiaridade – usar termos e conceitos obtidos da experiência de pessoas
que farão uso do sistema.
Consistência – sempre que possível, operações similares devem ser
ativadas da mesma maneira.
Prof. Victor Dalton
11 de 55
Surpresa mínima – os usuários nunca devem ser surpreendidos pelo
comportamento de um sistema.
Deixar o usuário no comando – o usuário deve ser capaz de interromper o
que está fazendo para fazer outra coisa, sem perder o trabalho já feito.
Reduzir a memória do usuário – o sistema deve ser capaz de guiar o
usuário, não precisando ele armazenar procedimentos na memória.
Projeto de interface com o usuário: um exemplo.
Em resumo, o projeto de interface com o usuário será a proposta de “tela”,
ou “telas”, por meio das quais os usuários do sistema realização sua interação
com o mesmo. Inevitavelmente o projeto de interface com o usuário será
submetido à aprovação do cliente, podendo sofrer modificações antes da
codificação.
Prof. Victor Dalton
12 de 55
IMPLEMENTAÇÃO, TESTES E IMPLANTAÇÃO
IMPLEMENTAÇÃO
Na implementação, o sistema é codificado, ou seja, ocorre a tradução da
descrição computacional obtida na fase de projeto em código executável,
mediante o uso de uma ou mais linguagens de programação.
Código de programa: ilustração
Ao codificar um software, um programador poderá escrever código novo,
ou reaproveitar código já existente. Esse reaproveitamento de código é chamado
de reuso de software.
O reuso de software pode trazer vários benefícios, como ganho de tempo (o
código já está escrito), confiança, redução de risco (o código já foi utilizado com
sucesso anteriormente), dentre outros fatores.
Por fim, é interessante destacar que a maioria das bibliografias prevê que o
teste de unidade acontece na etapa da implementação. O teste de unidade é o
teste pontual, realizado pelo programador, que verifica que aquele componente
Prof. Victor Dalton
13 de 55
ou módulo que ele desenvolveu realmente faz o que deveria fazer, atendendo às
especificações do projeto.
Uma vez que o sistema esteja codificado (e com seus módulos testados, a
nível unidade), os códigos desenvolvidos pelos diversos programadores é
integrado, e poderá ser submetido a uma bateria maior e mais complexa de
testes.
TESTES
Teste de software é uma atividade realizada para descobrir erros que
foram produzidos inadvertidamente no momento em que o software foi
projetado e construído. Pode ser planejado antecipadamente e conduzido
sistematicamente. Ainda, podem ser testes de baixo nível, no qual são
verificados se pequenos segmentos de código-fonte foram corretamente
implementados, bem como testes de alto nível, que validam as principais
funções do sistema com base nos requisitos do cliente.
Estratégias de teste de software
As estratégias de teste de software fornecem um roteiro que descreve os
passos a serem executados como parte do teste.
Em um contexto macro, o teste de software é um elemento de um aspecto
mais amplo, que é frequentemente referido como Verificação e Validação (V&V).
Verificação se refere ao conjunto de atividades que garante que o
software implementa corretamente uma função específica (estamos construindo
o produto corretamente?), enquanto a Validação se certifica que o software
construído corresponde aos requisitos do cliente (estamos construindo o produto
certo?).
O teste proporciona o último elemento a partir do qual a qualidade pode ser
estimada, e, mais pragmaticamente, os erros podem ser descobertos.
Conforme afirmado desde o início, a qualidade é incorporada ao software ao
longo do processo de engenharia de software. Portanto, a motivação, por trás do
teste, é a confirmação da qualidade. Se a qualidade não estiver lá antes do
teste, não estará lá após a realização dele.
Prof. Victor Dalton
14 de 55
Quanto à responsabilidade pela execução dos testes, cabe aos próprios
desenvolvedores a realização dos testes de unidade e, em muitos casos,
também os testes de integração. Os mais complexos, por sua vez, serão
realizados por um grupo independente de teste. Este grupo também faz parte
da equipe de desenvolvimento do software.
Quanto à estratégia em si, a espiral da figura abaixo ilustra o processo.
Estratégia de teste de software. Fonte: Pressman, 2011.
Teste de unidade – se concentra em cada unidade: componente, classe
ou módulo. Usa intensamente técnicas de teste com caminhos distintos, com o
objetivo de descobrir erros dentro do módulo testado.
Teste de integração – técnica sistemática para construir a arquitetura do
software ao mesmo tempo que conduz testes para descobrir erros associados
com as interfaces (comunicação entre os módulos, não confundir com interface
com o usuário). A integração pode ocorrer de forma descendente (top-down) ou
ascendente (bottom-up).
Integração de módulos. No exemplo, M4 e M7 serão incorporados à arquitetura, e o sistema deverá
ser testado com a presença desses dois novos módulos.
Prof. Victor Dalton
15 de 55
Teste de validação – a validação de software é conseguida por meio de
uma série de testes que demonstram conformidade com os requisitos. Um plano
de testes poderá definir casos de teste específicos que atestem que os requisitos
funcionais sejam satisfeitos, que os requisitos de desempenho sejam atendidos,
que a documentação esteja correta, dentre outros. Desvios ou erros descobertos
nesse estágio raramente podem ser corrigidos antes do prazo de entrega
programado.
Se um software é desenvolvido como um produto para ser usado por
muitos clientes, é impraticável que todos eles realizem testes formais de
aceitação. Muitos construtores de software, então, usam um processo chamado
de teste alfa e beta para descobrir erros que apenas o usuário final é capaz de
encontrar.
O teste alfa é conduzido na instalação do desenvolvedor por um grupo
representativo de usuários finais. Nele, o desenvolvedor monitora os usuários,
registrando os erros e os problemas de uso.
O teste beta é conduzido nas instalações dos usuários finais. Via de regra,
o desenvolvedor não está presente, e os erros e problemas encontrados são
reportados pelos usuários.
Teste de sistema – o teste de sistema extrapola os limites da engenharia
de software. Uma vez validado, o software deverá ser combinado com outros
elementos do sistemas (como hardware, pessoas, base de dados). Ele verifica se
todos os elementos se combinam corretamente e se a função/desempenho
global do sistema é conseguida. Podem ser:





Teste de recuperação: força o sistema a falhar de várias formas e
verifica se a recuperação é executada corretamente;
Teste de segurança: verifica se os mecanismos de proteção
incorporados ao sistema protegem contra acesso indevido;
Teste de esforço: coloca o programa em condições anormais. “Até
onde podemos forçar o sistema até que ele falhe?”
Teste de desempenho: testar o desempenho, em tempo de
execução, do software em um contexto de sistema integrado. Pode
ser feito em conjunto com testes de esforço;
Teste de disponibilização: exercitar o software em cada ambiente no
qual ele deve operar, como em vários sistemas operacionais, vários
navegadores web, ou várias plataformas (PC, smartphone...).
Depuração – Quando um erro é encontrado, o código deverá ser
“futucado” para encontrar o pedaço de código que está escrito de maneira
incorreta, para então ser corrigido. A esta etapa é dada o nome de depuração.
Depurar o código não é testar o código, mas são processos que se relacionam.
Prof. Victor Dalton
16 de 55
Técnicas de teste de software
Realizar testes em software é um paradoxo de raciocínio. Os
desenvolvedores devem “deixar” de construir o software e passar a trabalhar em
casos de teste para “quebrá-lo”.
O objetivo do teste é encontrar erros, e um bom este é aquele que tem alta
probabilidade de encontrar um erro. Os testes devem ter uma série de
características que permitam atingir o objetivo de encontrar o maior número de
erros com um mínimo de esforço. São atributos desejáveis em um teste:




Alta probabilidade de encontrar erros;
Não ser redundante;
O melhor de uma categoria (o mais completo de um grupo similar
de testes);e
Nem muito simples, nem muito complexo.
Vejamos algumas técnicas de teste:
Caixa-Branca - Também chamada de teste estrutural ou orientado à
lógica, a técnica de caixa-branca avalia o comportamento interno do
componente de software. Essa técnica trabalha diretamente sobre o código fonte
do componente de software para avaliar aspectos tais como: teste de condição,
teste de fluxo de dados, teste de caminho básico, teste de ciclos, teste de
caminhos lógicos, códigos nunca executados, teste de estrutura de controle.
Os aspectos avaliados nesta técnica de teste dependerão da complexidade
e da tecnologia que determinarem a construção do componente de software,
cabendo portanto avaliação de mais aspectos que os citados anteriormente. O
testador tem acesso ao código fonte da aplicação e pode construir códigos para
efetuar a ligação de bibliotecas e componentes. Este tipo de teste é desenvolvido
analisando o código fonte e elaborando casos de teste que cubram todas as
possibilidades do componente de software. Dessa maneira, todas as variações
relevantes originadas por estruturas de condições são testadas.
A técnica de teste de caixa-branca é recomendada para as fases de teste
de unidade e teste de integração, cuja responsabilidade principal fica a cargo dos
desenvolvedores do software, que por sua vez conhecem bem o código fonte
produzido.
Caixa-Preta
Também
chamada
de
teste
funcional,
teste
comportamental, orientado a dado ou orientado a entrada e saída, a técnica de
caixa-preta avalia o comportamento externo do componente de software,
sem se considerar o comportamento interno do mesmo. Dados de entrada são
fornecidos, o teste é executado e o resultado obtido é comparado a um resultado
Prof. Victor Dalton
17 de 55
esperado previamente conhecido. Como detalhes de implementação não são
considerados, os casos de teste são todos derivados da especificação.
Quanto mais entradas são fornecidas, mais rico será o teste. Numa situação
ideal todas as entradas possíveis seriam testadas, mas na ampla maioria dos
casos isso é impossível. Outro problema é que a especificação pode estar
ambígua em relação ao sistema produzido, e como resultado as entradas
especificadas podem não ser as mesmas aceitas para o teste. Uma abordagem
mais realista para o teste de caixa-preta é escolher um subconjunto de entradas
que maximize a riqueza do teste. Pode-se agrupar subconjuntos de entradas
possíveis que são processadas similarmente, de forma que testar somente um
elemento desse subconjunto serve para averiguar a qualidade de todo o
subconjunto. Por exemplo, em um sistema que aceita um inteiro como entrada,
testar todos os casos possíveis pode gerar pelo menos dezenas de milhares de
casos de testes distintos. Entretanto, a partir da especificação do sistema, podese encontrar um subconjunto de inteiros que maximizem a qualidade do teste.
Depende do propósito do sistema, mas casos possíveis incluem inteiros pares,
inteiros ímpares, zero, inteiros positivos, inteiros negativos, o maior inteiro, o
menor inteiro.
A aplicação de técnicas de teste leva o testador a produzir um conjunto de
casos de teste (ou situações de teste). A aplicação combinada de outra técnica –
técnica de particionamento de equivalência (ou uso de classes de
equivalência) permite avaliar se a quantidade de casos de teste produzida é
coerente. A partir das classes de equivalência identificadas, o testador construirá
casos de teste que atuem nos limites superiores e inferiores destas classes, de
forma que um número mínimo de casos de teste permita a maior cobertura de
teste possível.
Uma outra variação é a Análise do Valor Limite – na qual são testados
valores nas fronteiras de um domínio. Por exemplo: se determinado campo só
permite o preenchimento com números de 1 a 100, aplicam-se nos testes os
valores 0,1,100 e 101.
As técnicas caixa-preta podem ser aplicadas em todos as etapas de teste,
embora mais apropriadas a partir dos testes de integração até a implantação.
IMPLANTAÇÃO
Na implantação, o sistema é empacotado, distribuído e instalado no
ambiente do usuário. Os manuais do sistema são escritos, os arquivos são
carregados, os dados são importados para o sistema, e os usuários são
treinados para utilizar o sistema corretamente. Dependendo da situação, pode
ocorrer também a migração de sistemas de do software e de dados
preexistentes.
Prof. Victor Dalton
18 de 55
PAPÉIS E RESPONSABILIDADES EM PROJETOS DE SOFTWARE
Como você deve ter observado, o estudo do processo de desenvolvimento
de software é “orientado a processos”, ou seja, preocupa-se com o avançar do
processo em si.
Para avaliar os papéis e responsabilidades em projetos de software é
necessário realizar um estudo “transversal”, extraindo as participações dos
diversos personagens ao longo do projeto de software. Vejamos:
Patrocinador
O patrocinador do projeto, via de regra, é alguém do alto escalão de uma
organização, que “compra” a idéia do software. Em virtude de sua posição, é
capaz de atribuir recursos e dinheiro ao projeto.
Entretanto, além de financiar o projeto, os patrocinadores têm outras
funções muito importantes para o sucesso dos projetos.
Durante o ciclo de vida do projeto, o patrocinador atua como um decisor
acima do gerente de projeto, podendo tomar decisões fora da alçada do gerente
do projeto. Além disso, o patrocinador funciona como um ponto focal para a
alta administração e também para outros stakeholders, eventualmente.
À primeira vista, pode parecer que o patrocinador do projeto duplica os
esforços do gerente de projeto. No entanto, um patrocinador do projeto
experiente pode melhorar a comunicação e coordenação em questões além das
responsabilidades do gerente de projeto. O papel do patrocinador está
diretamente ligado à gerência sênior e inclui, mas não se limita a:







Participar na seleção de projetos, categorização e priorização;
Participar no estabelecimento de prioridades e alocação de recursos;
Estabelecer objetivos estratégicos para o projeto;
Alinhar os objetivos do projeto aos objetivos de negócio;
Realizar acompanhamento e relatórios sobre o andamento do projeto
para a alta administração;
Auxilia a fixação da autoridade do gerente de projeto;
Participa do comitê de controle de mudanças.
Prof. Victor Dalton
19 de 55
Em geral, patrocinadores devem ter sólidos conhecimentos de negócio e
boa capacidade de comunicação. Ele irá atuar mais como um líder visionário
para o projeto, enquanto o gerente de projeto irá desempenhar funções de
gestão e técnica a maioria dos o tempo.
Especialmente em projetos complexos de grande porte, os gerentes de
projetos precisam de muita ajuda de executivos de nível sênior. Sem patrocínio,
a chance de fracasso é muito grande. Sendo o patrocinador um gerente sênior,
ele possui autoridade e poder para tomar decisões que trazem grande agilidade
e flexibilidade aos projetos, permitindo responder a riscos mais rapidamente e
controlar mudanças. Desta forma, o patrocinador assegura, de uma maneira
indireta, que a alta administração apoia o projeto.
Um bom patrocinador é a ligação entre o gerente de projeto e gerentes
seniores e executa diferentes funções durante o ciclo de vida do projeto,
promover e proteger o projeto.
Durante o início de um projeto, o patrocinador deve ser responsável pelo
Termo de Abertura do Projeto e seu Business Case, alinhando os objetivos do
projeto à estratégia corporativa. O patrocinador irá designar um gerente para
o projeto, que pode ajudar neste planejamento inicial.
O planejamento do projeto será responsabilidade do gerente de projeto
designado e sua equipe, mas o patrocinador deve tomar conhecimento e aprovar
planos de projeto. Ao longo da execução, o patrocinador irá monitorar o
progresso e status do projeto, informando à gerência sênior. O patrocinador
deve ter reuniões regulares com o gerente do projeto para reforçar a confiança e
obter informações atualizadas.
Finalmente, é o patrocinador o responsável pelo projeto perante a
organização e à alta administração. Ele deve assegurar que os benefícios do
projeto estão sendo entregues.
Gerente de Projetos
O gerente de projetos é o responsável pela gerência ou coordenação
das atividades necessárias à construção do sistema. Deve fazer o
orçamento do projeto de desenvolvimento, estimar o tempo necessário para o
desenvolvimento do sistema, definir qual o processo de desenvolvimento, o
cronograma de execução das atividades, a equipe de desenvolvimento, os
recursos de hardware e software, etc.
Prof. Victor Dalton
20 de 55
O monitoramento e controle das atividades realizadas também é de
responsabilidade do gerente do projeto, bem como a realização dos ajustes
necessários para a adequação dos recursos e gastos.
O gerente deverá ser meticuloso em seus estudos, quando realizar o estudo
de viabilidade, escolher a equipe de desenvolvimento e o processo de
desenvolvimento de software.
O gerente de projeto, por sua vez, presta contas ao patrocinador do
projeto.
Segundo Pressman, o gerente de projeto, ao gerenciar efetivamente o
projeto de software, deve focar em 4Ps, e nessa sequência: Pessoas, Produto,
Processo e Projeto.
Pessoas
O gerente de projeto deve ater-se a algumas práticas-chaves, como:
formar a equipe, liderar sua equipe, estabelecer boa comunicação com a equipe
e com os interessados no projeto.
Produto
O gerente de projeto também deve analisar detalhadamente os requisitos
(junto com os analistas de requisitos), para estabelecer e delimitar o escopo, de
modo a poder estimar recursos e prazo.
Processo
A equipe de software deve ser flexível ao escolher o processo de software
mais adequado ao projeto e às tarefas de engenharia de software que fazem
parte do modelo selecionado.
Projeto
É a abordagem de cuidar do projeto como um projeto em si, entendendo
fatores críticos de sucesso, planejando, monitorando e controlando o projeto,
por meio de métricas e ferramentas.
Prof. Victor Dalton
21 de 55
Área de Negócio
A área de negócio é o conjunto de stakeholders que será o principal
beneficiado pelo projeto de software. Cabe a ela colaborar com a elicitação
de requisitos, participar dos testes finais do software, e fornecer o feedback
após a sua implantação.
Pode-se destacar um personagem nesse contexto, o Especialista de
Domínio. O especialista do domínio interage com o analista de requisitos para
levantar os requisitos do sistema.
Analista de Requisitos
O analista de requisitos é o profissional que precisa ter conhecimento do
domínio do negócio. Ele precisa compreender tal domínio para definir os
requisitos do sistema a ser desenvolvido.
Analistas devem estar aptos a se comunicar com especialistas do domínio
para obter conhecimento acerca dos problemas e das necessidades envolvidas
na empresa que necessita do sistema.
Se, por um lado, ele não precisa ser um especialista, por outro, deve ter
suficiente domínio do vocabulário da área de conhecimento na qual o sistema
será implantado. Preferencialmente, este nível de domínio deve ser suficiente
para que o especialista de domínio não precise, a todo momento, explicar
conceitos básicos da área.
O analista de requisitos precisará captar as necessidades dos clientes e
repassar esse entendimento aos demais desenvolvedores do sistema, fazendo
uma “ponte” entre os profissionais da computação e os profissionais do negócio.
Em suma, os analistas de requisitos realizam o levantamento e a análise
de requisitos. Inclusive, enxerga-se como uma progressão natural na carreira
dos analistas de requisitos a gerência de projetos, uma vez que os analistas de
requisitos adquirem experiência com a participação em diversos projetos.
Equipe de desenvolvimento
A equipe de desenvolvimento é fortemente atuante nas fases de projeto e
implementação da solução de software. Destaque para:
 Projetistas: avaliam as alternativas de solução do problema
resultante da análise e geram a especificação de uma solução
computacional detalhada. Podem ser especializados em interface,
redes, bancos de dados, etc;
Prof. Victor Dalton
22 de 55


Arquitetos de software: especialista em elaborar a arquitetura do
sistema como um todo;
Programadores: codificação do sistema e testes;
Equipe de sustentação
A sustentação consiste no suporte e atendimento ao cliente, responsável
por manter o produto. Logo, a equipe de sustentação é aquela responsável pela
manutenção do sistema após a sua entrega.
Via de regra, equipes de desenvolvimento de software são montadas sob
medida, em virtude do talento de seus integrantes, e desfeitas após o término
do projeto. Inclusive, pode ocorrer, por questões contratuais, que uma empresa
diferente da que desenvolveu o sistema seja responsável por sua manutenção.
A equipe de sustentação pode realizar suporte técnico e prestar consultoria
aos cliente, se for o caso.
A manutenção prestada por essa equipe pode ser corretiva, aquela que
corrige defeitos no sistema, adaptativa, adaptando alguns aspectos do sistema,
como hardware, plataforma de sistema operacional, etc, desde que não sejam
muito complexas, ou evolutiva, que adiciona novas funcionalidades ao software.
Destaco, ainda, que esse acréscimo de funcionalidade é pontual. Evolução
significativa de software é tratada à parte, como um outro projeto de software.
Dentre os integrantes da equipe de sustentação, destaca-se o analista de
suporte, profissional capaz de interpretar a solicitação do cliente e analisar se o
problema relatado é um defeito a ser corrigido no sistema ou não.
Prof. Victor Dalton
23 de 55
METODOLOGIAS ÁGEIS DE DESENVOLVIMENTO DE SOFTWARE
As metodologias ágeis surgiram como um esforço para sanar fraquezas
reais e perceptíveis da engenharia de software tradicional. Entretanto, ela não
pode ser aplicada a todos os projetos, produtos, pessoas e situações.
Nos dias atuais, as necessidades dos usuários finais mudam rapidamente,
e, em muitas situações, não será possível definir completamente os requisitos
antes que se inicie um projeto.
Porém, o conceito de “agilidade” vai além da rapidez para responder a
mudanças. Ela incentiva a estruturação e as atitudes em equipe que tornam a
comunicação mais fácil, a entrega rápida do software operacional; assume o
cliente como parte da equipe de desenvolvimento, reconhece que o
planejamento tem seus limites e que o plano de projeto tem que ser flexível.
Quatro são os valores percebidos pela filosofia ágil:




Indivíduos e interações, em vez de processos e ferramentas
Software funcional, em vez de documentação abrangente
Colaboração do cliente, em vez de negociação de contratos
Responder mudanças, em vez de seguir um plano
Com base nesses valores, a Agile Alliance estabelece 12 princípios de
agilidade:
1. Garantir
a satisfação do consumidor entregando rapidamente e
continuamente softwares funcionais;
2. Softwares funcionais são entregues frequentemente (semanas, ao invés
de meses);
3. Softwares funcionais são a principal medida de progresso do projeto;
4. Até mesmo mudanças tardias de escopo no projeto são bem-vindas. Os
processos ágeis devem ser uma vantagem competitiva;
5. Cooperação constante entre pessoas que entendem do 'negócio' e
desenvolvedores;
6. Projetos surgem através de indivíduos motivados, entre os quais existe
relação de confiança.
7. Conversa aberta é a melhor maneira de transmitir informações para
dentro e fora da equipe;
8. Atenção contínua para a excelência técnica;
9. Os
processos
ágeis
promovem
desenvolvimento
sustentável.
Desenvolvedores e usuários devem pode manter um ritmo constante de
trabalho indefinidamente;
10. Simplicidade é essencial;
Prof. Victor Dalton
24 de 55
11. As melhores arquiteturas, requisitos e projetos emergem de equipes que
se auto organizam;
12. Colaboração com clientes mais do que negociação de contratos;
Seguidos esses princípios, existem algumas metodologias ágeis bastante
conhecidas, como o XP e o Scrum. Vejamos:
XP, oriunda de eXtreme Programming, é uma filosofia de programação que
segue algumas práticas genéricas, cujo conhecimento considero válido. São
elas:
 Jogo de Planejamento (Planning Game): O desenvolvimento é feito em
iterações semanais. No início da semana, desenvolvedores e cliente reúnem-se
para priorizar as funcionalidades. Essa reunião recebe o nome de Jogo do
Planejamento. Nela, o cliente identifica prioridades e os desenvolvedores as
estimam. O cliente é essencial neste processo e assim ele fica sabendo o que
está acontecendo e o que vai acontecer no projeto. Como o escopo é reavaliado
semanalmente, o projeto é regido por um contrato de escopo negociável, que
difere significativamente das formas tradicionais de contratação de projetos de
software. Ao final de cada semana, o cliente recebe novas funcionalidades,
completamente testadas e prontas para serem postas em produção.
 Pequenas Versões (Small Releases): A liberação de pequenas versões
funcionais do projeto auxilia muito no processo de aceitação por parte do cliente,
que já pode testar uma parte do sistema que está comprando. As versões
chegam a ser ainda menores que as produzidas por outras metodologias
incrementais, como o RUP.
 Metáfora (Metaphor): Procura facilitar a comunicação com o cliente,
entendendo a realidade dele. O conceito de rápido para um cliente de um
sistema jurídico é diferente para um programador experiente em controlar
comunicação em sistemas em tempo real, como controle de tráfego aéreo. É
preciso traduzir as palavras do cliente para o significado que ele espera dentro
do projeto.
 Projeto Simples (Simple Design): Simplicidade é um princípio da XP.
Projeto simples significa dizer que caso o cliente tenha pedido que na primeira
versão apenas o usuário "teste" possa entrar no sistema com a senha "123" e
assim ter acesso a todo o sistema, você vai fazer o código exato para que esta
funcionalidade seja implementada, sem se preocupar com sistemas de
autenticação e restrições de acesso. Um erro comum ao adotar essa prática é a
confusão por parte dos programadores de código simples e código fácil. Nem
sempre o código mais fácil de ser desenvolvido levará a solução mais simples
por parte de projeto. Esse entendimento é fundamental para o bom andamento
do XP. Código fácil deve ser identificado e substituído por código simples.
Prof. Victor Dalton
25 de 55
 Time Coeso (Whole Team): A equipe de desenvolvimento é formada por
pessoas engajadas e de forma multidisclipinar (no sentido de incluir pessoas
com cada uma das habilidades necessárias para o projeto).
 Testes de Aceitação (Customer Tests): São testes construídos pelo
cliente e conjunto de analistas e testadores, para aceitar um determinado
requisito do sistema.
 Ritmo Sustentável (Sustainable Pace): Trabalhar com qualidade,
buscando ter ritmo de trabalho saudável (40 horas/semana, 8 horas/dia), sem
horas extras. Horas extras são permitidas quando trouxerem produtividade para
a execução do projeto. Outra prática que se verifica neste processo é a prática
de trabalho energizado, onde se busca trabalho motivado sempre. Para isto o
ambiente de trabalho e a motivação da equipe devem estar sempre em
harmonia.
 Reuniões em pé (Stand-up Meeting): Reuniões em pé para não se
perder o foco nos assuntos, produzindo reuniões rápidas, apenas abordando
tarefas realizadas e tarefas a realizar pela equipe.
 Posse Coletiva (Collective Ownership): O código fonte não tem dono e
ninguém precisa solicitar permissão para poder modificar o mesmo. O objetivo
com isto é fazer a equipe conhecer todas as partes do sistema.
 Programação em Pares (Pair Programming): é a programação em
par/dupla num único computador. Geralmente a dupla é formada por um
iniciante na linguagem e outra pessoa funcionando como um instrutor. Como é
apenas um computador, o novato é que fica à frente fazendo a codificação, e o
instrutor acompanha ajudando a desenvolver suas habilidades. Desta forma o
programa sempre é revisto por duas pessoas, evitando e diminuindo assim a
possibilidade de defeitos. Com isto busca-se sempre a evolução da equipe,
melhorando a qualidade do código fonte gerado.
 Padrões
de Codificação (Coding Standards): A equipe de
desenvolvimento precisa estabelecer regras para programar e todos devem
seguir estas regras. Desta forma parecerá que todo o código fonte foi editado
pela mesma pessoa, mesmo quando a equipe possui 10 ou 100 membros.
 Desenvolvimento Orientado a Testes (Test Driven Development):
Primeiro crie os testes unitários (unit tests) e depois crie o código para que os
testes funcionem. Esta abordagem é complexa no início, pois vai contra o
processo de desenvolvimento de muitos anos. Só que os testes unitários são
essenciais para que a qualidade do projeto seja mantida.
 Refatoração (Refactoring): É um processo que permite a melhoria
continua da programação, com o mínimo de introdução de erros e mantendo a
compatibilidade com o código já existente. Refabricar melhora a clareza (leitura)
do código, divide-o em módulos mais coesos e de maior reaproveitamento,
evitando a duplicação de código-fonte;
 Integração Contínua (Continuous Integration): Sempre que produzir
uma nova funcionalidade, nunca esperar uma semana para integrar à versão
atual do sistema. Isto só aumenta a possibilidade de conflitos e a possibilidade
Prof. Victor Dalton
26 de 55
de erros no código fonte. Integrar de forma contínua permite saber o status real
da programação.
O Scrum é uma metodologia de desenvolvimento iterativo e
incremental para gerenciamento de projetos e desenvolvimento ágil de software.
Scrum não é um processo nem descreve o que se deve fazer em cada
situação. Ele é usado para trabalhos complexos nos quais é difícil predizer tudo o
que irá ocorrer.
O Scrum é um conjunto de passos que contém grupos de práticas e papéis
pré-definidos. Os únicos papéis são:
1. O Proprietário do Produto, ou Product Owner, que representa os
stakeholders e o negócio;
2. o Scrum Master, que mantém os processos (normalmente no lugar de um
gerente de projeto);
3. a Equipe, ou Team, um grupo multifuncional com cerca de 7 pessoas e
que fazem a análise, projeto, implementação, teste, etc.
Sprint
Um sprint é a unidade básica de desenvolvimento em Scrum. Sprints
tendem a durar entre uma semana e um mês, e são um esforço dentro de uma
"caixa de tempo" (ou seja, restrito a uma duração específica) de comprimento
constante.
Cada sprint é precedido por uma reunião de planejamento, onde as tarefas
para o sprint são identificadas e um compromisso estimado para o objetivo do
sprint é definido e seguido por uma reunião de revisão ou de retrospectiva, onde
o progresso é revisto e lições para os próximos sprints são identificadas.
Durante cada sprint, a equipe cria um incremento de produto
potencialmente entregável (por exemplo, software funcional e testado). O
conjunto de funcionalidades que entram em um sprint vêm do backlog do
produto, que é um conjunto de prioridades de requisitos de alto nível do trabalho
a ser feito. Quais itens do backlog entram para o sprint são determinados
durante a reunião de planejamento do sprint. Durante esta reunião, o Product
Owner informa a equipe dos itens no backlog do produto que ele ou ela quer
concluídos. A equipe então determina quantos eles podem se comprometer a
concluir durante o próximo sprint, e registram isso no backlog do sprint. Durante
um sprint, ninguém está autorizado a alterar o backlog do sprint, o que significa
que os requisitos são congelados para esse sprint. O desenvolvimento de cada
sprint deve terminar na "caixa de tempo" prevista. Se os requisitos não são
completados por qualquer motivo, eles são deixados de fora e voltam para o
backlog do produto. Depois que um sprint é completado, a equipe demonstra
como usar o software.
Prof. Victor Dalton
27 de 55
O Scrum permite a criação de equipes auto organizadas, encorajando a
cooperação de todos os membros da equipe e a comunicação verbal entre todos
os membros e disciplinas da equipe no projeto.
Artefatos
Product Backlog
Um backlog é uma lista de itens priorizados a serem desenvolvidos para um
software. O Product Backlog é mantido pelo Product Owner e é uma lista de
requisitos que tipicamente vêm do cliente. O Product Backlog pode ser alterado
a qualquer momento pelo Product Owner ou por decisão deste.
Sprint backlog
O Sprint backlog é uma lista de itens selecionados do Product backlog e
contém tarefas concretas que serão realizadas durante o próximo sprint para
implementar tais itens selecionados. O Sprint Backlog é uma representação em
tempo
real
do
trabalho
que
o Development Team planeja
concluir
na sprint corrente, e ele pertence unicamente ao Development Team.
Planejamento de sprint
Antes de todo sprint, o Product Owner, o Scrum Master e a Equipe decidem
no que a equipe irá trabalhar durante o próximo sprint. O Product Owner
mantém uma lista priorizada de itens de backlog, o backlog do produto, o que
pode ser repriorizado durante o planejamento do sprint. A Equipe seleciona itens
do topo do backlog do produto. Eles selecionam somente o quanto de trabalho
eles podem executar para terminar. A Equipe então planeja a arquitetura e o
design de como o backlog do produto pode ser implementado. Os itens
do backlog do produto são então destrinchados em tarefas que se tornam
o backlog do sprint.
Reuniões
Daily Scrum
Cada dia durante o sprint, uma reunião de status do projeto ocorre. Isso é
chamado de "scrum diário". Esta reunião tem diretrizes específicas:
 A reunião começa precisamente no horário marcado.
 Todos são bem-vindos, mas apenas "poucos" podem falar.
 O encontro tem duração determinada (TimeBox) e dura 15 minutos.
 A reunião deve acontecer no mesmo local e mesma hora todos os dias
 Durante a reunião, cada membro da equipe responde a três perguntas:
 O que você tem feito desde ontem?
 O que você está planejando fazer hoje?
Prof. Victor Dalton
28 de 55
Você tem algum problema impedindo você de realizar seu objetivo?
É papel do Scrum Master para facilitar a resolução desses impedimentos.
Normalmente, isso deve ocorrer fora do contexto do Daily Scrum para que a
reunião possa durar menos de 15 minutos.

Reunião de Planejamento da Sprint (Sprint Planning Meeting)
No início do ciclo de sprint (a cada 7-30 dias), um Sprint Planning Meeting é
realizado.
 Selecione o trabalho que está a ser feito.
 Prepare o Sprint Backlog que detalha o tempo que levará para fazer esse
trabalho, com toda a equipe.
 Identificar e comunicar o quanto o trabalho é susceptível de ser feito
durante o sprint atual.
 Dividida em duas partes:
 Parte 1 (Primeiras quatro horas): Team Product Owner: diálogo para
priorizar o Product Backlog.
 Parte 2 (Próximas quatro horas): Team apenas: hash de um plano para a
Sprint, resultando na Sprint Backlog.
No final de um ciclo de sprint, são realizadas duas reuniões: a "Sprint Review" e
do "Sprint Retrospective".
Reunião de Revisão da Sprint (Sprint Review)
Rever o trabalho que foi concluído e não concluído.
 Apresentar o trabalho realizado para os interessados (ou "a demo"). Um
trabalho incompleto não pode ser demonstrado.
Retrospectiva da Sprint (Sprint Retrospective)
 Todos os membros da equipe refletem sobre a sprint passada.
Três questões principais são feitas na retrospectiva sobre o sprint: O que
deu errado? O que deu certo? O que poderia ser melhorado para o próximo
sprint?

Prof. Victor Dalton
29 de 55
Se você achou o Scrum um pouco utópico, eu posso garantir que não é.
Utilizamos ele no Banco Central pra valer, e os projetos andam! Com reuniões
diárias, sprints e tudo o mais!
Entretanto, existem outras metodologias ágeis, como:
 Desenvolvimento de Software Adaptativo (ASD): O apoio filosófico do
ASD concentra-se na colaboração humana e na auto-organização. A
auto-organização aparece quando agentes individuais independentes
cooperam para criar resultados emergentes. Um resultado
emergente é uma propriedade além da capacidade de qualquer
agente individual. Ciclo de vida: Especulação: iniciação do projeto e
planejamento adaptativo. Colaboração: pessoal motivado trabalha
junto de um modo que multiplica seus talentos e resultados criativos.
Aprendizagem que pode ocorrer de três modos: foco nos grupos;
revisão técnicas formais; pós-conclusão.
Prof. Victor Dalton
30 de 55
ASD

Método de Desenvolvimento de Sistemas Dinâmicos: É uma
metodologia de desenvolvimento de software originalmente baseada
em "Desenvolvimento Rápido de Aplicação" (RAD). DSDM é uma
metodologia de desenvolvimento iterativo e incremental que enfatiza
o envolvimento constante do usuário.
DSDM

Seu objetivo é entregar softwares no tempo e com custo estimados
através do controle e ajuste de requisitos ao longo do
desenvolvimento. DSDM é um dos modelos de Metodologia Ágil de
desenvolvimento de software, e seu formato é propriedade da Agile
Alliance.
Processo Unificado Ágil (AUP):Versão simplificada do RUP, adaptada
à metodologia ágil.
Prof. Victor Dalton
31 de 55
EXERCÍCIOS
1ª Questão) (ESAF – TCU - Analista de Controle Externo – Análise de
Sistemas - 2002) O paradigma do ciclo de vida clássico da engenharia de
software requer uma abordagem sistemática, sequencial ao desenvolvimento do
software, que se inicia no nível do sistema e avança ao longo da análise, projeto,
codificação, teste e manutenção. A etapa deste ciclo, que se apresenta como um
processo de múltiplos passos e se concentra em quatro atributos distintos do
programa: estrutura de dados, arquitetura de software, detalhes procedimentais
e caracterização da interface, é a atividade de
a) codificação.
b) análise de requisitos de software.
c) análise de sistemas.
d) engenharia de sistemas.
e) projeto.
2ª Questão) (ESAF – MPOG – Analista de Planejamento e Orçamento
– Tecnologia da Informação – 2008) Em Modelagem Orientada a objetos,
objetos podem ser:
a) Entidades externas. Coisas. Ocorrências ou eventos. Papéis. Unidades
organizacionais. Lugares. Estruturas.
b) Entidades internas. Coisas. Chaves de ocorrências. Papéis. Unidades
organizacionais. Especialidades de estruturas.
c) Atividades externas. Capacidades. Ocorrências ou eventos. Posições.
Unidades organizacionais. Lugares. Unidades de entidades.
d) Entidades externas. Coisas. Ocorrências ou eventos. Pastas. Unidades de
recursos. Objetivos. Estruturas.
e) Entidades de referência. Situações. Ocorrências ou eventos. Papéis.
Diretrizes organizacionais. Lugares. Objetos inominados.
3ª Questão) (FCC – TST – Analista Judiciário – Análise de Sistemas –
2012) São características da análise estruturada e da análise orientada a
objetos, respectivamente:
Prof. Victor Dalton
32 de 55
a) a organização do código-fonte em pacotes e o uso de diagrama de
classes.
b) programas elaborados com o uso de funções e determinação do
dicionário de dados.
c) o uso de diagramas de sequência e o uso do diagrama de contexto.
d) a modelagem do fluxo de dados e a abstração de conceitos do mundo
real.
e) a técnica de encapsulamento e a extensão de classes com a aplicação de
herança.
4ª Questão) (ESAF – Receita Federal – Analista – Informática –
2012) Assinale a opção correta relativa a diagrama de fluxo de dados (DFD).
a) Descreve graficamente o fluxo em depósitos de dados e as
transformações dos processos que interferem nas entradas a partir de entidades
externas.
b) Modela os objetos relativos a fluxo de informações e as categorias de
dados relevantes para as saídas.
c) Descreve graficamente o fluxo de informações e as transformações que
são aplicadas à medida que os dados se movimentam da entrada para a saída.
d) Descreve graficamente a estrutura das informações em que se
organizam os dados inerentes a processos.
e) Descreve graficamente o fluxo de dados transformados segundo
atributos das entidades externas.
5ª Questão) (ESAF – SEFAZ/CE – Analista de Tecnologia da
Informação – 2006 - adaptada) Analise a descrição a seguir.
O paradigma do ciclo de vida clássico da engenharia de software abrange
seis atividades. Na atividade de _____________ são traduzidas as exigências de
uma representação do software que podem ser avaliadas quanto à qualidade
antes que se inicie a codificação.
Escolha a opção que preenche corretamente a lacuna acima.
a) projeto
b) levantamento de requisitos
Prof. Victor Dalton
33 de 55
c) teste
d) implantação
e) análise
6ª Questão) (CESPE – CNJ – Analista Judiciário – Análise de Sistemas
– 2013) No ciclo de vida de software, a estrutura de dados, a arquitetura, os
detalhes procedimentais e a caracterização da interface são atributos da etapa
de análise e engenharia de software.
7ª Questão) (CESPE – Banco da Amazônia – Técnico Científico –
Análise de Sistemas – 2012) O projeto foca na solução, consistindo em
atividades de criação de um produto, enquanto a análise focaliza o problema. Na
análise orientada a objetos, descrevem-se objetos ou conceitos como livros e
usuários, que possuem atributos e responsabilidades.
8ª Questão) (CESPE – INPI – Analista – Desenvolvimento e
Manutenção de Sistemas – 2012) A documentação da arquitetura de
software de sistema facilita a comunicação entre os participantes do
desenvolvimento do sistema. A respeito das práticas de arquitetura de software,
julgue os itens a seguir.
1 A refatoração objetiva tornar o código mais claro e limpo.
2 Ao refatorar um código, altera-se a funcionalidade do sistema.
9ª Questão) (ESAF – SEFAZ/CE – Analista de Tecnologia da
Informação - 2006) Na engenharia de software, o objetivo do processo de
Teste de Software é
a) encontrar defeitos.
b) corrigir apenas os defeitos de alta criticidade.
c) executar apenas os testes de caixa preta.
d) demonstrar o correto funcionamento do software.
e) provar que o software está 100% isento de defeitos.
Prof. Victor Dalton
34 de 55
10ª Questão) (ESAF – Receita Federal - Técnico – Tecnologia da
Informação - 2006) Analise as seguintes afirmações relacionadas a Teste de
Software:
I. O teste “caixa-preta” e o teste “caixa-branca” são os únicos tipos de
testes possíveis quando não se dispõe do código-fonte.
II. O teste “caixa-preta”, também chamado “teste funcional”, testa o
sistema do ponto de vista do usuário, isto é, não considera a estrutura interna
ou a forma de implementação do sistema.
III. Ao adotar uma abordagem “top-down”, o executor de teste deve
concentrar-se inicialmente no teste “caixa-branca”, que parte de uma visão
externa do sistema.
IV. O teste “caixa-branca” procura exercitar todas as partes do código de
um sistema.
Indique a opção que contenha todas as afirmações verdadeiras.
a) II e IV
b) II e III
c) III e IV
d) I e III
e) I e II
11ª Questão) (ESAF – Prefeitura de Natal – Auditor do Tesouro
Municipal – Informática - 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.
Prof. Victor Dalton
35 de 55
e) foram executadas transações, variando as cargas de trabalho, para
observar e registrar o comportamento do sistema.
12ª Questão) (ESAF – MPOG – Analista de Planejamento e
Orçamento – Tecnologia da Informação - 2008) Uma estratégia de teste de
software integra métodos de projeto de casos de teste em uma série planejada
de passos. Em relação a estratégias de testes, é correto afirmar que:
a) realizar testes para mostrar que não existem defeitos no software faz
parte das estratégias de testes.
b) demonstrar ao desenvolvedor e ao cliente que o software atende aos
requisitos é uma meta de validação do software.
c) o particionamento de equivalência é uma maneira estratégica de aplicar
testes de software.
d) o teste estrutural é uma estratégia que se baseia na análise da
especificação de um programa para ajudar na seleção de casos de teste.
e) funções ou métodos individuais de um objeto não são exemplos de
estratégia da aplicação de teste de componentes.
13ª Questão) (ESAF – MPOG/ENAP – Analista de Sistemas - 2006) Na
Engenharia de Software, a atividade de Teste tem vários objetivos, entre os
quais não se encontra
a) projetar testes que descubram sistematicamente diferentes classes de
erros em um tempo e com um esforço mínimo.
b) executar um programa com o objetivo de descobrir um erro.
c) elaborar casos de teste que tem uma elevada probabilidade de revelar
um erro ainda não descoberto.
d) revelar um erro ainda não descoberto.
e) desenvolver um produto de software sem erros.
14ª Questão) (ESAF – MPOG/ENAP – Analista de Sistemas - 2006)
Analise as seguintes afirmações relacionadas às atividades de Teste de Software
na Engenharia de Software.
I. A Verificação refere-se a um conjunto de atividades que garante que o
software implemente corretamente uma função específica.
Prof. Victor Dalton
36 de 55
II. Os métodos de Engenharia de Software proporcionam a base a partir da
qual a qualidade é construída. Se a qualidade não estiver presente antes de se
testar um produto de software, ela não estará presente após a realização dos
testes.
III. A Verificação refere-se a um conjunto de atividades que garante que o
software que foi construído atenda às exigências do cliente.
IV. A Verificação visa garantir a resposta positiva da pergunta: “Estamos
construindo o produto certo?”.
Indique a opção que contenha todas as afirmações verdadeiras.
a) I e II
b) II e III
c) III e IV
d) I e III
e) II e IV
15ª Questão) (ESAF – MPOG – Analista de Planejamento e
Orçamento – Tecnologia da Informação - 2005) Analise as seguintes
afirmações relativas às estratégias de teste de software:
I. Teste é um conjunto de atividades
antecipadamente e realizado sistematicamente.
que
pode
ser
planejado
II. As atividades de teste e de depuração são atividades diferentes.
III. Na atividade de teste a atividade de depuração não necessita ser
considerada.
IV. Apenas uma técnica de teste é apropriada a um projeto, independente
do ponto do ciclo de vida em que se encontra o projeto.
Indique a opção que contenha todas as afirmações verdadeiras.
a) I e II
b) II e III
c) III e IV
d) I e III
e) II e IV
Prof. Victor Dalton
37 de 55
16ª Questão) (ESAF – MPOG – Analista de Planejamento e
Orçamento – Tecnologia da Informação - 2005) Analise as seguintes
afirmações relativas às atividades de teste de software:
I. O objetivo do processo Teste de Software é estabelecer e manter a
integridade dos produtos do projeto de software e executar o teste denominado
“Teste da caixa preta” ao longo de todo o ciclo de vida do projeto.
II. É de responsabilidade da equipe de Teste de Software realizar,
periodicamente, auditorias das configurações básicas para verificar se elas estão
de acordo com a documentação que as define.
III.Verificação de um software refere-se a um conjunto de atividades que
garante que o software implemente corretamente uma função específica.
IV.Validação de um software refere-se a um conjunto de atividades que
garante que o software que foi construído atende às expectativas do cliente.
Indique a opção que contenha todas as afirmações verdadeiras.
a) I e II
b) II e III
c) III e IV
d) I e III
e) II e IV
(CESPE – INCA – Analista em C&T Júnior – Gestão Pública - 2010)
Julgue os itens que se seguem, relativos à gestão de projetos.
17 O cliente, o patrocinador, a equipe do projeto e demais interessados,
conhecidos como stakeholders, são os responsáveis por determinar os requisitos
do projeto.
18 Caso um gerente de projeto constate que há um membro da equipe que
continuamente está prejudicando o trabalho, a solução correta a ser tomada
será a de retirar esse membro da equipe de trabalho.
19º Questão)(CESGRANRIO – Petrobrás – Técnico de Exploração de
Petróleo Júnior – Informática - 2011) A pessoa ou o grupo que fornece
recursos financeiros para realizar um projeto é o
a) cliente
Prof. Victor Dalton
38 de 55
b) usuário
c) patrocinador
d) gerente de portfólio
e) gerente de programas
20º Questão) (CESGRANRIO – Casa da Moeda do Brasil – Analista de
Nível Superior – Negócios em TI - 2009) No projeto de análise de
vulnerabilidades do ambiente Internet de uma empresa, João provê os recursos
financeiros necessários para o projeto. Segundo o PMBOK, João desempenha o
papel de
a) patrocinador.
b) analista financeiro.
c) gerente de projeto.
d) usuário final.
e) auditor.
21º Questão) (ESAF – STN – Analista de Finanças e Controle –
Governança e Gestão em TI - 2013) O desenvolvimento ágil de software
fundamenta-se no Manifesto Ágil. Segundo ele deve-se valorizar:
a) mudança de respostas em vez do seguimento de um plano.
b) indivíduos e interações em vez de processos e ferramentas.
c) documentação extensiva operacional em vez de software funcional.
d) indivíduos e intenções junto a processos e ferramentas.
e) seguimento de um plano em vez de resposta a mudança.
22º Questão) (FCC – Assembléia Legislativa do Estado de São Paulo –
Agente Técnico Legislativo – Tecnologia da Informação – 2010) São
consideradas metodologias ágeis de desenvolvimento de software:
a) XP e UP.
b) SCRUM e DSDM.
c) SCRUM e RUP.
Prof. Victor Dalton
39 de 55
d) DSDM e Cascata.
e) Cascata e PRINCE2.
GABARITO
1.e
11.d
21.b
2.a
12.b
22.b
3.d
13.e
4.c
14.a
5.a
15.a
6.e
16.c
7.c
17.c
8.c/e
18.c
9.a
19.c
10.a
20.a
Prof. Victor Dalton
40 de 55
EXERCÍCIOS COMENTADOS
1ª Questão) (ESAF – TCU - Analista de Controle Externo – Análise de
Sistemas - 2002) O paradigma do ciclo de vida clássico da engenharia de
software requer uma abordagem sistemática, sequencial ao desenvolvimento do
software, que se inicia no nível do sistema e avança ao longo da análise, projeto,
codificação, teste e manutenção. A etapa deste ciclo, que se apresenta como um
processo de múltiplos passos e se concentra em quatro atributos distintos do
programa: estrutura de dados, arquitetura de software, detalhes procedimentais
e caracterização da interface, é a atividade de
a) codificação.
b) análise de requisitos de software.
c) análise de sistemas.
d) engenharia de sistemas.
e) projeto.
Espero que não haja dúvidas nessa questão. A fase de análise é voltada
para o detalhamento dos requisitos, enquanto o projeto aprofunda esse nível de
detalhamento, orientado para a codificação do sistema. Suas quatro vertentes
são: projeto de dados/classes, projeto de componentes, projeto de arquitetura e
projeto de interface do usuário.
Resposta certa, alternativa e).
2ª Questão) (ESAF – MPOG – Analista de Planejamento e Orçamento
– Tecnologia da Informação – 2008) Em Modelagem Orientada a objetos,
objetos podem ser:
a) Entidades externas. Coisas. Ocorrências ou eventos. Papéis. Unidades
organizacionais. Lugares. Estruturas.
b) Entidades internas. Coisas. Chaves de ocorrências. Papéis. Unidades
organizacionais. Especialidades de estruturas.
c) Atividades externas. Capacidades. Ocorrências ou eventos. Posições.
Unidades organizacionais. Lugares. Unidades de entidades.
d) Entidades externas. Coisas. Ocorrências ou eventos. Pastas. Unidades de
recursos. Objetivos. Estruturas.
Prof. Victor Dalton
41 de 55
e) Entidades de referência. Situações. Ocorrências ou eventos. Papéis.
Diretrizes organizacionais. Lugares. Objetos inominados.
A ESAF, às vezes, enviesa para esse decoreba técnico, baseado em alguma
bibliografia. A pergunta fica rasa e superficial. Caso você se depare com uma
pergunta desse estilo, a melhor conduta é trabalhar por eliminação.
Intencionalmente, a banca coloca termos sem sentido para confundir o
candidato. “Chaves de ocorrências”, “Posições”, “Capacidades”, “Objetos
inonimados” são alguns desses termos. E a alternativa a), a correta, é cópia
literal da nossa bibliografia, o Pressman.
3ª Questão) (FCC – TST – Analista Judiciário – Análise de Sistemas –
2012) São características da análise estruturada e da análise orientada a
objetos, respectivamente:
a) a organização do código-fonte em pacotes e o uso de diagrama de
classes.
b) programas elaborados com o uso de funções e determinação do
dicionário de dados.
c) o uso de diagramas de sequência e o uso do diagrama de contexto.
d) a modelagem do fluxo de dados e a abstração de conceitos do mundo
real.
e) a técnica de encapsulamento e a extensão de classes com a aplicação de
herança.
A análise estruturada considera os dados e os processos que transformam
os dados em entidades separadas, destacando o fluxo dos dados pelo sistema.
A análise orientada a objetos, por sua vez, lança mão da abstração para
representar coisas do mundo real, sob a forma de objetos.
Resposta certa, alternativa d).
4ª Questão) (ESAF – Receita Federal – Analista – Informática –
2012) Assinale a opção correta relativa a diagrama de fluxo de dados (DFD).
a) Descreve graficamente o fluxo em depósitos de dados e as
transformações dos processos que interferem nas entradas a partir de entidades
externas.
Prof. Victor Dalton
42 de 55
b) Modela os objetos relativos a fluxo de informações e as categorias de
dados relevantes para as saídas.
c) Descreve graficamente o fluxo de informações e as transformações que
são aplicadas à medida que os dados se movimentam da entrada para a saída.
d) Descreve graficamente a estrutura das informações em que se
organizam os dados inerentes a processos.
e) Descreve graficamente o fluxo de dados transformados segundo
atributos das entidades externas.
O Diagrama de Fluxo de Dados (DFD) descreve o fluxo de informação e
transformações que são aplicadas à medida que os dados se movimentam da
entrada para a saída.
Resposta certa, alternativa c).
5ª Questão) (ESAF – SEFAZ/CE – Analista de Tecnologia da
Informação – 2006 - adaptada) Analise a descrição a seguir.
O paradigma do ciclo de vida clássico da engenharia de software abrange
seis atividades. Na atividade de _____________ são traduzidas as exigências de
uma representação do software que podem ser avaliadas quanto à qualidade
antes que se inicie a codificação.
Escolha a opção que preenche corretamente a lacuna acima.
a) projeto
b) levantamento de requisitos
c) teste
d) implantação
e) análise
Guarde essa ideia: na atividade de projeto são traduzidas as exigências de
uma representação do software que podem ser avaliadas quanto à qualidade,
antes que se inicie a codificação.
Resposta certa, alternativa a).
Prof. Victor Dalton
43 de 55
6ª Questão) (CESPE – CNJ – Analista Judiciário – Análise de Sistemas
– 2013) No ciclo de vida de software, a estrutura de dados, a arquitetura, os
detalhes procedimentais e a caracterização da interface são atributos da etapa
de análise e engenharia de software.
Errado. Esta é a fase de projeto.
7ª Questão) (CESPE – Banco da Amazônia – Técnico Científico –
Análise de Sistemas – 2012) O projeto foca na solução, consistindo em
atividades de criação de um produto, enquanto a análise focaliza o problema. Na
análise orientada a objetos, descrevem-se objetos ou conceitos como livros e
usuários, que possuem atributos e responsabilidades.
Correto!
8ª Questão) (CESPE – INPI – Analista – Desenvolvimento e
Manutenção de Sistemas – 2012) A documentação da arquitetura de
software de sistema facilita a comunicação entre os participantes do
desenvolvimento do sistema. A respeito das práticas de arquitetura de software,
julgue os itens a seguir.
1 A refatoração objetiva tornar o código mais claro e limpo.
2 Ao refatorar um código, altera-se a funcionalidade do sistema.
Analisando:
1 – Correto. A refatoração procura tornar o código mais claro e limpo,
também eliminando redundâncias e tornando o código mais eficiente.
2 – Errado! Mesmo otimizando o código, a funcionalidade do sistema não
deve ser modificada.
9ª Questão) (ESAF – SEFAZ/CE – Analista de Tecnologia da
Informação - 2006) Na engenharia de software, o objetivo do processo de
Teste de Software é
Prof. Victor Dalton
44 de 55
a) encontrar defeitos.
b) corrigir apenas os defeitos de alta criticidade.
c) executar apenas os testes de caixa preta.
d) demonstrar o correto funcionamento do software.
e) provar que o software está 100% isento de defeitos.
Como já foi falado, o Teste de Software difere um pouco do conceito
“convencional” de teste. Normalmente testamos as coisas para verificar que elas
realmente funcionam; em software, testamos o software para encontrar
defeitos.
Resposta certa, alternativa a).
10ª Questão) (ESAF – Receita Federal - Técnico – Tecnologia da
Informação - 2006) Analise as seguintes afirmações relacionadas a Teste de
Software:
I. O teste “caixa-preta” e o teste “caixa-branca” são os únicos tipos de
testes possíveis quando não se dispõe do código-fonte.
II. O teste “caixa-preta”, também chamado “teste funcional”, testa o
sistema do ponto de vista do usuário, isto é, não considera a estrutura interna
ou a forma de implementação do sistema.
III. Ao adotar uma abordagem “top-down”, o executor de teste deve
concentrar-se inicialmente no teste “caixa-branca”, que parte de uma visão
externa do sistema.
IV. O teste “caixa-branca” procura exercitar todas as partes do código de
um sistema.
Indique a opção que contenha todas as afirmações verdadeiras.
a) II e IV
b) II e III
c) III e IV
d) I e III
Prof. Victor Dalton
45 de 55
e) I e II
Analisando as alternativas:
I.
Errada. O teste caixa-branca precisa do código-fonte para ser
testado, pois analisa os componentes internos do software. Apenas o
teste caixa-preta pode ser realizado sem o código-fonte, pois apenas
são analisadas as reações do sistema.
II.
Correto.
III.
Errado. A pegadinha está em “visão externa”. Além disso, tanto nas
abordagens top-down como bottom-up, em testes de integração, a
técnica caixa-branca é a mais apropriada.
IV.
Correto.
Resposta certa, alternativa a).
11ª Questão) (ESAF – Prefeitura de Natal – Auditor do Tesouro
Municipal – Informática - 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.
O Teste Funcional é o teste “caixa-preta”, ou seja, analisa o sistema apenas
por fora, verificando se o seu comportamento corresponde aos requisitos
previamente acordados.
Logo, não cabe outra alternativa que não seja a alternativa d). A
propósito, a alternativa e) trata de testes de esforço.
Prof. Victor Dalton
46 de 55
12ª Questão) (ESAF – MPOG – Analista de Planejamento e
Orçamento – Tecnologia da Informação - 2008) Uma estratégia de teste de
software integra métodos de projeto de casos de teste em uma série planejada
de passos. Em relação a estratégias de testes, é correto afirmar que:
a) realizar testes para mostrar que não existem defeitos no software faz
parte das estratégias de testes.
b) demonstrar ao desenvolvedor e ao cliente que o software atende aos
requisitos é uma meta de validação do software.
c) o particionamento de equivalência é uma maneira estratégica de aplicar
testes de software.
d) o teste estrutural é uma estratégia que se baseia na análise da
especificação de um programa para ajudar na seleção de casos de teste.
e) funções ou métodos individuais de um objeto não são exemplos de
estratégia da aplicação de teste de componentes.
Quanto às estratégias de teste, lembremos que existe o teste de unidade,
teste de integração, teste de validação e teste de sistema.
A alternativa a) está errada, porque já sabemos que os testes existem para
encontrar defeitos;
O particionamento de equivalência é uma variação dos testes caixa-preta, e
o teste estrutural é o teste “caixa-branca”. Ambos são técnicas de teste e não
estratégias de teste, o que tornam as alternativas c) e d) incorretas;
Na alternativa e), fala-se em teste de componentes (teste de unidade).
Funções ou métodos individuais de um objeto são utilizados para testar os
mesmos, o que também torna a alternativa e) incorreta;
A alternativa b) está correta, pois os testes de validação servem
justamente para mostrar ao cliente que o sistema faz o que ele pediu.
13ª Questão) (ESAF – MPOG/ENAP – Analista de Sistemas - 2006) Na
Engenharia de Software, a atividade de Teste tem vários objetivos, entre os
quais não se encontra
a) projetar testes que descubram sistematicamente diferentes classes de
erros em um tempo e com um esforço mínimo.
b) executar um programa com o objetivo de descobrir um erro.
Prof. Victor Dalton
47 de 55
c) elaborar casos de teste que tem uma elevada probabilidade de revelar
um erro ainda não descoberto.
d) revelar um erro ainda não descoberto.
e) desenvolver um produto de software sem erros.
Não é objetivo da atividade de Teste desenvolver um produto sem erros. O
objetivo dos testes é encontrar defeitos. Em uma visão macro, o objetivo dos
testes é confirmar a qualidade do desenvolvimento do software. Nem mesmo o
objetivo da Engenharia de Software é desenvolver um produto sem erros. A ES
serve para fornecer métodos, princípios e ferramentas para produzir um
software com alta qualidade. Isso não implica em erro zero.
Alternativa errada, letra e).
14ª Questão) (ESAF – MPOG/ENAP – Analista de Sistemas - 2006)
Analise as seguintes afirmações relacionadas às atividades de Teste de Software
na Engenharia de Software.
I. A Verificação refere-se a um conjunto de atividades que garante que o
software implemente corretamente uma função específica.
II. Os métodos de Engenharia de Software proporcionam a base a partir da
qual a qualidade é construída. Se a qualidade não estiver presente antes de se
testar um produto de software, ela não estará presente após a realização dos
testes.
III. A Verificação refere-se a um conjunto de atividades que garante que o
software que foi construído atenda às exigências do cliente.
IV. A Verificação visa garantir a resposta positiva da pergunta: “Estamos
construindo o produto certo?”.
Indique a opção que contenha todas as afirmações verdadeiras.
a) I e II
b) II e III
c) III e IV
d) I e III
e) II e IV
Prof. Victor Dalton
48 de 55
Todas as sentenças acima estariam corretas, se os conceitos de Verificação
e Validação não estivessem trocados!
Resposta certa, alternativa a).
15ª Questão) (ESAF – MPOG – Analista de Planejamento e
Orçamento – Tecnologia da Informação - 2005) Analise as seguintes
afirmações relativas às estratégias de teste de software:
I. Teste é um conjunto de atividades
antecipadamente e realizado sistematicamente.
que
pode
ser
planejado
II. As atividades de teste e de depuração são atividades diferentes.
III. Na atividade de teste a atividade de depuração não necessita ser
considerada.
IV. Apenas uma técnica de teste é apropriada a um projeto, independente
do ponto do ciclo de vida em que se encontra o projeto.
Indique a opção que contenha todas as afirmações verdadeiras.
a) I e II
b) II e III
c) III e IV
d) I e III
e) II e IV
Analisando as alternativas:
I.
Correto. Toda metodologia de desenvolvimento
inclusive, preconiza o teste ao longo de seu ciclo.
de
software,
II.
Correto. Testar é buscar erros; Depurar é analisar o código para
saber corrigi-lo.
III.
Errado. A depuração será consequência de testes bem sucedidos, ou
seja, quando erros forem encontrados.
IV.
Errado. Testes caixa-branca serão mais apropriados na fase de
implementação de um projeto, enquanto testes caixa-preta serão
mais adequados em etapas mais próximas do usuário final, como
testes e implantação. Além disso, nada impede a realização
combinada das diferentes técnicas de teste.
Prof. Victor Dalton
49 de 55
Resposta certa, alternativa a).
16ª Questão) (ESAF – MPOG – Analista de Planejamento e
Orçamento – Tecnologia da Informação - 2005) Analise as seguintes
afirmações relativas às atividades de teste de software:
I. O objetivo do processo Teste de Software é estabelecer e manter a
integridade dos produtos do projeto de software e executar o teste denominado
“Teste da caixa preta” ao longo de todo o ciclo de vida do projeto.
II. É de responsabilidade da equipe de Teste de Software realizar,
periodicamente, auditorias das configurações básicas para verificar se elas estão
de acordo com a documentação que as define.
III.Verificação de um software refere-se a um conjunto de atividades que
garante que o software implemente corretamente uma função específica.
IV.Validação de um software refere-se a um conjunto de atividades que
garante que o software que foi construído atende às expectativas do cliente.
Indique a opção que contenha todas as afirmações verdadeiras.
a) I e II
b) II e III
c) III e IV
d) I e III
e) II e IV
Analisando:
I.
Errado. O objetivo do processo Teste de Software é encontrar
defeitos no mesmo.
II.
Errado. Essa é uma responsabilidade do gerente do projeto e dos
analistas de requisitos.
III e IV. Descritos corretamente.
Resposta certa, alternativa c).
Prof. Victor Dalton
50 de 55
(CESPE – INCA – Analista em C&T Júnior – Gestão Pública - 2010)
Julgue os itens que se seguem, relativos à gestão de projetos.
17 O cliente, o patrocinador, a equipe do projeto e demais interessados,
conhecidos como stakeholders, são os responsáveis por determinar os requisitos
do projeto.
18 Caso um gerente de projeto constate que há um membro da equipe que
continuamente está prejudicando o trabalho, a solução correta a ser tomada
será a de retirar esse membro da equipe de trabalho.
Analisando:
17 – Correto. Todos os interessados no projeto devem participar da
elaboração dos requisitos do sistema.
18 – Correto. O Gerente de projeto é o responsável por gerenciar sua
equipe, podendo modificar membros se assim julgar necessário.
19º Questão)(CESGRANRIO – Petrobrás – Técnico de Exploração de
Petróleo Júnior – Informática - 2011) A pessoa ou o grupo que fornece
recursos financeiros para realizar um projeto é o
a) cliente
b) usuário
c) patrocinador
d) gerente de portfólio
e) gerente de programas
Isso não é dúvida para você, não é mesmo?
Alternativa c).
20º Questão) (CESGRANRIO – Casa da Moeda do Brasil – Analista de
Nível Superior – Negócios em TI - 2009) No projeto de análise de
vulnerabilidades do ambiente Internet de uma empresa, João provê os recursos
financeiros necessários para o projeto. Segundo o PMBOK, João desempenha o
papel de
Prof. Victor Dalton
51 de 55
a) patrocinador.
b) analista financeiro.
c) gerente de projeto.
d) usuário final.
e) auditor.
Idem. Alternativa a).
21º Questão) (ESAF – STN – Analista de Finanças e Controle –
Governança e Gestão em TI - 2013) O desenvolvimento ágil de software
fundamenta-se no Manifesto Ágil. Segundo ele deve-se valorizar:
a) mudança de respostas em vez do seguimento de um plano.
b) indivíduos e interações em vez de processos e ferramentas.
c) documentação extensiva operacional em vez de software funcional.
d) indivíduos e intenções junto a processos e ferramentas.
e) seguimento de um plano em vez de resposta a mudança.
Analisando as alternativas:
a) Responder a mudanças em vez de seguir um plano. Errada;
b) Correta;
c) Software funcional, em vez de documentação extensiva. Errada;
d) Indivíduos e interações, em vez de processos e ferramentas.
Errada;
e) Responder mudanças, em vez de seguir um plano. Errada;
22º Questão) (FCC – Assembléia Legislativa do Estado de São Paulo –
Agente Técnico Legislativo – Tecnologia da Informação – 2010) São
consideradas metodologias ágeis de desenvolvimento de software:
a) XP e UP.
b) SCRUM e DSDM.
c) SCRUM e RUP.
Prof. Victor Dalton
52 de 55
d) DSDM e Cascata.
e) Cascata e PRINCE2.
A solução, nitidamente, é trabalhar por eliminação.
UP e RUP não variações de uma metodologia que não é ágil (Processo
Unificado), e você descarta alternativas a) e c).
Cascata passa MUITO LONGE de ser ágil, e você descarta alternativas d) e
e).
XP e Scrum você conhece bem, mas DSDM realmente é mais difícil de
lembrar. Eu não exigiria que você memorizasse Método de Desenvolvimento de
Sistemas Dinâmicos, que realmente é uma metodologia de pouco destaque,
mas, por eliminação, você marcaria a alternativa b) com segurança.
Prof. Victor Dalton
53 de 55
SIMULADO
1º Questão) “Nas primeiras iterações, a versão do software pode ser um
modelo ou um protótipo. Nas iterações posteriores, são produzidas versões cada
vez mais completas do sistema”. Esta estratégia de desenvolvimento de
software refere-se aos modelo
a) cascata.
b) espiral.
c) de prototipação.
d) ágil.
e) incremental.
2º Questão) O ciclo de vida clássico prevê que o software é desenvolvido
ao longo de etapas claras e bem definidas. A etapa na qual o software é
submetido a testes de unidade é chamada de:
a) análise.
b) implantação.
c) implementação.
d) testes.
e) engenharia de requisitos.
3º Questão) São etapas da Engenharia de Requisitos:
a) Estudo de requisitos. Licitação e análise. Formalização. Priorização.
Rastreabilidade.
b) Estudo
Implantação.
de
requisitos.
Análise.
Projeto.
Implementação.
Testes.
c) Estudo de viabilidade. Análise. Projeto. Negociação. Valorização de
requisitos.
d) Análise de viabilidade. Priorização e Negociação. Documentação. Estudo.
Gerenciamento.
e) Estudo de viabilidade. Elicitação e análise. Especificação. Validação.
Gerenciamento.
Prof. Victor Dalton
54 de 55
4º Questão) Na fase de projeto
a) Determina-se o como o sistema funcionará para atender aos requisitos.
b) O foco principal são os aspectos
implementação de um sistema.
lógicos
e
independentes
de
c) Ocorre a tradução da descrição computacional obtida na fase de projeto
em código executável.
d) O sistema é empacotado, distribuído e instalado no ambiente do
usuário.
e) Erros são descobertos no sistema.
5º Questão) Em relação a Testes de Software, é incorreto afirmar que:
a) teste é um conjunto de atividades
antecipadamente e realizado sistematicamente.
que
pode
ser
planejado
b) a Verificação visa garantir a resposta positiva da pergunta: “Estamos
construindo o produto certo?”.
c) quando um teste revela um erro ainda não descoberto, o teste é mal
sucedido.
d) demonstrar ao desenvolvedor e ao cliente que o software atende aos
requisitos é uma meta de validação do software.
e) encontrar defeitos é o objetivo dos Testes de Software.
6º Questão) É responsabilidade do analista de requisitos:
a) designar um gerente para o projeto de software.
b) coordenar as atividades necessárias para a construção do sistema.
c) ter conhecimento do domínio do negócio.
d) gerar a especificação de uma solução computacional detalhada.
e) manutenir o sistema após a sua entrega.
GABARITO DO SIMULADO
1.b
2.c
3.e
4.a
5.c
6.c
Prof. Victor Dalton
55 de 55