Livro Engenharia de Software

Prévia do material em texto

ENGENHARIA DE 
SOFTWARE
PROF. FRANCISCO LUÍS BORGHI 
NASCIMENTO
“A Faculdade Católica Paulista tem por missão exercer uma ação integrada de suas atividades educacionais, visando à 
geração, sistematização e disseminação do conhecimento, 
para formar profissionais empreendedores que promovam 
a transformação e o desenvolvimento social, econômico e 
cultural da comunidade em que está inserida.
Missão da Faculdade Católica Paulista
 Av. Cristo Rei, 305 - Banzato, CEP 17515-200 Marília - São Paulo.
 www.uca.edu.br
Nenhuma parte desta publicação poderá ser reproduzida por qualquer meio ou forma 
sem autorização. Todos os gráficos, tabelas e elementos são creditados à autoria, 
salvo quando indicada a referência, sendo de inteira responsabilidade da autoria a 
emissão de conceitos.
Diretor Geral | Valdir Carrenho Junior
ENGENHARIA DE SOFTWARE
PROF. FRANCISCO LUÍS BORGHI NASCIMENTO
SUMÁRIO
AULA 01
AULA 02
AULA 03
AULA 04
AULA 05
AULA 06
AULA 07
AULA 08
AULA 09
AULA 10
AULA 11
AULA 12
AULA 13
AULA 14
AULA 15
AULA 16
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
PROCESSO DE SOFTWARE
MÉTODOS TRADICIONAIS – PARTE 1
MÉTODOS TRADICIONAIS – PARTE 2
INTRODUÇÃO AOS MÉTODOS ÁGEIS
MÉTODOS ÁGEIS - EXEMPLOS
MÉTODOS ÁGEIS - SCRUM
REQUISITOS DE SOFTWARE
REQUISITOS DE SOFTWARE - CONTINUAÇÃO
MODELAGEM DE SOFTWARE – INTRODUÇÃO À UML
UML - DIAGRAMA DE ATIVIDADES
UML - DIAGRAMA
UML – DIAGRAMAS DE CASOS DE USO
TESTE E MANUTENÇÃO DE SOFTWARE
FERRAMENTAS DE APOIO AO DESENVOLVIMENTO DE 
SOFTWARE
SISTEMA DE CONTROLE DE VERSÃO - GIT
05
11
15
20
24
29
35
41
46
51
55
60
64
69
74
79
FACULDADE CATÓLICA PAULISTA | 4
ENGENHARIA DE SOFTWARE
PROF. FRANCISCO LUÍS BORGHI NASCIMENTO
INTRODUÇÃO
Uma ideia na cabeça, conhecimento de programação e um computador com internet são 
suficientes para começar um programa? 
Se sua ideia é entregar um projeto razoável e que necessite de intervenções que passem 
a fazer parte da rotina e ao mesmo tempo podem complicar a usabilidade de outros clientes, 
sim. 
Mas, se você pretende fazer um programa estruturado, com poucas manutenções, que seja 
útil, se utilizando de requisitos e as ferramentas úteis que agilizam e melhoram o resultado, 
e ao mesmo tempo entregar em um curto espaço de tempo, além dos itens mencionados 
acima, esse livro vai te ajudar bastante. 
Com a engenharia de Software o projeto tem começo, meio e torçamos para que nunca 
chegue ao fim. 
Desde os processos iniciais passando pela metodologia rápida de desenvolvimento, com 
diagramação e execução, um bom software precisa estar dentro daquilo que ele foi projetado. 
Tenha a certeza que você vai ter uma boa base para conseguir elaborar um projeto que 
atenderá as necessidades do seu cliente. 
FACULDADE CATÓLICA PAULISTA | 5
ENGENHARIA DE SOFTWARE
PROF. FRANCISCO LUÍS BORGHI NASCIMENTO
AULA 1
INTRODUÇÃO À ENGENHARIA DE 
SOFTWARE
 
Engenharia de Software cujo foco está em todos os aspectos da produção de software, 
compreende desde os estágios iniciais da especificação do sistema até a sua manutenção. 
A Engenharia de Software é a disciplina que se preocupa em estudar e monitorar o bom 
andamento das atividades e a integração entre elas. É importante notar que é baseado na 
Engenharia de Software o sucesso de um projeto e sua organização.
 
Fonte: https://network.grupoabril.com.br/wp-content/uploads/sites/4/2019/06/engenharia-de-software.png
O software se tornou um elemento muito importante para o mundo e diante da capacidade 
de manipular a informação. O crescimento computacional leva à criação de sistemas perfeitos 
e problemas para quem desenvolve softwares complexos. As preocupações dos engenheiros 
de software para desenvolverem aplicações sem defeitos e entregarem estes produtos no 
tempo marcado leva a aplicação das fundamentações da engenharia de software.
1.1 Mas, afinal, o que é Software?
O software é o conjunto de vários artefatos e não apenas o código fonte (SOMMERVILLE 
apud DEVMEDIA, 2021). 
O software pode ser desenvolvido e realizar a manutenção no software é uma tarefa 
complicada, exige grande esforço da equipe de engenheiro de software. Ao passar do tempo 
o software fica obsoleto. 
 https://network.grupoabril.com.br/wp-content/uploads/sites/4/2019/06/engenharia-de-software.png
FACULDADE CATÓLICA PAULISTA | 6
ENGENHARIA DE SOFTWARE
PROF. FRANCISCO LUÍS BORGHI NASCIMENTO
O software é caro porque torna se uma atividade difícil e trabalhosa de ser realizado pelo 
engenheiro de software (JALOTE apud DEVMEDIA, 2021).
1.2 Categorias de Softwares
Software de sistema. São programas que apoiam outros programas. Exemplo: sistema 
operacional e compiladores.
Software de aplicação. São programas que são desenvolvidos para auxiliar os negócios 
de uma empresa. Exemplo: software de gestão empresarial.
Software científico e de engenharia. Algoritmos que processam números.
Software embutido. Programas construídos para executarem dentro de um produto 
específico. Exemplo: teclas digitais de um forno micro-ondas.
Software de web. São aplicativos que são executados via Internet.
 
Fonte: https://arquivo.devmedia.com.br/marketing/img/artigo-principios-da-engenharia-de-software-29630.png
Software de inteligência artificial. Fazem os usos de algoritmos não numéricos. Exemplo: 
robótica.
Computação ubíqua. São softwares que realizam a verdadeira computação distribuída. 
Exemplo: Siri, Alexa, Cortana 
https://arquivo.devmedia.com.br/marketing/img/artigo-principios-da-engenharia-de-software-29630.png
FACULDADE CATÓLICA PAULISTA | 7
ENGENHARIA DE SOFTWARE
PROF. FRANCISCO LUÍS BORGHI NASCIMENTO
Software aberto. São softwares que disponibilizam a visualização do código fonte da 
aplicação para o engenheiro de software modifica da maneira que deseja. 
1.3 Aplicação da Engenharia de Software
Engenharia de Software envolve planejamento, no qual estão inseridas pessoas e os 
cronogramas de trabalho.
 Pessoas porque divide as responsabilidades de forma individual ou coletiva e cronograma 
porque, conforme o planejamento, os gestores têm a possibilidade de estimar e medir o 
tempo que será utilizado para o desenvolvimento de cada projeto.
A engenharia de software envolve também a preocupação com a qualidade do que será 
oferecido ao cliente, não só se referindo apenas à entrega de produtos em funcionamento, 
mas também ao atendimento das necessidades do cliente. 
A análise de requisitos tem importância fundamental, na medida em que é por meio dela 
que as equipes de desenvolvimento recebem informações sobre necessidade do cliente 
quanto ao produto que está sendo desenvolvido. 
 Até durante a fase de desenvolvimento da programação em si, a Engenharia de Software 
se faz presente, uma vez que a escolha do processo ideal irá influenciar diretamente no 
trabalho cotidiano dos envolvidos.
1.4 Histórico
O desenvolvimento de software empregou diversas mudanças e adaptações para facilitar 
os processos dos profissionais que realizam esse trabalho. As principais evoluções no 
desenvolvimento de software podem ser classificadas em dois grandes grupos: mudanças 
processuais e mudanças tecnológicas (MORAIS, 2017).
FACULDADE CATÓLICA PAULISTA | 8
ENGENHARIA DE SOFTWARE
PROF. FRANCISCO LUÍS BORGHI NASCIMENTO
 
Fonte: https://memoriainfo.furg.br/images/perfurador%20de%20cartao%20ibm%20x620-85.lg.jpg
Estima-se que o desenvolvimento de software começou por volta de 1725, em cartões 
perfurados. Posteriormente, surgiram as primeiras linguagens de programação, tais quais 
as que existem hoje, sendo elas FORTRAN (1955), List Processor (LISP) e Common Business 
Oriented Language (COBOL). Posteriormente, surgiram linguagens de programação de alto 
nível, isto é, que se aproximam mais da linguagem humana são exemplos: Java, JavaScript, 
Visual Basic, Object Pascal e PHP.
1.5 Finalidade
 
Ainda que a programação não seja o foco principal da Engenharia de Software é necessário 
conhecer as linguagens mais utilizadase seu funcionamento.
 Da mesma forma, habilidades matemáticas são recomendadas. Engenheiros, 
frequentemente, precisam criar algoritmos matemáticos.
 Para facilitar o trabalho com softwares, os profissionais podem empregar uma série de 
ferramentas. Entre elas Ambientes de Desenvolvimento Integrado (IDE, do inglês Integrated 
Development Environment).
https://memoriainfo.furg.br/images/perfurador%20de%20cartao%20ibm%20x620-85.lg.jpg
FACULDADE CATÓLICA PAULISTA | 9
ENGENHARIA DE SOFTWARE
PROF. FRANCISCO LUÍS BORGHI NASCIMENTO
 Além das IDE, ferramentas de teste automatizadas e bibliotecas de código aberto, que 
oferecem as funcionalidades prontas, devem ser utilizados com o intuito de diminuir o trabalho 
de desenvolvê-las. Por muitos sistemas de software atuais interagirem com bancos de dados, 
o engenheiro de software também precisa ser capaz de administrá-los.
 
Fonte: https://becode.com.br/wp-content/uploads/2017/05/IDEs-Usar-ou-nao-usar11.png
 
Entre as principais atribuições do engenheiro de software estão:
• gestão — gerenciamento de projetos em empresas de computação e software;
• desenvolvimento — aplicativos, softwares, jogos e variados tipos de sistema para 
computadores, dispositivos móveis e consoles;
• estruturação — design e funcionalidade de softwares;
• manutenção — testes e ajustes em sistemas já existentes.
https://becode.com.br/wp-content/uploads/2017/05/IDEs-Usar-ou-nao-usar11.png
FACULDADE CATÓLICA PAULISTA | 10
ENGENHARIA DE SOFTWARE
PROF. FRANCISCO LUÍS BORGHI NASCIMENTO
Isto acontece na prática
Análise de Sistemas versus Engenharia de Software
 
