Engenharia de Software

Prévia do material em texto

SISTEMAS DE
 INFORMAÇÕES 
 GERENCIAIS
Copyright © Todos os direitos desta obra são da Escola Superior Aberta do Brasil.
www.esab.edu.br
Diretor Geral:
Nildo Ferreira
Secretário Geral:
Aleçandro Moreth
Diagramadores
Felipe Silva Lopes Caliman
Rayron Rickson Cutis Tavares
Produção do Material 
Didático-Pedagógico
 Escola Superior Aberta do Brasil
www.esab.edu.br 3
Sumário
1. Apresentação..........................................................................07
2. Qual a diferença entre Engenharia de Software e Engenharia
de Sist.? O que é um método de Engenharia de Software? . 08
3. Quais são os atributos de um bom Software? Quais são os
desafios enfrentados pela Engenharia de Software? ............ 17
4. Modelos de Processos de Software - Paradigmas do
desenvolvimento de Software - Modelo Balbúrdia - Modelo
Cascata ................................................................................. 24
5. Paradigmas do desenvolvimento de Software - Modelo Espiral
- Modelos mistos e características genéricas....................... 35
6. Paradigmas da Engenharia de Software: Processo, Métodos e
Ferramentas .......................................................................... 38
7. Resumo ................................................................................. 46
8. Apresentação 1 ..................................................................... 47
9. Introdução ao RUP (Rational Unified Process) - Características
- Fases e Workflows- Modelos de Maturidade – CMM
(Capability Maturity Model) .................................................... 48
10. Requisitos de Software - Requisitos Funcionais e não
Funcionais - Requisitos de Usuário e de Sistema - Técnicas de
Análise de Requisitos - O Documento de Requisitos de
Software ................................................................................ 56
11. Processos de Engenharia de Requisitos - Estudos de
Viabilidade - Modelagem – UML: Unified Modeling Language
– Linguagem de Modelagem Unificada..................................62
12. Metodologias de Desenvolvimento Ágeis de Software: XP –
FDD – DSDM – Scrum – Crystal – ASD e AM ...................... 69
www.esab.edu.br 4
13. Engenharia de Projeto - Projeto Modular - Projeto de interface
com o usuário - Arquiteturas de Sistemas Distribuídos -
Arquitetura de Multiprocessadores........................................79
14. Resumo.................................................................................86
15. Apresentação 2.....................................................................87
16. Arquitetura cliente-servidor - Mudanças em Software -
Dinâmica da Evolução de Programas - Evolução da
Arquitetura.............................................................................88
17. Reengenharia de Software - Tradução de código fonte -
Engenharia Reversa - Melhoria de estrutura de programa
- Reengenharia de Dados e suas abordagens......................96
18. Gerenciamento de Configuração - Gerenciamento de
Mudanças - Gerenciamento de Versões e Releases -
Construção de Sistemas - Ferramenta CASE.....................101
19. Sistemas Legados - Estruturas dos Sistemas Legados -
Avaliação dos Sistemas Legados - Manutenção: fundamentos
da fase de Manutenção de Software, tipos de Manutenção,
procedimentos, técnicas e ferramentas ..............................109
20. Gestão de Projetos de Software e o PMBOK - Gerenciamento
de Qualidade e Estratégias de Teste de Software-
Engenharia de Software na WEB – Sistemas e Aplicações
baseadas na WEB..............................................................117
21. Resumo 3............................................................................132
22. GLOSSÁRIO.......................................................................133
23. BIBLIOGRAFIA...................................................................136
www.esab.edu.br 5
Palavras do Tutor
A Engenharia de Software preocupa-se com o desenvolvimento e 
manutenção de sistemas de software que produzem software 
eficientes e confiáveis, são acessíveis para desenvolver e manter 
todos os requisitos que os clientes definiram. Engenharia de 
Software integra matemática, informática e práticas significativas 
cujas origens estão na engenharia, utilizando princípios que 
costumam lidar com sistemas físicos, design, desenvolvimento, 
testes, implantação e gerenciamento.
Objetivo
Demonstrar a capacidade de desenvolver, incorporar e gerenciar 
processos e sistemas de software de tamanho e complexidade 
variados através do uso do conhecimento fundamental de 
engenharia de software, trabalho em vários níveis de abstração e 
com ferramentas, tecnologias, metodologias e práticas de 
qualidade apropriadas ao domínio no desenvolvimento de produtos 
de software.
Ementa
Engenharia de Software, A diferença entre Engenharia de Software 
e Engenharia de Sistemas, Método de Engenharia de Software, 
Atributos de um bom Software, Desafios enfrentados pela 
Engenharia de Software, Modelos de Processos de Software, 
Paradigmas do desenvolvimento de Software, Modelo Balbúrdia, 
Modelo Cascata, Paradigmas do desenvolvimento de Software, 
Modelo Espiral, Modelos mistos e características genéricas, 
Paradigmas da Engenharia de Software: Processo, Métodos e 
Ferramentas, Introdução ao RUP (Rational Unified Process) 
www.esab.edu.br 6
- Características - Fases e Workflows, Requisitos de Software - 
Requisitos Funcionais e não Funcionais - Requisitos de Usuário e 
de Sistema, Processos de Engenharia de Requisitos - Estudos de 
Viabilidade, Metodologias de Desenvolvimento Ágeis de Software: 
XP – FDD – DSDM – Scrum – Crystal – ASD e AM, Engenharia de 
Projeto - Projeto Modular - Projeto de interface com o usuário, 
Arquitetura cliente-servidor, Reengenharia de Software - Tradução 
de código fonte - Engenharia Reversa - Melhoria de estrutura de 
programa, Gerenciamento de Configuração - Gerenciamento de 
Mudanças - Gerenciamento de Versões e Releases, Sistemas 
Legados - Estruturas dos Sistemas Legados - Avaliação dos 
Sistemas Legados, Gestão de Projetos de Software e o PMBOK. 
Sobre o autor
1. Professor e Consultor de Tecnologia de Informação. 
2. Doutorando (ITA) e Mestre (IPT) em Engenharia de 
Computação, Pós-Graduado em Análise de Sistemas 
(Mackenzie), Administração (Luzwell-SP), e Reengenharia 
(FGVSP). Graduado/Licenciado em Matemática. 
3. Professor e Pesquisador da Universidade Anhembi Morumbi, 
UNIBAN, e ESAB (Ensino a Distância). Autor de livros em 
Conectividade Empresarial. Prêmio em e - Learning no 
Ensino Superior (ABED/Blackboard).
4. Consultor de T.I. em grandes empresas como SEBRAE, 
SENAC, Granero, Transvalor, etc. Viagens internacionais: 
EUA, França, Inglaterra, Itália, Portugal, Espanha, etc. 
www.esab.edu.br 7
ENGENHARIA DE SOFTWARE: DEFINIÇÕES E CONCEITOS 
A Engenharia de Software, conforme Sommerville (2011) um dos 
papas dessa área, é uma disciplina da engenharia que se ocupa 
de todos os aspectos da produção de software. Isso vai desde os 
estágios iniciais de especificação de um Sistema, até propriamente 
a Manutenção para que esse mesmo Sistema sobreviva ao longo 
do tempo.
A construção de software é uma das atividades mais complexas e 
vitais para o pleno sucesso de um Sistema informatizado. A 
Engenharia de Software justamente tenta, através dos princípios 
básicos de outras engenharias, trazer um pouco mais de luz para 
essa atividade complexa.
Objetivo
Levar o aluno(a) a uma melhor compreensão sobre o 
desenvolvimento de softwares, como apresentar as diferenças e 
definir método, bem como visualizar a interação que os sistemas 
possuem entre si definindo atributos de software e contextualizar 
a Engenharia de Software, entender os principais modelos de 
processos e de desenvolvimento de software relacionando os 
vários modelos de desenvolvimento de software., compreendendo 
assim os elementos dos paradigmas da Engenharia de Software 
e contextualizar um ambiente de desenvolvimento de software.
www.esab.edu.br8
A cobrança hoje das áreas de Informática e de T.I. (Tecnologia da 
Informação) é desenvolver Sistemas de forma rápida, com 
qualidade, e com custos cada vez menores. (O’LEARY; STUDER, 
2001; ABECKER et al., 2001). Somente através de tecnologias 
adequadas, e com as melhores práticas, podemos atender a esses 
novos desafios.
A Engenharia de Software é constituída de metodologias, 
métodos e ferramentas que permitem ao profissional especificar, 
projetar, implementar e manter Sistemas, avaliando e garantindo 
as qualidades especificadas pelos usuários.
Figura 1: Livros adotados para este módulo.
Fonte: Próprio autor.
www.esab.edu.br 9
Software
Muitos acham que Software são apenas programas de 
computadores. Mas que na verdade não restringe apenas a 
programas de computadores a visão é muito mais ampla do que 
se imaginam e não simplesmente apenas a programa. Segundo 
Sommerville (2011), software consiste em um conjunto de 
programas separados; arquivos de configuração e documentação 
de usuário, usado para configurar sistemas e realizar treinamentos; 
documentação de sistema, que descreve a estrutura do sistema; 
e sites Web por meio dos quais os usuários obtêm informações 
recentes sobre o produto.
Os engenheiros de softwares são o que produzem produtos de 
software que pode sr vendido para cliente. Segundo Sommerville 
(2011) existem dois tipos fundamentais de produto de software:
“Produtos genéricos. São sistemas do tipo stand-alone, 
produzidos por uma organização de desenvolvimento 
e vendidos no mercado para qualquer cliente disposto 
a compra-los. Desnte os exemplos deste tipo de 
produto estão os software para PCs, como banco de 
dados, processadores de texto, pacotes gráficos e 
ferramentas de gerenciamento de projetos
Produtos sob encomenda (ou personalizados). São os 
sistemas encomendados por um determinado cliente. 
O software é desenvolvido especialmente para aquele 
por uma empresa de software. Dentre os exemplos 
deste tipo de software destacam-se os sistemas de 
controle de dispositivos eletrônicos, desenvolvidos 
para apoiar um determinado processo de negócio e 
sistema de controle de tráfego aéreo”(SOMMERVILLE, 
2011).
www.esab.edu.br 10
Uma grande diferença entre esse dois tipos de software é que os 
software produzidos sob encomendas a especificação normalmente 
é produzida e controlada pela organização que encomentou o 
software, já o produto genérico a documentação e desenvolvida e 
controlada pela organização que desenvolve o produto.
Engenharia de Sistemas
A Engenharia de Sistemas é mais genérica e mais abrangente 
do que a Engenharia de Software. Na verdade, a segunda faz 
parte da primeira. A Engenharia de Sistemas é mais antiga do 
que a de Software. Enquanto a primeira está mais envolvida com 
o Sistema como um todo e seus detalhes, a Engenharia de 
Software é mais específica no que tange aos componentes do 
sistema, em especial ao hardware e software.
Processo de software
Summerville (2011), define processo de software um conjunto de 
atividades e resultados associados que produz um produto de 
software. Existem 4 atividades fundamentais de processo que são 
comuns a todos os processos de software: Especificação de 
software: responsável por definir o software que será produzido 
juntamente com as suas restrições para operação; Desenvolvimento 
de Software: responsável pela projeção e programação do 
software; Validação do Software: responsável por verificar se o 
software realmente foi produzido conforme o desejo do cliente; 
Evolução do software: responsável por adaptar o software para 
atender aos requisitos de mudança do cliente.
Os processos de desenvolvimento de software não são os mesmos 
para diferentes tipos de sistemas, eles podem variar de acordo 
www.esab.edu.br 11
com o software que está sendo produzido. Por exemplo, im 
software de tempo real de uma aerovane deve ser completamente 
especificado antes do início do desenvolvimento, enquanto nos 
sistema de comércio eletrônico a especificação e o programa são, 
geralmente, desenvolvidos com conjunto. Consequentemente 
essas atividades genéricas podem ser organizadas de diferentes 
maneiras e descridas em níveis diferentes de detalhes, para 
diferentes tipos de sistemas.
Modelo de processo de software
O modelo de processo de software descreve de forma simplificada 
o processo que representa uma visão de como o software será 
construído. As atividades pertencem os modelos de processo de 
software, os produtos de software e os papéis das pessoas 
envolvidas em engenharia de software. Segue alguns exemplos 
dos tipos de modelo de processo de software que podem ser 
produzidos:
Modelo de workflow: monstra a sequência das atividades ao longo 
do processo; Modelo de fluxo de dados: representa o processo 
como um conjunto de atividades, no qual cada atividades realiza 
alguma transformação de dados; Modelo de papel/ação: representa 
os papéis das pessoas envolvidas no processo de software e as 
atividades relacionadas.
Boa parte dos modelos de software são baseados em três modelos 
gerais ou paradigma de desenvolvimento de software: Modelo em 
cascada; desenvolvimento interativo; engenharia de software 
baseado em componentes. Mais adiante retornaremos a esses 
modelos de processo s genéricos.
www.esab.edu.br 12
Método de Engenharia de Software
Sommerville (2011), afirma que um método de Engenharia de 
Software é uma abordagem estruturada para o desenvolvimento 
de software. Podemos definir como abordagem estruturada a 
estratégia de desenvolver algo com uma estrutura previamente 
estudada, ou baseada nas melhores práticas. O objetivo maior de 
tudo isso é facilitar a produção, em curto espaço de tempo, de 
software de alta qualidade, apresentando uma relação custo-
benefício interessante.
Um ponto importante a observar é que não existe, repito, não 
existe um método ideal. As possibilidades e os ambientes de 
desenvolvimento são tão complexos, que dependendo de cada 
situação e momento, existe um método que possa explorar mais 
alguns tópicos, mas deixará outros em aberto.
Outro ponto a ressaltar é que existem vários métodos na 
Engenharia de Software, mas poucas Metodologias. Podemos 
entender Metodologia tanto pelas palavras de Maddison apud 
Avison e Fitzgerald (1997, p.418), como sendo um conjunto 
recomendado de filosofias, fases, procedimentos, técnicas, regras, 
ferramentas, documentação, gerenciamento e treinamento para o 
desenvolvimento de um sistema de informação, como também o 
estudo de um ou mais métodos.
No início da computação poucos programadores seguiam algum 
tipo de metodologia baseando-se, em sua maioria, na própria 
experiência. Na Engenharia de Software existem basicamente 
duas grandes metodologias. Uma originária da década de 70 
chamada de Metodologia Estruturada, e a mais recente intitulada 
de Metodologia Orientada a Objetos.
www.esab.edu.br 13
Diferenças das Metodologias
Tanto a abordagem estruturada quanto a orientada a objetos 
promovem soluções práticas. A diferença entre as duas 
metodologias é a vida útil e facilidade de manutenção de projetos. 
A possível reutilização de um código estruturado não é comum, 
enquanto que um código orientado a objetos, por possuir embutido 
em sua própria filosofia as facilidades de reutilização e de descrição, 
utilizando UML (Unified Modeling Language), aumenta 
naturalmente a vida útil dos códigos.
Abordando o software sob um ponto de vista puramente estruturado, 
definem-se os dados do sistema em uma posterior sequência de 
eventos que acarretará na transformação do estado do sistema.
Por outro lado, numa abordagem focada em orientação a objetos, 
definem-se estruturas abstratas, denominadas classes, que serão 
responsáveis por partes da solução do problema. Cada classe 
incorporará dados (forma) e métodos (comportamentos). Projetos 
orientados a objetos utilizam da linguagem de modelagem UML 
(Unified Modeling Language). Esta linguagem é fruto dos esforços, 
em conjunto, dos autores Booch (1993), Rumbaugh(1991) e 
Jacobson (1992).
Teoria de Sistemas - Interdependência de Sistemas
Um Sistema é uma coleção significativa de componentes inter-
relacionados, que trabalham em conjunto para atingir alguns 
objetivos (SOMMERVILLE, 2011). É organizado para executar 
certo método, procedimento ou controle ao processar informações. 
Automatiza ou apoia a realização de atividades humanas através 
do processamento de informações.
www.esab.edu.br 14
As complexas relações entre os componentes de um sistema 
significam que o sistema em si é maior do que simplesmente a 
soma de suas partes.
As Arquiteturas de Sistema são normalmente descritas com o uso 
de Diagramas de Blocos, mostrando os subsistemas principais e 
suas relações. Veja na figura 2 um exemplo desse conceito:
Figura 2: Fronteira do sistema
Fonte: Próprio auto.
Nós encontramos, na figura 2, os elementos de entrada e de 
saída do sistema. E na parte interna do sistema a composição 
da inter-relação de várias entidades. Na parte inferior do sistema 
temos um importante conceito de feedback chamado de controle 
do sistema.
www.esab.edu.br 15
Inicia-se esse controle com um padrão de comparação. Através 
de um sensor que mensura periodicamente as alterações do 
sistema, compara-se com o padrão. Uma vez o sistema sofrendo 
alterações em relação ao padrão, o ativador irá passar parâmetros 
para o sistema se autocorrigir.
Um bom exemplo prático deste conceito é imaginarmos o ar 
condicionado. Parte-se inicialmente da base de uma temperatura 
estabelecida por nós (padrão). O sensor mensura as variações 
de temperatura. E o ativador irá deixar o ar condicionado ativado 
até novamente o sensor verificar que a temperatura está no 
padrão desejado.
Estudo Complementar
Aprofunde seus estudos com o artigo recomendado: 
"Aspectos e reflexões conceituais sobre informação, 
sistemas e teoria de sistemas" 
https://eg.uc.pt/bitstream/10316/36470/1/
Art_01_CINFORM_2007.pdf
https://eg.uc.pt/bitstream/10316/36470/1/Art_01_CINFORM_2007.pdf
www.esab.edu.br 16
PARA SUA REFLEXÃO
Acesse o documento no site abaixo e veja maiores detalhes 
da interessante “Teoria de Sistemas”:
http://www.abdl.org.br/filemanager/download/4/
teoria%20de%20sistema.pdf
www.esab.edu.br 17
Os atributos de um bom software refletem seu comportamento 
quando em funcionamento, a estrutura e a organização do 
programa fonte, e também a documentação associada 
(SOMMERVILLE, 2011). Como exemplos, tem-se o tempo de 
resposta do software à consulta de um usuário e a facilidade de 
compreensão do código do programa. Esses mesmos exemplos 
também podem ser chamados de atributos não funcionais.
Resumidamente o software deve proporcionar ao usuário a 
funcionalidade e o desempenho requeridos e deve ser passível de 
manutenção, confiável, eficiente e de fácil uso (veja no quadro 1).
ATRIBUTOS Descrição
Facilidade 
de 
Manutenção
O software deve ser escrito de modo que possa 
evoluir para atender às necessidades mutáveis 
dos clientes. Esse é um atributo crucial, porque 
as modificações em um software são uma 
consequência inevitável de um ambiente de 
negócios em constante mutação.
Nível de 
Confiança
O nível de confiança do software tem uma gama 
de características que incluem confiabilidade, 
proteção e segurança. O software confiável não 
deve ocasionar danos físicos ou econômicos, 
no caso de um defeito no sistema.
Eficiência
O software não deve desperdiçar os recursos 
do sistema, como memória e ciclos do 
processador. A eficiência, portanto, inclui a 
rapidez de resposta, o tempo de processamento, 
a utilização da memória, entre outros.
www.esab.edu.br 18
Facilidade 
de Uso
O software deve ser utilizável, sem esforços 
indevidos, pelo tipo de usuário para quem foi 
projetado. Isso significa que ele deve dispor de 
uma interface apropriada com o usuário e de 
documentação adequada.
Quadro 1: Funcionalidade e o desempenho do software
Fonte: Próprio autor
Crise do Software e o início da Engenharia de Software
A crise do software, termo usado nos anos 70 (WIKIPÉDIA, 2016), 
referia-se às dificuldades do desenvolvimento de software da 
época. Por haver um rápido crescimento da demanda por software, 
imaginava-se que com toda a complexidade no desenvolvimento, 
haveria uma forte crise. Com a inexistência da Engenharia de 
Software nessa época, não havia técnicas estabelecidas para o 
desenvolvimento de sistemas que funcionassem adequadamente 
ou que pudessem ser validadas.
Figura 3: Crise do software
Fonte: PROGRAMMINGDUMPS (2017)
www.esab.edu.br 19
Figura 4: Inicio da Engenharia de Software
Fonte: Próprio autor
Já em 1988, Ambler afirmava: “Desenvolver software não é 
somente modelar e escrever código. É criar aplicações que 
resolvam os problemas dos usuários. É fazer isto dentro do prazo, 
de forma precisa e com alta qualidade” (AMBLER, 1988, p.5). 
Logo, com a crise de software, os desafios para a criação da 
disciplina de Engenharia de Software eram muito grandes.
Alguns dos típicos problemas que essa nova disciplina enfrentou 
foram:
1. identificar adequadamente os requisitos do Sistema, ou seja, 
saber o que o software deve fazer;
2. que ferramentas, linguagem, sistema operacional usar;
3. como diminuir os tempos e custos de desenvolvimento;
4. prever falhas antes da entrega final;
5. como fazer manutenção e controlar versões;
6. dificuldades de prever o progresso durante o desenvolvimento;
7. inexistência de histórico, ou documentação, no 
www.esab.edu.br 20
desenvolvimento de Sistemas;
8. comunicação com os usuários precária;
9. conceitos quantitativos inexistentes tais como confiabilidade,
qualidade e reusabilidade;
10. manutenção, no software existente, com difícil execução.
Esse início difícil da Engenharia de Software, com tantos desafios, 
gerou vários paradigmas e modelos de desenvolvimento (PETERS, 
2001).
Desafios da Engenharia de Software
Atualmente os principais desafios da Engenharia de Software, 
conforme Sommerville (2011), são:
DESAFIOS DESCRIÇÃO
O desafio do 
legado
Ainda os grandes sistemas de software 
existentes foram desenvolvidos no 
passado, e com importantes funções 
corporativas. O desafio é fazer a 
manutenção e atualização desses 
softwares à custos baixos e com qualidade.
O desafio da 
heterogeneidade
Os sistemas exigem em ambientes 
distribuídos por redes de diferentes tipos 
de computadores e sistemas de apoio. O 
desafio é desenvolver técnicas para 
construir softwares flexíveis para lidar com 
a heterogeneidade.
O desafio do 
fornecimento
Nos dias atuais existe uma demanda 
enorme de sistemas que sejam 
desenvolvidos no menor tempo possível e 
com facilidade de adaptação. O desafio é 
fornecer sistemas cada vez maiores e 
complexos com a qualidade desejada, e 
em curto espaço de tempo.
www.esab.edu.br 21
O desafio da 
entrega
As entregas com qualidade requerem 
tempo. No entanto, o ambiente de 
negócios de hoje deve apresentar resposta 
ágil e mudar rapidamente. O software de 
apoio deve acompanhar a velocidade da 
mudança. O desafio da entrega consiste 
em diminuir os tempos de entrega dos 
sistemas grandes e complexos, sem 
comprometer a sua qualidade.
O desafio da 
confiança
Como os softwares estão totalmente 
relacionado em nossas vidas, é essencial 
que possamos confiar nele. Isso é 
especialmente verdadeiro para sistema 
de acesso remoto, como uma página web 
ou interface web-service. O desafio da 
confiança é desenvolver técnicas que 
demonstrem que o software pode ter a 
confiança dos seus usuários
Quadro 2: Desafios da Engenharia de Software
Fonte: Próprio autor
Normalmente, esses desafios não são independentes. Para 
atender a esses desafios, necessitamos de ferramentas e técnicas 
novas, bem como formas inovadoras para combinar e usar 
métodos existentes de engenharia de software.
Responsabilidade profissional e ética
A engenharia de software está dentro de uma estrutura de 
condições legais e sociais que limita a liberdade dos engenheiros 
que, por sua vez, devem admitir que o seu trabalhoimplica 
responsabilidades mais amplas do que a aplicação de habilidades 
técnicas. Devem também se comportar de forma responsável 
ética e moralmente, para serem respeitados como profissionais.
Você deve sempre defender padrões normais de honestidade e 
integridade. Você não deve usar sua habilidade e sua capacidade 
www.esab.edu.br 22
para se comportar de maneira desonesta ou de modo que trará 
má reputação para a profissão de engenharia de software. No 
entanto segundo summerville (2011), existem áreas em que os 
padrões de um comportamento aceitável não estão limitados por 
leis, mas por uma tênue noção de responsabilidade profissional.
“Confidencialidade: você deve respeitar a 
confidencialidade de seus funcionários ou 
clientes, independentemente de ter ou não 
assinado um acordo formal;
Competência: você não deve desvirtuar seu nível 
de competência. Você não deve conscientemente 
aceitar um trabalho que deseja fora da sua 
competência;
Direitos sobre propriedade intelectual: você deve 
estar ciente das leis locais que regem o uso da 
propriedade intelectual tais como patentes e 
direitos autorais. Você deve tomar cuidado para 
assegurar que a propriedade intelectual de 
funcionários e cliente seja protegida;
Mau uso dos computadores: você não deve usar 
seuas habilidades técnicas para fazer mau uso 
dos computadores de outras pessoas. O mau 
uso de computadores varia deste o relativamente 
trivial (execução de jogos na máquina do 
funcionário, por exemplo) até o extremamente 
sério (disseminação de vírus)”(SUMMERVILLE, 
2011).
Sociedade e instituições profissionais têm um importante papel a 
desempenhar, definindo padrões de ética. Organizações tais como 
a ACM, a IEEE (Institute of Electrical and Eletronic Engineers) e 
Bristish Computer Society publicaram um código de conduta 
www.esab.edu.br 23
profissionais ou código de ética. Os membros dessas organizações 
se comprometem em seguir esse código de ética.
A ACM, a IEEE têm cooperado para produzir um código comum 
de ;ética e de prática profissional. Esse código existe no formato 
resumido, apresentado por Summerville (2011) no quadro ???
O quadro eu enviei por foto do livro do summerville. Precisa ser 
digitado e feito a citação.
Estudo Complementar
Para uma um melhor aproveitamento desta unidade 2, 
acesse o link abaixo:
http://pt.wikipedia.org/wiki/Crise_do_software
Para sua Reflexão
Reflita e se puder, responda com os seus próprios 
comentários a respeito:
1. quais são os atributos de um bom Software ?
2. quais são os desafios enfrentados pela Engenharia
de Software ?
www.esab.edu.br 24
Os Modelos de Processos de Software descrevem basicamente 
as principais etapas do desenvolvimento de software, desde da 
produção até a sua própria manutenção. 
Conforme cita Macoratti (2017): “Os modelos de processos de 
desenvolvimento de software surgiram pela necessidade de 
dar resposta às situações a analisar, porque só na altura em 
que enfrentamos o problema é que podemos escolher o 
modelo.”
Existem vários Modelos de Processos de Software, mas 
praticamente todos eles seguem o princípio das três principais 
macro etapas:
Requisitos
O analista deve obter respostas a várias perguntas junto aos 
usuários: O que exatamente se espera que seja feito? Qual a 
abrangência do software? Quais os limites, ou o escopo do 
sistema? Por que se faz aquilo daquela forma? Quais as restrições 
que existem nos procedimentos e dados utilizados? E muitas 
outras.
www.esab.edu.br 25
Projeto/Desenvolvimento
O analista faz especificações técnicas detalhando a solução criada 
para atender ao usuário conforme os requisitos anteriores. Os 
programadores codificam os programas em alguma linguagem de 
programação. Devem-se testar os programas exaustivamente 
para atingir um alto nível de qualidade, e após isso liberá-los para 
o uso.
Implantação/Manutenção
Na implantação do software podem ocorrer vários problemas não 
previstos nas fases anteriores. E a manutenção permanecerá 
durante toda sua vida útil e pode ocorrer motivada por 3 fatores:
1. a correção de algum problema existente no software;
2. sua adaptação decorrente de novas exigências (internas ou
externas da empresa);
3. algum melhoramento funcional que seja incorporado ao
software.
Figura 5: Implantação/Manutenção de software
Fonte: próprio autor.
www.esab.edu.br 26
Cabe ressaltar que não existe um consenso sobre o nome mais 
adequado para Modelos de Processos de Software. Os principais 
autores se referem a esse mesmo conceito com os seguintes 
nomes (figura 6):
Figura 6: Modelos de Processos de Software
Fonte: Próprio autor
Modelo Balbúrdia
Como falamos anteriormente, no início da computação, poucos 
programadores seguiam algum tipo de metodologia baseando-se, 
em sua maioria, na própria experiência. Era o que chamamos hoje 
de Modelo Balbúrdia, sistemas desenvolvidos na informalidade 
sem nenhum tipo de projeto ou documentação.
Nesse modelo, o software tende a entrar num ciclo de somente 
duas fases: o de implementação e de implantação. E os ajustes 
ao software para atender aos novos requisitos, sempre são em 
clima de urgência e de stress, motivados por vários fatores, e 
principalmente por pressão política.
www.esab.edu.br 27
Figura 7: Modelo balbúrdia
Fonte: Próprio autor
Portanto, havia a necessidade se criar um Ciclo de Vida mais 
inteligente para o desenvolvimento de Software. Ou seja, um 
Ciclo de Vida semelhante à própria natureza, com início, meio e 
fim bem definidos.
Modelo Cascata
Essa foi a proposta do Modelo Cascata (ou do inglês Waterfall), 
da década de 70 (LEITE, 2015.). Onde cada etapa do ciclo de vida 
pressupõe atividades que devem ser completadas antes do início 
da próxima etapa. Ou ainda, um modelo basicamente de atividades 
sistemáticas e sequenciais onde para cada etapa cumprida, 
segue-se a etapa imediatamente posterior, como se fosse uma 
cascata.
Não consigo
achar o relatório
www.esab.edu.br 28
O Modelo Cascata é extremamente clássico e 
antigo, por isso é também chamado de Ciclo de 
Vida Clássico. Originou-se dos velhos modelos 
de engenharia na elaboração de projetos. E na 
verdade, hoje em dia, é somente uma grande 
referência.
Vivemos num mundo de atividades paralelas, e 
esse modelo de atividades sequenciais, 
provocaria demoras excessivas, esperas 
indesejadas e problemas quando houvesse 
necessidade de voltar em etapas anteriores.
Figura 8: Modelo cascata (clássico e antigo)
Fonte: Pixabay (2012)
Repare nas figuras 9 e 10. Embora as duas refiram-se ao Modelo 
Cascata observe como a terminologia dessas imagens é distinta. 
Cada etapa praticamente tem um nome diferente em cada figura. 
Isso ocorre devido a não existir um padrão para esse modelo. 
Embora sendo clássico, para cada autor existe uma interpretação 
de cada etapa e é criado um nome distinto. 
www.esab.edu.br 29
Figura 9: Modelo cascata (A)
Fonte: Próprio autor
Figura 10: Modelo cascata (B)
Fonte: Próprio autor
www.esab.edu.br 30
O próprio Pressman (2016), outro papa da Engenharia de Software, 
na última edição do seu famoso livro de “Engenharia de Software”, 
alterou os nomes da quinta edição, colocando o nome dessas 
fases respectivamente de: Comunicação, Planejamento, 
Modelagem, Construção e Implantação.
Paradigmas do Desenvolvimento de Software - Modelo 
Incremental - Prototipação
Modelo Incremental
Como vimos anteriormente o tradicional Modelo Cascata é mais 
um modelo teórico do que prático. Na prática o usuário quer 
sempre o Sistema para ontem, e com qualidade. Para tanto, o 
Modelo Incremental parte do pressuposto que é preferível o 
usuário receber o Sistema em partes, permitindo que esses 
recursos já sejam utilizados, enquanto os demais estão sendo 
desenvolvidos.
O Modelo Incremental, ou interativo, é desenvolvido com o 
conceito de versões. Nesse modelo o sistema será especificado 
na documentação dos requisitos, e quebrado em subsistemas 
por funcionalidades. As versões são definidas, começando com 
um pequeno subsistema funcionale então adicionadas mais 
funcionalidades a cada versão. Pode-se então dizer que o Modelo 
Incremental chega lentamente à funcionalidade total, por meio 
dessas novas versões.
www.esab.edu.br 31
Figura 11: Modelo Incremental
Fonte: WIKIPEDIA (2017, tradução nossa)
Importante observar a diferença entre interativo e iterativo. As 
duas palavras embora com escrita extremamente parecidas, e 
muitas utilizadas em Informática, possuem significados distintos e 
é bom prestarmos a atenção, pois como ensina Jobs (2010): “Duas 
palavras muito comuns na área de TI, mas que constantemente 
são confundidas em seu significado e aplicação: iterativo e 
interativo.”
Quanto à palavra iterativo que significa, pelo próprio Aurélio 
(2004), “[...] diz-se de procedimento (como algoritmo, programa, 
etc.) que se baseia no uso ou aplicação da iteração”. Por sua vez 
iteração possui o significado de: “Processo de resolução (de uma 
equação, de um problema) mediante uma sequência finita de 
operações em que o objeto de cada uma é o resultado da que a 
precede” (AURÉLIO, 2004).
www.esab.edu.br 32
Ainda do próprio Aurélio (2004) podemos extrair a definição de 
interativo:
[...] de, ou relativo a sistemas ou procedimentos 
computacionais, programas, etc. em que o 
usuário pode (e, por vezes, necessita) 
continuamente intervir e controlar o curso das 
atividades do computador, fornecendo novas 
entradas (de dados ou comandos) à medida 
que observa os efeitos das anteriores. 
Portanto, no nosso caso específico utilizamos o processo 
interativo, e não iterativo.
Prototipação
A Prototipação tem o mesmo objetivo que uma maquete para um 
arquiteto (veja a figura 12). Antes da entrega final do sistema 
desenvolve-se rapidamente um esboço para melhorar o 
entendimento de desenvolvedores e clientes sobre todas as 
problemáticas das questões.
Figura 12: Criação de um protótipo de um veículo
Fonte: CREAFORM. (2017)
www.esab.edu.br 33
Foto 13: Modelo de prototipação
Fonte: JUBILEU (2016)
Dentro dessa visão, o projeto passa por várias investigações para 
garantir que o desenvolvedor, usuário e cliente cheguem a um 
consenso sobre o que é necessário e o que deve ser proposto. 
Como muitos usuários não possuem uma visão ampla sobre a 
Tecnologia, esse método de desenvolvimento é bastante 
interessante, permitindo que o usuário interaja significativamente 
no Sistema.
A prototipação é um processo que possibilita desenvolvedor e 
usuários a examinarem antecipadamente os requisitos. Com isso 
se reduzem os riscos e as incertezas do desenvolvimento.
Basicamente as etapas de desenvolvimento desse modelo são:
1. começar com um conjunto bem simples de requisitos fornecidos
pelos clientes e usuários;
2. clientes e usuários fazem testes e experimentações, e assim que
eles decidem o que querem, os requisitos são revisados, alterados,
detalhados, documentados e o sistema passa a ser codificado;
www.esab.edu.br 34
3. novamente as alternativas são apresentadas e discutidas
com os usuários, e voltamos para a etapa 2, até a entrega
definitiva do Sistema.
Logo, este modelo propicia duas grandes vantagens: velocidade 
de desenvolvimento no sentido de propiciar ao usuário uma visão 
mais real do software que se está projetando (o usuário poderá 
enxergar as telas e os relatórios resultantes do software) e o 
envolvimento direto do usuário na medida que o desenvolvimento 
do software evolui, o usuário passa a ser um coautor do 
desenvolvimento.
Pressman (2011) declara que a prototipação pode ser utilizada 
como um modelo de processo de software por si só. Mas, o 
mais comum é ser utilizada como uma ferramenta dentro de um 
outro modelo de processo de software.
Estudo Complementar
Veja estas informações através dos links abaixo que lhe 
ajudará no aprendizado:
http://pt.wikipedia.org/wiki/Processo_de_desenvolvimento_
de_software
http://pt.wikipedia.org/wiki/Modelo_em_cascata
http://www.macoratti.net/proc_sw1.htm
www.esab.edu.br 35
Modelo Espiral
Este modelo se confunde com o de Prototipagem. Mas, em 
princípio, é mais adequado para sistemas mais complexos, e que 
exigem um alto nível de interações com os usuários para possibilitar 
a abordagem de todos os problemas desse Sistema.
Foi criado por Barry W. Boehm, ainda em 1988 (BOEHM,1988, 
apud JUBILEU, 2016), e ao invés de representar o processo de 
software como uma sequência de atividades, a exemplo do Modelo 
Cascata, ele é representado através de uma espiral (veja a figura 
12).
Figura 12: Modelo espiral
Fonte: Fonte: JUBILEU (2016)
www.esab.edu.br 36
Cada ciclo da espiral representa uma fase do processo de 
software. Na parte mais interna relaciona-se o início da visão da 
viabilidade do sistema. E a cada ciclo, passando por várias etapas, 
vai evoluindo a visibilidade do sistema como um todo.
O Modelo Espiral basicamente é dividido em quatro setores:
SETORES Descrição
ATIVAÇÃO
Definem-se os objetivos específicos, identificam-se as restrições 
para o processo e é preparado um plano de gerenciamento 
detalhado. Identificam-se também os riscos sem analisá-los 
profundamente (foco da próxima fase).
ANÁLISE DE RISCOS
Com base nos riscos identificados na fase anterior, são realizadas 
análises detalhadas, e tomadas providências para amenizar esses 
riscos. Criam-se várias versões de protótipos para apoiar essa 
fase.
DESENVOLVIMENTO
Fundamentado pelas fases anteriores, escolhe-se o modelo mais 
adequado para o desenvolvimento do Sistema. A bagagem 
profissional e a vivência do desenvolvedor em outros sistemas 
são estratégicas para essa fase. Dependendo da complexidade 
do Sistema, às vezes, é necessária a presença de um consultor 
especialista.
PLANEJAMENTO
O projeto é revisto nessa fase, e é tomada uma decisão de realizar 
um novo ciclo na espiral ou não. Se continuar com o 
aperfeiçoamento do Sistema, é traçado um plano para a próxima 
fase do projeto.
Quadro 3: Divisão - Modelo espiral.
Fonte: Próprio autor.
Um diferencial nesse modelo comparado com outros, é a explícita 
consideração de riscos dentro do projeto como um todo. Para 
tanto, criou-se uma fase específica de Análise de Riscos nesse 
modelo.
Estude acerca do Modelo RAD acessando o artigo que se 
encontra no link abaixo:
https://www.treinaweb.com.br/blog/o-que-e-rad-rapid-application-
development/.
Modelo RUP
Outro modelo é o Processo Unificado Racional, RUP em inglês, 
que utiliza maciçamente do UML (Unified Modeling 
Language). Utilizando métodos e linguagens de programação 
orientada a objetos, aprimora o modelo RAD. A ênfase desse 
modelo é na arquitetura de software. 
https://www.treinaweb.com.br/blog/o-que-e-rad-rapid-application-development/
www.esab.edu.br 37
Saiba Mais
Veja o link abaixo e aprenda mais um pouco:
 http://pt.wikipedia.org/wiki/Modelo_em_espiral
