UNIDADE IV - PRINCÍPIOS DE SISTEMA DE INFORMAÇÕES

Prévia do material em texto

1 
 
UNIDADE IV 
7 PRINCÍPIOS QUE ORIENTAM A PRÁTICA 
7.1 A essência da prática 
A engenharia de software é uma prática contínua de conhecimento e aplicação de 
novas tecnologias. Tecnologias entendidas como novos computadores, novas 
interfaces e novos recursos de redes de computadores, tecnologias de programação 
como versões mais atuais de linguagens de programação e frameworks. As aplicações 
dessas tecnologias envolvem a prática de modelagem, de estruturas de dados e de 
construção de software. Enfim é o que o engenheiro de software precisa saber, dada a 
evolução constante da tecnologia. 
Frequentemente, diz-se que conhecimento sobre desenvolvimento de 
software tem uns três anos de vida: metade do que se precisa saber hoje 
estará obsoleto daqui a três anos. No que diz respeito ao conhecimento 
de tecnologia, essa afirmação está próxima da verdade. Mas há outro 
tipo de conhecimento sobre desenvolvimento de software - um tipo 
visto como “princípios da engenharia de software” – que não possui três 
anos de meia-vida. Tais princípios provavelmente servirão ao 
programador profissional durante toda a sua carreira (MCCONNELL, 
1999 apud PRESSMAN, 2011, p. 109). 
Os princípios da engenharia de software, ditados por Pressman (2011) conduzem a 
uma boa prática da engenharia de software. Na verdade, esses princípios manifestam 
toda a essência da prática. Servem de artefatos e regras que podem ser praticadas 
diariamente, criando ações racionais que conduzem a uma melhoria contínua de 
aprendizado e evolução profissional. 
A seguir serão discutidos os elementos que envolvem a essência da prática. Criados 
por Pressman (2011) a essência da prática se baseia nos princípios fundamentais e 
princípios das atividades metodológicas: 
7.1.1 Princípios fundamentais 
Pressman (2011) orienta: “A engenharia de software é norteada por um conjunto de 
princípios fundamentais que auxiliam na aplicação de um processo de software 
significativo e na execução de métodos de engenharias de software efetivos”. 
 Princípios que orientam o processo – este conjunto de princípios podem ser aplicados à 
metodologia e a todos os processos de software (PRESSMAN, 2011): 
➢ Princípio 1. Seja ágil – evite o desperdício de ações e tome decisões localmente sempre 
que possível. Use os princípios das metodologias ágeis. 
2 
 
➢ Princípio 2. Concentre-se na qualidade em todas as etapas – foco na qualidade para toda 
atividade, ação e tarefa do processo. 
➢ Princípio 3. Esteja pronto para adaptações – todo processo deve ser melhorado 
continuamente, acostume-se com mudanças. 
➢ Princípio 4. Monte uma equipe efetiva – Forme uma equipe que se auto-organize, que 
tenha confiança e respeito mútuos. 
➢ Princípio 5. Estabeleça mecanismos para comunicação e coordenação – falhas e omissões 
de informações no desenvolvimento do projeto, comprometem todo o esforço da equipe. 
➢ Princípio 6. Gerencie mudanças – estabeleça mecanismos de gestão de configuração do 
software para acompanhamento das mudanças. 
➢ Princípio 7. Avalie os riscos – no desenvolvimento do software falhas e erros acontecem. 
Estabeleça planos de contingência. Por exemplo: Manter os backups atualizados. 
➢ Princípio 8. Gere artefatos que forneçam valor para outros – a prática de reuso deve ser 
constante. Crie ou melhore artefatos que proporcione valor para outro processo, 
atividades, ações ou tarefas no desenvolvimento do software. 
 
 Princípios que orientam a prática – o objetivo primordial único é entregar dentro do prazo, 
com alta qualidade (PRESSMAN, 2011): 
➢ Princípio 1. Divida e conquiste – analise o projeto e o separe por níveis de interesses. Cada 
interesse fornece uma funcionalidade. O conjunto destes interesses terá uma solução 
mais fácil para um determinado problema. 
➢ Princípio 2. Compreenda o uso da abstração – abstrair é simplificar a interpretação de um 
elemento complexo e comunicar o significado de forma clara em poucas palavras. 
➢ Princípio 3. Esforce-se por consistência – procure garantir que todos os elementos de 
análise estejam apresentáveis e integrados. 
➢ Princípio 4. Foque na transferência de informação – a informação deve fluir por todos os 
dispositivos e interfaces de hardware e humana. A ocorrência de erros é relevante. A 
informação deve ser garantida da origem ao destino e os erros devem ser solucionados, 
ou no mínimo recuperados ou contornados. 
➢ Princípio 5. Construa software que apresente modularidade efetiva – com base no 
Princípio 1. A modularidade ou componentização efetiva, consiste em criar módulos 
capazes de serem substituídos, terem seus próprios endereços, ligações simples e 
recursos de manutenção isolada do restante do sistema. 
➢ Princípio 6. Padronize – a padronização leva a repetição, melhorias de soluções e 
eficiência da prática. 
➢ Princípio 7. Quando possível, represente o problema e sua solução sob uma série de 
perspectivas diferentes – faça desenhos específicos para cada ponto de vista de interesse. 
3 
 
➢ Princípio 8. Lembre-se de que alguém fará a manutenção do software – erros, omissões, 
mudanças e adaptações vão ocorrer. Uma prática aplicada com base na engenharia de 
software garante uma consistência ao longo do ciclo de vida do processo de 
desenvolvimento de software. 
7.2 Princípios das atividades metodológicas 
Os princípios das atividades metodológicas são aprimoramentos dos princípios 
fundamentais apresentados no Tópico 7.1.1. dessa unidade de ensino. 
7.2.1 Princípios da comunicação 
A comunicação entre o cliente e desenvolvedor é uma atividade desafiadora. O 
cliente e o usuário entendem do negócio e sabem o que querem do sistema, contudo a 
linguagem destes é diferente da linguagem do desenvolvedor. O cliente está envolvido 
no seu negócio e em seus modelos, sua organização, cultura e linguagem. É diferente 
do ambiente do desenvolvedor. O desenvolvedor entende de tecnologia da informação, 
mas não do negócio do cliente. E para que seja desenvolvido um software, eles 
precisam se comunicar de forma efetiva. 
➢ Princípio 1. Ouça – Concentre-se mais em ouvir do que em se preocupar com respostas. 
Elabore um questionário breve. “As pessoas gostam de falar do que entendem. Ouça 
apenas e anote todas as observações. Evite fazer perguntas durante a fala do cliente, 
reserve isto para a fase de análise” (MORENO, 2020). 
➢ Princípio 2. Prepare-se antes de se comunicar – Dedique tempo para compreender o 
problema antes de se encontrar com outras pessoas. Faça uma pesquisa sobre o negócio 
e a linguagem do cliente. 
➢ Princípio 3. Alguém deve facilitar a atividade – se possível eleja um líder (um facilitador) 
para intermediar a comunicação entre o cliente e o desenvolvedor. 
➢ Princípio 4. Comunique-se pessoalmente – comunicar-se pessoalmente é mais produtivo. 
➢ Princípio 5. Anote e documente as decisões – observações e decisões podem cair no 
esquecimento. Registre por escrito ou gravação todos os pontos importantes da 
comunicação. 
➢ Princípio 6. Esforce-se por colaboração – a colaboração dos interessados no projeto ajuda 
a equipe a criar um senso comum do que é para ser feito. 
➢ Princípio 7. Mantenha o foco e crie módulos para a discussão – mantenha o foco no 
elemento de análise, evite desvios para outros itens não ligados à análise. 
➢ Princípio 8. Faltando clareza, represente graficamente – se a forma verbal ou escrita for 
de difícil interpretação, faça um desenho, um diagrama ou qualquer representação gráfica 
do objeto em pauta. O índice de interpretação e entendimento do problema aumentam. 
4 
 
➢ 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 – este princípio de comunicação é para reforçar o Princípio 1. 
➢ Princípio 10. Negociação não é uma contestação e nem um jogo – a prática de negociação 
tem que sempre objetivarfavorecer mutuamente os negociadores. 
A comunicação ajuda a agrupar as ideias, definir elementos do projeto, tais como 
custos, prazos, componentes, metas e objetivos. Uma vez definido tais itens, agora é 
hora de saber como alcançá-los e de elaborar um plano para efetivar as ideias. 
7.2.2 Princípios de planejamento 
A atividade de planejamento engloba um conjunto de práticas técnicas e gerenciais 
que permitem à equipe de software definir um roteiro à medida que segue na direção 
de seus objetivos estratégicos e táticos (PRESSMAN, 2011). 
Como dito anteriormente a engenharia de software é uma área nova. Estima-se que 
60 a 90% do planejamento possa ser determinado com um nível alto de exatidão, 
contudo os 10 a 40% restantes do planejamento são imprecisos ou até mesmo serão 
descobertos durante o ciclo de desenvolvimento. “Por mais que se tente, é impossível 
prever com exatidão como um projeto de software irá evoluir. Não importando o rigor 
com o qual o planejamento seja feito, os seguintes princípios sempre se aplicam: 
(PRESSMAN, 2011)”. 
➢ Princípio 1. Compreenda o escopo do projeto – o escopo do projeto se refere as 
dimensões do projeto. O escopo favorece estabelecer marcas de referência no projeto. 
➢ Princípio 2. Envolva os interessados na atividade de planejamento – A participação dos 
interessados garante a obtenção de requisitos, restrições e qualidade exigida. 
➢ Princípio 3. Reconheça que o planejamento é iterativo – no projeto de software é comum 
ocorrerem modificações. Reuniões iterativas redefinem o arcabouço do processo com 
melhorias, prevenções e novas práticas. 
<Lembrete início> 
O Scrum promove reuniões iterativas de forma ágil. Reveja o “Tópico 5.2.2 Scrum – 
Unidade III”. 
<Lembrete fim> 
➢ Princípio 4. Faça estimativas com base no que conhece – utilize medidas com os dados 
que tem em mãos, tais como: custo, prazo, índice de mudanças. Estas medidas servirão 
para acompanhamento da eficácia e eficiência do projeto. 
➢ Princípio 5. Considere a análise de risco ao definir o plano – o risco e seu respectivo 
impacto no projeto devem ser avaliados. Um plano de contingência deve ser elaborado 
para que o negócio continue e possíveis ajustes dos custos e do cronograma devem ser 
revistos. 
5 
 