A Engenharia de Software abrange princípios da engenharia para criar programas e 
aplicativos. A Análise de Sistemas é um objeto de estudo da Engenharia de Software.
 Enquanto a Engenharia de Software foca aspectos processuais como o levantamento 
de requisitos, o projeto de sistemas, a implantação, entre outros, a Análise de Sistemas 
se aprofunda nas atividades processuais de Programação e Modelagem de Negócios.
 Simplificando, entende-se como Analista de Sistemas o profissional que, dentro de um 
negócio se concentra mais na maneira como o software é utilizado. Já o engenheiro 
se relaciona com o processo de produção desse software, tendo maior amplitude nas 
possibilidades de atuação. Embora as formações sejam parecidas, suas atuações são 
diferentes.
Isto está na rede
 
O canal Código Fonte TV tem um belo vídeo que descreve as atribuições do 
Engenheiro de Software: https://www.youtube.com/watch?v=wdU9L3DqU2w&ab_
channel=C%C3%B3digoFonteTV
https://www.youtube.com/watch?v=wdU9L3DqU2w&ab_channel=C%C3%B3digoFonteTV
https://www.youtube.com/watch?v=wdU9L3DqU2w&ab_channel=C%C3%B3digoFonteTV
FACULDADE CATÓLICA PAULISTA | 11
ENGENHARIA DE SOFTWARE
PROF. FRANCISCO LUÍS BORGHI NASCIMENTO
AULA 2
PROCESSO DE SOFTWARE
Quando um novo projeto de software se inicia seu planejamento é um desafio e nem 
sempre é possível conseguir preencher todas as lacunas existentes no momento de sua 
elaboração.
 
 
Fonte: https://miro.medium.com/max/882/1*gE4B5CMuBUnVqRdPth_ZFQ.png
Dificuldades, imprevistos e retrabalho são comuns em muitos projetos, gerando desconforto 
para a empresa e para o cliente. Embora não seja possível extinguir completamente esses 
fatores é possível reduzi-los a um nível mínimo se na estratégia utilizada adotarmos um 
processo adequado para a realidade específica e o tipo de projeto a ser desenvolvido.
O Processo de Software é um conjunto de atividades usadas para a produção de sistemas 
computacionais, envolvendo o desenvolvimento do início ao fim, ligadas por padrões de 
relacionamento entre elas, pelas quais, se as atividades operarem corretamente e de acordo 
com os padrões requeridos. O resultado desejado é um software de alta qualidade e com 
baixo custo (JALOTTE, 2005).
Existem vários modelos de processo de software, porém todos possuem algumas etapas 
em comum (SOMMERVILLE, 2011), como se seguem:
https://miro.medium.com/max/882/1*gE4B5CMuBUnVqRdPth_ZFQ.png
FACULDADE CATÓLICA PAULISTA | 12
ENGENHARIA DE SOFTWARE
PROF. FRANCISCO LUÍS BORGHI NASCIMENTO
2.1 Especificação
 
É onde acontece a definição das funcionalidades do software e as restrições em seu 
funcionamento. Envolve a engenharia de sistema que estabelece uma solução geral para 
o problema, envolvendo questões extra software; a análise de requisitos na qual levanta as 
necessidades do software produzindo um documento com a especificação de requisitos e 
a especificação de Sistema sendo a descrição funcional do sistema, incluindo um plano de 
testes para verificar a adequação.
2.2 Projeto
 
Aqui ocorre o planejamento do software que envolve o projeto arquitetural que desenvolve 
um modelo conceitual, composto de módulos mais ou menos independentes. O projeto de 
interface cada módulo tem sua interface de comunicação estudada e definida. No projeto 
detalhado os módulos em si são definidos, e possivelmente traduzidos para pseudocódigo.
2.3 Implementação e Validação
Nesta etapa o software deve ser produzido de modo que cumpra sua especificação. É 
onde acontece a chamada “programação” ou “codificação”.
Após a programação o código precisa ser validado para garantir que esteja, de fato, 
fazendo o que o cliente solicitou. Envolve:
Teste de Unidade e de Módulo: são feitos testes para verificar a presença de erros e 
comportamento adequado em nível das funções e módulos básicos do sistema.
Integração: a união de diferentes módulos implementados em um único produto e os 
testes da interação entre eles quando operando em conjunto.
FACULDADE CATÓLICA PAULISTA | 13
ENGENHARIA DE SOFTWARE
PROF. FRANCISCO LUÍS BORGHI NASCIMENTO
 
Fonte: https://www.mxm.com.br/wp-content/uploads/2017/11/passo-a-passo-implementacao-erp-01-1024x512.png
2.4 Manutenção e Evolução
Esta etapa é muito importante, pois o software precisa evoluir para atender a novas 
necessidades ou mudanças solicitadas pelo cliente. O software em geral entra em um ciclo 
iterativo que abrange todas as fases anteriores.
2.5 Modelos de Processo
A expressão “cada caso é um caso” é bem adequado quando se fala de Modelo de Processo, 
pois para cada tipo de projeto um Modelo de Processo será o mais adequado. Assim sendo, 
não existe o “modelo melhor de todos”, mas sim o “modelo melhor para este projeto”. Cada 
modelo possui vantagens e desvantagens que precisam ser consideradas na hora de serem 
adotados.
A escolha de um modelo deve ser embasada no custo-benefício que ele pode trazer no 
momento do desenvolvimento. Ou seja:
Se for um projeto pequeno não serão necessárias muitas tratativas de controle podendo 
talvez ser desenvolvido por um ou dois programadores.
https://www.mxm.com.br/wp-content/uploads/2017/11/passo-a-passo-implementacao-erp-01-1024x512.png
FACULDADE CATÓLICA PAULISTA | 14
ENGENHARIA DE SOFTWARE
PROF. FRANCISCO LUÍS BORGHI NASCIMENTO
Ao contrário, em projetos maiores, um controle mais minucioso de variantes será necessário, 
por causa da maior quantidade de mudanças durante o processo.
Uma escolha acertada do melhor modelo é determinante e pode reduzir imensamente o 
desperdício de tempo e de dinheiro, aumentando o lucro obtido na entrega do projeto.
 
 
Fonte: https://fluxoconsultoria.poli.ufrj.br/wp-content/uploads/2020/09/Sem-t%C3%ADtulo-2.png
 
Existem alguns modelos genéricos de processo de software, tais como o modelo cascata 
(que separa e distingue as fases de especificação e desenvolvimento), o desenvolvimento 
evolucionário (em que as atividades de especificação e desenvolvimento estão entrelaçadas) e 
o desenvolvimento baseado no reuso (em que o software é montado a partir de componentes 
existentes).
Os modelos são classificados em dois grupos: metodologias tradicionais e metodologias 
ágeis. O primeiro grupo é mais empregado em empresas com comunicação formal, com 
projetos longos e complexos e requisitos bem definidos. O segundo grupo é mais usado 
por organizações que dão ênfase à colaboração, com projetosque possuem requisitos que 
mudam muito e exigem comunicação mais próxima com o cliente.
Isto está na rede
Uma animação sobre o processo de desenvolvimento de software que demonstram 
os planejamentos e os cuidados a serem tomados: https://www.youtube.com/
watch?v=QPiR8jTMLdI&ab_channel=CarlosGouvea
https://fluxoconsultoria.poli.ufrj.br/wp-content/uploads/2020/09/Sem-t%C3%ADtulo-2.png
https://www.youtube.com/watch?v=QPiR8jTMLdI&ab_channel=CarlosGouvea
https://www.youtube.com/watch?v=QPiR8jTMLdI&ab_channel=CarlosGouvea
https://www.youtube.com/watch?v=QPiR8jTMLdI&ab_channel=CarlosGouvea
FACULDADE CATÓLICA PAULISTA | 15
ENGENHARIA DE SOFTWARE
PROF. FRANCISCO LUÍS BORGHI NASCIMENTO
AULA 3
MÉTODOS TRADICIONAIS – 
PARTE 1
 
Os modelos tradicionais foram criados entre as décadas de 1970 e 1990 pelas evoluções 
naturais que ocorrem no desenvolvimento de software. Na ocasião havia muitos problemas 
que representavam barreiras na criação de sistemas de alta qualidade. O modelo cascata 
foi um dos primeiros a serem propostos.
 
Fonte: https://img.freepik.com/fotos-gratis/composicao-simples-com-computador-antigo-em-3d-verde-render_165683-11.jpg?size=664&ext=jpg
 