Para sua Rflexão
Para você fazer uma revisão geral do que vimos nessas 
últimas unidades, leia e reflita sobre o texto que fala de 
Modelos de Ciclo de Vida:
http://pt.wikipedia.org/wiki/Modelos_ciclo_de_vida
http://pt.wikipedia.org/wiki/Modelo_em_espiral 
http://pt.wikipedia.org/wiki/Modelos_ciclo_de_vida 
www.esab.edu.br 38
A Engenharia de Software é uma tecnologia em camadas 
(PRESSMAN, 2011). Conforme a figura 13, podemos observar 
que todo o foco desta disciplina é na qualidade, que é a base de 
todas as camadas. O alicerce da Engenharia de Software, para 
tal, fica sendo no processo, aonde a partir daí temos os métodos 
a serem aplicados, e as ferramentas como apoio a todo esse 
esquema. O arcabouço deste conjunto é conhecido paradigma 
de Engenharia de Software.
Figura 13: Tecnologia em camadas (PRESSMAN 2011)
Fonte: Próprio autor
Processo
O Processo de Software é um conjunto de atividades, métodos, 
práticas e transformações ordenadas com a intenção de atingir a 
qualidade do software. 
www.esab.edu.br 39
Ainda, como ensina Humphrey (1989, p. 105): “Um processo é o 
conjunto total de atividades de engenharia necessárias para 
transformar requisitos do usuário em software.”
Sua meta fundamentalé entregar, de maneira eficiente e previsível 
um produto de software capaz de atender as necessidades de 
negócio, definidas pela análise de requisitos, dos usuários.
Pode-se também definir sucintamente como um conjunto completo 
de atividades necessárias para transformar os requisitos do 
usuário em um produto de qualidade de software. Um processo 
define quem está fazendo o que, quando e como para atingir 
esse objetivo.
Métodos
Método é uma palavra que vem do grego méthodos, que significa 
caminho para se chegar a um fim (ROCHA, 2017). O termo 
metodologia é bastante controverso nas ciências em geral e na 
Engenharia de Software em particular. Muitos autores parecem 
tratar metodologia e método como sinônimos, porém seria mais 
adequado dizer que uma metodologia envolve princípios filosóficos 
que guiam uma gama de métodos que utilizam ferramentas e 
práticas diferenciadas para realizar algo (ISUTIC, 2016).
As metodologias de Engenharia de Software objetivam ensinar 
como fazer para construir softwares. Esses métodos incluem 
atividades de modelagem, construção de programas, testes e 
manutenção. Na Engenharia de Software as principais abordagens 
de metodologias são:
www.esab.edu.br 40
1. Metodologia Estruturada: é a mais clássica das abordagens.
Utiliza como ferramental Dicionário de Dados, Diagrama de
Fluxo de Dados (DFD, figura 14), e o Modelo Entidade
Relacionamento (MER);
2. Metodologia Orientada a Objetos: O RUP, abreviação de
Rational Unified Process (ou Processo Unificado da Rational),
é um processo proprietário de Engenharia de software criado
pela Rational Software Corporation, adquirida pela IBM
(International Business Machines) tornando-se uma brand na
área de Software, fornecendo técnicas a serem seguidas
pelos membros da equipe de desenvolvimento de software
com o objetivo de aumentar a sua produtividade;
3. Metodologias de Desenvolvimento Ágil: Existem várias
metodologias que podem ser consideradas como abordagens
ágeis: XP, ASD, DSDM, Scrum, Crystal, FDD, AM entre outras.
Figura 14: Análise e Projeto de Sistemas
Fonte: Violin, (2015)
www.esab.edu.br 41
Figura 15: Fases do RUP
Fonte: Villela, (2014)
Figura 16: Metodologias de Desenvolvimento Ágil
Fonte: Web Master, (2013)
www.esab.edu.br 42
Ferramentas
Ferramenta é uma palavra que vem do latim ferramentum 
significando “[...] qualquer utensílio empregado nas artes e ofícios 
[...]” (AURÉLIO, 2004). As ferramentas de Engenharia de Software 
fornecem apoio automatizado, ou semi automatizado, para o 
processo e para os métodos.
Quando ferramentas são integradas de modo que a informação 
criada por uma ferramenta possa ser usada por outra, um sistema 
de apoio ao desenvolvimento de software, chamado de “[...] 
engenharia de software apoiada por computador” (CASE), é 
estabelecido (PRESSMAN, 2011, p. 9).
Características de um bom processo - Características de um 
bom ambiente de desenvolvimento
Processos de Engenharia de Software
Processo de software, ou processo de Engenharia de Software, 
é uma sequência coerente de práticas, que objetiva o 
desenvolvimento ou evolução de sistemas de software. Estas 
práticas englobam as atividades de especificação, projeto, 
implementação, testes e caracterizam-se pela interação de 
ferramentas, pessoas e métodos.
www.esab.edu.br 43
Figura 17: Processos de Engenharia de Software
Fonte: Próprio autor
As principais características de um bom processo são:
1. configurável para diferentes organizações;
2. adaptável para diferentes tamanhos e tipos de projetos;
3. bem definido, gerenciável e repetível;
4. com nomenclatura universal e métricas para planejamento e
gerenciamento do projeto;
5. integrado com ferramentas que o suportem.
Características de um bom ambiente de desenvolvimento
1. Processo de desenvolvimento definido.
2. Integração entre processo e ferramentas.
3. Integração entre ferramentas.
www.esab.edu.br 44
4. Gerenciamento de configuração.
5. Gerenciamento de mudanças.
6. Gerenciamento de projetos.
7. Automação de testes funcionais e de desempenho.
8. Documentação consistente.
9. E outros.
Figura 18: Ambiente de Desenvolvimento Organizacional
Fonte: Wikipédia, (2001)
Saiba Mais
Aperfeiçoe um pouco mais este estudo e acesse o link 
abaixo:
http://pt.wikipedia.org/wiki/Processo_de_desenvolvimento_
de_software
www.esab.edu.br 45
Estudo Complementar
Acesse o link abaixo que você estará enriquecendo o seu 
aprendizado sobre este módulo. 
http://pt.wikipedia.org/wiki/Engenharia_de_software#.
C3.81reas_de_Conhecimentohttp://pt.wikipedia.org/wiki/
Ferramenta_CASE
http://pt.wikipedia.org/wiki/Engenharia_de_software#.C3.81reas_de_Conhecimentohttp://pt.wikipedia.or
http://pt.wikipedia.org/wiki/Engenharia_de_software#.C3.81reas_de_Conhecimentohttp://pt.wikipedia.or
http://pt.wikipedia.org/wiki/Engenharia_de_software#.C3.81reas_de_Conhecimentohttp://pt.wikipedia.or
www.esab.edu.br 46
O objetivo do estudo sobre a Engenharia de Software tem a 
finalidade de demonstrar para o aluno um estudo sobre o 
desenvolvimento de softwares, suas diferenças, definições, 
atributos de software e principalmente contextualizar a Engenharia 
de Software. Portanto, ao discorrer sobre as cinco unidades desse 
eixo temático, buscou-se de forma sucinta alcançar os seguintes 
entendimentos sobre cada unidade e sua importância para a 
Engenharia de Software: unidade 1 - Qual a diferença entre 
Engenharia de Software e Engenharia de Sistemas? O que é um 
método de Engenharia de Software? Unidade 2 - Quais são os 
atributos de um bom Software? Quais são os desafios enfrentados 
pela Engenharia de Software? Unidade 3 – Modelos de Processos 
de Software - Paradigmas do desenvolvimento de Software - 
Modelo Balbúrdia - Modelo Cascata, unidade 4 - Paradigmas do 
desenvolvimento de Software - Modelo Espiral - Modelos mistos e 
características genéricas, unidade 5 - Paradigmas da Engenharia 
de Software: Processo, Métodos e Ferramentas.
www.esab.edu.br 47
PROCESSOS DE MODELAGEM DE SOFTWARE E ELICITAÇÃO DE REQUISITOS 
Processos de modelagem de software e elicitação de requisitos, 
faz parte de uma área desafiadora que se chama Engenharia de 
Requisitos. Trata-se de uma área restrita em termos de aquisição, 
estruturação e análise de informações o que, de uma certa forma, 
pode ocasionar duplo sentido. Assim, modelar problemas do 
mundo real para serem solucionados por sistemas de computação 
em geral, torna-se uma tarefa difícil. A Engenharia de Software 
tem por finalidade modelar problemas do mundo real, a fim de que 
sejam tratadas por sistemas computacionais por meio da elicitação 
de requisitos.
Objetivo
Apresentar os processos de modelagem de software e elicitação 
de requisitos, tais como: o RUP - Conceituar suas principais 
características e Modelos de Maturidade e a sua importância na 
Engenharia de Software. Identificar os vários tipos de requisitos 
de software, suas definições e técnicas. Conceituar os processos 
de engenharia de requisitos e a viabilidade técnica, bem como o 
processo de modelagem utilizando o UML. Abordar as várias 
metodologias ágeis e suas aplicações e apresentar as principais 
diretrizes para projetos e das interfaces com o usuário.
http://www.devmedia.com.br/curso/introducao-a-engenharia-de-requisitos/132
http://www.devmedia.com.br/curso/introducao-a-engenharia-de-requisitos/132
www.esab.edu.br 48
RUP (Rational Unified Process) usa a abordagem da orientação a 
objetos em sua concepção e é projetado e documentado utilizando 
a notação UML (Unified Modeling Language) para ilustrar os 
processos em ação. Utiliza técnicas e práticas aprovadas pelo 
mercado.
Atualmente o RUP é um produto desenvolvido e mantido pela 
Rational Software (Divisão IBM). Sistemas concebidos por esse 
processo normalmente são desenvolvidos um uma linguagem de 
programação orientada a objetos, como Java ou C++.
Figura 19: RUP (Rational Unified Process)
Fonte: Copyright IBM Corp.1987, 2006 
www.esab.edu.br 49
As principais características do RUP são:
1. desenvolvimentoInterativo;
2. gerência de requisitos;
3. uso de arquitetura baseada em componentes;
4. modelagem visual;
5. controle contínuo da qualidade;
6. gerência de mudanças.
A solução iterativa requer uma compreensão crescente do 
problema por meio de aperfeiçoamentos sucessivos e de 
desenvolvimento incremental em vários ciclos. (BOOCH; 
RUMBAUGH; JACOBSON, 2005).
Modelagem
A abstração do sistema de software através de modelos que o 
descrevem é um poderoso instrumento para o entendimento e 
comunicação do produto final que será desenvolvido. A maior 
dificuldade nesta atividade está no equilíbrio entre simplicidade 
(favorecendo a comunicação junto ao usuário) e a complexidade 
(favorecendo a precisão com detalhes) do modelo. É comum a 
utilização de linguagens para modelagem como UML.
Fases
Estruturar um projeto junto à dimensão de tempo envolve a adoção 
das seguintes fases baseadas em tempo (veja maiores detalhes 
no quadro 4 e figura 20):
www.esab.edu.br 50
FASES DESCRIÇÃO
Iniciação 
(Inception)
Estabelece a visão, o escopo e o plano 
inicial para o projeto.
Elaboração 
(Elaboration)
Projeta, implementa e testa a arquitetura 
do sistema e completa o plano do projeto.
Construção 
(Construction)
Desenvolve a primeira versão do sistema.
Transição 
(Transition)
Implantar o produto no ambiente de 
produção.
Quadro 4: Fases de estrutura de um projeto 
Fonte: Próprio autor
Figura 20: O modelo RUP 
Fonte: Ricardo Chaparro (2014)
http://slideplayer.com.br/user/84594/
www.esab.edu.br 51
Workflow de Processo
Estruturar um projeto junto à dimensão de componente de processo 
inclui as seguintes atividades:
ATIVIDADES DESCRIÇÃO
Modelagem do 
negócio
Descreve o negócio através de casos de uso 
de negócio.
Requisitos Narrativa da visão do sistema. Descrição das funções do sistema.
Análise e 
Projeto
Descrição de como o sistema será realizado 
na etapa de implementação.
Implementação Produção do código que resultará em um sistema executável.
Testes
Verificar a integração entre todos os 
componentes de software, identificar e 
corrigir erros de implementação.
Distribuição Gerar um release do produto. Entrega do produto e treinamento dos usuários.
Quadro 6: Workflow de processo
Fonte: Próprio autor
Workflow de Suporte
ATIVIDADES DESCRIÇÃO
Gestão de 
Projetos
Especifica um conjunto de princípios a 
aplicar na gestão de projetos no nível da 
alocação de recursos, planejamento, 
identificação e gestão de riscos, etc.
Gestão de 
Configuração e 
Mudança
Controla as mudanças e mantém a 
integridade dos artefatos do projeto.
Definição do 
Ambiente
Cobre a infraestrutura necessária para 
desenvolver um sistema (seleção de 
ferramentas, definição das regras de 
negócio, interface, testes, etc.)
Quadro 7: Workflow de suporte
Fonte: Próprio autor
www.esab.edu.br 52
Modelos de Maturidade – CMM (Capability Maturity Model)
O conceito de Modelo de Maturidade de Capacitação para 
Software, que é um metamodelo de processo, foi desenvolvido 
pela Carnegie Mellon University através do seu órgão SEI (Software 
Engineering Institute). O SEI é um centro de pesquisa e 
desenvolvimento criado, em 1984, pelo Departamento de Defesa 
dos Estados Unidos. Podemos definir Capacitação para Software 
como sendo a habilitação que a organização tem em 
sistematicamente produzir software possuindo a qualidade 
esperada, dentro dos prazos concordados e com os recursos 
alocados (MAGALHÃES et al. 2010).
Figura 21: Gráfico Benefit 2
Fonte: Argo Consultancy (2017)
Atente para a figura 21. Este gráfico representa que quanto maior 
a capacitação, menor será a variação dos erros de estimativa (de 
custos, prazos, etc.) em torno da média. Ou seja, enquanto no 
gráfico da esquerda as estimativas fogem muito da média, o da 
direita as variações em relação à média foram aprimoradas após 
a implantação do Capability Maturity Model - CMM (nível 5).
O CMM é o mais famoso representante desse conceito. Ele 
www.esab.edu.br 53
basicamente é uma metodologia de diagnóstico e avaliação da 
maturidade da capacitação em desenvolvimento de softwares numa 
organização (empresa ou instituição).
O objetivo maior do CMM é determinar em que estágio de maturidade 
uma empresa está em seu ciclo de desenvolvimento de software. 
Nasceu da necessidade do Departamento de Defesa americano 
em como avaliar as empresas terceirizadas que desenvolviam 
softwares para eles.
O uso de estratégia de melhoria de processos através de avaliação 
contínua, identificação de problemas e suas devidas ações corretivas 
permite estabelecer cinco níveis de maturidade. (Quadro 8).
CMMi (Capability Maturity Model Integration) é o modelo de 
maturidade surgido recentemente com o fim de unificar e agrupar 
as diferentes usabilidades do CMM e de outros modelos de 
processos de melhoria corporativo. Somente por curiosidade, raras 
são as empresas no mundo que conseguem atingir o nível 5. A 
grande maioria fica nos estágios iniciais. No Brasil, até o ano de 
2016, existiam 8 empresas que tinham alcançado o nível 5 do CMMi 
(CMMIINSTITUTE, 2017).
Estágios Descrição
Nível 1 – Inicial Caótico, estágio aonde que a maioria das empresas de software encontra-se.
Nível 2 – Repetitivo
Capacidade de repetir sucessos 
anteriores através do acompanhamento 
de custos, cronogramas e funcionalidades.
Nível 3 – Definido O processo de software é bem definido, documentado e padronizado.
Nível 4 – Gerenciado
Realiza uma gerência quantitativa e 
qualitativa do processo de software e do 
produto.
Nível 5 – Em 
Otimização
Usa a informação quantitativa para 
melhorar continuamente e gerenciar o 
processo de software.
Quadro 8: Nível 5 do CMMi
Fonte: Próprio autor
www.esab.edu.br 54
Para podermos visualizar melhor, de forma gráfica, todos os níveis 
de maturidade e a interação entre eles, podemos observar a figura 
22 a seguir:
Figura 22: Níveis de maturidade
Fonte: Próprio autor
Estudo Complementar
Leia adicionalmente o interessante artigo sobre a 
importância do UML nos dias atuais através do seguinte 
link:
http://www.linhadecodigo.com.br/artigo/76/buscando-novos-caminhos-por-
meio-da-uml.aspx
http://www.anacristinamelo.eti.br/artigos/Artigo_Buscando_Novos_Caminhos.pdf 
http://www.linhadecodigo.com.br/artigo/76/buscando-novos-caminhos-por-meio-da-uml.aspx
www.esab.edu.br 55
Saiba Mais
Para uma melhor compreensão sobre Gestão de Recursos 
Humanos, acesse o link abaixo:
http://pt.wikipedia.org/wiki/Rational_Unified_Processhttp://
pt.wikipedia.org/wiki/UML
http://pt.wikipedia.org/wiki/Rational_Unified_Processhttp://pt.wikipedia.org/wiki/UML 
http://pt.wikipedia.org/wiki/Rational_Unified_Processhttp://pt.wikipedia.org/wiki/UML 
www.esab.edu.br 56
É muito comum que o cliente não saiba o que ele realmente deseja, 
que haja problemas na comunicação e ainda que haja mudança 
constante desses requisitos. O termo requisito pode ser utilizado 
na indústria de software tanto com o significado de algo abstrato, 
como matematicamente formal. Para aprimorar esse conceito 
Alan M. Davis (1993) ilustra o seguinte case em seu livro “Software 
requirements - objects, functions and states”:
Se uma empresa deseja estabelecer com 
contrato para o desenvolvimento de um grande 
projeto de software (para selecionar entre vários 
fornecedores), ela tem de definir suas 
necessidades de maneira suficientemente 
abstrata para que uma solução não seja 
predefinida. Os requisitos devem ser redigidos 
de modo que os diversos fornecedores (de 
software) possam apresentar propostas, 
oferecendo, talvez, diferentes maneiras de 
atender às necessidades organizacionais do 
cliente. Uma vez estabelecido um contrato 
(entre as ambas as partes), o fornecedor (que 
ganhou) precisa preparar uma definição de 
sistema para o cliente, com mais detalhes, de 
modo que o cliente compreenda e possa validar 
o que o software fará. Esses dois documentos
podem ser chamados de documentos de
requisitos do sistema (DAVIS, 1993, s.n.).
As atividades de Análise de Requisitos concentram-se na 
identificação,especificação e descrição dos requisitos do sistema 
de software. Em resumo, requisito é uma necessidade que o 
software deve cumprir. Há várias interpretações e classificações 
sobre requisitos. Veja no quadro 9:
www.esab.edu.br 57
TIPOS DE 
REQUISITOS
DESCRIÇÃO
(Continua)
Requisitos do 
Usuário
São declarações, em linguagem natural e 
também em diagramas, sobre as funções 
que o sistema deve fornecer, e as restrições, 
sob as quais deve operar.
Requisitos de 
Sistema
(ou do 
desenvolvedor)
Estabelecem detalhadamente as funções e 
as restrições de sistema. O documento de 
requisitos de sistema, algumas vezes 
chamado de especificação funcional, deve 
ser preciso. Ele pode servir como um contrato 
entre o comprador do sistema e o 
desenvolvedor do software.
TIPOS DE 
REQUISITOS
DESCRIÇÃO
(Continuação)
Requisitos 
Funcionais
São declarações de funções que o sistema 
deve fornecer, como o sistema deve reagir a 
entradas específicas e como deve se 
comportar em determinadas situações. Em 
alguns casos, os requisitos funcionais podem, 
de forma explícita, declarar o que o sistema 
não deve fazer.
Requisitos não 
Funcionais
São restrições sobre os serviços ou as 
funções oferecidas pelo sistema. Entre eles 
destacam-se restrições sobre o processo de 
desenvolvimento, padrões, entre outros.
Quadro 9: Nível 5 do CMMi
Fonte: Próprio autor
Ressalta-se que essa classificação não é tão precisa, e até um 
pouco artificial. Ou seja, por exemplo, um requisito de usuário 
relacionado à proteção, aparenta ser um requisito não funcional. 
No entanto, ao detalharmos esse requisito ele pode assumir uma 
abrangência mais típica de um requisito funcional. Pois podemos 
necessitar de incluir recursos de autorização de usuários no 
sistema.
www.esab.edu.br 58
Figura 23: Tipos de requisitos não funcionais
Fonte: DEVMIDIA, 2017
Pela figura 23, podemos observar como os requisitos não funcionais 
são bastante abrangentes. Podem compreender desde requisitos 
éticos, como de desempenho ou mesmo de interoperabilidade.
Técnicas de Análise de Requisitos - O Documento de 
Requisitos de Software
1. Técnicas de Análise de Requisitos
Existem 10 princípios básicos, e engraçados, sugeridos por 
Pressman (2011), implementados por nós, no processo de 
levantamento de requisitos junto aos usuários numa reunião 
presencial:
Princípio nº 1: escute, escute e escute - Esta talvez seja a 
atitude mais importante na hora da captação dos requisitos de 
usuários. Se associado ao princípio 5, transforma-se num ponto 
estratégico para que o usuário/cliente perceba que você está 
querendo entender todos os seus problemas.
www.esab.edu.br 59
Princípio nº 2: prepare-se bem antes de se comunicar - Gere 
bastantes perguntas fundamentais à resolução e visão do negócio 
do usuário/cliente. Além de ser importante para essa atividade, 
todos gostam de responder questionamentos sinceros sobre as 
suas atividades.
Princípio nº 3: deve existir um facilitador na reunião - Não é 
interessante que o próprio analista seja o condutor dessa reunião. 
Existindo um personagem como facilitador na reunião, ameniza 
problemas de discussões ou maus entendidos. Seria praticamente 
um animador das discussões.
Princípio nº 4: foco da discussão num desenho ou documento, 
não nas pessoas - Se a discussão por ventura ficar pessoal, 
deve-se sempre voltar o foco da reunião para um desenho, 
documento ou mesmo sobre o processo envolvido. Isso abranda 
possíveis conflitos pessoais.
Figura 24: Foco da discussão num desenho 
Fonte: DEVMIDIA, 2017
www.esab.edu.br 60
Princípio nº 5: faça sempre anotações e documente as 
decisões - Por mais que não se queira a memória humana é fraca, 
muito fraca. Portanto, deve-se registrar o máximo das posições e 
informações dos usuários/clientes. Você irá se surpreender no 
futuro como anotou várias coisas que nem você não lembrava 
mais. E isso será muito importante nos conflitos que ocorrem ao 
longo do projeto.
Princípio nº 6: buscar ao máximo a colaboração de todos - 
Animosidades não ajudam a ninguém. O bom humor ajuda muito 
nessa fase de levantamento. Procurar ser agradável e simpático 
ameniza a grande maioria dos problemas pessoais. E por incrível 
que pareça, os problemas pessoais são os que mais atrapalham 
num projeto.
Princípio nº 7: conserve-se focado, departamentalize sua 
discussão - Discuta cada tema profundamente. Tente evitar 
questionar, ou discursar sobre vários temas simultaneamente. Vai 
eliminando a discussão tema a tema. A produtividade irá aumentar.
Princípio nº 8: se algo não estiver claro, sempre desenhe - 
Como o velho provérbio diz: “Uma imagem vale mil palavras” 
(CONFÚCIO, 551 a.C. - 479 a.C.). Não existe a necessidade de 
aplicar as técnicas de modelagem nessa hora, mas com desenhos 
simples, mapas mentais, transparências do PowerPoint, quadros 
e imagens ajudam muito nessa fase do projeto.
Princípio nº 9: (a) Se você concorda com algo, prossiga; (b) 
Se você não concordar com algo, prossiga; (c) Se algo não 
estiver claro, e sem condições de esclarecer naquele momento, 
prossiga - Há momentos que não adianta, como se diz no popular, 
“Dar murro em ponta de faca” (WIKCIONÁRIO, 2016). Prepare-se 
e aguarde o momento certo para voltar a tocar num tema polêmico. 
www.esab.edu.br 61
O uso da criatividade, na abordagem de um tema desse tipo, é 
super estratégico.
Princípio nº 10: negociar sempre no ganha-ganha - Existem 
várias posturas numa negociação entre dois personagens (perde-
perde, ganha-perde, perde-ganha e ganha-ganha). A melhor 
relação é o ganha-ganha. Essa é a postura dos vencedores. Ou 
seja, é conduzida a solução de conflitos de tal forma criativa e rica 
em oportunidades, que os dois lados ganham na negociação.
2. O Documento de Requisitos de Software
O Documento de Especificação de Requisitos de Software pode 
variar nos detalhes de empresa para empresa, mas normalmente 
possui os seguintes campos:
1. definição do contexto;
2. definição de requisitos: requisitos funcionais - requisitos de 
interface - requisitos não funcionais;
3. análise de risco;
4. anexos.
www.esab.edu.br 62
 
