Engenharia software

Prévia do material em texto

EngElet ESwDOnLineSisDigIV 1/106 
 
 
 
 
Engenharia de Software 
(Sistemas Digitais IV) 
 
Material de Referência Básico e Exercícios 
(a ser complementado pelos 
artigos e bibliografia indicada) 
EngElet ESwDOnLineSisDigIV Sumário 2/106 
Sumário 
Sumário ....................................................................................................................................................................................... 2 
Apresentação (EE) ....................................................................................................................................................................... 3 
Mod I: Engenharia de requisitos ................................................................................................................................................. 5 
Exercícios (13) ......................................................................................................................................................................... 5 
Mod II: Qualidade de software ................................................................................................................................................. 12 
Exercícios (13) ....................................................................................................................................................................... 12 
Módulo III: Gestão de configuração de software ..................................................................................................................... 20 
Exercícios (13) ....................................................................................................................................................................... 20 
Módulo IV: Gestão de riscos de software ................................................................................................................................. 27 
Exercícios (13) ....................................................................................................................................................................... 27 
Mod V: Metodologias de desenvolvimento ............................................................................................................................. 34 
Exercícios (17) ....................................................................................................................................................................... 34 
Módulo VI: Métricas ................................................................................................................................................................. 43 
Exercícios (8) ......................................................................................................................................................................... 43 
Módulo VII: Testes .................................................................................................................................................................... 48 
Exercícios (8) ......................................................................................................................................................................... 48 
Módulo VIII: Componentização e reuso ................................................................................................................................... 52 
Exercícios (8) ......................................................................................................................................................................... 52 
Módulo – Provas ....................................................................................................................................................................... 56 
Exercícios (20) ....................................................................................................................................................................... 56 
Módulo Complementar I .......................................................................................................................................................... 66 
Exercícios (8) ......................................................................................................................................................................... 66 
Módulo Complementar II ......................................................................................................................................................... 71 
Exercícios (8) ......................................................................................................................................................................... 71 
Módulo Complementar III ........................................................................................................................................................ 75 
Exercícios (8) ......................................................................................................................................................................... 75 
Módulo Complementar IV ........................................................................................................................................................ 79 
Exercícios (8) ......................................................................................................................................................................... 79 
Módulo Complementar V ......................................................................................................................................................... 83 
Exercícios (8) ......................................................................................................................................................................... 83 
Módulo Complementar VI ........................................................................................................................................................ 88 
Exercícios (8) ......................................................................................................................................................................... 88 
Módulo Complementar VII ....................................................................................................................................................... 92 
Exercícios (8) ......................................................................................................................................................................... 92 
Módulo Complementar VIII ...................................................................................................................................................... 96 
Exercícios (8) ......................................................................................................................................................................... 96 
Estudos Disciplinares .............................................................................................................................................................. 101 
Exercícios (10) ..................................................................................................................................................................... 101 
EngElet ESwDOnLineSisDigIV Apresentação (EE) 3/106 
 
Apresentação (EE) 
CURSO: Engenharia Elétrica / Eletrônica 
SÉRIE: 8º e 9º semestres 
DISCIPLINA: Engenharia de Software 
I - EMENTA 
Conceituação de Engenharia de Software. Caracterização da Crise do Software. Adoção dos modelos 
iterativos e incrementais, foco no gerenciamento de projetos de software. Processo e Produto de 
Software. 
II – OBJETIVOS GERAIS 
 Propiciar ao aluno contato com os paradigmas, modelos e normas de qualidade da área da 
Engenharia de Software. 
III – OBJETIVOS ESPECÍFICOS 
 Apresentar os métodos, procedimentos e ferramentas para a construção de software com 
qualidade. 
IV – CONTEÚDO PROGRAMÁTICO 
Módulo 01: Introdução(A) e Engenharia de Requisitos (B) 
A) Definição / Crise do Software / Modelos, Processo e Produto / Coesão e Acoplamento; 
B) Conceitos / Importância / Processo / Ergonomia Cognitiva; 
 Módulo 02: ISO/IEC 12.207 
 Conceitos / ISO/IEC 12.207 / Contexto Brasileiro; 
 Módulo 03: Gerência de Configuração e Mudança de Software 
 Definições / Modelo / IEEE / ISO / Ferramentas; 
 Módulo 04: Gestão de Riscos 
 Definições / Processo / Framework; 
 Módulo 05:Metodologia de Desenvolvimento 
 Sistemas de Informação para Internet: Requisitos e Modelos; 
 JAD - Joint Application Design: Conceito / Princípios e Práticas; 
 RUP - Processo Unificado: Definições / Processo / Atividades / Iterativo e Incremental; 
EngElet ESwDOnLineSisDigIV Apresentação (EE) 4/106 
 Módulo 06: Métricas de Software – FPA (A) e UCP (B) 
 A) APF – Análise de Ponto de Função: Conceitos e Aplicação; 
 B) UCP – Pontos por Caso de Uso: Conceitos e Aplicação; 
 Módulo 07: Testes de Software 
 Caixas Branca e Preta / Unitário / Integração / Aceitação e Regressão; 
 Módulo 08: Componentização 
 Engenharia de Software Baseada em Componentes – Reusabilidade; 
 V – AVALIAÇÃO 
Módulos de 01 á 04 - Conteúdo para a P1; 
Módulos de 05 á 08 - Conteúdo para a P2; 
Módulos de 01 á 08 - Conteúdo para a SUB;e 
Módulos de 01 á 08 - Conteúdo para o EXAME. 
VI – BIBLIOGRAFIA 
Básica 
NOGUEIRA, Marcelo - Engenharia de Software: um Framework – 2009 - Ciência Moderna. 
PRESSMAN, R. S. Engenharia de Software. São Paulo. Makron Books, 2006. 
SOMMERVILLE, Ian. Engenharia de Software - Ed. Prentice Hall, 2007. 
Complementar 
MAGELA, Rogério - Engenharia de Software Aplicada – Ed. Alta Books, 2006. 
PAULA FILHO, Wilson de Pádua - Engenharia de Software – Ed. LTC, 2009. 
PFLEEGER, Shari Lawrence. - Engenharia de Software - Ed. Prentice Hall Brasil, 2004. 
ENGHOLM JUNIOR, Hélio. Engenharia de Software na Prática. Ed. Novatec, 2010. 
SCHACH, Stephenr. Engenharia de Software. Ed. Mcgraw Hill – Artmed, 2008. 
EngElet ESwDOnLineSisDigIV Mod I: Engenharia de requisitos 5/106 
Mod I: Engenharia de requisitos 
A engenharia de requisitos fornece um mecanismo adequado para entender o que o cliente 
deseja, analisar as necessidades, avaliar a exeqüibilidade, negociar uma solução razoável, 
especificar a solução de maneira não-ambígua, validar a especificação e administrar os 
requisitos à medida que eles são transformados num sistema em operação. O processo da 
engenharia de requisitos pode ser descrito em seis passos distintos [PRESSMAN02]: 
 Elicitação de requisitos 
 Análise e negociação de requisitos 
 Especificação de requisitos 
 Modelagem do sistema 
 Validação de requisitos 
 Gestão de requisitos 
 Veja o material completo em: Engenharia de requisitos É o arquivo: paper_01_ER.pdf 
Exercícios (13) 
Exercício 1 
Assinale a função correta de engenharia de requisitos: 
A) 
Determinar o objetivo geral do sistema. 
B) 
Definir um amplo conjunto de conceitos, princípios, métodos e ferramentas que se pode considerar à medida que 
o software é planejado e desenvolvido. 
C) 
Ajudar os engenheiros de software a compreender melhor o problema que eles vão trabalhar para resolver. 
- (CORRETA) 
D) 
Usar uma combinação de formas textuais e diagramáticas para mostrar os requisitos de dados, função e 
comportamento. 
E) 
Especificar o conjunto de áreas que farão parte do projeto. 
Exercício 2 
No processo de desenvolvimento de um sistema de controle de materiais (matérias-primas) para uma metalúrgica, a 
equipe de projeto, responsável pelo mapeamento dos requisitos, desenvolveu seus trabalhos seguindo os quatro 
subprocessos da engenharia de requisitos. Inicialmente, foram feitas a análise e a avaliação para se verificar se o sistema 
seria útil ao negócio. Em um segundo momento, os requisitos foram identificados e analisados e, logo em seguida, foram 
documentados. 
Finalmente, foi verificado se os requisitos identificados atendiam às demandas dos usuários. Tendo sido executado esse 
procedimento, uma empresa independente de auditoria, após análise, identificou dois problemas no processo: a 
documentação dos requisitos (formulários e padrões utilizados) estava inadequada e não possibilitava o entendimento 
correto dos requisitos; o processo de checagem entre as demandas dos usuários e as especificações relatadas não foi bem 
conduzido e seus resultados eram insatisfatórios. 
Considerando o relatório da auditoria independente, quais foram as duas fases do processo de engenharia de requisitos 
que apresentaram problemas? 
EngElet ESwDOnLineSisDigIV Mod I: Engenharia de requisitos 6/106 
A) 
Entendimento do domínio e especificação. 
B) 
Elicitação e validação. 
C) 
Validação e entendimento do domínio. 
D) 
Especificação e validação. 
- (CORRETA) 
E) 
Validação e elicitação. 
Exercício 3 
Requisitos de um sistema são freqüentemente classificados como funcionais, não-funcionais e de domínio. Qual a definição 
que melhor descreve requisitos não-funcionais? 
A) 
São ferramentas automatizadas de apoio ao processo de desenvolvimento de sistemas. 
B) 
São requisitos que descrevem o que o sistema deve fazer, como deve reagir a determinadas entradas e como deve 
comportar-se em situações particulares. 
C) 
São requisitos que derivam do domínio da aplicação e que refletem características e restrições desse domínio. 
D) 
São requisitos que não estão diretamente relacionados com as funções específicas do sistema. 
- (CORRETA) 
E) 
São requisitos que especificam como deve ser testada uma parte do sistema, incluindo-se as entradas, os resultados 
esperados e as condições sob as quais os testes devem ocorrer. 
Exercício 4 
Requisitos são capacidades e condições para as quais um sistema deve ter conformidade. 
Analise as afirmações a seguir: 
(I) No Processo Unificado, requisitos são categorizados de acordo com o modelo FURPS+, onde o U do acrônimo representa 
requisitos de usabilidade. 
(II) Casos de uso são documentos em forma de texto, não diagramas, e modelagem de casos de uso é basicamente um 
ato de escrever estórias de uso de um sistema. 
(III) UML (Unified Modeling Language) provê notação para se construir o diagrama de casos de uso, que ilustra os nomes 
dos casos de uso, atores e seus relacionamentos. 
Considerando-se as três afirmações (I), (II) e (III) acima, identifique a única alternativa válida: 
A) 
Somente as afirmações (I) e (II) estão corretas. 
B) 
Somente as afirmações (II) e (III) estão corretas. 
C) 
Somente as afirmações (I) e (III) estão corretas. 
EngElet ESwDOnLineSisDigIV Mod I: Engenharia de requisitos 7/106 
D) 
As afirmações (I), (II) e (III) estão corretas. 
- (CORRETA) 
E) 
Somente a afirmação (III) está correta. 
Exercício 5 
Considere as afirmativas abaixo: 
 