Após sua criação diversos problemas foram apontados, levando ao surgimento de outros 
modelos, como o espiral, por exemplo. Ainda, houve a evolução dos modelos de ciclo de 
vida, possibilitando atualmente a utilização de diversos modelos. 
Para aprender sobre os modelos atuais é muito importante entender os modelos tradicionais, 
identificar quais foram as evoluções que ocorreram e o motivo da presença de determinadas 
características nos modelos que utilizamos hoje.
https://img.freepik.com/fotos-gratis/composicao-simples-com-computador-antigo-em-3d-verde-render_165683-11.jpg?size=664&ext=jpg
FACULDADE CATÓLICA PAULISTA | 16
ENGENHARIA DE SOFTWARE
PROF. FRANCISCO LUÍS BORGHI NASCIMENTO
3.1 Modelo Cascata
Primeiro modelo de ciclo de vida de desenvolvimento de software, motivo pelo qual é o 
mais conhecido entre os profissionais da área de desenvolvimento de sistemas. O modelo 
recebe o nome de cascata por ser um processo executado em sequência, sem que de uma 
etapa posterior seja possível retornar a uma etapa anterior. Também chamado de ciclo 
de vida clássico, esse modelo sugere uma abordagem sequencial e sistemática para o 
desenvolvimento de software, começando com a especificação dos requisitos do cliente, 
avançando pelas fases de planejamento, modelagem, construção e disponibilização, e 
culminando no suporte contínuo do software concluído (MORAIS, 2017).
Modelo Cascata. Fonte: Morais (2017)
Justamente por sua característica sequencial, esse modelo apresenta etapas muito bem 
definidas, o que facilita o gerenciamento dos projetos que o adotam. Outra vantagem do 
método cascata, também relacionada à separação do projeto em etapas, reside no fato de 
que os requisitos costumam estar bem definidos. O modelo não prevê alterações de requisitos 
no meio do processo, mas apenas uma definição detalhada no início que será implementada 
criteriosamente para ser entregue ao final do fluxo.
Esse processo de software foi espelhado em modelos utilizados em outras áreas, como 
nos projetos tradicionais de engenharia. Nesses casos, o sistema pode ser realmente útil, já 
que a execução das atividades de forma linear não atrapalha a realização do projeto.
FACULDADE CATÓLICA PAULISTA | 17
ENGENHARIA DE SOFTWARE
PROF. FRANCISCO LUÍS BORGHI NASCIMENTO
Fonte: https://www.ntaskmanager.com/wp-content/uploads/2019/07/3.png
Porém, o desenvolvimento de software tem algumas particularidades que tornam o 
modelo em cascata inapropriado para a criação desse tipo de produto. Isso leva a diversos 
contratempos, como:
• dificuldade para cumprir o cronograma do projeto e os prazos de entrega;
• problemas financeiros devido à ultrapassagem do orçamento previsto;
• dificuldade em atender às expectativas dos usuários finais.
3.2 Mudança de requisitos
O modelo cascata não permite flexibilidade. Uma vez iniciado, todas as etapas são 
executadas e o primeiro resultado só é visto no final. Para um bom funcionamento é preciso 
que a fase do levantamento de requisitos contenha o mínimo de erros.
Porém, requisitos de um software não são sempre estáveis, principalmente no caso de 
projetos mais longos, pois as necessidades dos clientes mudam com o tempo, o que pode 
exigir alterações e inclusão de novas funcionalidades no sistema. Caso o desenvolvimento 
seja demorado, quando as etapas do modelo em cascata forem concluídas e o software 
estiver pronto, pode ser que ele já esteja obsoleto.
https://www.ntaskmanager.com/wp-content/uploads/2019/07/3.png
FACULDADE CATÓLICA PAULISTA | 18
ENGENHARIA DE SOFTWARE
PROF. FRANCISCO LUÍS BORGHI NASCIMENTO
3.3 Ausência de feedback contínuo
A falta de feedback do cliente também acaba sendo uma desvantagem, pois a interação 
do mesmo com a equipe de desenvolvimento acontece geralmente no início e no fim do 
projeto. Essa falta de acompanhamento gera desentendimentos já que nem sempre o cliente 
sabe ao certo o que ele deseja na hora da contratação ou a equipe pode compreendê-lo de 
forma errada.
A primeira versão executável do software é entregue ao cliente para que dê o feedback. 
Caso haja algum problema, a equipe terá que reiniciar o modelo em cascata para realizar as 
mudanças necessárias. Se elas forem muitas, isso pode significar uma grande quantidade 
de retrabalho e custos desnecessários para a empresa.
3.4 Falta de produtividade. 
Fonte: https://pensandofalando.files.wordpress.com/2013/07/dormindo2.jpg
No modelo cascata a atividade dos programadores é dificultada, já que as etapas ocorrem 
de forma sequencial e é preciso respeitar essa definição. Neste caso, fica difícil a atribuição de 
tarefas para a equipe. Assim, algumas pessoas da equipe podem ficar ociosas, principalmente 
no início e no fim de cada etapa, pois em determinado momento, uma pessoa pode precisar 
esperar que a outra termine uma tarefa para que ela possa começar a sua. 
https://pensandofalando.files.wordpress.com/2013/07/dormindo2.jpg
FACULDADE CATÓLICA PAULISTA | 19
ENGENHARIA DE SOFTWARE
PROF. FRANCISCO LUÍS BORGHI NASCIMENTO
Um exemplo são as atividades de modelagem e design da interface, ocorridas na etapa 
de projeto e seu desenvolvimento. Se pequenas partes da interface fossem liberadas 
gradativamente, de forma iterativa para as pessoas programadoras, o trabalho seria agilizado.
3.5 Modelo prototipação
Leva algumas semelhanças com o modelo cascata, pois também tem etapas bem definidas. 
Apresenta como característica principal uma prototipação ao início do ciclo de vida. Essa 
prototipação é feita após um primeiro contato com o cliente e objetiva que todos os envolvidos 
consigam interagir com esse protótipo, tendo uma ideia de como o software funcionará para 
aprovar ou sugerir modificações.
O processo de estabelecer um protótipo antes da criação do sistema apresenta vantagens: 
• consiste no fato de que os requisitos se tornam mais visuais e intuitivos e possibilita 
que o cliente tenha maior certeza de que expressou suas necessidades corretamente e que, 
por isso, receberá o software esperado.
E desvantagens:
• pode ser considerado uma fonte de retrabalho e alto custo e, por considerar um tempo de 
criação e validação do protótipo, o ciclo de vida do software como um todo pode demandar 
maior tempo para ser executado (MORAIS, 2017).
 
Fonte: Morais (2017)
FACULDADE CATÓLICA PAULISTA | 20
ENGENHARIA DE SOFTWARE
PROF. FRANCISCO LUÍS BORGHI NASCIMENTO
AULA 4
MÉTODOS TRADICIONAIS – 
PARTE 2
4.1 Modelo Espiral
Busca reunir características dos demais modelos de ciclos de vida tradicionais e considera 
também a criação de protótipos e a execução por fases bem definidas. 
Sua diferença ante ao modelo cascata é que acrescenta uma análise criteriosa de riscos ao 
início de cada etapa, beneficiando-se da principal característica do modelo prototipação. Pelo 
fato de unificar características dosdemais modelos, o modelo espiral também tem vantagens 
e desvantagens quanto aos outros, pois apresenta requisitos e etapas bem definidos, mas 
com um alto custo de execução, por considerar diversas prototipações, uma para cada fase 
percorrida.
 
Fonte: http://ned.unifenas.br/cursosgratuitos/201302/tfs/img/modelo-espiral.png
Barry Boehm, em 1988, criou uma melhoria do modelo incremental e leva esse nome em 
virtude de sua representação, em que cada volta no espiral percorre todas as fases do processo 
http://ned.unifenas.br/cursosgratuitos/201302/tfs/img/modelo-espiral.png
FACULDADE CATÓLICA PAULISTA | 21
ENGENHARIA DE SOFTWARE
PROF. FRANCISCO LUÍS BORGHI NASCIMENTO
de software. De acordo com Pressman (2011) e Boehm e Hansen (2001) (apud MARTINS, 
2017), o modelo espiral de desenvolvimento gera modelos de processos dirigidos a riscos 
e utilizados para guiar a engenharia de sistemas com muito software. As características 
principais que o distinguem consistem em uma estratégia cíclica voltada para ampliar o 
grau de definição e a implantação de um sistema e reside no fato de dispor de uma série 
de marcos para garantir o comprometimento dos envolvidos quanto a busca de soluções 
de sistema mutuamente satisfatórias e viáveis conforme observa-se na figura abaixo:
 
Fonte: Morais (2017)
Ao analisar a figura, nota-se que a curva espiralada representa o custo acumulado até o 
momento e a dimensão angular o processo ao longo da espiral. Os ciclos correspondem às 
fases em que uma fase se inicia juntamente à determinação de sua meta. Na sequência, 
essa estratégia é analisada sob o ponto de vista de riscos que passam por tentativas de 
minimização construindo-se protótipos à medida que forem necessários. Se os riscos não 
puderem ser diminuídos, o projeto pode ser interrompido imediatamente, contudo, se forem 
FACULDADE CATÓLICA PAULISTA | 22
ENGENHARIA DE SOFTWARE
PROF. FRANCISCO LUÍS BORGHI NASCIMENTO
minimizados com sucesso, a próxima etapa de desenvolvimento é iniciada. Por fim, os 
resultados são avaliados e se planeja a fase seguinte.
Com o uso do modelo espiral, o software será desenvolvido em uma série de versões que 
se evoluem. Já as primeiras iterações poderão consistir em um modelo ou em um protótipo. 
Nas iterações posteriores são produzidas versões cada vez mais completas do sistema 
passando pelo processo de engenharia. Presmann (2011 apud MARTINS 2017) diz que o 
modelo espiral divide-se em um conjunto de atividades que representam um segmento do 
caminho espiral, no qual, assim que o processo evolucionário começa, a equipe de software 
realiza atividades indicadas por um circuito em torno da espiral, no sentido horário, iniciando 
pelo seu centro.
 
Fonte: elaborado pelo autor
Durante o processo os riscos são levados em conta à medida que se realiza cada revolução. 
Por fim, o primeiro circuito em volta da espiral pode resultar no desenvolvimento de uma 
especificação de produto, enquanto as passagens subsequentes em torno da espiral podem 
ser usadas para desenvolver versões cada vez mais sofisticadas do software.
Boehm (1988, p.71-72), diz que 
modelo espiral descreve um fluxo de atividades cíclico e evolutivo constituído 
de quatro estágios. No estágio 1 devem ser determinados objetivos, soluções 
alternativas e restrições. No segundo estágio devem ser analisados os riscos das 
decisões do estágio anterior construindo protótipos ou realizando simulações 
do software.
O terceiro estágio consiste nas atividades da fase de desenvolvimento, incluindo 
design, especificação, codificação e verificação. A principal característica é que 
a cada especificação que vai surgindo a cada ciclo. 
FACULDADE CATÓLICA PAULISTA | 23
ENGENHARIA DE SOFTWARE
PROF. FRANCISCO LUÍS BORGHI NASCIMENTO
O estágio 4 compreende a revisão das etapas anteriores e o planejamento da 
próxima fase. Neste planejamento, dependendo dos resultados obtidos nos 
estágios anteriores. As decisões, análise de riscos e verificação pode-se optar 
por seguir o desenvolvimento num modelo linear, tal como o cascata, Evolutivo 
ou Transformação. Se já no primeiro ciclo os requisitos forem completamente 
especificados e validados pode-se optar por seguir o modelo Cascata. Caso 
contrário pode-se optar pela construção de novos protótipos, incrementando-o, 
avaliando novos riscos e replanejando o processo.
Isto está na rede
 
O Canal do Youtube “Informática 2014 IFRS” produziu um curta mais explicativo, vídeo 
sobre o modelo espiral, que pode ser conferido no link abaixo:
h t t p s : / / w w w . y o u t u b e . c o m / w a t c h ? v = m r 3 v V w G g z C Q & a b _
channel=Inform%C3%A1tica2014IFRS
Isto acontece na prática
Uma empresa tem trabalhado em um projeto com o objetivo desenvolver um sistema 
de um e-commerce. 
Caso opte por utilizar o modelo cascata haverá apenas uma reunião com o cliente, na 
qual documentará os requisitos solicitados e os apresentará para validação do cliente. 
Uma vez aceitos os requisitos, o e-commerce é criado e o cliente apenas o visualiza 
após todos os testes terem sido executados e o projeto encerrado.
Caso se opte pelo modelo prototipação, antes de iniciar o desenvolvimento os profissionais 
criarão as telas do e-commerce e as mostrarão para o cliente. O cliente deverá interagir 
como se estivesse usando o software real para, então, aprovar o desenvolvimento ou 
sugerir alterações.
No caso de utilizar o modelo espiral será feito inicialmente o protótipo de uma tela de 
cadastro dos produtos a ser avaliada pelo cliente e depois desenvolvida. Em seguida, 
será feita uma tela para compras, também avaliada pelo cliente e, então, desenvolvida, 
e assim sucessivamente.
Além da prototipação a cada etapa serão analisados os riscos possíveis em cada etapa, 
por exemplo, ter um estagiário que está se formando e que precisará deixar a equipe, 
uma mudança de versão de alguma tecnologia durante o processo, entre outros riscos 
previsíveis que, nesse modelo, são analisados previamente a cada ciclo.
https://www.youtube.com/watch?v=mr3vVwGgzCQ&ab_channel=Inform%C3%A1tica2014IFRS
https://www.youtube.com/watch?v=mr3vVwGgzCQ&ab_channel=Inform%C3%A1tica2014IFRS
FACULDADE CATÓLICA PAULISTA | 24
ENGENHARIA DE SOFTWARE
PROF. FRANCISCO LUÍS BORGHI NASCIMENTO
AULA 5
INTRODUÇÃO AOS MÉTODOS 
ÁGEIS
O desenvolvimento ágil envolve mudanças rápidas e prioriza, às vezes, agilidade frente 
à qualidade. Após fazer um planejamento de etapas de requisitos é comum ter se deparar 
com mudanças dos próprios requisitos e isso é aceito neste método de desenvolvimento, 
pois não impossível antever todas as necessidades do mercado, visto que elas mudam 
frequentemente e, em alguns casos, os requisitos mudam depois da entrega do projeto 
(MASCHIETTO, 2020).
 