A Engenharia de Requisitos é um processo que envolve todas as 
atividades exigidas para criar e manter o Documento de Requisitos 
de Sistema (SOMMERVILLE, 2011). Na figura 25 podemos 
observar as quatro atividades genéricas de alto nível (caixas 
arredondadas): Estudo de Viabilidade, Obtenção e Análise de 
Requisitos, Especificação de Requisitos e Validação de Requisitos.
Segundo Rumbaugh, et al. (1994), alguns analistas consideram a 
Engenharia de Requisitos como um processo de aplicação de um 
método estruturado, como a análise orientada a objetos. No 
entanto, a Engenharia de Requisitos possui muito mais aspectos 
do que os que são abordados por esses métodos.
Figura 25: Processo de Engenharia de Requisitos 
Fonte: Sommerville (2011)
www.esab.edu.br 63
Estudos de Viabilidade
O primeiro processo a ser realizado num Sistema novo é o Estudo 
de Viabilidade. Os resultados deste processo devem ser um 
relatório com as recomendações da viabilidade técnica ou não da 
continuidade no desenvolvimento do Sistema proposto.
Basicamente, um estudo de viabilidade, embora seja normalmente 
rápido, deverá abordar fundamentalmente as seguintes questões:
1. O Sistema proposto contribui para os objetivos gerais da 
organização?
2. O Sistema poderá ser implementado com as tecnologias 
dominadas pela equipe dentro das restrições de custo e de 
prazo? Ou precisaria de treinamentos adicionais?
3. O Sistema pode ser integrado, e é compatível com os outros 
sistemas já em operação?
Modelagem – UML: Unified Modeling Language – Linguagem 
de Modelagem Unificada
O UML (Unified Modeling Language - Linguagem de Modelagem 
Unificada) é um padrão para a modelagem orientada a objetos. É 
uma linguagem de diagramação ou notação para especificar, 
visualizar e documentar modelos de sistemas de software 
Orientados a Objeto. O UML é controlado pela OMG (Object 
Management Group - OMG).www.esab.edu.br 64
Figura 26: UML Fonte: Wikipedia (2017)
Figura 27: OMG
Fonte: Print screen do http://www.uml.org/ (2017)
Veja, na figura 28, a árvore de diagramas do UML.
Figura 28: Árvore de diagramas do UML
Fonte: Próprio autor
www.esab.edu.br 65
Principais 
DIAGRAMAS Descrição
Diagrama de Caso 
de Uso
Mostra atores (pessoas ou outros usuários 
do sistema), casos de uso (os cenários 
onde eles usam o sistema), e seus 
relacionamentos.
Diagrama de 
Classe
Diagrama as classes e os relacionamentos 
entre elas.
Diagrama de 
Sequência
Mostra objetos e uma sequência das 
chamadas do método feitas para outros 
objetos.
Diagrama de 
Colaboração
Apresenta objetos e seus relacionamentos, 
colocando ênfase nos objetos que 
participam na troca de mensagens.
Diagrama de 
Estado
Exibe estados, mudanças de estado e 
eventos em um objeto ou em uma parte 
do sistema.
Diagrama de 
Atividade
Apresenta as atividades e as mudanças 
de uma atividade para outra com os 
eventos ocorridos em alguma parte do 
sistema.
Diagrama de 
Componente
Mostra os componentes de programação 
de alto nível (como KParts ou Java Beans).
Diagrama de 
Distribuição
Destaca as instâncias dos componentes e 
seus relacionamentos.
Quadro 10: Principais diagramas
Fonte: Próprio autor
Os use-cases são cada vez mais utilizados para a obtenção de 
requisitos, e são uma característica fundamental na notação UML. 
São técnicas baseadas em cenários para a obtenção de requisitos. 
No entendimento de Booch et al. (2005), o use-cases, por ser um 
conjunto de sequências e ações, também inclui variantes. Os use-
cases identificam os agentes envolvidos numa interação e o tipo 
dessa interação. Veja o exemplo na figura 29:
www.esab.edu.br 66
Figura 29: Use-cases
Fonte: Próprio autor
Diagramas de Sequência podem ser utilizados para acrescentar 
informações a um use-case. Esses diagramas mostram os agentes 
envolvidos na interação, os objetos dentro do sistema com os 
quais eles interagem, e as operações que estão associadas a 
esses objetos. A figura 30 ilustra isso:
www.esab.edu.br 67
Figura 30: Diagrama de Sequência
Fonte: Próprio autor
Estudo Complementar
Os textos no Wikipédia sobre o estudo desta Unidade são 
bastante interessantes. Acesse:
http://pt.wikipedia.org/wiki/UML
http://pt.wikipedia.org/wiki/Caso_de_usohttp://pt.wikipedia.
org/wiki/Casos_de_Uso
http://pt.wikipedia.org/wiki/UML 
http://pt.wikipedia.org/wiki/Caso_de_usohttp://pt.wikipedia.org/wiki/Casos_de_Uso
http://pt.wikipedia.org/wiki/Caso_de_usohttp://pt.wikipedia.org/wiki/Casos_de_Uso
www.esab.edu.br 68
Saiba Mais
Tenha a oportunidade de conhecer o site da OMG em:
 www.uml.org
