Engenharia de Software

Engenharia de Software I
Prof. Vickybert P. Freire

Aula 01
Prof. Vickybert Freire
Apresentação
Professor
• Vickybert P. Freire
vickybert.freire@fatec.sp.gov.br
– Bacharel em Ciências da Computação
– Pós-Graduado em Gestão de Projetos
– +14 anos de experiência em desenvolvimento de software em
diversas plataformas, linguagens e bancos de dados
– +8 anos de experiência em liderança de equipe e projetos
– +10 anos de experiência em ministrar disciplinas de programação
– +6 anos de experiência em ministrar disciplinas de gestão de
projetos
– Certificado em SCJP – Sun Certified Java Programmer
– Certificado em CSM – Certified ScrumMaster
– Certificado em Management 3.0
Disciplina
IES011 – Engenharia de Software I
Ementa
Introdução à Análise de Sistemas. Modelos de Ciclo de Vida de Software. Modelos
de Processos de Desenvolvimento de Software (Modelo em Cascata, Espiral e
Prototipagem). Definição e classificação de Requisitos de Software (funcionais e
não funcionais). Técnicas de Levantamento de Requisitos. Modelo de Negócios
aplicado ao levantamento de Requisitos (Canvas). Estudo de Viabilidade. Técnicas
de documentação. Metodologias para desenvolvimento de sistemas
Objetivos de Aprendizagem
• Identificar as características de Sistemas de Informação, seus tipos, viabilidade
técnica, características de custo, valor e qualidade da informação.
• Explicar as características de um sistema, seus componentes e relacionamentos.
• Compreender o ciclo de vida utilizando concepções do modelo cascata.
• Utilizar conceitos da UML na análise de requisitos e na elaboração de diagramas
focando na modelagem de sistemas.
Disciplina
Bibliografia básica
• Básica
– BEZERRA, Eduardo. Princípios de Análise e Projeto de Sistemas com UML. 3 ed. Rio de
Janeiro: Elsevier, 2015.
– PRESSMAN, Roger; MAXIM, Bruce. Engenharia de Software. 8 ed. São Paulo: McGraw
Hill Brasil, 2016.
– SOMMERVILLE, Ian. Engenharia De Software. 10 ed. São Paulo: Pearson Brasil, 2019.
• Complementar
– LARMAN, Craig. Utilizando UML e padrões. 3 ed. Porto Alegre: Bookman, 2007.
– REZENDE, Denis Alcides. Engenharia de software e sistemas de informação. 3 ed. Rio de
Janeiro: Brasport, 2005.
– WASLAWICK Raul. Análise e Projeto de Sistemas de Informação Orientados a Objetos. 2
ed. Rio de Janeiro: Elsevier, 2010.
Disciplina
Disciplina
Materiais recomendados
• YouTube • Podcast
– Curso em Vídeo – Gustavo Guanabara – Hipsters.Tech
https://www.youtube.com/c/CursoemVídeo https://hipsters.tech/category/podcast/
– Dev na Estrada
– Fabio Akita https://devnaestrada.com.br
https://www.youtube.com/c/FabioAkita1990
– Lamba3
– Full Cycle – Wesley Willians https://www.lambda3.com.br/lambda3-
podcast/
https://www.youtube.com/c/FullCycle
– Filipe Deschamps
https://www.youtube.com/c/FilipeDeschamps
Critérios de avaliação
• A avaliação do desempenho do aluno ao longo do semestre é feita
com o intuito de aferir aquisição do conteúdo da carga didática
seguirá as orientações da coordenação de curso;
• A nota semestral se dará pela média das notas entre Provas e