Fonte: https://appdevelopermagazine.com/scripts/resize/?path=/images/news_images/Rad-Tools-App-Developer-Magazine_mjcpjdmt.jpg&width=700
 
O desenvolvimento ágil é feito em equipes onde os processos são feitos em espiral e 
priorizam conversas em detrimento da documentação. Nesta metodologia é mais importante 
a funcionalidade do software do que a documentação, bem como satisfazer as necessidades 
do cliente do que seguir um plano. No método ágil, os colaboradores têm perfil motivado, 
as entregas são semanais e não mensais o que facilita o acompanhamento da satisfação 
do cliente.
https://appdevelopermagazine.com/scripts/resize/?path=/images/news_images/Rad-Tools-App-Developer-Magazine_mjcpjdmt.jpg&width=700
FACULDADE CATÓLICA PAULISTA | 25
ENGENHARIA DE SOFTWARE
PROF. FRANCISCO LUÍS BORGHI NASCIMENTO
No ano 2001, em Utah, nos Estados Unidos, 17 profissionais que praticavam metodologias 
ágeis se reuniram para praticar Snowbird e conversar sobre métodos de planejamento de 
software. Como resultado ocorreu a criação de um documento chamado de “Manifesto Ágil” 
que possui quatro valores. Estes valores priorizam:
• as pessoas frente aos processos, pois objetiva favorecer relacionamentos no ato da 
construção do software;
• ofuncionamento versus documentação que favorece a funcionalidade da criação de 
software e não somente o design;
• a colaboração do cliente, a funcionalidade da criação de software, que favorece a interação 
contínua com o cliente, a fim de compreender seus desejos e anseios com mais precisão;
• consertar problemas e se adaptar a mudanças que favorece uma construção dinâmica 
e não engessada, onde consertar problemas é mais importante que manter a burocracia.
O fato de deixar o trabalho mais funcional e orgânico não significa, necessariamente, 
deixar de se organizar ou de documentar. Considera-se que os profissionais da área de 
programação ficam sobrecarregados e que a área de tecnologia é estressante. Há muita 
demanda para pouco profissional e a tendência é aumentar a necessidade de profissionais.
Fonte: Maschietto (2020)
FACULDADE CATÓLICA PAULISTA | 26
ENGENHARIA DE SOFTWARE
PROF. FRANCISCO LUÍS BORGHI NASCIMENTO
5.1 Rapidez nas entregas
As entregas dos produtos podem ser agilizadas pelo fato do cliente acompanhar o 
desenvolvimento em cada etapa do projeto. Essa forma é entendida como a mais válida 
porque as empresas que adotam essa tecnologia acreditam que é melhor validar o projeto 
em cada etapa diretamente com o cliente em vez de gastar tempo e dinheiro.
Durante o desenvolvimento do software ele passa por diversos processos e fica em contato 
com o cliente para validação, é difícil não considerar que a sua qualidade melhorará. 
5.2 Independência e produtividade para a equipe
Uma consequência positiva é ter uma maior rentabilidade da equipe. Afinal, não será 
necessário ter preocupações burocráticas com documentações longas e complicadas, 
contratos e ferramentas rígidas que possam atrapalhar uma resposta rápida para imprevistos.
Desse modo, a equipe pode se tornar mais independente para lidar com os eventuais 
problemas de um projeto e aprender como solucioná-los. O resultado é mais produtividade 
e menos perda de tempo como poderia ocorrer com o uso das metodologias tradicionais.
5.3 Flexibilização dos softwares
É muito comum que os clientes peçam para que haja alterações no produto. Por isso, a 
cada versão recebida é possível que ele envie sugestões de alterações e os responsáveis 
pelas alterações já comecem a fomentá-las para as próximas fases do projeto. Para que uma 
mudança possa ocorrer e o cliente possa sair mais satisfeito, não é preciso que isso ocorra 
apenas na etapa final do projeto, como ocorria antes, flexibilizando o software desenvolvido.
5.4 Bom gerenciamento do risco
A constante comunicação com o cliente facilidade de alterar o que ele pede tornam 
mais fácil gerenciar os riscos de um projeto pelo fato de o cliente ter um maior controle e a 
possibilidade de identificar os possíveis problemas que um produto pode apresentar podendo 
reportá-los aos desenvolvedores para que sejam solucionados rapidamente.
As metodologias ágeis propõem economizar tempo na execução de diferentes atividades. 
Apresentam um interesse em oferecer um desenvolvimento constante até que sejam 
alcançados os resultados. Abaixo algumas características que merecem ser salientadas:
FACULDADE CATÓLICA PAULISTA | 27
ENGENHARIA DE SOFTWARE
PROF. FRANCISCO LUÍS BORGHI NASCIMENTO
5.5 Interatividade
O desenvolvimento deve focar no relacionamento entre as pessoas que devem se envolver 
bem entre si. Além da relação com os processos, as pessoas devem se conectar trabalhando 
em conjunto para a produção dos mesmos efeitos.
Toda a equipe deve atuar com consistência a fim de conquistar resultados satisfatórios. O 
cliente também deve integrar essa interatividade, assegurando a realização das expectativas.
5.6 Iteratividade
Atenção às palavras parecidas! Interatividade e iteratividade não são a mesma coisa, pois 
a iteratividade se relaciona com as entregas incrementais cujas ocorrências são em períodos 
menores. Como foi visto nos métodos convencionais, o comum é as etapas ocorrerem em 
cascatas e os resultados só são entregues no final de tudo.
Na gestão ágil uma etapa influencia a seguinte. Assim, as entregas se realizam em pequenos 
períodos. O cliente pode acompanhar todo o processo, não se limita a analisar os resultados.
 
Fonte: https://bsbr.com.br/wp-content/uploads/2018/03/31823189.png
https://bsbr.com.br/wp-content/uploads/2018/03/31823189.png
FACULDADE CATÓLICA PAULISTA | 28
ENGENHARIA DE SOFTWARE
PROF. FRANCISCO LUÍS BORGHI NASCIMENTO
5.7 A flexibilidade
As metodologias ágeis também se destacam por sua flexibilidade. Já os métodos 
convencionais são muito rígidos, pois é importante manter-se dentro do que foi planejado, 
do escopo original.
A flexibilidade a palavra de ordem nos métodos ágeis. A equipe deve se preparar para 
imprevistos e modificações, conforme se tornem necessárias. Algumas vezes, isso significa 
descobrir boa parcela do projeto justamente durante seu desenvolvimento e sua execução. 
5.8 A transparência
Para garantir a satisfação dos clientes e para garantir o sucesso da equipe na execução, 
a transparência deve ser maximizada. Ainda que seja relevante nos métodos tradicionais, 
nas metodologias ágeis ela se torna ainda mais importante.
FACULDADE CATÓLICA PAULISTA | 29
ENGENHARIA DE SOFTWARE
PROF. FRANCISCO LUÍS BORGHI NASCIMENTO
AULA 6
MÉTODOS ÁGEIS - EXEMPLOS
Existem vários tipos de métodos ágeis. Diante da diversidade e quantidade serão citados 
e exemplificados os mais comuns e utilizados. 
Durante a década de 1990 houve a influência de vários métodos ágeis. Por exemplo: 
Desenvolvimento Incremental, DSDM (Metodologia de Desenvolvimento de Sistemas 
Dinâmicos), Crystal Clear, FDD (Desenvolvimento Direcionado a Funcionalidade), XP (Extrem 
Programming) e Scrum.
 
Fonte: Maschietto (2020)
O desenvolvimento incremental faz a construção do sistema por etapas, de incremento 
em incremento. Geralmente, concluindo uma etapa e após o cliente dar alguns feedbacks. 
Cada etapa é uma parte inteira: por exemplo, uma página de login link com acesso a banco 
de dados é um incremento (MASCHIETTO, 2020). 
6.1 Metodologia de Desenvolvimento de Sistemas Dinâmicos 
(DSDM)
 
Usado em situações onde o tempo e a verba são limitados. De acordo com Cruz (2018, 
p. 316 apud MASCHIETTO)
FACULDADE CATÓLICA PAULISTA | 30
ENGENHARIA DE SOFTWARE
PROF. FRANCISCO LUÍS BORGHI NASCIMENTO
[...] tem um conceito mais próximo a um framework do que um método 
propriamente dito, sua ênfase foca a criação de protótipos que posteriormente 
evoluem para o sistema, e para isso é utilizada muito fortemente a colaboração 
próxima com o cliente.
 
Fonte: https://flowup.me/blog/wp-content/uploads/2020/02/Agile2-1200x630.png
 Este método busca entregar pelo menos 80% do projeto em até 20% do tempo 
disponibilizado. Ele é composto por três fases: a fase do pré-projeto (onde se elabora o 
orçamento), a fase do ciclo de vida (onde se analisa a viabilidade) e a fase do pós-projeto 
(onde ocorrem as alterações), como observado na figura abaixo:
 
Fonte: Maschietto (2020)
A DSDM é recomendada quando os projetos são urgentes quando os projetos são formados 
por uma nova tecnologia e precisam ser acompanhados de testes do usuário, ou quando 
https://flowup.me/blog/wp-content/uploads/2020/02/Agile2-1200x630.png
FACULDADE CATÓLICA PAULISTA | 31
ENGENHARIA DE SOFTWARE
PROF. FRANCISCO LUÍS BORGHI NASCIMENTO
remetem a um lançamento de produto com data marcada. Em metodologias tradicionais, o 
cronograma e o orçamento são abertos e o escopo é fechado; já a DSDM tem cronograma 
e orçamento fechados, mas o roteiro é aberto.
6.2 Crystal Clear
Atende vários tipos de projetos e tem como valor a comunicação com o cliente, bem como 
o relacionamento do desenvolvedor com o cliente. Com o objetivo de reduzir o tempo, este 
método evita a criação de ferramentas complexas que não serão utilizadas. Este método 
busca diferenciar a metodologia específica conforme a natureza de cada projeto e permite 
que os desenvolvedores se manifestem quando algo os incomodar.Como sugere o nome, 
o método consiste um “cristal em figura” elaborado pela gestão mostrando uma escala de 
cores, onde as cores variam de acordo com nível de criticidade e com o tamanho da equipe. 
 
