01.

Agile & Scrum

1.1 - Quais as 8 premissas do Agile Manifesto? 1

- Construir projetos com pessoas motivadas. Dar-lhes o ambiente e suporte que precisam e
confiar neles para fazer o seu trabalho
- O método mais eficaz de passar informação numa equipa de desenvolvimento é em conversas
cara-a-cara
- Software que funciona é o principal medidor de progresso
- O processo AGILE promove um ambiente sustentável - os patrocinadores, utilizadores e
desenvolvedores deverão manter um ritmo constante indefinidamente
- Atenção contínua para a excelência técnica e um bom design melhora a agilidade
- Simplicidade - a arte de maximizar a quantidade de trabalho não feito - é essencial
- As melhores arquiteturas, requisitos e designs vêm de equipas bem organizadas
- Em intervalos regulados, a equipa reflete como se tornar mais efetivo, ajusta e afina o
comportamento de acordo

1.2 - O que é SCRUM? 2

SCRUM é uma framework com a qual as pessoas podem endereçar problemas complexos,
entregando produtos valiosos de forma produtiva e criativa. É uma framework simples para
colaboração de equipas efetiva, em produtos complexos.
A definição de SCRUM consiste nos seus cargos, eventos, artefactos e regras.

1.3 - 3 características do SCRUM: 3

- Leve
- Simples de entender
- Difícil de dominar

1.4 - Esquematize a SCRUM framework: 4

1.5 - Quais os cargos no SCRUM? 5

- Equipa de desenvolvimento
- Product Owner
- Scrum Master

1.5 - O que é um product owner? 6

O Product Owner é o responsável pela maximização do valor do produto, resultante da equipa de

desenvolvimento. Ele fornece clareza à equipa sobre a visão e objetivo’s do produto. Todo o
trabalho é derivado e prioritizado de acordo com o Objetivo do Produto. O Product Owner
identifica, mede e maximiza o valor do produto durante todo o seu ciclo de vida

1.6 - O que é que um Product Owner faz? 7

O Product Owner é responsável pela gestão do backlog de produto. Esta gestão consiste em:
- Comunicar explicitamente o Objetivo do Produto
- Criar e claramente comunicar os itens do backlog do produto
- Ter a certeza de que o backlog do produto é transparente, visível e compreendido
Independentemente da delegação, ou não, de tarefas, o Product Owner é o responsável pela
execução das tarefas e a entrega do valor do produto

1.7 - O que é um SCRUM Master? 8

É o responsável por implementar o método SCRUM. É o responsável pela efetividade da equipa,

ajudando-a a melhorar a maneira como a equipa trabalha em conjunto para criar valor de forma
contínua.

1.8 - O que é que um SCRUM Master faz? 9

O Scrum Master ajuda a equipa de desenvolvimento:
- ensinando os seus membros em gestão pessoal e funcionalidade cruzada
- a ficar focada em criar Increments de grande valor que correspondam e atinjam a definição de
“Done”
- a remover qualquer impedimento para o progresso da mesma
- a garantir que os eventos acontecem e são positivos, produtivos e mantidos na janela de tempo

O Scrum Master também ajuda o Product Owner

- a encontrar técnicas para uma definição efetiva do Objetivo do Produto e gestão do backlog de
produto
- a fornecer maneiras da equipa entender a necessidade de ser claro e conciso nos items do
backlog.
- a estabelecer um planeamento empírico do produto para um ambiente complexo
- facilita a colaboração dos partes interessadas como preciso e requisitado

Suporta a organização:
- liderando e treinando os seus elementos na adoção do SCRUM
- ajudando os colaboradores e partes interessadas a entender uma abordagem empírica para um
trabalho mais complexo

1.9 - Quais as cerimónias do SCRUM? 10

- Sprint
- Sprint Planning
- Daily Scrum
- Sprint review
- Sprint retrospective

1.9.1 O que é uma sprint? 11

Períodos de tempo fixos que podem durar um mês ou menos, para criar consistência e assegurar
pequenas iterações para feedback, de modo a inspecionar e adaptar como o trabalho é feito e o
que precisa de ser trabalhado.

1.9.2 O que é Sprint Planning? 12

Inicia a sprint, delineando o trabalho a ser feito durante a Sprint. Isto é feito com a colaboração da
equipa Scrum
Tópicos avaliados: porque é que esta sprint tem valor? o que pode ser feito nesta sprint? como vão
escolher o trabalho a ser feito?

1.9.3 - O que é Daily Scrum? 13

Eventos de 15 minutos para os desenvolvedores da equipa. Para reduzir a complexidade, é
realizada à mesma hora e sítio do dia de trabalho. Focada no que está a ser feito para atingir o
objetivo da sprint e daqui advém um plano para o próximo dia de trabalho.

1.9.4 - O que é Sprint Review? 14

Inspecionar o resultado da Sprint e futuras adaptações. É apresentado o resultado do trabalho feito

na sprint para as partes interessadas e o progresso até ao objetivo do produto. É o penúltimo
evento da Sprint e deverá ser limitado a 4h para uma sprint de 1 mês.

1.9.5 - O que é Spring Retrospective? 15

O seu propósito é planear maneiras de aumentar a qualidade e efetividade. A equipa avalia como
é que a última sprint correu, relativamente a desempenho individual, interações, processos,
ferramentas e a sua definição de “Done”. Aqui termina a Sprint
Aqui avalia-se: o que correu bem na Sprint? o que pode ser melhorado? qual as melhorias com
que nos vamos comprometer na próxima sprint?

1.10 - Quais os artefactos do SCRUM? 16

- Product backlog
- Sprint backlog
- Increment

1.10.1 - O que é Product Backlog? 17

lista ordenada do que é necessário melhorar no produto. É a única fonte de trabalho a ser
realizado pela equipa. Também existe um refinement, que representa o ato de dividir um item do
backlog em items mais pequenos e precisos. Não é obrigatório, mas é considerada uma boa
prática.

1.10.2 - O que é Sprint Backlog? 18

É composta pelo objetivo da Sprint (why?), os items do Product backlog selecionados para a sprint
(what?) e um plano para entregar o Increment (how). É um plano de e para desenvolvedores

1.10.3 - O que é Increment? 19

É um passo concreto em direção ao objetivo de produto. É um aditivo a incrementos anteriores a

verificado, para que funcionem todos os incrementos até então. Para que seja de valor, o
Increment tem de ser útil e usável.

1.11 - O que é um Kanban Board? 20

É uma ferramenta usada para visualizar o trabalho e optimizar o fluxo de trabalho dentro da
equipa.
São extremamente úteis para garantir que o trabalho da equipa é visualizado e que o fluxo de
trabalho dos mesmos é normalizado.
Um kanban simples tem três passos: To Do, In Progress e Done. Mas podem ser adicionados
mais, dependendo do tamanho, estrutura e objetivos da equipa.
Os items representam-se por cards no quadro.
Ajuda a visualizar o trabalho e a evitar bottlenecks, uma vez que podem ser limitados o número de
items em WIP

1.12 - O que é um User Story? 21

São tarefas de desenvolvimento expressadas como “pessoa + necessidade + propósito”

É uma explicação generalizada e informal de uma feature escrita na perspetiva do utilizador final.
O seu propósito é articular como é que feature vai fornecer valor ao cliente. Não são apenas
requisitos do software.

02. SCV - GIT

2.1 - O que é controlo de versões? 22