➢ Princípio 6. Seja realista – mudanças e fatos da vida ocorrem e isso afeta o 
desenvolvimento do sistema. “Errar é humano”. Por melhor que seja o profissional, este 
também comete erros. Variâncias e desvios devem fazer parte do plano de projeto. 
➢ Princípio 7. Ajuste particularidades ao definir o plano – conforme o nível de detalhes do 
projeto é possível estabelecer marcas de referências em tarefas com menor lead-time 
(tempo de espera). Isso permite entregas rápidas e um controle melhor do projeto. 
<Lembrete início> 
O modelo de processo incremental (veja o “Tópico 4.1.4 Incremental – 
Unidade II”) e as metodologias ágeis (veja o “Tópico 5.1 Manifesto para 
desenvolvimento ágil de software – Unidade III”) trabalham com períodos curtos 
de entrega. Veja como funciona! 
<Lembrete fim> 
➢ Princípio 8. Defina como se pretende garantir a qualidade – medidas, melhorias, 
iterações, testes e revisões técnicas devem ser contempladas no plano do projeto. 
➢ Princípio 9. Descreva como pretende adequar as alterações – as mudanças vão ocorrer, 
tanto por parte do cliente como parte do desenvolvimento. Algumas mudanças podem 
até necessitar de implementação imediata. De que forma estas mudanças estarão 
implícitas no plano do projeto? Este princípio reforça o Princípio 6. 
➢ Princípio 10. Verifique o plano frequentemente e faça ajustes necessários – é de bom 
senso sempre ajustar o plano de projeto quando não houver conformidade. 
Pela comunicação se extrai os requisitos do negócio. Pelo planejamento são 
descritas as atividades do desenvolvimento durante o ciclo de vida da construção do 
software. E para que haja uma melhor compreensão do que e como será construído é 
feito a modelagem do software. 
7.2.3 Princípios de modelagem 
O modelo serve para ver o que será feito. A modelagem do software inclui tanto a 
modelagem do projeto de software, bem como a modelagem do produto software. 
A modelagem permite uma maior abstração do objeto em estudo, melhora a 
compreensão de como vai funcionar uma determinada implementação por exemplo. 
Os modelos devem expandir em detalhes os níveis de abstração de um determinado 
caso de uso ou de um componente de software. Os modelos de software podem ser 
elaborados para o cliente em uma abstração de baixo nível ou em uma abstração de 
alto nível da parte técnica para os desenvolvedores. 
Os princípios de modelagem citados por Pressman (2011) foram extraídos dos 
modelos ágeis e são apropriados para todos os engenheiros de software: 
6 
 
➢ Princípio 1. O objetivo principal da equipe de software é construir software, e não criar 
modelos – agilidade significa entrega de software ou parte deste em períodos curtos. 
Modelos que não contribuírem para a agilidade devem ser descartados. 
➢ Princípio 2. Viaje leve – não crie modelos desnecessários. 
➢ Princípio 3. Esforce-se ao máximo para produzir os modelos mais simples possíveis – 
construa modelos simples e de fácil compreensão, de forma a permitir que outros possam 
criticar ou sugerir alterações. 
➢ Princípio 4. Construa modelos que facilitem alterações – mudanças ocorrem. Não descarte 
esta hipótese nos modelos. Considere sempre um baixo acoplamento e alta coesão entre 
os componentes do software ou do sistema. 
➢ Princípio 5. Seja capaz de estabelecer um propósito claro para cada modelo – o modelo 
deve ser claro e justificável para todos os interessados no projeto. 
➢ Princípio 6. Adapte o modelo desenvolvido ao sistema à disposição – o modelo deve ser 
flexível de forma a permitir novas adaptações. 
➢ Princípio 7. Crie modelos úteis, mas esqueça a construção de modelos perfeitos – [..] a 
modelagem deve ser conduzida tendo em vista as etapas de engenharia de software 
seguintes; iterar indefinidamente para criar um modelo “perfeito” não atende à 
necessidade de agilidade (PRESSMAN, 2011). 
➢ Princípio 8. Não seja dogmático quanto à sintaxe do modelo – o objetivo do modelo é 
transmitir informações. Se a sintaxe do modelo transmitir o conteúdo com sucesso, 
perdoe a sintaxe incorreta. 
➢ Princípio 9. Se os instintos indicam que um modelo não está correto, embora pareça 
correto no papel, provavelmente há motivos com os quais se preocuparem – acredite em 
seus instintos profissionais. Se existir a crença de que algo no modelo está errado, destine 
um tempo para esta análise. 
➢ Princípio 10. Obtenha feedback o quanto antes – revisões sucessivas que proporcionem 
feedbacks, são necessárias para o refinamento de um modelo útil. 
No trabalho de engenharia de software, podem ser criadas duas classes 
de modelos: modelos de requisitos e modelos de projeto. Os modelos 
de requisitos (também denominados modelos de análise) representam 
os requisitos dos clientes, descrevendo o software em três domínios 
diferentes: o domínio da informação, o domínio funcional e o domínio 
comportamental. Os modelos de projeto representam características do 
software que ajudam os desenvolvedores a construí-lo efetivamente: a 
arquitetura, a interface para o usuário e os detalhes quanto a 
componentes (PRESSMAN, 2011, p. 116). 
 
 Princípios de modelagem de requisitos: 
➢ Princípio 1. O universo de informações de um problema deve ser representado e 
compreendido. 
7 
 
➢ Princípio 2. As funções que o software desempenha devem ser definidas. 
➢ Princípio 3. O comportamento do software (como consequência de eventos externos) 
deve ser representado. 
➢ Princípio 4. Os modelos que descrevem informações, funções e comportamentos devem 
ser divididos para que revelem detalhes por camadas (ou hierarquicamente). 
➢ Princípio 5. A análise deve partir da informação essencial para o detalhamento da 
implementação.Princípios de modelagem de projetos: 
➢ Princípio 1. O projeto deve ser roteirizado para a modelagem de requisitos. 
➢ Princípio 2. Sempre considere a arquitetura do sistema a ser construído. 
➢ Princípio 3. O projeto de dados é tão importante quanto o projeto das funções de 
processamento. 
➢ Princípio 4. As interfaces (tanto internas quanto externas) devem ser projetadas com 
cuidado. 
➢ Princípio 5. O projeto de interface do usuário deve ser voltado às necessidades do usuário 
final. Entretanto, em todo caso, deve-se enfatizar a facilidade de uso. 
➢ Princípio 6. O projeto no nível de componentes deve ser funcionalmente independente. 
➢ Princípio 7. Os componentes devem ser relacionados livremente tanto entre 
componentes quanto com o ambiente externo. 
➢ Princípio 8. Representações de projetos (modelos) devem ser de fácil compreensão. 
➢ Princípio 9. O projeto deve ser desenvolvido iterativamente. A cada iteração, o projetista 
deve se esforçar para obter maior grau de simplicidade. 
Com a especificação e modelagem prontas, o projeto está praticamente pronto. A 
próxima fase agora é de construção do produto software. 
7.2.4 Princípios de construção 
A atividade de construção engloba um conjunto de tarefas de codificação e testes 
que conduzem ao software operacional pronto para ser entregue ao cliente e ao usuário 
final (PRESSMAN, 2011). 
A construção do software está ligada as atividades de codificação e testes do 
software para entrega ao cliente. 
A codificação é feita com o uso de uma linguagem de programação e ferramentas 
que a suportem. Para que um programa de computador desenvolvido em qualquer 
linguagem da computação, ele precisa ser convertido em código de máquina no formato 
binário para que o hardware possa ser ativado. Para isso o programa fonte deve passar 
por um compilador (ou interpretador de comandos). 
8 
 
O compilador converte um programa fonte desenvolvido em linguagem "C" por 
exemplo, em código binário executável ".exe" no caso do Windows. 
O interpretador de comandos é um programa residente no computador, que converte 
em código binário no instante em que o programa fonte é carregado no computador. A 
linguagem Java por exemplo. 
<Observação início> 
Exemplos de linguagens de programação compiladas e/ou interpretadas: 
 Linguagens compiladas: BASIC, C, C++, C#, COBOL, Delphi e Fortran. 
 Linguagens interpretadas: ASP, BASIC, C#, , Java, JSP e PHP. 