Fonte:https://0901.static.prezi.com/preview/v2/sr47ujcyyzhyjfvorncv7r3x3t6jc3sachvcdoaizecfr3dnitcq_1_0.png
 
Quanto mais escuro o cristal, mais crítico de fazer é o software ou projeto. Nas cores 
claras (branco e amarelo) atestam que os softwares ou projetos serão simples e poucas 
pessoas serão necessárias. Projetos alaranjados ou até vermelhos demandam mais pessoas 
e são mais arriscados.
No exemplo hipotético desenhado abaixo, C significa “confortável” e D significa “baixo 
custo”, E significa “alto custo”, e L significa “risco de vida”. Os números indicam o número 
de funcionários.
https://0901.static.prezi.com/preview/v2/sr47ujcyyzhyjfvorncv7r3x3t6jc3sachvcdoaizecfr3dnitcq_1_0.png
FACULDADE CATÓLICA PAULISTA | 32
ENGENHARIA DE SOFTWARE
PROF. FRANCISCO LUÍS BORGHI NASCIMENTO
 
Fonte: Maschietto (2020)
6.3 Feature-driven development (FDD)
Fragmenta os projetos de gestão e de software em features (funcionalidades). Concebida 
na década de 1990 tem como características os pontos (MASCHIETTO, 2020):
• elaboração de lista de tarefas de funcionalidades onde cada passo tem foco em alguma 
funcionalidade do software;
• planejamento voltado ao método incremental por funcionalidade. Por exemplo: o primeiro 
item a ser feito é a área do cliente completa; o segundo item será o carrinho de compras 
completo; o terceiro item será o catálogo completo, e assim por diante;
• criar um design que simplifica a navegação e promove a experiência do usuário;
• testar cada função em detrimento de testar uma interface, por exemplo.
6.4 Extremming Programing (XP)
Criado em 1996 possui como princípios básicos: qualidade, mudanças incrementais, 
feedback rápido e abraçar mudanças. Segundo Maschietto (2020), a metodologia possui 
algumas práticas nos quais serão citadas algumas delas:
FACULDADE CATÓLICA PAULISTA | 33
ENGENHARIA DE SOFTWARE
PROF. FRANCISCO LUÍS BORGHI NASCIMENTO
• Jogos de planejamento: no início da semana os clientes e developers (desenvolvedores) 
se reúnem parar priorizar funcionalidades que serão entregues no final da semana. Cada 
versão deve ser pequena.
• Propriedade coletiva: qualquer pessoa do time pode usar o código do programa sem 
precisar de permissão para alterar, assim todos têm a oportunidade de conhecer o código 
inteiro e se familiarizar com ele. Isso é muito importante para agilizar manutenções.
• Teste de usuário: em equipes pequenas são realizados testes do software por clientes 
e desenvolvedores da empresa para avaliar sua qualidade.
• Ritmo sustentável: as equipes devem trabalhar 40 horas, divididas em 8 horas por dia, 
sem sobrecarga.
• Equipe inteira: as reuniões devem ser em pé e devem ser rápidas. 
• Programação em par: um desenvolvedor mais experiente fica com um novato, o novato 
codifica e o mais experiente programa. O benefício deste método é que ele é revisado por 
duas pessoas.
• Padronizações de código: a equipe de dev (developers) determina regras de codificação 
de salvamento, bem como as boas práticas que devem ser seguidas. Assim, parecerá que 
foi a mesma pessoa que editou o código, ele ficará com uma “cara” única.
• Desenvolvimento orientado a teste: elaborar códigos de forma que sejam capazes de ser 
testados por software de teste como Imeter (um software que mede desempenho), Selenium 
(um software que mede erros de sites) etc.
• Refatoração: é o processo de otimizar a estrutura do código sem alterar o seu 
comportamento externo para o usuário final.
• Integração contínua: integrar alterações de forma contínua, sem esperar uma semana, 
por exemplo. Permite saber a real situação do software da programação.
• Entregas curtas: entregar pequenos pedaços para o cliente corrigir e avaliar, aumentando 
a probabilidade de acertar o todo.
• Metáfora: entender a linguagem e as expressões do cliente.
• Design simples: o código deve ter exatamente o que o cliente pediu.
FACULDADE CATÓLICA PAULISTA | 34
ENGENHARIA DE SOFTWARE
PROF. FRANCISCO LUÍS BORGHI NASCIMENTO
Isto acontece na prática
Aline Barbosa escreveu um artigo no site Consumidor Moderno que exemplifica a 
metodologia ágil na prática:
“Um processo de transformação digital bem-sucedido é capaz de derrubar 
mitos, o maior de todos e que, em geral, leva as organizações ao fracasso – 
é acreditar que o emprego dos métodos ágeis e a adoção de soluções em 
nuvem implicam no automático descarte das práticas e disciplinas mais 
consolidadas e tradicionais de projetos e de atividades de sustentação.
‘Quando as metodologias ágeis são aplicadas, não pelo processo em si, mas 
com o objetivo de gerar resultados de valor para a empresa e para seus 
clientes, aos poucos, a busca pela automação e otimização de processos 
torna-se parte do dia a dia, inclusive internos’ aponta Marcio Drumond, diretor 
de P&D Tecnologia do PagSeguro PagBank.”
Fonte: BARBOSA (2020)
Disponível em: https://www.consumidormoderno.com.br/2020/09/18/resultados-
conquistados-pelas-empresas-com-as-metodologias-ageis/
https://www.consumidormoderno.com.br/2020/09/18/resultados-conquistados-pelas-empresas-com-as-metodologias-ageis/
https://www.consumidormoderno.com.br/2020/09/18/resultados-conquistados-pelas-empresas-com-as-metodologias-ageis/
FACULDADE CATÓLICA PAULISTA | 35
ENGENHARIA DE SOFTWARE
PROF. FRANCISCO LUÍS BORGHI NASCIMENTO
AULA 7
MÉTODOS ÁGEIS - SCRUM
Scrum é um método para organização de equipes criado por Schwaber e Sutherland onde um 
grupo de pessoas se organiza para desenvolver soluções para problemas complexos gerando 
produtos com alto valor para as organizações. O Scrum vem sendo adotado amplamente 
por equipes de desenvolvimento de software ao redor do mundo, pois sua utilização tem 
trazido resultados expressivos. 
Os princípios oferecem condições de aplicar um processo de desenvolvimento que envolva 
requisitos, análise, projeto, evolução e entrega.
 
Fonte: https://proj4.me/wp-content/uploads/2018/04/Base-imagem-destacada-blog.png
 
Cohn (apud MASCHIETTO, 2017) enfatiza que a adoção bem-sucedida e duradoura do 
Scrum depende de cinco principais atividades:
1. reconhecimento que o processo atual não está mais permitindo a entrega dos resultados 
esperados;
2. desejo de adotar o Scrum como meio de resolver os problemas atuais; 
3. aptidão da equipe para obter êxito com o Scrum; 
https://proj4.me/wp-content/uploads/2018/04/Base-imagem-destacada-blog.png
FACULDADE CATÓLICA PAULISTA | 36
ENGENHARIA DE SOFTWARE
PROF. FRANCISCO LUÍS BORGHI NASCIMENTO
4. promoção do Scrum por meio de compartilhamento de boas práticas para reconhecer 
o sucesso da aplicação do método;
5. transferência das implicações do uso de Scrum para toda a empresa.
O elemento-chave que faz com que o processo do Scrum seja executado é um espaço 
de tempo definido para execução de um conjunto de atividades, denominado por Sprint.
7.1 Sprint
O Sprint representa um intervalo de tempo no qual um conjunto de atividades deve ser 
executado. 
As funcionalidades a serem implementadas em um projeto são mantidas em uma lista 
que é conhecida como “Product Backlog”. No início faz-se um Sprint Planning Meeting, ou seja, 
uma reunião de planejamento na qual o cliente prioriza os itens do Product Backlog. Assim, 
a equipe seleciona as atividades que ela será capaz de implementar durante o Sprint que se 
inicia. As tarefas alocadas em um Sprint são transferidas do Product Backlog para o Sprint 
Backlog.
A cada dia de uma Sprint a equipe faz uma breve reunião (normalmente de manhã), 
chamada Daily Scrum. O objetivo é aprimorar conhecimento sobre o que foi feito no dia 
anterior, identificar impedimentos e priorizar o trabalho do dia que se inicia.
Ao final de um Sprint a equipe apresenta as funcionalidades implementadas em uma 
reunião. Finalmente faz-se uma Sprint Retrospective e a equipe parte para o planejamentodo próximo Sprint. Assim reinicia-se o ciclo.
 
Fonte: https://www.tecnicon.com.br/upload/public/Blog/post-scrum.png
https://www.tecnicon.com.br/upload/public/Blog/post-scrum.png
FACULDADE CATÓLICA PAULISTA | 37
ENGENHARIA DE SOFTWARE
PROF. FRANCISCO LUÍS BORGHI NASCIMENTO
Algumas regras precisam ser consideradas em relação a uma Sprint.
• Uma Sprint não deve ter seu término adiado. Ao finalizar, mesmo com o trabalho não 
concluído deve se formalizar o encerramento. Nos eventos de encerramento da Sprint existe 
previsão para tratar do trabalho não concluído.
• Após o início da Sprint as mudanças só podem ser executadas se não colocarem em 
risco o objetivo do processo.
• As prioridades podem mudar a qualquer momento, mas quanto maior for a Sprint, maior 
a chance de isso ocorrer. Por isso, a maioria dos times prefere utilizar Sprints com tempo 
médio de 15 dias de trabalho.
 A Retrospectiva da Sprint é o momento em que a equipe terá oportunidade de inspecionar 
a si mesmo e traçar um plano de melhorias para serem aplicadas na próxima Sprint. O objetivo 
da retrospectiva da Sprint é incentivar a continuidade de práticas que foram benéficas para o 
time e o andamento da Sprint. O propósito da Retrospectiva da Sprint é (MASCHIETTO, 2017):
• inspecionar como a Sprint ocorreu em relação às pessoas, aos relacionamentos, aos 
processos e às ferramentas;
• identificar e ordenar os principais itens que foram bem e as potenciais melhorias;
• traçar um planejamento para implementar melhorias no modo que o Time Scrum faz 
seu trabalho.
Ao final, a equipe terá identificado as melhorias que serão implementadas na próxima Sprint.
 