Atividades e deverá ser igual ou superior a 6,0 (seis) para
aprovação.
A1 e A2 = Atividades (Trabalhos)
P1 e P2 = Provas
P1 = 45% do conteúdo
P2 = 100% do conteúdo
Aprovado se: ((Freq >= 75%) && ((A1 + P1 + A2 + 2*P2)/5 >= 6)
FAQ
• Posso filmar ou gravar o áudio das aulas?
Não, está proibido o uso desses recursos.
• Posso divulgar o material da disciplina, provas e/ou trabalhos publicamente na
internet?
Não, o material fornecido visa ajuda-los no desenvolvimento do aprendizado e
orientação. As ações de divulgação do material, provas e/ou trabalhos são prejudiciais
aos futuros alunos e ao professor.
• Posso utilizar calculadora nas provas?
Sim, desde que não seja alfanumérica, nem telefone celular.
• Qual a matéria das provas e exercícios de classe?
Sempre toda a matéria lecionada até aquela data.
• Os alunos especiais estão dispensados de realizar as provas?
Não, os alunos especiais somente estão dispensados de realizar os trabalhos.
• A frequência é obrigatória?
Sim, e controlada.
FAQ
• Preciso fazer os trabalhos solicitados?
Sim, os trabalhos têm o intuito de ajuda-los a aprender e seu
reforço será recompensado computando pontos na sua
avaliação. Deixar de fazer os trabalhos fará que você perca
pontos valiosos, e que podem fazer falta no final.
• Posso, no final do semestre, me arrepender e entregar todos

ou algum trabalho atrasado?
Não, sou justo com aqueles que realizaram os trabalhos na
época correta. Seja responsável com suas próprias decisões. Se
decidiu não fazer o trabalho, assuma a responsabilidade pelo
risco de precisar dos pontos perdidos.
O que esperar desta disciplina?
• O foco principal desta disciplina será o aprendizado das
competências da Engenharia de Software, de forma
abrangente e prática, assim o aluno estará apto a
compreender e melhor se posicionar ao se deparar em
ambientes de fábricas de softwares, consultorias e afins,
e aplicar de forma supervisionada os conceitos
adquiridos.
• Durante esse curso faremos discussões a fim de trazer
para a sala de aula experiências do cotidiano e
empresariais.
Apresentação dos alunos
• Diga-me seu nome (farei a chamada enquanto
isso)
• Seu conhecimento prévio sobre Engenharia,
Desenvolvimento.
• Gostaria de trabalhar nesta área?
• Qual é seu super poder?
Aula 02
Gerenciamento de Projetos Empresariais

Introdução
O que é Software?
• Software é um agrupamento de comandos escritos em uma
linguagem de programação. Estes comandos, ou instruções, criam
as ações dentro do programa, e permitem seu funcionamento.
• Cada ação é determinada por uma sequencia, e cada sequencia se

agrupa para formar o programa em si. Estes comandos se unem,
criando um programa complexo.
• Um software, ou programa, consiste em informações que podem

ser lidas pelo computador, assim como seu conteúdo áudio-visual,
dados e componentes em geral. Para proteger os direitos do criador
do programa, foi criada a licença de uso. Todos estes componentes
do programa fazem parte da licença.
O que é Software?
• Software é o termo genérico usado para
descrever programas, apps, scripts, macros e
instruções de código embarcado diretamente
(firmware), de modo a ditar o que uma
máquina deve fazer
O que é Software?
• Esta pilha de
62.000 cartões
perfurados era o
software de
controle do SAGE.
Tamanho dos
dados? 5 MB
O que é Engenharia?
• Aplicação de métodos científicos ou empíricos à
utilização dos recursos da natureza em benefício
do ser humano.
• Engenharia é a área de atuação que se dedica a

oferecer soluções práticas para problemas
concretos. O trabalho do(a) profissional
formado(a) em engenharia é criar soluções
planejadas e sejam viáveis econômica e
tecnicamente, então é preciso conhecer a fundo
o tema daquele projeto.
O que é Engenharia de Software?
• A engenharia de software é uma disciplina de
engenharia que se preocupa com os aspectos
da produção de software, desde sua
concepção inicial até sua operação e
manutenção.
O que se estuda em Eng de Software
O SWEBOK define 12 áreas de conhecimento em Engenharia de Software:
1. Requisitos de Software
2. Desenho de Software
3. Construção de Software
4. Teste de Software
5. Manutenção de Software
6. Gerenciamento de Configuração de Software
7. Gerenciamento da Engenharia de Software
8. Processo de Engenharia de Software
9. Modelos e Métodos de Engenharia de Software
10. Qualidade de Software
11. Prática Profissional de Engenharia de Software
12. Aspectos Econômicos na Engenharia de Software
13. Fundamentos de Computação
14. Fundamentos de Matemática
15. Fundamentos de Engenharia
https://www.computer.org/education/bodies-of-knowledge/software-engineering
https://ieeecs-media.computer.org/media/education/swebok/swebok-v3.pdf
Eng de Software
• O conceito de engenharia de software foi proposto pela primeira
vez em 1968, em uma conferência realizada para discutir o que
então se chamava crise do software (NAUR; RANDELL, 1969). Ficou
claro que as abordagens individuais ao desenvolvimento de
programas não escalavam para sistemas de software grandes e
complexos. Os sistemas não eram confiáveis, custavam mais do que
o previsto e eram entregues com atraso.
• Durante os anos 1970 e 1980, foi desenvolvida uma série de

técnicas e métodos de engenharia de software, como a
programação estruturada, a ocultação da informação (information
hiding) e o desenvolvimento orientado a objetos. Foram
desenvolvidas ferramentas e notações que compõem a base da
engenharia de software atual.
Eng de Software
• Em uma conferência da OTAN, com 50
renomados cientistas da computação, houve a
seguinte citação:
“O problema é que certas classes de sistemas estão colocando
demandas sobre nós que estão além das nossas capacidades e das
teorias e métodos de projeto que conhecemos no presente
tempo. Em algumas aplicações não existe uma crise, como rotinas
de ordenação e folhas de pagamento, por exemplo. Porém,
estamos tendo dificuldades com grandes aplicações. Não podemos
esperar que a produção de tais sistemas seja fácil.”
Mercado de Trabalho
• O que faz um Engenheiro de Software?
Vídeo: Vídeo:
O que um Engenheiro de 4 Anos de ENGENHARIA
Software faz? DE SOFTWARE em 13
Minutos
Mercado de Trabalho
• Quanto ganha um Engenheiro de Software?
Mercado de Trabalho
Mercado de Trabalho
https://olhardigital.com.br/2021/07/26/pro/contracorrente-salarios-da-ti-sobem-55-nas-capitais-brasileiras-veja-valores/
Definições, Contexto e História
• No mundo moderno, tudo é software. Hoje em dia, por exemplo,
empresas de qualquer tamanho dependem dos mais diversos sistemas de
informação para automatizar seus processos. Governos também
interagem com os cidadãos por meio de sistemas computacionais, por
exemplo, para coletar impostos ou realizar eleições. Empresas vendem,
por meio de sistemas de comércio eletrônico, uma gama imensa de
produtos, diretamente para os consumidores. Software está também
embarcado em diferentes dispositivos e produtos de engenharia,
incluindo automóveis, aviões, satélites, robôs, etc. Por fim, software está
contribuindo para renovar indústrias e serviços tradicionais, como
telecomunicações, transporte em grandes centros urbanos, hospedagem,
lazer e publicidade.
• Portanto, devido a sua relevância no nosso mundo, não é surpresa que
exista uma área da Computação destinada a investigar os desafios e
propor soluções que permitam desenvolver sistemas de software —
principalmente aqueles mais complexos e de maior tamanho — de forma
produtiva e com qualidade. Essa área é chamada de Engenharia de
Software.
• Engenharia de Software trata da aplicação de
abordagens sistemáticas, disciplinadas e
quantificáveis para desenvolver, operar, manter e
evoluir software.
• Ou seja, Engenharia de Software é a área da

Computação que se preocupa em propor e aplicar
princípios de engenharia na construção de software.
Engenharia de software
A engenharia de software é importante por duas razões:
1. Cada vez mais os indivíduos e a sociedade dependem de

sistemas de software avançados.
2. Geralmente é mais barato, no longo prazo, usar métodos e

técnicas de engenharia de software para sistemas de
software profissionais em vez de apenas escrever
programas como um projeto de programação pessoal.
A abordagem sistemática utilizada na engenharia de software

é, às vezes, chamada de processo de software, uma
sequência de atividades que leva à produção de um software.
Engenharia de software
Existem dois tipos de produto de software:
1. Produtos genéricos
São sistemas stand-alone produzidos por uma organização de

desenvolvimento de software e vendidos no mercado para
qualquer cliente que queira comprá-los.
2. Software personalizado (ou feito sob medida)
São sistemas encomendados e desenvolvidos para um

determinado cliente.
Diversidade da engenharia de software
Existem muitos tipos diferentes de aplicação, incluindo:
1. Aplicações stand-alone
2. Aplicações interativas baseadas em transações
3. Sistemas de controle embarcados
4. Sistemas de processamento em lotes (batch)
5. Sistemas de entretenimento
6. Sistemas para modelagem e simulação
7. Sistemas de coleta de dados e análise
8. Sistemas de sistemas
Há fundamentos da engenharia de software que se aplicam a
todos os tipos de sistemas de software:
1. Eles devem ser desenvolvidos com o uso de um processo

gerenciado e compreendido.
2. Dependabilidade e desempenho são importantes para

todos os tipos de sistema.
3. É importante compreender e controlar a especificação e os

requisitos do software (o que o software deve fazer).
4. Os recursos existentes devem ser usados de modo eficaz.

• Desenvolvimento de software é diferente de qualquer outro produto de
Engenharia, principalmente quando se compara software com hardware. Frederick
Brooks, Prêmio Turing em Computação (1999), foi um dos primeiros a chamar a
atenção para esse fato. Em 1987, ele discorreu sobre as particularidades da área
de Engenharia de Software.
• Segundo Brooks, as dificuldades essenciais são as seguintes:

– Complexidade: dentre as construções que o homem se propõe a realizar, software é uma das
mais desafiadoras e mais complexas que existe. Na verdade, como dissemos antes, mesmo
construções de engenharia tradicional, como um satélite, uma usina nuclear ou um foguete,
são cada vez mais dependentes de software.
– Conformidade: pela sua natureza software tem que se adaptar ao seu ambiente, que muda a
todo momento no mundo moderno. Por exemplo, se as leis para recolhimento de impostos
mudam, normalmente espera-se que os sistemas sejam rapidamente adaptados à nova
legislação. Brooks comenta que isso não ocorre, por exemplo, na Física, pois as leis da
natureza não mudam de acordo com os caprichos dos homens.
– Facilidade de mudanças: que consiste na necessidade de evoluir sempre, incorporando novas
funcionalidades. Na verdade, quanto mais bem sucedido for um sistema de software, mais
demanda por mudanças ele recebe.
– Invisibilidade: devido à sua natureza abstrata, é difícil visualizar o tamanho e
consequentemente estimar o desafio de construir um sistema de software.
Exemplos reais
Para ilustrar a complexidade envolvida na construção de
sistemas de software reais, vamos dar alguns números sobre o
tamanho desses sistemas, em linhas de código.
Por exemplo, o sistema operacional Linux, em sua versão

4.1.3, de 2017, possui cerca de 25 milhões de linhas de
código e contribuições de quase 1.700 engenheiros.
Para mencionar um segundo exemplo, os sistemas do Google

somavam 2 bilhões de linhas de código, distribuídas por 9
milhões de arquivos, em janeiro de 2015 (link). Nesta época,
cerca de 40 mil solicitações de mudanças de código
(commits) eram realizadas, em média, por dia, pelos cerca de
25 mil Engenheiros de Software empregados pelo Google
nessa época.
FAQ – Eng de Software
Atributos essenciais do bom software
Aula 02

mputação está tão relacionada aos
quanto a Astronomia aos telescópios, Biologia
os, ou Química aos tubos de ensaio. A Ciência
ramentas. Ela estuda como nós as utilizamos,
brimos com elas.”
EDSGER WYBE DIJKSTRA
Ética

Código de Ética
• Os computadores têm um papel fundamental e crescente
no comércio, na indústria, no governo, na medicina, na
educação, no entretenimento e na sociedade em geral. Os
engenheiros de software são aqueles que contribuem para
análise, especificação, projeto, desenvolvimento,
certificação, manutenção e teste dos sistemas de software,
participando diretamente ou ensinando.
• Em virtude de seus papéis no desenvolvimento dos

sistemas de software, os engenheiros de software têm
oportunidades significativas para fazer o bem ou provocar
danos, capacitar terceiros a fazer o bem ou causar danos
ou influenciar terceiros a fazer o bem ou causar danos.
Código de Ética
• Para assegurar o máximo possível que seus
esforços serão utilizados para o bem, os
engenheiros de software devem se comprometer
a fazer da engenharia de software uma profissão
útil e respeitada. De acordo com esse
compromisso, os engenheiros de software devem
seguir o código de ética e prática profissional.
• O código contém princípios relacionados ao

comportamento e às decisões tomadas pelos
engenheiros de software.
Código de Ética
• Um engenheiro de software deve aceitar que o seu
trabalho envolve responsabilidades mais amplas do
que a simples aplicação de habilidades técnicas.
Também deve se comportar de maneira ética e
moralmente responsável se quiser ser respeitado como
um engenheiro profissional.
• Nem é preciso dizer que os padrões normais de

honestidade e integridade devem ser mantidos.
Habilidades e capacidades não devem ser usadas para
agir de forma desonesta ou que venha a comprometer
a reputação da profissão de engenheiro de software.
Código de Ética
No entanto, existem áreas nas quais os padrões de comportamento aceitável
não são delimitados pelas leis, mas por uma noção mais tênue de
responsabilidade profissional. Algumas dessas áreas são:
• 1. Confidencialidade. A confidencialidade dos seus empregadores ou
clientes deve ser respeitada, independentemente de um acordo ter sido
assinado ou não.
• 2. Competência. Não se deve apresentar um nível de competência que
não seja verdadeiro. Trabalhos que estejam fora da sua competência não
devem ser aceitos.
• 3. Direitos de propriedade intelectual. Deve-se estar a pardas leis locais
que regem o uso da propriedade intelectual, como patentes e direitos
autorais. É necessário ter o cuidado de assegurar que a propriedade
intelectual dos empregadores e clientes esteja protegida.
• 4. Mau uso do computador. Não se deve aproveitar habilidades técnicas
para usar indevidamente os computadores de outras pessoas. O uso
indevido do computador varia desde o relativamente trivial (jogar na
máquina de um empregador) até o extremamente grave (disseminação de
vírus ou outro tipo de malware).
Código de Ética
Código de Ética do Profissional de Informática - SOCIEDADE BRASILEIRA DE COMPUTAÇÃO
São deveres dos profissionais de Informática:
• Art. 1o : Contribuir para o bem-estar social, promovendo, sempre que possível, a inclusão de todos setores da
sociedade.
• Art. 2o : Exercer o trabalho profissional com responsabilidade, dedicação, honestidade e justiça, buscando sempre
a melhor solução.
• Art. 3o : Esforçar-se para adquirir continuamente competência técnica e profissional, mantendo-se sempre
atualizado com os avanços da profissão.
• Art. 4o : Atuar dentro dos limites de sua competência profissional e orientar-se por elevado espírito público.
• Art. 5o : Guardar sigilo profissional das informações a que tiver acesso em decorrência das atividades exercidas.
• Art. 6o : Conduzir as atividades profissionais sem discriminação, seja de raça, sexo, religião, nacionalidade, cor da
pele, idade, estado civil ou qualquer outra condição humana.
• Art. 7o : Respeitar a legislação vigente, o interesse social e os direitos de terceiros.
• Art. 8o : Honrar compromissos, contratos, termos de responsabilidade, direitos de propriedade, copyrights e
patentes.
• Art. 9o : Pautar sua relação com os colegas de profissão nos princípios de consideração, respeito, apreço,
solidariedade e da harmonia da classe.
• Art. 10: Não praticar atos que possam comprometer a honra, a dignidade, privacidade de qualquer pessoa.
• Art. 11: Nunca apropriar-se de trabalho intelectual, iniciativas ou soluções encontradas por outras pessoas.
• Art. 12: Zelar pelo cumprimento deste código.
Código de Ética
Código de ética e prática profissional da engenharia de software - ACM/IEEE-CS
De acordo com o seu compromisso com a saúde, segurança e bem-estar do público, os

engenheiros de software devem obedecer aos oito princípios a seguir:
• 1. Público - Os engenheiros de software devem agir coerentemente com o interesse público.

• 2. Cliente e empregador - Os engenheiros de software devem agir de uma maneira que
atenda aos interesses de seu cliente e empregador, coerente com o interesse público.
• 3. Produto - Os engenheiros de software devem assegurar que seus produtos e modificações
relacionadas cumpram o máximo possível os mais altos padrões profissionais.
• 4. Opinião - Os engenheiros de software devem manter a integridade e independência em
sua opinião profissional.
• 5. Gestão - Os gestores e líderes em engenharia de software devem aceitar e promover uma
abordagem ética do gerenciamento do desenvolvimento e manutenção do software.
• 6. Profissão - Os engenheiros de software devem promover a integridade e a reputação da
profissão em conformidade com o interesse público.
• 7. Colegas - Os engenheiros de software devem ser justos e apoiar os colegas.
• 8. Caráter - Os engenheiros de software devem aderir a uma aprendizagem contínua durante
toda a vida no que diz respeito à prática de sua profissão e promover uma abordagem ética
para a prática da profissão.
Aula 03
Processos de Software
Importância de Processos
• A produção de um carro em uma fábrica de automóveis segue um
processo bem definido. Sem estender a explicação, primeiro, as
chapas de aço são cortadas e prensadas, para ganhar a forma de
portas, tetos e capôs. Depois, o carro é pintado e instalam-se
painel, bancos, cintos de segurança e a fiação. Por fim, instala-se a
parte mecânica, incluindo motor, suspensão e freios.
• Assim como carros, software também é produzido de acordo com

um processo, embora certamente menos mecânico e mais
dependente de esforço intelectual. Um processo de
desenvolvimento de software define um conjunto de passos,
tarefas, eventos e práticas que devem ser seguidos por
desenvolvedores de software, na produção de um sistema.
• Em projetos pessoais, a adoção de um processo é
menos importante (a exemplo do Linux em seu início).
Ou, dizendo de outra forma, o processo em tais
projetos é pessoal, composto pelos princípios, práticas
e decisões tomadas pelo seu único desenvolvedor; e
que terão impacto apenas sobre ele mesmo.
• Porém, os sistemas de software atuais são por demais

complexos para serem desenvolvidos por uma única
pessoa. Por isso, casos de sistemas desenvolvidos por
heróis serão cada vez mais raros. Na prática, os
sistemas modernos — que nos interessam — são
desenvolvidos em equipes.
• E essas equipes, para produzir software com qualidade e
produtividade, precisam de um ordenamento, mesmo que
mínimo. Por isso, empresas dão tanto valor a processos de
software. Eles são o instrumento de que as empresas
dispõem para coordenar, motivar, organizar e avaliar o
trabalho de seus desenvolvedores, de forma a garantir que
eles trabalhem com produtividade e produzam sistemas
alinhados com os objetivos da organização.
• Sem um processo — mesmo que simplificado e leve —

existe o risco de que os times de desenvolvimento passem
a trabalhar de forma descoordenada, gerando produtos
sem valor para o negócio da empresa.
• Vamos estudar alguns processos de software,
como por exemplo Processos Waterfall e Ágeis
Processos em
Cascata
Processos em Cascata
• Os processos do tipo Waterfall (também chamado de
Cascata ou Tradicional) - dominante nas décadas de 70 e
80 - eram estritamente sequenciais, começando com
uma fase de especificação de requisitos até chegar às
fases finais de implementação, testes e manutenção do
sistema.
• O modelo em cascata é um processo dirigido por plano.

A princípio, pelo menos, é necessário planejar e criar um
cronograma de todas as atividades de processo antes de
começar o desenvolvimento do software.
• Se considerarmos o contexto histórico, essa primeira
visão de processo era natural, visto que projetos de
Engenharia tradicional também são sequenciais e
precedidos de um planejamento detalhado. Todas as
fases também geram documentações detalhadas do
produto que está sendo desenvolvido.
• Por isso, nada mais natural que a nascente Engenharia

de Software se espelhasse nos processos de áreas mais
tradicionais, como Engenharia Eletrônica, Civil,
Mecânica, Aeronáutica, etc.
Os estágios do modelo em cascata refletem diretamente as atividades
fundamentais do desenvolvimento de software:
1. Análise e definição dos requisitos. Os serviços, as restrições e as

metas do sistema são estabelecidos por meio de consulta aos
usuários. Depois, eles são definidos em detalhes e servem como
uma especificação do sistema.
2. Projeto do sistema e do software. O processo de projeto do

sistema reparte os requisitos entre requisitos de sistemas de
hardware e de software, e estabelece uma arquitetura global do
sistema. O projeto de software envolve a identificação e a
descrição das abstrações fundamentais do sistema de software e
seus relacionamentos.
3. Implementação e teste de unidade. Durante essa etapa, o projeto do
software é realizado como um conjunto de programas ou unidades de
programa. O teste de unidade envolve a verificação de cada unidade,
conferindo se satisfazem a sua especificação.
4. Integração e teste de sistema. As unidades de programa ou os

programas são integrados e testados como um sistema completo a fim
de garantir que os requisitos de software tenham sido cumpridos. Após
os testes, o sistema de software é entregue ao cliente.
5. Operação e manutenção. Normalmente, essa é a fase mais longa do

ciclo de vida. O sistema é instalado e colocado em uso. A manutenção
envolve corrigir os erros que não foram descobertos nas primeiras fases
do ciclo de vida, melhorar a implementação das unidades do sistema e
aperfeiçoar os serviços do sistema à medida que novos requisitos são
descobertos.
• Há muitas empresas, principalmente as que seu
produto final não é software, que utilizam o
modelo Waterfall para o desenvolvimento de
projetos.
• A principal referência é o PMBoK – Project

Management Book of Knowledge. Atualmente na
7ª edição, este guia traz a definição dos processos
envolvidos na condução de projetos de forma a
garantir maior taxa de sucesso para empresa de
qualquer tamanho.
• Alguns benefícios do uso de modelos Waterfall:
– Processos mais rígidos e portanto mais auditáveis;
– Alto nível de confiabilidade na evolução do projeto,
uma vez que cada etapa é validada e aceita;
– Menor exposição à imprevistos, devido à forte
preocupação com riscos e ameaças e
acompanhamento contínuo;
– Maior/melhor previsibilidade e planejamento,
evitando construções com baixo resultado.
PMBOK
• A versão atual do PMBOK (5ª edição, 2013)
contém 47 processos de gerenciamento,
agrupados nas 10 áreas de conhecimento.
10 Pilares da Gestão de Projetos
47 processos
5 grupos de processos
• No entanto, após cerca de uma década,
começou-se a perceber que software é diferente
de outros produtos de Engenharia.
• Essa percepção foi ficando clara devido aos

problemas frequentes enfrentados por projetos
de software nas décadas de 70 a 90. Por exemplo,
os cronogramas e orçamentos desses projetos
não eram obedecidos. Não raro, projetos inteiros
eram cancelados, após anos de trabalho, sem
entregar um sistema funcional para os clientes.
• Em 1994, um relatório produzido pela empresa de
consultoria Standish Group revelou informações mais
detalhadas sobre os projetos de software da época.
Por exemplo, o relatório, que ficou conhecido pelo
sugestivo nome de CHAOS Report, mostrou que mais
de 55% dos projetos estourava os prazos planejados
entre 51% e 200%; pelo menos 12% estouravam os
prazos acima de 200%, conforme mostra o próximo
gráfico.
Processos
Incrementais
Processos Incrementais
• O desenvolvimento incrementai se baseia na
ideia de desenvolver uma implementação inicial,
obter feedback dos usuários ou terceiros e fazer o
software evoluir através de várias versões, até
alcançar o sistema necessário.
• As atividades de especificação, desenvolvimento

e validação são intercaladas, em vez de
separadas, com feedback rápido ao longo de
todas elas.
• O desenvolvimento incremental, em alguma de suas
formas, é atualmente a abordagem mais comum para o
desenvolvimento de aplicações e produtos de
software.
• Essa abordagem pode ser dirigida por plano ou ágil; na

maioria das vezes, uma mistura de ambas. Em uma
abordagem dirigida por plano, os incrementos do
sistema são identificados antecipadamente; se for
adotada uma abordagem ágil, os incrementos iniciais
são identificados, mas o desenvolvimento dos
incrementos finais depende do progresso e das
prioridades do cliente.
• O desenvolvimento incremental tem três grandes
vantagens em relação ao modelo em cascata:
1. O custo de implementação das mudanças nos requisitos é
reduzido. A quantidade de análise e documentação que
precisa ser refeita é significativamente menor do que a
necessária ao modelo em cascata.
2. É mais fácil obter feedback do cliente sobre o trabalho de
desenvolvimento. Os clientes podem comentar as
demonstrações de software e ver o quanto foi implementado.
Para eles, é mais difícil julgar o progresso a partir dos
documentos do projeto (design) de software.
3. A entrega e a implantação antecipadas de um software útil
para o cliente são possíveis, mesmo se toda a funcionalidade
não tiver sido incluída. Os clientes são capazes de usar o
software e de obter valor a partir dele mais cedo do que com
um processo em cascata.
• Apesar dos benefícios o desenvolvimento incremental tem
desvantagens:
1. Grandes organizações têm procedimentos burocráticos que
evoluíram ao longo do tempo, o que pode levar a uma
incompatibilidade entre esses procedimentos e um processo
iterativo ou ágil mais informal;
2. O processo não é visível. Os gerentes precisam de resultados
regulares para medir o progresso. Se os sistemas forem
desenvolvidos rapidamente, não é econômico produzir documentos
que reflitam cada versão do sistema.
3. A estrutura do sistema tende a se degradar à medida que novos
incrementos são adicionados. Mudanças regulares deixam o código
bagunçado, uma vez que novas funcionalidades são adicionadas de
qualquer maneira possível. Fica cada vez mais difícil e caro adicionar
novas características a um sistema. Para reduzir a degradação
estrutural e a bagunça generalizada no código, os métodos ágeis
sugerem que se refatore (melhore e reestruture) o software
regularmente.
• Alguns modelos de desenvolvimento de software
usando processos incrementais foram criados e
evoluídos com o tempo, dentre eles estão:
– RUP – Rational Unified Process;
– XP – eXtreme Programming;
– Kanban;
– Scrum
• Estudaremos alguns deles mais adiante.
Atividades do
Processo
Atividades do Processo
• Os processos de software reais são sequências intercaladas de
atividades técnicas, colaborativas e gerenciais, cujo objetivo global
é especificar, projetar, implementar e testar um sistema de
software.
• As quatro atividades de processo básicas – a especificação, o

desenvolvimento, a validação e a evolução – são organizadas de
modo distinto em diferentes processos de desenvolvimento.
• No modelo em cascata, elas são organizadas em sequência; no

desenvolvimento incrementai, são intercaladas. O modo como
essas atividades são executadas depende do tipo de software que
está sendo desenvolvido, da experiência e da competência dos
desenvolvedores e do tipo de empresa que o desenvolve.
Especificação do software
• Especificação do software ou engenharia de requisitos é o processo
de compreender e definir quais serviços são necessários para o
sistema e identificar as restrições sobre sua operação e
desenvolvimento.
• A engenharia de requisitos é um estágio particularmente crítico do

processo de software, já que os erros cometidos nessa etapa
inevitavelmente geram problemas posteriores no projeto e na
implementação do sistema.
• Antes de iniciar o processo de engenharia dos requisitos, uma

empresa pode realizar um estudo de viabilidade em termos
técnicos e financeiros. Os estudos de viabilidade são de curto prazo,
relativamente baratos e orientam a decisão de ir adiante ou não
com uma análise mais detalhada.
• Existem três atividades principais no processo de engenharia de
requisitos:
1. Elicitação e análise de requisitos. É o processo de derivação dos
requisitos do sistema por meio da observação dos sistemas
existentes, de discussões com os potenciais usuários e clientes, da
análise de tarefas etc.
2. Especificação de requisitos. É a atividade de traduzir a informação
obtida durante a análise em um documento que defina um conjunto
de requisitos. Dois tipos podem ser incluídos nesse documento:
requisitos do usuário, que são declarações abstratas dos requisitos
do sistema para o cliente e usuário final; e requisitos do sistema, que
são uma descrição mais detalhada da funcionalidade a ser fornecida.
3. Validação de requisitos. Essa atividade confere os requisitos quanto
a realismo, consistência e integridade. Durante esse processo, erros
no documento de requisitos são inevitavelmente descobertos.
Projeto e implementação do software
• O estágio de implementação no desenvolvimento de software é o
processo de elaborar um sistema executável para ser entregue ao
cliente. Às vezes, isso envolve atividades distintas, que são o projeto
(design) e a programação do software.
• O projeto de software é uma descrição da estrutura do software a

ser implementado, dos modelos e estruturas de dados utilizados
pelo sistema, das interfaces entre os componentes do sistema e, às
vezes, do algoritmo utilizado. Os projetistas não chegam a um
projeto acabado imediatamente, mas o desenvolvem em estágios.
Eles acrescentam detalhes à medida que desenvolvem seu projeto,
com revisões constantes para modificar os projetos iniciais
• As atividades no processo de projeto variam, porém quatro que
podem fazer parte do processo de projeto para sistemas de
informação são:
1. Projeto de arquitetura, em que são identificados a estrutura global
do sistema e os componentes principais (módulos), observando seus
relacionamentos e como eles estão distribuídos.
2. Projeto de banco de dados, em que são projetadas as estruturas de
dados do sistema e como elas devem ser representadas em um
banco de dados.
3. Projeto de interface, em que são definidas as interfaces entre os
componentes do sistema; Uma vez acordadas as especificações da
interface, os componentes podem ser projetados e desenvolvidos
separadamente.
4. Seleção e projeto de componentes, em que são feitas buscas por
componentes reusáveis e, caso não haja componentes adequados,
são projetados novos componentes de software.
• O desenvolvimento (escrita de código) para implementar
um sistema é o próximo passo natural do projeto.
• É comum que o projeto e a programação sejam

intercalados.
• Há ferramentas de desenvolvimento de software que

podem ser usadas para gerar um esqueleto de programa a
partir de um projeto. Isso inclui o código para definir e
implementar interfaces e, em muitos casos, o
desenvolvedor precisará apenas acrescentar detalhes da
operação de cada componente do programa.
Validação do software
• A validação do software ou, em termos mais gerais,
verificação e validação (V & V), destina-se a mostrar
que um sistema está em conformidade com sua
especificação e que satisfaz as expectativas do cliente
do sistema.
• A principal técnica de validação é o teste de programa,
no qual o sistema é executado usando dados de teste
simulados.
• A validação também pode envolver processos de
conferência como inspeções e revisões em cada estágio
do processo de software, desde a definição dos
requisitos do usuário até o desenvolvimento do
programa.
• Os sistemas não devem ser testados como
uma unidade monolítica.
• Um processo de teste pode ter três estágios,
no qual os componentes do sistema são
testados individualmente e, depois, o sistema
integrado é testado e, por fim, testado pelo
cliente.
Os estágios no processo de teste são:
1. Teste de componente. Os componentes do sistema são testados pelas
pessoas que o desenvolvem. Cada componente é testado
independentemente, sem as demais partes do sistema. Os
componentes podem ser entidades simples. como as funções ou classes
de objetos, ou agrupamentos coerentes dessas entidades.
2. Teste de sistema. Os componentes do sistema são integrados para criar

um sistema completo. Esse processo encontra erros resultantes de
interações imprevistas entre os componentes e de problemas de
interface.
3. Teste do cliente. O sistema é testado pelo cliente (ou cliente potencial)

em vez de usar dados de simulação. Pode revelar erros e omissões na
definição dos requisitos do sistema funcionais e não-funcionais, nos
quais os recursos do sistema não satisfazem realmente as necessidades
dos usuários ou o desempenho do sistema é inaceitável.
Evolução do Software
• Historicamente, sempre houve uma divisão entre o processo de
desenvolvimento e o processo de evolução (manutenção) do software. As
pessoas pensam em desenvolvimento de software como uma atividade
criativa, na qual um sistema de software é desenvolvido a partir de um
conceito inicial até se tornar um sistema funcional. Por outro lado,
pensam em manutenção de software como uma atividade maçante,
menos interessante e menos desafiadora do que o desenvolvimento do
software original.
• Essa distinção entre desenvolvimento e manutenção é cada vez mais

irrelevante. Poucos sistemas de software são completamente novos, e faz
muito mais sentido encarar o desenvolvimento e a manutenção como
uma coisa só. Em vez de processos diferentes, é mais realista encarar a
engenharia de software como um processo evolutivo, no qual o software é
alterado continuamente ao longo de sua vida útil em resposta à mudança
dos requisitos e das necessidades do cliente.
Lidando com
Mudanças
Lidando com Mudanças
• A mudança é inevitável em todos os grandes projetos de
software. Os requisitos do sistema mudam à medida que as
empresas reagem a pressões externas, à concorrência e a
mudanças nas prioridades da gestão.
• A mudança eleva os custos de desenvolvimento de

software, já que isso normalmente significa que o trabalho
já concluído precisará ser refeito.
• Se novos requisitos forem identificados, parte ou toda a

análise de requisitos deve ser refeita. Então, será
necessário reprojetar o sistema para entregar os novos
requisitos, mudar quaisquer programas que tenham sido
desenvolvidos e testar o sistema novamente
Lidando com Mudanças
• Duas abordagens relacionadas podem ser
utilizadas para reduzir os custos de retrabalho:
1. Antecipação da mudança. O processo de software inclui
atividades que podem antecipar ou prever possíveis mudanças
antes da necessidade de um retrabalho considerável. Por
exemplo, um protótipo do sistema pode ser desenvolvido para
exibir aos clientes algumas características principais do
sistema. Eles podem experimentar o protótipo e refinar seus
requisitos antes da implementação.
2. Tolerância à mudança. O processo e o software são projetados
de modo que as mudanças no sistema possam ser feitas com
facilidade. Isso envolve, normalmente, alguma forma de
desenvolvimento incremental.
Aula 00
Projeto Interdisciplinar
• No Projeto Pedagógico do Curso Superior Tecnológico em Desenvolvimento de
Software Multiplataforma foram previstos 6 Projetos Interdisciplinares a
serem desenvolvidos em disciplinas-chave, ou seja, disciplinas nas quais o
professor responsável será encarregado de desenvolver o PI. Para cada
disciplina-chave existe um conjunto de disciplinas que servirão de apoio. Estas
disciplinas são denominadas Disciplinas Satélite.
• Cada PI deve gerar um produto, de acordo com a complexidade do

tema/problema/desafio proposto apresentados por empresas. Este produto
pode ser representado por protótipos funcionais com níveis variados de
detalhamento, modelos de negócios, APIs, software e ou aplicativos para
multiplataformas.
• Desta forma, os alunos terão a oportunidade de desenvolver projetos,

tornando possível o desenvolvimento de conjuntos de competências técnicas
e socioemocionais relacionadas à sua futura área de atuação profissional, por
meio da integração entre a teoria aprendida em sala de aula e a realidade na
prática exigida pelo mercado de trabalho.
O desenvolvimento dos Projetos Interdisciplinares permitirá ao aluno:
• Desenvolver um trabalho prático que integre as teorias abordadas nas disciplinas do
semestre referente ao Projeto Interdisciplinar, bem como em semestres anteriores.
• Buscar, aplicar, ampliar e adequar conhecimento técnico-científico, visando à integração
entre a teoria e a prática no desenvolvimento das competências requeridas para formação
do perfil profissional.
• Exercitar-se na perspectiva da prática profissional através de sua inserção em situação real
de trabalho.
• Exercitar a interpretação e a articulação dos argumentos teóricos e/ou empíricos para
demonstrar análises críticas, conclusões e sugestões de desdobramentos pertinentes aos
assuntos pesquisados.
• Participar do trabalho em equipes, que propicia o exercício de uma postura democrática,
participativa, cooperativa, crítica e empática dos integrantes do grupo, desenvolvendo suas
habilidades nas relações interpessoais.
• Aplicar ferramentas metodológicas e ou bibliotecas e boas práticas na apresentação de
trabalhos técnico-científicos.
• Diagnosticar e analisar situações-problema, propondo alternativas e soluções criativas em
situações reais, embasando sua futura vivência profissional e ética, tornando-se autônomo
na resolução de problemas.
• Melhorar a comunicação, inclusive no que tange aos processos de divulgação de produtos ou
serviços, que passam a ser desenvolvidos nos Projetos Interdisciplinares.
Ferramentas
Ferramentas
• Para o desenvolvimento dos Projetos
Interdisciplinares, recomenda-se o emprego
de métodos ágeis para gestão dos projetos.
Formalmente, o conteúdo será desenvolvido
na disciplina Gestão de Projetos Ágeis, que
está prevista no terceiro semestre. No
entanto, nada impede que alguns conceitos
sejam desenvolvidos transversalmente
durante todos os semestres.
Ferramentas
• O emprego do Canvas no desenvolvimento dos projetos é indicado por se
tratar de uma ferramenta amplamente utilizada para representar um
modelo de negócios, lembrando que os alunos do curso podem ser
futuros empreendedores ou intraempreendedores, por isso a importância
em trazer essa ferramenta em uma abordagem aplicada no contexto do
curso.
• Design Thinking é uma metodologia de desenvolvimento de produtos e
serviços focados nas necessidades, desejos e limitações dos usuários. Essa
metodologia é utilizada tanto para levantamento de requisitos, quanto
para pesquisa junto a usuários. Por se tratar de uma ferramenta voltada
para pessoas (clientes/usuários), ela auxilia no desenvolvimento centrado
no usuário e também na metodologia ágil, pois facilita a criação e entrega
de um MVP (Mínimo Produto Viável).
• Como método ágil, sugere-se o Framework Scrum, por ser o mais
difundido, porém o Coordenador do Curso e o corpo docente podem usar
o método que acharem mais adequado para a realidade da unidade.
Assim como pode-se optar por um método híbrido que empregue
métodos ágeis e processos tradicionais trazidos pelo PMBOK.
Ferramentas
Temas / Objetivos
Temas / Objetivos
• Os temas dos Projetos Interdisciplinares do CST em
Desenvolvimento de Software Multiplataforma devem ser trazidos
por empresas parceiras das Fatecs, uma vez que uma das
metodologias propostas é a Aprendizagem Baseada em Problemas.
• Cabe ressaltar que a empresa deve ter entendimento, que a

proposta de utilizar problemas reais é meramente para aplicação
didática, inclusive a empresa pode apresentar um problema que já
foi resolvido no âmbito da empresa, destacando que o problema
deve ser condizente com as competências a serem desenvolvidas
naquele semestre.
• O objetivo ao solicitar a empresa que apresente um problema real,

para ser resolvido dentro da Fatec, é ambientar os alunos no
processo de resolução de problemas, estimulando o pensamento
crítico e a capacidade de inovar.
Competências Profissionais / Objetivos de Aprendizagem
Competências Socioemocionais
Portfólio Digital
Portfólio Digital
• Em DSM, o Trabalho de Graduação será substituído
pelos PIs desenvolvidos no decorrer do curso; para
efetivar essa substituição, os PIs deverão ser avaliados
pelos professores e, se possível, por um integrante da
empresa parceira ou convidados externos, para então
ser disponibilizado em um Portfólio Digital.
• O Portfólio Digital deve ser individual, e o aluno poderá

colocar outros projetos desenvolvidos durante o curso,
ficando a cargo do aluno e do professor responsável
pela avaliação do referido projeto julgar se é viável ou
não sua inclusão.
Portfólio Digital
A adoção do Portfólio Digital justifica-se pela possibilidade de utilizá-lo como
uma forma de apresentar a produção técnica do aluno em entrevistas de
emprego. O uso de portfólio no processo avaliativo já vem sendo utilizado em
vários cursos de todos os níveis de educação, pois, por meio de um portfólio,
é possível:
– Desenvolver o protagonismo do aluno no processo de

aprendizagem.
– Concentrar todos os projetos desenvolvidos durante o curso em
um único repositório.
– Evidenciar as competências técnicas desenvolvidas.
– Destacar as tecnologias em que mais tem familiaridade e domínio.
– Promover a autoavaliação.
– Favorecer a postura reflexiva.
Ferramentas
Do primeiro ao
sexto semestre
Do primeiro ao sexto semestre
• Em DSM, foram propostos 6 PIs; para cada um
deles, foi escolhida uma Disciplina-Chave,
sendo que, nessa disciplina, o professor será
responsável por propor e desenvolver o PI.
Cada PI envolve as disciplinas, conhecimentos
e competências de ao menos 2 disciplinas
satélites.
Do primeiro ao sexto semestre
• Ao relacionar competências desenvolvidas em disciplinas de
diferentes semestres, é possível avaliar diferentes dimensões
de uma mesma competência, proporcionando, assim, ao
aluno, a possibilidade de adquirir o conhecimento integral,
que vai do conhecimento factual até o conhecimento
metacognitivo e, assim, alcançar todos os objetivos de
aprendizagem (Lembrar, Entender, Aplicar, Analisar, Sintetizar
e Criar) como proposto na Taxonomia de Bloom
Itens do projeto
Itens do projeto
• Como sugestão de estrutura dos projetos, são elencados alguns itens:
– Descrição do projeto: (Problema a ser resolvido, justificativa, objetivos, metas, requisitos
básicos, partes interessadas, entre outras);
– Metodologia de gestão do projeto: (definir qual o tipo de gestão: ágil, tradicional ou híbrida),
(equipe/responsabilidades, cronograma de atividades/entregas, regras para a entrega do
Pitch, avaliação entre outras);
– Ferramentas empregadas;
– Repositório e versionamento;
– Link de acesso ao Pitch;
– Competências técnicas desenvolvidas;
– Competências socioemocionais desenvolvidas;
– Critérios de avaliação;
– Produto final a ser entregue
– Dados do portfólio (link do projeto/produto).
• Cabe ressaltar que, além desses itens, o Coordenador de Curso e os

Professores Responsáveis pelos PIs podem incluir outros itens, assim como
criar regras para o formato das entregas, composição das notas e formas de
apresentação.
Regras Básicas
Como o desenvolvimento de PIs não está atrelado a uma única disciplina do PPC, a criação
de regras se faz importante. Com a finalidade de auxiliar a implantação do CST em
Desenvolvimento de Software Multiplataforma, foram propostas as seguintes regrais gerais,
cabendo ao Coordenador de Curso e professores avaliarem a necessidade da inclusão de
outras regras.
– Os Projetos “Interdisciplinares” têm caráter obrigatório nos períodos que estão

estipulados (1º ao 6º sexto semestre).
– O aluno só pode participar de um único PI por semestre.
– O “Projeto Interdisciplinar” se aplica a todos os alunos regularmente matriculados no
CST em Desenvolvimento de Software Multiplataforma, inclusive para os alunos que
tenham sido dispensados de alguma disciplina. Os casos omissos deverão ser
encaminhados à Coordenação do Curso.
– Os projetos deverão ser apresentados nas formas escrita e oral, seguindo os modelos e
regras para a parte escrita, parte prática e apresentação oral.
– Os projetos serão avaliados pelo Professor Responsável pela Disciplina-Chave na qual é
desenvolvido o PI e pelos professores das Disciplinas Satélite, quando possível, por um
integrante de uma empresa parceria da unidade ou algum convidado externo.
– A composição da nota do PI deve ser discutida entre os professores das Disciplina-Chave
e Disciplinas Satélite, sendo elaborada também uma lista de critérios para serem
apresentados aos alunos.
continua...
Regras Básicas
– Os projetos deverão ser desenvolvidos em grupos, sendo que o número de integrantes
fica a critério do professor da Disciplina Chave.
– Todos os integrantes dos grupos serão responsáveis pelo trabalho apresentado, não
cabendo atribuições de responsabilidades individuais, sendo assim o feedback deve ser
relacionado ao projeto e não a um único aluno.
– O desenvolvimento das competências técnicas e socioemocionais deve ser avaliado na
entrega dos Projetos Interdisciplinares, bem como durante o seu desenvolvimento.
– A avaliação do projeto não deve ser a única forma de avaliação do aluno, na Disciplina-
Chave. Deve ser levado em conta as competências técnicas e as socioemocionais
desenvolvidas durante na disciplina.
– As competências técnicas podem ser avaliadas por meio das entregas parciais e da
entrega final do projeto, sendo que os professores das Disciplina-Chave e Disciplinas
Satélite definem se a nota será por grupo ou individualmente.
– Cada aluno deve ser avaliado individualmente, no que tange ao desenvolvimento das
competências socioemocionais, ou seja, a avaliação destas competências não deve ser
realizada de forma coletiva. Sugere-se também que seja realizada uma avaliação em
pares e uma autoavaliação.
Papéis dos atores
do PI
Atores
Papel da Empresa
• A participação das empresas no processo em ensino
aprendizagem é de suma importância, pois diminui o gap
entre academia e o mercado de trabalho. No contexto dos PIs,
o papel da empresa é:
– Apresentar temas de projetos ou problemas reais para os alunos e
professores do Curso;
– Participar da avaliação das soluções/produtos desenvolvidos;
– Fornecer feedback estruturado das soluções apresentadas/produtos;
– Avaliar o Portfólio do aluno, quando possível.
Papel do Coordenador
• O Coordenador do Curso representa um papel importantíssimo no desenvolvimento dos PIs, pois
ele é o elo entre as empresas, os professores e os alunos. Para isso elencamos algumas atividades
que garantirão o exercício do seu papel.
– Realizar reuniões com os professores do curso, antes do início das aulas do semestre letivo, para planejar,
coletivamente, o trabalho interdisciplinar na sua totalidade, respeitando-se, porém, a especificidade de cada
disciplina.
– Buscar por empresas do setor para participarem dos PIs. Quando necessário, o coordenador por indicar
professores para realizarem esta atividade.
– Manter a interlocução entre as empresas parceiras. Quando necessário, o coordenador por indicar
professores para realizarem esta atividade.
– Promover o envolvimento dos professores na delimitação do que deve ser pesquisado em cada disciplina
envolvida no desenvolvimento do PI.
– Fazer a alocação, ao longo do semestre, de espaço nas reuniões com o corpo docente, com o objetivo de
avaliar o andamento do trabalho interdisciplinar e definir novos encaminhamentos, quando necessário.
– Manter interlocução contínua com os professores responsáveis pelos PIs, para monitorar o processo de
desenvolvimento interdisciplinar.
– Preparar cartas de apresentação de alunos às instituições, no caso de trabalho de campo, assim como
certificados de participação, quando necessário.
– Organizar, juntamente com os professores responsáveis, o período de apresentação do trabalho oral.
– Realizar reuniões com os professores, no final do semestre letivo, para avaliar o trabalho interdisciplinar e
identificar os aspectos que devem ser revistos no planejamento do semestre seguinte.
– Garantir a integração dos alunos, professores e coordenação de curso.
– Criar estratégias de implantação e acompanhar a execução das atividades dos PIs.
– Promover o evento de apresentação dos resultados finais dos PIs. Quando necessário, o coordenador por
indicar professores para realizarem esta atividade.
Papel do Prof da Discip. Chave
• O Professor Responsável pelas Disciplinas-Chave será o articulador do
desenvolvimento do PI. Sua principal atribuição é planejar e acompanhar o
andamento do trabalho pelos alunos e articular a contribuição dos demais
professores, de forma a garantir a construção da interdisciplinaridade,
desenvolvendo as seguintes ações:
– Definição do tema do PI, conjuntamente com os professores das Disciplinas Satélite ao
PI e com a empresa parceira (se houver).
– Definição dos definição dos critérios e composição da nota, conjuntamente com os
professores das Disciplinas Satélite.
– Apresentação da proposta do trabalho interdisciplinar aos alunos.
– Distribuição do tema e subtemas (se houver) do PI para os grupos.
– Descrição das tarefas a serem executadas pelos alunos e distribuição do cronograma de
atividades.
– Levantamento de possibilidades de contatos para realização de coleta de dados e
pesquisa/trabalho de campo.
– Interlocução contínua com os professores das Disciplinas Satélite do PI.
– Avaliação contínua junto ao Coordenador de Curso do processo de desenvolvimento do
PI.
– Avaliar o Portfólio do Aluno.
Papel do Prof da Discip. Chave
• Cabe lembrar que o Professor Responsável pela Disciplina-Chave não trabalhará o conteúdo
específico das Disciplinas-Satélite e sim a articulação desses conteúdos na parte escrita,
técnica e na apresentação oral do projeto. O Professor Responsável pela Disciplina-Chave
será o gestor do projeto e, para isso, será necessário que tenha encontros com os grupos
para:
– garantir a implementação do produto proposto;
– construir a metodologia do projeto;
– acompanhar a realização das atividades do projeto;
– acompanhar a elaboração o desenvolvimento do projeto, incluindo a parte escrita e
oral;
– colaborar na resolução dos obstáculos encontrados pelos grupos;
– avaliar o processo de desenvolvimento (etapas do processo) e o produto gerado.
Papel do Prof das Discip. Satélites
• Os professores das Disciplinas-Satélites são responsáveis por subsidiar o
professor da Disciplina-Chave e o Coordenador de Curso, realizando as
seguintes ações:
– Auxiliar na definição do tema e subtemas (se houver) do PI.
– Manter diálogo constante com o professor da Disciplina-Chave.
– Participar do processo de avaliação dos PIs, auxiliando na definição dos
critérios e na composição da nota.
– Garantir que as competências vinculadas à sua disciplina sejam desenvolvidas
e avaliadas de forma a garantir a interdisciplinaridade.
– Auxiliar os alunos, sempre que possível, no desenvolvimento do PI.
– Avaliar o Portfólio do Aluno.
Papel do Aluno
• O ator principal do PI, sem dúvida é o aluno. Além do desenvolvimento
das competências técnicas o aluno deve ser preocupar também em
melhorar suas competências socioemocionais, desenvolvendo as
seguintes ações:
– Administrar conflitos entre os componentes do grupo.
– Desenvolver o projeto de acordo com as etapas de planejamento descritas no
cronograma e seguir as orientações do Professor da Disciplina-Chave e dos
demais professores.
– Desenvolver o projeto e elaborar o trabalho escrito e preparar a apresentação
oral do PI, seguindo as recomendações dos professores.
– Criar um portfólio digital e incluir todos os PIs desenvolvidos, bem com demais
projetos que os professores julgarem ideais para divulgação.
Aula 04
Desenvolvimento ágil
• As empresas de hoje em dia operam em um
ambiente global em rápida mudança. Elas precisam
responder às novas oportunidades e mercados, às
mudanças nas condições econômicas e ao
surgimento de produtos e serviços concorrentes.
• O software faz parte de quase todas as operações de

negócios, então novo software tem de ser
desenvolvido rapidamente, para que seja possível
tirar vantagem das novas oportunidades e responder
à pressão da concorrência
• O desenvolvimento rápido de software passou a ser conhecido
como desenvolvimento ágil, ou métodos ágeis. Esses métodos são
concebidos para produzir software útil de maneira rápida. Todos
eles compartilham uma série de características comuns:
1. Os processos de especificação, projeto e implementação são

intercalados. Não há especificação detalhada do sistema e a
documentação do projeto é minimizada ou gerada
automaticamente pelo ambiente de programação utilizado para
implementar o sistema. O documento de requisitos do usuário é
uma definição resumida contendo apenas as características mais
importantes do sistema.
2. O sistema é desenvolvido em uma série de incrementos. Os
usuários finais e outros stakeholders estão envolvidos na
especificação e avaliação de cada um deles. Além de
mudanças no software, eles também podem propor novos
requisitos para serem implementados em uma versão
posterior do sistema
3. O amplo apoio de ferramentas é usado para ajudar no

processo de desenvolvimento. Podem ser utilizadas
ferramentas de teste automatizado, ferramentas de apoio ao
gerenciamento de configuração e à integração de sistemas,
além de ferramentas para automatizar a produção da
interface com o usuário.
• Os métodos ágeis se baseiam no
desenvolvimento incrementai; os incrementos
são pequenos e, normalmente, novas versões
do sistema são criadas e disponibilizadas para
os clientes a cada duas ou três semanas, para
que seja possível obter deles um feedback
rápido nos requisitos que mudam.
Recordando...
História da Metodologia Ágil
• 1992 – Crystal Methods - Alistair Cockburn
• 1993 – Refactoring - Bill Opdyke
• 1994 – Dynamic Systems Development Method – Consortium
• 1995 – Scrum - Jeff Sutherland and Ken Schwaber
• 1995 – Pair Development - Jim Coplien / Larry Constantine
• 1997 – Feature Driven Development – Jeff De Luca, Peter Coad and
Jon Kern
• 1999 – Adaptive Software Development – Jim Highsmith
• 1999 – The Pragmatic Programmer – Andrew Hunt and Dave
Thomas
• 1999 – Extreme Programming – Kent Beck
• 2001 – The Agile Manifesto for Software Development
Manifesto Ágil
• Em 2001, Kent Beck e outros 16 renomados desenvolvedores,
autores e consultores da área de software (batizados de “Agile
Alliance” – “Aliança dos Ágeis”) assinaram o “Manifesto para
o Desenvolvimento Ágil de Software”
• Um manifesto normalmente é associado a um movimento

político emergente: ataca a velha guarda e sugere uma
mudança revolucionária (espera-se que para melhor). De
certa forma, é exatamente disso que trata o desenvolvimento
ágil.
Manifesto Ágil
Mais informações em: https://agilemanifesto.org

Manifesto Ágil
Manifesto Ágil
12 princípios
• Satisfazer o cliente
• As mudanças são bem vindas
• Entrega periódica de funcionalidade
• Negócios e desenvolvedores em conjunto pelo projeto
• Indivíduos motivados
• Conversas face a face
• O produto funcional é a medida do progresso
• Manter um ritmo constante sempre
• Atenção contínua, excelência técnica e bom projeto
• Simplicidade
• Equipes auto-gerenciadas
• Melhoria contínua
Mais informações em: http://www.manifestoagil.com.br/
Metodologia Ágil
Engenharia de Software I Atenção: isto é não verdade. É somente piada.

Doze Princípios
Técnicas de
Desenvolvimento
Ágil
Extreme
Programming
Extreme Programming
• A abordagem mais importante para a
mudança de cultura no desenvolvimento de
software foi o Extreme Programming, criado
por Kent Beck.
Extreme Programming
• Processo de produção do incremento de um
sistema desenvolvido usando Extreme
Programming
Extreme Programming
• Na XP os requisitos são expressos em cenários (chamados de
histórias do usuário) implementados diretamente como uma
série de tarefas.
• Os programadores trabalham em pares e desenvolvem testes
para cada tarefa antes de escreverem o código.
• Todos os testes devem ser executados com sucesso quando o
novo código é integrado ao sistema, já que há um curto
intervalo de tempo entre os lançamentos (releases) do
sistema.
Extreme Programming
O XP introduziu uma série de práticas que refletem no manifesto ágil:
1. O desenvolvimento incremental é apoiado por lançamentos menores e mais
frequentes do sistema. Os requisitos se baseiam em histórias simples dos clientes —
ou cenários —, utilizados como base para decidir qual funcionalidade deve ser
incluída em um determinado incremento.
2. O envolvimento do cliente é apoiado por seu engajamento contínuo no time de
desenvolvimento. O representante do cliente participado desenvolvimento, e é
responsável por definir os testes de aceitação do sistema.
3. As pessoas, não os processos, são apoiadas pela programação em pares, pela
propriedade coletiva do código do sistema e por um processo de desenvolvimento
sustentável que não envolve expedientes de trabalho longos demais.
4. As mudanças são adotadas por meio de lançamentos regulares do sistema aos
clientes, desenvolvimento com testes a priori (test-first), refatoração para evitar a
degeneração do código e integração contínua de novas funcionalidades.
5. A manutenção da simplicidade é apoiada pela refatoração constante, que melhora a
qualidade do código, e pelo uso de projetos (designs) simples, que não antecipam
desnecessariamente as futuras mudanças no sistema.
Extreme Programming
Pair Programming
Pair Programming
• A técnica de programação em pares sugere que os
programadores devem trabalhar em duplas no
desenvolvimento do software.
• Cada dupla senta-se diante do mesmo computador para

desenvolver o software, mas o mesmo par nem sempre
programa junto. Em vez disso, os pares são criados
dinamicamente para que todos os membros do time
trabalhem uns com os outros durante o processo de
desenvolvimento.
Pair Programming
A programação em pares tem uma série de vantagens:
1. Apoia a ideia de propriedade e responsabilidade coletivas pelo sistema. Isso

reflete a ideia de Weinberg, de programação sem ego, em que o software é de
propriedade de todo o time e os indivíduos não são responsabilizados
individualmente pelos problemas com o código. Em vez disso, todos são
responsáveis pela resolução de problemas.
2. Ela age como um processo de revisão informal, já que cada linha de código é
examinada por ao menos duas pessoas.
3. Incentiva a refatoração para melhorar a estrutura do software. Um
desenvolvedor que investe tempo refatorando pode ser considerado menos
eficiente do que um que simplesmente desenvolva código. Nas situações em que
a programação em pares e a propriedade coletiva são empregadas, outras
pessoas se beneficiam imediatamente da refatoração, tendendo a apoiarem o
processo.
Gestão de
Projetos Ágil
Kanban
Kanban
• O termo “kanban” combina as palavras em
Japonês “kan”, que significa “visual” e “ban”,
que significa “cartão” ou “quadro”.
• Um kanban é um cartão visual ou outra
etiqueta que sinaliza que algo é necessário.
• É um sistema de “solicitação”.
Kanban
• Kanban foi desenvolvido como um sistema de
inventariado just-in-time (JIT).
• Ao utilizar o kanban, os materiais e
suprimentos são entregues somente quando
necessário. Isto reduz os custos de
armazenamento e transporte.
Kanban
• O sistema kanban exige um espaço
determinado por uma área física delimitada,
ou por um número fixo de contentores ou por
cartões, onde a quantidade de material
próximo à linha de produção nunca deverá ser
superior àquela que estes espaços, cartões ou
contentores determinam.
Kanban
Kanban - Benefícios
• Tempo de ciclo curtos, oferecendo recursos mais
rapidamente;
• Melhor gestão nas mudanças de prioridade;
• Requer menos organização;
• O processo é simplificado;
• Maior visibilidade dos projetos;
• Redução de desperdício;
• Redução de custo;
• Elimina atividades que não agregam valor para a
equipe;
• Melhora a motivação e desempenho da equipe.
Kanban
• Qualidade garantida. Tudo o que é feito deve ir bem na primeira vez, não
há margem para erro. Assim, o Kanban não recompensa a velocidade, mas
a qualidade final das tarefas executadas. Isto é baseado no fato de que
muitas vezes custa mais para corrigi-lo depois de fazer certo da primeira
vez.
• Redução de desperdício. O Kanban é baseado em fazer apenas o que é

necessário e justo, mas fazendo bem. Isso supõe a redução de tudo que é
superficial ou secundário (princípio YAGNI).
• Melhora contínua. O Kanban não é simplesmente um método de gestão,

mas também um sistema de melhoria no desenvolvimento de projetos, de
acordo com os objetivos a serem alcançados.
• Flexibilidade. A próxima coisa a fazer é decidir sobre o backlog (ou tarefas

acumuladas pendentes), sendo capaz de priorizar as tarefas recebidas de
acordo com as necessidades do momento (capacidade de responder a
tarefas inesperadas).
Metodologia Kanban
• A metodologia ágil Kanban trata de um sistema de organização
para execução de tarefas. Pode ser feito através de um software ou
até mesmo à mão, alinhando as atividade em categorias como “a
fazer”, “em produção” e “feito”. Para utilizar o método, é preciso
levar alguns pontos em consideração:
Definição de colunas
• Existem essas três colunas básicas citadas acima, porém, o kanban
pode ser organizado conforme sua necessidade. Por isso, antes de
mais nada, é preciso definir quais serão as colunas e o que elas
representarão. Uma coluna que pode aparecer no setor de
desenvolvimento é “ready to dev”, que corresponde às atividades
que já estão prontas para serem desenvolvidas.
Princípios do Kanban
Princípios da Gestão de Mudanças
• Estes princípios de gestão de mudanças são
comuns a todas as implementações Kanban:
– Comece com o que você faz hoje
– Acordar em buscar a melhoria através da
mudança evolucionária
– Encorajar atos de liderança em todos os níveis
• Kanban usa uma abordagem evolucionária de
mudança, baseando-se na forma de trabalhar já
existente, buscando melhorá-lo usando várias formas
de feedback e colaboração.
• O Método Kanban gera mudanças evolutivas através

de percepções obtidas pelas pessoas que trabalham
com o quadro Kanban e que tenham atos de liderança
para melhorar continuamente a sua maneira de
trabalhar. Esses atos de liderança podem ser pequenas
observações e sugestões para a melhoria, realizadas
por indivíduos sem papéis de liderança organizacional.
Princípios da Entrega de Serviços
• Os princípios orientados para os serviços são:
– Compreender e focar nas necessidades e
expectativas dos seus clientes.
– Gerenciar o trabalho; deixar que as pessoas se
autoorganizem em torno dele.
– Rever regularmente a rede de serviços e as suas
políticas, a fim de melhorar os resultados.
• Kanban encoraja você a adotar uma
abordagem orientada a serviços para
compreender a sua organização e como o
trabalho flui através dela.
• As solicitações dos clientes fluem através dos

serviços prestados. Se queremos melhorar a
prestação de serviços, as melhorias devem ser
guiadas por um conjunto de princípios.
Práticas Gerais do Kanban
O método Kanban possui 6 práticas gerais:
1. Visualizar – Construa um modelo visual que reflete como

você trabalha atualmente. Isso nos permite absorver e
processar muita informação num curto espaço de tempo.
2. Limite de trabalho em progresso (WIP - Work In Progress) –

indica o número de itens de trabalho em progresso num
determinado momento temporal. Isso deve ser feito para
evitar o atraso nas entregas e manter um bom fluxo de
trabalho. O foco sempre deve ser em entregar as atividades
com qualidade e evitar que sejam gerados gargalos entre as
etapas.
3. Gerenciando o Fluxo – gerir o fluxo de trabalho é
concluir o trabalho da forma mais contínua e o mais
previsível possível, mantendo simultaneamente um
ritmo sustentável. O monitoramento ou medição do
fluxo de trabalho resulta em informações
importantes que são muito úteis para a gestão das
expectativas com os clientes, para a previsão e
melhorias.
4. Tornando as Políticas Explícitas - As políticas devem
ser colocadas em uma área claramente perceptível,
de preferência ao lado do quadro, e incluem:
– Políticas como o de reabastecimento do quadro (quando,
quanto, por quem).
– Definição de quando uma atividade de trabalho é
concluída, e o item de trabalho pode seguir em frente
(“critérios para puxar”).
– Limites de WIP.
– Políticas para o tratamento de itens de trabalho de
diferentes classes de serviço.
– Horários das reuniões e conteúdo.
– Outros princípios e acordos de colaboração.
5. Ciclos de Feedback - Ciclos de Feedback são necessários
para uma entrega coordenada e para melhorar a
entrega do seu serviço. Alguns meios comumente
usados para os ciclos de feedback em sistemas Kanban
são o quadro, as métricas e um conjunto de reuniões
regulares e revisões.
6. Melhorar Colaborativamente, Evoluir

Experimentalmente - Kanban é um método para
mudanças contínuas, e fazemos essas mudanças
colaborativamente usando experimentos baseados em
modelos e no método científico.
Limites de WIP e Sistema Puxado
• O chamado limite de WIP, ou seja, o número
máximo de itens de trabalho permitidos de cada
vez, podem ser definidos por estado (s) do
trabalho, por pessoa, por faixa, por tipo de
trabalho, para todo o sistema Kanban etc.
• Reduz a falta de pontualidade e mudança de

contexto que pode resultar em atraso, qualidade
e potencial desperdício. O objetivo é criar um
equilíbrio entre a demanda e a capacidade ao
longo do tempo.
Limites de WIP e Sistema Puxado
• Cria um fluxo contínuo de trabalho através do
“princípio puxado” em que o trabalho ou “puxar” só
acontece se houver capacidade. Um sinal virtual para
puxar é gerado quando o limite de WIP não é
totalmente utilizado.
• O “princípio puxado” é um importante ponto de

distinção da gestão tradicional do projeto, onde os
itens de trabalho são programados com base no
planejamento determinístico (empurrado). Nos
sistemas puxados, o trabalho concluído é considerado
mais valioso do que iniciar um novo trabalho.
Principais Métricas do Kanban
Há uma série de métricas básicas no Kanban:
• O Lead Time é o tempo que leva para que um único
item de trabalho passe através do sistema desde o
início (Ponto de comprometimento) até a conclusão
• Delivery rate (Taxa de entrega) é o número de itens de
trabalho completos por unidade de tempo, tais como
características por semana, aulas de treinamento por
meses, ou novas contratações por mês
• WIP (trabalho em progresso) é a quantidade de itens
de trabalho no sistema (ou uma parte definida dele)
em um determinado momento no tempo
Cadências do Kanban
Scrum
Metodologia Ágil
Metodologia Tradicional
O que é o Scrum?
• Scrum é um framework Ágil, simples e leve,
utilizado para a gestão do desenvolvimento
de produtos complexos imersos em ambientes
complexos.
• Scrum é embasado no empirismo e utiliza
uma abordagem iterativa e incremental para
entregar valor com frequência e, assim,
reduzir os riscos do projeto.
Scrum
• O termo Scrum (pron. [skrʌm]) é um método de
reinício de jogada no rugby, onde os jogadores
dos dois times se juntam com a cabeça abaixada
e se empurram com o objetivo de ganhar a posse
de bola.
• A relação entre a jogada do rugby e a

metodologia ágil é em função da equipe
heterogênea, onde usar o melhor de cada perfil
na equipe é a chave para vencer.
Papéis no Scrum
Product Owner
Scrum Master
Papéis no Scrum
• Product Owner
– O Product Owner é a pessoa que define os itens que compõem
o Product Backlog e os prioriza nas Sprint Planning Meetings.
• Scrum Master
– O Scrum Master procura assegurar que a equipe respeite e siga
os valores e as práticas do Scrum. Ele também protege a equipe
assegurando que ela não se comprometa excessivamente com
relação àquilo que é capaz de realizar durante um Sprint.
• Scrum Team
– O Scrum Team é a equipe de desenvolvimento. Todos no projeto
trabalham juntos para completar o conjunto de trabalho com o
qual se comprometeram conjuntamente para um Sprint.
– Um Scrum Team típico tem de 6 a 10 pessoas
Scrum
Scrum
• No Scrum, os projetos são dividos em ciclos (tipicamente mensais)
chamados de Sprints.
• O Sprint representa um Time Box dentro do 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 de cada Sprint, faz-se um Sprint Planning Meeting, ou

seja, uma reunião de planejamento na qual o Product
Owner prioriza os itens do Product Backlog e 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.
Scrum
• A cada dia de uma Sprint, a equipe faz uma breve
reunião (normalmente de manhã), chamada Daily
Scrum. O objetivo é disseminar 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 Sprint Review
Meeting. Finalmente, faz-se uma Sprint
Retrospective e a equipe parte para o planejamento do
próximo Sprint. Assim reinicia-se o ciclo.
Product Backlog
• O Product Backlog é uma lista contendo todas as
funcionalidades desejadas para um produto. O
conteúdo desta lista é definido pelo Product
Owner.
• O Product Backlog não precisa estar completo

no início de um projeto. Pode-se começar com
tudo aquilo que é mais óbvio em um primeiro
momento. Com o tempo, o Product Backlog
cresce e muda à medida que se aprende mais
sobre o produto e seus usuários.
Sprint
Sprint
• O coração do Scrum é a Sprint, um time-boxed de um mês ou
menos, durante o qual um “Pronto”, versão incremental
potencialmente utilizável do produto, é criado.
• Sprints tem durações coerentes em todo o esforço de

desenvolvimento.
• As Sprints são compostas por uma reunião de planejamento da
Sprint, reuniões diárias, o trabalho de desenvolvimento, uma
revisão da Sprint e a retrospectiva da Sprint.
• Durante a Sprint:
– Não são feitas mudanças que possam por em perigo o objetivo da
Sprint;
– As metas de qualidade não diminuem; e,
– O escopo pode ser clarificado e renegociado entre o Product Owner e
o Time de Desenvolvimento quanto mais for aprendido.
Sprint
• Cada Sprint pode ser considerada um projeto
com horizonte não maior que um mês. Como os
projetos, as Sprints são utilizadas para realizar
algo.
• Cada Sprint tem a definição do que é para ser
construído, um plano projetado e flexível que irá
guiar a construção, o trabalho e o resultado do
produto.
• Sprints permitem previsibilidade que garante a
inspeção e adaptação do progresso em direção à
meta pelo menos a cada mês corrido.
Sprint Backlog
• O Sprint Backlog é uma lista de tarefas que o Scrum
Team se compromete a fazer em um Sprint. Os itens do
Sprint Backlog são extraídos do Product Backlog, pela
equipe, com base nas prioridades definidas
pelo Product Owner e a percepção da equipe sobre o
tempo que será necessário para completar as várias
funcionalidades.
• Cabe a equipe determinar a quantidade de itens

do Product Backlog que serão trazidos para o Sprint
Backlog, já que é ela quem irá se comprometer a
implementá-los.
Sprint Backlog
• Durante um Sprint, o Scrum Master mantém o
Sprint Backlog atualizando-o para refletir que
tarefas são completadas e quanto tempo a
equipe acredita que será necessário para
completar aquelas que ainda não estão prontas.
• A estimativa do trabalho que ainda resta a ser

feito no Sprint é calculada diariamente e colocada
em um gráfico, resultando em um Sprint
Burndown Chart.
Scrum – The Scrum Board
Product Backlog Sprint Backlog In Progress Done
Sprint Planning
• O trabalho a ser realizado na Sprint é
planejado na reunião de planejamento da
Sprint. Este plano é criado com o trabalho
colaborativo de todo o Time Scrum. Reunião
de planejamento da Sprint possui um time-
box com no máximo oito horas para uma
Sprint de um mês de duração.
Sprint Planning
Daily Scrum
• A cada dia do Sprint a equipe faz uma reunião diária,
chamada Daily Scrum. Ela tem como objetivo disseminar
conhecimento sobre o que foi feito no dia anterior,
identificar impedimentos e priorizar o trabalho a ser
realizado no dia que se inicia.
• Os Daily Scrums normalmente são realizadas no mesmo
lugar, na mesma hora do dia. Idealmente são realizados na
parte da manhã, para ajudar a estabelecer as prioridades
do novo dia de trabalho.
• Durante o Daily Scrum, cada membro da equipe provê
respostas para cada uma destas três perguntas:
– O que você fez ontem?
– O que você fará hoje?
– Há algum impedimento no seu caminho?
Sprint – Daily Scrum
Sprint Review
• A Revisão da Sprint é executada no final da Sprint para
inspecionar o incremento e adaptar o Backlog do Produto
se necessário. Durante a reunião de Revisão da Sprint o
Time Scrum e as partes interessadas colaboram sobre o
que foi feito na Sprint. Com base nisso e em qualquer
mudança no Backlog do Produto durante a Sprint, os
participantes colaboram nas próximas coisas que podem
ser feitas para otimizar valor.
• Esta é uma reunião informal, não uma reunião de status, e
a apresentação do incremento destina-se a motivar e
obter comentários e promover a colaboração.
• Esta é uma reunião time-boxed de 4 horas de duração para
uma Sprint de um mês.
Sprint Review
Sprint Retrospective
• A Retrospectiva da Sprint é uma oportunidade
para o Time Scrum inspecionar a si próprio e
criar um plano para melhorias a serem
aplicadas na próxima Sprint.
• A Retrospectiva da Sprint ocorre depois da

Revisão da Sprint e antes da reunião de
planejamento da próxima Sprint. Esta é uma
reunião time-boxed de três horas para uma
Sprint de um mês.
Sprint Retrospective
Estimando no Scrum – Planning Poker
• A técnica Planning Poker foi popularizada por Mike
Cohn no livro Agile Estimating and Planning no qual
registrou o termo Planning Poker (PP). É uma técnica
de estimativa de tamanho voltada para as
metodologias ágeis de desenvolvimento de software.
• O Planning Poker consiste-se em obter a estimativa
por meio de um jogo de cartas, que deve permitir que
todos os membros da equipe participem colocando a
sua visão de complexidade, levando em consideração o
fator tempo e esforço para pontuar um cartão e após
juntos chegar a um denominador comum na equipe
através de consenso.
• No Planning Poker cada integrante tem a sua
disposição um baralho de 13 cartas. As cartas
contém os tamanhos de 0, ½, 1, 2, 3, 5, 8, 13,
20, 40 e 100 que serão atribuídos a um cartão,
havendo ainda uma carta com o símbolo de
interrogação no qual representa que o
estimador não está apto a estimar e outra
carta com a imagem de uma xícara de café no
qual representa a sugestão de uma pausa.
Leia mais em: http://www.devmedia.com.br/scrum-e-planning-poker-analise-de-estimativa-de-software/31019#ixzz41NryKXl6
• Durante o Planning Poker devem ser realizadas
rodadas para obter a estimativa de um cartão
que possui uma tarefa a desenvolver.
• As diferenças que surgirem durante as rodadas
deverão ser mediadas por um coordenador, que
no Scrum este papel é de responsabilidade
do Scrum Master.
• O Product Owner, é o responsável por explicar o
que deverá ser desenvolvido, sendo um
importante papel para retirar possíveis dúvidas a
respeito do cartão, evitando assim, o retrabalho.
Planning Poker
https://pbs.twimg.com/media/Ek9cGMxWkAozNWQ?format=png&name=large
https://miro.medium.com/max/875/1*cTEkZOm4GHSPh9JBt6iLZQ.png
Aula 04
Engenharia de
Requisitos
The hardest single part of building a software
system is deciding precisely what to build. –
Frederick Brooks
Agenda
• Requisitos funcionais e não funcionais
• Processos de engenharia de requisitos
• Elicitação de requisitos
• Especificação de requisitos
• Validação de requisitos
• Mudança de requisitos
Requisitos
• Os requisitos de um sistema são as descrições
dos serviços que o sistema deve prestar e suas
restrições.
• Esses requisitos refletem as necessidades dos
clientes de um sistema que atende a um
determinado propósito.
• O processo de descoberta, análise,
documentação e conferência desses serviços e
restrições é chamado de engenharia de
requisitos (ER).
Requisitos
• Os requisitos de usuário e os requisitos de sistema podem ser
definidos da seguinte forma:
1. Requisitos de usuário são declarações, em uma linguagem natural

somada a diagramas, dos serviços que se espera que o sistema
forneça para os usuários e das limitações sob as quais ele deve
operar. Esses requisitos podem variar de declarações amplas das
características necessárias do sistema até descrições precisas e
detalhadas da sua funcionalidade.
2. Requisitos de sistema são descrições mais detalhadas das

funções, dos serviços e das restrições operacionais do sistema de
software. O documento de requisitos de sistema (chamado às
vezes de especificação funcional) deve definir exatamente o que
deve ser implementado. Pode fazer parte do contrato entre o
adquirente do sistema e os desenvolvedores de software
Requisitos funcionais e não-funcionais
• Os requisitos de sistema de software são classificados
frequentemente como funcionais ou não funcionais:
1. Requisitos funcionais. São declarações dos serviços que o sistema

deve fornecer, do modo como o sistema deve reagir a
determinadas entradas e de como deve se comportar em
determinadas situações. Em alguns casos, os requisitos funcionais
também podem declarar explicitamente o que o sistema não deve
fazer.
2. Requisitos não funcionais. São restrições sobre os serviços ou
funções oferecidas pelo sistema. Eles incluem restrições de
tempo, restrições sobre o processo de desenvolvimento e
restrições impostas por padrões. Os requisitos não funcionais se
aplicam, frequentemente, ao sistema como um todo, em vez de
às características individuais ou aos serviços
Requisitos funcionais
• Os requisitos funcionais de um sistema descrevem o que ele deve
fazer e dependem do tipo de software que está sendo
desenvolvido, dos usuários esperados para o software e da
abordagem geral adotada pela organização ao escrever os
requisitos.
• Quando são apresentados como requisitos de usuário, os requisitos

funcionais devem ser escritos de modo compreensível para os
usuários e gerentes do sistema.
• Os requisitos funcionais do sistema expandem os requisitos de

usuário e são escritos para os desenvolvedores.
• Requisitos funcionais devem descrever em detalhes as funções do

sistema, suas entradas, saídas e exceções
Requisitos funcionais
• A imprecisão na especificação de requisitos pode
levar a conflitos entre clientes e desenvolvedores
de software.
• É normal que um desenvolvedor de sistemas
interprete um requisito ambíguo de uma forma
que simplifique a sua implementação.
• Muitas vezes, porém, não é isso o que o cliente
quer. Novos requisitos devem ser estabelecidos e
mudanças devem ser feitas, o que resulta em
atraso na entrega do sistema e aumento dos
custos.
Requisitos não funcionais
• Os requisitos não funcionais são aqueles que não
possuem relação direta com os serviços específicos
fornecidos pelo sistema aos seus usuários.
• Esses requisitos não funcionais normalmente

especificam ou restringem as características do
sistema como um todo. Eles podem estar
relacionados a propriedades emergentes do sistema,
como confiabilidade, tempo de resposta e uso da
memória
• Embora muitas vezes seja possível identificar quais componentes do
sistema implementam requisitos funcionais específicos (por exemplo,
pode haver componentes de formatação que implementem requisitos de
relatório), isso é mais difícil com os requisitos não funcionais. Sua
implementação pode estar espalhada por todo o sistema por duas razões:
1. Os requisitos não funcionais podem afetar a arquitetura geral de um
sistema em vez de seus componentes individuais. Por exemplo, para garantir
que sejam cumpridos os requisitos de desempenho em um sistema, pode
ser necessário organizá-lo a fim de minimizar a comunicação entre seus
componentes.
2. Um requisito não funcional individual, como um requisito de segurança da
informação (security), pode gerar vários requisitos funcionais relacionados
que definem novos serviços do sistema que se fazem necessários caso o
requisito não funcional seja implementado. Além disso, também pode gerar
requisitos que restringem outros requisitos existentes: por exemplo, pode
limitar o acesso à informação no sistema
Os requisitos não funcionais surgem das necessidades dos usuários, que podem ser
classificados como:
1. Requisitos do produto. Esses requisitos especificam ou restringem o

comportamento do software durante a execução. Os exemplos incluem
requisitos de desempenho, relativos à rapidez com que o sistema deve executar
e de quanta memória ele precisa; requisitos de confiabilidade, que estabelecem
a taxa de falha aceitável; requisitos de segurança da informação (security); e
requisitos de usabilidade.
2. Requisitos organizacionais. São requisitos de sistema amplos, derivados das

políticas e procedimentos nas organizações do cliente e do desenvolvedor. Os
exemplos incluem requisitos de processos operacionais, que definem como o
sistema será utilizado; requisitos de processos de desenvolvimento, que
especificam a linguagem de programação, o ambiente de desenvolvimento ou os
padrões de processo a serem utilizados; e os requisitos ambientais, que
especificam o ambiente operacional do sistema.
3. Requisitos externos. Esse título abrangente cobre todos os
requisitos derivados de fatores externos ao sistema e seu
processo de desenvolvimento. Podem incluir requisitos
regulatórios, que estabelecem o que deve ser feito para o
sistema ser aprovado por uma entidade reguladora;
requisitos legislativos, que devem ser seguidos para garantir
que o sistema opere dentro da lei; e requisitos éticos, que
garantem que o sistema será aceitável para os usuários e
para o público em geral.
Sempre que possível, os requisitos não funcionais devem ser escritos de
forma quantitativa para que possam ser testados objetivamente e, portanto,
para conferir se ele cumpriu ou não seus requisitos não funcionais.
Processos de
Eng de Requisitos
Processos de Eng de Requisitos
• As atividades são organizadas como um processo iterativo em
torno de uma espiral, e o resultado do processo de ER é um
documento de requisitos de sistema. A quantidade de tempo
e esforço dedicados a cada atividade em uma iteração
depende do estágio do processo geral, do tipo de sistema a
ser desenvolvido e do orçamento disponível.
• No início do processo, a maior parte do esforço é dedicada à

compreensão do negócio em alto nível e dos requisitos não
funcionais, além dos requisitos de usuário.
• Em uma etapa mais avançada do processo, mais esforço será
dedicado à elicitação e à compreensão dos requisitos não
funcionais e dos requisitos de sistema mais detalhados.
Elicitação de
Requisitos
Elicitação de Requisitos
• Os objetivos do processo de elicitação de requisitos são
compreender o trabalho que os stakeholders realizam e
entender como usariam um novo sistema para apoiar o
trabalho deles
• Durante a elicitação de requisitos, os engenheiros de

software trabalham com os stakeholders para saber
mais sobre o domínio da aplicação, as atividades
envolvidas no trabalho, os serviços e as características
do sistema que eles querem, o desempenho desejado
para o sistema, as limitações de hardware etc.
Elicitar e compreender os requisitos dos stakeholders no
sistema é um processo difícil por várias razões:
1. Muitas vezes os stakeholders não sabem o que querem

de um sistema de computador, exceto em aspectos mais
gerais; eles podem achar difícil articular o que querem
que o sistema faça; podem fazer exigências irreais porque
não sabem o que é viável ou não.
2. Em um sistema, é natural que os stakeholders expressem

os requisitos em seus próprios termos e com
conhecimento implícito de seu próprio trabalho. Os
engenheiros de requisitos, sem experiência no domínio do
cliente, podem não entender tais requisitos.
3. Diferentes stakeholders, com requisitos distintos, podem
expressá-los de maneiras variadas. Os engenheiros de requisitos
têm de descobrir todas as possíveis fontes de requisitos, além dos
pontos de convergência e de conflito.
4. Fatores políticos podem influenciar os requisitos de um sistema.

Os gerentes podem exigir requisitos de sistema específicos, o que
lhes permite aumentar sua influência na organização.
5. O ambiente econômico e de negócios no qual a análise ocorre é

dinâmico. Inevitavelmente, ele muda durante o processo de
análise. A importância de determinados requisitos pode mudar.
Novos requisitos podem surgir de novos stakeholders que não
foram consultados originalmente.
• Um modelo padrão do processo de elicitação e análise pode ser
visto abaixo. Cada organização terá sua própria versão ou
instanciação desse modelo geral, dependendo de fatores locais
como a experiência da equipe, o tipo de sistema sendo
desenvolvido e os padrões utilizados.
As atividades de processo são:
1. Descoberta e compreensão dos requisitos. Esse é o processo de interagir com os

stakeholders do sistema para descobrir seus requisitos. Os requisitos de domínio
dos stakeholders e documentação também são descobertos durante essa
atividade.
2. Classificação e organização dos requisitos. Essa atividade pega o conjunto não

estruturado de requisitos, agrupa os requisitos relacionados e os organiza em
grupos coerentes.
3. Priorização e negociação dos requisitos. Inevitavelmente, quando estão

envolvidos vários stakeholders, os requisitos entrarão em conflito. Essa atividade
está relacionada com a priorização dos requisitos e com a descoberta e
negociação para resolução de conflitos.
4. Documentação dos requisitos. Os requisitos são documentados e servem de

entrada para a próxima volta da espiral. Um rascunho inicial pode ser produzido
nesse estágio ou os requisitos podem simplesmente ser mantidos de modo
informal em lousas, wikis ou outros espaços compartilhados.
Especificação de
Requisitos
Especificação de Requisitos
• A especificação de requisitos é o processo de
escrever os requisitos de usuário e de sistema em um
documento de requisitos. Em condições ideais, esses
requisitos devem ser claros, inequívocos, fáceis de
entender, completos e consistentes.
• Notações para escrever requisitos
• Especificação estruturada de um requisito
• Para usar uma abordagem estruturada para especificar requisitos
de sistema, é preciso definir um ou mais templates para os
requisitos e representá-los como formulários estruturados.
• Quando um template é empregado para especificar requisitos
funcionais, as seguintes informações devem ser incluídas:
1. uma descrição da função ou entidade que está sendo especificada;
2. uma descrição das entradas e suas origens:
3. uma descrição das saídas e sua destinação;
4. informações sobre os dados necessários para computar ou outras
entidades no sistema que sejam necessárias (a parte ‘requer’);
5. uma descrição da ação a ser tomada;
6. se for utilizada uma abordagem funcional, uma precondição
estabelecendo o que deve ser verdadeiro antes da função ser
invocada e uma pós-condição especificando o que é verdadeiro após
a função ser invocada;
7. uma descrição dos efeitos colaterais (se houver) da operação.
Casos de Uso
• Os casos de uso são uma maneira de descrever as
interações entre usuários e um sistema usando
um modelo gráfico e um texto estruturado.
• Os casos de uso são documentados por meio de

um diagrama de casos de uso de alto nível.
• O conjunto de casos de uso representa todas as

interações possíveis que serão descritas nos
requisitos de sistema.
Casos de Uso
• Os atores no processo, que podem ser seres humanos
ou outros sistemas, são representados como 'bonecos
palito’.
• Cada classe de interação é representada como uma

elipse nomeada.
• Linhas fazem a ligação entre os atores e a interação.
• Opcionalmente, pontas de seta podem ser

acrescentadas às linhas para mostrar como a interação
começa.
Casos de Uso
• https://medium.com/operacionalti/uml-
diagrama-de-casos-de-uso-29f4358ce4d5
Documento de Requisitos
• O documento de requisitos de software (às vezes
chamado de especificação de requisitos de software
ou ERS – em inglês SRS) é uma declaração oficial do
que os desenvolvedores do sistema devem
implementar.
• Ele pode incluir os requisitos de usuário para um

sistema e uma especificação detalhada dos requisitos
de sistema.
BRD
• https://templatelab.com/brd-templates/
Validação de Requisitos
• A validação de requisitos é o processo de conferir
se os requisitos definem o sistema que o cliente
realmente quer.
• A validação de requisitos é criticamente

importante porque os erros em um documento
de requisitos podem levar a grandes custos de
retrabalho quando esses problemas são
descobertos durante o desenvolvimento ou após
o sistema entrar em serviço
• O custo de corrigir um problema nos
requisitos com uma alteração no sistema
normalmente é muito maior do que o de
consertar erros de projeto ou de código.
• Uma mudança nos requisitos significa,

geralmente, que o projeto e a implementação
do sistema também deverão ser modificados.
Durante o processo de validação de requisitos, diferentes tipos
de conferências devem ser executados nos requisitos do
documento, incluindo:
1. Conferência da validade. Confere se os requisitos refletem

as reais necessidades dos usuários do sistema.
2. Conferência da consistência. Os requisitos no documento

não devem entrar em conflito entre si.
continua...
3. Conferência da completude. O documento de requisitos deve
incluir aqueles que definem todas as funções e as restrições
pretendidas pelo usuário do sistema.
4. Conferência do realismo. Usando o conhecimento das tecnologias

existentes, os requisitos devem ser conferidos para assegurar que
possam ser implementados dentro do orçamento proposto para o
sistema.
5. Verificabilidade. Os requisitos do sistema sempre devem ser

escritos de modo que sejam verificáveis. Isso significa ser capaz de
escrever um conjunto de testes que possam demonstrar que o
sistema entregue satisfaz cada um dos requisitos especificados.
Uma série de técnicas de validação de requisitos pode ser utilizada
individualmente ou em conjunto:
1. Revisões de requisitos. Os requisitos são analisados

sistematicamente por uma equipe de revisores que conferem
erros e inconsistências.
2. Prototipação. Isso envolve o desenvolvimento de um modelo

executável do sistema e o uso desse modelo com os usuários
finais e clientes para ver se satisfaz suas necessidades e
expectativas. Os stakeholders experimentam o sistema e opinam
sobre mudanças nos requisitos para o time de desenvolvimento.
3. Geração de casos de teste. Os requisitos devem ser testáveis. Os

casos de testes frequentemente revelam problemas nos
requisitos. * Desenvolver testes a partir dos requisitos de usuário antes de qualquer código
ser escrito faz parte do desenvolvimento dirigido por testes (TDD)
Mudanças de Requisitos
• Os requisitos podem mudar, seja por um erro
na especificação do requisito, por
entendimento incompleto do problema
devido sua complexidade, ou por mudança no
produto esperado.
• Devido ao ambiente atual ser muito volátil,

instável, frágil, precisamos estar preparados
para aceitar as mudanças (agilidade).
Gerenciamento de Mudanças
• O gerenciamento de mudança de requisitos deve ser aplicado
a todas as mudanças propostas para os requisitos de um
sistema após a aprovação do documento de requisitos.
• O gerenciamento de mudança é essencial para decidir se os
benefícios de implementar novos requisitos são justificados
pelos custos de sua implementação.
Gerenciamento de Mudanças
• Existem três estágios principais em um processo de gerenciamento
de mudança:
1. Análise do problema e especificação da mudança. O processo

começa com a identificação de um problema de requisito (ou,
com uma proposta de mudança), e, é analisado para averiguar se
é válido.
2. Análise da mudança e estimativa de custo. O efeito da mudança

proposta é avaliado com base nas informações de rastreabilidade
e no conhecimento geral dos requisitos do sistema. O custo de
fazer a mudança é estimado. Então, toma-se uma decisão de
proceder ou não com a mudança de requisitos.
3. Implementação da mudança. Os documentos de requisitos são

modificados.
User Story
User Story
• História de usuário é um jeito bastante simples e eficiente de representar
um requisito de software ou descrever uma funcionalidade, pois foca na
linguagem de negócio e não se preocupa em detalhar a parte técnica,
muito menos em tentar descrever o “como" uma funcionalidade será
implementada.
• Sua principal característica é representar um requisito de software sob a

perspectiva do usuário final, incluindo os diferentes tipos de usuários e
focando no resultado que este usuário está tentando atingir, bem como no
valor que aquilo trará àquele usuário.
• As histórias de usuário são excelentes alternativas para facilitar a conversa

entre o Product Owner (Dono do produto) e o time, permitindo que o foco
dessa conversa seja no resultado e no valor que uma determinada
funcionalidade trará ao usuário final, ao invés de no ‘como’ uma
funcionalidade será implementada tecnicamente.
User Story
Aplicação
• Histórias de usuário são mais indicadas
quando o usuário ou tipo de usuário é o foco
central da ação e geralmente ocorrem em
situações onde deseja-se criar algo novo,
novos requisitos ou novas funcionalidades de
software.
User Story
• Formato
Como um <Tipo de usuário>
Eu quero <Ação/Objetivo>
Para que <Porque/Resultado esperado>
Improvement Story
• Improvement Stories, ou “histórias para
melhoria”, são alternativas bastante
interessantes às histórias de usuário e
funcionam muito bem em situações em que
deseja-se melhorar uma funcionalidade
existente, desde que essa melhoria seja
relativamente pequena e bastante óbvia, pois
focam na solução daquela situação.
Improvement Story
• Aplicação
As Improvement Stories são recomendas em
produtos de software mais “maduros”, bem depois
da entrega do MVP (Minimum Viable Product -
Produto Minimamente Viável), geralmente em
suporte ou BAU (Business as Usual).
Improvement Story
• Formato
Nós temos <Situação do momento>
Nós queremos ter <Situação desejada>
Para que <Porque/Resultado esperado>
Technical Story
• Como o nome sugere, as Technical Stories são
mais focadas na parte técnica da
implementação e são usadas principalmente
em “SPIKES”, embora também possam ser
usadas para identificação de requisitos não
funcionais.
Technical Story
• Aplicação
Technical Stories são recomendadas quando se
deseja descrever requisitos técnicos, não funcionais
e/ou SPIKES.
Technical Story
• Formato
A fim de OU Para <Atingir um objetivo>, <um
sistema ou persona> precisa < 'Fazer' alguma ação>
Resultado esperado: <Relatório da investigação> OU
<Lista de ações que serão incorporadas no backlog>
Technical Story
Bug
• Bug, falha ou defeito. Modelo genérico o
bastante para poder ser utilizado em
praticamente todas essas situações, e que tem
se demonstrado bastante eficaz na
identificação e reprodução de problemas
deste gênero.
Bug
• Aplicação
Este template pode ser utilizado para identificação,
reprodução e resolução de bugs, defeitos, falhas ou
erros de software.
Bug
• Formato
Título <Breve descrição do problema>
Passo-a-passo <Passo-a-passo de como reproduzir o
problema>
1. Passo 1
2. Passo 2
3. …
Comportamento esperado <Saída
esperada/correta>
Comportamento atual <Saída atual>
Use Case
• Use Cases descrevem uma sequência de ações que
permitirão a um ator atingir um ou mais objetivos.
Geralmente, eles estão relacionados a um processo
bem definido e basicamente descrevem de uma
maneira bem estruturada, as interações entre o
sistema que será construído e seus atores, que pode
ser uma pessoa, um sub-sistema ou um dispositivo
físico que interage com esse sistema.
Use Case
• Aplicação
Casos de uso podem ser usados em projetos onde
seja necessário documentar todos os requisitos de
uma vez e em bastante detalhe.
Use Case
• Formato
Objetivo <O que o ator quer atingir>
Pré-condições <Condições que devem ser verdade
antes do caso de uso iniciar>
Ator primário <Usuários, papéis, tipos de usuários>
Cenário principal de sucesso <Descreve o passo-a-
passo de um caso de uso de sucesso>
Pós-condições <Condições que são verdades após
um caso de uso encerrar com sucesso>
Aula 00
“O engenheiro de software amador está sempre à procura da mágica,
de algum método sensacional ou ferramenta cuja aplicação
promete tornar trivial o desenvolvimento de software. É uma
característica do engenheiro de software profissional saber que tal
panaceia não existe.”
GRADY BOOCH
Controle de Versão
Controle de Versão
• O controle de versão, também conhecido
como controle de fonte, é a prática de rastrear
e gerenciar as alterações em um código de
software.
• Os sistemas de controle de versão (SCV ou

VCS) são ferramentas de software que ajudam
as equipes de software a gerenciar as
alterações ao código-fonte ao longo do tempo.
Controle de Versão
• O software de controle de versão mantém
registro de todas as modificações no código
em um tipo especial de banco de dados.
• Se um erro for cometido, os desenvolvedores

podem voltar no tempo e comparar versões
anteriores do código para ajudar a corrigir o
erro enquanto diminuem interrupções para
todos os membros da equipe.
Controle de Versão
Principais vantagens
• Controle do histórico: facilidade em desfazer e possibilidade de
analisar o histórico do desenvolvimento.
• Trabalho em equipe: permite que diversas pessoas trabalhem

sobre o mesmo conjunto de documentos ao mesmo tempo e
minimiza o desgaste provocado por problemas com conflitos de
edições.
• Marcação e resgate de versões estáveis: marcar onde é que o

documento estava com uma versão estável, podendo ser facilmente
resgatado no futuro.
• Ramificação de projeto: possibilita a divisão do projeto em várias

linhas de desenvolvimento, que podem ser trabalhadas
paralelamente, sem que uma interfira na outra.
Principais vantagens
• Segurança: mecanismos para evitar qualquer tipo de invasão
de agentes infecciosos nos arquivos. E, somente usuários com
permissão poderão mexer no código.
• Rastreabilidade: Com a necessidade de sabermos o local, o

estado e a qualidade de um arquivo; o controle de versão traz
todos esses requisitos de forma que o usuário possa se
embasar do arquivo que deseja utilizar.
• Confiança: O uso de repositórios remotos (na nuvem) ajuda a

não perder arquivos por eventos inesperados.
Mais usados
• Free
Mais usados
• Comerciais
Mais usados
Centralizado vs Distribuído
• Os sistemas de controle de versão possuem 2 formas
de operam o controle dos arquivos, sendo:
• Centralizado, onde o VCS fica instalado em um

servidor, todos os arquivos e controles de histórico
ficam nele.
• Distribuído, onde o VCS fica instalado em todas as

máquinas que utilizam o controle de versão,
portanto há arquivos e históricos distribuídos
individualmente.
Subversion
• Subversion é um exemplo de VCS centralizado
Git
• Git é um exemplo de VCS distribuído
Git As A Service
• Git nos permite criar um reporitório local para rastrear as
mudanças de um único usuário o qual criou o servidor git
local. Nós perdemos esses arquivos e rastros de mudanças
quando o sistema quebra. Não é possível recuperar um
código perdido ou um repositório criado localmente.
• Para superar esse problema podemos hospedar o servidor

git em uma máquina remota e sincronizar o repositório
local com o repositório remote.
• Tal servidor git hospedado remotamente pode ser criado

por você mesmo, ou você pode utilizar algum dos serviços
como Github, Bitbucket e Gitlab.
Git As A Service
IaaS, PaaS e SaaS
IaaS, PaaS e SaaS
Git - Iniciando
• Instale o Git na sua máquina
– https://git-scm.com/downloads
• Crie uma conta em algum serviço de Git

– https://github.com/signup
– https://gitlab.com/users/sign_up/
– https://bitbucket.org
Git – Comandos básicos
• https://training.github.com/downloads/pt_BR
/github-git-cheat-sheet/
• https://education.github.com/git-cheat-sheet-
education.pdf
• https://dev-to-
uploads.s3.amazonaws.com/uploads/articles/
n082uxea33j6zq3mca7u.png
Git - Iniciando
• Crie um repositório remoto
– Via interface web, depende do SaaS escolhido
• Clone o repositório localmente
– git clone [url]
• Adicione arquivos
https://www.themezy.com/free-website-templates
– git add [file] https://www.free-css.com/free-css-templates
• Commit no repo local

– git commit -m “[descrição]”
Git - Iniciando
• “Empurre” para o servidor remoto
– git push [branch]
• Causem conflito e resolvam
– 2 pessoas devem editar o mesmo trecho de
código
– As 2 pessoas devem enviar para o server remoto
– 1 delas não irá conseguir, e precisar dar pull,
resolver o conflito e dar push novamente
Dica: os comandos do Git são do ponto de vista do repo atual, ou seja, de
onde você está dando o comando. Portanto o push é sempre “empurrar”
do local para o remoto; o pull é sempre “puxar” do remoto para o local
Git - Iniciando
• Check o status do seu repositório
– git status
• Compare as mudanças
– git diff
Git Branches
• Quando desenvolvemos um projeto, independentemente
se há um time de pessoas ou só uma, é muito importante
nos preocuparmos com versões e ramificações de código.
Para isso, existem branches.
• Um exemplo clássico do uso de branches é quando temos

um projeto funcionando e precisamos modificar uma das
funcionalidades desse projeto. Se mexermos direto,
podemos quebrar o que já está funcionando e causar uma
série de problemas. Mas quando criamos um branch,
conseguimos fazer alterações, parar o desenvolvimento,
retornar depois de um tempo, tudo isso sem alterar o que
já está funcionando.
Git Branches
• Figura
desenvolvimento
paralelo
Git Branches
• Crie um branch
https://dev.to/couchcamote/git-
– git branch [nome-da-branch] branching-name-convention-cch
• Alterne para a nova branch

– git checkout [nome-da-branch]
• Edite algum arquivo e commit
• Empurre a branch para o servidor remoto
– git push origin [nome-da-branch]
• Verifique na interface web do servidor remoto
a existência do branch e as alterações
Git Branches
• Trasporte as alterações da nova branch para a
main
– git checkout main
– git merge [nome-da-branch]
• Suba as novas mudanças do main para o
servidor remoto
Git - Desfazendo
• Retirar um arquivo do stage
– git reset HEAD [nome-do-arquivo]; ou,
– git restore --staged [nome-do-arquivo]
• Retirar um arquivo do commit mais recente
não feito push
– git rm –cached [nome-do-arquivo]
– git commit --amend
Git - Desfazendo
• Pegando uma versão anterior
– git checkout [commit-id]
.gitignore
• Os arquivos ignorados costumam ser artefatos de
desenvolvimento e arquivos gerados por máquina que
podem ser derivados da fonte do seu repositório ou que
não devem passar por commit. Exemplos comuns incluem:
– caches de dependência, como o conteúdo de /node_modules

ou /packages
– código compilado, como arquivos .o, .pyc e .class
– diretórios de saída de build, como /bin, /out ou /target
– arquivos gerados no período de execução, como .log, .lock ou
.tmp
– arquivos de sistema ocultos, como .DS_Store ou Thumbs.db
– arquivos pessoais de configuração do IDE, como
.idea/workspace.xml
.gitignore
• Os arquivos ignorados são rastreados em um arquivo
especial chamado .gitignore, que é verificado na
origem do seu repositório.
• Não há nenhum comando git ignore explícito: é preciso

editar e fazer commit do arquivo .gitignore à mão
quando você tiver novos arquivos que quer ignorar.
• Os arquivos .gitignore contêm padrões que são

comparados com nomes de arquivos em seu
repositório para determinar se devem ou não ser
ignorados.
https://www.atlassian.com/br/git/
tutorials/saving-changes/gitignore
Git Flow
• https://blog.betrybe.com/git/git-flow/
Git GUI
• Terminal não é pra mim. O que eu faço?
– Procure plugins para sua IDE; ou,
– https://git-scm.com/downloads/guis
– https://www.hostinger.com.br/tutoriais/git-gui
Aprofunde
• Conventional Commits
https://www.conventionalcommits.org/en/v1.0.0-beta.2/
• README.md
https://www.alura.com.br/artigos/escrever-bom-readme
Aula 9
“Ciência da Computação está tão relacionada aos computadores
quanto a Astronomia aos telescópios, Biologia aos microscópios, ou
Química aos tubos de ensaio. A Ciência não estuda ferramentas. Ela
estuda como nós as utilizamos, e o que descobrimos com elas.”
EDSGER WYBE DIJKSTRA
Modelagem de Sistemas
• A modelagem de sistemas é um processo de
desenvolvimento de modelos abstratos de um
sistema, em que cada modelo apresenta uma
visão ou perspectiva diferente desse sistema.
• Modelagem de sistemas significa,

basicamente, representar um sistema usando
algum tipo de notação gráfica baseada nos
tipos de diagrama em UML (Unified Modeling
Language).
• A UML possui 14 tipos de diagramas e, portanto, permite a
criação de diversos tipos de modelos de sistema.
• Os 5 principais são:
1. diagramas de atividades, que mostram as atividades
envolvidas em um processo ou no processamento de dados;
2. diagramas de caso de uso. que mostram as interações entre
um sistema e seu ambiente;
3. diagramas de sequência, que mostram as interações entre os
atores e o sistema e entre os componentes do sistema;
4. diagramas de classes, que mostram as classes de objetos no
sistema e as associações entre elas;
5. diagramas de máquinas de estados, que mostram como o
sistema reage a eventos internos e externos.
Modelos de Contexto
• No estágio inicial da especificação de um sistema,
deve-se decidir sobre seus limites, ou seja, sobre o que
faz e o que não faz parte do sistema que está sendo
desenvolvido.
• É preciso levantar todas as possíveis sobreposições em

termos de funcionalidade com os sistemas existentes e
decidir onde a nova funcionalidade será
implementada. Essas decisões devem ser tomadas o
quanto antes para limitar os custos e o tempo
necessário para compreender os requisitos e o projeto
(design) do sistema.
Modelos de Contexto
• Normalmente, os modelos de contexto mostram que
o ambiente inclui vários outros sistemas
automatizados; no entanto, não mostram os tipos de
relações entre os sistemas.
• Esses modelos descrevem processos humanos e

automatizados nos quais são utilizados determinados
softwares
Modelos de Contexto
• Em dias atuais os modelos de sistemas são
amplamente usados entre desenvolvedores
para analisar sistemas existem ou planejar a
criação de um.
• Apesar dos modelos poderem ser utilizados

para documentação em alto nível de detalhes
e até mesmo para geração de software sem
codificação, essas não são suas maiores
utilidades.
Duas situações principais de uso da UML:
• Engenharia Avante (Forward Engineering): quando os desenvolvedores usam

modelos UML para discutir e analisar alternativas de design, antes que exista
qualquer código. Por exemplo, suponha que uma história tenha sido alocada para
o sprint corrente. Antes de implementar a história, os desenvolvedores podem se
reunir e fazer um esboço das principais classes que deverão ser criadas no sistema,
bem como dos relacionamentos entre elas. O objetivo é validar a proposta de tais
classes antes de começar a codificar.
• Engenharia Reversa (Reverse Engineering): quando os desenvolvedores usam

modelos UML para analisar e discutir uma funcionalidade que já se encontra
implementada no código fonte. Por exemplo, um desenvolvedor mais experiente
pode desenhar alguns diagramas UML para explicar para um desenvolvedor
recém-contratado como uma funcionalidade está implementada. Normalmente, é
mais fácil conduzir essa explicação usando modelos e diagramas gráficos do que
analisar e explicar cada linha de código.
Diagrama de Atividades
• Diagramas de atividades são
usados para representar, em
alto nível, um processo ou
fluxo de execução.
• Principais elementos
Nó Inicial: Inicia a execução do processo.
Ações: Uma ação é executada (atividade). Possuem um único fluxo de

entrada e um único fluxo de saída.
Decisões: Possuem um único fluxo de entrada e dois ou mais
fluxos de saída. Cada fluxo de saída possui uma variável booleana
associada, chamada de guarda. O fluxo segue apenas para a saída
cuja condição é verdadeira.
Merges: Podem possuir vários fluxos de entrada, mas um único

fluxo de saída. São usados para unir os fluxos de nodos de decisão.
Forks: Bifurca o fluxo de forma a criar paralelismo (concorrência),
passando a existir múltiplos processos em execução.
Joins: Sincroniza fluxos de forma que o processo somente continua após

todos os fluxos terem dado entrada no join.
Nó Final: Quando uma ficha chega em um dos fluxos de entrada,

encerra-se a execução do diagrama de atividades.
Diagrama de Caso de Uso
• Um caso de uso pode ser considerado uma descrição
simples do que o usuário espera de um sistema nessa
interação. Discutimos os casos de uso na elicitação dos
requisitos; considero os modelos de caso de uso mais
úteis nos estágios iniciais do projeto do sistema em vez
da engenharia de requisitos.
• Cada caso de uso representa uma tarefa discreta que

envolve a interação externa com um sistema.
• Em sua forma mais simples, um caso de uso é exibido

como uma elipse, com os atores envolvidos
representados como 'bonecos palito'.
• A notação de ‘bonecos palito’ representa a
interação humana, mas também é utilizada
para representar outros sistemas e hardware
externos.
Diagrama de Classes
• Diagramas de classes são os mais usados da UML.
• Representam um conjunto de classes, provendo

informações sobre atributos, métodos e
relacionamentos que existem entre as classes
modeladas.
• Um diagrama de classes é desenhado usando-se

retângulos e setas.
Diagrama de Classes
• Retângulo representa a classe, e é divido em 3
partes: nome da classe; atributos; e, métodos.
Observações
1. O nome da classe (e métodos) pode ser em itálico se for
abstrata
2. Os atributos e métodos devem conter o sinal de “-” para
indicar acesso privado; ou “+” para indicar acesso
público[1]
[1] Existem outros modificadores de acesso como #, ~, / . Veja em

https://www.lucidchart.com/pages/pt/o-que-e-diagrama-de-classe-uml
Diagrama de Classes
Diagrama de Classes
• Associações
– Quando uma classe A possui um atributo b de um tipo B,
dizemos que existe uma associação de A para B,
representada por meio de uma seta.
– Frequentemente, associações incluem multiplicidade, que
indicam quantos objetos podem estar associados ao
atributo responsável pela associação. As informações de
multiplicidade mais comuns são as seguintes:
• 1 (exatamente um objeto),
• 0..1 (zero ou um objeto), e
• * (zero ou mais objetos).
Diagrama de Classes
• Herança
– Relações de herança são representadas por meio de setas
com a extremidade não preenchida.
– A linha deve ser tracejada caso seja a relação entre uma
classe e uma interface
Diagrama de Classes
• Dependências
– Existe uma dependência de uma classe A para uma classe
B, representada por uma seta com uma linha tracejada de
A para B, quando a classe A usa a classe B, porém esse uso
não ocorre por meio de associação
Diagrama de Classes
Diagrama de Pacotes
• Diagramas de pacotes são
recomendados quando se
pretende oferecer um modelo de
mais alto nível de um sistema,
que mostre apenas grupos de
classes e as dependências entre
eles.
• Nestes diagramas, temos um

único tipo de seta, sempre
tracejada, que representa
qualquer tipo de relacionamento
Diagrama de Pacotes
Diagrama de Pacotes
Diagrama de Sequência
• Diagramas de sequência são diagramas
dinâmicos, também chamados de
comportamentais.
• Eles incluem informações sobre quais métodos

desses objetos são executados em um
determinado cenário de uso de um programa.
• Logo, eles são usados quando se pretende

explicar o comportamento de um sistema, em um
determinado cenário.
• Os objetos são representados por
meio de retângulos, com o nome
dos objetos modelados. Esses
retângulos ficam dispostos logo na
primeira linha do diagrama. Abaixo
de cada objeto, desenha-se uma
linha vertical tracejada
• Um retângulo sobre a linha

tracejada é desenhado para
representar um método em
execução
• As chamadas dos métodos é

representada por setas, onde é
demonstrado o nome e parâmetros
do método
Diagrama de Máquina de Estados
• A modelagem dirigida por eventos mostra como um
sistema responde a eventos externos e internos. Ela
se baseia no pressuposto de que um sistema tem um
número finito de estados e que os eventos (estímulos)
podem causar uma transição de um estado para
outro.
• Diagramas de Máquina de Estados mostram os estados

do sistema e os eventos que causam transições de um
estado para outro. Eles não mostram o fluxo de dados
dentro do sistema, mas incluem outras informações
sobre as computações executadas em cada estado.
Diagramas de
Arquitetura
Diagramas de Arquitetura
• Um diagrama de arquitetura técnica prove uma visão de alto
nível da infraestrutura da sua organização. O diagrama ilustra
como componentes em um sistema interagem com outro em
uma larga escala de itens.
• Os 5 principais diagramas são [1]:

• Diagrama de Arquitetura de Aplicação
• Diagrama de Arquitetura de Integração
• Diagrama de Arquitetura de Implantação (Deployment)
• Diagrama de Arquitetura de DevOps
• Diagrama de Arquitetura de Dados
[1] Vamos falar só do primeiro. Veja os demais em:

https://medium.com/the-internal-startup/how-to-draw-useful-technical-architecture-diagrams-2d20c9fda90d
Diagrama de Arquitetura de Aplicação
• Um diagrama de arquitetura de aplicação compreende uma visão
geral de alto nível dos componentes e as interações fundamentais
no sistema, por exemplo, de microserviços, bancos de dados, etc.
• O diagrama de arquitetura de aplicação principalmente endereça o

“O Que” na relação com o sistema.
• Um uso comum deste diagrama é facilitar o planejamento e a

implementação da solução de forma a avaliar o impacto de
melhorias, substituições ou mesclagens com aplicações existentes.
Com novas aplicações sendo continuamente lançadas no mercado e
prometendo um incremento de eficiência e redução de custos ,
torna-se vital ter uma visão geral das aplicações do seu sistema.
Diagrama de Arquitetura de Aplicação
• Exemplificando, suas aplicações podem residir em múltiplos
containers, isto é, bare-metal Kubernetes, AWS ECS, etc. devido
várias razões; e você é questionado sobre consolidar e mesclar as
aplicações para usar uma única plataforma de gerenciamento de
containers, como o Kubernetes para otimizar os custos e
operacionalizar um fluxo único em um ambiente multi-cloud.
• Como um início, algumas dessas questões podem surgir em sua

mente:
– Quais tipos de aplicações estão em cada cluster?
– Quais são as aplicações e dependências e interações?
– Qual é o resultado pretendido e o estado desejado da arquitetura?
• O exemplo seguinte ilustra o estado atual (as-is) da arquitetura da

aplicação.
Modelagem de
Processos
Modelagem de Processos
• O propósito da modelagem é criar uma representação do processo de
maneira completa e precisa sobre seu funcionamento. Por esse motivo, o
nível de detalhamento e o tipo específico de modelo têm como base o que
é esperado da iniciativa de modelagem.
• Um modelo é uma representação simplificada de uma coisa, um conceito

ou uma atividade. Modelos podem ser matemáticos, gráficos, físicos,
narrativos ou alguma combinação desses tipos. Possuem ampla gama de
aplicações nos ambientes de negócio, incluindo:
– Organização (estruturação)
– Descoberta (aprendizagem)
– Previsão (estimativas)
– Medição (quantificação)
– Explicação (ensino, demonstração)
– Verificação (validação)
– Controle (restrições, objetivos)
BPMN - Notação de Modelagem
de Processos de Negócio
• Business Process Modeling Notation (BPMN) é uma notação
gráfica que transmite a lógica das atividades, as mensagens
entre os diferentes participantes e toda a informação necessária
para que um processo seja analisado, simulado e executado.
• A notação usa um conjunto de figuras que permite diagramar
modelos de processos ajudando a melhorar a gestão de
processos de negócios, documentam o funcionamento real deles
e consegue um desempenho melhor.
• Utiliza-se uma linguagem comum para diagramar os processos
de forma clara e padronizada, o que proporciona um
entendimento geral e facilita a comunicação entre as pessoas.
Eventos
• Acontece durante o curso do processo de
negócio. Afetam o fluxo e pode ter uma causa.
• Eventos são representados por círculos
vazados para permitir sinalização que
identificarão os gatilhos ou resultados. Os
tipos de eventos são: Início, Intermediário e
Final.
Atividades
• É um termo genérico para o trabalho que a organização
realiza. Pode conter uma ou mais tarefas em níveis mais
detalhados.
• Os tipos de atividades que podem fazer parte de um processo

de negócio são: Processos, Subprocessos e Tarefas.
• Tarefas e Subprocessos são representados por um retângulo

com as quinas arredondadas. Os processos podem ser
representados da mesma forma ou inseridos dentro de um
Pool.
Decisões (Gateways)
• São usadas para definir que rumo o fluxo vai
seguir e controlar suas ramificações. A forma
gráfica é um losango com as pontas alinhadas
horizontal e verticalmente.
• O interior do losango indica o tipo de
comportamento da decisão.
Objetos de Conexão
Open your mind
Glossário
• AS-IS / TO-BE – como é / como
será
• FYI (PSC) – For Your Information
(Para Seu Conhecimento)
• AKA – As Knowledge As
• ASAP – As Soon As Possible
• e.g. – For example
• i.e. – That is
Aula 00
“The most fundamental problem in computer science is
problem decomposition: how to take a complex problem an
divide it up into pieces that can be solved independently.”
JOHN OUSTERHOUT
Projeto de Arquitetura
• O projeto de arquitetura visa compreender como
um sistema de software deve ser organizado e
projetar a estrutura geral desse sistema.
• É o vinculo fundamental entre o projeto e a

engenharia de requisitos, já que identifica os
principais componentes estruturais em um
sistema e as relações entre eles. A saída do
processo de projeto de arquitetura é um modelo
que descreve como o sistema está organizado
como um conjunto de componentes que se
comunicam.
• Nos processos ágeis, é geralmente aceito que um
estágio inicial do processo de desenvolvimento ágil
esteja focado na criação do projeto da arquitetura geral
do sistema.
• O desenvolvimento incrementai das arquiteturas

normalmente não é bem-sucedido. É relativamente
fácil refatorar os componentes em resposta às
mudanças. No entanto, é caro refatorar a arquitetura
do sistema porque é possível ter de modificar a maior
parte dos componentes do sistema para adaptá-los às
mudanças da arquitetura
• O projeto de arquitetura pode ser concebido com
2 níveis principais de abstração:
– Arquitetura em pequena escala – relacionada a um
programa individual;
– Arquitetura em grande escala – relacionada a sistemas
complexos, que incluem outros sistemas.
• A arquitetura de software é importante porque

afeta o desempenho, a robustez, a capacidade de
distribuição e a manutenibilidade de um sistema
(requisitos não funcionais).
• Em virtude do relacionamento entre as características não
funcionais do sistema e sua arquitetura, a escolha do estilo de
arquitetura e da estrutura deve depender dos requisitos não
funcionais do sistema:
– 1. Desempenho. Se for um requisito crítico, a arquitetura deve ser
projetada para centralizar as operações críticas dentro de um
pequeno número de componentes, com esses componentes
implantados no mesmo computador, em vez de distribuídos pela
rede. Isso pode significar a necessidade de usar alguns componentes
relativamente grandes, em vez de pequenos e mais refinados. Usar
componentes grandes reduz o volume de comunicação entre os
componentes.
• 2. Segurança da informação (security). Sendo um requisito crítico, deve
ser utilizada uma estrutura em camadas na arquitetura, com os ativos
mais críticos protegidos nas camadas mais internas e um alto nível de
validação de segurança da informação aplicado a essas camadas.
• 3. Segurança (safety). Se um requisito crítico, a arquitetura deve ser

projetada para que as operações relacionadas à segurança fiquem juntas
em um mesmo componente ou em um pequeno número de
componentes. Isso reduz os custos e os problemas de validação da
segurança e permite o fornecimento de sistemas de proteção
relacionados, que, em caso de falha, possam desligar o sistema de
maneira segura.
Diferença entre Safety e Security

https://www.perforce.com/blog/kw/software-safety-vs-security-whats-different
• 4. Disponibilidade. Se um requisito crítico, a arquitetura deve ser
projetada para incluir componentes redundantes para que seja possível
substituir e atualizar os componentes sem parar o sistema [1].
• 5. Manutenibilidade. Se um requisito crítico, a arquitetura do sistema

deve ser projetada usando componentes pequenos e autocontidos que
possam ser facilmente modificados. Os produtores de dados devem ser
separados dos consumidores, e as estruturas de dados compartilhadas
devem ser evitadas.
[1] Pesquisar sobre arquitetura tolerante a falha e arquitetura de alta

disponibilidade
Visões de Arquitetura
• Ao conceber um projeto podemos utilizar de visões ou
perspectivas distintas, o que irá resultar em um enfoque
diferente no desenho criado. As visões podem ser:
– Visão Lógica: mostra as abstrações fundamentais do sistema
como objetos ou classes;
– Visão de Processo: mostra como, no tempo de execução, o
sistema é composto de processos que interagem;
– Visão de Desenvolvimento: mostra como o software é
decomposto para desenvolvimento; isto é. mostra a divisão do
software em componentes que são implementados
– Visão Física: mostra o hardware do sistema e como os
componentes de software estão distribuídos pelos
processadores no sistema. Essa visão é útil para os engenheiros
de sistema que estão planejando uma implantação do sistema.
Padrões de
Arquitetura
Padrões de Arquitetura
• Os padrões foram criados como uma maneira
de apresentar, compartilhar e reutilizar
conhecimento sobre sistemas foi adotada em
uma série de áreas da engenharia de
software.
• Falaremos superficialmente dos principais

padrões de arquitetura
Model-View-Controller
• O padrão MVC (Modelo-Visão-Controlador),
que é a base do gerenciamento da interação
em muitos sistemas web. sendo suportado
pela maioria dos frameworks.
Model-View-Controller
• Separa a apresentação e a interação dos dados
do sistema.
• O sistema é estruturado em três componentes

lógicos que interagem entre si.
– Modelo - gerencia os dados do sistema e as operações
a eles associadas.
– Visão - define e gerencia como os dados são
apresentados ao usuário.
– Controlador - gerencia a interação do usuário (por
exemplo, pressionamento de teclas, cliques de mouse
etc.) e passa essas interações para Visão e Modelo.
Arquitetura em camadas
• Os conceitos de separação e de
independência são fundamentais para o
projeto de arquitetura porque permitem que
as mudanças sejam localizadas.
• A funcionalidade do sistema é organizada em

camadas separadas e cada uma se baseia
apenas nos recursos e serviços oferecidos
pela camada imediatamente abaixo dela.
Arquitetura em camadas
• Exemplo de arquitetura genérica em camadas
Arquitetura de repositório
• O padrão repositório (repository) descreve
como um conjunto de componentes que
interagem pode compartilhar dados.
• Todos os dados em um sistema são

gerenciados em um repositório central que é
acessível a todos os componentes do sistema.
Os componentes não interagem diretamente
com o dado, apenas por meio do repositório.
• Organizar as ferramentas em torno de um repositório é
uma maneira eficiente de compartilhar uma grande
quantidade de dados.
• Não é necessário transmitir os dados explicitamente de
um componente para outro. No entanto, os
componentes devem operar em torno de um modelo
aprovado de repositório de dados.
• Inevitavelmente, esse é um acordo entre as
necessidades específicas de cada ferramenta e pode
ser difícil ou impossível integrar novos componentes se
os modelos de dados não se encaixarem no esquema
aprovado.
Arquitetura cliente-servidor
• Um sistema que segue o padrão cliente-
servidor é organizado como um conjunto de
serviços e servidores associados e de clientes
que acessam e usam esses serviços.
Arquitetura cliente-servidor
• A vantagem mais importante do modelo
cliente-servidor é que se trata de uma
arquitetura distribuída.
• O uso eficaz pode ser feito nos sistemas em

rede que contam com muitos processadores
distribuídos. É fácil adicionar um novo
servidor e integrá-lo ao resto do sistema ou
atualizar os servidores transparentemente
sem afetar as outras partes do sistema.
Arquitetura duto e filtro
• Um modelo de organização de um sistema em
tempo de execução no qual transformações
funcionais processam suas entradas e produzem
saídas. Os dados fluem de um para outro e são
transformados enquanto passam pela sequência.
• O processamento dos dados em um sistema é

organizado de modo que cada componente de
processamento (filtro) é discreto e executa um
tipo de transformação dos dados. Os dados fluem
(como em um duto) de um componente para
outro para serem processados.
Arquitetura duto e filtro
• Os sistemas duto e filtro são mais adequados
para sistemas de processamento em lotes e
sistemas embarcados nos quais há interação
limitada do usuário.
Outros
Arquitetura Monolítica
• Uma aplicação monolítica é autônoma e
independente de outras aplicações de
computação. A filosofia do projeto consiste
em um aplicativo que não é responsável
apenas por uma determinada tarefa, mas que
também pode executar todos os passos
necessários para completar uma determinada
função
• Vantagens da Arquitetura Monolítica
– Mais simples de desenvolver: a organização fica concentrada em um único sistema;
– Simples de testar: é possível testar a aplicação de ponta a ponta em um único lugar;
– Simples de fazer o deploy para o servidor: a alteração é simplesmente feita e pronto;
– Simples de escalar: como é só uma aplicação, se for preciso adicionar mais itens, é
simplesmente ir adicionando o que for necessário.
• Desvantagens da Arquitetura Monolítica

– Manutenção: a aplicação se torna cada vez maior de acordo com o seu tamanho, o código será
cada vez mais difícil de entender e o desafio de fazer alterações rápidas e ter que subir para o
servidor só cresce;
– Alterações: para cada alteração feita, é necessário realizar um novo deploy de toda a
aplicação;
– Linha de código: uma linha de código que subiu errada pode quebrar todo o sistema e ele ficar
totalmente inoperante;
– Linguagens de programação: não há flexibilidade em linguagens de programação. Aquela que
for escolhida no início do projeto terá que ser seguida, sempre. Se o desenvolvimento de uma
nova funcionalidade exigir outra linguagem de programação, existem duas possibilidades: ou
todo o código é alterado ou a arquitetura do sistema precisará ser trocada.
Arquitetura de Micro Serviços
• Micro serviços é o nome dado a uma arquitetura que
estrutura a aplicação criando uma coleção de serviços.
• Quando se fala nesse tipo de arquitetura, basicamente

nós pegamos um monolito que seria criado e o
dividimos em vários serviços separados e
independentes um do outro.
• A ideia é separar os serviços para que cada um acesse

uma camada do banco de dados ou somente um
acesse algum serviço externo.
As vantagens deste tipo de arquitetura podem ser listadas como:
• Baixo acoplamento e melhor isolamento, mais fácil de testar e mais rápido para inicializar a aplicação
• Interações de desenvolvimento mais rápidas. Novos recursos podem ser desenvolvidos mais rapidamente e os
existentes facilmente refatorados
• Problemas em um dos serviços estão isolados e não vão derrubar a aplicação toda
• A adoção de novas tecnologias é mais simples, os componentes podem ser atualizados de forma independente e
de forma incremental, possibilitando um stack com diferentes tecnologias e linguagens
• Os serviços serão inicializados de forma mais rápida e possivelmente de forma paralela
• Os times serão independentes. Encaixa direitinho em squads e times ágeis
As desvantagens deste tipo de arquitetura:

• A aplicação é mais complexa, a stack de tecnologias é mais complexo e é mais difícil de aprender, e precisa de uma
infraestrutura complexa com Docker, multiplas JVMs e app containers
• Os testes de end-to-end e integração são complexos e custosos
• O deploy é mais complexo, pois geralmente envolvem containers e virtualização
• Escalar é mais fácil, porém definir as regras de upscaling são mais complexas e necessitam de funcionalidades
avançadas como o Service Discovery, DNS Routing e por ai vai…
• Geralmente precisa de um time maior para manter o software
• O skill set da equipe se torna mais variado, dificultando o compartilhamento de conhecimento e deixando
reposição de recursos mais complicada
• O desenvolvimento inicial é mais lento, atrasando o time to market
https://lgertel.medium.com/padrões-de-arquitetura-web-monolítica-ou-micro-serviços-7b3f0c9394fe
https://www.zappts.com/blog/arquitetura-monolitica-e-
microsservicos/#:~:text=Arquitetura%20Monolítica%20é%20um%20sistema,dentro%20de%20uma%20única%20plataforma.
BFF – Backend For Frontend
• Hoje é muito comum, por exemplo, um mesmo
produto ter uma interface web, outra móvel e outra
responsiva. Neste contexto, entendo que seja
bastante tentador projetar uma única API de back-
end para todas as interfaces, que seja reutilizável.
• Entretanto, as necessidades e restrições são bastante

variáveis, e às vezes é necessária uma
personalização. Para resolver este problema, é usado
um “Back-end for Front-end”.
• O Back-end for Front-end é um microsserviço que
customiza a entrega de back-end para cada interface
ou experiência do usuário.
• Isso é bastante útil quando temos um produto

complexo, com diversas interfaces, uma vez que
cada uma delas tem uma necessidade específica.
Arquitetura BFF
https://medium.com/digitalproductsdev/arquitetura-bff-back-end-for-front-end-13e2cbfbcda2

Engenharia de Software

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Engenharia de Software

Enviado por

Direitos autorais:

Formatos disponíveis

Engenharia de Software I

Prof. Vickybert P. Freire

• A nota semestral se dará pela média das notas entre Provas e

Aprovado se: ((Freq >= 75%) && ((A1 + P1 + A2 + 2*P2)/5 >= 6)

• Posso, no final do semestre, me arrepender e entregar todos

Gerenciamento de Projetos Empresariais

• Cada ação é determinada por uma sequencia, e cada sequencia se

• Um software, ou programa, consiste em informações que podem

• Engenharia é a área de atuação que se dedica a

• Durante os anos 1970 e 1980, foi desenvolvida uma série de

• Ou seja, Engenharia de Software é a área da

1. Cada vez mais os indivíduos e a sociedade dependem de

2. Geralmente é mais barato, no longo prazo, usar métodos e

A abordagem sistemática utilizada na engenharia de software

São sistemas stand-alone produzidos por uma organização de

2. Software personalizado (ou feito sob medida)

São sistemas encomendados e desenvolvidos para um

1. Eles devem ser desenvolvidos com o uso de um processo

2. Dependabilidade e desempenho são importantes para

3. É importante compreender e controlar a especificação e os

4. Os recursos existentes devem ser usados de modo eficaz.

• Segundo Brooks, as dificuldades essenciais são as seguintes:

Por exemplo, o sistema operacional Linux, em sua versão

Para mencionar um segundo exemplo, os sistemas do Google

Gerenciamento de Projetos Empresariais

Gerenciamento de Projetos Empresariais

• Em virtude de seus papéis no desenvolvimento dos

• O código contém princípios relacionados ao

• Nem é preciso dizer que os padrões normais de

São deveres dos profissionais de Informática:

De acordo com o seu compromisso com a saúde, segurança e bem-estar do público, os

• 1. Público - Os engenheiros de software devem agir coerentemente com o interesse público.

• Assim como carros, software também é produzido de acordo com

• Porém, os sistemas de software atuais são por demais

• Sem um processo — mesmo que simplificado e leve —

• O modelo em cascata é um processo dirigido por plano.

• Por isso, nada mais natural que a nascente Engenharia

1. Análise e definição dos requisitos. Os serviços, as restrições e as

2. Projeto do sistema e do software. O processo de projeto do

4. Integração e teste de sistema. As unidades de programa ou os

5. Operação e manutenção. Normalmente, essa é a fase mais longa do

• A principal referência é o PMBoK – Project

• Essa percepção foi ficando clara devido aos

• As atividades de especificação, desenvolvimento

• Essa abordagem pode ser dirigida por plano ou ágil; na

• Estudaremos alguns deles mais adiante.

• As quatro atividades de processo básicas – a especificação, o

• No modelo em cascata, elas são organizadas em sequência; no

• A engenharia de requisitos é um estágio particularmente crítico do

• Antes de iniciar o processo de engenharia dos requisitos, uma

• O projeto de software é uma descrição da estrutura do software a

• É comum que o projeto e a programação sejam

• Há ferramentas de desenvolvimento de software que

2. Teste de sistema. Os componentes do sistema são integrados para criar

3. Teste do cliente. O sistema é testado pelo cliente (ou cliente potencial)

• Essa distinção entre desenvolvimento e manutenção é cada vez mais

• A mudança eleva os custos de desenvolvimento de

• Se novos requisitos forem identificados, parte ou toda a

• Cada PI deve gerar um produto, de acordo com a complexidade do

• Desta forma, os alunos terão a oportunidade de desenvolver projetos,

• Cabe ressaltar que a empresa deve ter entendimento, que a

• O objetivo ao solicitar a empresa que apresente um problema real,

• O Portfólio Digital deve ser individual, e o aluno poderá

– Desenvolver o protagonismo do aluno no processo de