Slides de Aula IV

Prévia do material em texto

Prof. Me. Edson Moreno
UNIDADE IV
Fundamentos de 
Engenharia de Software
 A partir dos requisitos e da disposição de processos para construir o software, a engenharia 
de software apresenta os princípios das atividades metodológicas voltadas para a 
comunicação, o planejamento, a modelagem, a construção e a disponibilização do software. 
 Para garantir a mantenabilidade do software, são abordados os processos de mudanças no 
software, durante o desenvolvimento e, mesmo depois que ele for liberado e o 
acompanhamento destas mudanças, garante que o produto software foi construído, de 
acordo com o que foi pedido.
 Neste contexto, a unidade IV, da disciplina Fundamentos de Engenharia de Software, 
aborda os princípios que orientam a prática e, ao término da disciplina, aborda a integração 
e a entrega do sistema.
Introdução
 A engenharia de software é uma prática contínua de conhecimento e de aplicação de novas 
tecnologias. 
 De acordo com Pressman (2011), o conhecimento sobre o desenvolvimento de software tem 
uma vida média de três anos. Metade do que se aprendeu se torna obsoleto.
 Os princípios da engenharia de software servirão ao profissional durante toda a sua carreira.
Neste capítulo, serão abordados os seguintes itens:
 A essência da prática;
 Princípios das atividades metodológicas;
 Atividade de verificação do código do software.
7 Princípios que orientam a prática
 Os princípios da engenharia de software servem de artefatos e regras que podem ser 
praticadas diariamente, criando as ações racionais que conduzem a uma melhoria contínua 
de aprendizado e de evolução profissional.
A essência da prática – Princípios fundamentais que orientam o processo
Princípios que orientam o processo
Princípio 1. Seja ágil;
Princípio 2. Concentre-se na qualidade em todas as etapas;
Princípio 3. Esteja pronto para as adaptações; 
Princípio 4. Monte uma equipe efetiva; 
Princípio 5. Estabeleça os mecanismos para a comunicação 
e a coordenação; 
Princípio 6. Gerencie as mudanças; 
Princípio 7. Avalie os riscos; 
Princípio 8. Gere os artefatos que forneçam valor para os 
outros.
Fonte: PRESSMAN (2011).
A essência da prática – Princípios fundamentais que orientam a prática
Princípios que orientam a prática
Princípio 1. Divida e conquiste; 
Princípio 2. Compreenda o uso da abstração; 
Princípio 3. Esforce-se por consistência; 
Princípio 4. Foque na transferência de informação; 
Princípio 5. Construa um software que apresente uma modularidade efetiva;
Princípio 6. Padronize; 
Princípio 7. Se possível, represente o problema e a sua solução sob as perspectivas diferentes; 
Princípio 8. Lembre-se de que alguém fará a manutenção do software.
Fonte: ARKAN. Descubra como funciona o Desenvolvimento de 
Softwares e os seus processos. Arkan System. Disponível em:
https://arkansystem.com.br/desenvolvimento-de-
softwares_e_seus_processos/. Acesso em: 24 fev. 2020.
Conheça a prática 
da prática.
Fonte: PRESSMAN (2011).
 A comunicação entre o 
cliente e o desenvolvedor é 
uma atividade desafiadora. 
Cliente  Negócio
X
Desenvolvedor  TI
Princípios das atividades metodológicas – Comunicação
Princípios da Comunicação
Princípio 1. Ouça;
Princípio 2. Prepare-se antes de se comunicar;
Princípio 3. Alguém deve facilitar a atividade;
Princípio 4. Comunique-se pessoalmente;
Princípio 5. Anote e documente as decisões; 
Princípio 6. Esforce-se por colaboração; 
Princípio 7. Mantenha o foco e crie módulos para a discussão; 
Princípio 8. Faltando clareza, represente graficamente;
Princípio 9. (a) Uma vez de acordo, siga em frente; (b) Se não 
chegar a um acordo, siga em frente; (c) Se uma 
característica ou função estiver obscura, e não 
puder ser elucidada no momento, siga em frente;
Princípio 10. Negociação não é uma contestação e 
nem um jogo.
Fonte: PRESSMAN (2011).
 O planejamento permite à 