7.2 Backlog do produto
O backlog do produto é composto por todas as necessidades de desenvolvimento do 
produto através da visão do cliente. O backlog do produto é um documento vivo e nunca estará 
completo. O Project Owner (PO) interagirá constantemente com as partes interessadas do 
produto a fim de manter este backlog priorizado, atualizado e evoluindo. A seguir, um exemplo 
de um backlog de produto de um software de controle de estoque. Nele estão listados uma 
série de requisitos funcionais que o software deve atender.
FACULDADE CATÓLICA PAULISTA | 38
ENGENHARIA DE SOFTWARE
PROF. FRANCISCO LUÍS BORGHI NASCIMENTO
 
Fonte: Maschietto (2017)
7.3 Backlog da Sprint
O backlog da Sprint é o conjunto de itens do backlog do produto selecionados para serem 
desenvolvidos durante a Sprint. Somente o time de desenvolvimento tem autonomia para 
alterar os itens de backlog durante uma Sprint. A seguir, observar-se uma lista de itens do 
backlog do produto, selecionadas para serem desenvolvidas, por exemplo, na Sprint 001. 
A seleção ocorre na reunião de planejamento mediante a análise da capacidade de entrega 
da equipe versus os itens do backlog do produto em ordem de prioridade.
 
Fonte: Maschietto (2017)
7.4 Quadro Kanban
Ferramenta de gestão visual que representa a característica de transparência do Scrum. 
Através de um quadro de tarefas, que pode ser físico ou digital, a equipe visualiza os itens a 
serem desenvolvidos e seu andamento. A divisão das colunas do quadro geralmente é entre 
“Backlog”, “A fazer”, “Fazendo” e “Pronto”. Estas divisões também podem ser personalizadas de 
acordo com a necessidade da equipe, mas devem seguir a tendência do ágil: A simplicidade.
 
FACULDADE CATÓLICA PAULISTA | 39
ENGENHARIA DE SOFTWARE
PROF. FRANCISCO LUÍS BORGHI NASCIMENTO
Fonte: https://blog.trello.com/hs-fs/hubfs/Imported_Blog_Media/make_scrum_visual-1024x512-2.jpg?width=1024&height=512&name=make_scrum_visual-1024x512-2.jpg
7.5 Definição de pronto
Conceito é muito importante numa equipe Scrum. Podem existir vários entendimentos do 
que seja “Pronto” para um item do Sprint backlog. Para um determinado membro do time 
a definição de pronto pode significar que o item foi acoplado ao código fonte sem causar 
erros. Já na visão de um testador pode significar “sem bugs”. E na visão de um analista de 
negócios que atende às necessidades do cliente (MASCHIETTO, 2017).
https://blog.trello.com/hs-fs/hubfs/Imported_Blog_Media/make_scrum_visual-1024x512-2.jpg?width=1024&height=512&name=make_scrum_visual-1024x512-2.jpg
FACULDADE CATÓLICA PAULISTA | 40
ENGENHARIA DE SOFTWARE
PROF. FRANCISCO LUÍS BORGHI NASCIMENTO
Isto acontece na prática
Provavelmente, ao ouvir falar de Scrum você tenha lembrado de métodos ágeis, não 
é mesmo?
Muitas vezes há confusão entre as metodologias. De forma resumida, o Scrum é um 
tipo de metodologia ágil. 
Métodos ágeis são um conjunto de metodologias e práticas alternativas à gestão 
de projetos tradicional e têm como objetivo a rapidez e a adaptação constante dos 
processos. 
Esses métodos nasceram no desenvolvimento de software e na tecnologia da informação, 
mas hoje já são utilizados em projetos de diferentes áreas.
Isto está na rede
O canal MindMaster tem um vídeo interessante sobre o Scrum que vai ajudar no processo 
de aprendizagem.
https://www.youtube.com/watch?v=XfvQWnRgxG0&ab_channel=MindMaster
https://www.youtube.com/watch?v=XfvQWnRgxG0&ab_channel=MindMaster
FACULDADE CATÓLICA PAULISTA | 41
ENGENHARIA DE SOFTWARE
PROF. FRANCISCO LUÍS BORGHI NASCIMENTO
AULA 8
REQUISITOS DE SOFTWARE
O levantamento de requisitos pode ajudar a evitar a frustração de clientes ao final de um 
projeto de software. Na maioria dos casos, pelo fato de o cliente não saber muito bem do que 
precisa fica mais difícil criar um projeto que satisfaça as suas necessidades. A identificação 
de requisitos no início do projeto é muito importante para um melhor desenvolvimento. 
 
Fonte: https://miro.medium.com/max/1000/0*VFQLo1RU-d12SHtV.jpg
Um requisito pode ser uma condição, uma capacidade, uma função, um objetivo, uma 
propriedade ou uma restrição que caracterize um sistema e satisfaça uma regra de negócio 
ou contrato.
 
https://miro.medium.com/max/1000/0*VFQLo1RU-d12SHtV.jpg
FACULDADE CATÓLICA PAULISTA | 42
ENGENHARIA DE SOFTWARE
PROF. FRANCISCO LUÍS BORGHI NASCIMENTO
8.1 Técnicas para coleta de dados
As particularidades de um software estão diretamente ligadas a sua complexidade que vão 
desde as suas funcionalidades até os recursos necessários para desempenhar sua função. 
O desenvolvimento de um sistema exige que algumas etapas sejam seguidas e executadas 
com lógica. Um planejamento de um software tem como uma de suas principais atividades 
a obtenção dos requisitos, ou seja, todas as funcionalidades do software.
A coleta é crucial para todas as demais etapas, pois se a equipe desenvolve todo o 
software e no final ele não atende às necessidades do cliente todo processo pode ser perdido. 
Diante disso, essa etapa tem também cunho investigativo, no qual a equipe, além de ter que 
desenvolver o software deve saber extrair do cliente tudo que ele precisa. Nem sempre o 
cliente compreende o processo de desenvolvimento do software não tendo noção de como 
deve expor ideias e, muito menos, saberá relacionar o trabalho que será empenhado em seu 
projeto com os custos e os prazos finais.
Algumas técnicas acabaram sendo elaboradas para auxiliar a equipe de desenvolvimento 
neste processo. Conforme Pressman e Maxim (apud MORAIS, 2017), muitas abordagens 
para a coleta colaborativa de requisitos foram propostas. Cada uma faz uso de um cenário 
ligeiramente diferente, porém todas aplicam alguma variação das seguintes diretrizes básicas:
• As reuniões (reais ou virtuais) são conduzidas com a participação tanto dos Engenheiros 
de software quanto de outros envolvidos.
• São estabelecidas regras para a preparação e a participação. É sugerida uma agenda 
suficientemente formal para cobrir todos os pontos importantes; porém, suficientemente 
informal para estimular o fluxo livre de ideias.
• Um “facilitador” (pode ser um cliente, um desenvolvedor ou uma pessoa de fora) dirige 
a reunião.
• É utilizado um “mecanismo de definições” (planilhas, flip charts, adesivos de parede ou 
um boletim eletrônico, salas de bate-papo ou fórunsvirtuais).
FACULDADE CATÓLICA PAULISTA | 43
ENGENHARIA DE SOFTWARE
PROF. FRANCISCO LUÍS BORGHI NASCIMENTO
 
Fonte: https://miro.medium.com/max/3840/1*4QW7Z3ECLUJvG0Lj6vZLDw.jpeg
A coleta de requisitos é o processo de reunir informações sobre o sistema requerido e os 
sistemas existentes e separar dessas informações os requisitos de usuário e de sistema. 
Para isso existem algumas formas de executar tal ação (MORAIS, 2017):
8.2 Entrevistas
Podem ser de dois tipos: fechadas, onde um conjunto predefinido de perguntas é respondido 
pelo cliente e entrevistas abertas, onde a equipe desenvolve uma série de questões com o 
intuito de compreender as necessidades do cliente.
8.3 Cenários
Um cenário começa por meio de um rascunho da interação. Durante o processo de 
lançamento são adicionados detalhes ao esboço para criar uma descrição completa dessa 
interação. Um cenário pode incluir uma descrição do que o sistema e os usuários esperam 
quando o cenário se iniciar, do fluxo normal de eventos no cenário e do que pode dar errado 
e como isso é tratado. Incluem também informações sobre outras atividades que podem 
acontecer ao mesmo tempo uma descrição do estado do sistema quando o cenário acaba.
https://miro.medium.com/max/3840/1*4QW7Z3ECLUJvG0Lj6vZLDw.jpeg
FACULDADE CATÓLICA PAULISTA | 44
ENGENHARIA DE SOFTWARE
PROF. FRANCISCO LUÍS BORGHI NASCIMENTO
8.4 Casos de uso
Trazem definições estabelecidas pela linguagem de modelagem unificada (UML, do inglês 
Unified Modeling Language). São documentados por um diagrama de casos de uso de alto nível. 
Identificam as interações individuais entre o sistema e seus usuários ou outros sistemas.
8.5 Etnografia
Técnica de observação que pode ser usada para entender os processos operacionais em 
que um analista faz uma imersão no ambiente de trabalho em que o sistema será usado. 
O trabalho diário passa por diversas observações, nas quais contêm anotações sobre as 
tarefas em que os participantes estão envolvidos são realizadas.
8.6 Requisitos funcionais e não funcionais
Um software necessita de recursos técnicos para ser executado, ou seja, ele precisa de um 
computador para operar. Para isso define-se quais restrições e qual poderá ser o limite de 
alcance que o software que está sendo desenvolvido terá. Um requisito traz especificações de 
como deve agir para que o objetivo de sua função seja atingido. Dessa forma, as necessidades 
do cliente são separadas em duas modalidades: Requisitos Funcionais e Requisitos Não 
Funcionais:
 
8.7 Requisitos funcionais 
“São declarações de serviços que o sistema deve fornecer, de como o sistema deve reagir 
a entradas específicas e de como o sistema deve se comportar em determinadas situações. 
Em alguns casos, também podem explicitar o que o sistema não deve fazer” (SOMMERVILLE 
apud MORAIS, 2017, p.96).
Um software para uma plataforma de móvel, por exemplo, terá diferentes requisitos de 
um software que roda em um navegador.
Portanto, requisitos funcionais preocupam-se com a funcionalidade e os serviços do 
sistema, ou seja, as funções que o sistema deve fornecer para o cliente e como o sistema 
se comportará em determinadas situações. Segue abaixo alguns exemplos de requisitos 
funcionais:
FACULDADE CATÓLICA PAULISTA | 45
ENGENHARIA DE SOFTWARE
PROF. FRANCISCO LUÍS BORGHI NASCIMENTO
• O Sistema deve cadastrar médicos profissionais (entrada).
• O Sistema deve emitir um relatório de clientes (saída).
• O Sistema deve passar um cliente da situação “em consulta” para “consultado” quando 
o cliente terminar de ser atendido (mudança de estado)
• O cliente pode consultar seus dados no sistema.
FACULDADE CATÓLICA PAULISTA | 46
ENGENHARIA DE SOFTWARE
PROF. FRANCISCO LUÍS BORGHI NASCIMENTO
AULA 9
REQUISITOS DE SOFTWARE - 
CONTINUAÇÃO
9.1 Requisitos não funcionais 
“Pode ser descrito como um atributo de qualidade, de desempenho, de segurança ou como 
uma restrição geral em um sistema” (PRESSMAN; MAXIM apud MORAIS). Esses requisitos 
abrangem muito mais atributos que podem estar associados a outras áreas do software.
Para Sommerville (2011), os requisitos não funcionais, como desempenho, proteção ou 
disponibilidade, por dependerem de recursos de hardware, especificam ou restringem as 
características do sistema. Eles podem afetar a arquitetura de um sistema em vez de apenas 
atingir componentes individuais. A figura abaixo traz um diagrama com alguns dos requisitos 
não funcionais:
 