I. Requisitos não-funcionais não são mensuráveis. 
II. Requisitos funcionais descrevem as funções que o software deverá executar. 
III. Requisitos não-funcionais expressam condições que o software deve atender ou qualidades específicas que o software 
deve ter. 
Assinale a alternativa CORRETA: 
 
A) 
Somente as afirmativas I e II são verdadeiras. 
B) 
Somente as afirmativas II e III são verdadeiras. 
- (CORRETA) 
C) 
Somente a afirmativa III é verdadeira. 
D) 
As afirmativas I, II e III são falsas. 
E) 
Todas as afirmativas são verdadeiras. 
Exercício 6 
A Engenharia de Requisitos é um processo que envolve todas as atividades exigidas para criar e manter o documento de 
requisitos de sistema. 
Sobre a Engenharia de Requisitos, considere as afirmativas a seguir. 
I. A Engenharia de Requisitos, como todas as outras atividades de Engenharia de Software, precisa ser adaptada às 
necessidades do processo, do projeto, do produto e do pessoal que está fazendo o trabalho. 
II. No estágio de levantamento e análise dos requisitos, os membros da equipe técnica de desenvolvimento do software 
trabalham com o cliente e os usuários finais dosistema para descobrir mais informações sobre o domínio da aplicação, 
que serviços o sistema deve oferecer, o desempenho exigido do sistema, as restrições de hardware, entre outras 
informações. 
III. Na medida em que a informação de vários pontos de vista é coletada, os requisitos emergentes são consistentes. 
IV. A validação de requisitos se ocupa de mostrar que estes realmente definem o sistema que o cliente deseja. Ela é 
importante porque a ocorrência de erros em um documento de requisitos pode levar a grandes custos relacionados ao 
retrabalho. 
Assinale a alternativa correta: 
A) 
Somente as afirmativas I e II são corretas. 
B) 
Somente as afirmativas I e III são corretas. 
C) 
EngElet ESwDOnLineSisDigIV Mod I: Engenharia de requisitos 8/106 
Somente as afirmativas III e IV são corretas. 
D) 
Somente as afirmativas I, II e IV são corretas. 
- (CORRETA) 
E) 
Somente as afirmativas II, III e IV são corretas. 
Exercício 7 
Assinale a alternativa falsa 
A) 
Tradicionalmente, os requisitos de software são separados em requisitos funcionais e não-funcionais. Os requisitos 
funcionais são a descrição das diversas funções que clientes e usuários querem ou precisam que o software ofereça. 
Eles definem a funcionalidade desejada do software. 
B) 
O termo função é usado no sentido genérico de operação que pode ser realizada pelo sistema, seja através comandos 
dos usuários ou seja pela ocorrência de eventos internos ou externos ao sistema 
C) 
A especificação de um requisito funcional deve determinar o que se espera que o software faça, sem a preocupação de 
como ele faz. É importante diferenciar a atividade de especificar requisitos da atividade de especificação que ocorre 
durante o design do software. 
D) 
No design do software deve-se tomar a decisão de quais a funções o sistema efetivamente terá para satisfazer àquilo 
que os usuários querem. 
E) 
Requisitos não-funcionais são as qualidades globais de um software, como manutenibilidade, usabilidade, desempenho, 
custos e várias outras. Normalmente estes requisitos são descritos de maneira informal, de maneira controversa e são 
fáceis de validar. 
- (CORRETA) 
Exercício 8 
Assinale a alternativa falsa 
A) 
A análise e a especificação de requisitos de software são atividades para determinar os objetivos de um software e as 
restrições associadas a ele, bem como elaborar a especificação precisa do software. 
B) 
Estas atividades devem ser vistas como parte da análise de sistemas. Normalmente, elas são iniciadas separadamente 
da análise do sistema, podendo se estender após a elaboração do documento de especificação do sistema, quando serão 
refinados os requisitos do software. 
- (CORRETA) 
C) 
Análise e especificação são atividades inter-dependentes e devem ser realizadas conjuntamente. A análise é o processo 
de observação, classificação e modelagem dos elementos do domínio. 
D) 
EngElet ESwDOnLineSisDigIV Mod I: Engenharia de requisitos 9/106 
A especificação é a descrição sistemática e abstrata do que o software deve fazer, a partir daquilo que foi analisado. Ela 
apresenta a solução de como os problemas levantados na análise serão resolvidos pelo software do sistema 
computacional. Visa descrever de maneira sistemática quais as propriedades funcionais são necessárias para resolver o 
problema do domínio. 
E) 
A especificação é também a forma de comunicação sistemática com os arquitetos, programadores e testadores do 
software. 
Exercício 9 
Assinale a alternativa falsa 
A) 
 
A Análise de Requisitos ou Engenharia de Requisitos é um aspecto importante no Gerenciamento de Projetos, é a 
responsável por coletar dados indispensáveis, necessários, exigências de que o usuário necessite para solucionar um 
problema e alcançar seus objetivos. 
B) 
A análise de requisitos é um processo que envolve o estudo das necessidades do usuário para se encontrar uma 
definição correta ou completa do sistema ou requisito de software. 
C) 
A análise de requisitos é vital para o desenvolvimento do sistema, ela vai determinar o sucesso ou o fracasso do 
projeto. 
D) 
Os requisitos colhidos devem ser quantitativos, detalhados e irrelevantes para o projeto. 
- (CORRETA) 
E) 
Os requisitos fornecerão a referência para validar o produto final, estabelecerão o acordo entre cliente e fornecedor 
sobre o que e o software fará e consequentemente reduzirão os custos de desenvolvimento, pois requisitos mal 
definidos implicam num retrabalho. 
Exercício 10 
Assinale a alternativa falsa 
A) 
Em um projeto de software o Levantamento de Requisito é a etapa onde ocorre a busca do entendimento, 
documentação, conhecimento do fluxo de trabalho e detalhamento de todos os objetivos que buscam ser alcançados. 
B) 
Uma grande quantidade de conhecimento técnico por parte do cliente é utilizada, e todo requisito captado é armazenado 
para ser utilizado em todas as fases do desenvolvimento. 
C) 
Apesar das inovações advindas da Engenharia de Software, grandes projetos de desenvolvimento continuam sendo 
abandonados no meio do caminho, e os índices de fracasso continuam a assolar grandes companhias de 
desenvolvimento. Muitos desses fracassos ocorrem devido a falhas nos processos seguidos pelas instituições e da pouca 
importância dada à fase de análise. 
D) 
EngElet ESwDOnLineSisDigIV Mod I: Engenharia de requisitos 10/106 
A comunicação constitui-se em um dos grandes desafios da engenharia de software, caracterizando-se pela dificuldade 
em conseguir compreender um conjunto de conceitos vagos, abstratos e difusos que representam as necessidades e os 
desejos dos clientes e transformá-los em conceitos concretos e inteligíveis 
E) 
A especificação do requisito tem pouca importância na fase de análise de um sistema. Um requisito mal levantado pode 
causar impactos desastrosos, atrasos e muito retrabalho 
- (CORRETA) 
Exercício 11 
 