<Observação fim> 
Para a codificação são usadas ferramentas que fornecem apoio automatizado para 
construir o software, das quais se destacam as ferramentas CASE e frameworks que 
funcionam no domínio da aplicação. Entenda mais, leia Ferramenta no “Tópico 2.4 
Projetos e construção do software – Unidade I”. 
<Observação início> 
A verificação assegura você construiu direito e a validação assegura que você 
construiu a coisa certa. 
<Observação fim> 
De acordo com Pressman (2011) os seguintes princípios e conceitos são aplicados 
a codificação e testes: 
 Princípios de codificação – Os princípios que regem a codificação são intimamente alinhados 
com o estilo de programação, com as linguagens e com os métodos de programação 
(PRESSMAN, 2011). 
➢ Princípios de preparação: Antes de escrever uma única linha de código, certifique-se de 
que: o problema está entendido, a ideia do projeto está clara, linguagens de programação 
e tecnologias estão disponíveis e elaborou um plano de testes dos componentes. 
➢ Princípios de programação: Ao começar a escrever código – otimize os algoritmos, 
estruture a informação para atender o projeto, tenha um bom senso em evitar muitos 
nomes de funções (labels), contudo não faça algoritmos muito extensos com muitos 
atalhos, crie o processo de loops, e seja ágil na documentação. 
➢ Princípios de validação: Após completar a primeira etapa de codificação, certifique-se de: 
verificar o código do software por um processo de depuração de falhas, fazer testes de 
componente e reescrever o código se necessário. 
7.2.5 Princípios de disponibilização 
9 
 
A disponibilização envolve três ações: entrega, suporte e feedback. Pelo 
fato de os modernos modelos de processos de software serem, em sua 
natureza, evolucionários ou incrementais, a disponibilização não ocorre 
imediatamente, mas sim, em muitas vezes, quando o software segue 
para sua finalização (PRESSMAN, 2011, p. 122). 
 
Veja os modos de disponibilização do software apresentados nos modelos de 
processos de software Incremental (Tópico 4.1.4 Incremental – Unidade II) e Espiral 
(Tópico 4.1.5 Espiral – Unidade II). 
<Lembrete fim> 
O modelo Incremental, por exemplo, trabalha com o conceito de versões, é iterativo 
e tem como objetivo apresentar um produto operacional a cada incremento realizado. 
“A entrega para um incremento de software representa um marco importante para 
qualquer projeto de software (PRESSMAN, 2011)”. Pressman (2011) orienta também 
os seguintes princípios a serem seguidos para a entrega de um incremento: 
➢ Princípio 1. As expectativas dos clientes para o software devem ser gerenciadas – o cliente 
sempre espera algo mais. Deixe claro formalmente ao cliente o que vai ser entregue. Evite 
desapontamentos. 
➢ Princípio 2. Um pacote de entrega completo deve ser auditado e testado – antes da 
entrega de um pacote de software ao cliente. O pacote deve ser verificado e validado, de 
preferência realizando testes no ambiente do cliente, evitando é lógico, comprometer o 
ambiente operacional do cliente. 
➢ Princípio 3. Deve-se estabelecer uma estrutura de suporte antes da entrega do software – 
estima-se que em 80% dos casos de ligação dos usuários para o suporte, se referem a 
fatos operacionais comuns e outros de soluções rápidas. O usuário na verdade se sente 
satisfeito em saber que tem “ouvidos” para ele. Os registros das ligações estabelecem 
parâmetros para a evolução e melhoria do software. 
➢ Princípio 4. Material adequado referente às instruções deve ser fornecido aos usuários 
finais - o treinamento do usuário final é essencial para o sucesso do software. O manual 
do usuário funciona de forma colaborativa, porque o usuário ao se acostumar com o 
manual irá auxiliar nas revisões do software. 
➢ Princípio 5. Software com bugs (erros), primeiro, deve ser corrigido, e, depois, entregue – 
“Os clientes esquecerão a entrega de um produto de alta qualidade em poucos dias, mas 
jamais esquecerão os problemas causados por um produto de baixa qualidade. O 
software os faz lembrar isso todos os dias” (PRESSMAN, 2011). Os desenvolvedores 
muitas vezes são submetidos a pressões devido a prazos de entrega ou solução de um 
problema prioritário. Não entregue funcionalidades com problemas e a promessa de que 
o problema vai ser corrigido. 
7.3 Atividade de verificação do código do software 
10 
 
A prática da engenharia de software se torna consistente com a verificação do 
código do software, faz-se o que é chamado de depuração. Do dicionário da língua 
portuguesa, depuração é a atividade de limpeza ou exclusão de partes indesejáveis. No 
desenvolvimento do software erros ocorrem, seja por uma “trava” do programa ou algum 
comportamento inesperado. No processo de desenvolvimento do software, depuração 
é a atividade de rastreamento do código, com objetivo de corrigir e reduzir falhas no 
programa de computador. 
Para depurar falhas no software (DEBUG) é necessário fazer o rastreamento do 
código no tempo de execução do programa, da onde vem a palavra Trace (rastrear). O 
rastreamento de um bug inicia com 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 necessidade, um relatório formal de registro do erro. No diagnóstico deve 
constar o erro identificado e possíveis soluções para o problema. 
Depuração de falhas no software (DEBUG): 
A atividade de depuração de falhas (debugging) mostrada na Figura 53 consiste em 
4 tarefas: 
1. Reprodução(Reproduce): consiste em rastrear o erro com objetivo de identificar a 
causa de um determinado problema. Neste caso usar breakpoints (pontos de parada no 
software). 
2. Diagnóstico (Diagnose): avaliar o ponto do erro, sua causa, gravidade, grau de 
prioridade, riscos e impactos no comportamento do software (no programa em análise 
e em outros programas). 
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 solução 
para o problema, analisar se a mudança não impacta em outras características do 
sistema, validações das entradas/saídas, otimização do código e garantia de 
encapsulamento. 
Figura 53: Fluxo das atividades de Depuração, Testes e Diagnósticos do software. 
 
11 
 
➢ Princípios de testes: o objetivo do teste de software é rastrear o código em busca de 
erros. O bom teste é aquele com alta probabilidade de encontrar erros. Um princípio 
básico na realização de testes de software. principalmente em sistemas de média 
complexidade para cima, é diferenciar a equipe puramente de desenvolvimento, da 
equipe especificamente de testes. Ou seja, quem desenvolve não testa, e quem testa não 
desenvolve. 
7.3.1 Abordagens top-down (de cima para baixo) e bottom-up (de baixo para 
cima) 
Para entender melhor como funciona o teste de software estabeleça duas 
perspectivas: 1. Interface do usuário com o software; e 2. Interface do software com o 
ambiente operacional do computador. 
Essas duas perspectivas levam a uma técnica básica de testes de software, as 
abordagens top-down e bottom-up, observe as Figuras 54 e 55. 
A abordagem top-down apresentada na Figura 54, verifica a integração dos 
componentes de um sistema começando pelos níveis superiores: requisitos, funções e 
interface com o usuário e caminha para os níveis inferiores incluindo testes do código. 
O foco principal deste teste é caminhar da informação até os dados que a geraram. 
Figura 54: A abordagem de teste top-down parte dos níveis superiores, no caso em testes de: 
requisitos, funcionalidade e usabilidade. 
 
A abordagem bottom-up, apresentada na Figura 55, começa pelos níveis inferiores, 
basicamente em nível de código, onde são feitos testes de interface com o hardware, 
drivers e instalação, e caminha para os níveis superiores, os níveis operacionais. A 
abordagem bottom-up, normalmente é usada em instantes do desenvolvimento do 
software. 
Figura 55: A abordagem de teste bottom-up parte dos níveis inferiores, no caso no nível de 
código. Tipo de teste característico de sistema ou software em desenvolvimento. 
12 
 
 
8 INTEGRAÇÃO E ENTREGA DO SISTEMA 
8.1 Projeto de arquitetura 
O projeto de arquitetura está preocupado com a compreensão de como um sistema 
deve ser organizado e com a estrutura geral desse sistema. No modelo do processo de 
desenvolvimento de software, o projeto de arquitetura é o primeiro estágio no processo 
de projeto de software (SOMMERVILLE, 2011). 
A arquitetura de software produz modelos e organiza a estrutura de um software que 
serve de guia para a construção do software. A Figura 56 mostra uma arquitetura para 
desenvolvimento de páginas web em ambiente JSP. Esta arquitetura é útil para 
apresentar o projeto conceitual da arquitetura web, ou seja, este é um modelo de 
abstração de alto nível sem detalhes específicos de como vai funcionar. 
Figura 56: Modelo conceitual de arquitetura web com base na tecnologia JSP (Java Server Page). 
 
O projeto lógico apresentado na Figura 57 mostra uma arquitetura com alguns 
detalhes de implementação. Esta é uma tecnologia de três camadas e quatro nós. No 
modelo são apresentados os componentes (blocos menores), a implantação (caixa) e 
os estereótipos de ligação. 
13 
 
Figura 57: Modelo lógico de arquitetura web de implantação, independente de ambiente 
operacional para cliente acessar SIL – Sistema de Informação Logístico. 
 
Podemos observar na Figura 57 a estrutura em camadas, que permite o acesso pelo 
cliente à aplicação SIL. A visão estática da arquitetura do software permite separar o 
sistema em camadas de acordo com os requisitos do sistema. 
A Figura 58 apresenta um modelo típico de arquitetura em três camadas: camada de 
apresentação, camada de negócios (ou aplicação) e camada de integração. 
Figura 58: Arquitetura em camadas. 
 