Também conhecido por source control, é a prática de monitorizar ou gerir alterações a um código
de software.

2.2 - Porque é que os sistemas de controlo de versões são importantes? 23

Os sistemas de controlo de versões ajudam as equipas a trabalhar mais rápido e de maneira mais
inteligente.
São especialmente úteis para equipa de DevOps uma vez que as ajuda a reduzir o tempo de
desenvolvimento e a aumentar a implementação bem sucedida

2.3 - Como funcionam os sistemas de controlo de versões? 24

Os softwares de controlo de versões mantêm rasto de todas as alterações feitas no código, numa
base de dados especial.
Se um erro for cometido, os developers conseguem comparar versões antigas do código para
ajudar a resolver esse erro enquanto minimizam disrupção para todos os elementos da equipa

2.4 - Como é normalmente estruturado o código nestes sistemas de controlo de versões? 25

Tipicamente, o código está organizado numa estrutura de pastas ou árvore de ficheiros. Enquanto
um elemento da equipa de desenvolvimento trabalha numa nova funcionalidade, outro corrige
erros de um bug não relacionado. Assim, cada developer faz as suas alterações na árvore de
ficheiros

2.5 - O que pode dizer sobre incompatibilidade de alterações feitas por diferentes developers? 26

Alterações feitas num ponto A de um código podem impactar alterações ou código existente num
ponto B. Estes problemas deverão ser identificados e resolvidos de maneira organizada, sem
bloquear o trabalho a ser desenvolvido pelo resto da equipa.
Em todo o desenvolvimento de software, qualquer alteração pode introduzir novos BUGs e o novo
software não pode ser confiado até ser testado. Assim sendo, teste e desenvolvimento devem
prosseguir juntos até uma nova versão estar pronta.

2.6 - Quais alguns sistemas (softwares) de controlo de versões? 27

- Git
- Mercurial
- Suversion
- AzureDevOpe
- CVS

2.7 - O que pode dizer sobre o GIT? 28

GIT é um sistema grátis e open source de controlo de versões, desenhado para lidar com tudo,
desde pequenos a grandes projetos com rapidez e eficácia.
GIT é fácil de aprender e tem uma pequena pegada com rápida performance, passando à frente de
softwares como o subversion, CVS, perforce, clearcase, com funcionalidades como ramificação
local, áreas de staging conveninentes e múltiplos fluxos de trabalho

2.8 - Esquematize as estratégias de ramificação 29

2.9 - Explique um pouco do GitFlow 30

Considerado complicado e avançado para os projetos de hoje em dia, o GitFlow permite um

desenvolvimento paralelo onde os developers podem trabalhar separadamente desde a branch
principal, em funcionalidades onde a branch da feature é criada a partir da branch principal
(master)
Depois, quando as alterações estiverem concluídas, o developer junta (merge) essas alterações
para a branch principal para release.
2.10 - A estratégia de ramificação (branch) consiste em que “ramos” (branches)? 31

1 - Master
2 - Develop
3 - Feature - para desenvolver novas funcionalidades the advenham da develop branch
4 - Release - ajuda a preparar uma nova release em produção - usualmente advém da develop
branch e deverá ser fundida (merge) de volta para a branch develop e master
5 - Hotfix - também ajuda a preparar para uma futura release, mas ao contrário de outras
branches, as hotfix advém de um BUG que foi descoberto a deverá ser resolvido. Permite aos
developers continuar a trabalhar nas suas próprias alterações na branch develop enquanto o bug
está a ser corrigido

A Master e Develop branches são consideradas branches principais, com um tempo de vida
infinito, enquanto que o resto das branches esperam-se ser de desenvolvimento paralelo e tempo
de vida curto.

2.11 - Diga outros exemplos de fluxos de trabalhos para ramificação. 32

- GitHub Flow
- GitLab flow
- Trunk-based development

03. DevOps

3.1 - O que é DevOps, no sentido abstrato? 33

DevOps é uma combinação cultural de filosofias, práticas e ferramentas que aumentam a

habilidade de uma organização entregas aplicações e serviços a alta velocidade - evoluir e
melhorar produtos a um ritmo mais rápido do que o que as organizações usariam tradicionalmente
para desenvolvimento de software e processos de gestão de infraestruturas.

3.2 - O que é DevOps, na teoria? 34

É uma metadologia em desenvolvimento de software e na indústria IT. É usada como um conjunto

de práticas e ferramentas. Integra e automatiza o trabalho no desenvolvimento de software (Devs)
e as operações IT (Ops) como meios para melhorar e encurtar o ciclo de vida do desenvolvimento
de sistemas.
DevOps é complementar ao desenvolvimento de software Agile. Muitos aspetos de DevOps vêm
da maneira de trabalho do Agile.

3.3 - Esquematize, na prática, o que é DevOps: 35

3.4 - Explique um pouco a história de DevOps 36

80’s - 90’s: proposta para combinar as metodologias de desenvolvimento de software e os

conceitos de desenvolvimento e operações.
2007 e 2008: preocupações foram levantadas por aqueles dentro do desenvolvimento e
comunidades IT que a separação entre as duas indústrias (os que escrevem e criam software
estão completamente separados daqueles que implementam e fazem suporte ao mesmo) estava a
criar um nível de disfunção fatal dentro da indústria como um todo.
2009: a primeira conferência chamada DevOps aconteceu na Bélgica. Esta conferência foi fundada
pelo consultor belgo, project manager e agile practitioner Patric Depois. A conferência espalhou-se
então para outros países.
2012: um relatório chamado “State of DevOps” foi publicado por Alanna Brown em Puppet Labs
2014: o relatório anual do State of DevOps foi publicado por Nicole Forsgren, Gene Kim, Jez
Humble e outros. Eles afirmaram que a adoção de DevOps estava a acelerar. Também em 2014,
Lisa Crispin e Janet Gregory escrever um livro sobre testes Agile, que continha um capítulo sobre
testes e DevOps.
2016: a “Dora Metrics for Throughput and Stability” foi publicado no relatório “State of DevOps”.

3.5 - Em que resultou a evolução do conceito de DevOps? 37

Em algumas abordagens, a equipa de desenvolvimento e a equipa de operações poderiam ser

fundidas numa.
Em alguns modelos, as equipas de QA de segurança poderiam também aumentar a sua interação
com as equipas de desenvolvimento e operaçõe, assim como em todo o ciclo de vida da aplicação.
Se a segurança é uma prioridade para os todos os envolventes, é chamada DevSecOps
O objetivo destas equipas é automatizar o processo que fora sempre manual e demorado para
executar. O conjunto de ferramentas são usadas para aumentar a velocidade e eficiência, numa
maneira mais confiável.
Estes conceitos ajudam os developers a trabalhar independentemente - como gerir uma
infraestrutura de implementação - sem que as outras equipas precisem de intervir, aumentando
toda a velocidade no processo.

3.6 - Qual as vantagens de DevOps? 38

- Velocidade
- Entrega rápida
- Confiabilidade
- Escalabilidade
- Colaboração melhorada

3.9 - Quais as melhores práticas em DevOps? 39

- Contínua integração e entrega

- Infraestrutura como código
- Microsserviços
- Monitorização e logging
3.9.1 - O que pode dizer sobre Integração Contínua? 40

É uma prática de desenvolvimento na qual developers mantêm as alterações ao código num