Assinale a alternativa falsa 
A) 
Em engenharia de software, requisitos funcionais são os requisitos relacionados ao uso da aplicação em termos de 
desempenho, usabilidade, confiabilidade, segurança, disponibilidade 
- (CORRETA) 
B) 
Uma função é descrita como um conjunto de entradas, seu comportamento e as saídas. 
C) 
Os requisitos funcionais podem ser cálculos, detalhes técnicos, manipulação de dados e de processamento e outras 
funcionalidades específicas que definem o que um sistema, idealmente, será capaz de realizar. 
D) 
Requisitos comportamentais, que descrevem todos os casos em que o sistema utiliza os requisitos funcionais, são 
extraídos dos casos de uso. 
E) 
O plano para a implementação dos requisitos funcionais é detalhado no projeto do sistema. Já o plano para a 
implementação de requisitos não funcionais é detalhado na arquitetura do sistema. 
Exercício 12 
Assinale a alternativa falsa 
A) 
Tal como definido na engenharia de requisitos, os requisitos funcionais especificam resultados particulares de um 
sistema. Isto deve ser contrastado com requisitos não-funcionais, os quais especificam características gerais, tais como 
custo e confiabilidade. 
B) 
Os requisitos funcionais denotam a arquitetura técnica de um sistema, enquanto os requisitos não funcionais fazem 
parte da arquitetura do aplicativo de um sistema. 
- (CORRETA) 
C) 
Em alguns casos, um analista de requisitos gera casos de uso após a coleta e validação de um conjunto de requisitos 
funcionais. 
D) 
Cada caso de uso ilustra cenários de comportamento através de um ou mais requisitos funcionais. 
EngElet ESwDOnLineSisDigIV Mod I: Engenharia de requisitos 11/106 
E) 
Muitas vezes, um analista começará por evocar um conjunto de casos de uso, a partir do qual o analista pode derivar os 
requisitos funcionais, que devem ser implementados para permitir que um usuário possa realizar cada caso de uso. 
Exercício 13 
Assinale a alternativa falsa 
A) 
A validação de requisitos é um processo da Engenharia de Requisito que trata, tal como o seu nome indica, da validação 
quanto à consistência,precisão, contextualização de requisitos levantados no processo de identificação e descoberta e 
de análise e negociação de requisitos. 
B) 
A validação de requisitos envolve uma revisão de todos os requisitos levantados e negociados, assim como uma 
prototipagem e validação de modelos e teste de requisitos. 
C) 
A validação de requisitos é um dos mais importantes processos na Engenharia de Requisitos. Isto porque tal como um 
documento de requisitos bem definido permite a correção de incoerências e inconformidades no desenvolvimento de um 
produto de software, a validação permite maximizar o tempo gasto na detecção dessas incoerências e inconformidades 
devido à sua alta eficiência na sua descoberta. 
- (CORRETA) 
D) 
Um erro encontrado numa fase tardia do desenvolvimento do projeto pode ser desastroso, pois a sua alteração poderá 
ser bastante custosa, se não impossível, em termos temporais. 
E) 
O processo de análise e negociação de requisitos agrega um grande volume de informação pouco estruturada e informal 
cedida pelos Stakeholders e tenta ir ao encontro das reais necessidades destes, através da estruturação,organização e 
interpretação desta informação e através da negociação desta nova reformulação da informação com os StakeHolders 
EngElet ESwDOnLineSisDigIV Mod II: Qualidade de software 12/106 
Mod II: Qualidade de software 
Atingir um alto nível de qualidade de produto ou serviço é o objetivo da maioria das 
organizações. Atualmente não é mais aceitável entregar produtos com baixa qualidade e 
reparar os problemas e as deficiências depois que os produtos foram entregues ao cliente. 
[SOMMERVILLE03] 
 
Segundo Machado [MACHADO01], para muitos engenheiros de software, a qualidade do 
processo de software é tão importante quanto à qualidade do produto. Assim na década de 
90 houve uma grande preocupação com a modelagem e melhorias no processo de 
software. Abordagens importantes como as normas ISO 9000 e a ISO / IEC 12207, o 
modelo CMM (Capability Maturity Model) e o SPICE (Software Process Improvement and 
Capability dEtermination) sugerem que melhorando o processo de software, podemos 
melhorar a qualidade dos produtos. 
 
A qualidade é conseqüência dos processos, das pessoas e da tecnologia. A relação entre e 
qualidade do produto e cada um desses fatores é complexa. Por isso, é muito mais difícil 
controlar o grau de qualidade do produto do que controlar os requisitos.[PÁDUA03] 
Veja o material completo em Qualidade de Software Arquivo: paper_02_QS.pdf 
Exercícios (13) 
Exercício 1 
Engenharia de Software inclui um grande número de teorias, conceitos, modelos, técnicas e métodos. Analise as 
seguintes definições. 
 
I) No planejamento de projetos de software, há várias técnicas que podem ser usadas para estimativa de custo e 
esforço. A técnica de Pontos por Função é uma técnica de estimativa que, embora não seja relacionada diretamente 
a linhas de código, é utilizada também para a obtenção de métricas de produtividade e qualidade do desenvolvimento 
de software; 
II) CMMI (Capability Maturity Model Integration) é um modelo estabelecido pelo Software Engineering Institute 
(SEI) que propõe níveis de competência organizacional relacionados à qualidade do processo de desenvolvimento 
de software; 
III) Engenharia Reversa é o processo de inferir ou reconstruir um modelo de mais alto nível (projeto ou 
especificação) a partir de um documento de mais baixo nível (tipicamente um código fonte); 
 
Levando-se em conta as três afirmações I, II e III acima, identifique a única alternativa válida: 
A) 
Apenas a I está correta; 
B) 
Apenas a II está correta. 
C) Apenas a II e a III estão corretas; 
D) 
Apenas a I e a III estão corretas; 
EngElet ESwDOnLineSisDigIV Mod II: Qualidade de software 13/106 
E) 
As afirmações I, II e III estão corretas. 
- (CORRETA) 
Exercício 2 
Qual das alternativas abaixo não corresponde a um fator da qualidade de software, segundo McCALL? 
A) 
Corretitude. 
B) 
Derivação. 
- (CORRETA) 
C) 
Confiabilidade. 
D) 
Reusabilidade. 
E) 
Integridade. 
Exercício 3 
2) NÃO é uma atividade do grupo de Garantia de Qualidade de Software (SQA): 
A) 
Participar no desenvolvimento da descrição do processo de software do projeto. 
B) 
Registrar qualquer eventual não-satisfação e relatar à gerência superior. 
C) 
Rever as atividades de engenharia de software para verificar a satisfação do processo 
de software definido. 
D) 
Corrigir e verificar se as correções foram feitas dentro do padrão estabelecido. 
- (CORRETA) 
E) 
Audita os produtos do trabalho de software encomendado para verificar a satisfação do que foi definido 
como parte do processo de software. 
Exercício 4 
Ao longo de todo o desenvolvimento do software, devem ser aplicadas atividades de garantia de 
qualidade de software (GQS), entre as quais se encontra a atividade de teste. Um dos critérios de teste 
utilizados para gerar casos de teste é o denominado critério dos caminhos básicos, cujo número de 
caminhos pode ser determinado com base na complexidade ciclomática. Considerando-se o grafo de 
fluxo de controle apresentado na figura ao lado, no qual os nós representam os blocos de comandos e 
as arestas representam a transferência de controle, qual a quantidade de caminhos básicos que 
devem ser testados no programa associado a esse grafo de fluxo de controle, sabendo-se que 
essa quantidade é igual à complexidade ciclomática mais um ? 
A) 
1. 
B) 
3. 
C) 
EngElet ESwDOnLineSisDigIV Mod II: Qualidade de software 14/106 
4. 
- (CORRETA) 
D) 
7. 
E) 
8. 
Exercício 5 
Coesão e acoplamento são dois conceitos fundamentais para a qualidade do projeto modular de 
um software. A coesão diz respeito à funcionalidade dos módulos que compõem o software e é 
relacionada ao conceito de ocultação de informação. 
O acoplamento está relacionado aos dados e representa a interconexão entre os módulos. Suponha que 
determinado sistema possa ter a arquitetura de seus módulos projetada por meio das duas alternativas 
diferentes mostradas na figura acima, sendo a funcionalidade de um módulo a mesma nas duas 
alternativas. 
Nessa figura, os retângulos representam os módulos e as arestas representam chamadas a 
funcionalidades de outros módulos. 
 
A partir dessas informações, assinale a opção correta. 
A) 
A coesão e o acoplamento de todos os módulos são iguais nas duas alternativas. 
B) 
Em relação à alternativa 1, na alternativa 2, a coesão do módulo A é menor, a dos módulos B e C é 
maior e o acoplamento do projeto é maior. 
- (CORRETA) 
C) 
Em relação à alternativa 1, na alternativa 2, a coesão do módulo A é maior, a dos módulos B e C é 
menor e o acoplamento do projeto é maior. 
D) 
Em relação à alternativa 1, na alternativa 2, a coesão do módulo A é maior, a dos módulos B e C é maior 
e o acoplamento do projeto é menor. 
E) 
Em relação à alternativa 1, na alternativa 2, a coesão do módulo A é menor, a dos módulos B e C é 
maior e o acoplamento do projeto é menor. 
Exercício 6 
Qualidade é uma das premissas básicas para se desenvolver software hoje em dia. Contudo, gerenciar 
a qualidade dentro do processo de software não é uma etapa trivial. Requer preparação, conhecimento 
EngElet ESwDOnLineSisDigIV Mod II: Qualidade de software 15/106 
técnico adequado e, sobretudo, comprometimento de todos os stakeholders envolvidos. A esse respeito, 
considere as seguintes afirmativas. 
I. O MPS.br é uma iniciativa para Melhoria de Processo do Software Brasileiro. O MPS.br adequa-se à 
realidade das empresas brasileiras e está em conformidade com as normas ISO/IEC 12207. No entanto, 
não apresenta uma estratégia de compatibilidade com o CMMI - Capability Maturity Model Integration. 
II. A rastreabilidade de requisitos de software proporciona uma melhor visibilidade para a gerência de 
qualidade do projeto. 
III. Uma empresa de tecnologia certificada por meio de modelos como CMMI ou 
MPS.br oferece produtos de software tambémcertificados. 
IV. A padronização é um dos fundamentos básicos da gerência da qualidade. A padronização pode 
acontecer em diversos níveis: na documentação, no código e, principalmente, no processo. 
Considerando a gerência da qualidade, assinale a alternativa CORRETA. 
A) 
Todas as afirmativas são verdadeiras. 
B) 
Nenhuma das afirmativas é verdadeira. 
C) 
Somente as afirmativas II e III são verdadeiras. 
D) 
Somente as afirmativas II e IV são verdadeiras. 
E) 
Somente as afirmativas I, II e III são verdadeiras. 
- (CORRETA) 
Exercício 7 
Considerando-se o Capability Maturity Model (CMM), é CORRETO afirmar que: 
A) 
A área chave de processo relacionada à garantia de qualidade está no nível dois de maturidade. 
- (CORRETA) 
B) 
As disciplinas de engenharia estão disponíveis a partir do nível um de maturidade. 
C) 
O CMM é uma técnica de modelagem. 
D) 
O nível zero de maturidade é caracterizado por processos repetitivos. 
E) 
No nível três, a organização está empenhada em obter melhorias contínuas de processo. 
Exercício 8 
Analise estas afirmativas concernentes à qualidade de software: 
EngElet ESwDOnLineSisDigIV Mod II: Qualidade de software 16/106 
I. A inspeção é uma atividade de garantia da qualidade de software. 
II. A revisão técnica formal não pode ser usada para treinamento da equipe. 
III. O controle de qualidade consiste em funções gerenciais de auditar e relatar não-conformidades. 
A partir dessa análise, pode-se concluir que: 
A) 
Apenas a afirmativa I está correta. 
- (CORRETA) 
B) 
Apenas a afirmativa II está correta. 
C) 
Apenas a afirmativa III está correta. 
D) 
Somente as afirmativas I e II estão corretas. 
E) 
Somente as afirmativas I e III estão corretas. 
Exercício 9 
A garantia de qualidade de software é uma atividade de guarda-chuva que é aplicada ao longo de todo 
o processo de engenharia de software, que abrange: 
I. métodos e ferramentas de análise, projeto, codificação e testes; 
II. revisões técnicas formais que são aplicadas durante cada fase de engenharia de software; 
III. uma estratégia de teste de múltiplas fases; 
IV. controle da documentação de software e das mudanças feitas nela; 
V. um procedimento para garantir a adequação aos padrões de desenvolvimento de software (quando 
aplicáveis); 
VI. mecanismos de medicação e divulgação. 
Quais itens estão corretos? 
A) 
Somente I, II e III. 
B) 
Somente II, III e IV. 
C) 
Somente III, IV e V. 
D) 
Somente I, III e VI. 
E) 
 I, II, III, IV, V e VI. 