equipe de software definir 
um roteiro à medida que 
segue na direção de 
seus objetivos 
estratégicos e táticos 
(PRESSMAN, 2011).
Princípios das atividades metodológicas – Planejamento
Princípios de planejamento
Princípio 1. Compreenda o escopo do projeto;
Princípio 2. Envolva os interessados na atividade de 
planejamento; 
Princípio 3. Reconheça que o planejamento é iterativo; 
Princípio 4. Faça as estimativas com base no que conhece; 
Princípio 5. Considere a análise de risco ao definir o plano; 
Princípio 6. Seja realista; 
Princípio 7. Ajuste as particularidades ao definir o plano; 
Princípio 8. Defina como se pretende garantir a qualidade;
Princípio 9. Descreva como pretende adequar as alterações;
Princípio 10. Verifique o plano, frequentemente, e faça ajustes 
necessários.
Fonte: PRESSMAN (2011).
Modelagem do software:
 Modelagem do projeto 
de software;
 Modelagem do 
produto software.
Princípios das atividades metodológicas – Modelagem
Princípios de modelagem
Princípio 1. O objetivo principal da equipe de software é construir 
softwares, e não criar modelos;
Princípio 2. Viaje leve; 
Princípio 3. Esforce-se ao máximo para produzir os modelos 
mais simples possíveis; 
Princípio 4. Construa modelos que facilitem as alterações; 
Princípio 5. Estabeleça um propósito claro para cada modelo; 
Princípio 6. Adapte o modelo desenvolvido a outros;
Princípio 7. Crie modelos úteis, mas esqueça a construção de 
modelos perfeitos; 
Princípio 8. Não seja dogmático quanto à sintaxe do modelo; 
Princípio 9. Se os instintos indicam que um modelo não está 
correto, provavelmente, há motivos para se
preocupar;
Princípio 10. Obtenha o feedback o quanto antes.
Fonte: PRESSMAN (2011).
As pessoas gostam de falar do que entendem, logo, o engenheiro de software que pretende 
coletar as informações sobre o negócio do cliente, tem que saber se comunicar para abstrair, 
ao máximo, o conhecimento sobre o negócio. Assinale a alternativa que possua alguns dos 
princípios da comunicação:
a) Defina junto ao cliente a qualidade do software, explique como vai alinhar o negócio com o 
sistema e forneça feedbacks sucessivos.
b) Explique ao cliente como irá funcionar o sistema, considere o risco da biblioteca do sistema, 
e anote e documente os itens do negócio.
c) Ouça, comunique-se pessoalmente e foque no objetivo.
d) Prepare-se antes de se comunicar, mantenha uma 
comunicação constante com o cliente, para deixá-lo seguro, 
e forneça feedbacks sucessivos.
e) Questione sempre que tiver dúvidas, anote e documente os 
itens do negócio e esclareça as dúvidas do cliente.
Interatividade
As pessoas gostam de falar do que entendem, logo, o engenheiro de software que pretende 
coletar as informações sobre o negócio do cliente, tem que saber se comunicar para abstrair, 
ao máximo, o conhecimento sobre o negócio. Assinale a alternativa que possua alguns dos 
princípios da comunicação:
a) Defina junto ao cliente a qualidade do software, explique como vai alinhar o negócio com o 
sistema e forneça feedbacks sucessivos.
b) Explique ao cliente como irá funcionar o sistema, considere o risco da biblioteca do sistema, 
e anote e documente os itens do negócio.
c) Ouça, comunique-se pessoalmente e foque no objetivo.
d) Prepare-se antes de se comunicar, mantenha uma 
comunicação constante com o cliente, para deixá-lo seguro, 
e forneça feedbacks sucessivos.
e) Questione sempre que tiver dúvidas, anote e documente os 
itens do negócio e esclareça as dúvidas do cliente.
Resposta
 A atividade de construção engloba um conjunto de tarefas de codificação e de testes que 
conduzem ao software operacional, pronto para ser entregue ao cliente e ao usuário final 
(PRESSMAN, 2011).
 A codificação é feita com o uso de uma linguagem de programação e os testes são voltados 