Fonte: VERSOLATTO (2015), p. 95. 
As camadas da arquitetura são definidas por Versolatto (2015) de acordo com a 
tabela de definições da arquitetura em três camadas, mostradas na Figura 59: 
Figura 59: Definições da arquitetura em três camadas. 
CAMADA DEFINIÇÃO 
Apresentação Classes responsáveis pela interação com o usuário. 
14 
 
Negócios (ou Aplicação) Classes responsáveis pela execução das regras de negócio. 
Integração 
Classes responsáveis pela integração das tecnologias da 
informação. Por exemplo: SGBD. 
Fonte: VERSOLLATO (2015), p. 95. 
Se analisarmos a arquitetura da Figura 57 conseguimos localizar as camadas. O 
servidor SOR – Sistema Operacional de Rede funciona na camada de apresentação, o 
servidor APP – SIL na camada da aplicação e o servidor SGBD na camada de 
integração. 
O projeto físico utiliza o projeto lógico como base para implementação das 
ferramentas e técnicas que serão aplicadas. 
Com base nos requisitos do sistema são atribuídas as linguagens de programação, 
o sistema de gerenciamento do banco de dados, endereços de redes, restrições do 
sistema, aplicativos e bibliotecas que acompanham o sistema. 
<Lembrete início> 
Quando se está alterando a arquitetura de um sistema já existente, é interessante 
que se tenha um modelo em camadas para melhorar a orientação. A Figura 60 
representa as estruturas de uma aplicação J2EE divididas por camadas, facilitando a 
interpretação da arquitetura. 
 Figura 60: Camadas numa aplicação J2EE. 
 
15 
 
Fonte: VALLE (2007). 
https://www.devmedia.com.br/imagens/javamagazine/medvcjeefig01.jpg 
<Lembrete fim> 
8.1.1 Evolução da arquitetura do sistema 
Os principais sistemas antigos, mesmo os legados, foram desenvolvidos com base 
em arquiteturas centralizadas, que normalmente são sistemas multiusuários formados 
por um servidor e múltiplos terminais acoplados por interface de E/S. O servidor 
normalmente não é estruturado em camadas, pois possui a aplicação, a base de dados 
e a apresentação integrados com alto acoplamento, logo, a apresentação é feita de 
forma simples, normalmente em modo texto. O funcionamento de um terminal de 
computador ocorre da seguinte forma: o terminal recebe ou capta dados de um 
periférico, o terminal requisita a atenção do servidor, envia os dados para o servidor, os 
dados são processados no servidor e devolvidos ao terminal. 
<Observação início> 
Os terminais são periféricos conectados normalmente por uma interface multi 
USB ou Ethernet, que recebem o nome de terminais “burros”, por não possuir 
CPU. Estes terminais podem ser: conjunto de monitor de vídeo e teclado, catracas, 
sensores digitais e outros dispositivos. 
<Observação fim> 
Atualmente a sequência evolutiva da arquitetura é o desenvolvimento com base na 
arquitetura servidor/cliente (ou do inglês server/client) e posteriormente para uma 
configuração de arquitetura de sistemas distribuídos. 
A arquitetura servidor/cliente possui computadores conectados em rede por um 
Sistema Operacional de Rede (SOR). Os servidores são divididos em camadas, sendo 
que, dependendo da capacidade do servidor, esse pode fornecer serviços da camada 
de apresentação, da camada da aplicação e da camada de integração em um único 
computador ou vários computadores, como pode ser visto na Figura 61. O servidor 
atende as requisições de dados e de processamento em baixo nível tanto para a 
apresentação como para a aplicação. Os computadores clientes (ou estações 
computacionais) dividem o processamento da aplicação e da apresentação com o 
servidor, permitindo assim um processamento com maior desempenho. 
Na Figura61 são observados no alto nível de rede os computadores servidores, de 
Telas na camada de apresentação, serviços da Aplicação e Web na camada da 
aplicação (ou negócios) e serviços SGBD na camada de integração. Os clientes que se 
utilizam dos serviços estão no baixo nível da rede. 
Figura 61: Arquitetura servidor/cliente. 
16 
 
 
Os frameworks de aplicações Web (WAFs, do inglês web application 
frameworks) são um tipo de framework mais recente e muito 
importante. WAFs que apoiam a construção de sites dinâmicos estão 
amplamente disponíveis. Geralmente, a arquitetura de um WAF é 
baseada no padrão Composite do MVC (Modelo-Visão-Controlador) 
(GAMMA et al., 1995. apud SOMMERVILLE, 2011, p. 301). 
 
A evolução da arquitetura se baseia em modificar a arquitetura de um sistema, a 
partir da arquitetura centralizada (centrada em dados), passando para uma arquitetura 
servidor/cliente e, por fim, para uma arquitetura de sistema distribuído. 
Nos sistemas distribuídos a interface com o usuário, as funcionalidades e as bases 
de dados do sistema, ficam distribuídas pelos computadores servidores do ambiente 
operacional. 
Uma estratégia comum da evolução da arquitetura, para sistemas legados em 
especial, é encapsular o sistema legado como um servidor e implementar uma interface 
com o usuário distribuída, que acesse a funcionalidade do sistema (por meio da 
tecnologia middleware de propósito especial. 
Na evolução da arquitetura o engenheiro de software deverá observar as mudanças 
apresentadas na Figura 62: 
Figura 62: Mudanças no sistema que acompanham a evolução da arquitetura. 
APRESENTAÇÃO Exibição e organização de telas. 
VALIDAÇÃO DOS DADOS Checagem das entradas e saídas de/para o usuário. 
17 
 
CONTROLE DE INTERAÇÕES 
Controle das operações realizadas pelo usuário e ordem de 
sequência de telas. 
APLICAÇÃO Implementação dos serviços da aplicação. 
BANCO DE DADOS Armazenamento dos dados e gerência dos dados armazenados. 
Nos sistemas distribuídos o SOR é fracamente acoplado, é usado para sistemas 
heterogêneos de multicomputadores. Embora o gerenciamento do hardware seja um 
importante assunto para o SOR, a distinção entre sistemas operacionais tradicionais e 
de rede, vem do fato dos serviços de redes ficarem disponíveis a clientes remotos. 
Para um sistema operacional de rede ser configurado para um sistema distribuído, 
melhorias aos seus serviços são necessárias de maneira que o suporte para 
transparência de distribuição seja provido, ou seja, os recursos compartilhados dos 
computadores são acessados pelos usuários de forma transparente independente de 
sua identificação ou localização. Estas melhorias são implementadas com a tecnologia 
middleware, que é o coração dos sistemas distribuídos modernos. 
A Figura 63 mostra transparência no acesso a um típico sistema distribuído. O cliente 
quando acessa a internet inicialmente se conecta ao seu provedor de serviços web, 
contudo o cliente quando está navegando pela internet não se preocupa de onde vem 
os dados ou mesmo de algumas aplicações, como por exemplo o acesso a nuvem 
(cloud computing). 
Figura 63: Transparência de acesso do cliente ao sistema, comum em 
sistemas distribuídos. 
 
<Saiba mais início> 
Observe a Figura 64, o middleware é o principal componente de um sistema 
distribuído. É uma camada adicionada ao sistema operacional de rede, que fica 
localizada entre as camadas de Aplicação e a camada de Transporte, oferecendo 
18 
 
um alto nível de abstração. Assim, tais aplicações não fazem uso direto da 
interface de programação oferecida pelos sistemas operacionais de rede, permite 
que processos em diferentes máquinas troquem mensagens, ou do acesso ao 
sistema de arquivo local, o que aumenta a transparência de distribuição. 
Figura 64: Implementação da camada de rede middleware para um sistema distribuído. 
 
<Saiba mais fim> 
Sommerville (2011) recomenda os requisitos não funcionais aplicados na arquitetura 
do software, que estabelecem o estilo e a estrutura da arquitetura particular que você 
escolhe. Os principais requisitos não funcionais recomendados são: Desempenho; 
Proteção; Segurança; Disponibilidade; e Manutenção. 
8.1.2 Arquiteturas multiprocessadas e multicomputadorizadas 
No multiprocessamento existe mais que um processador funcionando na mesma 
memória, mas executa processos simultâneos. Em um sistema de multiprocessamento 
são empregados múltiplos processadores que executam mais de uma atividade no 
mesmo tempo. O processamento de dados executado regularmente faz com que estes 
dados sejam processados concorrentemente por processadores diferentes. 
O multiprocessamento fornece uma sincronização entre os múltiplos processadores 
para acessarem a memória de forma comum, de modo que nenhuma parte dos dados 
seja negligenciada. 
A arquitetura de multiprocessamento como é mostrada na Figura 65 fornece um 
ambiente de multiprogramação, permitindo que múltiplos programas residam em áreas 
separadas da memória principal ao mesmo tempo. Com esta aproximação, é possível 
manter dois ou mais empregos simultaneamente na execução ou em estados da 
execução. Os sistemas de computador multiprocessado são caros e encontraram o seu 
uso em dados complexos que processam aplicação em ponto flutuante e em alta 
velocidade. 
19 
 
Tanenbaum (2013) explica no texto a seguir como funciona o sistema de 
multiprocessamento da CPU Core i7 que usa como base a Figura 65. 
<citação direta início> 
A CPU Core i7 é um processador em um único chip manufaturado com 
quatro ou mais núcleos em uma única pastilha de silício. A organização 
de alto nível de um processador Core i7 tem suas próprias caches: L1 
privada para instrução e dados, e L2 unificada e privada para 
armazenamento de lista de instruções. Os processadores são conectados 
às caches privadas com conexões ponto a ponto dedicadas. O próximo 
nível da hierarquia de memória é a cache de dados L3 compartilhada e 
unificada (TANENBAUM, 2013, p. 449). 
 
Figura 65: Arquitetura do multiprocessador em um único chip do Core i7. 
 
Fonte: TANENBAUM (2013), p. 449. 
Uma arquitetura multicomputadorizada é formada por um aglomerado de 
computadores, que quando conectados em uma rede local, podem constituir um cluster. 
O ambiente multicomputacional é formado por um conjunto de computadores, que se 
utiliza um tipo especial de sistema operacional classificado como sistema distribuído. É 
construído muitas vezes a partir de computadores convencionais, ligados em rede que 
se comunicam através do SOR. O cluster de computador trabalha como se fosse um 
único computador de grande porte. 
A arquitetura da Figura 66 mostra uma estratégia de sistemas escaláveis da LC (o 
"Livermore Model") ao hardware de commodities executando o sistema operacional 
Linux de código aberto. 
Figura 66: Clusters Linux no Lawrence Livermore National Laboratory (LLNL). 
20 
 
 
Fonte: BARNEY (2016). 
https://computing.llnl.gov/tutorials/linux_clusters/images/liv_model2.gif 
Os sistemas de cluster Linux LC mostrado na Figura 67 é baseado no sistema Zin, 
com rede Ccah, possui 2.916 nós, 46.656 núcleos e 961.1 Tflops. 
Figura 67: Sistemas TLCC2 consistem em vários clusters baseados no sistema 
Zin com processadores Intel Xeon E5-2670 (Sandy Bridge EP), 
QDR Infiniband. 
 
Fonte: BARNEY (2016). 
https://computing.llnl.gov/tutorials/linux_clusters/images/zin.440pix.jpg 
<Saiba mais início> 
Consulte a referência a seguir: 
21 
 
BARNEY, B. Visão geral do Linux Clusters. Lawrence Livermore National Laboratory. 
Departamento de Energia dos EUA, 2016. Disponível em: 
https://computing.llnl.gov/tutorials/linux_clusters/. Acesso em: 3 mar. 2021. 
<Saiba mais fim> 
8.2 Testes e diagnósticos 
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). 
<Lembrete início> 
A Figura 6 no “Tópico1.5 Características do software – Unidade I” faz um 
comparativo sobre as falhas do software e mostra que os defeitos do software 
ocorrem com as mudanças no software, devido a diversas situações que ocorrem 
no ciclo de vida do software. 
Em Princípios de testes no “Tópico 7.2.4 Princípios de Construção – Unidade IV” 
destaca que “o objetivo do teste de software é rastrear o código em busca de 
erros. O bom teste é aquele com alta probabilidade de encontrar erros [..]. 
<Lembrete fim> 
A premissa da necessidade de fazer testes, extrair resultados e solucionar ou evitar 
o problema é a arte do engenheiro de software (veja a Figura 68) não é verdadeira, mas 
muitos dos erros do software transmitem este impacto. Ninguém gosta disto, mas com 
certeza todos já passaram por algo semelhante. Quando não for uma mudança a ser 
implementada, a maioria das falhas do software começa assim com alguma mensagem 
de erro impactante. 
Figura 68: Erro absurdo.
 