EngElet ESwDOnLineSisDigIV Mod II: Qualidade de software 17/106 
- (CORRETA) 
Exercício 10 
A garantia de qualidade de software é uma atividade de guarda-chuva que é aplicada ao longo de todo 
o processo de engenharia de software, que abrange: 
 
I) Métodos e ferramentas de análise, projeto, codificação e testes; 
II) Revisões técnicas formais que são aplicadas durante cada fase de engenharia de software; 
III) Uma estratégia de teste de múltiplas fases; 
IV) Controle da documentação de software e das mudanças feitas nela; 
V) Um procedimento para garantir a adequação aos padrões de desenvolvimento de software (quando 
aplicáveis); 
VI) Mecanismos de medicação e divulgação. 
 
Quais itens estão corretos? 
 
 
A) 
Somente I, II e III. 
B) 
Somente II, III e IV. 
C) 
Somente III, IV e V. 
D) 
Somente I e II. 
 
E) 
I, II, III, IV, V e VI. 
- (CORRETA) 
Exercício 11 
Assinale a alternativa falsa 
A) 
A falta de mecanismos de controle e garantia de qualidade normalmente geram custos e riscos associados com 
retrabalho ou com perda de processos, como por exemplo, falha na execução de algumas tarefas. 
B) 
EngElet ESwDOnLineSisDigIV Mod II: Qualidade de software 18/106 
Quando os defeitos são identificados em ambiente de produção, os impactos podem causar ainda mais danos gerando 
custos com atendimento e tratamento de reclamações, lançamento de novas versões ou pacotes de correção, ou ainda 
em alguns casos, o deslocamento e realocação de profissionais para tratarem os erros. 
C) 
O CMMI dispõe de um processo específico para Garantia de Qualidade, denominado PPQA (Process and Product Quality 
Assurance) que visa avaliar a aderência das atividades executadas e dos produtos gerados conforme o processo de 
qualidade planejado pela empresa, verificando se a qualidade não foi comprometida durante o desenvolvimento do 
software. 
D) 
O Processo de Garantia da Qualidade verifica por meio de auditoria nos projetos, se os processos estão sendo 
executados corretamente e se os produtos de trabalho estão sendo gerados. O principal instrumento das auditorias é o 
checklist, que colabora na organização do que deve ser verificado, no qual o auditor identifica as não conformidades e 
as relata em um relatório que é enviando ao Gerente de Projeto para que as correções ou justificativas sejam 
realizadas. 
E) 
A Garantia de Qualidade fornece uma visão subjetiva quanto a desvios e pontos de melhoria, tanto para atividades de 
processo quanto de produto. Como conseqüência a empresa adquire ganhos nos resultados financeiros e na satisfação 
do cliente, ocasionado pelo aumento de custos, prazos e qualidade dos projetos. 
- (CORRETA) 
Exercício 12 
Assinale a alternativa falsa 
A) 
A qualidade de software é uma área de conhecimento da engenharia de software que objetiva garantir a qualidade do 
software através da definição e normatização de processos de desenvolvimento. 
B) 
Apesar dos modelos aplicados na garantia da qualidade de software atuarem principalmente no processo, o principal 
objetivo é garantir um produto final que satisfaça às expectativas do cliente, dentro daquilo que foi acordado 
inicialmente. 
C) 
A qualidade é o grau em que um conjunto de características inerentes a um produto, processo ou sistema cumpre os 
requisitos inicialmente estipulados para estes. 
D) 
No desenvolvimento de software, a qualidade do produto está diretamente relacionada à qualidade do processo de 
desenvolvimento, desta forma, é comum que a busca por um software de maior qualidade não passe necessariamente 
por uma melhoria no processo de desenvolvimento. 
- (CORRETA) 
E) 
Requisitos de qualidade é um tópico por si dentro do assunto qualidade. Dentro da ótica desta última, espera-se que os 
requisitos sejam definidos de maneira a caracterizar completamente o produto a ser construído 
Exercício 13 
Assinale a alternativa falsa 
A) 
EngElet ESwDOnLineSisDigIV Mod II: Qualidade de software 19/106 
No contexto de desenvolvimento de software, qualidade pode ser entendida como um conjunto de características a 
serem satisfeitas, de modo que o produto de software atenda às necessidades dos desenvolvedores. 
- (CORRETA) 
B) 
Apesar dos modelos aplicados na garantia da qualidade de software atuarem principalmente no processo, o principal 
objetivo é garantir um produto final que satisfaça às expectativas do cliente, dentro daquilo que foi acordado 
inicialmente. 
C) 
Quando os defeitos são identificados em ambiente de produção, os impactos podem causar ainda mais danos gerando 
custos com atendimento e tratamento de reclamações, lançamento de novas versões ou pacotes de correção, ou ainda 
em alguns casos, o deslocamento e realocação de profissionais para tratarem os erros. 
D) 
Em geral, o Processo da Garantia da Qualidade não é percebido pelo cliente ou usuário do software, no entanto, todo 
esse trabalho visa beneficiá-lo, uma vez que o resultado da aplicação da metodologia influencia diretamente os produtos 
que serão entregues, além de ser um instrumento importante para que as empresas de software identifiquem falhas em 
sua metodologia e iniciem um processo de melhoria 
E) 
A qualidade de produto é definida por um conjunto de características que devem ser alcançadas em um determinado 
grau para que o produto atenda às necessidades de seus usuários. É através deste conjunto de características que a 
qualidade de um produto pode ser descrita e avaliada 
 
EngElet ESwDOnLineSisDigIV Módulo III: Gestãode configuração de software 20/106 
Módulo III: Gestão de configuração de software 
O processo de gerência de configuração é um processo de aplicação de procedimentos 
administrativos e técnicos, por todo o ciclo de vida de software, destinado a: identificar e 
definir os itens de software em um sistema e estabelecer suas linhas básicas (baseline); 
controlar as modificações e liberações dos itens; registrar e apresentar a situação dos itens 
e dos pedidos de modificação; garantir a completeza, a consistência e a correção dos itens; 
e controlar o armazenamento, a manipulação e a distribuição dos itens.[ISO12207: 97] 
Veja o material completo em Gestão de configuração de software Arquivo: paper_03_GC.pdf 
Exercícios (13) 
Exercício 1 
 
O gerenciamento de configuração de software (GCS) é uma atividade que deve ser realizada para identificar, controlar, 
auditar e relatar as modificações que ocorrem durante todo o desenvolvimento ou mesmo durante a fase de manutenção, 
depois que o software for entregue ao cliente. O GCS é embasado nos chamados itens de configuração, que são produzidos 
como resultado das atividades de engenharia de software e que ficam armazenados em um repositório. Com relação ao 
GCS, analise as duas asserções apresentadas a seguir. 
No GCS, o processo de controle das modificações obedece ao seguinte fluxo: começa com um pedido de modificação de 
um item de configuração, que leva à aceitação ou não desse pedido e termina com a atualização controlada desse item 
no repositório porque o controle das modificações dos itens de configuração baseia-se nos processos de check-in e check-
out que fazem, respectivamente, a inserção de um item de configuração no repositório e a retirada de itens de 
configuração do repositório para efeito de realização das modificações. 
Acerca dessas asserções, assinale a opção correta. 
 
A) 
 
As duas asserções são proposições verdadeiras, e a segunda é uma justificativa correta da primeira. 
B) 
 
As duas asserções são proposições verdadeiras, e a segunda não é uma justificativa correta da primeira. 
- (CORRETA) 
C) 
 
A primeira asserção é uma proposição verdadeira, e a segunda é uma proposição falsa. 
D) 
A primeira asserção é uma proposição falsa, e a segunda é uma proposição verdadeira. 
E) 
As duas asserções são proposições falsas. 
Exercício 2 
Analise estas afirmativas relacionadas à gerência de configuração de software: 
EngElet ESwDOnLineSisDigIV Módulo III: Gestão de configuração de software 21/106 
I. Os artefatos que fazem parte de uma linha-base somente podem ser alterados mediante procedimentos formais de controle de 
modificação. 
II. A identificação dos itens de configuração é processo integrante da gerência de configuração. 
III. Controle de mudanças e controle de versões têm o mesmo significado no contexto da gerência de configurações. 
A partir dessa análise, pode-se concluir que: 
 