repositório central. Depois disso, o código é compilado e os testes são feitos. Os principais
objetivos da CI são os de encontrar e investigar erros mais depressa, melhorar a qualidade do
código e reduzir o tempo para validar e entregar novas atualizações de software

3.9.2 - O que pode dizer sobre entrega contínua? 41

É uma prática no desenvolvimento de software na qual as alterações ao código são criadas,

testadas e preparadas automaticamente para serem implementadas em produção. Expande o
Continuous Integration, implementando todas as alterações num ambiente de produção ou testes,
depois do código ser compilado.

3.9.3 - O que pode dizer sobre microserviços? 42

A arquitectura em microserviços é uma abordagem de projeto para a criação de uma única

aplicação que usa vários pequenos serviços.
Cada serviço executa o seu próprio processo e comunica com outro usando uma interface bem
definida, normalmente uma API baseada em HTTP
Microserviços são criados à volta de recursos de negócio e cada serviço tem um objetivo único
Microserviços podem ser usados com diferentes estruturas ou linguagens de programação, e
serem implementadas separadamente ou em grupo

3.9.4 - O que pode dizer sobre infraestrutura como código? 43

É uma prática na qual a infraestrutura é provisionada e gerida usando código e técnicas de

desenvolvimento de software, como o controlo de versões e continuous integration.
O modelo de API controlada na nuvem permite que developers e admins de sistema interajam com
as infraestruturas de forma programada e em escala, ao invés de precisarem de manualmente
instalarem e configurarem recursos. Os engenheiros podem assim dialogar com a infraestrutura,
usando ferramentas codificadas e tratá-las de uma maneira similar a códigos de aplicação.
A partir do momento em que são geridas por código, infraestruturas e servidores podem ser
implementados mais rapidamente, usando padrões normativos, atualizados com patches e novas
versões ou duplicados muitas vezes
Gestão de configurações - developers e admins de sistema usam código para automatizar as
configurações de OS e do Host, assim como tarefas da operação; a utilização de código faz com
que com que as alterações a configurações possam ser repetidas e normalizadas, evitando a
necessidade de executar estas tarefas manualmente, fazer o processo mais rápido e eficiente.
Políticas como código - tendo infraestrutura e a sua respetiva configuração como código na nuvem
permite ao negócio monitorar e normalizar dinamicamente e em escala. Desta maneira, a
infraestrutura pode ser implementada, monitorada e gerida automaticamente; isto permite uma
maneira mais segura e simples para o negócio gerir os seus recursos enquanto mantém e reforça
políticas de segurança em ambientes distribuídos; isto permite para uma maior velocidade da
operação, à medida que recursos não conformados são automaticamente sinalizados para revisão
e correção

3.9.5 - O que pode dizer sobre Monitorização e logging 44

Estes verificam como é que o desempenho da aplicação e da infraestrutura impactam a
experiência UX do seu produto. Captando dados, catalogando e analisando, assim como
guardando em log da aplicação e infraestrutura, permite identificar como é que as alterações e
atualizações impactam os utilizadores, fornecendo entendimento à operação.
Os serviços deveriam estar disponíveis 24/7 e à medida que a recorrência a atualizações à
aplicação e infraestrutura aumenta, a monitorização ativa torna-se crucial. Criação de alertas ou
serviços de análise em real time permitem ao negócio atingir isso.

3.10 - Quais algumas das ferramentas de DevOps? 45

- Ferramentas de controlo de versões - p.e GIT (GitLab, GitHub, BitBucket)

- Ferramentas de compilação - p.e Maven
- Ferramentas de integração contínua - p.e Jenkins
- Ferramentas de gestão de configurações - p.e Chef
- Plataformas de contenterização - p.e Docker
- Computação e armazenamento - p.e AWS Cloud
- Ferramentas de testes - p.e Selenium

3.10.1 - Porque é que o GIT é uma ferramenta de controlo de versões importante para DevOps 46

Git deverá ser a melhor e mais usada ferramenta de controlo de versões, atualmente. Controlo de
versões fornece aos developers um meio com o qual eles podem manter o rasto de todas as
mudanças e atualizações feitas ao seu código, para o caso de haver algum erro, ser fácil voltar e
usar uma versão anterior do código.
A ferramenta Git DevOps torna fácil a implementação, uma vez que é compatível com a maioria
dos protocolos HTTP, SSH e FTP. Oferece a melhor vantagem para repositórios partilhados de
projetos não lineares, ao contrário de outras ferramentas de controlo de versões centralizadas.
O Git possui três ferramentas de armazenamento, incluindo o GitHub e o GitLab, assim como o
BitBucket.
GitLab e BitBucket são especialmente desenhadas para controlo de versões num espectro
empresarial.

3.10.2 - Porque é que uma ferramenta de compilação como o Maven é importante para 47
DevOps?
Maven é uma das mais importantes ferramentas DevOps para construir projetos. Ao contrário do
sistema de compilação ANT, Apache Maven é mais do que uma framework de automatização de
compilação. Também é desenhada para gerir relatórios, documentação, distribuir releases, e
processos de dependências. Escrito em Java, o Maven pode compilar e gerir projetos escritos em
Java ou C#, Ruby, Scala, e outras linguagens de programação que usam POM (project object
model) plugins.
O Maven oferece muitos benefícios aos seus utilizadores. Facilita a compilação e monitorização de
processos através da automatização e mantém um processo de construção uniforme,
possibilitando a consistência e a eficiência. Esta ferramenta também oferece uma informação
compreensiva do projeto através de documentação de qualidade, um valioso recurso para as
melhores práticas de desenvolvimento. Também fornece uma funcionalidade de processo do
processo de migração muito simplificada.
Tem um rico repositório de plugins para melhorar o processo de compilação e uma grande
compatibilidade com IDEs como o Eclipse, Jbuilder, MyEclipse, NetBeans, IntellijIDEA, entre
outros.

3.10.3 - Porque é que uma ferramenta de integração contínua, como o Jenkins, é importante 48
para DevOps?

O Jenkins está desenhado para extensões internas e de plugins. É um software de automatização

CI open-source, escrito em Java, suportado por múltiplos sistemas operativos, como o Windows,
MacOs e outros Unix OSs. Também pode ser implementado em plataformas na nuvem.
É compatível com a maioria das ferramentas de CI/CD e serviços, graças aos mais de 1500
plugins disponíveis, para fornecer valor na implementação para um entrega costumizada de
funcionalidades durante o desenvolvimento do software.
É fácil de instalar e configurar. Está desenhado para suportar fluxos de trabalho distribuídos para
compilações aceleradas e transparentes, testes e implementações em várias plataformas.

3.10.4 - Porque é que ferramentas de gestão de configurações, como o Chef, são importantes 49
em DevOps?

Gestão de configurações - manutenção e controlo de componentes de um grande sistema

complexo num estado consistente, determinado e conhecido durante o ciclo de vida do DevOps.
Componentes esses que podem ser servidores, rede, armazenamento e aplicações.
Por esta razão, gestão de configurações (CM) é crítico para qualquer sistema uma vez sendo um
processo pelo qual os sistemas são monitorados, corretamente implementados e controlados. Se
não forem automatizados, CM podem ser trabalhosos, consomem recursos e são susceptíveis a
erros dispendiosos.
Chef, Puppet e Ansible são frameworks de automatização de CM (configuration management).
Enquanto que Chef e Puppet são baseados em Ruby, Ansible é baseado em Python.
Chef é uma framework open source, usa um modelo de master-agent e tem capacidades de
infraestrutura como código para automatizar a configuração da infraestrutura.
Juntos com suporte a outras multi plataformas que incluem plataformas na nuvem, Chef mantém-
se uma das ferramentas mais populares de DevOps, depois do Puppet.