para os componentes, denominados como testes de unidade.
Princípios das atividades metodológicas – Construção
Princípios de codificação
Princípios de preparação;
Princípios de programação;
Princípios de validação.
 Verificação eValidação (V&V) trabalham juntas. A verificação 
inspeciona e a validação demonstra que o produto criado 
satisfaz os objetivos.
Fonte: PRESSMAN (2011).
Princípios das atividades metodológicas – Disponibilização
Princípios para a entrega de um incremento do software
Princípio 1. As expectativas dos clientes para o software
devem ser gerenciadas;
Princípio 2. Um pacote de entrega completo deve ser 
auditado e testado;
Princípio 3. Deve-se estabelecer uma estrutura de suporte 
antes da entrega do software; 
Princípio 4. Material adequado referente às instruções deve 
ser fornecido aos usuários finais;
Princípio 5. Software com bugs (erros), primeiro, deve ser 
corrigido, e, depois, entregue.
Fonte: PRESSMAN (2011).
A disponibilização envolve 
três ações:
 Entrega;
 Suporte; e 
 Feedback.
 A prática de verificação do código do software é chamada de depuração.
 A depuração é a atividade de rastreamento do código, com objetivo de corrigir e reduzir 
falhas no programa de computador.
 O termo trace (rastrear) é o termo técnico utilizado para rastrear um bug passo a passo, com 
testes para reproduzir o problema e buscar o ponto de erro. 
Atividade de verificação do código do software
Debugging (atividade de depuração de falhas)
1. Reprodução (Reproduce): rastrear o erro com o objetivo 
de identificar a causa de determinado problema; 
2. Diagnóstico (Diagnose): avaliar o ponto do erro, a sua 
causa, a gravidade, o grau de prioridade, os riscos e os 
impactos no comportamento do software;
3. Corrigir (Fix): implementação e testes para as correções 
necessárias;
4. Refletir (Reflect): aplicação das medidas corretivas, de 
forma a garantir uma solução para o problema.
 Fluxo das atividades de depuração, testes e diagnósticos do software.
Atividade de verificação do código do software – Fluxo de atividades
Fonte: MORENO (2020).
Reproduzir 
o
problema
Diagnosticar
Corrigir os
problemas
Reflexão
Correções
feitas com
sucesso?
Problema
corrigido?
Implantar a
solução
SIM
NÃO
NÃO
*Estabelecer as Marcas 
de referência 
(milestones)
Estabelecer 
as
medidas
corretivas
Registro e
Versionamento
Para entender melhor como funciona o teste de software estabeleça duas perspectivas: 
1. Interface do usuário com o software;
Atividade de verificação do código do software – top-down e bottom-up
Fonte: MORENO (2020).
2. Interface do software com o ambiente operacional do computador.
Fonte: MORENO (2020).
REQUISITOS FUNCIONALIDADE USABILIDADE
PROJETO
CÓDIGO
REQUISITOS FUNCIONALIDADE USABILIDADE
PROJETO
CÓDIGO
up
down
bottom
top
 O grafo de fluxo é utilizado para rastrear o código, normalmente, utilizado nos testes caixa-