Fonte: ALLAN (2011). 
 
“Huum, que erro estranho. Aqui diz para deletar o Windows!” 
“E se for verdade? Meus dados são mais importantes que o 
sistema operacional?” 
“E se não for verdade? Seria o hardware ou um vírus?” 
 
A Figura 68 mostra como a história começa se não houver testes do 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”. 
22 
 
Planeje antes e dependendo da urgência relaxe um pouco para meditar sobre o erro 
com o som “Windows Error Remix 2014”, Jefferson Allan. Disponível em 
https://www.youtube.com/watch?v=djlot1_Eots. Acesso em 27/07/2020. 
Os testes e diagnósticos do software têm como objetivo validar a aplicação, verificar 
se está funcionando de acordo, se atende aos requisitos do usuário, funcionais, não-
funcionais e do sistema em número e grau. Diversas técnicas podem ser aplicadas em 
diferentes momentos e de diferentes formas para validar os aspectos principais do 
software. Neste livro serão abordadas duas técnicas de destaque no contrato do 
software, quais sejam, os Testes Alfa e Beta, e os Testes Caixa-branca e Caixa-preta. 
8.2.1 Testes Alfa e Beta 
Quando um software é construído especificamente para um cliente, é normal ele 
passar por um Teste de Aceitação. Esse teste por ser conduzido pelo próprio usuário, 
pode passar por uma bateria de testes levando às vezes semanas, ou mesmo meses, 
para ser finalizado. No entanto, se o software é feito para vários clientes, o Teste de 
Aceitação não é viável de ser realizado por cada usuário principal. Por isso, a estratégia 
melhor a ser aplicada é a dos Testes Alfa e Beta. 
Para a realização do Teste Alfa existe a necessidade de um ambiente controlado. 
Ou seja, os usuários são levados a testar o software desde seus estágios iniciais de 
instalação, até a sua operação completa. Tudo realizado num ambiente especial, onde 
ficam registradas todas as impressões dos usuários, suas reações às interfaces 
homem-máquina, e assim por diante. 
O Teste Beta é realizado exclusivamente no habitat do usuário. É realizado 
tipicamente sem a presença dos desenvolvedores, porém acompanhados por esses. 
Ao contrário do Teste Alfa o ambiente de teste é dito descontrolado. Os usuários 
envolvidos no teste normalmente possuem um perfil crítico e colaborador. Em alguns 
casos o software é fornecido a usuários de forma que os desenvolvedores consigam do 
próprio usuário suas observações, questionamentos e sugestões, registrado de forma 
minuciosa e com riqueza de detalhes. 
8.2.2 Testes Caixa-preta e Caixa-branca 
Para um sistema encomendado ou configurado especificamente para um 
determinado negócio, o processo de Verificação e Validação (V&V) tem como objetivo 
demonstrar que um software atende aos requisitos especificados (verificação) e que 
realmente atendam as expectativas dos stakeholders (validação). Os testes Caixa-
Preta e Caixa-Branca 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. 
O Teste Caixa-preta também chamado de Teste Comportamental visa identificar 
as falhas em seu comportamento externo com o foco nos requisitos funcionais, 
conduzidos na interface do software e o Teste Caixa-branca também, chamado de 
Teste Estrutural, é focado nos possíveis erros internos na estrutura dos componentes 
do sistema. 
23 
 
<citação direta início> 
Conhecendo o funcionamento interno de um produto, podem ser 
realizados testes para garantir que “tudo se encaixa”, isto é, que as 
operações internas foram realizadas de acordo com as especificações e 
que todos os componentes internos foram adequadamente exercitados. 
A primeira abordagem de teste usa uma visão externa e é chamada de 
teste caixa-preta. A segunda abordagem requer uma visão interna e é 
chamada de teste caixa-branca (PRESSMAN, 2011, pgs. 430-431). 
 
Inicialmente para realizar os testes caixa-preta ou testes caixa-branca é sugerido que 
se crie casos de testes, que possam ser especificados em uma tabela como é mostrada 
abaixo. Para melhor referência observe na Figura 69 a tabela de casos de testes. A 
tabela se refere aos testes caixa-preta. Na primeira coluna mostra os códigos de casos 
de testes representados pela sigla CTP. Na segunda coluna os códigos de referência 
para os testes, com as siglas RF para requisito funcional e RS para requisito do sistema 
e na terceira coluna a especificação do teste. 
Figura 69: Tabela de casos de testes que associa o caso de teste com os requisitos específicos do 
produto. 
Caso de 
teste 
Referência Especificação 
CTP01 
RF01, 
RF01.1, 
RF01.2. 
CTP01: Testes MVC – apresentação de relatórios: 
1. Ver em menu de Relatórios os relatórios disponíveis e se estão de acordo 
com os requisitos. 
2. Verificar exibição de relatórios se está de acordo com os requisitos e 
registros de dados. 
3. Textos e mensagens deverão ser exibidos em sua integra. 
4. Revisar cálculos. 
CTP02 
RS01, RS02, 
RS03. 
CTP02: Ambiente do usuário. 
1. Tipo de computador esta de acordo com requisitos. 
2. Sistema operacional e Navegador estão de acordo com os requisitos do 
sistema 
 
O principal objetivo do Teste Caixa-Preta é testar as operações ligadas aos requisitos 
funcionais “[..] o Teste Caixa-Preta tenta encontrar erros nas seguintes categorias 
(PRESSMAN, 2011)”: 
➢ Funções incorretas ou omitidas; 
➢ Erros de interface; 
➢ Erros de estrutura de dados ou de acesso à base de dados pelo usuário; 
24 
 
➢ Erros de comportamento ou desempenho; e 
➢ Erros de iniciação e finalização do software. 
Principais técnicas utilizadas nos Testes de Caixa-Preta: 
➢ Métodos de teste baseados em grafo de fluxo: 
 Modelagem de fluxo de transação – sequência de passos de uma determinada 
transação. 
 Modelagem de estado finito – situação final das operações e das estruturas de dados, 
com objetivo de reduzir redundâncias de códigos e dados. 
 Modelagem do fluxo de dados – modela a sequência de tratamento dos dados entre 
um objeto e outro. 
 Modelagem no tempo – especificação de tempos na execução de programas. 