A) 
apenas a afirmativa I está correta. 
B) 
Apenas a afirmativa II está correta. 
C) 
Apenas a afirmativa III está correta. 
D) 
Apenas as afirmativas I e II estão corretas. 
- (CORRETA) 
E) 
Apenas as afirmativas II e III estão corretas. 
 
Exercício 3 
O processo de Gerência de Configuração de Software é definido por quatro funções básicas, a saber: 
A) 
Armazenagem, Utilização, Alteração e Personalização. 
B) 
Classificação, Agrupamento, Utilização e Manipulação. 
C) 
Identificação, Documentação, Controle e Auditoria. 
- (CORRETA) 
D) 
Públicas, Privadas, Atribuídas e Herdadas. 
E) 
Usuário, Sistema, Ambiente e Desempenho. 
Exercício 4 
Considere as seguintes assertivas sobre a Gerência de Configuração de Software: 
I- Um baseline somente pode ser alterado por processos formais de controle de alteração. 
II-O controle de versões pode ser descrito pelo grafo de evolução do software. 
III-A inserção de um objeto no repositório (check-in) necessariamente invoca o mecanismo de controle de versão. 
As assertivas corretas são: 
A) 
Somente I; 
EngElet ESwDOnLineSisDigIV Módulo III: Gestão de configuração de software 22/106 
B) 
Somente II; 
C) 
Somente III; 
D) 
Somente I e II; 
E) 
I, II e III. 
- (CORRETA) 
Exercício 5 
 No que diz respeito à área da engenharia de software, analise a citação a seguir. 
A) 
 Auditoria de Configuração 
B) 
 Gestão de Configuração 
- (CORRETA) 
C) 
 Gerência de Mudanças 
D) 
 Controle de Versão 
E) 
 Versões de Projeto 
Exercício 6 
Assinale a alternativa falsa 
A) 
Configuração é o estado em que um sistema se encontra em um determinado momento. 
B) 
A Configuração de Software trata apenas dos elementos que se encontram em formato eletrônico e fazem parte dessa 
configuração. Isso inclui todos os arquivos fontes, todos os documentos eletrônicos, as ferramentas de software 
utilizadas para construir ou mesmo ler estes arquivos, o sistema operacional utilizado, as bibliotecas de software, etc. 
C) 
A configuração não varia com o tempo, pois novos arquivos são incluídos, e arquivos existentes são alterados ou 
removidos. 
- (CORRETA) 
D) 
O objetivo da Gerência de Configuração como um todo é organizar todos estes elementos de forma a saber em qual 
estado o sistema se encontrava nos momentos chave do desenvolvimento 
EngElet ESwDOnLineSisDigIV Módulo III: Gestão de configuração de software 23/106 
E) 
A Gerência de Configuração como um todo trata dos elementos, incluindo hardware, necessários para a manutenção 
apropriada do sistema. 
Exercício 7 
Assinale a alternativa falsa 
A) 
Definimos uma linha básica como um marco de referência no desenvolvimento de um software, que é caracterizado pela 
entrega de um ou mais itens de configuração e pela aprovação desses SCIs, obtida por meio de uma revisão técnica 
formal. 
B) 
A Gerência de Configuração de Software trata especificamente dos elementos necessários a construção de sistemas de 
software, e em geral, controla apenas os elementos em formato computadorizado. 
C) 
Linhas-base ou Baseline é um conceito de gerenciamento de configuração de software que nos ajuda a controlar as 
mudanças, impedindo as mudanças justificáveis 
 
- (CORRETA) 
D) 
O Controle de versão rastreia e controla todos os artefatos do projeto (código-fonte, arquivos de configuração, 
documentação etc.) e assim consegue coordenar o trabalho paralelo de desenvolvedores 
E) 
Controle de Versão resolve diversos problemas básicos de desenvolvimento tais como uso de diferentes versões de 
código, sincronização do trabalho paralelo de desenvolvedores no mesmo projeto, recuperação de versões anteriores e 
registro do histórico de alterações. 
Exercício 8 
Assinale a alternativa falsa 
A) 
A finalidade do Controle de versão é dar um controle maior sobre tudo que você altera no seu projeto de software. 
B) 
Todos os arquivos e diretórios que compõem o projeto ficam sob a responsabilidade do sistema de controle de versão 
num local denominado de repositório, lugar onde se guarda, arquiva, coleciona alguma coisa 
C) 
O controle de versão além de rastrear e controlar alterações, também coordena a edição colaborativa e o 
compartilhamento de dados entre os vários desenvolvedores de uma equipe. 
D) 
A Gerência de mudanças não é uma parte geralmente negligenciada da Gerência de configuração. Como ela não tem 
resultados imediatos para os desenvolvedores e engenheiros de software envolvidos no projeto, estes acabam por não 
perceber sua importância 
- (CORRETA) 
E) 
EngElet ESwDOnLineSisDigIV Módulo III: Gestão de configuração de software 24/106 
Uma Auditoria de Configuração Física (PCA) identifica os componentes de um produto que serão implantados do 
Repositório do Projeto 
Exercício 9 
Assinale a alternativa falsa 
A) 
Gerenciamento de Configuração de Software é uma atividade que procura garantir que todos os itens de um produto 
sejam rigorosamente mantidos sob controle, com isso todas as alterações são registradas com a finalidade de ter 
registro e garantia de recuperação dos dados. Nesses registrosnão são encontrado as razões das modificações 
solicitadas, mas sim quem solicitou e quem realizou a modificação. 
- (CORRETA) 
B) 
Referenciais são utilizados para dar agilidade no processo de desenvolvimento de software, também chamados de linhas 
de base ou baseline, antes de se tornar um referencial as modificações podem ocorrer rapidamente e informalmente, 
após a aprovação de uma referência, ou linha de base, as modificações somente podem ocorrer após aprovações 
formais, isso ajuda a garantir que modificações não ocorram sem que as partes interessadas tomem ciência do impacto 
que pode causar, se fazer ou não fazer, estas mudanças no projeto 
C) 
Um item de configuração de software é a informação criada como parte do processo de engenharia de software. Em 
caso extremo, pode-se considerar um SCI como sendo uma única seção de uma especificação grande ou um caso de 
teste em uma sequência de testes grande. Mais realisticamente, um SCI é um documento, toda sequência de casos de 
teste ou um componente de programa que tem nome 
D) 
O objetivo do Gerenciamento de Configurações é estabelecer e manter a integridade dos seus resultados intermediários 
e finais, ao longo de seu ciclo de vida 
E) 
Uma linha de base consiste em um ou mais itens de configuração de software, aprovados através dos procedimentos 
previstos pelos respectivos padrões e pelo Plano de Qualidade do Software de um projeto 
Exercício 10 
Assinale a alternativa falsa 
A gestão de configuração de software visa garantir que: 
A) 
todos os resultados intermediários e finais, associados a marcos importantes de todos os projetos, sejam colocados e 
controlados como itens de configuração, em base de dados de Gestão de Configurações; 
B) 
esses itens sejam organizados em linhas de base que representam estados significativos e consistentes de cada projeto; 
C) 
todas as alterações em itens das linhas de base sejam controladas, mas não checadas; 
- (CORRETA) 
D) 
toda a história dos itens de configuração de cada projeto seja recuperável e auditável; 
E) 
EngElet ESwDOnLineSisDigIV Módulo III: Gestão de configuração de software 25/106 
todos os membros das equipes e demais interessados em cada projeto possam recuperar facilmente versões oficiais 
atualizadas de todos os respectivos itens de configuração, de acordo com as respectivas permissões de acesso 
Exercício 11 
Assinale a alternativa falsa 
São importantes elementos que precisam estar presentes em um sistemas de gestão de configuração: 
A) 
Elementos de componente 
B) 
Elementos de processo 
C) 
Elementos de construção 
D) 
Elementos humanos 
E) 
Elementos técnicos 
- (CORRETA) 
Exercício 12 
Não é uma atividades do Grupo de Gestão de Configuração de Software: 
A) 
desenvolvimento, manutenção e divulgação dos procedimentos de gestão de configurações e de uso das respectivas 
ferramentas; 
B) 
assessoria aos projetos, relativa à conformidade com os padrões e aos procedimentos de gestão de configurações; 
C) 
verificação de conformidade das linhas de base dos projetos e produtos com as regras e os procedimentos de gestão de 
configurações; 
D) 
administração das bibliotecas de configurações, excluindo a manutenção, análise de integridade, emissão de relatórios 
gerenciais e realização de cópias de segurança; 
- (CORRETA) 
E) 
comunicação aos gerentes de projeto sobre problemas relativos à gestão de configurações encontrados dentro dos 
projetos, para que providenciem sua resolução; 
Exercício 13 
Em relação à Gestão de Configurações, os gerentes de projetos não devem: 
A) 
EngElet ESwDOnLineSisDigIV Módulo III: Gestão de configuração de software 26/106 
tomar as providências necessárias, em nível do respectivo projeto, para realização das atividades de gestão de 
configurações previstas no Plano da Qualidade do Software do projeto; 
B) 
tomar as providências necessárias para que sejam respeitados os apenas alguns procedimentos de gestão de 
configurações, em nível dos projetos; 
- (CORRETA) 
C) 
designar uma Comissão de Controle de Configurações de Software do projeto, responsável pelo controle das linhas de 
base do projeto, ou assumir a função dessa comissão; 
D) 
designar um gestor de configurações do projeto, responsável pelo contato com o Grupo de Gestão de Configurações de 
Software da Organização, ou assumir essa função; 
E) 
encaminhar ao Grupo de Gestão de Configurações de Software o material das linhas de base do projeto, ao final de cada 
interações de software; 
 
 
EngElet ESwDOnLineSisDigIV Módulo IV: Gestão de riscos de software 27/106 
Módulo IV: Gestão de riscos de software 
 