3.10.5 - E sobre o Puppet? Porque também é uma ferramenta importante a considerar? 50

Puppet também é open-source e usa programação declarativa para configuração de sistemas,
implementações e ferramentas gestão de servidores DevOps.
Está organizada em módulos reutilizáveis para uma configuração rápida de um servidor pré
configurado, sendo compatível com a maioria das plataformas.
Como Chef, também usa infraestrutura como código, adota uma arquitectura master-slave, e tem
uma interface de utilizador intuitiva para um relatório em tempo real, gestão de nós e outras muitas
tarefas.

3.10.6 - E o Ansible? Porque também é uma ferramenta a considerar para gestão de 51

configurações?

Ansible é uma ferramenta de gestão de configurações DevOps open source, usada para
implementação, automatização e orquestração.
Enquanto que o Ansible alavanca a arqutetura da infraestrutura como código, usa conexão SSH
para empurrar os seus nós sem agente.
É considerado fácil para aprender e usa o seu playbook escrito em Yaml com comandos
minimalistas e fácilmente lidos por humanos.

3.10.7 - Porque é que as plataformas de conterização, como o Docker, são ferramentas 52

importantes para DevOps.

Plataformas de contenterização são soluções aplicacionais que permitem aos developers compilar,
testar e enviar aplicações em ambientes que não contenham dependências de recursos. Cada
container (contentor) compreende um ambiente de execução que inclui aplicações específicas, as
suas bibliotecas, código fonte, configurações e dependências. Plataformas destas oferecem
orquestração, automatização, segurança, governação e outros recursos.
DevOps depende muito de contenterização e microsserviços para implementação e
desenvolvimento eficiente de aplicações, com Docker e Kubernetes sendo as tecnologias mais
utilizadas de containers.
O motor de Docker está desenhado para automatizar desenvolvimento, implementação e gestão
de aplicações contenterizadas em nós únicos. Docker é uma ferramenta open source compatível
com serviços na cloud como AWS, GCP e Azure Cloud. Docker é executável em Windows e
Sistemas Operativos Linux.

3.10.8 - E o Kubernetes? Porque pode ser uma ferramenta importante para DevOps? 53

Kubernetes, por outro lado, é uma plataforma de automatização de orquestração que permite aos
desenvolvedores executar aplicações em contentores através de clusters Kubernetes, referindo a
um grupo de nós.
Desenvolvedores aproveitam o Kubernetes para automatizar processos como configuração de
containers, escalabilidade, rede, segurança e outros para atingir velocidade e eficiência em
produção.

3.10.9 - Porque é que o AWS Cloud, por exemplo, pode ser uma ferramenta importante para 54
DevOps?
AWS tem uma grande variedade de serviços que oferece dentro das categorias PaaS (Platform as
a Service), SaaS (Software as a Service) e IaaS (Infrastructure as a Service), incluindo
computação, identificação e gestão de acessos (ACM), redes e armazenamento.
Enquanto que a AWS oferece nuvens públicas, privada e híbridas, o foco é maioritariamente em
núvens públicas.

3.10.10 - E o Azure Cloud? Como pode ser útil na computação e armazenamento em DevOps? 55

Azure é a escolha preferida para empresas, especialmente nas que confiam mais em aplicações
office, graças à facilidade de transição.
Azure oferece ao DevOps um serviço com conjunto de ferramentas para gerir desenvolvimento de
projetos de software end-to-end. Este serviço compreende o servidor DevOps da Azure e o serviço
Azure DevOps Cloud.
O servidor fornece um ambiente de execução baseado em ferramentas na cloud para facilitar
implementações on-premise.
O serviço na Cloud, por outro lado, possui ferramentas como Azure Boards, Azure Pipeline, Azure
Reports, Azure Test Plans e Azure Artifacts para desenvolvimento, teste e implementação de
software na cloud.

3.10.11 - E o Google Cloud Platform? Como pode ser uma ferramenta importante para o 56
DevOps?

GCP suporta DevOps fornecendo serviços que requerem desenvolvimento, armazenamento e

implementação de software de alta qualidade em pequenos ciclos.
GCP possui instâncias até 96 vCPUs e 624 GB de RAM, ao lado de serviços como consola na
cloud, motor de computação da Google, e o gestor de implementação GCP que suporta a
implementação de DevOps na GCP.
Em adição, a Google Cloud possui uma impressionante expertise técnica assim como inteligência
artificial, machine learning, e recursos de análise de dados.

3.10.12 - Porque é que ferramentas de teste, como o Selenium, são importantes para DevOps? 57
A lógica por detrás da automatização é eliminar envolvimento humano em determinadas tarefas,
usando a tecnologia para automaticamente executar essas tarefas. Automatização de testes
emprega aplicações de software, à parte do software a ser desenvolvido, para executar cenários
de testes automaticamente, comparar resultados e reportar defeitos.
O processo é executado muitas vezes para entregar software de alta qualidade para os
utilizadores finais. Testar é uma parte integral do desenvolvimento de software e é menos
propenso a erros.
Selenium é uma framework open source para testes em aplicações web que suporta os browsers
mais usados e plataformas como Linux, Windows e MacOS.
Selenium integra com uma grande variedade de linguagens de programação incluindo Python, C#,
Ruby, Java, Javascript, PHP e Perl, e muitas outras frameworks de automatização de testes.
A Suite de Testes Selenium possui:
- Selenium IDE - para criar e executar casos de teste para testes exploratórios e gravar playbacks
de testes.
- Selenium Client API - permite aos developers escrever scripts de testes diretamente em várias
linguagens de programação ao invés de precisarem de escrevê-las numa linguagem de
programação do Selenium
- Selenium WebDriver - possui atalhos (bindings) para escrever scripts de teste
- Selenium Grid - servidor proxy inteligente que permite que sejam executados testes em múltiplos
browsers a sistemas operativos em paralelo.
- Selenium Remote Control Server - escrito em Java, comunica com browsers, através de
comandos em Selenium, para execução.

04. Containers

4.1 - O que são containers (contentores)? 58

Solução de software que “embrulha” o processo de software, ou microsserviço, para o fazer

executável em todos os ambientes de computação. Em geral, podemos executar todo o tipo de
ficheiros executáveis em containers, como ficheiros de configuração, código de software,
bibliotecas e programas binários.
Com ambientes computacionais, queremos dizer sistemas locais, data centers on-premises e
plataformas na cloud geridas por vários fornecedores de serviço.
Containers na cloud são hospedados num ambiente online. Utilizadores podem acessá-los de todo
lado. No entanto, processos aplicacionais ou microsserviços baseados na cloud ficam separados
da infraestrutura cloud.
São como sistemas operativos virtuais que embrulham a nossa aplicação para que seja compatível
com qualquer OS.
Como não está amarrado a uma nuvem, sistema operativo ou espaço de armazenamento
específico, software contentarizado pode ser executado em qualquer ambiente.

4.2 - O que é uma imagem de container e como é constituída? 59

