Escolar Documentos
Profissional Documentos
Cultura Documentos
Engenharia de Software
Elisamara de Oliveira
Claudinei Di Nuno
1
Engenharia de Software
Apresentação ..............................................................................4
2
Engenharia de Software
3
Engenharia de Software
4
Engenharia de Software
5
Engenharia de Software
do sistema e sua adaptação a novas condições de Spector e Gifford (1986, p. 268-273) realizaram
contorno. Os sistemas também podem se tornar um famoso estudo no qual comparavam a
complexos na medida em que novas versões são construção de pontes ao desenvolvimento de
criadas. software. Os autores partiam da premissa que as
pontes normalmente eram construídas no tempo
planejado, no orçamento e nunca caíam. Por outro
lado, os softwares nunca ficavam prontos dentro do
A crise do software
prazo e do orçamento, e, além disso, quase sempre
A crise do software foi uma expressão criada
apresentavam problemas.
para descrever as dificuldades enfrentadas no
desenvolvimento de software no final da década de
1960. O aumento da complexidade dos problemas 1.2 O Chaos Report
aliado à inexistência de técnicas bem estabelecidas e
à crescente demanda por novas aplicações indicavam Uma década mais tarde, em 1995, a organização
que medidas sérias deveriam ser tomadas. Essa crise
The Standish Group (1995) publicou um estudo
teve como origem a introdução de computadores
analisando as estatísticas sobre sucesso e fracasso
“mais poderosos”, e o advento desse hardware com
mais recursos tornava viáveis softwares bem maiores dos projetos de desenvolvimento de software: o
e mais complexos que os sistemas existentes. Chaos Report. Nesse estudo foi revelado que:
6
Engenharia de Software
Ao observar esses números, fica claro que mais manutenção, que ocorre após a entrega do produto
de 50 anos de experiência no desenvolvimento de e o início de sua operação. Seu principal objetivo
software não bastaram para melhorar efetivamente é fornecer uma estrutura metodológica para a
a qualidade do software, a despeito da evolução construção de um software com alta qualidade.
ocorrida na área de engenharia de software e
do ferramental disponível. Grady Booch, um dos Podemos definir engenharia de software como
criadores da UML (Unified Modeling Language), um processo que envolve a criação e a utilização
resumiu a história dizendo que uma “doença” de sólidos princípios de engenharia, a fim de obter
que dure tanto tempo quanto esta deveria ser softwares que sejam:
chamada de “anormalidade” (BOOCH; RUMBAUGH; • de alta qualidade;
JACOBSON; 2006) • produzidos de maneira econômica;
• confiáveis;
• de trabalho eficiente em máquinas reais;
• entregues no prazo;
• feitos gerando satisfação ao cliente.
7
Engenharia de Software
8
Engenharia de Software
No final do ciclo de vida do produto podem Notemos que esta é apenas uma teoria, já que
surgir problemas relacionados ao envelhecimento, a curva real do índice de falhas de um software
acúmulo de poeira, vibração, abuso, temperaturas considera o processo de manutenção e mudanças.
extremas, entre outros. Este processo pode ser
visto no Gráfico 1. Durante o processo de refinamento do produto
ou nas mudanças aumenta-se, consideravelmente,
a probabilidade de inserção de novos erros, gerando
picos na curva de falhas. As sucessivas alterações
do software tendem a introduzir mais erros antes
da estabilização de erros de alterações anteriores,
ocasionando a tendência crescente do índice de
falhas.
9
Engenharia de Software
Atualmente, a visão de reuso foi ampliada para mais elevados do que os projetados inicialmente e com
abranger não apenas algoritmos consagrados, mas uma qualidade aquém do esperado.
também estruturas de dados, interfaces gráficas b) Foi um termo criado para descrever as dificuldades
e diferentes classes e componentes orientados a enfrentadas no desenvolvimento de software no final
objetos. da década de 1960.
c) A complexidade dos problemas, a ausência de técnicas
bem estabelecidas e a crescente demanda por novas
Exercícios do Módulo 1 aplicações começavam a se tornar um problema sério.
1) Qual das questões abaixo não é mais d) Essa crise teve como origem a introdução de
uma das grandes preocupações de um computadores pessoais na década de 1970.
engenheiro de software?
a) Por que normalmente se gasta tanto tempo para 6) A essência da prática da engenharia de
desenvolver software? software pode ser resumida em compreender
b) Por que, via de regra, o software custa tão caro? o problema, planejar a solução, executar o
c) Por que quase sempre não se consegue remover plano e examinar o resultado.
todos os erros do software antes de sua entrega? a) Verdadeiro.
d) Por que o hardware é tão caro? b) Falso.
2) O software é um produto que pode ser 7) Qual dos itens listados abaixo não se
manufaturado usando as mesmas tecnologias constitui numa das camadas da engenharia
utilizadas para outros artefatos de engenharia. de software?
a) Verdadeiro. a) Processo.
b) Falso. b) Manufatura.
c) Métodos.
3) O software deteriora-se em vez de d) Ferramentas.
desgastar porque:
a) Ele “sofre” quando exposto a ambientes “hostis”. 8) Complete as lacunas:
b) Defeitos são mais prováveis de surgir quando o
O processo criativo do hardware gera algo
software é usado várias vezes.
_______. O desenvolvimento de software resulta
c) Mudanças frequentes aumentam a probabilidade
em um sistema lógico, _______. Os custos do
de se introduzir erros no software.
software estão concentrados no ________ e não
d) Componentes de reposição de software são difíceis
no processo de ________. Ao longo do tempo,
de encontrar no mercado.
o produto de software não se ________, mas
se ________em função da introdução de erros
4) Atividades “guarda-chuva” de oriundos de atividades de manutenção ou evoluções
engenharia de software são aplicadas somente do sistema.
durante as fases iniciais do desenvolvimento
de software.
a) Verdadeiro.
b) Falso.
10
Engenharia de Software
11
Engenharia de Software
Nesta fase, três etapas técnicas específicas O ciclo de vida de um software descreve as fases
ocorrerão: pelas quais o software passa desde a sua concepção
1) Projeto do software; até a descontinuidade de seu uso. O conceito de ciclo
2) Geração de código; de vida de um software é muitas vezes confundido
3) Teste de software. com o de modelo de processo, embora sejam bem
diferentes, como veremos a seguir.
3) Fase de manutenção: esta fase tem como
alvo as modificações e manutenções que o software
sofrerá. Durante ela, quatro tipos de modificações Aula 4 – Modelos prescritivos de
são encontradas: processo – Parte 1
• Manutenção corretiva: modifica o software para Os processos prescritivos são uma categoria
corrigir defeitos; que engloba os processos que possuem pontos
• Manutenção adaptativa: modifica o software para observáveis, ou seja, aqueles que a cada passo
acomodar mudanças em seu ambiente externo podem ser verificados e classificados como válidos
(processador, sistema operacional, etc.); ou sujeitos a ajustes.
• Manutenção de aperfeiçoamento: aprimora o software
além dos requisitos funcionais originais (cliente/usuário Enquanto um modelo descritivo retrata como
reconhece e solicita funcionalidades adicionais que um processo é executado, um modelo prescritivo
trarão benefícios, à medida que o software é usado). retrata como um processo deveria ser executado.
• Manutenção preventiva: faz modificações nos Assim, um modelo prescritivo é uma recomendação
programas de modo que eles possam ser mais que pode ser adaptada ou melhorada pela empresa/
facilmente corrigidos, adaptados e melhorados. equipe de software que for adotá-la.
12
Engenharia de Software
No modelo em cascata, também conhecido como ciclo de vida clássico, o processo de desenvolvimento
de software é visto como uma abordagem sistemática e sequencial, que começa com a especificação
dos requisitos do cliente e progride seguindo as etapas de planejamento, modelagem, construção e
implantação do sistema, culminando na manutenção progressiva do produto entregue, conforme ilustra
a Figura 3.
Esse modelo é o paradigma mais antigo da significativamente melhor do que uma abordagem
engenharia de software, sendo bastante criticado casual para o desenvolvimento de software.
em função dos problemas encontrados nos projetos
em que é aplicado. A realidade tem mostrado que 4.2 Modelos evolucionários de processo
num projeto raramente se segue o fluxo sequencial
que o modelo propõe, gerando problemas futuros Modelos evolucionários de processo são
que oneram os custos e prazos. Uma das causas aqueles que consideram a natureza evolutiva do
mais comuns deste problema é a dificuldade do software. Os modelos evolucionários são iterativos,
cliente em declarar claramente todas as suas sendo implementados de forma a permitir o
necessidades e expectativas, ou seja, de definir desenvolvimento de versões cada vez mais
todos os requisitos inicialmente. completas do software. Citamos a seguir algumas
de suas características:
O foco incorreto ou não claro pode gerar uma
distorção, que reflete diretamente na percepção de • São usados quando o deadline (limite de tempo) não
qualidade por parte do próprio cliente. Isso pode é adequado para o desenvolvimento do software, ou
levar a entregas parciais do produto, o que exige que seja, a data de término não é realística (por exemplo,
o cliente tenha muita paciência durante os aceites prazos reduzidos de mercado face à competitividade).
parciais que são formalizados em um Documento • Uma versão limitada pode ser introduzida para
de Encerramento do Projeto, com observações no atender a essa competitividade e às pressões do
campo Restrições “Entrega Parcial de Projeto”, que negócio.
contém detalhes quanto à aceitação condicional do • São liberados produtos core (núcleo dos produtos) ao
projeto por parte do cliente. longo do desenvolvimento.
• Os detalhes e extensões do projeto são definidos ao
Os trabalhos de desenvolvimento de software longo do desenvolvimento.
atuais seguem ritmos muito rápidos e sujeitos a
Os modelos que são agrupados nesta categoria
diversas modificações, o que torna o modelo em
são: prototipação, modelo espiral e modelo
cascata inadequado para esses tipos de projeto.
concorrente, que serão apresentados a seguir.
Cumpre ressaltar que, embora o modelo em cascata
ou ciclo de vida clássico tenha fragilidades, ele é
13
Engenharia de Software
14
Engenharia de Software
O modelo espiral foi desenvolvido para abranger as melhores características do modelo em cascata
e da prototipação, acrescentando, ao mesmo tempo, um novo elemento: a análise de riscos. Foi
desenvolvido por Barry Boehm (1988) em seu artigo intitulado A Spiral Model of Software Development
and Enhancement. Esse modelo foi o primeiro a explicar o porquê do modo iterativo e a elencar suas
vantagens.
As iterações têm uma duração típica de seis meses a dois anos. Cada fase inicia-se com um objetivo
esperado e termina como uma revisão do progresso pelo cliente, que deve ser interna, e assim por
diante. Esforços de análise e engenharia são aplicados em cada fase, tendo sempre o foco no objetivo do
projeto. A Figura 6 ilustra este processo.
As principais características desse modelo são: Trata-se de uma abordagem realística para o
desenvolvimento de software de grande porte.
• Engloba a natureza iterativa da prototipação e os
Como o software evolui na medida em que o
aspectos sistemáticos e controlados do modelo em
processo avança, o cliente e o desenvolvedor
cascata.
entendem melhor e reagem aos riscos em cada nível
• Fornece potencial para o desenvolvimento rápido de
evolucionário. Para pequenos projetos, o conceito
versões incrementais do software.
de desenvolvimento de software ágil torna-se uma
• O processo se inicia com a equipe de desenvolvimento
alternativa mais viável.
movendo-se em volta da espiral, no sentido horário, a
partir do centro.
Como vantagens desse modelo, podemos citar
• O primeiro circuito em torno da espiral pode resultar
as estimativas realísticas dadas à identificação de
na especificação do produto.
problemas importantes logo no início do processo,
• Nas primeiras iterações, a versão incremental pode
a versatilidade para lidar com mudanças (quando
ser um modelo em papel ou um protótipo.
inevitáveis), o desenvolvimento antecipado por
• Nas iterações mais adiantadas são produzidas versões
parte dos engenheiros de software — que têm
incrementais mais completas e melhoradas.
visibilidade das necessidades por fases — e o uso
15
Engenharia de Software
da prototipagem (em qualquer estágio de evolução Por exemplo, suponha que durante os estágios da
do produto) como mecanismo de redução de risco. etapa de projeto, descobre-se uma inconsistência
no modelo de análise. Isso geraria o evento
No entanto, o uso do modelo espiral exige “correção no modelo de análise”, que, por sua vez,
experiência significativa para determinar os riscos, implicaria na passagem da atividade de análise
sendo dependente dessa experiência para obter do estado “pronto” para o estado “aguardando
sucesso. Além disso, pode ser difícil convencer modificações”.
os clientes que uma abordagem “evolutiva” é
controlável. De forma geral, as principais características
desse modelo são:
4.2.3 Modelo de desenvolvimento
• Todas as atividades ocorrem em paralelo, mas estão
concorrente
em diferentes estados.
De acordo com Pressman (2010), o modelo de • O modelo define uma série de eventos que vão
desenvolvimento concorrente, também chamado disparar transições de estado a estado, para cada uma
de engenharia concorrente, pode ser representado, das atividades.
esquematicamente, como uma série de atividades • Em vez de usar uma sequência como o modelo em
de arcabouço, ações e tarefas da engenharia de cascata, ele define uma rede de atividades.
software e seus estados associados. • Eventos gerados dentro de certa atividade — ou em
algum outro lugar da rede de atividades — disparam
Um exemplo do uso desse modelo pode ver visto transições entre estados de uma atividade
na Figura 7, que traz a atividade “modelagem” do • Pode ser aplicado a todo tipo de desenvolvimento de
modelo Espiral (mostrado na Figura 6), espelhada software e fornece uma visão exata de como está o
no modelo concorrente. estado do projeto.
• Em vários projetos pode existir uma simultaneidade
(concorrência) entre as várias atividades de
desenvolvimento e de gestão de projetos.
• É representado como uma série de grandes atividades
técnicas, tarefas e seus estados associados (fornece
um panorama preciso do estado atual do projeto).
16
Engenharia de Software
17
Engenharia de Software
5) Note que todo o processo pode se repetir até que • Especificação: atividade em que se entende o
um produto completo seja produzido. problema de negócio, as características das informações
e é realizado o levantamento de requisitos.
5.1.2 Modelo RAD — Rapid Application
• Planejamento: atividade essencial. Várias equipes
Development
trabalham em paralelo em diferentes funções.
• Modelagem: estabelece representações de projeto
O modelo RAD é uma adaptação do modelo em
que servem como base para a atividade de construção.
cascata, mas que enfatiza um desenvolvimento
Abrange três fases:
extremamente rápido. A alta velocidade é
» Modelagem de negócio;
conseguida por uma abordagem de construção » Modelagem de dados;
baseada em componentes, ou seja, o sistema é » Modelagem de processo.
modularizado. • Construção: faz uso de componentes de softwares
preexistentes e geração de códigos.
Se os requisitos forem bem definidos e o objetivo • Implantação: estabelece a base para iterações
do projeto for restrito, a equipe pode criar um subsequentes, se necessárias.
sistema plenamente funcional em pouco tempo.
A Figura 9 apresenta a representação
O RAD enquadra-se no modelo de atividades de esquemática do modelo RAD em relação ao modelo
arcabouço do modelo em cascata: sequencial tradicional.
18
Engenharia de Software
19
Engenharia de Software
20
Engenharia de Software
Dentre os vários métodos de especificação formal adeptos, devido à maneira organizada e consistente
existentes, destacam-se o método Z, que já foi que oferece na condução de um projeto.
utilizado em várias aplicações práticas, e o método
de gramáticas de grafos, que possui uma linguagem O PU utiliza uma abordagem evolucionária paro o
visual de representação e descreve com naturalidade desenvolvimento de software. O ciclo de vida iterativo
fenômenos de sistemas concorrentes (PUCRS, 2012). é baseado em refinamentos e incrementos sucessivos,
a fim de convergir para um sistema adequado. Em
De uma maneira mais abrangente, o modelo cada iteração, procura-se incrementar um pouco
de métodos formais pode ser caracterizado da mais o produto, baseando-se na experiência obtida
seguinte forma: nas iterações anteriores e no feedback do usuário.
Cada iteração pode ser considerada um miniprojeto
• Permite especificar, desenvolver e verificar um
de duração fixa, sendo que cada um desses inclui
software por meio de uma rigorosa notação matemática.
suas próprias atividades de análise de requisitos,
• Fornece um mecanismo para eliminar muitos
projeto, implementação e testes.
problemas encontrados nos outros modelos, como por
exemplo, ambiguidade, incompletude e inconsistência,
O PU foi modelado usando o Software Process
que podem ser descobertos e corrigidos mais facilmente
Engineering Model (SPEM), que é um padrão para
por análise matemática.
modelagem de processos baseado em Unified
• Promete o desenvolvimento de software livre de
Modeling Language (UML). O processo tem duas
defeitos.
estruturas, ou duas dimensões, a saber:
• Consome muito tempo de desenvolvimento e é muito
caro. • Estrutura dinâmica: representa a dimensão do tempo
no processo.
Como poucos desenvolvedores possuem o
• Estrutura estática: descreve como elementos do
conhecimento necessário para utilizá-lo, são
processo são agrupados em disciplinas.
requeridos muitos cursos e treinamentos. É difícil
usar tais modelos matemáticos formais como meio de A estrutura que representa o tempo é denominada
comunicação com a maioria dos clientes. Assim, como fase e a estrutura que representa os elementos do
já dissemos, sua área de aplicação é muito restrita, processo são as disciplinas, que são descritas a
abrangendo, principalmente, aplicações críticas. seguir, baseado em IBM (2006). A Figura 11 ilustra
tais estruturas.
21
Engenharia de Software
O processo unificado organiza suas iterações em 3) Construção: visa à implementação iterativa dos
quatro fases principais: elementos restantes de menor risco e mais fáceis, além
da preparação para a implantação.
1) Concepção ou iniciação: o objetivo desta
4) Transição: testes finais e implantação.
fase é levantar, de forma genérica e pouco precisa, o
escopo do projeto. Não deve existir aqui a pretensão
de especificar de forma detalhada os requisitos; a ideia
é ter uma visão inicial do problema, estimar de forma Disciplinas
vaga o esforço e os prazos e determinar se o projeto é
Disciplina é uma coleção de atividades
viável e merece uma análise mais profunda.
relacionadas que estão ligadas à maior área de
2) Elaboração: na fase de elaboração todos (ou
interesse dentro do processo em geral. Cada
a grande maioria dos requisitos) são levantados em
disciplina possui, resumidamente, os seguintes
detalhes. Numa primeira iteração, um ou dois requisitos
objetivos específicos:
(os de maior risco e valor arquitetural) são especificados
em detalhes. Estes são implementados e servem como • Modelagem de negócios: entender a estrutura
base de avaliação junto ao usuário e desenvolvedores e a dinâmica da organização para a qual o produto
para o planejamento da próxima iteração. Em cada será desenvolvido; identificar problemas correntes na
nova iteração na fase de elaboração pode haver um organização e possíveis aperfeiçoamentos; assegurar
seminário de requisitos, em que requisitos antigos são que o cliente, o usuário final e os desenvolvedores
melhor esclarecidos e os novos são detalhados. Ao fim possuam a mesma compreensão da empresa; produzir
dessa fase, deseja-se que 90% dos requisitos tenham os requisitos de sistemas necessários para suportar os
sido levantados em detalhes, que o núcleo do sistema objetivos da organização.
tenha sido implementado com alta qualidade, que • Requisitos: estabelecer e manter o consentimento
os principais riscos tenham sido tratados e que haja entre clientes e stakeholders sobre o que o sistema
condições para se fazer estimativas mais realistas. deve fazer; fornecer uma melhor compreensão dos
requisitos aos desenvolvedores; definir os limites
do sistema; fornecer as bases para o planejamento
22
Engenharia de Software
23
Engenharia de Software
Alguns críticos do processo ágil afirmam que • Intercalação das etapas de projeto e construção, que
o maior risco desse tipo de abordagem é a baixa vão sendo realizadas juntas, de modo que os modelos
qualidade ou mesmo inexistência de documentação de projeto vão sendo comprovados na medida em que
do projeto devido à interação humana face a face são criados;
que, se por um lado traz agilidade na comunicação, • Falta de previsibilidade da análise, projeto, construção
por outro traz a informalidade nas definições. Assim e testes do ponto de vista do planejamento, como seria
sendo, é necessário um bom acompanhamento do desejado.
gestor do projeto para garantir a qualidade dos
A metodologia ágil vem gerando grande
trabalhos, independente do processo utilizado.
debate entre desenvolvedores apaixonados e
críticos ferrenhos. Contudo, deve-se manter a
De forma geral, os processos ágeis atendem
imparcialidade profissional e questionar o que
aos projetos de software que, normalmente,
apresentam: realmente tem que ser observado, como:
• Dificuldade em prever com antecedência quais • Qual é a melhor forma de se alcançar a agilidade nos
requisitos vão persistir e quais serão modificados, bem processos e práticas do desenvolvimento de software?
como quais prioridades dos clientes sofrerão mudanças • Como construir softwares que satisfaçam às
ao longo do projeto; necessidades do cliente e possuam características de
24
Engenharia de Software
25
Engenharia de Software
26
Engenharia de Software
14) O que não caracteriza os modelos • Valorizar a colaboração com o cliente mais do que a
evolucionários de processo? negociação de contratos;
• Valorizar responder a mudanças mais que seguir um
a) São implementados de forma a permitir o
plano.
desenvolvimento de versões cada vez mais completas
do software. Referem-se a ___________________.
b) São usados quando o deadline (limite de tempo)
não é adequado para o desenvolvimento do software,
ou seja, a data de término não é realística (por exemplo, 18) Nos modelos de processos ágeis o único
prazos reduzidos de mercado face à competitividade). produto de trabalho gerado é o programa de
c) São liberados produtos core (“núcleo dos trabalho.
produtos”) ao longo do desenvolvimento. a) Verdadeiro.
d) Os detalhes e extensões do projeto são definidos b) Falso.
logo no início, antes do desenvolvimento.
17) Os princípios:
27
Engenharia de Software
28
Engenharia de Software
29
Engenharia de Software
30
Engenharia de Software
realidade o que querem do sistema computacional, requisitos, alguns serão mais importantes do que outros.
a não ser em termos muito gerais. Eles costumam Esse estágio envolve a interação com os stakeholders para
termos e com o conhecimento implícito de sua área • Verificação de requisitos: os requisitos são verificados, a
31
Engenharia de Software
32
Engenharia de Software
• Gerenciamento de mudanças: esse processo pode aos requisitos funcionais, descrevendo processos de
ser simplificado se o apoio de ferramentas estiver negócio, informações e interação com o produto de
disponível. forma apropriada a ser documentada textualmente; d)
• Gerenciamento de facilidade de rastreamento: o aos requisitos não funcionais, tais como nível de serviço,
apoio de ferramentas para a rastreabilidade permite desempenho, cuidados, segurança, atendimento a leis
que sejam descobertos requisitos relacionados. e regulamentos, etc.; e) aos impactos em outras áreas
organizacionais e f) aos impactos em outras entidades
internas ou externas à organização.
33
Engenharia de Software
Completo O requisito contém tudo que o software deve fazer e atender em todas as situações possíveis.
Conciso É tão pequeno quanto possível, sem afetar qualquer outra qualidade que deva atender.
Anotado por Permite que se possa facilmente determinar qual requisito é mais importante para os clientes.
importância
relativa
Anotado por Permite que se possa facilmente determinar qual requisito é mais suscetível à mudança.
estabilidade
relativa
Entrevistas
34
Engenharia de Software
35
Engenharia de Software
36
Engenharia de Software
Prototipação
37
Engenharia de Software
38
Engenharia de Software
O software precisa gerar o resultado esperado e, por isso, testá-lo envolve planejar e controlar a
aplicação, além de validar seus resultados. O principal objetivo sempre será a busca de qualidade.
Neste módulo você entenderá esses conceitos, o que ajudará a conhecer as técnicas, estratégias e a
importância dos testes de software.
Para começarmos a falar sobre testes, precisamos entender primeiro a diferença entre defeito, falha
e erro (veja Figura 15).
• Defeito: ocorre quando há uma instrução ou comando incorreto. Um veículo, por exemplo, apresenta defeito
quando não obedece ao comando do motorista.
• Falha: é um comportamento inconsistente. No exemplo do veículo, quando ocorre uma falha, ele continua
funcionando de forma precária, mas não para.
• Erro: é um desvio da especificação. Em um veículo seria semelhante a quando ocorre uma montagem indevida
de algum componente.
Mas por que é importante termos bem definidas Na tentativa de destruir a confiança para
essas diferenças? Considere a seguinte frase: “A encontrar defeitos, falhas ou erros, na verdade
melhor maneira de tentar construir a confiança é estamos construindo uma confiança cada vez mais
tentar destruí-la”. sólida no produto desenvolvido.
Parece um paradoxo, concorda? Pois saiba que Pense, por exemplo, nos exaustivos testes
não apenas parece, mas é um paradoxo. automobilísticos, quando as montadoras
literalmente destroem seus veículos para provar a
39
Engenharia de Software
40
Engenharia de Software
ser integrados até que todo o sistema seja construído. permitir um acompanhamento gerencial na medida
A partir desse ponto uma série de testes de alto nível é em que o projeto progride.
executada para descobrir erros relativos aos requisitos
do cliente. À medida que erros forem encontrados, O plano de teste deve definir conjuntos de
é necessário se fazer um diagnóstico e buscar sua critérios de conclusão para os testes unitários, de
correção pelo processo de depuração do sistema. integração e de sistema. Pode haver diferentes
• O que é uma especificação de testes? É um conjuntos de critérios de conclusão definidos para
documento que relata a abordagem da equipe que iterações individuais. Uma estratégia para testes
realiza os testes, definindo um plano que descreve a de software pode ser vista no contexto da espiral
estratégia global e um procedimento que define os mostrada na Figura 16.
passos específicos dos testes, bem como quais testes
serão realizados.
• Como ter certeza que os testes foram feitos
corretamente? Para certificar-se sobre esse aspecto
deve-se realizar uma revisão na especificação do teste
antes de realizá-lo, de forma a avaliar a completeza dos
casos e das tarefas elencadas. Um plano e procedimento
de testes efetivos vão levar à construção coordenada
do software e à descoberta de erros em cada fase da Figura 16. Espiral de estratégia de testes.
Fonte: Pressman (2010).
construção do projeto.
O teste de unidade começa no centro da espiral
De acordo com IBM (2006), uma estratégia
e concentra-se em cada componente (trecho
para o teste de um projeto descreve a abordagem
de código-fonte) do software. O teste progride
geral e os objetivos das atividades de teste. Ela
movendo-se para fora ao longo da espiral, indo em
inclui os estágios de teste (unidade, integração e
direção ao teste de integração, que foca no projeto
sistema) que devem ser abordados e os tipos de e na construção da arquitetura do software.
teste (de função, desempenho, carga, estresse,
etc.) que devem ser executados. A estratégia deve Seguindo para fora da espiral, há o teste de
definir as ferramentas e técnicas de teste a serem validação, no qual os requisitos são validados, ou
empregadas e os critérios de conclusão e êxito que seja, a especificação dos requisitos é confrontada
serão usados. com o software que acabou de ser construído.
Finalmente, chega-se ao teste de sistema, em
que os outros elementos do software são testados
Uma estratégia de testes de software integra
como um todo.
métodos de projeto de casos de teste em uma
série bem planejada de passos, que resultam na
Sommerville (2007) e Pressman (2010)
construção bem sucedida de software. A estratégia
descrevem, de forma complementar, esses estágios
fornece um roteiro que descreve os passos a serem
conduzidos como parte do teste, quando esses passos
de teste da seguinte forma:
são planejados e depois executados, além do quanto • Teste de unidade: é também conhecido como
de esforço, tempo e recursos serão necessários teste unitário. Avalia a menor unidade do código e seu
(PRESSMAN, 2010). objetivo é verificar falhas de funcionamento em partes
pequenas independentes do software. Possibilita
Além de enfatizar a importância da estratégia uma análise mais profunda e específica de uma
de testes, Pressman (2010) afirma que esta função independente do resto do código, facilitando a
deve ser suficientemente flexível para criar uma descoberta de erros nos limites dos módulos. Esse teste
abordagem de teste sob medida para o projeto tem como base estratégica o teste de caixa branca.
Nesse teste, os casos são projetados para descobrir
em desenvolvimento, mas ao mesmo tempo ser
erros devido a computações errôneas, comparações
rígida para promover um planejamento adequado e
incorretas ou fluxo de controle impróprio.
41
Engenharia de Software
• Teste de integração: avalia diferentes componentes » Teste de segurança: nesse caso o testador
que são desenvolvidos separadamente mas trabalham tenta penetrar no sistema provocando ações que
em conjunto. Ao avaliar esses componentes de forma prejudiquem alguém. Ele usa formas ilegais ou
isolada, consegue-se encontrar possíveis falhas no impróprias simulando condições extremas de violação
resultado apresentado em consequência do mau das informações.
funcionamento ou erro de algum dos componentes. » Teste de estresse: esse procedimento cria ambientes
• Teste de validação: avalia o software em um extremos para utilização do software. Volumes
ambiente específico, considerando os requisitos definidos anormais e frequência irregular têm como objetivo
pelo cliente em uma situação próxima à realidade. Tem forçar falhas por sobrecarga, verificando as possíveis
como objetivo provar ao cliente que o software atende interrupções e consequências de paradas anormais
às solicitações desejadas. por estresse. Os dados, então, são avaliados para ver
• Teste de sistema: tenta impor a visão do cliente, se não foram corrompidos ou perdidos.
dando normalmente uma perspectiva diferente ao » Teste de desempenho: todo sistema desenvolvido
testador. Normalmente executa-se em um ambiente tem em sua especificação de requisitos o desempenho
que se assemelha ao ideal. Seu objetivo é pôr o sistema adequado de funcionamento e após a integração dos
desenvolvido completamente à prova, com todos os componentes uma avaliação é indispensável para se
elementos adequadamente integrados e realizando obter o seu desempenho real.
suas funções corretamente. Em testes de sistemas
De acordo com Pressman (2010), do ponto
encontramos pelo menos quatro tipos de testes:
de vista procedimental, o teste no contexto da
» Teste de recuperação: esse procedimento avalia
engenharia de software é uma série de quatro
a recuperação de uma falha dentro de um tempo
passos que são implementados sequencialmente,
especificado em caso de falha. Podem ocorrem várias
conforme mostra a Figura 17.
falhas forçadas para verificar a recuperação.
Inicialmente o teste focaliza cada componente conjunto de testes de alto nível é conduzido, de
individualmente, garantindo que ele funcione forma que critérios de validação de requisitos
adequadamente como uma unidade. Em seguida, sejam avaliados. O último passo avança para
os componentes devem ser montados ou integrados fora dos limites da engenharia de software, indo
para formar um pacote de software completo. em direção ao sistema de computação. O teste
Depois que o software tiver sido integrado, um de sistema verifica se todos os elementos estão
42
Engenharia de Software
ajustados de forma que a função e o desempenho de execução periódica causa também acúmulos de
global do sistema sejam alcançados. erros ou falhas, que podem tornar a implementação
de melhorias incompatível com o cumprimento de
Uma estratégia de teste deve acomodar testes prazos estabelecidos.
de baixo nível, que atuem na identificação de
problemas em um pequeno segmento do código-
fonte e testes de alto nível, que validam as principais Aula 13 – Tipos de testes de software
funções do sistema levando em consideração os
requisitos do cliente. A estratégia fornece diretrizes 13.1 Testes automatizados
aos profissionais e um conjunto de referências para
o gestor. De acordo com Bastos et al. (2007), quanto mais
cedo se iniciarem os testes, mais barata será a
Existem testes rápidos e alguns mais demorados correção dos erros encontrados e, para conquistar
para serem realizados. A definição de prioridades é
esse benefício, o processo de teste, assim como o
essencial para o sucesso na execução dos testes.
processo de desenvolvimento, deve ter um ciclo de
Pressman (2010) garante que o teste de software vida, que é definido em fases.
é um fator decisivo para garantir a qualidade de
Ainda segundo os autores, o ciclo de vida
um programa. Ainda de acordo com o autor, alguns
testes, por sua simplicidade, podem ser executados dos testes de software compreende as etapas
a todo momento, como os testes de longevidade. que envolvem: planejamento, preparação,
Há outros que devem ser programados, como os procedimentos iniciais, especificação, execução e
testes de segurança e desempenho, os quais geram entrega, como mostra a Figura 18.
invariavelmente lentidão das ferramentas que
necessitam utilizar. Outros tipos de testes, como
carga e estresse, não precisam ser executados
frequentemente, pois avaliam a infraestrutura e
esta normalmente não é alterada com frequência.
teste, pois esse framework atua com entregas Segundo Pressman (2010), o teste frequente
imediatas — o que exige validação imediata. responde por mais esforço de projeto do que
qualquer outra atividade de engenharia de software.
É importante destacar que executar testes
Se for conduzido ao acaso, há um desperdício de
com frequência é fundamental. É mais vantajoso
executar baterias pequenas e frequentes de testes tempo e esforço e, mais do que isso, erros se
do que uma rara e grande bateria. Além disso, infiltram sem serem descobertos. Assim, seria
as baterias de testes que não são executadas razoável estabelecer uma estratégia sistêmica para
com frequência podem se tornar obsoletas, o teste de software.
correndo o risco de ficarem desatualizadas e,
consequentemente, não acompanharem a evolução Testes automatizados podem fazer a diferença
natural dos componentes relacionados. no que diz respeito à confiança que um software
desenvolvido pode alcançar. Como qualquer
Ressalta-se ainda que quanto mais obsoleto se artefato, o código-fonte dos testes automatizados
torna um teste, mais caro fica, comprometendo e os documentos gerados requerem qualidade. À
recursos e podendo, no momento mais importante, medida que aumenta a complexidade do software,
não atender à solicitação de seus usuários. Sua falta
43
Engenharia de Software
44
Engenharia de Software
45
Engenharia de Software
vezes em modo manual, para depois que houver de tempo só podem ser detectados num ambiente
a comprovação do sucesso de sua utilização serem controlado. De acordo com Silva (2012), existem tipos
automatizados. Citamos na sequência alguns distintos de testes de desempenho, como os testes de
desses testes: configuração — que, da mesma forma que o teste de
longevidade, visam identificar configurações otimizadas
• Teste de desempenho: teste que determina o
de hardware e software para a execução correta da
desempenho de um sistema. As ferramentas que
aplicação — e os testes de contenção — que avaliam
apoiam os testes de desempenho possuem duas
a forma como o sistema gerencia demandas para
facilidades, a saber, geração de carga e mensuração
um mesmo recurso computacional (memória, dados,
das transações do teste. De acordo com Silva (2012),
processador, etc.).
a geração de carga pode simular múltiplos usuários
• Teste de segurança: os testes de segurança
ou grandes volumes de dados de entrada. Durante a
normalmente requerem uma infraestrutura similar à do
execução, os tempos de resposta para determinadas
ambiente de produção, pois se espera que esse tipo
transações são medidos e registrados. As ferramentas
de teste exponha as vulnerabilidades do sistema no
de teste de desempenho, normalmente, fornecem
ambiente adequado. Testes de segurança garantem
relatórios baseados nos registros dos testes e gráficos
a confidencialidade, integridade e disponibilidade das
da carga em função dos tempos de resposta.
informações. Um dos problemas relacionados a ele é o
• Teste de carga: teste que mede o comportamento
buffer overflow, ou a necessidade maior de capacidade
de um sistema com uma carga crescente, como por
de armazenamento.
exemplo, número de usuários paralelos e/ou números
• Teste de correção: os testes de correção (unidade,
de transações, para determinar qual a carga que ele
integração, aceitação, etc.) não necessitam das mesmas
pode suportar. Para Silva (2012), esses testes indicam
dependências. Têm como objetivo revelar a presença
também o tempo de resposta de transações e processos
de erros, descobrindo o maior número possível deles.
de negócios, com o intuito de determinar se a aplicação
está de acordo com as expectativas documentadas e Uma vez que o software tenha sido elaborado, é
determinadas pelo cliente. necessário fazer a implementação de testes manuais
• Teste de estresse: teste que avalia a execução de ou automatizados. Isso pode exigir conhecimento
um sistema ou componente no limite (ou acima) dos multidisciplinar, ou seja, conhecimento de
requisitos especificados. Esses testes determinam a programação, de testes de software, de linguagem
carga necessária para que o sistema falhe e avaliam seu de negócio e de ferramentas específicas. Portanto, o
comportamento em condições anormais. Podem incluir, profissional responsável pelos testes automatizados
além de cargas de trabalho extremas, insuficiência normalmente é diferenciado.
de memória e recursos de processamento limitados.
Avaliam também a capacidade que o software tem de Segundo Schach (2007), implementar refere-se
se recuperar de uma falha mantendo a integridade dos ao processo de converter o projeto detalhado de
dados (SILVA, 2012). um sistema de software em código. Se apenas uma
• Teste de longevidade: nesse teste é avaliado o única pessoa realizasse este trabalho, o processo
funcionamento do sistema em médio e longo prazo. Seu seria mais fácil, mas a maioria dos produtos de
objetivo é detectar influências externas ao software, software são muito grandes e complexos, exigindo
principalmente de hardware ou sistema operacional. uma equipe de desenvolvedores. Em cenários
Fatores como grandes volumes armazenados, tamanho mais realistas, diversas pessoas trabalham
ou limpeza do cache podem ser decisivos na eficiência simultaneamente e em diferentes componentes
em médio e longo prazo de um software. do sistema. Isso gera um fator complicador ao
• Teste de avaliação de desempenho: muitos problemas processo de testabilidade. Assim, desenvolvedores
de desempenho que podem surgir após o sistema ser e testadores devem trabalhar de forma colaborativa
submetido à carga extrema durante um longo período e integrada.
46
Engenharia de Software
a) Sistema.
b) Correção.
c) Estresse.
d) Integração.
a) Testes oficiais.
b) Testes de equivalência.
c) Testes frequentes.
d) Testes manuais.
e) Testes automatizados.
47
Engenharia de Software
48
Engenharia de Software
49
Engenharia de Software
práticas cujo objetivo é melhorar os processos 15.1 Visão geral do modelo CMMI
organizacionais e sua habilidade para gerenciar o
desenvolvimento, a aquisição e a manutenção de O CMMI está organizado em três modelos (veja
produtos e serviços de software. Figura 20) chamados de constelação, cada um
contendo práticas para áreas de desenvolvimento,
serviços e de aquisição:
A organização pode usar o modelo CMMI para cultura voltada para o planejamento, a qualidade e
ajudar a estabelecer objetivos e prioridades do o controle dos processos de desenvolvimento dos
melhoramento de processos, obtendo um guia softwares.
para garantir estabilidade, processos estáveis e
maduros. Mas o CMMI não é um modelo simples O CMMI possui duas representações: contínua
de ser implantado, pois exige uma mudança de ou por estágios. Estas representações permitem
50
Engenharia de Software
à organização utilizar diferentes caminhos para primeira diferença que vemos é a quantidade de
a melhoria de seus processos de acordo com seu níveis: na contínua são seis níveis (de capacidade)
interesse. Estas representações serão detalhadas e a contagem começa do nível 0, enquanto na
a seguir. representação por estágios são cinco níveis (de
maturidade) e começa-se do nível 1. Os níveis da
15.2 Representação contínua esquerda (contínua) representam a capacidade
e por estágios de um processo, ao passo que os da direita
(por estágios) representam a maturidade da
O propósito do CMMI é fornecer um guia organização.
para melhorar processos de organizações e sua
habilidade de gerenciar o desenvolvimento,
aquisição e manutenção de produtos ou serviços
de software. O CMMI, por meio de sua estrutura,
ajuda a organização a avaliar sua maturidade
organizacional ou sua capacidade na área de
processos, estabelecendo prioridades para
melhoramentos e sua implementação.
51
Engenharia de Software
52
Engenharia de Software
análises de custo/benefício das novas tecnologias e tem o apoio do Ministério da Ciência, Tecnologia
das mudanças propostas com base nos dados sobre e Inovação (MCTI), Financiadora de Estudos e
a efetividade dos processos. Lições aprendidas em Projetos (FINEP), Serviço Brasileiro de Apoio às
projetos bem sucedidos e causas de fracassos são Micro e Pequenas Empresas (SEBRAE) e Banco
disseminadas para outros projetos. A participação Interamericano de Desenvolvimento (BID/FUMIN).
e empowerment da força de trabalho, alinhada
com os objetivos e valores da organização e seus Segundo o SOFTEX (2012), as iniciativas
negócios, impulsiona a otimização de processos, desse programa buscam que ele seja adequado
que passam a ser velozes e inovadores. A melhoria ao perfil de empresas com diferentes tamanhos e
de processos passa a ser parte da atividade de características, públicas e privadas, embora com
todos, levando a um ciclo de melhoria contínua. especial atenção às micro, pequenas e médias
empresas. Adicionalmente, outro objetivo do projeto
é replicar o modelo na América Latina, incluindo o
Caro aluno, assista à animação sobre CMMI,
disponível em: http://www.youtube.com/watch?v=k Chile, Argentina, Costa Rica, Peru e Uruguai.
F8sxDDoRns&feature=youtu.be
O modelo MPS segue os modelos e normas
internacionais mais aceitos no mercado. Está em
Aula 16 – O modelo de qualidade MPS.BR conformidade com as normas internacionais ISO/
IEC 12207 e ISO/IEC 15504, é compatível com o
16.1 Visão geral do modelo MPS.BR modelo CMMI, baseado nas melhores práticas da
engenharia de software e é adequado à realidade
O MPS.BR (Melhoria das empresas brasileiras. Assim, o modelo é
de Processo de compatível com os padrões de qualidade aceitos
Software.Brasileiro) foi internacionalmente e tem como pressuposto o
criado em dezembro de aproveitamento de toda a competência existente
2003, coordenado pela nos padrões e modelos de melhoria de processo já
SOFTEX (Associação disponíveis.
para Promoção da
O modelo MPS, conforme definido pelo Softex
Excelência do Software
(2012), baseia-se nos conceitos de maturidade e
Brasileiro). O programa tem por objetivo a melhoria
capacidade de processo para a avaliação, melhoria
de processo para o desenvolvimento de software
da qualidade e produtividade de software e serviços
brasileiro, visando aumentar a competitividade
correlatos, bem como para a melhoria da qualidade
da indústria brasileira de software nos mercados
e produtividade dos serviços prestados. Dentro
interno e externo, por meio de programas de
desse contexto, o modelo MPS possui quatro
qualificação de profissionais nessa área e de
componentes:
melhoria e avaliação de processos e produtos
de software brasileiros a um custo acessível às • Modelo de referência MPS para software (MR-MPS-
empresas de menor porte. SW);
• MPS para serviços (MR-MPS-SV);
O MPS.BR conta com a participação de • Método de avaliação (MA-MPS);
representantes de universidades, instituições • Modelo de negócio para melhoria de processo de
governamentais, centros de pesquisa e de sotware e serviços.
organizações privadas, os quais contribuem
Cada componente é descrito por meio de guias
com suas visões complementares que agregam
e/ou documentos do modelo MPS, como pode ser
qualidade ao empreendimento. Além disso, o MPS.
visto na Figura 22.
BR recebe investimentos de empresas privadas e
53
Engenharia de Software
54
Engenharia de Software
55
Engenharia de Software
nacionais, que precisavam encontrar uma forma Tabela 2. Equivalência entre os níveis de
de adaptar à sua realidade, rapidamente, modelos maturidade CMMI x MPS.BR.
para melhoria de processos de software como o
CMMI níveis 2 e 3, a um custo mais acessível. Comparação dos níveis de maturidade
CMMI MPS.BR
Os dois modelos apresentam níveis de
maturidade que definem a capacidade da empresa 1 Não é definido
para trabalhar com projetos grandes e complexos.
2 G
Como vimos, o CMMI varia do 1 ao 5 e o MPS.BR
varia do G ao A. Ao contrário do CMMI, o primeiro F
nível do MPS.BR já exige que a empresa tenha
determinados processos definidos (ITS, 2014). 3 E
Analisando a Tabela 2, podemos verificar que os níveis do MPS.BR permitem que a empresa implante
processos de uma forma mais gradual. Essa estratégia aplicada ao mercado brasileiro de software permite
que empresas de pequeno porte, que não possuem muito dinheiro para investir em metodologias e
processos, possam tomar a iniciativa de definir processos.
O MPS.BR e o CMMI possuem níveis equivalentes de qualidade de software, mas a norma brasileira
tem a vantagem de ser muito mais barata, além de existir financiamento do BID para grupos de empresas
que desejem se certificar (ITS, 2014).
56
Engenharia de Software
57
Engenharia de Software
58
Engenharia de Software
Fontes: http://marketplace.pmi.org/Pages
Aula 17 – Conceitos básicos do http://brasil.pmi.org/brazil/AboutUS/
WhatIsProjectManagement.aspx
gerenciamento de projetos
17.1 O Guia PMBoK – Project 17.2 O gerente de projetos
Management Body of Knowledge e os stakeholders
59
Engenharia de Software
60
Engenharia de Software
61
Engenharia de Software
13. Planejar o
gerenciamento do
cronograma
14. Definir as atividades
15. Sequenciar
as atividades Incluir os processos
Planejamento necessários para o
3. Gerenciamento 16. Estimar os recursos
cumprimento do término
de tempo das atividades
do projeto dentro do
17. Estimar as durações prazo estipulado
das atividades
18. Desenvolver
o cronograma
19. Controlar o
Monitoramento e controle
cronograma
Áreas de conhecimento Processos Grupos de processo Resumo
20. Planejar o
gerenciamento dos custos Planejar, estimar, orçar
21. Estimar os custos Planejamento e controlar os custos
4. Gerenciamento
a fim de encerrar o
de custos 22. Determinar projeto dentro do
o orçamento orçamento aprovado
23. Controlar os custos Monitoramento e controle
24. Planejar o
gerenciamento Planejamento
Garantir a qualidade
da qualidade
5. Gerenciamento do projeto e a melhoria
da qualidade 25. Realizar a garantia contínua dos processos
Execução
da qualidade do início ao fim
26. Controlar a qualidade Monitoramento e controle
27. Planejar o
gerenciamento dos Planejamento
Recursos Humanos
28. Mobilizar a
6. Gerenciamento de equipe do projeto Organizar e gerenciar
Recursos Humanos a equipe do projeto
29. Desenvolver a
Execução
equipe do projeto
30. Gerenciar a
equipe do projeto
31. Planejar o
gerenciamento das Planejamento
comunicações Planejar, gerenciar e
7. Gerenciamento controlar as comunicações
32. Gerenciar as
das comunicações Execução de forma adequada
comunicações
e bem-sucedida
33. Controlar as
Monitoramento e controle
comunicações
62
Engenharia de Software
34. Planejar o
gerenciamento de riscos
35. Identificar os riscos
36. Realizar a análise Aumentar a probabilidade
qualitativa dos riscos Planejamento e o impacto dos eventos
8. Gerenciamento
37. Realizar a análise positivos e diminuir a
de riscos
quantitativa dos riscos probabilidade e o impacto
dos eventos adversos
38. Planejar as
respostas aos riscos
39. Monitorar e
Monitoramento e controle
controlar os riscos
Áreas de conhecimento Processos Grupos de processo Resumo
40. Planejar as aquisições Planejamento
Gerenciar os processos
41. Conduzir as aquisições Execução de aquisições de
9. Gerenciamento
42. Administrar produtos, serviços
de aquisições Monitoramento e controle
as aquisições ou resultados para a
realização do projeto
43. Encerrar as aquisições Encerramento
44. Identificar as
Iniciação
partes interessadas
45. Planejar o
gerenciamento das Planejamento
partes interessadas Gerenciar os stakeholders
10. Gerenciamento das
46. Gerenciar o durante todo o ciclo
partes interessadas
engajamento das Execução de vida do projeto
partes interessadas
47. Controlar o
engajamento das Monitoramento e controle
partes interessadas
Fonte: adaptado de PMI (2012).
63
Engenharia de Software
4) Sobre o PMBoK, é correto afirmar 7) Qual dos itens listados abaixo não se
que “apresenta conhecimentos sobre o constitui uma área de conhecimento do PMBoK?
gerenciamento de projetos e foi realizado
a) Comunicações.
pelo PMI – Project Management Institute –
b) Riscos.
desde 1983, com o intuito de documentar os
c) Métodos.
processos de gerenciamento de projetos”.
d) Aquisições.
a) Verdadeiro.
b) Falso.
64
Engenharia de Software
65
Engenharia de Software
b) Manufatura
c) Especificação, planejamento, modelagem,
construção, implantação (entrega).
66
Engenharia de Software
10) Podemos dizer que o modelo de 16) Assinale a alternativa que não é
desenvolvimento baseado em componentes: característica do processo unificado:
11) O modelo de métodos formais faz uso O correto seria: é um framework genérico de
de métodos matemáticos para: um processo de desenvolvimento.
67
Engenharia de Software
18) Nos modelos de processos ágeis o único • Que forneça uma base para validação e verificação
produto de trabalho gerado é o programa de do produto;
trabalho. • Que facilite a manutenção do produto de software
final.
b) Falso.
Módulo 4
Módulo 3 1) Uma falha:
1) Stakeholder é qualquer pessoa que vá
c) É um comportamento inconsistente.
comprar o software em desenvolvimento.
2) Assinale a alternativa correta: um dos
a) Falso.
problemas relacionados a este teste é o
buffer overflow, ou a necessidade de maior
2) É relativamente comum para diferentes
capacidade de armazenamento:
usuários propor requisitos conflitantes, cada
qual argumentando que sua versão é a mais
a) Segurança.
adequada ou melhor.
3) Assinale a alternativa correta: tem
a) Verdadeiro.
como objetivo revelar a presença de erros.
Descobre o maior número possível deles,
3) Na validação de requisitos, o modelo
alguns dependendo do desenvolvimento
de requisitos é revisto para assegurar sua
previamente já identificado para comprovar a
viabilidade técnica.
eficiência do teste.
b) Falso.
b) Correção.
4) Faça a associação e assinale a resposta
4) São programas ou scripts simples que
correta sobre a técnica PIECES:
exercitam funcionalidades do sistema sendo
a) i-c ii-e iii-a iv-b v-f vi-d testado e fazem verificações automáticas nos
efeitos colaterais obtidos.
5) Assinale a afirmativa ERRADA:
e) Testes automatizados.
c) Requisitos não-funcionais: são requisitos que
não dizem respeito diretamente à funcionalidade 5) Podemos afirmar sobre testes de baixo
do sistema, mas expressam suas propriedades e/ nível:
ou restrições sobre os serviços ou funções por ele
providas. Exemplos de requisitos não funcionais: d) Atuam na identificação de problemas em um
cadastro de cliente; emissão de nota fiscal; consulta pequeno segmento do código-fonte.
ao estoque; geração de pedido.
6) Alguns testes, por sua simplicidade,
podem ser executados frequentemente, como
O correto seria: Exemplos de requisitos
os testes de longevidade. Há outros que devem
funcionais: cadastro de cliente; emissão de nota
ser programados, como os testes de segurança
fiscal; consulta ao estoque; geração de pedido.
e desempenho, os quais geram invariavelmente
6) Quais os benefícios esperados de um lentidão por causa das ferramentas que
documento de especificação de requisitos? necessitam utilizar. Outros tipos de testes,
como carga e estresse, não precisam ser
• Que estabeleça a base de acordo entre os clientes e a
executados a o todo momento, pois avaliam
empresa fornecedora sobre o que o software irá fazer;
a infraestrutura e esta normalmente não é
• Que reduza o esforço de desenvolvimento;
alterada com frequência.
• Que forneça uma base para estimativas de custo e
prazos;
68
Engenharia de Software
i. A avaliação de produtos de software é definida como (V) No modelo MPS.BR, um nível é alcançado quando
uma operação técnica que consiste em elaborar um os propósitos e todos os resultados esperados dos
julgamento de uma ou mais características de um respectivos processos são atendidos. Os níveis são
produto de software de acordo com um procedimento acumulativos.
definido. (F) O nível mais baixo (o correto seria: alto) do MPS.
ii. As normas da ISO mais conhecidas que abordam a BR é o nível A; logo, o nível mais alto (o correto seria:
qualidade de produto (o correto seria: de processo) de baixo) é o nível G.
software são a norma ISO/IEC 12207 e a norma ISO/ (V) O nível de maturidade A é composto pelos níveis G,
IEC 15504. F, E, D, C e B, acrescido do processo análise de causas
iii. O ANSI (American National Standards Institute) é de problemas e resolução.
o representante ISO dos Estados Unidos, e no Brasil a (F) Adicionalmente, outro objetivo do MPS.BR é replicar
ISO é representada pela ABNT (Associação Brasileira o modelo na América do Norte, incluindo os Estados
de Normas Técnicas). Unidos e Canadá, que apoiam o projeto (o correto
seria: América Latina).
c) Apenas i e iii estão corretas.
(V) O modelo MPS segue os modelos e normas
internacionais mais aceitos no mercado. Está em
4) Assinale V-verdadeiro e F-falso:
conformidade com as normas internacionais ISO/IEC
(V) Uma distinção entre o nível 4 e o nível 5 do CMMI é o 12207 e ISO/IEC 15504 e é compatível com o modelo
tipo de variação de processo com que se lida. No nível 4, CMMI.
processos ocupam-se com causas especiais de variação e
69
Engenharia de Software
(F) Apesar do MPS.BR ser compatível com os padrões 6) Segundo o PMBoK, o gerente de
de qualidade aceitos internacionalmente, não se projetos deve ter as seguintes competências:
compromete em aproveitar a competência existente conhecer gerenciamento geral e gestão de
nos padrões e modelos de melhoria de processo já projetos, ter habilidades interpessoais e
disponíveis. habilidades de gerenciamento geral, entender
(V) O modelo MPS baseia-se nos conceitos de do ambiente do projeto e conhecer as normas
maturidade e capacidade de processo para a avaliação e regulamentos da área de aplicação.
e melhoria da qualidade e produtividade de produtos
de software e serviços correlatos. a) Verdadeiro.
a) Verdadeiro.
b) Stakeholders.
a) Verdadeiro.
d) IV.
70
Engenharia de Software
71
Engenharia de Software
72