Fonte: Sommerville (2011)
Os requisitos não funcionais definem propriedades e restrições do sistema como tempo, 
espaço, linguagens de programação, versões do compilador, Banco de Dados, Sistema 
Operacional, método de desenvolvimento etc. Os requisitos não funcionais são geralmente 
FACULDADE CATÓLICA PAULISTA | 47
ENGENHARIA DE SOFTWARE
PROF. FRANCISCO LUÍS BORGHI NASCIMENTO
mensuráveis e assim deve-se associar uma medida ou referência para cada requisito não 
funcional.
A figura abaixo mostra algumas propriedades métricas:
Fonte: Devmedia (2021)
Segue abaixo alguns exemplos de requisitos não funcionais:
• O sistema deve carregar um relatório em no máximo 5 segundos.
• Todas as telas devem seguir o padrão especificado pelo setor ABC.
• O sistema deve ser implementado em Pyton.
 Existe um sistema de classificação de requisitos chamada FURPS+, iniciais dos nomes 
abaixo, que ajudam os analistas a identificar o propósito das informações obtidas com os 
usuários:
• Functionality: é todo o aspecto funcional do sistema sendo desenvolvido.
• Usability: indica o tempo de treinamento para um usuário se tornar produtivo e também 
auxilia a aferir o tempo de duração desejado para determinada operação no sistema.
• Reliability: tempo permitido para indisponibilidade quando ocorre uma falha. Bugs devem 
ser categorizados por nível de impacto na confiabilidade do sistema.
• Performance: tempo de resposta para uma transação, uso de recursos: memória, espaço 
em disco, comunicação etc.
FACULDADE CATÓLICA PAULISTA | 48
ENGENHARIA DE SOFTWARE
PROF. FRANCISCO LUÍS BORGHI NASCIMENTO
• Supportability: indica o padrão de codificação, convenção de nomes, classes, utilitários 
de manutenção etc.
• Plus (+): indica Outros como Design, implementação, interface, físicos etc.
9.2 Requisitos no Ciclo de Vida do Projeto
Os requisitos devem ser considerados durante todo o ciclo de vida de desenvolvimento 
do software. As etapas onde os requisitos são usados durante o ciclo do projeto estão 
descritas abaixo:
• Definição de critérios de aceitação e validação.
• Definição sobre “o quê” o sistema deve fazer.
• Teste e Verificação.
• Informações para gerenciamento de mudanças.
• Alocação de tarefas para a equipe.
• Estimativa de custos.
• Acompanhamento e controle do andamento do projeto.
9.3 Identificação das regras de negócio
A identificação das regras de negócio que fazem parte do contexto do projeto, compartilham 
das mesmas técnicas da coleta de dados, até mesmo porque é o momento em que os dados 
estão sendo coletados e as restrições do sistema estão sendo impostas, automaticamente, 
em que é necessário se ter conhecimento, também, das regras de negócio do cliente.
Podem ser usadas várias técnicas diferentes para obter as informações necessárias para 
criar o modelo de negócio, tais como o uso de formulários e questionários no processo de 
levantamento de requisitos e, consequentemente, das regras de negócio. A definição de uma 
regra de negócio requer a especificação de alguns detalhes operacionais, dentre os quais 
destacam-se (MORAIS, 2017):
• Quem invoca uma regra: esta informação geralmente é descrita em um caso de uso ou 
em uma descrição de processo do negócio.
• Quando a regra é executada: normalmente isto é descrito por um evento, caso de uso 
ou descrição de processo do negócio.
FACULDADE CATÓLICA PAULISTA | 49
ENGENHARIA DE SOFTWARE
PROF. FRANCISCO LUÍS BORGHI NASCIMENTO
• Onde a regra é executada: esta decisão é pertinente ao design do sistema e, mais 
especificamente, ao empacotamentodo software.
• Como a regra é implementada: também é uma decisão da fase de projeto.
O Quadro abaixo traz características das Regras de Negócios encontradas na prática em 
muitas organizações:
Fonte: Morais (2017)
FACULDADE CATÓLICA PAULISTA | 50
ENGENHARIA DE SOFTWARE
PROF. FRANCISCO LUÍS BORGHI NASCIMENTO
Isto está na rede
Veja no YouTube o vídeo “Gerenciamento de requisitos sem mistério”, do canal de 
Fabrício Laguna, que apresenta um breve resumo sobre os requisitos, assunto em 
destaque neste capítulo.
https://www.youtube.com/watch?v=jajQyzOpLaE&ab_channel=Fabr%C3%ADcioLaguna
https://www.youtube.com/watch?v=jajQyzOpLaE&ab_channel=Fabr%C3%ADcioLaguna
FACULDADE CATÓLICA PAULISTA | 51
ENGENHARIA DE SOFTWARE
PROF. FRANCISCO LUÍS BORGHI NASCIMENTO
AULA 10
MODELAGEM DE SOFTWARE – 
INTRODUÇÃO À UML
Após o levantamento e a análise dos requisitos de software é preciso fazer um projeto de 
como um sistema funcionará internamente. Neste projeto é importante analisar questões 
como arquitetura do sistema linguagens de programação que serão usadas, banco de dados, 
interface gráfica e outros elementos, além de gerar uma descrição computacional do que o 
software irá fazer. Divide-se esta fase em duas partes: projeto da arquitetura (também chamado 
de projeto de alto nível) e projeto detalhado (também chamado de projeto de baixo nível).
 
Fonte: https://www.heflo.com/pt-br/wp-content/uploads/sites/2/2016/07/software-de-modelagem-de-processos-gratuito-1024x688.jpg
Segundo Morais (2017), um projeto de software é uma descrição da estrutura do software 
a ser implementado, dos modelos e das estruturas de dados usados pelo sistema, das 
interfaces entre os componentes do sistema e, às vezes, dos algoritmos usados.
https://www.heflo.com/pt-br/wp-content/uploads/sites/2/2016/07/software-de-modelagem-de-processos-gratuito-1024x688.jpg
FACULDADE CATÓLICA PAULISTA | 52
ENGENHARIA DE SOFTWARE
PROF. FRANCISCO LUÍS BORGHI NASCIMENTO
É importante ressaltar que o projeto é desenvolvido de acordo com as particularidades 
do sistema. Dentre elas, Sommerville (2011 apud MORAIS, 2017) destaca quatro atividades 
que podem ou não fazer parte do processo de projeto de sistemas de informação:
- Projeto de arquitetura: pode ser identificada a estrutura geral do sistema, os componentes 
principais, como subsistemas ou módulos, seus relacionamentos e como eles são distribuídos.
- Projeto de interface: deve ser inequívoca. Com uma interface bem definida, um componente 
pode ser usado de maneira com que outros itens não saibam como ele é implementado.
- Projeto de componente: cada componente do sistema projeta seu funcionamento. Trata-se 
de uma declaração da funcionalidade que se espera implementar, com o projeto específico 
para cada programador. Este modelo de projeto pode ser usado para gerar automaticamente 
uma implementação.
- Projeto de banco de dados: Estruturas de dados do sistema e como eles devem ser 
representados em um banco de dados.
Fonte: https://www.embarcados.com.br/wp-content/uploads/2015/01/imagem-de-destaque-89.png
Entre as décadas de 1970 e 1980 foram desenvolvidos alguns métodos, os quais 
antecederam a Linguagem de Modelagem Unificada (do inglês UML – Unified Modeling 
Language). Ao longo dos anos, o processo de criação de um software passou por diversas 
etapas. 
Todas acompanharam a evolução dos próprios recursos computacionais que foram 
exigindo funcionalidades cada vez melhores implementadas. Uma boa implementação de 
um sistema está relacionada à sua documentação e às definições estabelecidas entre a 
equipe e o cliente. 
https://www.embarcados.com.br/wp-content/uploads/2015/01/imagem-de-destaque-89.png
FACULDADE CATÓLICA PAULISTA | 53
ENGENHARIA DE SOFTWARE
PROF. FRANCISCO LUÍS BORGHI NASCIMENTO
Assim, quanto mais especificados os requisitos melhor, pois o risco de haver má interpretação 
das funcionalidades é reduzido. Uma boa forma de fazer isso é por meio do uso de diagramas, 
os quais mostram por meio gráfico as informações pertinentes sobre um sistema.
 