Contentarizar em computação da Cloud é o processo de compilar aplicações de software para
contentores. O produto final desse pacote e design de uma app em container é uma imagem. De
facto, deverá ter tudo o que se achar necessário para executar a aplicação contentorizada,
independentemente da infraestrutura que a hospeda.
Essa imagem é constituída, tipicamente, por:
- O código da aplicação
- Ficheiros de configuração
- Dependências de software
- Bibliotecas
- Variáveis de ambiente

4.3 - O que é orquestração de containers? 60

É o processo de criar um ambiente que automatiza a maioria das tarefas de manutenção para
cargas de trabalho contentorizadas, aplicações e serviços. A maioria das empresas conta com
plataformas de orquestração de containers e fornece serviços completos de gestão de containers
aos seus utilizadores.

4.4 - Containers vs Máquinas Virtuais - qual a diferença? 61

4.5 - Como é que os containers funcionam? 62

O processo de gestão de containers padronizado ter 4 estágios para as aplicações e serviços que
contém:
- Criação
- Implementação
- Escalabilidade/Expansão
- Destruição
Contentorização assegura que nenhum destes pontos dependa de um OS Kernel. Assim,
containers não trazem nenhum Sistema Operativo convidado com eles, da mesma maneira que
máquinas virtuais precisam.
Aplicações contentorizadas estão ligadas a todas as suas dependências como uma única unidade
de implementação. Alavancando as funcionalidades e recursos do SO hospedeiro, os containers
permitem estas aplicações de funcionar em qualquer ambiente.

4.6 - Quais os benefícios da contentorização? 63

- Precisam de menos recursos de sistema, uma vez que não ligam imagens de sistemas
operativos a cada aplicação que guardam
- São altamente interoperáveis, uma vez que estas aplicações podem usar o SO anfitrião.
- Uso de recursos otimizado como computação de containers permite que aplicações semelhantes
partilhem das mesmas bibliotecas e ficheiros binários.
- Não existem problemas de hardware ou implementação, uma vez que os containers são
independentes de infraestruturas
- Melhor portabilidade porque consegue migrar e implementar containers em qualquer lado,
tranquilamente
- Escabilidade e desenvolvimento facilitado porque a tecnologia de contentorização permite
expansão gradual e testes paralelos de aplicações
4.7 - Para que são usados os containers? 64

- Desenvolvimento Agile
- Alta eficiência
- Soluções prontas para o futuro

4.8 - Quão seguros são os containers? 65

Os containers oferecem múltiplas camadas de segurança. Existem 4 níveis para prevenir

vulnerabilidades na segurança:
- Ao nível da aplicação - os desenvolvedores podem adicionar validações e alinhar o seu código a
padrões de segurança
- Ao nível do container - é boa prática usar um serviço confiável de segurança (como o
Kubernetes)
- Ao nível do cluster - administradores de rede devem adicionar restrições para filtrar tráfico não
autorizado
- Ao nível da cloud - uma plataforma de containers confiável, como Ridge, oferece segurança top-
level
Adicionalmente, nunca devemos configurar a nossa implementação de maneira vulnerável ou
permitir utilizadores não autorizados ou pedidos não autenticados, a aceder aos nossos
containers.

4.9 - Containers, Docker e Kubernetes - como é que funciona? 66

Docker - fornece um espaço de execução para aplicações em containers

Kubernetes - guarda múltiplos containers para formar um cluster enquanto fornece um
desenvolvimento gerido para colaboração dos containers.

05. Frameworks

5.1 - O que é uma framework, em termos teóricos? 67

Uma framework é uma estrutura de software que fornece funcionalidades genéricas e orientações
de design para o desenvolvimento de aplicativos. Ela ajuda os desenvolvedores ao oferecer uma
base reutilizável que agiliza o processo de criação, reduzindo a complexidade e promovendo boas
práticas.
5.2 - O que é uma framework, em termos práticos? 68

Framework é um pedaço de software que facilita o desenvolvimento e manutenção de projetos

maiores.
É uma coleção de módulos fundamentais que inclui código preparado que os programadores
podem usar para corrigir/executar tarefas de programação como gerir pedidos AJAX ou tentar
definir uma estrutura de ficheiros.
Também especificam regras para desenvolver a arquitectura da aplicação: temos a estrutura do
esqueleto que deverá ser extendida e alterada de acordo com os requisitos.

5.3 - Quais as principais funcionalidades de uma framework? 69

- Inversão de controlo - template method pattern

- Comportamento padrão - fornecido pelo template method pattern
- Extensibilidade - programadores podem adicionar código especializado que fornece
funcionalidade específica. Normalmente atingido pelo hook method numa subclass que sobrepõe o
template method na superclass
- Código não modificável da framework - normalmente, o código da framework não deve ser
modificado. Os utilizadores podem, como visto acima, extendê-la, mas não podem modificar o seu
código

5.4 - Porque é que as frameworks são criadas? 70

O objetivo é facilitar o desenvolvimento, permitindo aos developers e designers focarem-se e

dedicarem o seu tempo aos requisitos mais específicos da aplicação, ao invés de lidarem com os
detalhes padronizados a low-level, que fazem o sistema funcionar. Assim, reduzem o tempo de
desenvolvimento, num geral

5.5 - O que é code-bloat e como pode ser associado a uma framework? 71

Code-bloat é um termo utilizado para descrever o aumento desnecessário e excessivo do tamanho

do código fonte de um programa ou software.
Este fenómeno pode acontecer com a utilização de frameworks, uma vez que as mesmas podem
trazer funcionalidades não requisitadas ou utilizadas, mas que vêm by default com o setup da
mesma.

5.6 - Como é que uma framework pode ser um custo desnecessário para uma empresa? 72

Uma framework pode ser considerada um custo se os desenvolvedores não souberem como a
mesma funciona. Assim sendo, a empresa terá custos na formação dos seus desenvolvedores. Se
essa framework não for utilizada em tarefas futuras, o tempo investido em aprendê-la pode custar
mais que um código desenvolvido com o propósito pretendido.

5.7 - Como é que se pode contornar um custo, considerado desnecessário, na aprendizagem 73

de uma framework?

Uma vez aprendida, futuros projetos nessa framework serão, com certeza, mais rápidos e fáceis
de completar. O conceito de uma framework pressupõe uma solução “one-size-fits-all"
5.8 - O que são frameworks de frontend? 74

São plataformas/ferramentas/produtos de software que servem como fundação para os

componentes avançados de frontend de soluções para a web.

5.9 - Quais alguns exemplos de frameworks de frontend? 75

- React / ReactJS - Javascript

- Angular - Typescript
- Vue.js - Javascript
- Zurb’s foundation - Javascript

5.10 - O que são frameworks de backend? 76

Frameworks do lado do servidor desenhadas para tornar as tarefas mais fáceis para
desenvolvedores. Fornecem ferramentas, bibliotecas e outros componentes que ajudam os
developers a criar o backend para uma aplicação ou website. Podem automatizar alguns aspetos
de web dev, tornando-o mais rápido e simples

5.11 - Quais algumas frameworks de backend? 77

- Django - Python
- ExpressJS - NodeJS
- Laravel - PHP
- Flask - Python
- Ruby on Rails - Ruby
- CakePHP - PHP

06. Architecture and Design Patterns

6.1 - O que é a arquitetura e design de um sistema? 78

A arquitetura de um sistema descreve os seus componentes principais, as suas relações, e como é
que eles interajem entre eles. Arquitetura e Design de Software inclui alguns fatores contribuintes
como a estratégia de business, atributos de qualidade, dinâmicas humanas e ambiente IT
Podemos segregar este conceito em dois: Arquitetura de Software e Design de Software.
Na arquitetura, as decisões não funcionais são lançadas e separadas pelos requisitos funcionais.
No design, os requisitos funcionais são atingidos/realizados.