De modo simplificado, podemos pensar no risco como uma probabilidade de que alguma 
circunstância adversa realmente venha ocorrer. Os riscos podem ameaçar o projeto, o 
software que está sendo desenvolvido ou a organização. Essas categorias de riscos 
podem ser definidas como se segue: [SOMMERVILLE03] 
O processo de gestão de riscos envolve vários estágios: [SOMMERVILLE03] 
1. Identificação dos riscos: São identificados os possíveis riscos de projeto, produto e 
negócios. 
2. Análise de riscos: São avaliadas as possibilidades e as conseqüências da ocorrência 
desses riscos. 
3. Planejamento de riscos: São traçados planos para enfrentar os riscos, seja evitando-
os, seja minimizando seus efeitos sobre o projeto. 
4. Monitoramento de riscos: O Risco é constantemente avaliado e os planos para a 
diminuição dos riscos revisados, à medida que mais informações sobre eles se tornam 
disponíveis. 
Veja o material completo em Gestão de riscos de software Arquivo: paper_04_Riscos.pdf 
Exercícios (13) 
 
Exercício 1 
Durante o processo de análise de risco é necessário fazer uma avaliação dos tipos de riscos e dos riscos possíveis. Associe 
os tipos de riscos com os riscos possíveis. 
 
Tipos de riscos: 
A. Tecnologia 
B. Pessoal 
C. Ferramentas 
D. Estimativas 
 
Riscos possíveis: 
( ) A taxa de reparo de defeito foi subestimada. 
( ) O treinamento necessário não está disponível. 
( ) O banco de dados usado no sistema não suporta a quantidade de transações que o sistema demanda. 
( ) Não será possível integração de CASE. 
A) 
C – A – B – D. 
B) 
B – C – D – A. 
C) 
EngElet ESwDOnLineSisDigIV Módulo IV: Gestão de riscos de software 28/106 
A – D – C – B. 
D) 
D – B – A – C. 
- (CORRETA) 
E) 
B – D – C – A. 
Exercício 2 
 São axiomas em risco: 
A) 
 É impossível testar um programa completamente. Teste de software é um exercício baseado em certezas. Quanto 
menos bugs forem encontrados, mais bugs existirão. 
B) 
 É possível testar um programa completamente. Teste de software não pode ter riscos. Quanto mais breaks forem 
encontrados, mais breaks existirão. 
C) 
 É impossível testar um programa completamente. Teste de software é um exercício baseado em risco. Quanto mais 
bugs forem encontrados, mais bugs existirão. 
- (CORRETA) 
D) 
 É impossível testar um programa que tenha riscos. Teste de software deve ser feito pelos seus desenvolvedores. Todos 
os bugs encontrados serão consertados. 
E) 
 É impossível testar um programa parcialmente. Teste de software aplica-se unicamente a ambientes sem risco. Quanto 
mais bugs forem encontrados, menos bugs existirão. 
Exercício 3 
 O Fluxo de Análise das ameaças e riscos, na ordem apresentada, consiste de: 
A) 
 diversificação das ameaças, minimização das probabilidades dos riscos, redução dos pesos dos riscos, controle do risco, 
eliminação dos riscos prioritários, adoção de medidas de proteção lógica. 
B) 
 determinação das probabilidades dos riscos, quantificação dos riscos, avaliação do risco, proteção de ativos, eliminação 
dos riscos. 
C) 
 restrição das ameaças, planejamento das probabilidades dos riscos, determinação da hierarquia dos riscos, aquisição de 
software, estabelecimento de propriedades, redimensionamento. 
D) 
 identificação das medidas de proteção, determinação das probabilidades de ameaças, determinaçãodas prioridades dos 
pesos dos riscos, vinculação de ameaças a riscos, realocação de pessoal. 
EngElet ESwDOnLineSisDigIV Módulo IV: Gestão de riscos de software 29/106 
E) 
 identificação das ameaças, determinação das probabilidades dos riscos, determinação dos pesos dos riscos, avaliação 
do risco, estabelecimento de prioridades de proteção, adoção de medidas de proteção. 
- (CORRETA) 
Exercício 4 
 Determinado órgão público deseja analisar, quantitativamente, alguns riscos de seus projetos de software. Que técnica 
é apropriada para atingir tal objetivo? 
A) 
 BAM (Business Activity Monitoring). 
B) 
 Monte Carlo. 
- (CORRETA) 
C) 
 Algoritmo de Dijkstra. 
D) 
 BPM (Business Process Management). 
E) 
 Análise de Turing-Knuth-Wirth. 
Exercício 5 
 Na especificação dirigida a riscos, a compreensão da probabilidade de ocorrência de um risco e das consequências 
potenciais, se um acidente ou incidente, associado com este risco, ocorrer, é da competência do processo de 
A) 
 especificação de requisitos. 
B) 
 decomposição de riscos. 
C) 
 análise da qualidade. 
D) 
 validação de requisitos. 
E) 
 análise e classificação de riscos. 
- (CORRETA) 
Exercício 6 
Assinale a alternativa falsa 
A) 
EngElet ESwDOnLineSisDigIV Módulo IV: Gestão de riscos de software 30/106 
Gestão (ou gerenciamento) de Riscos preocupa-se em identificar os riscos os quais um projeto está exposto e prover 
ações que visam fazer com eles não se tornem eventos ou, caso aconteça, que seus impactos sejam os mínimos 
possíveis. 
B) 
Com o tratamento adequado dos riscos é possível eliminar os incidentes de falhas em projetos de software. 
- (CORRETA) 
C) 
Se usado como instrumento, no processo de desenvolvimento de software, permite a redução da exposição ao risco 
possibilitando aumentar a qualidade do produto e melhorar o processo de desenvolvimento. 
D) 
Pode-se caracterizar como risco ou incerteza qualquer aspecto que de alguma forma impacta o projeto, considerando as 
dimensões prazo, custo e qualidade. Em outras palavras, é a possibilidade de algum evento adverso ocorrer. 
E) 
O processo de gerenciamento de risco deve ser adaptado de maneira a se adequar ao projeto em questão 
Exercício 7 
Assinale a alternativa falsa 
A) 
A pressão por prazos, curtos custos baixos e alta qualidade, bem como o mercado altamente competitivo, reduzem os 
riscos inerentes aos projetos. 
- (CORRETA) 
B) 
Devem ser utilizados métodos e técnicas específicas que permitam gerenciar os riscos de forma que o projeto aumente 
suas chances de sucesso. 
C) 
O processo de gerenciamento de risco deve ser adaptado de maneira a se adequar ao projeto em questão 
 
D) 
Deve-se avaliar a probabilidade de ocorrência e as consequências de riscos, em ordem de prioridade ou efeito. 
E) 
A análise de risco consiste em um processo de identificação e avaliação dos fatores de risco presentes e de forma 
antecipada no Ambiente Organizacional, possibilitando uma visão do impacto negativo causado aos negócios. É feita 
para concretização efetiva dos planos de desenvolvimento e deve acontecer periodicamente 
Exercício 8 
Assinale a alternativa falsa 
A) 
A gestão dos riscos deve buscar a crítica constante, pensar em todas as variáveis da forma mais pessimista possível, 
considerar as perspectivas e tudo o que pode acontecer. 
B) 
EngElet ESwDOnLineSisDigIV Módulo IV: Gestão de riscos de software 31/106 
O gerenciamento de risco, mais do que estabelecer margens de risco, deve influenciar as decisões e planejamento do 
projeto, principalmente para aumentar sua qualidade 
C) 
No que diz respeito ao monitoramento e controle dos riscos, uma reavaliação ocorre durante as reuniões, onde os riscos 
são revistos e ações que minimizem a probabilidade de ocorrência dos mesmos nas próximas iterações. 
D) 
Pode ser mantido um histórico com as ações e decisões tomadas, pois alguns riscos e erros são constantes e comuns 
em diversos projetos. 
E) 
Se usado como instrumento, no processo de desenvolvimento de software, permite o aumento da exposição ao risco 
possibilitando reduzir a qualidade do produto e melhorar o processo de desenvolvimento. 
- (CORRETA) 
Exercício 9 
Assinale a alternativa falsa 
A) 
Riscos são eventos que podem ocorrer no futuro e se concretizados, afetam o projeto de software. 
B) 
Os fatores relacionados ao risco são: o evento ou fato que caracteriza o risco, a probabilidade de que ele irá ocorrer 
(possibilidade) e a perda resultante de sua ocorrência (conseqüência). 
C) 
O risco caracteriza-se pela certeza (o evento que caracteriza o risco pode ou não ocorrer) e perda (se o evento ocorrer, 
conseqüências inesperadas ou perdas irão ocorrer). 
- (CORRETA) 
D) 
Os riscos de projeto ameaçam o plano do projeto: é a possibilidade de ocorrerem problemas com orçamento, 
cronograma, pessoal, recursos, cliente e requisitos. 
E) 
Os riscos técnicos ameaçam a qualidade do produto, ou seja, são as possibilidades de ocorrerem problemas com a 
especificação, projeto técnico, implementação, interfaces, verificações e manutenção 
Exercício 10 
Assinale a alternativa falsa 
A) 
A análise dos riscos é uma das atividades essenciais para o bom encaminhamento de um projeto de software. Esta 
atividade está baseada na realização de quatro tarefas, conduzidas de forma seqüencial: a identificação, a projeção, a 
avaliação e a administração. 
B) 
Os riscos de negócio são aqueles que ameaçam a viabilidade do software a ser desenvolvido, ocorrendo quando 
desenvolve-se um excelente produto do qual ninguém precisa (risco de mercado) ou um produto não alinhado com a 
estratégia da companhia (risco estratégico) ou um produto que a força de vendas não entende como vendê-lo ou pode 
ocorrer perda do apoio da gerência de alto nível da companhia (risco gerencial) e a redução de orçamento ou de pessoal 
(risco orçamentário). 
EngElet ESwDOnLineSisDigIV Módulo IV: Gestão de riscos de software 32/106 
C) 
Os riscos conhecidos podem ser descobertos após uma avaliação cuidadosa do plano do projeto, ambiente técnico e do 
negócio, como por exemplo: prazos irreais, escopo mal definido, ambiente de desenvolvimento ruim. 
 