http://www.uml.org 
www.esab.edu.br 69
 
Através do Manifesto for Agile Software Development (Manifesto 
para Desenvolvimento Ágil de Software) criado em 2001 por Kent 
Beck, e mais 16 notáveis desenvolvedores, se reuniram para 
defender as seguintes regras (BECK, 2001, apud PRESSMAN; 
MAXIM, 2016, p. 846): 
Estamos descobrindo maneiras melhores de 
desenvolver softwares fazendo-o nós 
mesmos e ajudando outros a fazê-lo. Através 
desse trabalho, passamos a valorizar: 
Indivíduos e interação entre eles mais que 
processos e ferramentas; Software em 
funcionamento mais que documentação 
abrangente; Colaboração com o cliente mais 
que negociação de contratos. Responder a 
mudanças mais que seguir um plano. Ou 
seja, mesmo havendo valor nos itens à direita, 
valorizamos mais os itens à esquerda.
Portanto, com base no Manifesto Ágil, chega-se aos seguintes 
princípios básicos:
1. simplicidade acima de tudo;
2. rápida adaptação incremental às mudanças;
3. desenvolvimento do software preza pela excelência técnica;
4. projetos de sucesso surgem através de indivíduos motivados, 
e com uma relação de confiança entre eles;
5. desenvolvedores cooperam constantemente e trabalham 
junto com os usuários/clientes;
6. atender o usuário/cliente, entregando rapidamente e 
continuamente produtos funcionais em curto espaço de tempo 
www.esab.edu.br 70
(normalmente a cada 2 semanas);
7. software funcionando é a principal medida de progresso;
8. mudanças no escopo, ou nos requisitos, do projeto não é
motivo de chateação;
9. a equipe de desenvolvimento se auto organiza, fazendo
ajustes constantes em melhorias.
Esse Manifesto ocorreu para ser um contraponto as Metodologias 
de Desenvolvimento Prescritivas. Ou seja, enquanto o RUP 
(visto na Unidade 6) é extremamente rígido com altos níveis de 
controle, e forte documentação, as metodologias ágeis caminham 
ao contrário. Destacamos que, mesmo assim, ela não inflige a 
uma sólida prática da Engenharia de Software.
Figura 31: Metodologias ágeis
Fonte: Próprio autor
Na figura 31 vemos num extremo o RUP enfatizando os controles, 
e uma política de trabalho rígida. Ele é mais interessante de ser 
utilizado com equipes grandes de desenvolvimento. Na outra 
ponta temos o Extreme Programming - XP, que veremos a seguir, 
sinalizando maior liberdade e mais adequada para equipes 
pequenas. E num ponto intermediário o Feature Driven 
Development - FDD, que também veremos no final desta unidade, 
como um modelo conciliador dessas duas estratégias.
www.esab.edu.br 71
Um dos pontos de destaque na Metodologia Ágil é a liberdade 
dada para as equipes de desenvolvimento. A declaração de Ken 
Schwaber (2004, p. 5) define isso da seguinte forma:
A equipe seleciona quanto trabalho acredita 
que pode realizar dentro da iteração, e a equipe 
se compromete com o trabalho. Nada desmotiva 
tanto uma equipe quanto alguém de fora assumir 
compromissos por ela. Nada motiva tanto uma 
equipe quanto a aceitação das responsabilidades 
de cumprir os compromissos que ela própria 
estabeleceu.
XP (Extreme Programming)
Existe uma grande ênfase ao trabalho em duplas, no qual um 
analista mais experiente trabalha com um novato. Enquanto o 
mais jovem trabalha na programação o mais antigo vai revisando 
o código. Dessa forma ao mesmo tempo desenvolve-se a equipe,
e melhora-se automaticamente a qualidade do código fonte
gerado.
Um Development Team - DT de um Scrum Team tem como 
característica ser auto organizável e multifuncional. Dessa forma, 
ele consegue decidir qual a melhor forma de se chegar às metas 
estabelecidas, sem precisar de um Gerente de projeto delegando 
responsabilidades ao logo do tempo. E por ser também 
multifuncional todos os integrantes de um DT devem ser capazes 
de desenvolver diversas atividades dentro do projeto, não sendo 
apropriado possuir profissionais que sejam apenas especialistas. 
Todos que fazem parte de um Development Team no Scrum 
recebem a classificação de desenvolvedores.
www.esab.edu.br 72
Figura 31: Equipe de Desenvolvimento
Fonte: Próprio autor
FDD – Feature Driven Development
O FDD (Desenvolvimento guiado por Características), concebido 
por Peter Coad (1980/1990), teve como premissa criar um modelo 
prático de processo para a Engenharia de Software orientado a 
objetos.
No entanto, Stephen Palmer e John Felsing (2002) aprimoraram o 
modelo descrevendo um processo ágil e adaptativo que pode ser 
aplicado a projetos de software tanto a projetos de médio como de 
grande porte.
www.esab.edu.br 73
Figura 32: Feature Driven Development
Fonte: (LEITE, 2016)
Dentro do contexto do FDD, o significado de característica vem a 
ser uma função, relativamente pequena, acertada com o cliente 
que pode ser implementada em menos de duas semanas, com os 
seguintes benefícios:
1. sendo as características pequenos blocos de funcionalidade,
os usuários e desenvolvedores têm melhor controle e
entendimento de todo o processo;
2. organizam-se as características em um agrupamento
hierárquico relacionado ao negócio, melhorando a visão para
o usuário. E para os desenvolvedores facilitando o
planejamento de todo o projeto.
3. a equipe tem metas de desenvolvimento dessas
características a cada duas semanas.
O FDD enfatiza mais as diretrizes e técnicas de gestão de projetos 
do que outros métodos ágeis. O projeto é muito bem acompanhado,www.esab.edu.br 74
ficando claro para todos os envolvidos os avanços e problemas 
que o Projeto vai sofrendo. Para tanto, o FDD define seis marcos 
de referência durante o projeto e implementação de uma 
característica:
1. travessia do projeto;
2. projeto;
3. inspeção do projeto;
4. código;
5. inspeção do código;
6. promoção para a construção.
Metodologias de Desenvolvimento Ágeis de Software: Scrum 
- Crystal - ASD e AM
Scrum
O significado peculiar desse modelo de desenvolvimento ágil vem 
do nome da atividade de jogadores de rugby ao trabalharem 
fortemente juntos para deslocar a bola pelo campo (COUTINHO, 
2011). Foi desenvolvida por Jeff Sutherland (2013, p. 13), ainda na 
década de 1990. Seus princípios básicos seguem o manifesto ágil.
Um ponto que se destaca nesse modelo são as Reuniões Scrum. 
Sugere-se que sejam realizadas diariamente por 15 minutos, mas 
com base em nossa realidade brasileira, acreditamos que o período 
ideal seria semanal, com uma duração de 1 hora (preferencialmente 
as sextas-feiras à tarde).
São somente três questões que são apresentadas para todos os 
envolvidos, e com excelentes resultados. Todos devem apresentar 
suas respostas com base nas seguintes perguntas:
www.esab.edu.br 75
1. O que você fez desde a última Reunião Scrum?
2. Que obstáculos você está encontrando que podemos ajudar?
3. O que você planeja realizar até a próxima Reunião Scrum?
Figura 33: Reuniões Scrum
Fonte: Próprio autor.
Crystal
Criado por Alistair Cockburn (2005) e Jim Highsmith (2004) com 
intuito de fazer uma analogia com os cristais geológicos que 
apresentam na natureza com a sua própria cor, forma e dureza. 
Destaca-se a manobrabilidade com o significado de um jogo 
cooperativo de invenção e comunicação de recursos limitados, 
com o principal objetivo de entregar softwares úteis funcionando e 
com o objetivo secundário de preparar-se para o jogo seguinte 
(PRESSMAN, 2011).
A família Crystal é, na verdade, um conjunto de processos ágeis 
que se mostraram efetivos para diferentes tipos de projeto. A 
intenção é permitir que equipes ágeis selecionem o membro da 
família Crystal mais apropriado para o seu projeto e ambiente.
www.esab.edu.br 76
ASD – Adaptative Software Development
O ASD (Desenvolvimento Adaptativo de Software) foi proposto 
por Jim Highsmith (2015), com o intuito de ser uma técnica para 
construção de sistemas e softwares complexos. O foco desse 
modelo é a colaboração humana e na auto-organização da equipe 
de desenvolvimento. O ciclo de vida de um ASD incorpora três 
fases, detalhadas no quadro 11:
FASES Descrição
Especulação
Planejamento do ciclo adaptativo usa 
informações de iniciação do projeto para definir 
o conjunto de ciclos de versão (incrementos de
software) que serão necessários para o projeto.
Colaboração
Os analistas precisam confiar um no outro para: 
criticar sem animosidade, ajudar sem 
ressentimentos, trabalhar mais do que estão 
acostumados, potencializar suas habilidades, e 
comunicar problemas de um modo que conduza 
à ação efetiva.
Aprendizado
A medida que os membros de uma equipe ASD 
começam a desenvolver os componentes que 
fazem parte de um ciclo adaptativo, a ênfase 
está tanto no aprendizado quanto no progresso 
em direção a um ciclo completo.
Quadro11: ciclo de vida de um ASD
Fonte: Próprio autor
www.esab.edu.br 77
AM – Agile Modeling
Conforme o site que se auto 
intitula The Official Agile 
Modeling - Scott W. Ambler 
(2017), seu criador, descreve a 
Modelagem Ágil (AM) como 
sendo (adaptado por nós):
A Modelagem Ágil (AM) é uma metodologia 
baseada na prática, para modelagem e 
documentação efetiva de sistemas baseados 
em software. Modelagem Ágil é uma coleção 
de valores, princípios e práticas de modelagem 
de software que podem ser aplicados a um 
projeto de desenvolvimento de software de 
modo efetivo e leve. Os modelos ágeis são mais 
efetivos do que os modelos tradicionais, porque 
eles são suficientemente bons, não precisando 
ser perfeitos!
Dos princípios mais importantes da Modelagem Ágil (AM), 
anunciados por Ambler (2017), destacamos os dois mais 
significativos:
Modelos Múltiplos: há muitos modelos e notações diferentes que 
podem ser usados para descrever softwares. Importante: apenas 
um pequeno subconjunto é essencial para a maioria dos projetos. 
A AM sugere que, para fornecer a visão necessária, cada modelo 
apresente um aspecto diferente desse sistema e que apenas 
aqueles modelos que ofereçam valor à sua pretensa audiência 
sejam usados.
Viajar Leve: essa expressão se refere aos turistas que para não 
ficar carregando pesadas malas, adotam esse princípio. No caso, 
para a AM, ela dita que à medida que o trabalho de Engenharia de 
www.esab.edu.br 78
Software prossegue, conserve apenas aqueles modelos que 
fornecerão valor em longo prazo e livre-se do resto.
Saiba Mais
Visite o site do MANIFESTO ÁGIL em:
http://www.agilemanifesto.org/
Estudo Complementar
Para aprender mais um pouco sobre o que estudamos, 
acesse os link’s abaixo:
http://pt.wikipedia.org/wiki/Desenvolvimento_%C3%A1gil_
de_software
http://www.heptagon.com.br/?q=scrum
http://www.agilemanifesto.org/
http://pt.wikipedia.org/wiki/Desenvolvimento_%C3%A1gil_de_software
http://pt.wikipedia.org/wiki/Desenvolvimento_%C3%A1gil_de_software
http://www.heptagon.com.br/?q=scrum 
www.esab.edu.br 79
O que é Projeto de Software? Podem-se pegar as interessantes 
palavras de Mitch Kapor (1996) para definir bem essa ação: “É 
onde você se instala com um pé em dois mundos – o mundo da 
tecnologia e o mundo das pessoas e objetivos humanos – e você 
tenta juntar os dois [...]” (KAPOR, 1996, p. 1-9). 
Portanto, é um lugar de criatividade aonde os requisitos do usuário/
cliente, as necessidades do negócio, e as considerações técnicas 
se juntam na formulação de um produto ou sistema. É o momento 
mágico aonde o engenheiro de software modela, cria e constrói a 
estrutura de toda as partes de um Sistema, antes dele mesmo 
existir. 
Projeto Modular
A Modularidade consiste na divisão do software em componentes 
nomeados separadamente e endereçáveis, muitas vezes 
chamados de módulos. Os mesmos são integrados para satisfazer 
aos requisitos do Sistema (adaptado de PRESSMAN 2011). Veja 
a figura 34, aonde são apresentados os vários módulos do ERP 
da SAP.
www.esab.edu.br 80
Figura 34: Vários módulos do ERP da SAP
Fonte: Próprio autor
Uma prática de Engenharia de Software condenável é a construção 
de softwares monolíticos. Ou seja, um software composto de um 
único e grande módulo. Isso gera uma complexidade global quanto 
ao número de caminhos de controle, intervalos de referência, 
número de variáveis, que faz um programa ter uma baixa 
compreensão para todos.
Outro problema é a manutenibilidade do Sistema (BLANCHARD, 
1992). Com poucas pessoas compreendendo o Sistema, mais 
difícil e custoso fica sendo a sua manutenção. Por outro lado, um 
software com excesso de módulos pode acarretar no mesmo erro. 
O bom senso novamente é a melhor resposta.
www.esab.edu.br 81
Projeto de interface com o usuário
Os computadores atuais fornecem uma interface chamada de GUI 
(Graphical User Interface - Interface Gráfica do Usuário), mas nem 
sempre foi assim. As primeiras versões eram 1D (uma única 
dimensão), aonde o usuário simplesmente alimentava um terminal 
que podia se deslocar para a direita e esquerda. Atualmente temos 
os de 2D (duas dimensões), graças ao mouse podemos deslocar 
o ponteiro por toda a tela. E como tendência temos já as interfaces 
3D (três dimensões). Um bom exemplo seria o Second Life.
Podemos ver no quadro 12, as diretrizes gerais para a elaboração 
de uma boa interface com o usuário:
DIRETRIZES Descrição
Familiaridade com 
o usuário
Deve utilizar termos e conceitos 
que tenham como base a 
experiência das pessoas que vão 
utilizar o sistema.
Consistência
Sempre que possível, operações 
semelhantes devem ser ativadas 
da mesma maneira.
Mínimo de surpresa
Os usuários nunca devem ser 
surpreendidos com o 
comportamentodo Sistema.
Facilidade de 
recuperação
A interface deve incluir mecanismos 
para permitir aos usuários a 
recuperação a partir de erros 
humanos.
Orientação do 
usuário
Na ocorrência de erros fornecer 
feedback significativo, e oferecer 
recursos sensíveis ao contexto de 
ajuda.
www.esab.edu.br 82
Diversidade de 
usuários
A interface deve fornecer recursos 
de interação apropriados a 
diferentes tipos de usuários do 
sistema.
Quadro 12: Diretrizes gerais para a elaboração de uma boa 
interface com o usuário
Fonte: Sommerville (2011)
Arquiteturas de Sistemas Distribuídos - Arquitetura de 
Multiprocessadores
Os sistemas com base em Mainframes, ou seja, computadores 
de grande porte, na prática são Sistemas Distribuídos. O conceito 
de Sistema Distribuído é a conexão de várias máquinas iguais, ou 
mesmo diferentes, para processar um ou mais sistemas.
Os três principais sistemas existentes atualmente são:
1. sistemas pessoais;
2. sistemas embutidos;
3. sistemas distribuídos.
Nos primeiros temos como exemplo os editores de texto e as 
planilhas eletrônicas. Um exemplo de Sistema embutido seria a 
ignição eletrônica, aonde num processador existe toda uma lógica 
de controle.
Veja no quadro 13 as mais importantes características dos 
Sistemas Distribuídos.
www.esab.edu.br 83
CARACTERÍSTICAS Descrição
Compartilhamento 
de Recursos
Compartilha recursos de hardware e de 
software gerenciados por computadores 
centrais, ou servidores.
Abertura
Pode-se facilmente incluir hardware e 
software de diferentes fabricantes.
Concorrência
Vários processos podem operar ao 
mesmo tempo em diferentes 
computadores na rede.
Escabilidade
Em princípio, pode-se aumentar 
infinitamente a capacidade dos Sistemas 
distribuídos, somente limitado pela 
capacidade de sua rede.
Tolerância a 
Defeitos
Com a estrutura dos Sistemas 
Distribuídos, há o potencial da duplicação 
de informações, evitando algumas falhas 
de hardware e software.
Transparência
Embora tendo complexidade alta, os 
usuários conseguem o que querem do 
Sistema, e sem a necessidade de se 
inteirar dessa complexidade.
Quadro 13: Características dos Sistemas Distribuídos
Fonte: Sommerville (2011)
Por outro lado, as principais desvantagens desse Sistema são:
1. alta Complexidade;
2. segurança baixa;
3. dificuldade de Gerenciamento;
4. imprevisibilidade nos tempos de resposta.
Veremos na próxima unidade os dois tipos de arquitetura de 
Sistemas Distribuídos mais importantes: a arquitetura 
www.esab.edu.br 84
cliente-servidor e a arquitetura de objetos distribuídos. De um 
modo geral os Sistemas Distribuídos são desenvolvidos com o 
uso da abordagem orientada a objetos.
Figura 35: Sistemas Distribuídos
Fonte: Próprio autor
Arquitetura de Multiprocessadores
O modelo mais simples de Sistema Distribuído é a Arquitetura de 
Multiprocessadores. Essa arquitetura, típica de sistemas em 
tempo real, consiste em uma série de diferentes processos que 
podem ser executados em processadores distintos.
Os Sistemas de software, compostos de vários processos, não 
são necessariamente sistemas distribuídos. Se mais de um 
processador estiver disponível, então a distribuição poderá ser 
implementada, mas os projetistas de sistema não precisam sempre 
www.esab.edu.br 85
considerar as questões de distribuição durante o processo de 
projeto. A abordagem de projeto para esse tipo de sistema é 
essencialmente aquela utilizada em sistemas de tempo real.
Estudo Complementar
Para complementar seus estudos acesse o site americano:
www.secondlife.com
http://www.secondlife.com
www.esab.edu.br 86
 