6.2 - Para que serve a arquitetura de um sistema? 79

Serve como blueprint para um sistema. Fornece uma abstração para gerir a complexidade do
sistema e estabelecer a comunicação e o mecanismos de coordenação entre componentes.
Define a solução estruturada para ir de encontro aos requisitos técnicos e operacionais, enquanto
otimiza os atributos de qualidade comuns como a performance e a segurança

6.3 - Quais as decisões envolvidas, na Arquitetura de Software? 80

- Seleção de elementos estruturais e as suas interfaces nas quais o sistema é composto

- Comportamento como especificado na colaboração entre os elementos
- Composição dos elementos estruturais e comportamentais num subsistema maior
- Decisões arquitetónicas alinham com os objetivos de negócio
- Estilos de arquitetura guiam a organização

6.4 - O que é Software Design? 81

Este fornece um plano que descreve os elementos de um sistema, como é que eles encaixam e
trabalham juntos para atingir os requisitos do sistema.

6.5 - Porque precisamos de Design de Software? 82

- Para negociar requisitos de sistema, e definir expectativas para os clientes, marketing e gestão
de pessoas
- Para agir como uma blueprint durante o processo de desenvolvimento
- Guiar as tarefas de implementação, incluindo o design detalhado, código, integração e teste.

6.6 - Onde se insere a arquitetura de software? 83

Esta vem antes do design detalhado, código, integração e teste e depois da análise de domínio,
análise de requisitos e análise de risco

6.7 - Quais os objetivos da arquitetura? 84

O principal é identificar os requisitos que afetam a estrutura da aplicação. Uma arquitetura bem
apresentada reduz os riscos de negócio associados na construção de uma solução técnica e
constrói uma ponte entre requisitos de negócio e técnicos.
Outros objetivos:
- Expor a arquitetura do sistema, mas esconder os detalhes de implementação
- Realizar todos os casos-uso e cenários
- Tentar endereçar requisitos a todas as partes interessadas
- Lidar com os requisitos funcionais e de qualidade
- Reduzir o goal of ownership e melhorar a posição da organização no mercado
- Melhorar a qualidade e funcionalidade oferecidas pelo sistema
- Melhorar a confiança exterior na organização ou sistema

6.8 - Quais as limitações na arquitetura de um sistema? 85

- Falta de ferramentas ou maneiras padronizadas para representar a arquitetura

- Falta de métodos de análise para prever se a arquitetura vai resultar numa implementação que
corresponda aos requisitos
- Falta de conhecimento na importância do desenho arquitetónico para desenvolvimento de
software
- Falta de entendimento do cargo de um arquiteto de software e a pobre comunicação entre partes
interessadas
- Falta de entendimento do processo de design, experiência de design e avaliação de design
6.9 - O que são padrões arquitetónicos? 86

São solução reutilizáveis para um problema comum e recorrente, em arquitetura de software,

dentro de um determinado contexto. Padrões de arquitetura são semelhantes de padrões de
design de software, mas têm um escopo mais abrangente.

6.10 Quais são alguns padrões de design? 87

1. Layered Pattern
2. Client-server pattern
3. Master-slave pattern
4. Pipe-filter pattern
5. Broker pattern
6. Peer-to-peer pattern
7. Event-bus pattern
8. Model-view-controller pattern
9. Microservices
10. Model-view-view model

6.10.1 Descreva o Layered Pattern e sua usabilidade 88

Pode ser usado para estruturar programas que possam ser compostos em grupos de sub-tarefas,
nas quais cada uma é um nível particular de abstração. Cada camada fornece serviços ao nível
acima seguinte
As 4 principais camadas são:
- Presentation Layer - UI Layer
- Application Layer - Service Layer
- Business Logic Layer - Domain Layer
- Data Access Layer - Persistence Layer
Uso:
- General Desktop Applications
- E-commerce Web Applications

6.10.2 Descreva o Client-Server pattern e sua usabilidade 89

Consiste em duas partes: Um servidor e múltiplos clientes.
O componente de servidor irá fornecer serviços para múltiplos componentes de cliente. O cliente
pede serviços ao servidor e o servidor fornece serviços relevantes a esses clientes. O servidor
continua a “ouvir” os pedidos dos clientes
Uso:
- Online applications, como e-mail, partilha de documentos e banking

6.10.3 Descreva o Master-Slave Pattern e sua usabilidade 90

Consiste em duas partes: Master e Slaves. O componente master distribui trabalho entre os
componentes idênticos de Slave, e calcula o resultado final com os resultados que os slaves
trazem.
Uso:
- Database replication - a master database é considerada como a fonte autoritária e as slaves
databases estão sincronizadas a ela.
- Periféricos conectados a um bus num sistema computacional

6.10.4 Descreva o Pipe-Filter Pattern e sua usabilidade 91

Pode ser usado para estruturar sistemas que produzam e processem um fluxo de dados. Cada
passo de processamento é anexado dentro de um componente de filtro. Os dados são passados
por pipes. Estes pipes podem ser usados para propósitos de sincronização e buffering.
Uso:
- Compiladores - os filtros consecutivos executam análises lexicais, parsing, análise semântica e
geração de código
- Workflows em bioinformática

6.10.5 Descreva o Broker Pattern e sua usabilidade 92

Usado para estruturar sistemas distribuídos com componentes dissociados. Estes componentes
podem interagir uns com os outros pela invocação remota de serviços. O componente broker é
responsável pela coordenação de comunicação entre componentes.
Os servidores publicam os seus recursos (serviços e características) a um broker. O cliente pede
um serviço do broker e o broker redireciona o cliente para o serviço mais adequado do seu registo.
Uso:
- Software de message broker como o Apache ActiveMQ, Apache Kafka, RabbitMQ e JBoss
Messaging

6.10.6 Descreva o Peer-to-Peer Pattern e sua usabilidade 93

Neste padrão, componentes individuais são chamados de peers. Peers podem funcionar como
cliente, fazendo pedidos de outros peers, ou servidor, fornecendo serviços para outros peers. Um
peer pode atuar como cliente, servidor ou ambos, e pode mudar o seu cargo de forma dinâmica
com o tempo.
Uso:
- Redes de partilha de ficheiros como o Gnutella e G2
- Protocolos multimedia como P2PTV e PDTP
- Produtos Cryptocurrency-based como a Bitcoin e Blockchain

6.10.7 Descreva o Event-Bus Pattern e sua usabilidade 94

Este pattern lida com eventos e tem 4 principais componentes: event source, event listener,
channel e event bus. Sources publicam mensagens para channels particulares num event bus.
Listeners subscrevem a um channel particular. Listeners são notificados de mensagens que são
publicadas num canal ao qual eles subscreveram antes.
Uso:
- Android development
- Notification services

6.10.8 Descreva o Model-View-Controller Pattern e sua usabilidade 95

aka MVC - divide uma aplicação interativa em 3 partes:
- Modelo (que contem a core functionality e data);
- View (que apresenta a informação ao utilizador (pode ser definida mais que uma view));
- Controller (lida com o input do utilizador)
Isto é feito para separar representações de informação internas das maneiras em que a
informação é apresentada, e aceite, pelo utilizador. Ela dissocia componentes e permite uma
reutilização do código eficiente.
Uso:
- Arquitetura para Aplicações da World Wide Web, na maioria das linguagens de programação
- Web Frameworks, como Django e Rails