branca e caixa-preta, que será visto mais à frente.
O grafo de fluxo é sugerido por Pressman (2007), para o acompanhamento da codificação, 
como é mostrado de forma adaptada na figura a seguir: 
Atividade de verificação: Projeto do código – Grafo de fluxo
Fonte: FELIZARDO, K. R. Técnicas de VV&T - Validação, Verificação e Teste. 
Disponível em: http://www.linhadecodigo.com.br/artigo/492/tecnicas-de-vvampt-
validacao-verificacao-e-teste.aspx. Acesso em: 28 jul. 2020.
1
2
2 2 2
1 1 1
3
3 34
Leia o texto: “O rastreamento de um bug inicia com os testes para reproduzir o problema e 
buscar o ponto de erro. Ao encontrar o erro faz-se um diagnóstico, que pode ser informal ou 
quando houver a necessidade um relatório formal de um registro do erro”. Este texto se refere 
à atividade de verificação do código, na limpeza e na exclusão de partes indesejáveis. Esta 
atividade, em termos técnicos, é chamada de _____________ do programa. 
Qual a alternativa que completa corretamente a lacuna:
a) Break point.
b) Customização.
c) Depuração.
d) Trace.
e) Validação.
Interatividade
Leia o texto: “O rastreamento de um bug inicia com os testes para reproduzir o problema e 
buscar o ponto de erro. Ao encontrar o erro faz-se um diagnóstico, que pode ser informal ou 
quando houver a necessidade um relatório formal de um registro do erro”. Este texto se refere 
à atividade de verificação do código, na limpeza e na exclusão de partes indesejáveis. Esta 
atividade, em termos técnicos, é chamada de _____________ do programa. 
Qual a alternativa que completa corretamente a lacuna:
a) Break point.
b) Customização.
c) Depuração.
d) Trace.
e) Validação.
Resposta
 O último capítulo de Fundamentos de Engenharia de Software trata da integração dos 
componentes do sistema com os recursos da engenharia de software para a implantação 
do sistema.
 O capítulo apresenta a preparação do sistema e a garantia da qualidade combinadas, para 
propiciar a implantação, o suporte, a manutenção e a evolução do sistema. 
Neste capítulo, serão abordados os seguintes itens:
 Projeto de arquitetura;
 Testes e diagnósticos;
 Manutenção do software;
 Gerenciamento de configuração do software.
8 Integração e entrega do sistema
 O projeto de arquitetura é o primeiro estágio no processo de projeto de software
(SOMMERVILLE, 2011).
Entre o início e o fim do projeto existem inúmeras arquiteturas que são elaboradas; contudo, 
os principais projetos são: 
 Projeto conceitual – modelo de abstração de alto nível, ou seja, sem detalhes específicos;
 Projeto lógico  modelo com os detalhes de implementação.
A visão estática da arquitetura do software permite separar o sistema em camadas, de acordo 
com os requisitos do sistema: 
Projeto de arquitetura
Fonte: VERSOLATTO (2015).
Camada de apresentação
Camada de negócios
Camada de integração
O
b
je
to
s
 d
e
 n
e
g
ó
c
io
Projeto de arquitetura – Evolução da arquitetura do sistema
Arquitetura Centralizada
SERVIDOR
Apresentação (usuário)
Negócios (aplicação)
Integração (dados)
TT
T – Terminais “burros” que não 
têm CPU. São periféricos E/S.
SERVIDOR
Integração (dados)
SERVIDOR (nS)
Negócios (aplicação)
Integração (dados)
Arquitetura Servidor/Cliente
E E
E – Estação (Cliente) – São 
computadores que executa e 
interpreta os programas de 
computador.
Arquitetura de Sistema Distribuído
E E
Fonte: MORENO (2020).
nS – múltiplos Servidores
Multiprocessamento – Existe mais que um 
processador funcionando na mesma memória, 
mas executa os processos simultâneos.
Projeto de arquitetura – Multiprocessamento e Multicomputação
Multicomputação – É formada por um 
aglomerado de computadores que, quando 
conectados, em uma rede local, podem 
constituir um cluster.
Fonte: BARNEY (2016).
Fonte: TANENBAUM (2013).
IA-32
CPU + L1
IA-32
CPU + L1
IA-32
CPU + L1
IA-32
CPU + L1
Cache L2Cache L2Cache L2Cache L2
Rede em anel
Cache L3 compartilhada
cpu0 cpu1 cpu1cpu0
nMPOpe
MPI MPI MPI
Ope nMP Ope nMP Ope nMP
cpu0 cpu1 cpu0 cpu1 cpu0 cpu1 cpu0 cpu1
Parallel File System
Service Nodes
Interconnect
Compute Nodes
 A disciplina de Testes é crítica para o desenvolvimento de software. Frequentemente, as 
