Gerência e Qualidade de Software

Prévia do material em texto

GIT - VISÃO GERAL
Elementos de componente. Conjunto de ferramentas acopladas em um sistema de gestão de arquivos
(p. ex., um banco de dados) que possibilita acesso à gestão de cada item de configuração de software.
Elementos de processo. Coleção de procedimentos e tarefas que definem uma abordagem eficaz de
gestão de alterações (e atividades relacionadas) para todas as partes envolvidas na gestão, engenharia e
uso do software.
Elementos de construção. Conjunto de ferramentas que automatizam a construção do software,
assegurando que tenha sido montado o conjunto apropriado de componentes validados (i.e., a versão
correta).
Elementos humanos. Conjunto de ferramentas e características de processo (abrangendo outros
elementos de CM) usado pela equipe de software para implementar um SCM eficaz.
Referenciais: é um conceito de gerenciamento de configuração de software que ajuda a controlar
alterações sem obstruir seriamente as alterações justificáveis. Uma especificação ou produto que tenha
sido formalmente revisado e acordado, que depois serve de base para mais desenvolvimento e pode ser
alterado somente por meio de procedimentos formais de controle de alteração. Para que um item de
configuração de software se torne uma referência para o desenvolvimento, as alterações devem ser feitas
rápida e informalmente. No entanto, uma vez estabelecida uma referência, podem ser feitas alterações,
mas deve ser aplicado um processo específico e formal para avaliar e verificar cada alteração
Gerência e Qualidade de
Software
SEMANA 1
Conhecer os principais tópicos a serem cobertos na disciplina;
Conhecer o versionamento de software via o uso de uma ferramenta.
é um software livre que atua como repositório de arquivos com controle de versões.
Similares são: CVS, SVN, Mercurial, BitKeeper, Bazzar, Monotone 
Mudanças são inevitáveis quando o software de computador é construído e podem causar confusão quando os
membros de uma equipe de software estão trabalhando em um projeto. Babich [Bab86] sugere uma abordagem
que minimiza a confusão, melhora a produtividade e reduz o número de erros quando afirma: “A gestão de
configuração é a arte de identificar, organizar e controlar modificações no software que está em construção por
uma equipe de programação. O objetivo é maximizar a produtividade minimizando os erros”.
Fluxo do SCM:
(1) identificar a alteração, 
(2) controlar a alteração, 
(3) assegurar que a alteração esteja sendo
implementada corretamente e 
(4) relatar as alterações a outros envolvidos
O gerenciamento de configuração de software é um conjunto
de atividades desenvolvidas para gerenciar alterações ao longo
de todo o ciclo de vida de um software. O SCM pode ser visto
como uma atividade de garantia de qualidade do software
aplicada em todo o processo do software.
GESTÃO DE CONFIGURAÇÃO DE SOFTWARE
ES
SE
N
CI
AI
S
Acompanhamento de dependências e gestão de alterações: A capacidade de manter o controle de todas
essas relações é crucial para a integridade das informações armazenadas no repositório e para a geração de
outros produtos nele baseados, e é uma das contribuições mais importantes do conceito de repositório para o
aperfeiçoamento do processo de desenvolvimento de software.
Controle de requisitos: Essa função especial depende da gestão de links e proporciona a capacidade de
controlar todos os componentes de projeto e construção e outros produtos que resultam de uma especificação
especial de requisitos (acompanhamento adiante). Além disso, proporciona a capacidade de identificar quais
requisitos geraram determinado produto (acompanhamento retroativo).
Gestão de configuração: mantém controle de uma série de configurações representando marcos de projeto
específicos ou versões de produção.
Pistas de auditoria: estabelece informações adicionais sobre quando, por que e por quem foram feitas as
alterações. As informações sobre a origem das alterações podem ser colocadas como atributos de objetos
específicos no repositório. 
Itens de Configuração. Uma seta curva indica uma relação de composição.
Isto é, DataModel e ComponentN fazem parte do objeto DesignSpecification.
Uma seta reta bidirecional indica uma inter-relação. Se for feita uma alteração
no objeto SourceCode, as inter-relações permitem determinar quais outros
objetos (e SCIs) podem ser afetados.
CARACTERÍSTICAS DE REPOSITÓRIO
Versões: O repositório deve poder controlar uma grande variedade de tipos
de objetos, incluindo texto, gráficos, bitmaps, documentos complexos e
objetos especiais, como definições de tela e relatório, arquivos de objeto,
dados de testes e resultados.
O controle de versão combina procedimentos e ferramentas para gerenciar diferentes versões dos objetos de
configuração criados durante o processo de software. Um sistema de controle de versão implementa ou está
diretamente integrado a quatro recursos principais: (1) um banco de dados de projeto (repositório) que
armazena todos os objetos de configuração relevantes; (2) um recurso de gestão de versão que armazena todas
as versões de um objeto de configuração (ou permite que qualquer versão seja construída usando diferenças
das versões anteriores); (3) uma facilidade de construir que permite coletar todos os objetos de configuração
relevantes e construir uma versão específica do software. 
INTEGRAÇÃO CONTÍNUA
As melhores práticas do SCM incluem: (1) minimizar o número de variantes de código; (2) testar desde o início e
com frequência; (3) integrar desde o início e com frequência; e (4) usar ferramentas para automatizar o teste, a
construção e a integração do código. Vantagens: 
Feedback acelerado. Notificar os desenvolvedores imediatamente quando a integração não dá certo permite
que os consertos ocorram enquanto o número de alterações realizadas é pequeno.
Maior qualidade. Criar e integrar software sempre que necessário gera confiança sobre a qualidade do
produto desenvolvido.
Menor risco. Integrar os componentes com antecedência evita o risco de uma fase de integração longa, pois as
falhas de projeto são descobertas e consertadas antes.
Melhores relatórios. Fornecer informações adicionais (p. ex., métricas de análise de código) permite uma
contabilidade de status de configuração mais precisa.
PROCESSO DE GESTÃO DE ALTERAÇÃO
Define uma série de tarefas que têm quatro objetivos principais: (1) identificar todos os itens que
coletivamente definem a configuração do software; (2) gerenciar alterações de um ou mais desses itens;
(3) facilitar a construção de diferentes versões de uma aplicação; e (4) assegurar que a qualidade do
software seja mantida à medida que a configuração evolui com o tempo. Aplicado para responder as
questões: 
A PARTIR DAS QUESTÕES SÃO DEFINIDAS AS CINCO TAREFAS DA SCM
A gestão de impacto é realizada com três ações [Sou08]. Primeiro, uma rede de impacto identifica os membros de
uma equipe de software (e outros envolvidos) que podem afetar ou ser afetados pelas alterações feitas no
software. Uma definição clara da arquitetura do software (Capítulo 10) ajuda muito na criação de uma rede de
impacto. Em seguida, a gestão de impacto adiante (forward impact management) avalia o impacto das alterações
feitas por você sobre os membros da rede de impacto e, então, informa-os sobre o impacto dessas alterações.
Por último, a gestão de impacto retroativo (backward impact management) examina as alterações feitas por
outros membros da equipe e o impacto sobre o seu trabalho e incorpora mecanismos para reduzir o impacto.
GESTÃO DE IMPACTO
Assegura que a alteração foi realizada
corretamente. Uma auditoria de
configuração de software complementa a
revisão técnica avaliando o objeto de
configuração quanto a características que
em geral não são consideradas durante a
revisão. A auditoria propõe e responde às
seguintes questões:
AUDITORIA DE CONFIGURAÇÃO
O relatório de status de configuração (CSR, do inglês configuration status reporting) (às vezes chamado de
contabilidade de status) é uma tarefa do SCM que responde às seguintes questões: (1) O que aconteceu?(2)
Quem fez? (3) Quando aconteceu? (4) O que mais será afetado?
RELATÓRIO DE STATUS
O relatório de status de configuração (CSR, do inglês configuration status reporting) (às vezes chamado de
contabilidade de status) é uma tarefa do SCM que responde às seguintes questões: (1) O que aconteceu? (2)
Quem fez? (3) Quando aconteceu? (4) O que mais será afetado?
Cada alteração deve ser classificada em uma dentre quatro classes:
Classe 1. Alteração de conteúdo ou função que corrige um erro ou melhora o conteúdo ou a funcionalidade local.
Classe 2. Alteração de conteúdo ou função que tenha impacto sobre outros objetos de conteúdo ou sobre os
componentes funcionais.
GESTÃO DE ALTERAÇÃO ÁGIL
Classe 3. Alteração de conteúdo ou função que tenha um amplo impacto em uma aplicação (p. ex., extensão ou
funcionalidade principal, melhora significativa ou redução em conteúdo, alterações importantes necessárias na
navegação).
Classe 4. Uma alteração importante de projeto (p. ex., alteração na abordagem de projeto da interface ou na
estratégia de navegação) que será notada imediatamente por uma ou mais categorias de usuário.
está relacionada à gestão de configuração no sentido de que um sistema de gestão de conteúdo (CMS, do inglês
content management system) estabelece um processo (suportado por ferramentas apropriadas) que adquire o
conteúdo existente (de uma ampla variedade de objetos de configuração de jogos e/ou aplicativos), estrutura
esse conteúdo de maneira que ele possa ser apresentado a um usuário e, então, fornece-o ao ambiente no lado
do cliente para ser exibido.
O uso mais comum de um sistema de gestão de conteúdo ocorre quando é criada uma aplicação dinâmica. 
Classe 2. Alteração de conteúdo ou função que tenha impacto sobre outros objetos de conteúdo ou sobre os
componentes funcionais.
GESTÃO DE CONTEÚDO
GIT -LISTA DE COMANDOS
INIT Cria um repositório vazio.
CLONE Primeiro chama init para criar um repositório vazio. Em seguida, ele copia para esse repositório
todos os commits de um repositório remoto, passado como parâmetro
COMMIT
Usados para criar snapshots (ou fotografias) dos arquivos de um sistema. Uma vez tiradas essas
fotografias, elas são armazenadas no sistema de controle de versões, de forma compactada e
otimizada, para não ocupar muito espaço em disco. Recomenda-se que desenvolvedores
realizem commits periodicamente, sempre que tiverem efetuado uma mudança importante no
código.
ADD Salvar o conteúdo do arquivo no index. Feito isso, podemos usar um commit para salvar no
repositório local a versão adicionada ao index. 
Controle de Versão:
Um repositório central para o projeto de jogo ou aplicativo deve ser estabelecido. O repositório terá as
versões atuais de todos os objetos de configuração (conteúdo, componentes funcionais e outros).
Cada desenvolvedor Web cria sua própria pasta de trabalho. A pasta contém os objetos que estão sendo
criados ou alterados em determinado instante.
Os relógios das estações de trabalho de todos os desenvolvedores devem estar sincronizados. Isso é
feito para evitar conflitos de sobrescrita, quando dois desenvolvedores fazem alterações em horários muito
próximos.
À medida que novos objetos de configuração são desenvolvidos ou objetos existentes são alterados,
são importados para o repositório central. A ferramenta de controle de versão vai gerenciar todas as
funções de entrada (check-in) e saída (check-out) das pastas de trabalho de cada desenvolvedor. A ferramenta
também fornecerá atualizações automáticas de e-mail a todas as partes envolvidas quando forem feitas
alterações no repositório.
À medida que objetos são importados ou exportados do repositório, é gerada uma mensagem automática com
data e hora. Isso proporciona informações úteis para auditoria e pode se tornar parte de um esquema eficaz de
relatórios.
STATUS
Mostra o estado do diretório de trabalho e do index (arquivos do diretório de trabalho que foram
alterados pelo desenvolvedor, mas que ele ainda não adicionou no index ou não são rastreados
pelo git, ou seja, eles ainda não foram objetos de um add que encontram-se no index,
aguardando um commit. 
DIFF Destacar as modificações realizados nos arquivos do diretório de trabalho e que ainda não foram
movidas para o index (ou stage).
LOG Lista informações sobre os últimos commits, como data, autor, hora e descrição do commit.
PUSH
Copia os commits mais recentes do repositório local para o repositório remoto. Portanto, ele é
uma operação mais lenta, pois envolve comunicação pela rede. Um push deve ser usado quando
o desenvolvedor deseja tornar uma modificação visível para os demais desenvolvedores. 
PULL
Para atualizar seu repositório local (Primeiro, um pull copia os commits mais recentes do
repositório central para o repositório local do desenvolvedor-FETCH e Em seguida, o comando
pull atualiza os arquivos do diretório de trabalho - MERGE.
Pull requests
Mecanismo que viabiliza que um branch seja revisado e discutido antes de ser integrado no
branch principal. Quando se usa pull requests, um desenvolvedor sempre implementa novas
funcionalidades em um branch separado. Concluída a implementação, ele não integra
imediatamente o novo código no branch principal. Antes que isso ocorra, ele abre uma
solicitação para que seu branch seja revisado e aprovado por um segundo desenvolvedor.
Squash Comando que permite unir diversos commits em um único commit. É uma operação
recomendada, por exemplo, antes de submeter pull request
Forks
Mecanismo que o GitHub oferece para clonar repositórios remotos, isto é, repositórios
armazenados pelo próprio GitHub. Um fork é realizado via interface do GitHub. Na página de
qualquer repositório, existe um botão para realizar essa operação. Se fizermos um fork do
repositório torvalds/linux será criado uma cópia desse repositório na nossa conta do GitHub,
chamado, por exemplo, mtov/linux.
Conflito de Merge acontecem quando dois
desenvolvedores alteram o mesmo trecho de
código ao mesmo tempo.
Branches: é a organização o diretório de
trabalho em diretórios virtuais. Um
desenvolvedor somente pode alterar o
branch corrente de A para B se as
modificações que ele fez em A estiverem
salvas. Isto é, se ele tiver realizado antes um
add e commit. 
Conhecer a automação de compilação e integração de software via o
uso das ferramentas Maven, Gradle e Cmake.
SEMANA 2
Usada primariamente em Java, mas também outras linguagens
POM (Project Object Model), arquivo XML descreve o projeto de software sendo construído:
Dependências sobre módulos e componentes externos 
Ordem de compilação 
Diretórios
Plug-ins necessários
Facilitar a compilação do código, o empacotamento (JAR, WAR, EAR, …), a execução de testes
unitários, etc.
Unificar e automatizar o processo de geração do sistema. Nada mais de uma coleção de
passos e scripts a serem executados manualmente.
Centralizar informações organizadas do projeto, incluindo suas dependências, resultados de
testes, documentação, etc.
Reforçar boas práticas de desenvolvimento, tais como: separação de classes de teste das
classes do sistema, uso de convenções de nomes e diretórios, etc.
Ajuda no controle das versões geradas (releases) dos seus projetos.
O Maven é uma ferramenta de gerenciamento de dependências e do ciclo de vida de projetos de
software no sentido técnico. Isso inclui:
CONCEITOS
Artefato (artifact): Um artefato é geralmente um arquivo JAR que fica no repositório do Maven, mas pode ser de
outro tipo. Identificados através dos seguintes elementos: grupo (é como o endereço do site ao contrário, como
br.com.starcode, org.apache, com.google, com.ibm, etc); identificador único de artefato ( geralmente é o nome do
projeto. Ele deve ser único por grupo); Número de versão: a versão do projeto, como 1.4.2 ou 3.0 (se houver o
sufixo -SNAPSHOT (0.0.1-SNAPSHOT, por exemplo) significa que o projeto está em desenvolvimento e o pacote
pode ser alterado); Tipo do projeto (jar, war, ear, pom (projeto de configuração); e Classificador: identificação
opcional para diferenciar variaçõesda mesma versão (Por exemplo, se o programa é compilado para diferentes
versões do Java podemos usar os classificadores jdk4 e jdk6. Se há variações específicas para Sistemas
Operacionais, podemos ter os classificadores linux e windows).
Repositório local: É um diretório em seu PC onde os artefatos são armazenados após baixados de um repositório
remoto na internet ou na intranet.
Repositório remoto: Consiste numa aplicação que disponibiliza artefatos do Maven. Pode se um repositório
público na Internet, onde criadores de bibliotecas e frameworks disponibilizam seus artefatos, ou pode ser um
repositório privado da empresa, disponível na intranet.
Existe um repositório central que já vem configurando no Maven, mas algumas empresas criam seus próprios
repositórios. Inclusive você pode criar o seu instalando o Artifactory ou Nexus num servidor.
Quando adicionamos esses repositórios remotos em nossa instalação do Maven, ele é capaz de localizar e baixar
automaticamente as dependências através da identificação do artefato.
Arquivo POM: O arquivo pom (pom.xml) é a configuração principal do Maven e estará presente em todo projeto.
Nele você declara a identificação do seu projeto (que após gerado será também um artefato Maven), as
dependências, repositórios adicionais, etc.
http://www.jfrog.com/home/v_artifactory_opensource_overview
http://www.sonatype.org/nexus/
Centralização das informações: O Maven centraliza as informações dos projetos no arquivo pom.
Padronização do ambiente de desenvolvimento: Através da especificação do projeto, incluindo suas
características e dependências, o Maven constrói a estrutura necessária do projeto, baixando automaticamente as
versões corretas das dependências (JARs, por exemplo) de um repositório central ou de um repositório privado
(contendo sistemas da empresa).
Gerenciamento de dependências: o Maven faz o download automático de dependências para o projeto e os
adiciona ao classpath do seu projeto. Cada dependência pode ter também as suas próprias dependências. Elas são
chamadas dependências transitivas. O Maven resolve essa árvore de dependências e traz tudo o que você
precisa.
Facilidade de compreensão do projeto
Automação: O Maven gerencia o ciclo de vida da aplicação. Após configurar um projeto, você será capaz de
executar comandos que vão desde a compilação até a geração de documentação (Javadoc) e um site padrão
contendo informações sobre o projeto. Uma vez feita a configuração necessária, o projeto pode ser baixado e
compilado sem nenhum esforço. Novas versões podem ser geradas em servidores de Integração Contínua e
testadas automaticamente sempre que necessário.
1. process-resources
2. compile
3. process-test-resources
4. test-compile
5. test
6. package
7. install
8. deploy
mvn process-resources
mvn compile
mvn process-test-resources
mvn test-compile
mvn test
mvn package
mvn install
mvn deplo
Ciclo de vida padrão do Maven
O Maven possui um ciclo de vida padrão. Cada
passo do ciclo de vida é chamado de Goal e
possui plugins específicos. Os mais importantes
são:
validate: valida o projeto e se as informações
necessárias para os próximos passos estão
disponíveis, como as dependências por
exemplo.
compile: compila o código-fonte.
test: executa os testes unitários (JUnit, por
exemplo).
package: empacota o código compilado em um JAR, WAR, etc.
integration-test: executa os testes de integração.
install: adiciona o pacote gerado ao repositório local, assim outros projetos na mesma máquina podem usar
essa dependência.
deploy: copia o pacote final para o repositório remoto, disponibilizando-o para outros desenvolvedores e
outros projetos.
VANTAGENS DO MAVEN
DESVANTAGENS DO MAVEN
Incompatibilidade de dependências
Algumas tecnologias simplesmente não vão funcionar bem com o Maven
Trata-se de uma ferramenta de build open source bastante poderosa que nos permite configurar
arquivos de build por meio da sua DSL (Domain Specific Language) baseada na linguagem
Groovy.
Além da DSL, a ideia do Gradle é permitir configurações baseando-se em tasks, ou seja, quando queremos criar
algum novo comportamento durante o build, vamos criar uma task.
é um "Cross-Platform Makefile Generator" ou uma ferramenta open-source que permite gerar
automaticamente scripts de construção de aplicação em diferentes plataformas.
https://github.com/gradle/gradle
http://groovy-lang.org/
http://groovy-lang.org/
http://groovy-lang.org/
JUNIT
@Test Identifica que este método é um método de teste. 
@Before 
Executará o método antes de cada teste. Este método pode ser usado
para preparar o ambiente de teste, por exemplo, lendo dados do
usuário.
@After Executará o método após cada teste. 
Conhecer a automação de teste de software via o uso das ferramentas
JUnit, Selenium e Cucumber.
SEMANA 3
O teste unitário é uma modalidade de testes que se concentra na verificação da menor unidade do projeto de
software. É realizado o teste de uma unidade lógica, com uso de dados suficientes para se testar apenas à lógica
da unidade em questão. Em sistemas construídos com uso de linguagens orientadas a objetos, essa unidade
pode ser identificada como um método, uma classe ou mesmo um objeto. O JUnit é um framework que facilita o
desenvolvimento e execução de testes unitários em código Java. 
@BeforeClass 
Executará o método antes do início de todos os testes. Por
exemplo: usado para se conectar a um banco de dados
@AfterClass 
Executára o método após todos os testes finalizarem. Por
exemplo: usado para desconectar a base de dados.
@Ignore 
 O método será ignorado. Usado quando fizemos alguma
mudança e ainda não adaptamos o teste. 
@Test
(expected=IllegalArgumentException.class) 
Testa se o método levanta a exceção especificada. 
@Test (timeout=100) Falha se o teste levar mais que 100 milisegundos
SELENIUM
É uma ferramenta de teste automatizada de código aberto usada para testar aplicativos da Web em vários
navegadores. Ele é construído principalmente em Java e suporta vários navegadores e linguagens de
programação. uma interface fácil de usar que registra as interações do usuário no navegador e as exporta como
um script reutilizável.
O Selenium IDE faz parte da suíte Selenium e foi desenvolvido para acelerar a criação de scripts de automação. É
uma ferramenta de prototipagem rápida e pode ser usada por engenheiros sem nenhum conhecimento de
programação. Abaixo o fluxo de funcionamento do Selenium:
Os comandos de selênio são amplamente classificados em:
1. Ações - Comandos que interagem diretamente com o aplicativo:
clickAndWait(),
tipoAndWait()
2. Permitir que o usuário armazene determinados valores em uma variável definida pelo usuário:
storeTitle()
3. Asserções - Verifica o estado atual do aplicativo juntamente com um estado esperado. Existem
diferentes tipos de asserções:
O comando Assert garante que a execução do teste seja encerrada em caso de falha
O comando Verify garante a execução do script mesmo se a verificação tiver falhado
O comando WaitFor aguarda que uma condição específica seja atendida antes de executar a próxima etapa de
teste
BDD é um conjunto de práticas de engenharia de software projetado para ajudar as equipes a construir e
entregar mais rápido software de alta qualidade.
Para explicar o funcionamento do BDD vamos usar o seguinte exemplo: uma equipe praticante de BDD decide
implementar uma nova funcionalidade e para isso, eles trabalham em conjunto com os usuários e outras partes
interessadas para definir as histórias e cenários do que os usuários esperam dessa funcionalidade. Em
particular, os usuários ajudam a definir um conjunto de exemplos concretos que ilustram resultados que a nova
funcionalidade deve fornecer. Esses exemplos são criados utilizando um vocabulário comum e podem ser
facilmente compreendidos pelos usuários finais e membros da equipe de desenvolvimento de software, e
geralmente são expressos usando Cenário(Scenario), Dado(Given), Quando(When) e Então (Then).
Exemplo:
Cenário: Transferir dinheiro para uma conta poupança
Dado que eutenho uma conta corrente com 1000.00
E que eu tenho uma conta de poupança com 2.000,00
Quando eu transferir 500,00 a partir de minha conta corrente para a minha conta poupança
Então eu deveria ter 500,00 em minha conta corrente
E eu deveria ter 2.500,00 em minha conta poupança
Depois de especificada a nova funcionalidade, sempre que possível estes exemplos concretos são
automatizados sob a forma de especificações executáveis, que tanto valida o software quanto fornece uma
documentação atualizada, técnica e funcional. Logo, existem várias ferramentas e frameworks que apoiam esta
fase do BDD, transformando esses requisitos em testes automatizados que ajudam a orientar o desenvolvedor
para que a nova funcionalidade seja desenvolvida corretamente e dentro do prazo.
Desenvolvimento orientado a comportamento
CUCUMBER
 uma ferramenta usada para executar testes de
aceitação automatizados que foram criados em
um formato BDD. Um de seus recursos mais
destacados é a capacidade de realizar descrições
funcionais de texto simples (escritas numa
linguagem chamada Gherkin) como testes
automatizados. 
Esta característica incrível da abordagem BDD
apresenta as seguintes vantagens:
Escrever testes de BDD em uma linguagem
onipresente, estruturada em torno do
modelo de domínio e amplamente usada por
todos os membros da equipe incluindo
desenvolvedores, testadores, analistas de
negócio e clientes;
Conexão técnica com membros não técnicos
de uma equipe de software;
Permitir a interação direta com o código do
desenvolvedor; os testes de BDD são
escritos em um idioma que também podem
ser criados pelos stakeholders envolvidos;
Por último, mas não menos importante, os
testes de aceitação podem ser executados
automaticamente, enquanto são executados
manualmente pelos stakeholders.
o teste de automação usando o Cucumber é criado em uma linguagem de domínio do negócio, ou em uma
linguagem natural, que pode ser facilmente produzida por todos os membros do projeto. A comunicação é
crucial para qualquer time de desenvolvimento, especialmente para um time Ágil.
Conhecer a análise de cobertura de teste via o uso de ferramenta;
Conhecer os principais tipos de refatoração de software. SEMANA 4
COVERAGE.PY
Os engenheiros do Python usam Coverage.py para medir a eficácia de um conjunto de testes quando aplicado
a um aplicativo. Ao medir a cobertura de teste, há quatro medições que podem ser feitas que fornecem
informações sobre a eficácia de um conjunto de testes para uma aplicação específica. Essas quatro medidas
são: cobertura de declaração, cobertura de função, cobertura de agência e cobertura de condição.
Cobertura de Declaração (Statement Coverage): A cobertura de instrução informa quantas linhas de
código foram executadas pelo conjunto de testes e quantas linhas de código não foram executadas. A
principal medida aqui é a porcentagem de código executado para cada arquivo individual, bem como para
todo o aplicativo. Obviamente, a meta é atingir 100% de cobertura.
não tem uma opção de relatório que mostre cobertura em nível de função ou cobertura de condição.
JaCoCo
Cobertura de Função (Function Coverage): informa quais funções foram chamadas e quais funções não
foram chamadas. Observar a cobertura de código a partir do nível de funções é uma boa maneira de
encontrar código morto. Analisar a cobertura da função ajuda você a descobrir como melhorar a cobertura
de um conjunto de testes. 
Cobertura de Agências (Branch Coverage): medida que informa se cada ramificação de uma instrução de
controle foi executada. Exemplos de instruções de controle são instruções if e instruções de caso. Como
exemplo, uma instrução if simples sem cláusula else tem duas ramificações possíveis. Uma ramificação é
executada quando a condição da instrução if é avaliada como true. A segunda ramificação é executada
quando a condição é false. É importante ressaltar que é possível ter 100% de cobertura de declaração e
menos de 100% de cobertura de agência.
Cobertura de Condição (Condition Coverage): medida que informa se cada subexpressão booleana
dentro de um programa foi avaliada como verdadeira e falsa durante a execução de um conjunto de
testes.
Jacoco é uma biblioteca gratuita de Cobertura de Código para Java que pode ser usada para capturar a
cobertura de Código durante a execução de Testes de Unidade e Suítes de Automação completas. Ele
instrumenta as Classes do aplicativo quando elas são carregadas na JVM e despeja os dados mediante
solicitação ou na saída.
Pode ser usado em conjunto com Maven e com Gradle. 
Sobre limiares (thresholds) dos valores de cobertura de teste, é correto afirmar que: 
com Gradle, é possível informar classes a serem excluídas da verificação dos limiares. 
REFATORAÇÃO
EXTRAIR MÉTODO: Se você tiver um fragmento de código que pode ser agrupado - Transforme o fragmento em
um método cujo nome explique o propósito do mesmo 
INTERNALIZAR MÉTODO: Se o corpo de um método for tão claro quanto seu nome - Coloque o corpo do
método dentro do corpo do que o chama e remova o método.
INTERNALIZAR VARIÁVEL TEMPORÁRIA: Você tem uma variável temporária que recebe uma única atribuição
de uma expressão simples, e essa variável está atrapalhando outras refatorações. - Substitua todas as
referências a essa variável temporária pela expressão.
SUBSTITUIR VARIÁVEL TEMPORÁRIA POR CONSULTA: Se você estiver usando uma variável temporária para
armazenar o resultado de uma expressão - Extraia a expressão para um método. Substitua todas as
referências à variável temporária pela expressão. Este novo método pode então ser usado em outros
métodos.
 é um passo essencial an- tes de Extrair Método
INTRODUZIR VARIÁVEL EXPLICATIVA: Se você tiver uma expressão complicada: Coloque o resultado da
expressão, ou partes da expressão, em uma variável temporária cujo nome explique o seu propósito.
SUBSTITUIR MÉTODO POR OBJETO MÉTODO: Você tem um método longo que usa variáveis locais de um
modo que você não po- de aplicar Extrair Método (100) - Transforme o método em seu próprio objeto de
modo que todas as variáveis locais se tornem campos desse objeto. Você pode então decompor o
método em outros métodos no mesmo objeto.
DIVIDIR VARIÁVEL TEMPORÁRIA: Você tem uma variável temporária que mais de uma vez recebe uma
atribuição, mas não é uma variável de laço nem um acumulador temporário. - Crie uma variável temporária
separada para cada atribuição.
SUBSTITUIR ALGORITMO: Se você quiser substituir um algoritmo por um mais claro - Substitua o corpo do
método pelo novo algoritmo. 
SEMANA 5
INTEGRAÇÃO CONTÍNUA
conhecer os principais conceitos relacionados à integração contínua;
conhecer algumas métricas de código-fonte de software via uma
ferramenta;
conhecer os principais conceitos relacionados à beleza de código.
A mais popular
Código aberto / grande comunidade por trás
Fácil suporte na internet
Quase 1000 plugins para extensão
Baseada em Java
Focado em instalações locais
Não inclui suporte a testes
Gitlab CI/CD
Uma das principais ferramentas de IC
Grande eficiência
Trio: integração, implantação e entrega
contínua
Integração com Docker
Uso local ou na nuvem
Suporte a testes automatizados
Boa experiência do usuário, facilidade de
aprender
TESTE DE VALIDAÇÃO
CENÁRIOS DE TESTES: 
TESTES DE SISTEMA
de Recuperação de Falhas:
de Segurança
de Estresse
de Desempenho
de Implantação
TESTES DE VERSÃO
TESTES DE USUÁRIO
MÉTRICAS PARA INTERFACE DO USUÁRIO
TESTES DE ACEITAÇÃO
MÉTRICAS DE ESTÉTICA
MÉTRICAS DE CONTEÚDO
MÉTRICAS DE NAVEGAÇÃO
MÉTRICAS PARA CÓDIGO FONTE
PRINCÍPIOS CLEAN CODE
1. Use nomes que revelam seu propósito.
2. Use distinções significativas
3. Use nomes fáceis de se pronunciar, ou pelo menos que
sejam pronunciáveis.
4. Use nomes que sejam fáceis de se buscar.
5. Nomes de classes devem ter nomes com substantivos
6. Nome de métodos é uma boa prática ter verbos
7. Escreva funções melhores
Funções devem fazer somente uma coisa e devem fazê-la bem.
7.1. Faça apenas uma coisa
7.2. Um nível de abstração porfunção
7.3. Use nomes descritivos
Não tenha medo de criar nomes extensos, pois eles são
melhores que um pequeno e enigmático.
7.4. Parâmetros de funções
Devemos evitar passar vários parâmetros para uma função, o
ideal é que nossas funções recebam no máximo 2 parâmetros.
SEMANA 6
PROGRAMAÇÃO PAREADA
Técnica de desenvolvimento de software ágil em que dois programadores trabalham juntos em uma estação de
trabalho. Um deles, o "piloto", escreve o código, enquanto o outro, chamado de "co-piloto" (ou "navegador"),
analisa cada linha do código. Os dois programadores geralmente trocam de papel frequentemente.
Evitando distrações e criando um ambiente colaborativo, em geral, a programação pareada se prova mais
produtiva do que a isolada. Enquanto está analisando, o co-piloto também considera a orientação estratégica do
trabalho, dando ideias para melhorias e comenta sobre possíveis problemas futuros que devem ser resolvidos.
Isso libera o controlador para concentrar toda a sua atenção nos aspectos táticos da tarefa atual.
7.5. Parâmetros lógicos
Parâmetros lógicos é uma má prática, pois mostra
explicitamente que a função faz mais de uma coisa.
7.6. Evite efeitos colaterais e Evite variáveis globais.
Efeitos colaterais são mentiras. Sua função promete fazer
apenas uma coisa, mas ela também faz outras coisas
escondidas.
7.7. Evite repetição
Duplicação de código pode ser um grande mal no seu
software, sempre que você ver que você está repetindo muito
código, extraia isso para funções.
7.8 Escreva comentários com responsabilidade
conhecer os principais conceitos relacionados à programação
pareada;
conhecer os principais conceitos relacionados à revisão de código;
conhecer os principais conceitos relacionados à dívida técnica.
Piloto:
Co-piloto: analisa cada linha de código escrita e dá ideias para melhorias e comenta sobre possíveis
problemas futuros que devem ser resolvidos.
escreve o código. 
“...96% dos programadores que já programaram 
utilizando a técnica de programação em par preferem 
trabalhar em um ambiente com essa metodologia do 
que programarem sozinhos” (Blekinge Institute of Technology)
Mais produtiva do que a programação isolada. 
Evita distrações e cria um ambiente colaborativo. 
Melhor colaboração, maior qualidade, melhor código e melhores práticas de desenvolvimento sustentado.
Melhor aprendizado e compartilhamento de informações entre os desenvolvedores.
Mais de uma pessoa pensando no mesmo problema pode ajudar a criar soluções e cenários mais simples
e eficazes.
V
A
N
T
A
G
E
N
S
equipes que usaram programação pareada completaram 
vários projetos com uma qualidade de código superior, 
além de, em muitos casos, certas funcionalidades terem 
sido implementadas com uma quantidade menor de 
linhas de código do que com programadores sozinhos
(Universidade de Utah)
Tipo Vantagem Desvantagem
Especialista–
especialista
Parece a escolha óbvia para maior
produtividade; pode produzir ótimos
resultados; 
Geralmente fornece pouca percepção sobre
novas maneiras de resolver problemas, pois é
improvável que ambas as partes questionem as
práticas estabelecidas
Especialista–
novato
Cria várias oportunidades para o especialista
orientar o novato; pode introduzir novas ideias,
pois é mais provável que o novato questione as
práticas estabelecidas; o especialista, ao ser
obrigado a explicar práticas estabelecidas, fica
mais propenso a questioná-las. 
Um novato intimidado pode passivamente apenas
“observar o mestre” e hesitar em participar de
forma significativa; e alguns especialistas podem
não ter a paciência necessária para permitir a
participação construtiva de novatos. 
Novato–
novato
Pode produzir resultados significativamente
melhores do que dois novatos trabalhando
independentemente
É mais difícil para novatos desenvolver bons
hábitos sem um “modelo” adequado e, por isso, é
desincentivada
Modelos de Pareamento
Melhora a disciplina do time: programação individual costuma ser cansativa levando à distrações
Compartilhar conhecimento: a rotação entre os papéis de piloto e copiloto e entre os membros das
duplas permite troca de informações, técnicas, conhecimento e melhora o nivelamento do nível técnico
da equipe, além do compartilhamento do conhecimento sobre as diferentes partes do código e
versões do projeto. 
Melhor qualidade do código: supera o desafio de criar códigos limpos e sem erros de forma rápida
pela revisão e aprimoramento constantemente por diferentes integrantes da equipe, já que revisar
sozinho não costuma ser agradável mas aos pares sim. Em dupla, há menor risco de se usar
"gambiarras", já que seu algoritmo vai ser visualizado e revisado por outra pessoa. 
Gera mais união na equipe: o espírito coletivo é fortalecido, pois erros e qualidade do código
passam a ser responsabilidade do time e não de apenas uma pessoa; além disso, amizades são criadas
e relações interpessoais são fortalecidas.
V
A
N
T
A
G
E
N
S
Parear consome 15% a mais de tempo total de trabalho mas reduz,
pelo menos, 15% a quantidade de códigos com defeito
Boas Práticas
Entrosamento: deve existir boa química entre participantes, que precisam entender como os outros
gostam de trabalhar.
Entender o motivo: os programadores devem entender as suas funções dentro do projeto e por qual
motivo estão trabalhando aos pares. 
Troca de pares: para que todos aprendam a trabalhar uns com os outros, melhorando o desempenho
de toda a equipe, o que pode ocorrer, por exemplo, no fim de cada Sprint.
Estrutura: uma boa estrutura é necessária, incluindo materiais como cadeiras ergométricas, mesas com
tamanho suficiente para comportar todos os equipamentos necessários e um monitor de boa qualidade
com bom tamanho de tela. 
REVISÃO DE CÓDIGO
é uma das práticas mais importantes para
garantir a saúde a médio e longo prazo da
base de código de um sistema. Ela é hoje
adotada por várias empresas que
desenvolvem software.
A ideia de revisão de código é simples: todo
código desenvolvido por um desenvolvedor
tem que ser, em seguida, analisado por pelo
menos um outro desenvolvedor, chamado
de revisor. O revisor pode adicionar
comentários no código sob revisão,
procurando esclarecer dúvidas, sugerindo
melhorias, indicando bugs, etc.
Assim, estabelece-se um diálogo – na forma
de uma troca de comentários — entre o
autor do código e o seu revisor.
Assim, estabelece-se um diálogo – na
forma de uma troca de comentários — entre
o autor do código e o seu revisor.
Prioridade de Revisão
Bugs em geral
Código mais complexo do que o necessário
Código que usa um algoritmo e/ou
estrutura de dados menos eficiente
Código que viola princípios de projeto (veja
mais no Capítulo 5)
Código que viola a arquitetura de camadas
do sistema (veja mais no Capítulo 7)
Código que não trata exceções e erros
Código com code smells (veja mais no
Capítulo 9)
Otimizações prematuras
Ausência de testes
Ausência de documentação, principalmente aquela mais
relevante
Falhas de segurança ou privacidade
Problemas de desempenho
Problemas de usabilidade com o usuário
Uso inadequado ou sub-ótimo de APIs
Uso de bibliotecas ou frameworks não autorizados
Problemas relacionados com alocação de memória dinâmica
Problemas relacionados com programação concorrente
Código com problemas de leiaute ou indentação
Código que viola convenções de nome
Recomendações
O objetivo da revisão é detectar problemas inequívocos no código submetido. A revisão não é para propor
alternativas que não tenham vantagens claras e inequívocas. Ou seja, um revisor somente deve propor uma
alternativa se ela for, de fato, bem melhor!
1.
Evite comentários subjetivos e relacionados a estilos pessoais.2.
Nunca use palavras ofensivas, sarcásticas ou mesmo irônicas. Seja sempre educado e profissional.3.
Sempre restrinja seus comentários ao código que foi submetido.4.
Procure fazer perguntas e não julgamentos.5.
Se você tiver feito um comentário errado ou sem sentido, reconheça o seu erro e agradeça6.
Sempre que for esclarecedor, referencie a documentação interna ou externaao projeto.7.
Procure justificar os seus comentários8.
“Um trecho de código para revisão deve ter no máximo 200 linhas de código.
DÍVIDA TÉCNICA
Descreve a dívida que a equipe de desenvolvimento assume quando escolhe um design ou abordagem fácil de
implementar no curto prazo mas com grande impacto negativo no longo prazo.
É inevitável possuir dívidas técnicas em um projeto. 
Martin Fowler, também cita também os exemplos de classificação da dívida técnica, como um cruzamento de 2
conceitos básicos, de Prudencia, quando o time de desenvolvimento entende o conceito de dívida técnica e
como utilizá-lo e o conceito de Consciência, quando o time de desenvolvimento sabe que está gerando dívidas
técnicas.
 
O time não tem tempo para o design e utiliza
uma solução rápida e com pouca preocupação
com a qualidade;
 O time precisa entregar o produto agora com todas as
limitações conhecidas e assume de maneira pró-ativa as
consequências para futuras correções.
Isso é verdade para times com excelentes arquitetos.
Eles fornecem uma solução que agrega valor ao negócio,
mas depois de completar a solução, eles entendem que
a abordagem de design poderia ter sido melhor.
O time não tem consciência dos princípios
básicos de design e então nem sequer imagina
a bagunça que estão adicionando;
Suponha uma unidade de medida para o valor (funcionalidades novas, melhorias de performance entre outros) do software
que estamos entregando, algo hipotético. Essa medida vamos chamar de “F”.
Assim com essa medida, vamos pensar em um time que é capaz de entregar 100 F por semana. Porém “excepcionalmente”
essa semana existe uma funcionalidade muito importante que deve ser entregue, a qual necessita que sejam entregues 150 F.
O que fazer? O time pega um empréstimo, utilizando POG (gambiarra), para que o time consiga entregar os 50 Fs a mais
necessários nessa semana atípica. 
Nas semanas seguintes o time continua com a meta de entregar os 100 F por semana. Porém um empréstimo foi contraído, e
está começando a cobrar os juros. Então o time não consegue desenvolver com o mesmo desempenho, pois a gambiarra feita
na semana excepcional está com problemas no design, bugs e outras coisas que fazem com que a atenção do time também
esteja focada nessa funcionalidade muito importante. Suponha que isso custe 20% dos F entregues nessas semanas,
entregando apenas 80 F de funcionalidades novas.
Se esse pagamento de juros continuar por 3 semanas custando 20% por semana, por exemplo, a sua dívida técnica terá
custado 60 Fs e você emprestou somente 50 Fs para utilizar a mais naquela semana excepcional. Com esse simples ponto já
estamos percebendo que não está valendo a pena ter se endividado no começo.
Percebeu que se em algum momento você não quitar a sua dívida técnica a sua geração de valor em software fica
comprometida? E a situação é muito pior quando mesmo já tendo uma dívida técnica resolvemos contrair mais um
empréstimo. Assim a dívida aumenta, e chega num determinado momento em que simplesmente não entregamos mais valor,
mas somente ficamos pagando juros em uma gigantesca bola de neve
SEMANA 7
Conhecer os principais conceitos relacionados à arquitetura de
software e padrões arquiteturais;
Conhecer a geração automática de documentação via o uso de
ferramenta;
Conhecer os principais conceitos relacionados à comunicação com o
usuário.
Curva do Pânico
Uma pressão pelo aumento da
produtividade inicia-se quando o time
percebe que precisa adiar a entrega por
algum desses motivos:
Erros na estimativa
Pressão por um prazo menor
Falta de habilidade/conhecimento do
time
Juros da dívida técnica acumulado
Entre outros motivos
Adicionais mais pessoas não adianta: A
Lei de Brooks é um conceito criado por
Fred Brooks em 1975 em seu livro "O
mítico homem-mês". Segundo Brooks,
adicionar mais indivíduos a um projeto
que já está atrasado não irá torná-lo
pronto mais rápido, mas pelo contrário,
irá atrasá-lo ainda mais
 Trabalhar mais horas por dia pode funcionar, aumentando de forma efetiva a produtividade. Mas esta não é uma
situação sustentável, desgasta a equipe que acaba sacrificando ainda mais a qualidade e gerando mais dívida
técnica.
Optar conscientemente por menos controle de qualidade pode funcionar a curto prazo, mas ao longo do tempo,
o acúmulo de juros da dívida técnica, fatalmente, implicará em novos atrasos e mais pânico.
Ao contrário disso, será que não poderíamos negociar com o cliente? Se não for uma opção mexer no
prazo, podemos negociar o escopo. Priorizar as funcionalidades mais importantes, que agreguem
valor de negócio e retirar/simplificar funcionalidades menos importantes.
Por outro lado, se precisarmos contornar a qualidade para ter um benefício imediato, contraindo
dívida técnica, temos que ter bem claro em nossas mentes (e na do cliente): será necessário pagar
essa dívida o quanto antes, de preferência já na próxima iteração.
Abrir mão da qualidade dificilmente será uma boa opção. Não dá para construir algo bom
em cima de uma base podre. Uma vez que o código está deteriorado, recuperar sua
qualidade é difícil e caro
https://blog.aevo.com.br/squads/
https://blog.aevo.com.br/squads/
https://blog.aevo.com.br/squads/
https://blog.aevo.com.br/squads/
https://blog.aevo.com.br/squads/
https://blog.aevo.com.br/squads/
https://blog.aevo.com.br/squads/
https://blog.aevo.com.br/squads/
ARQUITETURA DE SOFTWARE PADRÕES ARQUITETURAIS
Preocupa-se com projeto em mais alto nível. 
Inclui as decisões de projeto mais
importantes em um sistema.
Estilos arquiteturais propõem que os
módulos de um sistema devem ser
organizados de uma determinado modo, o
que não necessariamente ocorre visando
resolver um problema específico.
Propõem uma organização de mais alto nível para
sistemas de software, incluindo seus principais módulos
e as relações entre eles. Essas relações definem, por
exemplo, que um módulo A pode (ou não pode) usar os
serviços de um módulo B. Padrões focam em soluções
para problemas específicos de arquitetura
Arquitetura em Camadas
É um dos padrões arquiteturais mais usados, desde que os primeiros sistemas de software de maior porte
foram construídos nas décadas de 60 e 70. Em sistemas que seguem esse padrão, as classes são
organizadas em módulos de maior tamanho, chamados de camadas. As camadas são dispostas de forma
hierárquica, como em um bolo. Assim, uma camada somente pode usar serviços — isto é, chamar métodos,
instanciar objetos, estender classes, declarar parâmetros, lançar exceções, etc. — da camada imediatamente
inferior. Dentre outras aplicações, arquiteturas em camadas são muito usadas na implementação de
protocolos de rede. Uma arquitetura em camadas particiona a complexidade envolvida no desenvolvimento
de um sistema em componentes menores (as camadas). Como uma segunda vantagem, ela disciplina as
dependências entre essas camadas. 
Duas Camadas: camadas de interface e de aplicação são unidas em uma única camada, que executa no
cliente. A camada restante continua sendo o banco de dados. A desvantagem de arquiteturas em duas
camadas é que todo o processamento ocorre nos clientes, que, portanto, devem ter um maior poder de
computação.
Três Camadas: comum na construção de sistemas de informação corporativos, é composta por (i)
Interface com o Usuário, também chamada de camada de apresentação, é responsável por toda
interação com o usuário; (ii) Lógica de Negócio, também conhecida como camada de aplicação,
implementa as regras de negócio do sistema e (iii) Banco de Dados, que armazena os dados manipulados
pelo sistema. Normalmente, uma arquitetura em três camadas é uma arquitetura distribuída. Isto é, a
camada de interface executa na máquina dos clientes. A camada de negócio executa em um servidor,
muitas vezes chamado de servidor de aplicação.
https://blog.aevo.com.br/squads/
https://blog.aevo.com.br/squads/
https://blog.aevo.com.br/squads/
https://blog.aevo.com.br/squads/
https://blog.aevo.com.br/squads/
https://blog.aevo.com.br/squads/
https://blog.aevo.com.br/squads/
https://blog.aevo.com.br/squads/https://blog.aevo.com.br/squads/
https://blog.aevo.com.br/squads/
https://blog.aevo.com.br/squads/
https://blog.aevo.com.br/squads/
https://blog.aevo.com.br/squads/
MVC (Model-View-Controller): define que as classes de um sistema devem ser organizadas em três
grupos:
Visão: classes responsáveis pela apresentação da interface gráfica
do sistema, incluindo janelas, botões, menus, barras de rolagem, etc.
Controladores: classes que tratam e interpretam eventos gerados
por dispositivos de entrada, como mouse e teclado. Como resultado
de tais eventos, Controladoras podem solicitar uma alteração no
estado do Modelo ou da Visão. 
Modelo: classes que armazenam os dados manipulados pela
aplicação e que têm a ver com o domínio do sistema em construção.
Assim, classes de modelo não têm qualquer conhecimento ou
dependência para classes de Visão e Controladoras. Além de dados,
classes de modelo podem conter métodos que alteram o estado dos
objetos de domínio.
vantagens
 favorece a especialização do trabalho de desenvolvimento.
permite que classes de Modelo sejam usadas por diferentes Visões
 favorece testabilidade.
Microsserviços
Arquiteturas baseadas em microsserviços tornaram-se possíveis devido ao aparecimento de plataformas de
computação em nuvem. Certos grupos de módulos são executados em processos independentes, sem
compartilhamento de memória. Ou seja, o sistema é decomposto em módulos não apenas em tempo de
desenvolvimento, mas também em tempo de execução. Com isso, as chances de que mudanças em um
módulo causem problemas em outros módulos ficam bem menores.
Monolito Microsserviços
 (1) eles permitem a evolução mais rápida e
independente de um sistema, permitindo que
cada time tenha seu próprio regime de liberação
de novas releases; (2) eles permitem escalar um
sistema em um nível de granularidade mais fino
do que é possível com monolitos; (3) como os
microsserviços são autônomos e independentes
eles podem ser implementados em tecnologias
diferentes, incluindo linguagens de programação,
frameworks e bancos de dados e (4) podemos ter
falhas parciais. 
vantagens
Desvantagens
Complexidade
Latência
Transações Distribuídas
Arquiteturas Orientadas a Mensagens
este tipo de arquitetura, a comunicação entre clientes e servidores é mediada por um terceiro serviço que
tem a única função de prover uma fila de mensagens 
https://blog.aevo.com.br/squads/
https://blog.aevo.com.br/squads/
https://blog.aevo.com.br/squads/
https://blog.aevo.com.br/squads/
https://blog.aevo.com.br/squads/
https://blog.aevo.com.br/squads/
https://blog.aevo.com.br/squads/
https://blog.aevo.com.br/squads/
https://blog.aevo.com.br/squads/
https://blog.aevo.com.br/squads/
https://blog.aevo.com.br/squads/
https://blog.aevo.com.br/squads/
https://blog.aevo.com.br/squads/
Os clientes atuam como produtores de informações, isto é, eles inserem mensagens na fila. E os servidores
atuam como consumidores de mensagens, isto é, eles retiram mensagens da fila e processam a informação
contida nelas. Uma mensagem é um registro (ou um objeto) com um conjunto de dados. E uma fila de
mensagens é uma estrutura do tipo FIFO (first in, first out), isto é, a primeira mensagem a entrar na fila é a
primeira a ser consumida pelo servidor.
Com o uso de filas de mensagens, a comunicação pelo lado do cliente torna-se assíncrona, pois uma vez que
a informação seja colocada na fila, o cliente está liberado para continuar seu processamento.
Além de permitirem comunicação assíncrona entre clientes e servidores, filas de mensagens viabilizam duas
formas de desacoplamento entre os componentes de uma aplicação distribuída:
Desacoplamento no espaço: clientes não precisam conhecer os servidores e vice-versa. Em outras
palavras, o cliente é exclusivamente um produtor de informações. Mas ele não precisa saber quem vai
consumir essa informação. O raciocínio inverso vale para servidores.
Desacoplamento no tempo: clientes e servidores não precisam estar simultaneamente disponíveis
para se comunicarem. Se o servidor estiver fora do ar, os clientes podem continuar produzindo
mensagens e colocando-as na fila. Quando o servidor voltar a funcionar, ele irá processar essas
mensagens.
Arquiteturas Publish/Subscribe
Em arquiteturas publish/subscribe, as mensagens são chamadas de eventos. Os componentes da
arquitetura são chamados de publicadores (publishers) e assinantes (subscribers) de eventos. Publicadores
produzem eventos e os publicam no serviço de publish/subscribe, que normalmente executa em uma
máquina separada. Assinantes devem previamente assinar eventos de seu interesse. Quando um evento é
publicado, os seus assinantes são notificados.
Assim como ocorre quando se usa filas de mensagens,
arquiteturas publish/subscribe também oferecem
desacoplamento no espaço e no tempo. No entanto,
existem duas diferenças principais entre publish/subscribe e
sistemas baseados em filas de mensagens:
Em publish/subscribe, um evento gera notificações em todos os seus assinantes. Por outro lado, em filas de
mensagens, as mensagens são sempre consumidas — isto é, retiradas da fila — por um único servidor.
Portanto, em publish/subscribe temos um estilo de comunicação de 1 para n, também conhecido como
comunicação em grupo. Já em filas de mensagens, a comunicação é 1 para 1, também chamada de
comunicação ponto-a-ponto.
Em publish/subscribe, os assinantes são notificados assincronamente. Primeiro, eles assinam certos eventos
e, então, continuam seu processamento. Quando o evento de interesse ocorre, eles são notificados por meio
da execução de um determinado método. Por outro lado, quando se usa uma fila de mensagens, os
servidores — isto é, os consumidores das mensagens — têm que puxar (pull) as mensagens da fila.
Em alguns sistemas publish/subscribe, eventos são organizados em tópicos, que funcionam como categorias
de eventos. Quando um publicador produz um evento, ele deve informar seu tópico. Assim, clientes não
precisam assinar todos os eventos que ocorrem no sistema, mas apenas eventos de um determinado tópico.
Arquiteturas publish/subscribe são, às vezes, chamadas de arquiteturas orientadas a eventos.
JAVADOC
A ferramenta JavaDoc é uma ferramenta geradora de documentos na linguagem de programação Java para
gerar documentação padrão em formato HTML. Ele gera documentação de API . Ele analisa a documentação do
anúncio de declarações em um conjunto de arquivos de origem que descreve classes, métodos, construtores e
campos.
DESIGN CENTRADO NO USUÁRIO
Formato JavaDoc: - 
Tem duas partes: - uma descrição que é seguida por tags de bloco.
Alguns ambientes de desenvolvimento integrado (IDE) geram automaticamente o arquivo JavaDoc como NetBeans,
IntelliJ IDEA, Eclipse, etc.
Geração de JavaDoc: - 
Para criar um JavaDoc não é necessário compilar o arquivo java. Para criar a API de documentação Java, você
precisa escrever Javadoc seguido pelo nome do arquivo. 
javadoc file_name or javadoc package_name
Após a execução bem-sucedida do comando acima, vários arquivos HTML serão criados, abra o arquivo
denominado index para ver todas as informações sobre as classes.
Na maioria dos modelos de desenvolvimento, pouco se fala sobre a maneira de se conversar com o cliente, ou
quais passos devem ser dados para facilitar a comunicação, com o objetivo de obter informações sobre os
usuários e suas necessidades. Isso acontece porque a Engenharia de Software, onde se originaram esses
modelos, foca no software e não as pessoas que irão utilizá-lo. A ênfase está nos requisitos do sistema e
não nas características dos usuários.
A IHC tem como principal característica preocupar-se com os usuários, observando suas
características físicas e cognitivas para utilizá-las na criação do sistema.
A principal característica da área de Design Centrado no Usuário (User Centered Design ou UCD) é
colocar as necessidades do usuário como um todo no centro das decisões. Não importa se são
necessidades de requisitos ou necessidades cognitivas, é preciso pensar no usuário final em todo o processo
de desenvolvimento.“os usuários não são projetistas, e
projetistas não são usuários”.
Usuários Experientes Fornecem
Informações Genéricas: 
Outro fator importante a se considerar
são as situações onde o usuário está
envolvido com suas atividades há muito
tempo. Por possuir uma prática imensa,
realiza as tarefas de maneira
“automática”, sem a necessidade de
pensar muito. Estes usuários costumam
não levar muito em consideração todas
as atividades que realizam, e na hora de
passar as informações, acabam usando
frases muito genéricas.
Outro erro é perguntar diretamente aos
usuários “o que eles querem”, pois embora
eles saibam que a tecnologia pode ajudar a
amenizar ou resolver seus problemas, eles
não são projetistas.
A UCD precisa entender mais profundamente a
regra do negócio, ou seja:
Como é feito o controle de estoque?
Quais são as atividades mais importantes?
Quais são as atividades menos importantes?
Quais são as dificuldades?
Qual processo é mais simples?
Qual processo é mais complexo?
O UCD se preocupa em promover a colaboração entre o projetista e o usuário (que pode ser o próprio cliente ou
um funcionário que usará o sistema). Tanto o projetista como o usuário possuem conhecimentos que devem ser
compartilhados.
o UCD abrange várias áreas, dentre elas:
IHC: com sua preocupação em entender as características físicas e psicocognitivas dos usuários, os fatores
humanos etc;
Engenharia de Usabilidade: que se preocupa em entender os objetivos dos usuários, desenvolver interfaces
para eles etc.
Assim como nos Modelos de Processos de Software, o UCD também possui algumas etapas para auxiliar o projetista
nesse contato com o usuário, permitindo um melhor entrosamento, compreensão e colaboração.
PESQUISA DE DESIGN DESENHO AVALIAÇÃO DE DESENHO
Planejamento: 
Identifica-se o objetivo, as restrições e as suposições do projeto.
Identificam--se os Stakeholders. 
Condução
Este passo objetiva conduzir a investigação na empresa, onde um projetista irá
conhecer as atividades das pessoas e como elas realizam suas tarefas.
Recomenda-se o Background Research. 
Análise
Projetista deverá organizar todas as informações, decidir quais são as
prioridades, o que deve ser feito, o que precisa ser mudado, suas propostas,
enfim, todas as informações necessárias para, depois, conversar com as
pessoas.
Reporte
PESQUISA DE DESIGN
Entrevista face a face;
Perguntas abertas e fechadas;
Entrevistas remotas/presenciais
DESENHO
Ocorre a consolidação de todas as informações obtidas até esse momento.
Pode ser realizada por meio dos primeiros desenhos da interface. Esses
desenhos são feitos de acordo com as informações obtidas e pelas conversas
feitas durante esta etapa.
Prototipagem
AVALIAÇÃO
Terceira e última etapa do UCD, essa etapa avalia tudo o que foi investigado,
desenvolvido e representado por meio do Desenho. A avaliação pode ser feita
com auxílio do usuário, certificando que tudo o que foi planejado e realizado
está de acordo com as necessidades e as características do usuário. 
Heurística;
Questionário de satisfação;
Percurso cognitivo;
Revisão pelos usuários;
https://medium.com/codigo-facil/os-processos-de-software-56a2e70fddfb