D) 
Os riscos previsíveis são percebidos a partir de experiências em projetos anteriores (rotatividade de pessoal, 
comunicação ruim com o cliente, canalização de esforços para manutenção) 
E) 
Os riscos os imprevisíveis são aqueles difíceis de serem identificados, e que não ocorrerão 
- (CORRETA) 
Exercício 11 
FGV - 2010 - BADESC - Analista de Sistemas - Desenvolvimento de Sistemas 
O Modelo Espiral, segundo Pressman (1995), incorpora as melhores características do Ciclo de Vida Clássico e da 
Prototipação e acrescenta o seguinte elemento: 
A) 
análise dos riscos. 
- (CORRETA) 
B) 
análise de projetos. 
C) 
avaliação de usuários. 
D) 
refinamento de requisitos. 
E) 
refinamento de protótipos. 
Exercício 12 
ESAF - 2010 - CVM - Analista de Sistemas 
São axiomas em risco 
A) 
É impossível testar um programa completamente. Teste de software é um exercício baseado em certezas. Quanto 
menos bugs forem encontrados, mais bugs existirão. 
B) 
É possível testar um programa completamente. Teste de software não pode ter riscos. Quanto mais breaks forem 
encontrados, mais breaks existirão. 
C) 
É impossível testar um programa completamente. Teste de software é um exercício baseado em risco. Quanto mais 
bugs forem encontrados, mais bugs existirão. 
- (CORRETA) 
EngElet ESwDOnLineSisDigIV Módulo IV: Gestão de riscos de software 33/106 
D) 
É impossível testar um programa que tenha riscos. Teste de software deve ser feito pelos seus desenvolvedores. Todos 
os bugs encontrados serão consertados. 
E) 
É impossível testar um programa parcialmente. Teste de software aplica-se unicamente a ambientes sem risco. Quanto 
mais bugs forem encontrados, menos bugs existirão. 
Exercício 13 
CESGRANRIO - 2010 - EPE - Analista de Gestão Corporativa - Tecnologia da InformaçãoDeterminado órgão público deseja analisar, quantitativamente, alguns riscos de seus projetos de software. Que técnica 
é apropriada para atingir tal objetivo? 
A) 
BAM (Business Activity Monitoring). 
B) 
Monte Carlo. 
- (CORRETA) 
C) 
Algoritmo de Dijkstra. 
D) 
BPM (Business Process Management). 
E) 
Análise de Turing-Knuth-Wirth. 
 
EngElet ESwDOnLineSisDigIV Mod V: Metodologias de desenvolvimento 34/106 
Mod V: Metodologias de desenvolvimento 
O RUP (Rational Unified Process) é um framework genérico para processos de 
desenvolvimento de software, criado pela empresa Rational Software Corporation, que está 
fortemente centrado na arquitetura, funcionalidade (caso de uso) e o desenvolvimento 
iterativo e incremental (inspirado no ciclo de vida espiral de Boehm), que aplica a UML, 
para o projeto e a documentação. [TONSIG03] 
 
O RUP é um processo de desenvolvimento de software e, como tal, descreve os papéis e 
as atividades que cada membro da equipe de projeto deve desempenhar ao longo do ciclo 
de desenvolvimento do software e os produtos que devem ser gerados como resultado 
destas atividades, os chamados artefatos. [BALDUINO02] 
Veja o material completo em Metodologia de desenvolvimento - RUP Arquivo: 
Exercícios (17) 
Exercício 1 
Analise as seguintes afirmativas sobre Engenharia de Software: 
I) Os modelos de maturidade têm o objetivo de avaliar a qualidade dos processos de software aplicados em uma 
organização (empresa ou instituição). Um exemplo de modelo de maturidade muito conhecido é o Capability 
Maturity Model Integration (CMMI) do Software Engineering Institute (SEI). 
II) Refactoring é o processo de modificar um sistema de software para melhorar seu comportamento externo, 
minimizando alterações na estrutura interna do código. 
III) Programação extrema (eXtreme Programming), ou simplesmente XP, é uma metodologia ágil para equipes 
pequenas e médias que irão desenvolver software com requisitos vagos e em constante mudança. Para isso, adota a 
estratégia de constante acompanhamento e realização de vários pequenos ajustes durante o desenvolvimento 
de software. 
 
São VERDADEIRAS as afirmativas: 
A) 
I e II, apenas. 
B) 
I e III, apenas. 
- (CORRETA) 
C) 
II e III, apenas. 
D) 
I, II e III, apenas. 
E) I apenas. 
Exercício 2 
A construção de sistemas é difícil devido à sua complexidade. Um fator crucial para gerenciar esta complexidade é 
o processo adotado para o desenvolvimento. O conjunto básico de atividades e a ordem em que são realizadas neste 
processo definem o que é também denominado de ciclo de vida do software. Analise as seguintes afirmações sobre 
processos de software: 
EngElet ESwDOnLineSisDigIV Mod V: Metodologias de desenvolvimento 35/106 
 
I) Um modelo de processo de software é uma representação abstrata de um processo; Exemplos de modelo de 
processos de software genéricos são o modelo waterfall (cascata) e o spiral (espiral); 
II) O modelo de processo waterfall ainda é hoje em dia um dos mais difundidos e tem por característica principal a 
codificação de uma versão executável do sistema desde as fases iniciais do desenvolvimento, de modo que o sistema 
final é incrementalmente construído, daí a alusão à idéia de “cascata” (waterfall); 
III) Em um processo de software incremental, o desenvolvimento do sistema é iterativo e partes de suas 
funcionalidades (denominadas “incrementos”) são entregues na medida em que são desenvolvidas; assim, estas 
entregas parciais tentam priorizar as necessidades mais urgentes do usuário e podem auxiliar a revisão e a uma 
melhor definição das partes ainda não entregues; 
 
Levando-se em conta as três afirmações I, II e III acima, identifique a única alternativa válida: 
A) 
Apenas a I e a II estão corretas; 
B) 
Apenas a II e a III estão corretas; 
C) Apenas a I e a III estão corretas; - (CORRETA) 
D) 
As afirmações I, II e III estão corretas; 
E) 
Apenas a III está correta. 
Exercício 3 
Um modelo de processo de software pode ser visto como uma representação, ou abstração dos objetos e atividades 
envolvidas no processo. São modelos de processo de software, EXCETO: 
A) 
RAD. 
B) 
RUP. 
- (CORRETA) 
C) 
Formal. 
D) 
V-Model. 
E) 
Espiral. 
Exercício 4 
No processo unificado, cinco workflows acompanham o conjunto das fases de desenvolvimento de software. 
Cada workflow é um conjunto de atividades executadas por vários membros do projeto. 
Considerando o desenvolvimento de um sistema integrado de gestão (ERP), o empacotamento em componentes 
de software dos elementos do modelo de projeto — tais como arquivo de código fonte,biblioteca de ligação dinâmica e 
componentes executáveis — é descrito pelo workflow de: 
A) 
Teste. 
EngElet ESwDOnLineSisDigIV Mod V: Metodologias de desenvolvimento 36/106 
B) 
Análise. 
C) 
Projeto. 
D) 
Implementação. 
- (CORRETA) 
E) 
Requisito. 
Exercício 5 
O Processo Unificado (RUP – rational unified process) é um moderno processo de desenvolvimento de software constituído 
de quatro fases. Assinale a opção que apresenta as quatro fases do RUP, na ordem em que elas devem ser executadas. 
A) 
Concepção, elaboração, construção, teste. 
B) 
Elaboração, transição, concepção, construção. 
C) 
Elaboração, concepção, teste, transição. 
D) 
Elaboração, concepção, transição, construção. 
E) 
Concepção, elaboração, construção, transição. 
- (CORRETA) 
Exercício 6 
 
No processo de desenvolvimento de software, todo software passa pelas fases de análise e projeto, associadas, 
respectivamente, com o que deve ser feito e como deve ser feito. A partir dessa informação, avalie a opções correta. 
 
A) 
Na fase de análise, três modelos que devem ser considerados são: do domínio da informação, o funcional e o 
comportamental. 
- (CORRETA) 
B) 
Na fase de projeto, dois níveis de projeto devem ser considerados: o projeto detalhado, que se preocupa com uma 
transformação dos requisitos em um projeto de dados e arquitetural; e o projeto preliminar, que se preocupa em aprimorar 
o projeto detalhado para que a implementação possa ser realizada em seguida. 
C) 
O objetivo do projeto arquitetural é desenvolver uma estrutura de programa e representar os diversos fluxos de dados 
entre os módulos. 
D) 
O projeto arquitetural independe do paradigma de desenvolvimento. 
E) 
Para lidar com a complexidade do software, pode-se aplicar o princípio do particionamento, quebrando o problema em 
problemas menores. Esse princípio não é aplicado nas outras fases de desenvolvimento e ele não causa impacto nos 
custos de desenvolvimento. 
EngElet ESwDOnLineSisDigIV Mod V: Metodologias de desenvolvimento 37/106 
Exercício 7 
Considere que você trabalhe em uma empresa de desenvolvimento de software e que a empresa tenha decidido 
desenvolver um novo editor de texto para colocar no mercado. Esse editor deve ser um software que forneça recursos 
adicionais de apoio à autoria, embasado no estilo de escrita do usuário, o que o torna um software de funcionalidade mais 
complexa. Considere que a empresa deseje disponibilizar o produto no mercado em versões que agreguem esse suporte 
de forma gradativa, fazendo análise de risco para avaliar a viabilidade de desenvolvimento de uma nova versão. Tendo 
de escolher um modelo de processo para desenvolver esse editor, e conhecendo as características dos modelos existentes, 
entre os modelos abaixo, qual é o modelo apropriado para esse caso? 
A) 
Cascata. 
B) 
Espiral. 
- (CORRETA) 
C) 
RAD (rapid application development). 
D) 
Prototipação. 
E) 
Cleanroom. 
Exercício 8 
As seguintes afirmações dizem respeito ao modelo de desenvolvimento em Espiral - proposto por Barry Boehm na década 
de 70: 
 