➢ Particionamento de equivalência – método que divide o domínio de entrada de um 
programa em classes de dados. 
➢ Análise de valor-limite – avaliação dos limites dos campos de entradas de dados. 
➢ Teste de Matriz Ortogonal – refere-se ao número de parâmetros de entrada em relação 
ao número de ligações às funções operacionais. 
O teste caixa-branca, também chamado de teste da caixa-de-vidro, é uma filosofia 
de projeto de casos de teste que usa a estrutura de controle descrita como parte do 
projeto no nível de componentes para derivar casos de teste (PRESSMAN, 2011). 
Uma prática comum no teste caixa-branca é à aplicação do Teste do Caminho 
Básico, muito utilizado também no teste caixa-preta. Esse teste tem como objetivo 
derivar casos de testes,orientados por meio do caminho de execução do programa. 
Para isso é usado um grafo de fluxo. Uma das notações de grafo de fluxo, sugeridas 
por Pressman (2007) é para acompanhamento da codificação como é mostrado de 
forma adaptada na Figura 70. 
Figura 70: Simbologia de comandos estruturados para o grafo de fluxo. 
 
FONTE: Adaptada. Pressman (2007), p. 432. 
25 
 
<Saiba mais início> 
Leia a referência a seguir: 
FELIZARDO, K. R. Técnicas de VV&T – Validação, Verificação e Teste. 
Linhadecódigo, [s.d.]. Disponível em: 
http://www.linhadecodigo.com.br/artigo/492/tecnicas-de-vvampt-validacao-verificacao-
e-teste.aspx. Acesso em: 3 mar. 2021. 
< Saiba mais fim> 
8.3 Manutenção do software 
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. 
<Lembrete início> 
Em Princípios de testes no “Tópico 7.2.4 Princípios de Construção – Unidade IV” foram 
apresentadas as abordagens top-down e bottom-up para testes de software. 
<Lembrete fim> 
A abordagem top-down e bottom-up para manutenção difere do teste de software no 
aspecto de que: o teste de software tem como objetivo validar o software para aceite do 
cliente e na manutenção tem como objetivo fazer mudanças no software para reparar 
defeitos, adaptar o software a um novo ambiente operacional ou fazer acréscimos de 
funções. 
Com base nos requisitos do usuário os níveis de manutenção iniciam pela interface 
do usuário, na Figura 71 representada pelo bloco software/sistema que responde pelos 
resultados operacionais do software, apesar de que neste modelo foi escolhida a 
característica funcionalidade. Esta escolha pode ser de outras características também, 
tais como: desempenho, usabilidade e outras, definidas como requisitos não-funcionais 
do software em análise. 
Figura 71: Níveis de abordagens top-down e bottom-up para mudanças no software quanto a 
funcionalidade. 
26 
 
 
Uma outra abordagem de manutenção do software pode ser orientada com base na 
Qualidade do produto da engenharia de software: ISO/IEC 9126 e ISO 25000 (NBR 
9126-1 ABNT, 2003) como mostra em destaque o texto abaixo. 
A Qualidade do produto da engenharia de software (ISO/IEC 9126) é 
composta em duas partes: 1. Qualidade interna e qualidade externa; e 2. 
Qualidade em uso. 
 Os atributos de qualidade externa e interna são categorizados em 
seis características: funcionalidade; confiabilidade; usabilidade; 
eficiência; manutenibilidade; e portabilidade. 
 Os atributos de qualidade em uso são categorizados em quatro 
características: eficácia; produtividade; segurança; e satisfação. 
(NBR 9126-1 ABNT, 2003). 
 
<Observação início> 
Na organização do desenvolvimento de software com base na ISO 9126 e ISO 
25000 (NBR 9126-1 ABNT, 2003), para garantir uma semântica comum no projeto 
do software às métricas de qualidade são chamadas de características e sub-
características. 
<Observação fim> 
8.3.1 Fundamentos da manutenção 
O processo de mudança do software ocorre em todo o seu ciclo de vida. Várias 
mudanças são feitas: adaptações a novos ambientes operacionais, customização do 
software com base nas mudanças de requisitos, erros de codificação, adaptação de 
novas interfaces, enfim tudo o que é necessário para manter o software operacional e 
adaptado a novas tecnologias. 
27 
 
<Exemplo de aplicação início> 
Estudo de caso: Leis de Lehman de 1985 (apud PRESSMAN, 2011) 
As leis de Lehman foram produzidas com base no estudo da mudança em sistemas. 
Foram examinados o crescimento e a evolução de uma série de grandes sistemas e 
software para chegar nessas leis. Duas destas leis se destacam: 
 Mudança Contínua: a qual afirma que um programa utilizado em um ambiente 
do mundo real 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, sua estrutura tende a se tornar mais complexa. Recursos extras 
precisam ser dedicados para preservar e simplificar a estrutura. 
<Exemplo de aplicação fim> 
Com base nas definições de Pressman (2011) e Sommmerville (2011) a manutenção 
do software ocorre durante todo o ciclo de vida operacional do software, motivada por 
três tipos fundamentais mostrados na tabela da Figura 72. 
Figura 72: Tipos fundamentais de manutenção. 
Tipos de Manutenção Descrição 
Manutenção para reparar os 
defeitos no software 
A correção de erros de codificação é um processo 
relativamente barato comparado com os erros de projeto. 
Os maiores custos estão nos erros de requisitos, pois irá 
implicar num reprojeto. 
Manutenção para adaptar o 
software a um ambiente 
operacional diferente 
É a típica manutenção de adaptação sofrida por alguma 
alteração no software de apoio tal como o Sistema 
Operacional, Banco de Dados ou mesmo o próprio hardware. 
Manutenção para fazer 
acréscimos à funcionalidade 
do sistema ou modificá-la. 
Na alteração dos requisitos, devido a mudanças 
organizacionais, ou nos negócios, que são bastante constantes, 
ocorre a manutenção mais comum entre todas as outras. 
Fonte: SOMMMERVILLE (2011), p. 170. 
8.3.2 Procedimentos de manutenção 
O Processo de Manutenção é normalmente iniciado pelos pedidos de mudança por 
parte dos vários usuários que utilizam o sistema. Isso pode ser de maneira informal, ou 
preferencialmente formalizado, com uma documentação estruturada. Em seguida é 
verificado o custo e o impacto das mudanças sugeridas e com as mudanças aprovadas, 
um novo release do sistema é planejado. 
28 
 
No desenvolvimento, o bom planejamento reduz em custo e tempo à entrega 
operacional do sistema. Observe a Figura 73. O Sistema 1, que embora tenha custos 
maiores de planejamento, exigiu no ciclo de desenvolvimento um custo e período menor 
de manutenção. Consequentemente, o custo e tempo total de entrega do Sistema 1 são 
menores que o do Sistema 2. O Sistema 2 foi planejado mais rapidamente com custo e 
tempo inferiores ao do Sistema 1, porém exigiu no período de manutenção um maior 
custo e tempo. O resultado final é que o Sistema 1, por ter um maior planejamento, 
obteve sobre o Sistema 2 um menor custo e tempo na entrega do sistema. 
Figura 73: Gráfico de custo e tempo entre dois sistemas. O Sistema 1 com ênfase maior no 
planejamento e o Sistema 2 com ênfase maior na manutenção. 
 
Existem equipes de manutenção especializadas em atuarem na Manutenção 
Corretiva, que ocorre quando existi uma requisição formal do usuário para solucionar 
um problema. No entanto, a melhor estratégia é a Manutenção Preventiva, 
oportunidade em que se detectam possíveis falhas e previne-se de eventuais erros. Em 
ambos os casos a equipe técnica deverá registrar a mudança que deverá ser feita no 
sistema, realizar uma força tarefa para dar manutenção e, possivelmente, fornecer 
melhorias preventivas. 
8.3.3 Prevenção de defeitos com Cleanroom 
O modelo de desenvolvimento Cleanroom é uma filosofia herdada do 
desenvolvimento de circuitos integrados. Este modelo se baseia na prevenção de 
defeitos ao invés da remoção de defeitos. Utiliza uma especificação formal, usando um 
modelo de transição de estados baseada no desenvolvimento incremental com 
inspeções rigorosas. Observe a Figura 74. 
Figura 74: Processo de desenvolvimento Cleanroom. 
 
Fonte: SOMMERVILLE ( 2003, p. 370). 
29 
 
8.4 Gerenciamento de configuração do software 
O gerenciamento de configuração (CM, do inglês configuration 
management) está relacionado com as políticas, processos e 
ferramentas para gerenciamento de mudanças dos sistemas de 
software. Você precisa gerenciar os sistemas em evolução, pois é fácil 
perder o controle de quais mudanças e versões de componentes foram 
incorporadas em cada versão de sistema (SOMMERVILLE, 2011, p. 475). 
Mostrado na tabela da Figura 75, Sommerville (2011) sugere quatro principais 
atividades do gerenciamento de configuração. 
Figura75: Principais atividades do gerenciamento de configuração do software. 
ATIVIDADES DESCRIÇÃO 
1. Gerenciamento de 
mudanças 
Com as constantes mudanças exercidas em cima dos softwares, as 
mesmas devem ser registradas e aplicadas ao sistema de forma 
prática, econômica e que satisfaça o cliente. 
2. Gerenciamento de 
versões 
Consiste em acompanhar e identificar o desenvolvimento das 
diferentes versões do sistema. 
3. Construção de 
sistemas 
Processo de compilar e ligar componentes de software em um 
programa que é executado em uma configuração específica. 
4. Gerenciamento de 
releases 
Envolve a preparação do software para o release externo e manter o 
acompanhamento das versões de sistema que foram liberadas para 
uso do cliente 
Fonte: SOMMERVILLE (2011), p. 476. 
8.4.1 Gerenciamento de mudanças 
Durante os testes de sistemas, ou ainda na manutenção depois da entrega do 
software ao cliente, os procedimentos de Gerenciamento de Mudanças devem ser 
aplicados. Sommerville (2011) orienta que o principal passo desse processo é a 
utilização de um formulário intitulado de Requisição de Mudança (ou do inglês Change 
Request Form (CRF)), mostrado na Figura 76. O formulário de Requisição de mudança 
é o registro de mudança no software que precede os procedimentos de manutenção. 
Figura 76: Modelo de formulário de Requisição de Mudança. 
Formulário de Requisição de Mudança 
Projeto: SuperBlue Código da mudança: 190729 2106 
Requisitor da Mudança: Edson Moreno Data: 29/07/2019 
 