atividades de testes inserem tantos defeitos em um produto quanto a própria implementação 
(PAULA FILHO, 2015).
Testes e diagnósticos
“Huum, que erro estranho. Aqui diz para deletar 
o Windows!”
“E se for verdade? Meus dados são mais 
importantes do que o sistema operacional?”
“E se não for verdade? Seria o hardware ou um 
vírus?”
Fonte: ALLAN (2011).
 Como a história começa? Se não houver testes de software, 
não tem jeito. A equipe se reúne e decide que tem que 
resolver este problema. A gerência afirma: “Temos que seguir 
os procedimentos de testes e diagnósticos, para resolver e 
evitar que este problema ocorra novamente”. 
 No processo V&V, quando o software é construído especificamente para um cliente e é 
normal que ele passe por um teste de aceitação por parte do usuário. A melhor estratégia 
são os Testes Alfa e Beta. 
 Teste Alfa – Os usuários são levados a testar o software desde os seus estágios iniciais de 
instalação até a sua operação completa. Tudo realizado num ambiente especial, controladopelos desenvolvedores.
 Teste Beta – É acompanhado por uma versão release, realizado, exclusivamente, no hábitat 
do usuário em um ambiente descontrolado. Sem a presença do desenvolvedor, porém 
monitorados por estes, ao contrário do Teste Alfa.
Testes e diagnósticos – Testes Alfa e Beta
 Os Testes Caixa-branca e Caixa-preta são guiados pelo código-fonte, respectivas métricas 
de software aplicáveis e se, realmente, estão atendendo aos requisitos com um bom 
desempenho e segurança.
 Teste Caixa-branca (teste estrutural) – É focado nos possíveis erros internos de estrutura dos 
componentes do software ou sistema.
 Teste Caixa-preta (teste comportamental) – Visa identificar as falhas em seu comportamento 
externo, com foco nos requisitos funcionais, e conduzidos na interface de software com o 
usuário e com o hardware.
Testes e diagnósticos – Testes Caixa-preta e Caixa-branca
Fonte: MORENO (2020).
Caso
de teste
Referência Especificação
CTP01
RF01,
RF01.1,
RF01.2.
CTP01: Teste MVC – apresentação de relatórios:
1. Ver no menu de relatórios os relatórios disponíveis e se 
estão de acordo com os requisitos;
2. Verificar a exibição de relatórios se está de acordo com os 
requisitos e os registros de dados;
3. Textos e mensagens deverão ser exibidos em sua íntegra.
4. Revisar os cálculos.
CTP02
RS01,
RS02,
RS03.
CTP02: ambiente do usuário:
1. Tipo de computador está de acordo com os requisitos;
2. Sistema operacional e Navegador estão de acordo com os 
requisitos do sistema.
A CPU Core i7 é um processador em um único chip 
manufaturado com quatro ou mais núcleos em uma única 
pastilha de silício (TANENBAUM, 2013). Sobre esta 
arquitetura é correto afirmar que:
a) Esta é uma arquitetura típica de um cluster de 
computadores.
b) Este tipo de multiprocessamento ocorre com o 
acréscimo de outros computadores conectados em uma 
rede local, para serviços de uma determinada aplicação.
c) Nesta arquitetura, o hardware e o software dos vários 
computadores são compartilhados por todos na rede.
d) O multiprocessamento fornece uma sincronização entre 
os múltiplos processadores para acessarem a memória 
de forma comum.
e) Os sistemas de informação, neste tipo de arquitetura, 
conseguem acessar os objetos distribuídos pela rede.
Interatividade
IA-32
CPU + L1
Cache L2
IA-32
CPU + L1
Cache L2
IA-32
CPU + L1
Cache L2
IA-32
CPU + L1
Cache L2
Rede em anel
Cache L3 compartilhada
A CPU Core i7 é um processador em um único chip 
manufaturado com quatro ou mais núcleos em uma única 
pastilha de silício (TANENBAUM, 2013). Sobre esta 
arquitetura é correto afirmar que:
a) Esta é uma arquitetura típica de um cluster de 
computadores.
b) Este tipo de multiprocessamento ocorre com o 
acréscimo de outros computadores conectados em uma 
rede local, para serviços de uma determinada aplicação.
c) Nesta arquitetura, o hardware e o software dos vários 
computadores são compartilhados por todos na rede.
d) O multiprocessamento fornece uma sincronização entre 
os múltiplos processadores para acessarem a memória 
de forma comum.
e) Os sistemas de informação, neste tipo de arquitetura, 
conseguem acessar os objetos distribuídos pela rede.
Resposta
IA-32
CPU + L1
Cache L2
IA-32
CPU + L1
Cache L2
IA-32
CPU + L1
Cache L2
IA-32
CPU + L1
Cache L2
Rede em anel
Cache L3 compartilhada
 Os níveis de manutenção do software variam do negócio para a tecnologia e funcionam, 