O objetivo do eixo temático sobre Processos de modelagem de 
software e elicitação de requisitos é apresentar uma visão geral 
de cada processo, fundamentando-se nos conceitos descritos 
pela Engenharia de Software. Para isso, buscou-se discorrer sobre 
as cinco unidades (6-10) desse eixo temático de forma a passar 
para os alunos uma melhor compreensão sobre os seguintes 
assuntos: Introdução ao RUP (Rational Unified Process) - 
Características - Fases e Workflows - Requisitos de Software - 
Requisitos Funcionais e não Funcionais - Requisitos de Usuário e 
de Sistema - Processos de Engenharia de Requisitos - Estudos de 
Viabilidade - Modelagem – UML - Metodologias de Desenvolvimento 
Ágeis de Software: XP – FDD – DSDM – Scrum – Crystal – ASD e 
AM - Engenharia de Projeto - Projeto Modular - Projeto de interface 
com o usuário. Desta forma, espera-se que o aluno tenha 
assimilado a aprendizagem adquirida e que tenha realizado as 
atividades propostas, bem como participado dos estudos 
complementares e alcançado o conhecimento proposto neste eixo 
temático.
www.esab.edu.br 87
 
ENGENHARIA DE SOFTWARE E GESTÃO DE PROJETOS
O termo Engenharia de Software vem do reconhecimento de que 
métodos formais e ferramentas e técnicas mais sofisticadas foram 
necessárias para enfrentar o desafio de: “[...] a construção de sistemas 
por grandes grupos de pessoas” (NAUR e RANDELL, 1969, p.23) 
especificamente sistemas em tempo real.
Um projeto é uma tarefa bem definida, é um conjunto de várias operações 
realizadas para atingir um objetivo (por exemplo, desenvolvimento de 
software e entrega). 
A Gestão de Projetos de software é executada por uma pessoa (Gerente 
de projetos) que assume a responsabilidade monitorando de perto o 
processo de desenvolvimento, além de preparar e executar vários 
planos, organizar recursos necessários e adequados, manter a 
comunicação entre todos os membros da equipe, a fim de abordar 
questões de custo, orçamento, recursos, tempo, qualidade e satisfação 
do cliente.
Objetivo
Proporcionar conhecimentos nos conceitos inerentes à Engenharia 
de Software e Gestão de Projetos, apresentando as características 
das principais arquiteturas, a Reengenharia de Software - Tradução 
de código fonte - Engenharia Reversa - Melhoria de estrutura de 
programa, Gerenciamento de Configuração - Gerenciamento de 
Mudanças - Gerenciamento de Versões e Releases, abordar os 
principais aspectos do gerenciamento de mudanças, acompanhar 
e identificar o desenvolvimento das diferentes versões e releases 
de um Sistema. Também chamado de versionamento e explorar o 
conceito da ferramenta CASE, Sistemas Legados - Estruturas dos 
Sistemas Legados - Avaliação dos Sistemas Legados, apresentar 
os princípios da gestão de projetos e a base do PMBOK, visualizar 
os elementos da qualidade e de teste de software e apresentar as 
diferenciações quanto ao desenvolvimento na WEB.
www.esab.edu.br 88
 