10.1 Diagramas
O projeto de um software, assim como sua documentação traz os detalhes acerca das 
diversas partes de um software. Um recurso que auxilia a equipe de desenvolvimento, 
principalmente na etapa de documentação e posteriormente de implementação do software 
é o uso de diagramas que são baseados na UML.
Para Fowler (2004 apud MORAIS, 2017) UML é aplicada durante a modelagem, basicamente, 
por três modos. Rascunho, Planta de Software e Linguagem de Programação.
Como rascunho através de diagramas informais, geralmente feitos a mão, para tentar 
elucidar as partes difíceis do problema, explorando o poder das linguagens visuais.
Como planta de software para poder fazer a engenharia reversa de um código já existente, 
ou para engenharia avante, criando códigos baseados no diagrama.
Como linguagem de programação gerando automaticamente um código executável, mas 
não normalmente visto ou modificado por desenvolvedores. Esse uso da UML requer um modo 
prático de diagramar todo o comportamento ou a lógica (provavelmente usando diagramas 
de interação ou estado) e está ainda em desenvolvimento em termos de teoria, ferramentas 
robustas e usabilidade.
Já para Larman (2007 apud MORAIS, 2017) a UML descreve tipos de esboço de diagramas, 
tais como diagramas de classe e diagramas de sequência. A mesma notação UML de diagrama 
de classes pode ser usada para desenhar imagens de conceitos do mundo real ou de classes 
de softwares, por exemplo. Os diagramas podem ser vistos por três perspectivas:
• Perspectiva conceitual – os diagramas são interpretados como descrevendo coisas em 
uma situação do mundo real ou domínio de interesse.
• Perspectiva de especificação (software) – os diagramas (usando a mesma notação 
da perspectiva conceitual) descrevem abstrações de software ou componentes com 
especificações e interfaces, mas nenhum comprometimento com uma implementação 
particular (por exemplo, não especificamente uma classe em C# ou Java).
• Perspectiva de implementação (software) – os diagramas descrevem implementações 
de software em uma tecnologia particular (tal como Java).
FACULDADE CATÓLICA PAULISTA | 54
ENGENHARIA DE SOFTWARE
PROF. FRANCISCO LUÍS BORGHI NASCIMENTO
Isto está na rede
 
Veja no YouTube o vídeo “(Aula 1) Pratica - UML - Diagrama de Classe - (Atributos,Operações 
e Herança)”, do canal Sthefane Soares - Vida Programação, que apresenta explicações 
acerca da concepção de um diagrama de classe por meio de uso de programas 
específicos para criação de diagramas.
https://www.youtube.com/watch?v=9Wdjuds5vPQ&ab_channel=SthefaneSoares-
VidaPrograma%C3%A7%C3%A3o
Isto acontece na prática
 
O desenvolvimento do projeto de software deve ser elaborado a partir de uma detalhada 
Metodologia de Desenvolvimento de Sistemas e ancorado por uma competente NPTO 
(Normas e Padrões Técnicos Operacionais). Tais atividades envolvem muitas pessoas, as 
quais compõem a equipe multidisciplinar do projeto de software. Deve contemplar fases, 
subfases, produtos e pontos de avaliação, de acordo com o consenso dos envolvidos, 
sejam da própria organização, sejam prestadores de serviços.
https://www.youtube.com/watch?v=9Wdjuds5vPQ&ab_channel=SthefaneSoares-VidaPrograma%C3%A7%C3%A3o
https://www.youtube.com/watch?v=9Wdjuds5vPQ&ab_channel=SthefaneSoares-VidaPrograma%C3%A7%C3%A3o
FACULDADE CATÓLICA PAULISTA | 55
ENGENHARIA DE SOFTWARE
PROF. FRANCISCO LUÍS BORGHI NASCIMENTO
AULA 11
UML - DIAGRAMA DE ATIVIDADES
Diagrama comportamental que permite a especificação e a modelagem do comportamento 
do software. O diagrama ilustra, de forma gráfica, como será o funcionamento do software 
e como será a sua execução, além de como será a atuação do sistema no dia a dia do 
negócio no qual ele está inserido.
 
Fonte: https://drawio-app.com/wp-content/uploads/2018/01/uml-activity-diagrams-with-draw.io_.png
Semelhante ao fluxograma utilizado na área da Administração de Empresas, permite que 
se demonstre,do ponto de vista funcional e as atividades que serão realizadas. 
Os principais objetivos são de documentar os aspectos funcionais do programa, demonstrar 
aspectos específicos de alguma rotina, explicitar questões relacionadas aos requisitos 
funcionais e explicar de forma macro o sistema.
O diagrama de atividades é um dos mais completos diagramas comportamentais da UML. 
Ele permite visualizar detalhadamente os fluxos do sistema no que diz respeito às ações que 
podem ser feitas e aos caminhos percorridos na utilização deste sistema. Comumente ele pode 
ser utilizado como um detalhamento da especificação textual dos requisitos especificados 
pelos casos de uso.
O diagrama permite ao destinatário ter uma visão mais positiva daquilo que está solicitando 
à equipe de desenvolvimento. Exemplo: um cliente, proprietário de um serviço de autopeças 
que nunca teve um sistema para controle de seu estoque, gostaria de implementar um 
sistema que realizasse um fluxo similar ao que ele efetua no papel, assim, se sentiria mais 
https://drawio-app.com/wp-content/uploads/2018/01/uml-activity-diagrams-with-draw.io_.png
FACULDADE CATÓLICA PAULISTA | 56
ENGENHARIA DE SOFTWARE
PROF. FRANCISCO LUÍS BORGHI NASCIMENTO
confortável com a aquisição do software, ao ver esse fluxo modelado em um fluxograma 
(MORAIS, 2017).
 
Fonte: Morais (2017)
Um diagrama de atividades, assim como todos os diagramas da UML é baseado em 
elementos que, em conjunto, representam, neste caso, o comportamento do sistema. Os 
diagramas de atividades têm os seguintes elementos básicos: estados iniciais e finais, 
atividades e transições, decisões e, ainda, alguns elementos adicionais, como bifurcação, 
união e raias. Todos serão descritos a seguir: (MORAIS, 2017).
Estados iniciais e finais demonstram o início e o fim do diagrama:
FACULDADE CATÓLICA PAULISTA | 57
ENGENHARIA DE SOFTWARE
PROF. FRANCISCO LUÍS BORGHI NASCIMENTO
 
Fonte: Figueiredo (2017 apud MORAIS, 2017)
As atividades marcam uma rotina realizada no sistema, enquanto as decisões marcam 
um ponto no qual o sistema pode ter dois caminhos:
Fonte: Figueiredo (2017 apud MORAIS, 2017)
A bifurcação ocorre quando há uma divisão no fluxo do sistema, enquanto que na união 
junta fluxos que em outro momento foram bifurcados:
Fonte: Figueiredo (2017 apud MORAIS, 2017)
As raias são utilizadas para organizar o diagrama. Podem ser associadas a objetos e 
componentes do sistema:
 
Fonte: Figueiredo (2017 apud MORAIS, 2017)
FACULDADE CATÓLICA PAULISTA | 58
ENGENHARIA DE SOFTWARE
PROF. FRANCISCO LUÍS BORGHI NASCIMENTO
Analisando detalhadamente o diagrama completo utilizado nesta aula, o exemplo citado 
acima será numerado para que possa ser detalhado. Conforme Morais (2017, p.138) detalha-
se o diagrama da seguinte forma:
1. Marca o início do diagrama. 
2. Indica uma atividade, uma ação que deverá ser feita no sistema, no caso, 
efetuar login no sistema.
3. É uma transição, representa a ligação de uma atividade com outra, neste 
caso, leva do login para o acesso à página de cadastro.
4. Indica a ação de acessar a página de cadastro de produtos. 
5. É a transição de ligação entre o acesso à página de cadastro de produtos e 
digitar o código de produto.
6. Indica a ação de digitar o código do produto. 
7. Indica a ligação da ação ou da atividade de digitar código de produto com 
um ponto de decisão, ou seja, com um ponto que no sistema pode ser seguido 
de dois fluxos distintos.
8. Ponto de decisão em que o sistema verifica se o produto já está cadastrado 
e, baseado nisso, define o fluxo que o sistema irá seguir: cadastrar um novo 
produto ou registrar uma quantidade de um produto já cadastrado.
9. Indica a ação ou a atividade de cadastro da descrição de um novo produto.
10. Indica a ação ou a atividade de informar a quantidade do produto para ser 
incrementado o estoque.
11. Indica a ligação entre o incremento de estoque e a impressão da etiqueta. 
12. Representa a ação ou a atividade de imprimir uma etiqueta no sistema. 
13. Indica a ligação entre a impressão da etiqueta e a confirmação da inclusão 
do produto.
14. Indica a ação ou a atividade de confirmar o cadastro do produto. 
15. Indica a ligação da confirmação do cadastro com o final do diagrama. 
16. É o ponto final que marca o encerramento do diagrama.
FACULDADE CATÓLICA PAULISTA | 59
ENGENHARIA DE SOFTWARE
PROF. FRANCISCO LUÍS BORGHI NASCIMENTO
Fonte: Morais (2017)
Isto acontece na prática
Os diagramas de atividades são documentações bastante detalhadas sobre o fluxo 
comportamental do sistema e, por este motivo, alguns projetos não são bons cenários 
para utilização desse tipo de diagrama. São exemplos de cenários em que é importante 
efetuar a criação de diagramas de atividades: sistemas mais críticos, ou seja, nos quais 
uma falha no sistema pode ocasionar grandes impactos; situações em que o cliente 
deseja visualizar melhor o fluxo do sistema e projetos que dispõem de tempo para 
uma documentação mais detalhada.
FACULDADE CATÓLICA PAULISTA | 60
ENGENHARIA DE SOFTWARE
PROF. FRANCISCO LUÍS BORGHI NASCIMENTO
AULA 12
UML - DIAGRAMA 
As aplicações de diagramas UML descritos pelos autores Larman (2007) e Fowler (2004) 
se complementam. Um fato a ser acrescentado diante dessa informação é que os diagramas 
servem também para representar o sistema diante do cliente, fazendo com que a compreensão 
acerca de todas as funcionalidades e de suas aplicações seja expressa de forma gráfica.
 
Fonte:https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcSsHtKIkD6rcYw8SLbfrQq5odBQS_oiEjmLtw&usqp=CAU
A UML inclui diagramas de interação para ilustrar como os objetos interagem por meio de 
mensagens. Eles são usados para modelagem de objetos dinâmica. Há dois tipos comuns 
de diagramas de interação: diagramas de sequência e de comunicação.
Diagrama de sequência. Fonte: Morais (2017)
https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcSsHtKIkD6rcYw8SLbfrQq5odBQS_oiEjmLtw&usqp=CAU
FACULDADE CATÓLICA PAULISTA | 61
ENGENHARIA DE SOFTWARE
PROF. FRANCISCO LUÍS BORGHI NASCIMENTO
Diagrama de comunicação. Fonte: Morais (2017)
Larman (2007 apud MORAIS, 2017) traz um quadro comparativo entre os dois diagramas, 
apenas para sintetizar as informações sobre ambos:
 
Fonte: Morais (2017)
Outro meio de se representar as funcionalidades é o Diagrama de Estado, que faz parte 
de uma modelagem dirigida a eventos. Os diagramas mostram os estados, o sistema e os 
eventos que causam transições de um estado para outro. Não mostram o fluxo de dados 
dentro do sistema, mas podem incluir informações adicionais sobre os processamentos 
realizados em cada estado.
Cada diagrama de estados começa com um círculo escuro que indica o estado inicial e 
termina com um círculo contornado, indicando o estado final. Apesar de ter pontos iniciais 
e finais claros, diagramas de estados não são necessariamente a melhor ferramenta para 
FACULDADE CATÓLICA PAULISTA | 62
ENGENHARIA DE SOFTWARE
PROF. FRANCISCO LUÍS BORGHI NASCIMENTO
registrar a progressão geral de eventos. Em vez disso, eles ilustram tipos específicos de 
comportamento, principalmente mudanças de um estado para outro.
Diagramas de estados retratam principalmente estados e transições. Estados são 
representados por retângulos com cantos arredondados e rotulados com o nome do estado. 
As transições são marcadas com setas que fluem de um estado para outro, mostrando 
como os estados mudam. Abaixo, você pode ver esses dois elementos em ação por meio 
de um diagrama básico retratando um estado de venda para o outro.
 
Fonte: Abdalla (2021)
Como a maioria dos diagramas UML, diagramas de estados têm diversos usos. As principais 
aplicações são as seguintes:
• Descrever objetos orientados a eventos em um sistema reativo.
• Ilustrar cenários de caso de uso em um contexto de negócios.
• Descrever como um objeto se move por vários estados em seu tempo vida.
• Mostrar o comportamento geral de uma máquina de estados ou o comportamento de 
um conjunto relacionado