6.10.9 Descreva o Microservices Patter e sua usabilidade 96

Envolve criar múltiplas aplicações - ou microserviços - que podem trabalhar

interindependentemente. Embora cada microserviço possa ser desenvolvido e implementado
independentemente, a sua funcionalidade é entrelaçada co outros microserviços.
Um conceito chave neste padrão é a separação de unidades de implementação. Isto cria uma
pipeline de entrega simplificada que permite uma implementação mais fácil de microserviços e
aumenta a escabilidade da aplicação.
Outra funcionalidade chave é a da arquitetura distribuída. Ou seja, os componentes podem ser
dissociados na sua íntegra e acessados através de protocolos de acesso remoto como REST,
SOAP ou GraphQL. Esta natureza distribuída do padrão permite as suas propriedades de
escalabilidade.
Uso:
- Web applications
- Websites com componentes pequenos
- Datacenters corporativos que têm limites bem definidos
6.10.10 Descreva o Model-View-View-Model e sua usabilidade 97

Facilita a separação do desenvolvimento da GUI do desenvolvimento da lógica do

negócio/backend. A view não é dependente de uma plataforma de modelo específica.
MVVM é um conversor valioso, responsável por expor os objetos de dados do modelo de uma
maneira que consigam ser facilmente geridos e apresentados.
Também é referido como Model-View-Binder, especialmente em implementações que não
envolvam plataformas .NET

07. Software Development Process

7.1 - O que é o processo de desenvolvimento de software? 98

É uma abordagem estruturada para desenvolver software para um sistema ou projeto, às vezes
chamado Software Development Life Cycle (SDLC)
A abordagem Incremental Development forma a base para o desenvolvimento de software dentro
do nivel de Evolutionary Acquisition (EA) em sistemas maiores.
O processo de desenvolvimento de software é uma maneira de melhorar o design e gestão de
produto, dividindo o trabalho de desenvolvimento em pequenos passos ou subprocessos que
podem ser feitos em paralelo ou numa ordem

7.2 - Quais os principais passos no desenvolvimento software? 99

1 - Planning
2 - Implementing
3 - Testing
4 - Deployment and Maintenance

7.2.1 - Em que consiste o passo “Planning”? 100

Análise de requisitos - clientes têm tipicamente uma ideia abstrata do que querem como resultado
final, mas não o que o software deve fazer.
Engenheiros experientes e qualificados reconhecem os requisitos incompletos, ambíguos ou
mesmo contratitórios, neste ponto.
Mostrar código ao vivo pode ajudar a reduzir o risco dos requisitos estarem incorretos.
Uma vez recolhidos os requisitos gerais, deverá ser feita uma análise do escopo, de forma clara e
determinante. Isto é comumente chamado de SOO (Statement of Objectives) ou SOW (Statement
of Work)

7.2.2 - Em que consiste o passo “Implementation”? 101

Implementação, desenvolvimento ou “coding” é a parte do processo onde os engenheiros de
software programam o código para o projeto

7.2.3 - Em que consiste o passo “Testing”? 102

Esta parte do processo assegura que os defeitos são reconhecidos assim que possível. Pode
também fornecer um objetivo, independentemente da visão do software, permitindo aos
utilizadores apreciar e compreender os riscos do desenvolvimento de software. Os testes podem
ser vistos como um processo de validação e verificação do programa/aplicação/produto.

7.2.4 - Que verificações são feitas no passo “Testing”? 103

Na fase de testes, é assegurado que o produto:

- Vai de encontro aos requisitos que guiaram ao seu design e desenvolvimento
- Funciona como esperado
- Podem ser implementados com as mesmas características.

7.2.5 - Em que consiste o passo “Deployment and Maintenance”? 104

Deployment começa assim que o produto acaba de ser testado e é aprovado para release,
vendido e distribuído para um ambiente de produção. Isto pode envolver instalação, customização,
testes e possivelmente um período de avaliação.
Passagens de conhecimento e suporte são importantes, para que o software seja corretamente
usado, de forma eficiente.
Manutenção e melhorias ao software que lidem com falhas ou novos requisitos podem durar algum
tempo e esforço, uma vez que requisitos em falha podem forçar a um redesign do software

7.3 - Quais algumas abordagens de desenvolvimento de software? 105

- Waterfall
- Incremental
- Spiral
- Agile e Scrum

7.3.1 - Explique a abordagem Waterfall 106

As atividades de desenvolvimento são executadas por ordem, com a possibilidade de sobreporem,
mas com pouca ou nenhuma iteração entre elas.
As necessidades do utilizador são determinadas, os requisitos são definidos, e todo o sistema é
desenhado, compilado e testado para uma grande entrega, num determinado ponto do tempo. É
uma abordagem motivada pela documentação, mais apropriada para sistemas altamente
precedentes com requisitos estáveis.
Waterfall model é também referido como linear e sequencial, uma vez que o fluxo de atividades
são também lineares e sequenciais.
Neste modelo, as atividades de desenvolvimento de software passam para a próxima fase quando
as atividades na fase atual estiverem concluídas. No entanto, nesta abordagem, não podemos
voltar ao estágio anterior.

7.3.2 - Explique a abordagem Incremental 107

Esta abordagem determina as necessidades do utilizador e define uma arquitetura generalizada,

mas depois entrega um sistema em séries de incrementos (“software builds”). O primeiro build
incorpora uma parte dos recursos totais planeados, a próxima acrescenta mais recursos, e assim
sucessivamente, até todo o sistema ficar completo.

7.3.3 - Explique a abordagem Spiral 108

Esta é uma abordagem motivada pela prototipagem controlada do risco. Desenvolve protótipos
cedo, no processo de desenvolvimento, para endereçar áreas de risco, seguidas de um
assessment dos resultados dessa prototipagem, para que se determine outras áreas de risco para
fazer o protótipo. Áres que são frequentemente alvos de protótipos incluem requisitos do utilizador
e performance do algoritmo. A prototipagem continua até que as áreas de alto risco sejam
resolvidas ou mitigadas a um nível aceitável.
Durante cada iteração ou ciclo, é explorado o sistema em grande profundidade, adicionando mais
detalhe.
Esta abordagem é apropriada para projetos que trabalham num domínio desconhecido ou com
outras vertentes técnicas não provadas. A natureza iterativa permite que se obtenha conhecimento
durante os primeiros passes, para informar a passes subsequentes. Requer um compromisso up-
front baixo.

7.3.4 - Explique a abordagem Agile e Scrum 109

Este processo de desenvolvimento de software (agile) e o seu método mais popular (scrum) usam
uma maneira dinâmica e iterativa para desenvolver software. As equipas funcionam em sprints de
uma semana ou alguns meses para construir e entregar software que os clientes possam usar e
dar feedback.
Agile é sobre “mover” rápido, entregar versões mais frequentemente, e responder ao que os
utilizadores realmente precisam, mesmo que isso vá contra o que estava inicialmente planeado.
Isto significa não precisa de uma lista completa de requisitos ou uma SOW completa antes de
começar. Ao invés disso, move-se numa direção com a ideia de que podemos mudar de direção
durante o caminho.

08. Requirements Analysis

8.1 - O que é análise de requisitos ou engenharia de requisitos? 110