30 
 
Requisito de mudança 
Quando ocorre a remoção de um valor na tabela de custos fixos, o valor do custo total não é 
alterado. 
Análise da mudança 
Analista: Milton del Rio Blas Data: 29/07/2019 
Componente afetado: Algoritmo de cálculo do custo total. 
 
Avaliação 
Haverá necessidade de mudança no código de cálculo do custo total na lista de custo fixo. 
 
Prioridade: Alto Prazo estimado de entrega: 3 dias 
 
Autorizada mudança: SIM ( X ); NÃO ( ); Aguardar para o dia ___ / ___ / _____. 
 
 Gerente Responsável: ____________________________ 
 
Um formulário de Requisição de Mudança pode conter as seguintes informações: 
registro da solicitação da mudança, recomendações, custos, datas de solicitação, 
aprovação, implementação e validação da mudança. É sugerido também existir um 
espaço para um esboço, mostrando como a mudança deverá ser implementada. 
Em ambiente de manutenção, esse formulário no formato eletrônico e com um 
pequeno banco de dados, oferecerá consultas rápidas, por permitir criar um histórico 
das mudanças que ocorrem ao longo do ciclo de vida operacional do software. As 
mudanças que ocorrem no software são registradas como versões, que é o próximo 
assunto a ser abordado. 
8.4.2 Gerenciamento de versões 
As mudanças ocorrem em todo o ciclo de vida do software. Quando aumentam o 
nível de complexidade e de confusão, compromete o controle na entrega do produto ou 
subproduto do software. O gerenciamento de versões acompanha e identifica o 
desenvolvimento das diferentes versões de um determinado sistema. Este processo é 
chamado de versionamento. 
As versões são criadas para testes ou desenvolvimento interno e não são liberadas 
para o cliente. 
A Figura 77 mostra que no controle de versões podem ser adotadas algumas 
técnicas básicas para a devida identificação de componente. 
31 
 
Figura 77: Técnicas básicas de numeração e indentificação da versão aplicadas no gerenciamento 
de versões. 
TÉCNICAS BÁSICAS DESCRIÇÃO 
Numeração de versões 
É o esquema de identificação mais comum. Atribui-se um número, 
explícito e único, de versão ao componente. 
Exemplo: Versão 3.21 – o dígito (3) identifica mudança de estrutura, 
o dígito (2) indica inserção de uma funcionalidade e o dígito (1) 
indica que houve a implementação de uma mudança. 
Identificação baseada em 
atributos 
Cada componente recebe um nome e um conjunto de atributos, que 
não é único em todas as versões. Exemplo: 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 
Além do anterior é associado uma ou mais solicitações de mudança. 
Exemplo: CAR_04 – Carlos requisita uma quarta mudança. 
<Exemplo de aplicação início> 
Controle de versão na identificação baseada em atributos 
Padrão de numeração de versão: X.Y.Zzzz, onde: 
 X – corresponde a uma mudança de estrutura do software. 
 Y – inserção ou adaptação de novas funções ou funcionalidade. 
 Zzzz – adaptações, correções ou implementações no código fonte. 
“Estou agora abrindo meu Windows 10. Hoje dia 28/07/2020, verifico em Informações 
do sistema a versão 10.0.18363”. Se for aplicar o conceito de identificação baseada em 
atributos, isto nos leva a seguinte análise: 
X = 10 – indica a 10ª geração de um projeto de arquitetura do Windows. 
Y = 0 – indica que não houve inserções ou adaptações de novas funções ou 
funcionalidade no projeto original. 
Zzzz = 18363 – indica as mudanças ocorridas no código fonte. 
 
<Exemplo de aplicação fim> 
Observe a Figura 78, o controle de versões (V 1.0, V 1.1 e assim por diante) 
acompanham as mudanças realizadas pelos desenvolvedores e os releases (Rel 1.0 e 
Rel 1.1) correspondem às versões aprovadas para distribuição ao usuário. A numeração 
do release independe da numeração da versão, porém neste caso pode se considerar 
o primeiro dígito como uma mudança de estrutura. Observe o grafo de controle. 
32 
 
Figura 78: Modelo de grafo de controle aplicado na numeração de versões. 
 
8.4.3 Construção de sistemas: entrega 
A construção de sistemas é o processo da criação de um sistema completo, 
executável por meio da construção e ligação dos componentes de sistema, bibliotecas 
externas, arquivos de configuração, etc (SOMMERVILLE, 2011). 
O processo de construção do sistema na entrega ao cliente é um processo complexo, 
porque além de se tomar todas as precauções constantes do projeto de implantação e 
que são inúmeras, é necessário assegurar também que o ambiente operacional do 
cliente seja mantido, quando este existir. 
O ambiente de desenvolvimento é diferente do ambiente do cliente. Para verificação 
é interessante construir ou simular todo o ambiente operacional do cliente como 
plataforma de testes. Para configurações do sistema é importante que no sistema do 
cliente estejam todas as ferramentas, bibliotecas e frameworks utilizados no 
desenvolvimento. 
Toda a versão gerada deve ser registrada e armazenada. Essa prática facilita uma 
depuração detalhada das mudanças ocorridas no software ou em alguma busca de 
algum componente ou algoritmo já produzido. 
De acordo com Sommerville (2011) a construção de sistemas envolve a montagem 
de uma grande quantidade de informações sobre o software e seu ambiente 
operacional, mostrada na Figura 79. 
Figura 79: A construção de sistemas. 
33 
 
 
Fonte: SOMMERVILLE (2011), p. 485. 
8.4.4 Gerenciamento de releases 
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, como pode ser visto também na Figura 71 no “Tópico 8.4.2 Gerenciamento 
de versões – Unidade IV”. 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. 
REFERÊNCIAS 
Textuais 
ABNT. NBR 9126/14598 – Guia para utilização das normas sobre avaliação de 
qualidade de produto de software – NBR ISO/IEC 9126 e NBR ISO/IEC 14598. Curitiba: 
ABNT, 1999. 
ABNT. NBR ISO/IEC 9126-1 – Engenharia de software – Qualidade de produto. Rio 
de Janeiro: ABNT, 2003. 
ALLAN, J. Windows Error Remix 2014, 13 fev. 2011.https://www.youtube.com/watch?v=djlot1_Eots. Acesso em: 27 jul. 2020. 
BAHN, C. IEEE 830-1998: prática recomendada do IEEE para especificações de 
requisitos de software. Comitê de Normas de Engenharia de Software e Sistemas, 20 
out. 1998 [reafirmado em 9 dez. 2009]. Disponível em: 
https://standards.ieee.org/standard/830-1998.html. Acesso em: 3 mar. 2021. 
34 
 
BARNEY, B. Visão geral do Linux Clusters. Lawrence Livermore National Laboratory. 
Departamento de Energia dos EUA, 2016. Disponível em: 
https://computing.llnl.gov/tutorials/linux_clusters/. Acesso em: 3 mar. 2021. 
BECK, K. et al. Manifesto para Desenvolvimento Ágil de Software. 
Agilemanifesto.org, 2001. Disponível em: 
https://agilemanifesto.org/iso/ptbr/manifesto.html. Acesso em: 3 mar. 2021. 
BEZERRA, E. Princípios de análise e projetos de sistemas com UML. Rio de Janeiro: 
Campus-Elsevier, 2003. 
BOOCH, G. UML: guia do usuário. São Paulo: Campus-Elsevier, 2002. 
CAMARGO, R. Extreme Programming: quais principais regras e valores? Robson 
Camargo Projetos e Negócios, 3 out. 2019. Disponível em: 
https://robsoncamargo.com.br/blog/Extreme-Programming. Acesso em: 3 mar. 2021. 
COIMBRA, Rodrigo. Ag i l e Me t h o d s : C r y s t a l . Projetos e Ti, 0 4 / 0 5 / 2 0 2 0 . 
D i s p o n í v e l e m https://projetoseti.com.br/agile-methods-crystal/. Acesso em 
09/03/2021. 
COULOURIS, G. et al. Sistemas distribuídos: conceitos e projeto. São Paulo: 
Bookman, 2007. 
DAD, K.; JAMIL, A. N. Enhanced Facilitated Application Specification Techniques 
(eFAST). In: IEEE/ACIS INTERNATIONAL CONFERENCE ON COMPUTER AND 
INFORMATION SCIENCE, 5., 2006, Honolulu (USA). Anais […]. Honululu: Institute of 
Eletrical and Eletronics Engineers (IEEE), 2006. Disponível em: 
https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1651985. Acesso em: 3 
mar. 2021. 
DELUCA, J. A importância da engenharia de software: FDD Feature-Driven 
Development. Engenheiro do Software, 7 out. 2008. Disponível em: 
http://engenheirosdosoftware.blogspot.com/2008/10/fdd-feature-driven-
development.html. Acesso em: 3 mar. 2021. 
FELIZARDO, K. R. Técnicas de VV&T – Validação, Verificação e Teste. 
Linhadecódigo, [s.d.]. Disponível em: 
http://www.linhadecodigo.com.br/artigo/492/tecnicas-de-vvampt-validacao-verificacao-
e-teste.aspx. Acesso em: 3 mar. 2021. 
HUMPHREY, W. S. A discipline for software engineering. USA: Addison-Wesley, 
1995. 
FIORINI, S.; STAA, A.; BAPTISTA, R. M. Engenharia de software com CMM. Rio de 
Janeiro: Brasport, 1998. 
FOURNIER, R. Desenvolvimento e manutenção de sistemas estruturados. São 
Paulo: Makron Books, 1994. 
35 
 