I. suas atividades do desenvolvimento são conduzidas por riscos ; 
II. cada ciclo da espiral inclui 4 passos: passo 1 - identificação dos objetivos ; passo 2 – avaliação das alternativas tendo 
em vista os objetivos e os riscos (incertezas, restrições) do desenvolvimento; passo 3 - desenvolvimento de estratégias 
(simulação,prototipagem) p/ resolver riscos; e passo 4 - planejamento do próximo passo e continuidade do processo 
determinada pelos riscos restantes; 
III. é um modelo evolutivo em que cada passo pode ser representado por um quadrante num diagrama cartesiano: assim 
na dimensão radical da espiral tem-se o custo acumulado dos vários passos do desenvolvimento enquanto na dimensão 
angular tem-se o progresso do projeto. 
Levando-se em conta as três afirmações I, II e III acima, identifique a única alternativa válida: 
A) 
Apenas a I e a II estão corretas; 
B) 
Apenas a II e a III estão corretas; 
C) 
Apenas a I e a III estão corretas; 
D) 
As afirmações I, II e III estão corretas; 
- (CORRETA) 
E) 
Apenas a III está correta. 
Exercício 9 
Considere as seguintes afirmativas sobre os modelos prescritivos de processos de desenvolvimento de software 
I. Uma das vantagens do modelo de prototipação é servir como base para entendimento dos requisitos do sistema. 
EngElet ESwDOnLineSisDigIV Mod V: Metodologias de desenvolvimento 38/106 
II. Um dos problemas do modelo RAD (Rapid Application Development) é a necessidade de conseguir recursos suficientes 
para a montagem de vários grupos operando em paralelo. 
III. O caso negócio (Business Case) é um dos produtos da fase de Concepção do Processo Unificado (Unified Process). 
Assinale a alternativa CORRETA: 
 
A) 
Apenas a afirmativa I é verdadeira. 
B) 
Apenas a afirmativa II é verdadeira. 
C) 
Apenas a afirmativa III é verdadeira. 
D) 
Apenas as afirmativas I e II são verdadeiras. 
E) 
Todas as afirmativas são verdadeiras. 
- (CORRETA) 
Exercício 10 
Sobre Ciclo de Vida de Desenvolvimento de Software, é correto afirmar: 
 
I. O desenvolvimento em cascata tem como base a idéia de desenvolver uma implementação inicial, mostrar e discutir tal 
implementação com o usuário e fazer seu aprimoramento por meio de versões 
subsequentes, até que um sistema adequado tenha sido desenvolvido. 
II. No modelo de processo de desenvolvimento em espiral, cada loop na espiral representa uma fase do processo de 
software. Este modelo exige a consideração direta dos riscos técnicos em todos os estágios do projeto e, se aplicado 
adequadamente, deve reduzir os riscos antes que eles se tornem problemáticos. 
III. O Rapid Application Development (Desenvolvimento Rápido de Aplicação) é um modelo de processo de software 
incremental que enfatiza um ciclo de desenvolvimento rápido. Este modelo é uma adaptação de modelo cascata, no qual 
o desenvolvimento rápido é conseguido com o uso de uma abordagem de construção baseada em componentes. 
IV. O modelo incremental combina elementos do modelo em cascata aplicado de maneira iterativa. Em um processo de 
desenvolvimento incremental, os clientes identificam (esboçam) as funções a serem fornecidas pelo sistema e a 
importância das mesmas. Em seguida, é definida uma série de estágios de entrega, com cada estágio fornecendo um 
subconjunto das funcionalidades do sistema. 
Assinale a alternativa correta. 
 
A) 
Somente as afirmativas I e II são corretas. 
B) 
Somente as afirmativas I e III são corretas. 
C) 
Somente as afirmativas III e IV são corretas. 
D) 
Somente as afirmativas I, II e IV são corretas. 
E) 
EngElet ESwDOnLineSisDigIV Mod V: Metodologias de desenvolvimento 39/106 
Somente as afirmativas II, III e IV são corretas. 
- (CORRETA) 
Exercício 11 
Ordene as atividades abaixo segundo o ciclo de vida clássico de engenharia de software, também chamado modelo em 
cascata. 
1. Manutenção 
2. Teste 
3. Projeto 
4. Análise 
5. Codificação 
 
A) 
1 – 2 – 3 – 4 – 5. 
B) 
4 – 3 – 5 – 2 – 1. 
- (CORRETA) 
C) 
2 – 5 – 4 – 1 – 3. 
D) 
3 – 5 – 4 – 1 – 2. 
E) 
3 – 4 – 5 – 2 – 1. 
Exercício 12 
O conjunto básico de atividades e a ordem em que são realizadas no processo de construção de um software definem o 
que é habitualmente denominado de ciclo de vida do software. O ciclo de vida tradicional (também denominado waterfall ) 
ainda é hoje em dia um dos mais difundidos e tem por característica principal: 
A) 
O uso de formalização rigorosa em todas as etapas de desenvolvimento; 
B) 
A abordagem sistemática para realização das atividades do desenvolvimento de software de modo que elas seguem um 
fluxo sequencial; 
- (CORRETA) 
C) 
A codificação de uma versão executável do sistema desde as fases iniciais do desenvolvimento, de modo que o sistema 
final é incrementalmente construído, daí a alusão à idéia de "cascata"(waterfall ); 
D) 
A priorização da análise dos riscos do desenvolvimento; 
E) 
A avaliação constante dos resultados intermediários feita pelo cliente. 
Exercício 13 
A situação atual do desenvolvimento de software encontra-se aquém do ideal. 
EngElet ESwDOnLineSisDigIV Mod V: Metodologias de desenvolvimento 40/106 
Sistemas são invariavelmente entregues com atraso ou com o orçamento estourado, isto quando são efetivamente 
entregues... E o que é pior, freqüentemente eles não atendem os requisitos dos clientes. Existem várias alternativas de 
tentar enfrentar este desafio, entre as quais a adoção de métodos formais, a sistematização do desenvolvimento usando 
processos tais como o Unified Process e a integração de novas tecnologias. Uma outra abordagem que recentemente vem 
ganhando adeptos é o Desenvolvimento Ágil de software. As seguintes afirmações dizem respeito a ele. 
I. Suas idéias principais estão divulgadas em um Manifesto para o Desenvolvimento Ágil de Software escrito pela Aliança 
Ágil (Agile Alliance), que reúne autores famosos como Martin Fowler, Alistair Cockburn, Scott Ambler, Ward Cunningham 
e Kent Beck; 
II. Desnvolvimento Ágil basicamente concentra-se em melhorias na comunicação (interna à equipe e com os clientes), na 
entrega incremental de várias versões funcionais do software continuamente até o fim do projeto e na maleabilidade e 
dinamicidade do desenvolvimento, facilitando as respostas às mudanças que aparecem durante este desenvolvimento. 
III. A técnica mais conhecida de Desenvolvimento Ágil é a Programação eXtrema (Extreme Programming - XP) que entre 
suas práticas possui programação em pares (pair programming), entregas pequenas (small releases) e frequentes, a 
propriedade coletiva do código (collective ownership), abolindo as práticas de teste e os padrões de codificação; 
Levando-se em conta as três afirmações I, II III acima, identifique a única alternativa válida: 
A) 
Apenas a I e a II estão corretas. 
- (CORRETA) 
B) 
Apenas a II e a III estão corretas. 
C) 
Apenas a I e a III estão corretas. 
D) 
Apenas a II e III estão corretas. 
E) 
Apenas a III está correta. 
Exercício 14 
No desenvolvimento em espiral, cada loop representa uma fase do processo de software. Identifique abaixo a opção que 
contém os quatro setores que compõem cada loop do desenvolvimento em espiral: 
A) 
Definição dos requisitos, análise, projeto e testes. 
B) 
Definição dos objetivos, planejamento, identificação dos riscos e testes. 
C) 
Requisitos, desenvolvimento, validação e evolução. 
D) 
Identificação dos riscos, projeto, implementação e testes. 
E) 
Definição de objetivos, avaliação e redução dos riscos, desenvolvimento e validação, e planejamento. 
- (CORRETA) 
Exercício 15 
Os modelos de ciclo de vida surgidos na área de Interação Humano-computador apresentam uma tradição mais forte de 
foco no usuário, quando comparados aos modelos de ciclo de vida da Engenharia de Software. Assinale a alternativa 
incorreta: 
A) 
O desenvolvimento de protótipos é parte integral do design iterativo centrado no usuário porque possibilita que designers 
testem suas idéias com usuários. 
EngElet ESwDOnLineSisDigIV Mod V: Metodologias de desenvolvimento 41/106 
B) 
O modelo de ciclo de vida Estrela surgiu de um trabalho empírico de observação de como os designers de interface de 
usuário trabalhavam. 
C) 
O modelo de ciclo de vida Estrela não especifica a ordem em que as atividades devem ser realizadas. 
D) 
O modelo de ciclo de vida Estrela é centrado na avaliação;