É um processo usado para determinar as necessidades e expectativas de um produto novo.

Envolve comunicações frequentes com as partes interessadas e utilizadores finais sobre o
produto, para definir expectativas, resolver conflitos e documentar todos os requisitos chave.

8.2 - Quem está envolvido na análise de requisitos de negócio? 111

A análise de requisitos de negócio envolve um esforço de equipa de todas as partes interessadas,

desenvolvedores de software, utilizadores finais e gestores de clientes para atingir um
entendimento partilhado de tudo o que o produto deverá fazer. Isto é sempre feito num estágio
inicial do projeto, para garantir que o produto final está conforme todos os requisitos.

8.3 - Quais os passos no processo de análise de requisitos? 112

1 - Identificação de stakeholders chave e utilizadores finais

2 - Obter requisitos
3 - Categorizar requisitos
4 - Interpretar e registar requisitos
5 - Sign Off

8.3.1 - Em que consiste a identificação de stakeholders chave e end-users? 113

Os stakeholders são os principais patrocinadores do projeto. Eles é que têm a última palavra no
que deverá ser incluído no scope do projeto.
Depois são identificados os utilizadores finais do produto. Uma vez que o produto deve satisfazer
as suas necessidades, a sua participação é igualmente importante.

8.3.2 - Em que consiste a captura de requisitos? 114

… em perguntar aos stakeholders e end-users os seus requisitos para o novo produto.

Algumas técnicas para fazer isso:
- ter entrevistas individuais
- conversas de grupo focadas
- utilizar casos de uso
- construir protótipos

8.3.3 - Em que consiste a categorização de requisitos? 115

Os requisitos podem ser de vários tipos, pelo que deverão ser agrupados, para evitar confusões.
São normalmente divididos em quatro categorias:
- Requisitos funcionais - funções que o produto precisa de executar
- Requisitos técnicos - problemas técnicos que devem ser considerados para uma implementação
bem sucedida do produto
- Requisitos transacionais (transitional) - passos precisos para implementar o novo produto de
forma suave
- Requisitos operacionais - operações a serem executadas no backend para um bom
funcionamento do produto

8.3.4 - Em que consiste a interpretação e o registo de requisitos? 116

Uma vez categorizados, é necessário determinar que requisitos são atingíveis e documentar cada
um.
Algumas técnicas neste ponto:
- Definir requisitos de modo preciso - assegurar que os requisitos são corretamente nomeados,
suficientemente detalhados e relacionados com as necessidades de negócio
- Prioritizar requisitos - prioritizar requistos e listá-los baseado nos mais críticos e nos que são
“bons de ter”
- Fazer uma análise de impacto - para ter a certeza que foram completamente entendidas as
consequências dos requisitos
- Resolver conflitos - marcar reuniões com os stakeholders e resolver requisitos conflituosos.
Pode-se também encenar uma análise de cenário para explorar como o(s) requisito(s) poderão
trabalhar em possíveis cenários.
- Analisar viabilidade - fazer uma análise detalhada do produto, baseada nos requisitos recolhidos
para determinar a sua confiabilidade e identificar problemas maiores.
Depois de todos os requisitos estarem analisador, criar um documento detalhado e partilhá-lo com
os stakeholders, end-users e equipas de desenvolvimento

8.3.5 - Em que consiste o Sign Off? 117

Uma vez tomada a última decisão sobre os requisitos, ter a certeza que existe um acordo assinado
pela parte dos stakeholders. Isto é feito para assegurar que não há mudanças nem crescimento
incontrolado do scope do projeto

8.4 - Quais os passos para a análise de requisitos? 118

1 - Desenhar um diagrama de contexto

2 - Desenvolvimento de um protótipo (opcional)
3 - Modelar os requisitos
4 - Finalização de requisitos

8.4.1 - Em que consiste o Context Diagram? 119

O propósito deste diagrama é descobrir como desenhar um novo sistema dentro da organização
ou como modificá-lo.
São diagramas complexos que desenham a análise de sistema de forma clara e simples.
As setas indicam o fluxo de dados entre elementos externos e o sistema interno.

8.4.2 - Em que consiste o desenvolvimento de um protótipo 120

É uma parte importante no desenvolvimento, uma vez que ajuda a organização a encontrar
requisitos específicos dos clientes. Baseado na resposta do cliente, o protótipo é alterado até
atingir o máximo de satisfação do cliente.
O protótipo permite ao cliente imaginar o sistema a ser criado e entender os seus requisitos.
Se os desenvolvedores e end-users precisarem de alcançar algum aspeto do sistema, o protótipo
ou réplica ajuda-os a finalizar esses elementos.
O protótipo é criado mais rapidamente e a um custo mais acessível, mas vem com algumas
limitações e não é aceite na análise final

8.4.3 - Em que consiste a modelação de requisitos? 121

Este estágio envolve criar modelos de requisitos que permitam aos stakeholders e clientes
imaginar o produto a ser feito. Várias funções, tabelas de dados, elementos externos, e as
relações entre si, representadas em gráficos. Uma visão gráfica ajuda a encontrar falhas nos
requisitos. Isto permite aos desenvolvedores a ver se há inconsistências, elementos em falta,
errados ou não necessários adicionadas ao sistema. Estes modelos de requisitos podem ser
divididos em categorias.

8.4.3.1 - Em que categorias podem ser divididos os modelos de requisitos? 122

- Diagramas de fluxo de dados - uma preparação gráfica que usa símbolos e notações para
mostrar como é que um negócio opera através do movimento de dados
- Diagram entidade-relação - um gráfico de fluxo que descreve coisas como pessoas, conceitos ou
objetos relacionados dentro de um sistema.
- Dicionários de dados - estes contém diferentes definições, nomes e outras formas de elementos
de dados utilizados num projeto
- Diagrama de state-transition - representam as mudanças que podem ocorrer dentro do sistema

8.4.4 - Em que consiste a Finalização de requisitos? 123

Modelos de requisitos adicionam entendimento do sistema. Todas as correções necessárias são

feitas neste estágio. Todas as ambiguidades são removidas e os fluxos de dados examinados nos
vários modelos. O processo de elicitação e subsequente análise leva a grande entendimento do
sistema. Finalmente, os requisitos são aprovados e a documentação começa

8.5 - Quais algumas técnicas de análise de requisitos? 124

1 - Business Process Model and Notation (BPMN)
2 - Flowcharts
3 - Gantt Charts
4 - Gap Analysis

8.5.1 - Em que consiste o BPMN? 125

BPMN é usado para criar gráficos que simplificam o entendimento do processo de negócio. É uma
técnica popular usada pelos analistas de negócio para coordenar a sequência de mensagens entre
diferentes participantes num conjunto de atividades relacionadas.

8.5.2 - Em que consiste um flowchart? 126

Os flowcharts representam fluxos sequenciais ou uma lógica controlada de um conjunto de

atividades relacionadas. São uteis para membros da equipa técnica ou não.

8.5.3 - Em que consistem gráficos Gantt? 127

Estes gráficos fornecem uma representação visual das tarefas juntamente com as timelines
programadas. Isto ajuda um analista de negócio a visualizar todas as tarefas de um projeto do
início ao fim.

8.5.4 - Em que consiste o Gap Analysis? 128

Gap analysis avalia as brechas na performance de um produto para determinar se vai ao encontro
dos requisitos ou não. Ajudam os analistas de negócio a determinar o estado atual e o estado
pretendido de um produto.