Pela definição de Orfali, Harkey e Edwards (1999), em uma 
arquitetura cliente-servidor (client/server), uma aplicação é 
modelada como um conjunto de serviços que são fornecidos por 
servidores e um conjunto de clientes que utilizam desses serviços. 
Veja na figura 36 a distribuição do modelo lógico de uma arquitetura 
cliente-servidor:
Figura 36: Arquitetura cliente-servidor
Fonte: Próprio auto.
Um projeto de sistema cliente-servidor deve refletir a estrutura 
lógica da aplicação que está sendo desenvolvida (SOMMERVILLE, 
2011). O tipo de arquitetura cliente-servidor mais utilizada em 
aplicações de baixa complexidade é a arquitetura cliente-
servidor de duas camadas. Nessa situação a aplicação reside em 
um ou mais servidores, e um conjunto de clientes usufruindo desse 
serviço.
www.esab.edu.br 89
Existem basicamente dois tipos: Thin clien, ou cliente magro, e 
Fat client (às vezes chamado de thick client), ou cliente gordo. No 
primeiro modelo todo o processamento é realizado no servidor. A 
segunda estrutura é mais complexa e mais comum. O servidor é 
responsável somente pelo gerenciamento de dados. E nos clientes 
é implementada a lógica da aplicação e as interações com o 
usuário do sistema.
Arquitetura de 3 camadas
A arquitetura de três camadas não necessariamente representa 
que existam três tipos de computadores conectados numa rede. É 
possível implementar esse modelo simplesmente com um servidor 
assumindo a camada de dados e a de negócio simultaneamente.Para visualizarmos melhor todos esses relacionamentos vejamos 
na figura 37.
Figura 37: Arquitetura de 3 camadas
Fonte: Próprio autor
www.esab.edu.br 90
Do lado direito temos um Database Server - Servidor de Banco de 
Dados fornecendo as solicitações do Web Server – Servidor Web 
(Camada de Dados). Do lado oposto, à esquerda, vemos os clients 
(clientes), na Camada de Apresentação, como interface com os 
usuários. E no meio, Camada de Negócio, o Web Server prove, 
através das regras de negócio, os serviços desejados ao conjunto 
de clientes.
Arquitetura de Objetos Distribuídos
A Arquitetura de Objetos Distribuídos é uma abordagem distinta 
da cliente/servidor onde elimina o conceito de distinguir quem é 
servidor ou mesmo cliente. Entretanto é criado um novo conceito 
chamado de middleware.
O middleware intermedeia os computadores a ele conectados. É 
também chamado de requisitor de objetos, e seu papel é fornecer 
uma interface contínua de comunicação entre esses objetos.
Os objetos no sistema podem ser implementados com o uso de 
diferentes linguagens de programação, podem ser executados em 
diferentes plataformas e seus nomes não precisam ser conhecidos 
por todos os outros objetos no sistema. Os dois padrões normais 
para o middleware são o CORBA - Common Object Request 
Broker Architecture, flexibilidade, por ser genérico, sistemas 
operacionais adotados e o acrônimo para o DCOM - Distributed 
Component Object Model.
www.esab.edu.br 91
Figura 38: CORBA
Fonte: Próprio autor
Figura 39: DCOM
Fonte: Próprio autor
Por todas as vantagens do padrão CORBA (flexibilidade, por ser 
genérico, sistemas operacionais adotados), organizado pelo OMG 
que é constituída por mais de 500 empresas, deva ser o padrão 
de fato que o mercado irá adotar.
Mudanças em Software - Dinâmica da Evolução de Programas 
- Evolução da Arquitetura Objetivo: Contextualizar os impactos 
das mudanças de software
Depois que os sistemas são entregues aos usuários/clientes, os 
softwares têm que sofrer mudanças para que possam responder 
às exigências das constantes mudanças impostas pelos mercados 
www.esab.edu.br 92
cada vez mais competitivos. Conforme Warren (WIKIPÉDIA, 
2017), existem diversas estratégias para essas mudanças.
ESTRATÉGIAS Descrição
Evolução da 
Arquitetura
Os sistemas normalmente evoluem de uma 
arquitetura mais centralizada, para uma 
arquitetura cliente/servidor (veremos a seguir 
nesta mesma Unidade).
Manutenção
Quando a estrutura fica estável, mas sofre 
modificações para adaptar a novos requisitos 
dos usuários (veremos mais detalhes na 
Unidade 27).
Reengenharia
Ao contrário da Manutenção, sofre alterações 
na estrutura, para que o sistema torne-se 
mais fácil sua compreensão e também para 
alterações (veremos mais detalhes na 
Unidade 22).
Quadro 14: Estratégias de mudanças de software
Fonte: Próprio autor.
Figura 40: Mudanças em Software
Fonte: Próprio autor
www.esab.edu.br 93
Dinâmica da Evolução de Programas
Vamos exemplificar a Dinâmica da Evolução de Programas 
pegando como exemplo o Microsoft Word. Ele começou operando 
como um simples processador de texto, ocupando 256Kb de 
memória. Hoje é um gigante com tantos recursos disponíveis que 
a grande maioria dos usuários pouco os utilizam.
Necessita atualmente de muitos megabytes de memória, e mais 
um processador ágil para que possa ser executado. A evolução 
desse software, na verdade, passou por várias fases. Alguns 
podem achar que trabalham somente com o mais novo release 
desse editor de texto.
No entanto, ele não é uma simples sequência de revisões, mas 
sim um software que sofreu várias mudanças na sua estrutura. 
Em certos momentos, ele passou não só por manutenções, mas 
também por reengenharias. E atualmente até evoluindo na sua 
arquitetura para ficar mais condizendo com o mundo da Internet.
Evolução da Arquitetura
Os principais sistemas antigos, ou mesmo os legados, foram 
desenvolvidos na concepção de arquiteturas centralizadas. Hoje, 
a tendência geral é do desenvolvimento de sistemas com 
arquiteturas distribuídas cliente/servidor.
Quando estamos alterando a arquitetura de um sistema já existente 
é interessante que tenhamos um modelo de camadas lógicas para 
nos orientar. A figura 41 representa as estruturas de um sistema 
divididas por camadas, facilitando a modularização para uma 
arquitetura distribuída.
www.esab.edu.br 94
Figura 41: Estruturas de um sistema divididas por camadas
Fonte: Próprio autor
A Evolução da Arquitetura envolve modificar a arquitetura de um 
sistema, a partir de uma arquitetura centralizada, centrada em 
dados, para uma arquitetura distribuída. Tanto a interface com o 
usuário quanto a funcionalidade do sistema podem ser distribuídas.
Uma estratégia comum da Evolução da Arquitetura, para sistemas 
legados em especial, é encapsular o sistema legado como um 
servidor. E implementa-se uma interface com o usuário distribuída, 
que acesse a funcionalidade do sistema (por meio de um 
middleware de propósito especial).
www.esab.edu.br 95
Figura 42: Middleware de propósito especial
Fonte: Próprio autor
Saiba Mais
Para uma melhor compreensão sobre Gestão de Recursos 
Humanos, acesse o link abaixo:
http://pt.wikipedia.org/wiki/Cliente-servidor
http://pt.wikipedia.org/wiki/Modelo_em_tr%C3%AAs_
camadas
http://pt.wikipedia.org/wiki/Corba
Estudo Complementar
Acesse o link abaixo e acrescente um pouco mais de 
conhecimento sobre o estudo desta unidade:
www.twiki.dcc.ufba.br/pub/Residencia/MaterialModuloTI1/
slides_aula04arquiteturadesoftware.pdf
http://pt.wikipedia.org/wiki/Cliente-servidor
http://pt.wikipedia.org/wiki/Modelo_em_tr%C3%AAs_camadas 
http://pt.wikipedia.org/wiki/Modelo_em_tr%C3%AAs_camadas 
http://pt.wikipedia.org/wiki/Corba 
http://www.twiki.dcc.ufba.br/pub/Residencia/MaterialModuloTI1/slides_aula04arquiteturadesoftware.pdf 
http://www.twiki.dcc.ufba.br/pub/Residencia/MaterialModuloTI1/slides_aula04arquiteturadesoftware.pdf 
www.esab.edu.br 96
 
A principal diferença entre Reengenharia de Software e o 
desenvolvimento de um novo Sistema é de onde que se parte 
esse próprio desenvolvimento. Num Sistema novo inicia-se com 
uma especificação escrita (os requisitos) dos usuários/clientes. 
Enquanto que, numa reengenharia, o sistema existente 
(normalmente um Sistema Legado) é que é a base para esse 
início.
Chikofsky e Cross II (1990, p. 13-17) chegam até definir o 
desenvolvimento tradicional como “Engenharia Direta”, para 
distinguir da Reengenharia de Software.
Pode-se perceber, na figura 43, a complexidade do processo de 
Reengenharia de Software. Embora, nem toda reengenharia 
passe por todos esses processos, essencialmente o programa é 
reestruturado. Vejamos mais detalhadamente o que cada processo 
realiza (caixas arredondadas).
Figura 43: Complexidade do processo de Reengenharia de 
Software
Fonte: Próprio autor
www.esab.edu.br 97
Processo de Reengenharia conforme a visão de Sommerville 
(2011)
PROCESSOS Descrição
Tradução de 
código-fonte
O programa é convertido da linguagem de 
programação original para uma versão mais 
moderna ou mesmo para uma nova linguagem 
mais adequada.
Engenharia 
Reversa
O programa é analisado conforme essas 
técnicas e as informações são extraídas dele, 
a fim de ajudar a documentar sua organização 
e funcionalidade.
Melhoria de 
estrutura do 
programa
A estrutura de controle do programa é 
analisada e modificada, a fim de torná-la mais 
fácil de ser lida e compreendida. Visa-se a 
manutenabilidade do sistema.
Modularização
de programa
Partes em comum do programa são agrupadas 
e, quando apropriado, a redundância é 
removida. Em alguns casos, esse estágio 
pode envolver a transformação da arquitetura.
Reengenharia
de dados
Os dados processados pelo programa são 
modificados, a fim de refletir as mudanças 
feitas nele. Ou mesmo adota-se uma nova 
estrutura de Banco de Dados.
Quadro 15: Processo de Reengenharia
Fonte: Próprio autor
Reengenharia de Dados e suas abordagens
A necessidade de analisar, reorganizara estrutura dos dados, e 
mesmo os valores contidos num Sistema é chamada de 
Reengenharia de Dados. Vejamos no quadro 16, as possíveis 
abordagens visualizadas por Sommerville (2011).
www.esab.edu.br 98
ABORDAGENS Descrição
Limpeza
de dados
Os registros e valores de dados são 
analisados, a fim de melhorar sua qualidade. 
As duplicações são removidas, as 
informações redundantes são excluídas e 
um formato consistente é aplicado a todos 
os registros. Normalmente, isso não deve 
requerer quaisquer mudanças nos 
programas associados.
Extensão
de dados
Nesse caso, os dados e programas 
associados passam pelo processo de 
reengenharia, a fim de eliminar os limites 
no processamento de dados. Isso pode 
exigir mudanças no programa para 
aumentar a extensão de campos, modificar 
limites superiores nas tabelas e assim por 
diante. Os dados em si podem precisar ser 
reescritos e limpos, para que reflitam as 
mudanças no programa.
Migração
de dados
Nesse caso, ocorre a migração dos dados 
para o controle de um Sistema de 
Gerenciamento de Banco de Dados. Os 
dados podem ser armazenados em arquivos 
separados ou serem gerenciados por um 
tipo de sistema de gerenciamento de Banco 
de Dados antigo. Essa situação é ilustrada 
na figura abaixo.
Quadro 16: Reengenharia de Dados
Fonte: Próprio auto.
www.esab.edu.br 99
Figura 44: Reengenharia de Dados
Fonte: Próprio autor
Para sua reflexão
Realize uma pesquisa na Internet sobre esse importante 
tópico. Procure em inglês (“Data reengineering”) para 
encontrar mais material a respeito.
 
 
http://pt.wikipedia.org/wiki/Corba 
www.esab.edu.br 100
Estudo Complementar
Aprenda mais um pouco, acesse os link’s:
http://pt.wikipedia.org/wiki/Reengenharia
http://pt.wikipedia.org/wiki/Reengenharia_de_Processos
Saiba Mais
Visite o site abaixo e saiba mais sobre Strategies for Data 
Reengineering
http://www.info.fundp.ac.be/~dbm/publication/2003/FNRS-
ReEngineering.pdf
http://pt.wikipedia.org/wiki/Reengenharia
http://pt.wikipedia.org/wiki/Reengenharia_de_Processos 
http://www.info.fundp.ac.be/~dbm/publication/2003/FNRS-ReEngineering.pdf 
http://www.info.fundp.ac.be/~dbm/publication/2003/FNRS-ReEngineering.pdf 
www.esab.edu.br 101
 
Gerenciamento de Configuração
É o desenvolvimento e a aplicação de padrões e procedimentos 
para gerenciar um Sistema em desenvolvimento. Esses 
procedimentos definem como registrar e processar as mudanças 
do Sistema, como relacioná-los aos seus componentes e os 
métodos utilizados para identificar as diferentes versões desse 
Sistema (adaptado de SOMMERVILLE, 2011).
As quatro atividades principais do Gerenciamento de 
Configuração são:
ATIVIDADES Descrição
Planejamento 
do 
Gerenciamento 
de 
Configuração
Descreve os padrões e os procedimentos 
que devem ser utilizados para o 
Gerenciamento de Configuração.
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 e econômica.
Gerenciamento 
de Versões e 
Releases
Consiste em acompanhar e identificar o 
desenvolvimento das diferentes versões e 
releases de um Sistema.
Construção de 
Sistemas
Processo de compilar e ligar componentes 
de software em um programa que é 
executado em uma configuração-alvo 
específica.
Quadro 17: Gerenciamento de Configuração
Fonte: Próprio autor.
www.esab.edu.br 102
 
Gerenciamento de Mudanças
Durante os testes de sistemas, ou ainda depois da entrega do 
software ao cliente, devem sofrer os procedimentos de 
Gerenciamento de Mudanças. O primeiro passo desse processo 
é a utilização de um formulário intitulado de Requisição de 
Mudança (CRF – change request form).
O formulário CRF deverá conter informações do tipo: registro da 
solicitação da mudança, recomendações, custos, datas de 
solicitação, aprovação, implementação e validação da mudança. 
É aconselhável também existir um espaço para um esboço 
especificando como a mudança deverá ser implementada. Um 
exemplo do formulário CRF é mostrado na figura 45:
www.esab.edu.br 103
Figura 45: Formulário CRF
Fonte: Próprio autor.
Gerenciamento de Versões e Releases
O release de um sistema é uma versão que é distribuída para os 
clientes (SOMMERVILLE, 2011). Logo, sempre existem mais 
versões de um sistema do que releases, pois existem muitas 
versões criadas para testes, ou desenvolvimento interno e não 
são liberadas para os clientes. 
www.esab.edu.br 104
Figura 46: Release
Fonte: Próprio autor.
www.esab.edu.br 105
Para a devida identificação de componentes existem três técnicas 
básicas:
TÉCNICAS BÁSICAS Descrição
Numeração de 
versões
Esse é o esquema de identificação 
mais comum. Atribui-se um número, 
explícito e único, de versão ao 
componente (ver figura)
Identificação 
baseada em 
atributos
Cada componente recebe um nome e 
um conjunto de atributos (que não é 
único em todas as versões).
Identificação 
orientada a 
mudanças
Além do anterior é associado uma ou 
mais solicitações de mudança.
Quadro 18: Técnicas Básicas
Fonte: Próprio autor.
Construção de Sistemas - Ferramenta CASE
Construção de Sistemas
Na construção de um Sistema, a partir dos seus componentes, 
devem-se questionar os seguintes pontos:
1. Todos os componentes foram incluídos nas instruções de 
construção?
2. A versão de cada componente requerido foi incluída nas 
instruções de construção?
3. Todos componentes requeridos estão disponíveis?
4. Os arquivos de dados do componente utilizado são iguais ao 
da máquina-alvo?
5. A versão do compilador e outras ferramentas estão 
disponíveis?
www.esab.edu.br 106
Figura 47: Construção de Sistema
Fonte: Próprio autor.
Ferramenta CASE
Uma ferramenta CASE (Computer-Aided Software Engineering) 
significa Engenharia de Software com o auxílio de computador. 
Ela possibilita apoiar as atividades de processo do software, como: 
a análise de requisitos, a modelagem de sistema, a depuração e 
os testes. Ferramentas CASE são constituídas com uma ampla 
gama de diferentes tipos de programas.
As ferramentas CASE podem também incluir um gerador de 
códigos que, automaticamente, origina o código-fonte a partir da 
modelagem do Sistema. Adicionalmente pode ter alguma 
orientação de processo, ao fornecer conselhos ao engenheiro de 
software sobre o que fazer em seguida.
Uma diferenciação que pode existir nas ferramentas CASE é a 
denominação Upper-CASE e Lower-CASE. As primeiras têm como 
www.esab.edu.br 107
utilidade de dar apoio à análise e ao projeto, ou seja, apoiar as 
fases iniciais do processo de software. As ferramentas Lower-
CASE, por outro lado, são projetadas para dar apoio à 
implementação e aos testes, como depuradores, sistemas de 
análise de programa, geradores de casos de testes e editores de 
programas.
Na figura 48 damos um destaque para telas da ferramenta CASE 
como o Rational Rose da IBM.
Figura 48: Telas da ferramenta CASE como o Rational Rose da 
IBM
Fonte: Próprio autor.
www.esab.edu.br 108
Estudo Complementar
Aprenda mais um pouco, acesse os link’s:
Wikipédia
http://pt.wikipedia.org/wiki/Ger%C3%AAncia_de_
Configura%C3%A7%C3%A3o_de_Software
http://pt.wikipedia.org/wiki/Sistema_de_controle_de_
vers%C3%A3o
Site da PRONUS sobre a “Gerência de Configuração”:
http://www.pronus.eng.br/artigos_tutoriais/gerencia_
configuracao/gerencia_configuracao.php?pagNum=0
http://pt.wikipedia.org/wiki/Ger%C3%AAncia_de_Configura%C3%A7%C3%A3o_de_Software
http://pt.wikipedia.org/wiki/Ger%C3%AAncia_de_Configura%C3%A7%C3%A3o_de_Software
http://pt.wikipedia.org/wiki/Sistema_de_controle_de_vers%C3%A3o 
http://pt.wikipedia.org/wiki/Sistema_de_controle_de_vers%C3%A3o 
http://www.pronus.eng.br/artigos_tutoriais/gerencia_configuracao/gerencia_configuracao.php?pagNum=0 
http://www.pronus.eng.br/artigos_tutoriais/gerencia_configuracao/gerencia_configuracao.php?pagNum=0 
www.esab.edu.br 109
 