basicamente, com as abordagens top-down e bottom-up, vistas no “Tópico 7.2.4 Princípios 
de construção – Unidade IV”.
 A abordagem top-down e bottom-up para a manutenção difere do teste de software. O teste
de software tem, como objetivo, validar o software para o aceite do cliente e, na manutenção,
tem, como objetivo, fazer as mudanças no software para reparar os defeitos, adaptar o 
software a um novo ambiente operacional ou fazer os acréscimos de funções.
Manutenção do software
Fonte: MORENO (2020).
Top-down Software/Sistema
Funcionalidade 2Funcionalidade 1 n Funcionalidades
n FunçõesFunção 1 Função 2
Código
(software)
Interface
(usuário)
Interface
(hardware)
Desempenho e
Segurança
Bottom-up
 O processo de mudança do software ocorre em todo o seu ciclo de vida. Tudo para manter o 
software operacional e adaptado às novas tecnologias.
 Adaptações a novos ambientes operacionais e interfaces, mudanças de requisitos, possíveis 
erros de projeto ou de codificação.
De acordo com Lehman (1985), duas leis se destacam: 
 Mudança contínua: um programa necessariamente tem de ser modificado ou se tornará, de 
maneira progressiva, menos útil nesse ambiente;
 Aumento da complexidade: à medida que um programa em evolução se modifica, a sua 
estrutura tende a se tornar mais complexa.
Manutenção do software – Fundamentos da manutenção
Tipos de manutenção
Manutenção para reparar os defeitos no software;
Manutenção para adaptar o software a um ambiente operacional 
diferente;
Manutenção para fazer os acréscimos à funcionalidade do 
sistema ou modificá-la.
Fonte: PRESSMAN (2011).
 Cleanroom se baseia na prevenção de defeitos, ao invés da remoção de defeitos. 
 Utiliza uma especificação formal, usa um modelo de transição de estados baseada no 
desenvolvimento incremental com as inspeções rigorosas. 
Manutenção do software – Prevenção de defeitos com cleanroom
Fonte: SOMMERVILLE (2007).
Especificar
formalmente
o sistema
Definir
incrementos
de software
Desenvolver 
o perfil
operacional
Construir 
um
programa
estruturado
Verificar um 
código
formalmente
Integrar um
incremento
Projetar os
testes
estatísticos
Testar o
sistema
integrado
Retrabalho devido ao erro
 O gerenciamento de configuração define como registrar e processar as mudanças do 
sistema, e de como relacioná-los aos componentes e os métodos utilizados.
Gerenciamento de configuração do software
Atividades de configuração de software
Gerenciamento de mudanças Registro histórico das mudanças aplicadas no sistema;
Gerenciamento de versões Registro e acompanhamento das versões do sistema;
Construção de sistemas
Processo de compilar e ligar componentes de software
em um programa para uma configuração específica;
Gerenciamento de releases
Registro e acompanhamento das versões liberadas 
para o cliente.
Fonte: SOMMERVILLE (2011).
 O formulário de Requisição de Mudança 
é o registro de mudança no software que 
precede os procedimentos de manutenção.
Gerenciamento de configuração – Gerenciamento de mudanças
Fonte: MORENO (2019).
 São versões criadas para testes ou no desenvolvimento, e não são liberadas para o cliente. 