INTERNET das coisas: como ela otimiza os recursos na indústria? Digicomp 
Engenharia e Tecnologia, 2019. Disponível em: https://digicomp.com.br/internet-das-
coisas-como-ela-otimiza-os-recursos-na-industria/. Acesso em: 3 mar. 2021. 
IMOVELWEB. Entenda como a computação gráfica vem sendo utilizada no mercado 
imobiliário. Imovelweb, [s.d.]. Disponível em: 
https://www.imovelweb.com.br/noticias/socorretor/tecnologia-e-inovacao/entenda-
como-computacao-grafica-vem-sendo-utilizada-no-mercado-imobiliario/. Acesso em: 3 
mar. 2021. 
JOHNSON, P. Seis características presentes em todos os softwares bem escritos. 
Computerworld, 25 set. 2015. Disponível em: 
https://computerworld.com.br/2015/09/25/seis-caracteristicas-presentes-em-todos-os-
softwares-bem-escritos/. Acesso em: 3 mar. 2021. 
KOHN, K.; MORAES, C. H. O impacto das novas tecnologias na sociedade: conceitos 
e características da sociedade da informação e da sociedade digital. CONGRESSO 
BRASILEIRO DE CIÊNCIAS DA COMUNICAÇÃO, 30., 2007, Santos (SP). Anais [...]. 
Santos: Sociedade Brasileira de Estudos Interdisciplinares da Comunicação (Intercom), 
2007. Disponível em: 
https://www.intercom.org.br/papers/nacionais/2007/resumos/R1533-1.pdf. Acesso em: 
3 mar. 2021. 
KOSCIANSKI, A. Qualidade de software: aprenda as metodologias e técnicas mais 
modernas para o desenvolvimento de software. 2. ed. São Paulo: Novatec, 2007. 
KRUCHTEN, P. Introdução ao RUP (Rational Unified Process). 2. ed. Rio de Janeiro: 
Ciência Moderna, 2001. 
KRUCHTEN, P. The Rational Unified Process: an introduction. 2. ed. USA: Addison-
Wesley Professional, 2000. 
LAUDON, K. C.; LAUDON, J. P. Sistemas de informação gerencial: administrando a 
empresa digital. 5. ed. São Paulo: Prentice Hall, 2004. 
OBJECT MANAGEMENT GROUP (OMG). Categoria de modelagem de negócios: 
especificações associadas. [s.d.]. Disponível em 
https://www.omg.org/spec/category/business-modeling/. Acesso em: 3 mar. 2021. 
O´BRIEN, JAMES, A. Sistemas de informação e as decisões gerenciais na era da 
internet. São Paulo: Saraiva, 2002. 
PAKISTAN INSTITUTE OF ENGINEERING AND APPLIED SCIENCES (PIEAS). 
Cyclic personal process-software quality-lecture. Paquistão: Pieas, 2017. Disponível 
em: https://www.docsity.com/en/cyclic-personal-process-software-quality-lecture-
slides/80929/. Acesso em: 3 mar. 2021 
PAULA FILHO, W. P. Engenharia de software: fundamentos, métodos e padrões. 3. 
ed. Rio de Janeiro: L TC, 2015. 
36 
 
PAULA FILHO, W. P. O processo Praxis 3.0. Vdocuments, 17 abr. 2015. Disponível 
em: https://vdocuments.site/o-processo-praxis-30-2008-wilson-de-padua-paula-filho-o-
processo-praxis-30-wilson-de-padua-paula-filho-professor-aposentado-dcc-icex-ufmg-
diretor.html, 2008. Acesso em: 3 mar. 2021. 
PFLEEGER, S. L. Engenharia de software. 2. ed. São Paulo: Prentice Hall, 2004. 
PINTO, M. Introdução ao debugging de software. pplware, 10 mar. 2015. Disponível em: 
https://pplware.sapo.pt/software/introducao-ao-debugging-de-software/. Acesso em: 3 
mar. 2021. 
PMI MG. PROJECT MANAGEMENT BODY OF KNOWLEDGE (PMBOK 2000). Um 
guia do conhecimento em gerenciamento de projetos. 2. ed. Minas Gerais: PMI MG: 
Project Management Institute (PMI), 2002. Tradução livre do PMBOK 2000. 
PROJECT MANAGEMENT BODY OF KNOWLEDGE (PMBOK). Um guia do 
conhecimento em gerenciamento de projetos. 4. ed. Atlanta (EUA): Project Management 
Institute (PMI), 2010. 
PROJECT MANAGEMENT BODY OF KNOWLEDGE (PMBOK). Um guia do 
conhecimento em gerenciamento de projetos. 6. ed. Atlanta (EUA): Project Management 
Institute (PMI), 2017. 
PRESSMAN, R. S. Engenharia de software. 5. ed. Rio de Janeiro: McGraw-Hill, 2002. 
PRESSMAN, R. S. Engenharia de software. 6. ed. Rio de Janeiro: McGraw-Hill, 2007. 
PRESSMAN, R. S. Engenharia de software: uma abordagem profissional. 7. ed. Rio 
de Janeiro: McGraw-Hill, 2011. 
REALIDADE aumentada é vista como solução por empresários. Computerworld, 7 
abr. 2020. Disponível em: Disponível em 
https://computerworld.com.br/2020/04/07/realidade-aumentada-e-vista-como-solucao-
por-empresarios/, 07/04/2020. Acesso em: 3 mar. 2021. 
REZENDE, D. A. Engenharia de software e sistemas de informação. 3. ed. ed. Rio 
de Janeiro: Brasport, 2005. 
ROCHA, R. S. Modelagem do processo de desenvolvimento e manutenção de 
software para a UINFOR/UESB. Cadernos do Sep Adm, Bahia, n. 3, p. 91-109, 2006. 
Disponível em: 
http://www.cadernosnpga.ufba.br/viewarticle.php?id=107&layout=abstract. Acesso em: 
3 mar. 2021. 
SERRA, A. P. Modelos de processo pessoal e de equipe. In: CONFERÊNCIA DA 
QUALIDADE DE SOFTWARE, 4., 2011, São Paulo. Anais [...]. São Paulo: Universidade 
São Judas, 2011. Disponível em: https://docplayer.com.br/16240196-Profa-dra-ana-
paula-goncalves-serra-prof-anapaula-saojudas-br.html. Acesso em: 3 mar. 2021. 
37 
 
SHEPHERD, G. Microsoft ASP.NET 3.5: passo a passo. Porto Alegre: Bookman, 
2009. 
SILVA, T. A. S. Modelos UML estáticos vs. dinâmicos. TASSinfo, 19 abr. 2016. 
Disponível em: http://tassinfo.com.br/orientacao-a-objeto/11-modelos-uml-estaticos-vs-
dinamicos. Acesso em: Acesso em: 3 mar. 2021. 
SOMMERVILLE, I. Engenharia de software. 6. ed. São Paulo: Pearson Prentice Hall, 
2003. 
SOMMERVILLE, I. Engenharia de software. 8. ed. São Paulo: Pearson Prentice Hall, 
2006. 
SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Pearson Prentice Hall, 
2011. 
STAIR, R.M.; REYNOLDS, G. W. Princípios de sistemas de informação: uma 
abordagem gerencial. 6. ed. São Paulo: Pioneira Thomson Learning, 2006. 
TANENBAUM, A. S. Organização estruturada de computadores. São Paulo: Pearson 
Prentice Hall, 2013. 
TANENBAUM, A. S. Sistemas distribuídos: princípios e paradigmas. 2. ed. São 
Paulo: Pearson Prentice Hall, 2008. 
VALLE, Marcelo Elias del. Camadas na arquitetura de referência JavaEE. Disponível 
em https://www.devmedia.com.br/camadas-na-arquitetura-de-referencia-javaee/6037, 
2007. Consultado em 25/07/2020. 
VERSOLATTO, F. R. Projeto de sistemas: projeto de sistemas orientado a objetos. 
São Paulo: Sol, 2015. 
Sites 
http://agilemodeling.com 
https://www.ibm.com/br-pt 
https://www.microsoft.com/pt-br 
https://www.sap.com/brazil/index.html 
https://www.totvs.com 
 
 
https://www.ibm.com/br-pt
https://www.microsoft.com/pt-br
https://www.sap.com/brazil/index.html
https://www.totvs.com/