As empresas continuamente evoluem em seus Sistemas, 
adaptando-os a sua realidade, e as constantes mudanças do 
mercado. No entanto, descartarSistemas mais antigos, os legados, 
e puramente substituí-los por softwares mais modernos envolve 
riscos empresariais significativos.
Podemos dar um simples exemplo atual. Imagine, de repente, 
mudarmos todos os Sistemas Operacionais Windows XP, de uma 
grande empresa, para o novo Windows Vista, ou mesmo para 
um Linux. A quantidade de problemas e adaptações necessárias, 
será tão grande, que poderia chegar a paralisar essa empresa.
Empresas com grande número de Sistemas Legados enfrentam 
dilemas fundamentais. Se continuarem com os sistemas velhos, 
os custos de adaptação aumentam. E se substituírem por novos, 
terão um custo inicial alto, e com a possibilidade de não atenderem 
as expectativas. Exige-se estar ciente das técnicas de Engenharia 
de Software para resolver esses problemas.
Estruturas dos Sistemas Legados
Pode-se dividir um Sistema Legado, do ponto vista didático, em 
seis partes lógicas: Hardware do Sistema, Software de Apoio, 
Software de Aplicação, Dados de Aplicação, Processos de 
Negócios e Políticas e Regras de Negócios. Mas, veremos a 
seguir, que na prática, pode-se dividir um Sistema Legado de 
forma mais simplificada.
www.esab.edu.br 110
Ao observarmos atentamente a figura 49, veremos as estruturas 
ideais e as reais de um Sistema Legado. O ideal seria termos a 
estrutura da esquerda, para numa possível migração termos cada 
componente claramente separado. No entanto, na grande maioria 
das vezes, encontramos a estrutura da direita.
Figura 49: Sistema Legado
Fonte: Próprio autor.
Os serviços sobrepõem interagindo com outros componentes do 
Sistema. A interface com o usuário e o código do serviço está 
integrada nos mesmos componentes, e pode não haver uma nítida 
distinção entre os serviços e o Banco de Dados do Sistema. 
Nesses casos, pode não ser possível identificar as partes do 
Sistema que podem ser distribuídas (SOMMERVILLE, 2011).
www.esab.edu.br 111
Avaliação dos Sistemas Legados
Figura 50: Avaliação dos Sistemas Legados
Fonte: Próprio autor.
Podemos, através da figura 50, caracterizar tipicamente as ações 
que devemos tomar quanto aos Sistemas Legados. Enquanto 
num eixo mensuramos a importância que um Sistema Legado tem 
para o negócio da empresa, no outro quantificamos a sua respectiva 
qualidade. Vamos, a seguir, tabular essas ações a serem tomadas.
www.esab.edu.br 112
Valor X 
Qualidade Descrição
Alto Valor de 
Negócios
X
Baixa Qualidade
São sistemas com importante contribuição 
à empresa e não devem ser descartados. 
Contudo, pela sua baixa qualidade, os 
custos operacionais são altos, de modo 
que são fortes candidatos à reengenharia 
ou à substituição total do sistema.
Baixo Valor de 
Negócios
X
Baixa Qualidade
Manter sistemas desse tipo em operação 
é dispendioso, e a taxa de retorno de 
investimento para os negócios é bastante 
pequena. Esses sistemas são fortes 
candidatos a receberem nenhum 
investimento, e mesmo a serem 
descartados.
Alto Valor de 
Negócios
X
Alta Qualidade
Sistemas com essas características 
devem ser mantidos em operação pela 
sua importância. E pela sua alta qualidade 
significa que não é necessário investir na 
sua transformação ou substituição. 
Portanto, devem continuar a manutenção 
normal no sistema.
Baixo Valor de 
Negócios
X
Alta Qualidade
São sistemas que não contribuem muito 
para os negócios, mas por outro lado, a 
manutenção não é muito dispendiosa. Não 
vale o risco de substituir esses sistemas, 
de modo que a manutenção normal pode 
ser continuada ou eles podem ser 
descartados.
Quadro 19: Tabulação dos Sistemas Legados
Fonte: Próprio autor, adaptado de Sommerville (2011).
Manutenção: fundamentos da fase de Manutenção de 
Software, tipos de Manutenção, procedimentos, técnicas e 
ferramentas
As leis de Lehman (1985) 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 de software para 
chegar nessas leis. Duas delas que destacamos são a da:
www.esab.edu.br 113
1. Mudança Contínua: 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;
2. 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.
Tipos de Manutenção
A manutenção será necessária durante toda o Ciclo de Vida útil, e 
pode ocorrer motivada por três tipos fundamentais:
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.
Quadro 20: Tipos de manutenção
Fonte: Próprio autor, adaptado de Sommerville (2011)
www.esab.edu.br 114
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 
são verificados o custo e o impacto das mudanças sugeridas. Com 
as mudanças aprovadas, um novo release do sistema é planejado.
Figura 51: Procedimentos de Manutenção
Fonte: Próprio autor.
Repare atentamente na figura 51. Veja que uma vez bem 
estruturado um sistema, no caso o System 1, que embora tenha 
despendido maiores custos de desenvolvimento, exigiu no período 
de manutenção menos tempo e recursos. Ou seja, o System 2 foi 
desenvolvido mais rapidamente, mas por não investir, ou visualizar, 
nos processos de manutenção, ao chegar nessa fase, despende 
maior tempo e custos.
Interessante observar que a manutenção segue o mesmo modelo 
do processo de desenvolvimento de sistema. Na figura 52 vemos 
que a representação das etapas que a manutenção que está 
sendo realizada, segue o Modelo Espiral.
www.esab.edu.br 115
Figura 52: Procedimentos de Manutenção modelo espiral
Fonte: Próprio autor.
Existem equipes de manutenção que atuam somente em corretivas, 
ou seja, somente quando existir um pedido dos usuários é que se 
atua no problema. No entanto, a melhor estratégia é a Manutenção 
Preventiva na qual se detecta previamente onde estão ocorrendo 
um maior número de corretivas, e destaca-se uma força-tarefa 
para realizar uma reengenharia nesses processos.
Na figura 53, veja as principais perguntas a serem feitas no 
Processo de Manutenção:
www.esab.edu.br 116
Figura 53: Principais perguntas a serem feitas no Processo de 
ManutençãoFonte: Próprio autor.
Estudo Complementar
Como sugestão, leia este artigo no link que segue abaixo: 
“Uma Proposta de Evolução em Sistemas Legados”:
http://wer.inf.puc-rio.br/WERpapers/artigos/artigos_
WER04/Luciana_Paiva.pdf
http://wer.inf.puc-rio.br/WERpapers/artigos/artigos_WER04/Luciana_Paiva.pdf 
http://wer.inf.puc-rio.br/WERpapers/artigos/artigos_WER04/Luciana_Paiva.pdf 
www.esab.edu.br 117
Gestão de Projetos de Software
A Gerência de Projetos se preocupa em entregar o sistema de 
software no prazo e de acordo com os requisitos estabelecidos, 
levando em conta sempre as limitações de orçamento e tempo.
A Gestão de Projetos de Software se caracteriza por tratar sobre 
um produto intangível, muito flexível e com processo de 
desenvolvimento com baixa padronização. Ou seja, não trata de 
processos rotineiros ou de prévio conhecimento.A gestão efetiva de projetos de software focaliza os quatros P’s: (P)
essoal, (P)roduto, (P)rocesso e (P)rojeto (PRESSMAN, 2011). 
Quanto ao PESSOAL existe até um padrão equivalente ao CMM, 
estudado anteriormente, intitulado de PM-CMM. Um dos pontos 
importantes do produto é a determinação adequada dos objetivos 
e o escopo do projeto. No processo é estabelecido o ferramental 
para apoiar um plano abrangente de desenvolvimento de software. 
E finalmente no projeto as diretrizes do PMBOK (que veremos a 
seguir) auxiliam na construção de um projeto de sucesso.
O planejamento de um projeto de desenvolvimento de software 
inclui:
1. Organização do Projeto (incluindo equipes e responsabilidades);
2. Estruturação das Tarefas (WBS - Work Breakdown Structure);
3. Cronograma do Projeto (normalmente um Diagrama de Barras);
4. Análise de Risco.
www.esab.edu.br 118
Essas atividades sofrem com dificuldades típicas de 
desenvolvimento de software. A produtividade não é linear em 
relação ao tamanho da equipe e o aumento de produtividade não 
é imediato devido os custos de aprendizado dos novos membros. 
A diminuição de qualidade para acelerar o desenvolvimento 
constantemente prejudica a produtividade.
A estimativa de dificuldades e custos de desenvolvimentos são 
muito difíceis, além do surgimento de problemas técnicos. Esses 
fatores requerem uma Análise de Riscos cuidadosa.
PMBOK
O PMBOK é uma importante referência em Gerenciamento de 
Projetos. Desenvolvido pelo PMI (Project Management Institute) 
possibilitou utilizar termos em comum para se discutir, escrever e 
aplicar o Gerenciamento de Projetos.
O guia atualmente é base para uma certificação específica e bem 
remunerada no mercado. Como os profissionais de Engenharia 
de Software praticamente são gerentes de projetos, existe a 
necessidade do entendimento desse conjunto de práticas para o 
bom desenvolvimento de um projeto de software.
A estrutura do PMBOK Guide (veja na figura 54 - os números 
entre parênteses representam respectivamente os blocos da 
imagem) contempla nove áreas de conhecimento específicas, que 
são:
1. Gerenciamento da Integração do Projeto (4);
2. Gerenciamento do Escopo do Projeto (5);
3. Gerenciamento do Prazo do Projeto (6);
www.esab.edu.br 119
4. Gerenciamento do Custo do Projeto (7);
5. Gerenciamento da Qualidade do Projeto (8);
6. Gerenciamento dos Recursos Humanos do Projeto (9);
7. Gerenciamento da Comunicação do Projeto (10);
8. Gerenciamento dos Riscos do Projeto (11);
9. Gerenciamento das Aquisições do Projeto (12);
Figura 54: Estrutura do PMBOK
Fonte: Próprio autor.
www.esab.edu.br 120
Figura 55: Project Management
Fonte: Próprio autor.
Gerenciamento de Qualidade e Estratégias de Teste de 
Software
Existe uma relação direta entre a qualidade do produto de software 
desenvolvido, e qualidade do processo de software utilizado para 
criar esse produto. Ou seja, qualquer melhoria no processo de 
software irá resultar diretamente um impacto na qualidade do 
produto final.
www.esab.edu.br 121
Portanto, os principais itens do Processo que deverão receber 
atenção especial do desenvolvedor para a melhoria da qualidade, 
e as perguntas mais significativas a serem questionadas são:
ITENS Perguntas
Facilidade de 
compreensão
Até que ponto o processo está definido e 
com que facilidade se compreende a 
definição do processo?
Visibilidade
As atividades culminam em resultado nítidos, 
de forma que o progresso do processo seja 
visível?
Facilidade de 
suporte
Até que ponto as atividades do processo 
podem ser apoiadas por ferramentas CASE?
Aceitabilidade O processo é aceitável e utilizável pelos desenvolvedores?
Confiabilidade
Os erros podem ser evitados ou identificados 
antes que o produto seja entregue aos 
usuários?
Robustez Existe continuidade no processo mesmo que surjam problemas inesperados?
Facilidade de 
manutenção
Existe evolução no processo para refletir os 
requisitos mutáveis da organização ou para 
receber melhorias?
Rapidez
A partir de uma determinada especificação 
com que rapidez pode ser alterado o 
processo?
Quadro 21: Itens do Processo
Fonte: Próprio autor, adaptado de Sommerville (2011)
Os principais fatores da qualidade de produtos de software, ou 
mesmo para quaisquer outros produtos intelectuais (livros, filmes, 
etc.), são:
1. a tecnologia de desenvolvimento;
2. a qualidade do pessoal;
3. a qualidade do processo (como vimos anteriormente!);
4. o custo, o tempo e o cronograma.
www.esab.edu.br 122
E de todos esses elementos o mais significativo é o último. Pois se 
um projeto tiver um orçamento baixo, ou ainda pior, um cronograma 
de entrega fora da realidade, a qualidade será diretamente afetada.
Estratégias de Teste de Software
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.
Uma das estratégias de Teste de Software é a abordagem Top-
down e a Bottom-up (veja na figura 56). Enquanto que a primeira 
(lado esquerdo da figura) tenta ver a integração de todos os 
componentes de um Sistema começando pelos níveis superiores, 
a segunda a Bottom-up (lado direito da figura), começa pelos 
níveis inferiores. As duas estratégias têm pontos positivos e 
negativos. O mais comum é utilizar a abordagem Top-down, por 
ser mais natural.
www.esab.edu.br 123
Figura 56: Top – Bottom-Up
Fonte: Próprio autor.
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 dos Testes Alfa existe a necessidade de um 
ambiente controlado. Ou seja, os usuários são levados a testar o 
www.esab.edu.br 124
software desde os seus estágios iniciais de instalação, até a sua 
operação completa. Tudo isso é realizado num ambiente especial, 
onde fiquem registradas todas as impressões dos usuários, suas 
reações às interfaces homem-máquina, e assim por diante.
Os Testes Beta são realizados exclusivamente no habitat do 
usuário. E é realizado tipicamente sem a presença dos 
desenvolvedores, ao contrário do Alfa. Normalmente é selecionado 
um público especial de usuários, com um perfil crítico e colaborador. 
É importante a escolha adequada de usuários nesse tipo de teste. 
Pois existe a necessidade do próprio usuário deixar todas suas 
observações, questionamentos e sugestões, registrados de forma 
minuciosa e com riqueza de detalhes.
Testes Caixa-Branca e Caixa-Preta
O Teste Caixa-Branca, também chamado de Teste Estrutural, 
foca-se mais nos possíveis erros internos ao Sistema. E o Teste 
Caixa-Preta visa identificar as falhas em seu comportamento 
externo.
Enquanto o Teste Caixa-Branca realiza testes na estrutura dos 
componentes de um Sistema, o Caixa-Preta refere-se aos testes 
que são conduzidos na interface do software.
Para realizar os Testes da Caixa-Branca são utilizadas técnicas 
tais como:
1. Testes de Caminho Básico: 
1. notação de grafo de fluxo;
2. caminhos independentes de programa;
3. derivação de casos de teste;
4. matrizes de grafos.
www.esab.edu.br 125
2. Testes de Estrutura de Controle:
1. teste de condição;
2. teste de fluxo de dados;
3. teste de ciclo.
No caso dos Testes de Caixa-Preta que focalizam nos requisitos 
funcionais do software são os mais utilizados no mundo prático. 
Os Caixa-Branca demandam muito tempo, e praticamente não 
conseguem realizar todas as possibilidades de resposta que um 
software fornece. As principais técnicas utilizadas nos Testes de 
Caixa-Preta são:
1.Métodos de Teste baseados em Grafo:
1. modelagem de fluxo de transação;
2. modelagem de estado finito;
3. modelagem do fluxo de dados;
4. particionamento de equivalência;
5. análise de valor-limite;
6. teste de matriz ortogonal.
Engenharia de Software na WEB – Sistemas e Aplicações 
baseadas na WEB
A Engenharia de Software na Web, também utilizada pela sigla 
WebE, é o processo usado para criar WebApps (aplicações 
baseadas na Web) de alta qualidade. Embora os princípios básicos 
da WebE sejam muito próximos da Engenharia de Software 
clássica, existem peculiaridades especificas e próprias.
Com o advento do B2B (e-business) e do B2C (e-commerce), e 
ainda mais com aplicações para a Web 2.0, maior importância 
ficou sendo esse tipo de engenharia. Como as WebApps evoluem 
www.esab.edu.br 126
continuamente, devem ser estabelecidos mecanismos para 
controle de configuração, garantia de qualidade e suporte 
continuado.
Tipicamente as WebApps são desenvolvidas incrementalmente, 
sofrendo modificações frequentemente, e possuindo cronogramas 
extremamente curtos. Por tudo isso, normalmente, o modelo de 
processo utilizado na WebE é o da filosofia do desenvolvimento 
ágil, por ter uma abordagem de desenvolvimento simples e com 
ciclos rápidos de desenvolvimento.
Figura 57: WebApps
Fonte Start developing today (2017)
Os métodos adotados na WebE são os mesmos conceitos e 
princípios da Engenharia de Software. No entanto, os mecanismos 
de análise, projeto e teste devem ser adaptados para acomodar 
as características próprias das WebApps
www.esab.edu.br 127
Quanto às ferramentas e tecnologias aplicadas na WebE englobam 
várias linguagens de modelagem (htmL, VRML, XML, etc.), 
recursos baseados em componentes (CORBA, COM, 
ActiveX,.NET, AJAX, etc.), navegadores, ferramentas multimídia, 
ferramentas de autoria de sites, ferramentas de conectividade de 
Banco de Dados, ferramentas de segurança, servidores e utilitários 
de servidor, e ferramentas de gestão e análise de sites.
Para quem desenvolve aplicações na Web deve observar os 
seguintes requisitos de qualidade:
1. usabilidade;
2. funcionalidade;
3. confiabilidade;
4. eficiência;
5. manutenibilidade;
6. segurança;
7. disponibilidade;
8. escabilidade
9. prazo de colocação no mercado.
Pirâmide de Projeto da WebE
Um projeto no contexto de Engenharia da Web leva a um modelo 
que contém a combinação adequada de estética, conteúdo e 
tecnologia. Repare na figura a seguir. Enquanto a base da pirâmide 
é a tecnologia (technology, figura 58), todos os seus itens são 
direcionados para atender o usuário (user).
www.esab.edu.br 128
Figura 58: Pirâmide de Projeto da WebE
Fonte: Próprio autor.
www.esab.edu.br 129
Cada nível da pirâmide representa uma atividade de projeto. Veja 
maiores detalhes de cada fase no quadro 22, vendo a pirâmide 
para baixo (figura 58):
Nível da 
Pirâmide Descrição
Projeto de 
Interface
Descreve a estrutura e organização da 
interface com o usuário.
Projeto Estético Atenta para os esquemas de cor, leiaute, fonte, uso de gráficos, etc.
Projeto de 
Conteúdo
Define a estrutura e o esboço de todo o 
conteúdo, relacionando os objetos de 
conteúdo.
Projeto de 
Navegação
Representa o fluxo de navegação entre 
objetos de conteúdo e todas as funções da 
WebApp.
Projeto 
Arquitetural
Identifica a estrutura de hipermídia para a 
WebApp.
Projeto de 
Componente
Desenvolve a lógica de processamento 
detalhada necessária para implementar os 
componentes funcionais.
Quadro 22: Itens do Processo
Fonte: Próprio autor, adaptado de Pressman (2011)
Arquitetura da WebApp
Conforme Jacyntho (2002) as aplicações devem ser construídas 
usando camadas nas quais diferentes preocupações são levadas 
em conta. Em particular, dados da aplicação devem ser separados 
dos conteúdos da página da Web. E esses conteúdos, por sua 
vez, devem ser claramente separados dos aspectos da interface.
Os autores sugerem um projeto de arquitetura em três camadas 
(veja na figura 59) que desacopla a interface da navegação, e do 
comportamento da aplicação. Os mesmos argumentam que 
manter a interface, aplicação e navegação separadas simplifica a 
implementação e aumenta o reuso.
www.esab.edu.br 130
Figura 59: Pirâmide de Projeto da WebE
Fonte: Próprio autor
A arquitetura mais utilizada nesse caso é a Modelo-Visão-
Controlador (MVC – Model-View-Controller). Embora seja um 
padrão de projeto arquitetural desenvolvido para o ambiente 
Smalltalk (linguagem de programação orientada a objeto), ele 
pode ser utilizado para qualquer aplicação interativa. Veja os 
detalhes de cada item da arquitetura MVC no quadro 23:
www.esab.edu.br 131
ITEM do MVC Descrição
MODELO
Encapsula funcionalidade, objetos de 
conteúdo e incorpora todos os estados 
da WebApp. É o conteúdo em si, 
normalmente armazenado num Banco 
de Dados externo.
VISÃO
Prepara dados do Modelo, requisita 
atualizações dele, apresenta visão 
selecionada pelo Controlador. 
Geralmente é a própria página htmL.
CONTROLADOR
Gera requisições do usuário, seleciona 
comportamento do Modelo e seleciona 
resposta de visão. É o código que gera 
os dados dinâmicos para dentro da 
página htmL.
Quadro 23: Itens arquitetura MVC
Fonte: Próprio autor
Estudo Complementar
Para você explorar mais adequadamente os objetivos do 
PMBOK, baixe o arquivo do site: http://www.prodepa.psi.br/
sqp/pdf/Capítulo 01 - Introdução.pdf, e leia o primeiro 
capítulo, em português, desse importante livro de 
Gerenciamento de Projetos.
http://www.prodepa.psi.br/sqp/pdf/Capítulo 01 - Introdução.pdf
http://www.prodepa.psi.br/sqp/pdf/Capítulo 01 - Introdução.pdf
www.esab.edu.br 132
Neste eixo temático fez-se uma abordagem metodológica e atual 
quanto a Engenharia de software e gestão de projetos através de 
cinco unidades: 1. Arquitetura cliente-servidor - Mudanças em 
Software - Dinâmica da Evolução de Programas - Evolução da 
Arquitetura, 2 Reengenharia de Software - Tradução de código 
fonte - Engenharia Reversa - Melhoria de estrutura de programa 
- Reengenharia de Dados e suas abordagens, 3. Gerenciamento 
de Configuração - Gerenciamento de Mudanças - Gerenciamento 
de Versões e Releases - Construção de Sistemas - Ferramenta 
CASE, 4. Sistemas Legados - Estruturas dos Sistemas Legados 
- Avaliação dos Sistemas Legados - Manutenção: fundamentos da 
fase de Manutenção de Software, tipos de Manutenção, 
procedimentos, técnicas e ferramentas, 5. Gestão de Projetos de 
Software e o PMBOK - Gerenciamento de Qualidade e Estratégias 
de Teste de Software- Engenharia de Software na WEB – Sistemas 
e Aplicações baseadas na WEB
www.esab.edu.br 133
AJAX: é o uso metodológico de tecnologias como Javascript e 
XML, providas por navegadores, para tornar páginas Web mais 
interativas com o usuário, utilizando-se de solicitações assíncronas 
de informações. R
C++: é uma linguagem de programação compilada multiparadigma 
(seu suporte inclui linguagem imperativa, orientada a objetos e 
genérica) e de uso geral. R
Elicitação: é a criação de sistema solicitado pelo cliente. R
Feedback: é uma palavra inglesa que significa realimentar ou dar 
resposta a um determinado pedido ou acontecimento. R
Hardware: É um termo da língua inglesa que se refere a 
equipamentos como chaves, fechaduras, trincos e peças de 
máquinas. No âmbito eletrônico utiliza-se na área de computação, 
e se aplica à unidade central de processamento, à memória e aos 
dispositivos de entrada e saída. R
HTML: abreviação para a expressão inglesa HyperText Markup 
Language, que significa Linguagem de Marcação de Hipertexto R
Interface: conjunto de meios planejadamente dispostos sejam 
eles físicos ou lógicos com vista a fazer a adaptação entre dois 
sistemas para se obter um certo fim cujo resultado possui partes 
comuns aos dois sistemas, ou seja, o objeto final possui 
características dos dois sistemas. R
Java: é uma linguagem de programação interpretada orientada a 
objetos desenvolvida na década de 90 por uma equipe de 
programadores chefiada por James Gosling,na empresa Sun 
Microsystems. R
www.esab.edu.br 134
Linux: é o núcleo do sistema operacional, programa responsável 
pelo funcionamento do computador, que faz a comunicação entre 
hardware (impressora, monitor, mouse, teclado) e software 
(aplicativos em geral). R
Mainframes: é um computador de grande porte dedicado 
normalmente ao processamento de um volume enorme de 
informações.R
Manutenibilidade: é uma característica inerente a um projeto de 
sistema ou produto, e se refere à facilidade, precisão, segurança 
e economia na execução de ações de manutenção nesse sistema 
ou produto. R
NET: é uma empresa de telecomunicações brasileira que oferece 
serviços como televisão por assinatura, acesso à internet e 
telefonia fixa. R
PMBOK: Project Management Body of Knowledge, é um guia para 
o conjunto de conhecimentos de gerenciamento de projetos. R
Rugby: o rúgbi ou râguebi, também chamado rugby, é um esporte 
coletivo de intenso contato físico. É originário da Inglaterra. Por ter 
sido, inicialmente, concebido como uma variação do futebol, foi 
chamado anteriormente de “rugby football”. R
Scrum: é uma metodologia ágil para gestão e planejamento de 
projetos de software. R
Second Life: é um ambiente virtual e tridimensional que simula 
em alguns aspectos a vida real e social do ser humano. R
Use-case: em software e engenharia de sistemas, um Use-case 
(caso de uso) é uma lista de ações ou etapas de eventos, 
tipicamente definindo as interações entre uma função (conhecida 
na linguagem de modelagem unificada como ator) e um sistema 
para atingir um objetivo. R
www.esab.edu.br 135
VRML: é um padrão de formato de arquivo para realidade virtual, 
utilizado tanto para a Internet como para ambientes desktop. R
Windows Vista:é um sistema operacional desenvolvido pela 
Microsoft, sendo a sexta versão do Windows para uso em 
computadores pessoais, incluindo computadores residenciais e de 
escritórios, laptops, Tablet PCs e computadores Media Centers. R
Windows XP: é uma família de sistemas operacionais de 32 e 64 
bits produzido pela Microsoft, para uso em computadores pessoais, 
incluindo computadores residenciais e de escritório, notebooks, 
tablets e media centers. R
XML: (extensible Markup Language) é uma recomendação da 
W3C para gerar linguagens de notação para necessidades 
especiais. R
www.esab.edu.br 136
ABECKER, A., BERNADI, A., HINKELMANN, K. et al., 2001, 
“Toward a Technology for Organizational Memories”, IEEE 
Intelligent Systems, v. 13, May/June. 2001.
ADAPTIVE SOFTWARE DEVELOPMENT. In: WIKIPÉDIA, a 
enciclopédia livre. Flórida: Wikimedia Foundation, 2015. Disponível 
em: <https://pt.wikipedia.org/w/index.php?title=daptive_Software_
Development&oldid=41742258>. Acesso em: 26 mar. 2015.
ALL Programming Tutorials, Books, Sample Codes & Programming. 
Disponível em: <http://programmingdumps.blogspot.com.
br/2011/11/software-engineering-software-crisis.html>. Acesso 
em: 1 out. 2017.
Ambiente de Desenvolvimento. 2001. Disponível em: <http://www.
funpar.ufpr.br:8080/rup/process/workflow/environm/co_deven.
htm>. Acesso em: 3 set. 2017.
AMBLER, Scott W. Agile Modeling. Disponível em: <http://www.
agilemodeling.com/>. Acesso em 26 set. 2017.
ARGO CONSULTANCY. CMMI Profits: Predictable Project 
Management. Disponível em: <http://www.argoconsultancy.eu/
cmmi-model/profits/profits-project-management.html> Acesso em: 
13 set. 2017.
AURÉLIO. O minidicionário da língua portuguesa. 4. ed. rev. e 
ampl. Rio de Janeiro: 2002.
AVISON, D.E., FITZGERALD, G. Information Systems Development 
Methodologies, Techniques and Tools. 2 ed. London: McGraw-Hill, 
1997.
http://
http://
http://programmingdumps.blogspot.com.br/2011/11/software-engineering-software-crisis.html
http://programmingdumps.blogspot.com.br/2011/11/software-engineering-software-crisis.html
http://
http://
http://
http://www.agilemodeling.com/
http://www.agilemodeling.com/
http://www.argoconsultancy.eu/cmmi-model/profits/profits-project-management.html
http://www.argoconsultancy.eu/cmmi-model/profits/profits-project-management.html
www.esab.edu.br 137
BLANCHARD, Benjamin. Logistics engineering and management. 
4th ed. Englewwod Cliffs: Prentice Hall, 1992. 
BOEHM, B. W. A Spiral Model of Software Development and 
Enhancement, IEEE Software. Technical Report 0018-9162/88. 
1988.
BOOCH, Grady. Object-Oriented Analysis and Design with 
Applications, 2end edition. Redwood City, CA: The Benjamin/
Cummings publishing Company. 1993.
BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. Tradução 
de Fábio Freitas da Silva e Cristina de Amorim Machado. UML. 
Guia do usuário. 6. reimp. Rio de Janeiro: Elsevier, 2005.
CHIKOFSKY, E.J.; CROSS II, J.H. Reverse Engeneering and 
Design Recovery: A Taxonomy. IEEE Software, v. 7., n. 1, 1990 
CMMIINSTITUTE. Disponível em: < https://sas.cmmiinstitute.com/
pars/pars.aspx >. Acesso em: 4 jun. 2017.
COCKBURN, A., Crystal Clear: A Human Powered Methodology 
for Small Teams, AddisonWesley, Boston, MA, 2005.
COUTINHO, Júlio. Web e Web App Webdesign cms Joomla! 2011. 
Disponível em: ursosbrasil.com.br/cursoonline/cursojoomla/mod1/
doc/projeto/memento-cons-web.pdf>. Acesso em 20 set. 2017.
CREAFORM. Disponível em: <https://www.creaform3d.com/es/
aplicaciones/productos-para-el-consumidor/creacion-rapida-de-
prototipos>. Acesso em 2 set. 2017.
CRISE DO SOFTWARE. In: WIKIPÉDIA, a enciclopédia livre. 
Flórida: Wikimedia Foundation, 2016. Disponível em: <https://
pt.wikipedia.org/w/index.php?title=Crise_do_
software&oldid=46485434>. Acesso em: 19 ago. 2016.
DAR MURRO EM PONTA DE FACA. In: WIKCIONÁRIO, o dicionário 
livre. Flórida: Wikimedia Foundation, 2016. Disponível em: <https://
pt.wiktionary.org/w/index.php?title=dar_murro_em_ponta_de_
faca&oldid=2155016>. Acesso em: 1 ago. 2016.
https://sas.cmmiinstitute.com/pars/pars.aspx 
https://sas.cmmiinstitute.com/pars/pars.aspx 
http://ursosbrasil.com.br/cursoonline/cursojoomla/mod1/doc/projeto/memento-cons-web.pdf
http://ursosbrasil.com.br/cursoonline/cursojoomla/mod1/doc/projeto/memento-cons-web.pdf
https://www.creaform3d.com/es/aplicaciones/productos-para%20-el-consumidor/creacion-rapida-de-prototipos
https://www.creaform3d.com/es/aplicaciones/productos-para%20-el-consumidor/creacion-rapida-de-prototipos
https://www.creaform3d.com/es/aplicaciones/productos-para%20-el-consumidor/creacion-rapida-de-prototipos
http://
http://
http://
http://
http://
http://
www.esab.edu.br 138
DAVIS, Alan M. Software requirements - objects, functions and 
states. 2. ed. USA: Prentice Hall. 1993.
DEVMIDIA. Introdução a Requisitos de Software. 2017. Disponível 
em: < <http://www.devmedia.com.br/introducao-a-requisitos-de-
software/29580>. Acesso em: 13 set. 2013.
FORM BOX. Change Reques Form. 2015. Disponível em: <http://
formbox .net/image /60 120?type=Big>. Acesso em 19 set. 2017.
Highsmith, J., Agile Project Management: Creating Innovative 
Products, Addison Wesley, Boston, MA, 2004.
HOLANDA FERREIRA. Aurélio Buarque de. Novo Dicionário 
Aurélio. Rio de Janeiro: Nova Fronteira, 1975.
HUMPHREY, Watts S. Managing the Software Process. ddison-
Wesley Professional, 1989.
IBM Corp. 1987, 2006. Todos os Direitos Reservados. Disponível 
em: <http://walderson.com/IBM/RUP7/SmallProjects/core.base_
rup/guidances/supportingmaterials/introduction_to_
rup_36B63436.html>. Acesso em: 12 set. 2017.
ISUTIC. Engenharia de Software. Metodologias, métodos e 
modelos (Engenharia de Software). 2016. Disponível em: <https://
engenhariasoftwareisutic.wordpress.com/2016/04/18/
metodologias-metodos-e-modelos-engenharia-de-
software/#more-20>. Acesso em: 20 set. 2017. 
Iterative development model V2.jpg. In: WIKIPÉDIA, Disponível 
em: <https://en.Wikipedia.org/wiki/File:Iterative_development_
model_V2.jpg>. Acesso em: 3 set. 2017.
JACOBSON, Ivar, CHRISTERSON, Magnus, JONSSON, Patrik et 
al. Object-Oriented Software Engineering – A Use Case-Driven 
Approach, Addison-Wesley, 1992. 
http://
http://
http://
http://
http://
http://
http://
https://engenhariasoftwareisutic.wordpress.com/http://
http://
http://
http://
https://en.wikipedia.org/wiki/File:Iterative_development_model_V2.jpg
https://en.wikipedia.org/wiki/File:Iterative_development_model_V2.jpg
www.esab.edu.br 139
JACYNTHO, Mark D.; SCHWABE, Daniel; ROSSI, Gustavo. A 
Software Architecture for Structuring Complex Web Applications. 
The Eleventh International world wide web conference. Honolulu, 
7-11.mai.2002. Não paginado. Disponível em: <http://www2002. 
org/CDROM/alternate/478/>. Acessado em 1 out. 2017.
JOBS, Marc Fast . Vivenciando TI. Diferença entre iterativo e 
interativo. 2010. Disponível em: <http://vivenciandoti.blogspot.
com.br/2010/10/diferenca-entre-iterativo-e-interativo.htm>. 
Acesso em: 20 set. 2017.
JUBILEU, Andrea Padovan. MODELOS DE PROCESSO DE 
SOFTWARE - Definição e Elementos de Processo de Software 
Alguns Modelos Prescritivos Alguns Modelos Ágeis. 2016.— 
Transcrição da apresentação: Disponível em: <http://slide player 
.com.br /slide/11 658097/>. Acesso em: 3 set. 2017.
LEITE, Jair C. O Modelo Cascata. Engenharia de software. 2007. 
Disponível em: <http://engenhariadesoftware.blogspot.com.
br/2007/03/o-modelo-cascata.html>. Acesso em 20 set. 2017.
LEITE, Lemon Lopes. Published in:Technology.2016. Disponível 
em: <https://www.slideshare.net/LemonLopesLeite/fdd-feature-
driven-development-slide-do-trabalho>. Acesso em: 18 set. 2017.
MACORATTI, José Carlos. O processo de Software. Disponível 
em:< http://www.macoratti.net/proc_sw1.htm>. Acesso em 20 set. 
2017.
MAGALHÃES, Teresinha Moreira de; MAGALHÃES, Lúcia Helena 
de; ROCHA, Fernando Machado da. Modelos de Maturidade 
Cmmi Capability Maturity Model Integration (CMMI). Revista 
eletrônica Fundação Educacional São José. 4. ed. 2010.
Mitchell Kapor – A software design manifesto, in “Bringing Design 
to Software, T. Winograd, 1996.
NAUR, P. Randell B. [1969]. Software Engineering. Rept. NATO 
Sci. Comm., 1969.
http://
http://
https://www.blogger.com/profile/00855566386793338679
http://vivenciandoti.blogspot.com.br/
http://vivenciandoti.blogspot.com.br/2010/10/diferenca-entre-iterativo-e-interativo%20.htm%3e.
http://vivenciandoti.blogspot.com.br/2010/10/diferenca-entre-iterativo-e-interativo%20.htm%3e.
http://
http://
http://
http://
https://www.slideshare.net/featured/category/technology
http://
http://
http://
www.esab.edu.br 140
O’LEARY, D.E., STUDER, R., 2001, “Knowledge Management: An 
Interdisciplinary Approach”, IEEE Intelligent Systems. 2001.
ORFALI, Robert; HARKEY, Dan; EDWARDS, Jeri. Client/Server 
Survival Guide. New York. John Wiley & Sons, 1999. 
PALMER, Stephen R.; FELSING, John M. A Practical Guide to 
Feature-Driven Development. New Jersey: Prentice Hall PTR, 
2002.
PETERS, J.F., PEDRYCZ, W. Engenharia de software, teoria e 
prática. Rio de Janeiro: Editora Campus, 2001.
PIXABAY . Categoria pessoas.2012. Disponível em:< https://
pixabay.com/pt/idade-homem-vov%C3%B4-homem-
velho-1015484/>. Acesso em 20 set. 2017.
PRESSMAN, Roger S. Engenharia de Software - Uma Abordagem 
Profissional. 7. ed. Porto Alegre: Bookman, 2011.
PRESSMAN, Roger S; MAXIM, Bruce R. Engenharia de Software 
- Uma Abordagem Profissional. Tradução: João Eduardo Nóbrega 
Tortello. 8. ed. Porto Alegre: Mariana Belloli, 2016.
ROCHA, Jennifer. Método Científico. Disponível em: <http:// 
manualdaquimica.uol.com.br/quimica-geral/metodo-cientifico.
htm>. Acesso em: 20 set. 2017.
RUMBAUGH, J. et al. Modelagem e projetos baseados em objetos. 
Rio de Janeiro: Editora Campus, 1994.
RUMBAUGH, James, BLAHA Michael, PREMERLANI, William et 
al. Object-Oriented Modeling and Design, Englewood Cliffs, NJ: 
Prentice Hall, 1991.
SCHWABER, Ken. Agile project management with Scrum, 
Microsoft Press. 2004.
https://pixabay.com/pt/idade-homem-vov%C3%B4-homem-velho-1015484/
https://pixabay.com/pt/idade-homem-vov%C3%B4-homem-velho-1015484/
https://pixabay.com/pt/idade-homem-vov%C3%B4-homem-velho-1015484/
http://
http://
http://
www.esab.edu.br 141
Scott W. Ambler, Análise e Projeto Orientados a Objeto, Volume 2, 
IBPI Press, Livraria e Editora Infobook S.A., 1998.
SOMMERVILLE, Ian. Engenharia de Software. Pearson. 9 ed, São 
Paulo, 2011.
START DEVELOPING TODAY. Progressive Web Apps. Disponível 
em: <https://developers.google.com/web/progressive-web-
apps/.> Acesso em: 20 set. 2017.
SUTHERLAND, Jeff; SCHWABER, Ken. Guia do Scrum: um guia 
definitivo para o Scrum: As regras do jogo. 2013. Disponível em: 
<https://www.scrumguides.org/docs/scrumguide/v1/Scrum-
Guide-Portuguese-BR.pdf>. Acesso em: 20 set. 2017. 
THE OMG – Disponível em: <http://www.uml.org/>. Acesso em: 14 
set. 2017.
Unified Modeling Language. (2017, September 20). In Wikipedia, 
The Free Encyclopedia. Retrieved 2017. Disponível em: <https://
en.wikipedia.org/w/index.php?title=Unified_Modeling_
Language&oldid=801574126>. Acesso em 20 set. 2017.
VILLELA, Isabelly. Visão Geral do RUP (Rational Unified Process). 
Disponível em: http://slideplayer.com.br/slide/1791122/. Acesso 
em: 6 set. 2017. 
VIOLIN, Renato O. Análise e Projeto de Sistemas. Transcrição da 
apresentação. 2015. Disponível em: http://slideplayer.com.br/
slide/1832728/ Acesso em: 5 set. 2017.
WARREN BUFFETT. In: WIKIPÉDIA, a enciclopédia livre. Flórida: 
Wikimedia Foundation, 2017. Disponível em: <https://pt.wikipedia. 
org/w/index.php?title= Warren_ Buffett&oldid =49744421>. Acesso 
em: 2 set. 2017.
http://
http://
http://
http://
http://www.uml.org/
http://
http://
http://
http://slideplayer.com.br/slide/1791122/
http://slideplayer.com.br/slide/1832728/
http://slideplayer.com.br/slide/1832728/
http://
http://
	_GoBack
	_GoBack
	_Hlk494199896
	_Hlk494201269
	_GoBack
	_GoBack
	_Hlk494204471
	_GoBack
	_Hlk494215977
	_Hlk494217296
	_GoBack
	_GoBack
	_GoBack
	Top
	XE_development_environment
	XE_environment__development_environment
	_GoBack
	AJAX: é o uso metodológico de tecnologias como Javascript e XML, providas por navegadores, para to