Gerenciamento de configuração – Gerenciamento de versões
Exemplos de técnicas básicas de numeração e identificação da versão
Numeração de versões
Versão 3.21 – Dígito (3) identifica a mudança de estrutura, 
dígito (2) indica a inserção de funcionalidade e o dígito (1) 
indica que houve a implementação de uma mudança;
Identificação por atributos
Versão TEC01_1 - TEC – Representa o componente 
teclado, (01) inserção de um mapa de caracteres e (_1) 
indica que houve a implementação de uma mudança;
Identificação orientada a mudanças CAR_04 – Carlos requisita uma quarta mudança.
Fonte: MORENO 
(2020).
V 1.0 V 1.1 V 1.1a
V 1.1b
Rel 1.0
V 1.2 V 1.3 V 1.31
Rel 1.1
 A construção de sistemas é o processo da criação de um sistema completo, executável por 
meio da construção e da ligação dos componentes de sistema, bibliotecas externas, arquivos 
de configuração, [...] (SOMMERVILLE, 2011).
 Toda a versão gerada deve ser registrada e armazenada.
Gerenciamento de configuração – Construção de sistemas: entrega
Fonte: SOMMERVILLE (2020).
Arquivos de
códigos-fonte
Arquivos de
configuração
Testes
executáveis
Arquivos
de dados
Bibliotecas
Sistema-alvo
executável
Sistema
automatizado
de construção
Compiladores
e ferramentas
Resultados
de testes
 Sempre existiram muitas versões de um sistema,mais do que releases, porque o release é 
a versão do software ou do sistema produzido que é autorizada para distribuir ao cliente.
O lançamento do release é acompanhado de vários fatores técnicos e organizacionais, 
tais como:
 Programa de instalação;
 Manual técnico e do usuário;
 Arquivos de configurações;
 Bibliotecas, arquivos de dados e scripts de registros.
Gerenciamento de configuração – Gerenciamento de releases
Em um determinado servidor foi feita uma expansão da memória RAM e uma atualização do 
sistema operacional. Assinale a alternativa correspondente ao tipo de manutenção que deverá 
ser aplicada:
a) Com a inserção de novos drivers a manutenção é para reparar os defeitos do software.
b) Como houve a atualização do sistema operacional, haverá novas funcionalidades, logo, a 
manutenção é para fazer acréscimos de funcionalidades do sistema.
c) Manutenção para fazer acréscimos à funcionalidade do sistema, porque novas interfaces 
serão inclusas.
d) Manutenção preventiva para identificar o erro antes do 
software entrar em operação.
e) No domínio do sistema é feita a manutenção para adaptar 
o software a um ambiente operacional diferente.
Interatividade
Em um determinado servidor foi feita uma expansão da memória RAM e uma atualização do 
sistema operacional. Assinale a alternativa correspondente ao tipo de manutenção que deverá 
ser aplicada:
a) Com a inserção de novos drivers a manutenção é para reparar os defeitos do software.
b) Como houve a atualização do sistema operacional, haverá novas funcionalidades, logo, a 
manutenção é para fazer acréscimos de funcionalidades do sistema.
c) Manutenção para fazer acréscimos à funcionalidade do sistema, porque novas interfaces 
serão inclusas.
d) Manutenção preventiva para identificar o erro antes do 
software entrar em operação.
e) No domínio do sistema é feita a manutenção para adaptar 
o software a um ambiente operacional diferente.
Resposta
 LEHMAN, M. M.; BELADY, L. A. Program evolution. APIC Studies in Data Processing, 
Academic Press, 1985.
 PAULA FILHO, W. de P. Engenharia de Software: Fundamentos, Métodos e Padrões. 3. ed. 
Rio de Janeiro: LTC, 2015.
 PRESSMAN, R. S. Engenharia de Software: uma abordagem profissional. 7. ed. Rio de 
Janeiro: McGraw-Hill, 2011.
 SOMMERVILLE, I. Engenharia de Software. 9. ed. São Paulo: Pearson Prentice H., 2011.
 TANENBAUM, A. S. Organização Estruturada de Computadores. São Paulo: Pearson 
Prentice Hall, 2013.
 VERSOLATTO, F. R. Projeto de Sistemas: Projeto de 
Sistemas Orientado a Objetos. São Paulo: Editora Sol, 2015.
Referências
ATÉ A PRÓXIMA!