IN0953

ENGENHARIA
DE SOFTWARE
VINICIUS CARDOSO GARCIA

LICENA DO MATERIAL
Este Trabalho foi licenciado com uma Licena
Creative Commons - Atribuio-NoComercialCompartilhaIgual 3.0 No Adaptada.
Mais informaes visite

http://creativecommons.org/licenses/by-ncsa/3.0/deed.pt

DOWNLOAD

http://bit.ly/in0953-2015-w01a01

REFERNCIAS
A biblioteca do Desenvolvedor
de Software dos dias de hoje
http://bit.ly/TDOA5L

SWEBOK
Guide to the Software Engineering
Body of Knowledge (SWEBOK):
http://www.computer.org/web/
swebok

Engineering Software as a
Service: An Agile Approach
Using Cloud Computing (Beta
Edition)

http://beta.saasbook.info/

ORGANIZAO
Introduo a Engenharia de Software
Software como Servio
Arquitetura Orientada a Servio
Computao em Nuvem
Cdigo Bonito vs Cdigo Legado
Garantia de Qualidade de Software: Testes

Produtividade: Clareza via Conciso, Sntese, Reuso,

& Ferramentas

OBJETIVOS

Discutiros [Princpios] da Engenharia de Software

compreendendo os novos desafios, oportunidades e
problemas AINDA em aberto
SaaS/SOA, Computao em Nuvem, Cdigo Legado,
Testes, Produtividade...
Desenvolver um sistema de informao [SaaS] da sua
concepo implantao
Investigar como solucionar problemas no-tcnicos dos
clientes
Novas abordagens: Agile Frameworks, BDD, TDD
E do lado do cliente: HTML, CSS, AJAX, JavaScript
Implantao por meio da Computao em Nuvem

COMUNICAO
Site da disciplina [material e informaes]:
WDHY
Para facilitar a comunicao via email que no
acontecer pela lista, utilizem [in0953] como parte do
assunto do email.
Comunidade da in0953no Facebook:

IF0953.2014
https://www.facebook.com/groups/237528629769662/

AVALIAO
A avaliao neste curso se dar da seguinte forma:
os aspectos tericos sero avaliados por meio de dois exerccios escolares;
a prtica ser avaliada por meio de projeto de software desenvolvido em
equipe.
A mdia da disciplina ser calculada da seguinte forma:
Mdia = ( 3 * NotaEE1 + 3 * NotaEE2 + 4 * NotaProjeto) / 10, onde
NotaEE1 a nota do Primeiro Exerccio Escolar;
NotaEE2 a nota do Segundo Exerccio Escolar;
A nota do projeto (NotaProjeto) ser calculada assim:

NotaProjeto = (NotaEntrega1 + NotaEntrega2 + NotaEntrega3 +

NotaEntrega4) / 4 , onde
NotaEntregaX (X = 1 .. 4) corresponde nota referente entrega de partes do
projeto, sendo quatro ao todo.

SE PREPARANDO PARA O CURSO

AMBIENTE E FERRAMENTAS
Para reduzir os obstculos de instalar e configurar o mesmo ambiente
de desenvolvimento em diferentes computadores com diferentes
sistemas operacionais, recomendado o uso de uma mquina virtual
que contm todo software necessrios para o desenvolvimento do
projeto

Oracle VirtualBox: https://www.virtualbox.org

Cloud9: https://c9.io
Nitrous: https://www.nitrous.io
Vagrant: https://www.vagrantup.com

Tambm recomendado, para quem no familiarizado com

Programao, que percorra trilhas do Code Academy:

10

i.e.: http://www.codecademy.com/tracks/ruby (ou similar).

CONTROLE DE VERSO
Controle de verso e ferramentas de controle de verso (e.g., git) so
essenciais na ES
A VISUAL GUIDE TO VERSION CONTROL
http://betterexplained.com/articles/a-visual-guide-to-version-control/

BASH SHELL COMMANDS REVIEW

http://bit.ly/1ltGFyD and follow along in the command terminal in your VM.

GIT IMMERSION TUTORIAL

11

Sees 1-35 do GitImmersion tutorial (http://gitimmersion.com/

lab_01.html) na sua VM.

12

INTRODUO A ENGENHARIA DE
SOFTWARE

1. Software Engineer

104. Airline Pilot

28. Civil Engineer

133. Fashion Designer

38. Nurse

137. High School Teacher

40. Physician

163. Police Officer

47. Accountant

173. Flight Attendant

60. Mechanical Engineer

185. Firefighter

73. Electrical Engineer

196. Newspaper Reporter

87. Attorney

200. Lumberjack

InformationWeek 5/15/12. Based on salary, stress levels, hiring outlook, physical

demands, and work environment (www.careercast.com)

13

RANKING TOP 200 JOBS ('12)

ENGENHARIA DE SOFTWARE
As economias de TODAS as naes desenvolvidas
so dependentes de software.
Cada vez mais sistemas so controlados por
software.
A engenharia de software se dedica s teorias,
mtodos e ferramentas para desenvolvimento de
software profissional

14

Sistemas no-triviais
Com base em um conjunto de requisitos

SE [ES] TO POPULAR, POR

QUE TANTOS DESASTRES?
[Procure na Wikipedia para mais detalhes]
Mariner I (O hfen mais caro da histria)
1962: menos de cinco minutos depois do incio de voo, o Mariner I explodiu,
dando um prejuzo de US$80 milhes (http://gizmodo.uol.com.br/hifen-nasa/)
Therac-25: sobredosagem de radiao letal
1985: Reutilizao de SW de uma mquina com HW de bloqueio em uma
mquina sem: SW bug => 3 morreram
Desintegrao da Mars Climate Orbiter
1999: os engenheiros espaciais se esqueceram de converter as medidas do
sistema imperial para unidades mtricas (pound-seconds vs. newton-seconds)
=> desperdiou $325M
Projeto FBI Virtual Case File abandonado

1996 => desperdiou $370M

15

2005: abandonado aps 5 anos de trabalho => desperdcio de $170M

Exploso do foguete Ariane 5

COMO EVITAR O DESCRDITO?

Quais so as lies de 60 anos de
Desenvolvimento de Software?
Vamos revisar algumas abordagens
ressaltando pontos fortes e fracos

16

Experincia prtica com uma boa abordagem

para Software como Servio

17

SOFTWARE COMO SERVIO

ALVOS DO SOFTWARE
SW Tradicional: cdigo binrio instalado e rodando
totalmente no dispositivo do cliente
Os usurios precisam atualizar repetidamente
Muitas verses de hardware e muitas verses de SO
Novas verses precisam passar por um ciclo de
release extensivo para garantir a compatibilidade
Uma alternativa onde o desenvolva-se o SW que
necessita rodar em apenas uma plataforma de
HW&SO?

18

Ciclo de releases rpido, sem atualizaes dos

usurios?

SOFTWARE COMO SERVIO:

SAAS
SaaS entrega SW & dados como servio atravs da
rede via clintes magros (e.g., browser) rodando no
cliente
Busca, redes sociais, streaming de vdeo
Verses SaaS de SW tradicionais

19

Microsoft Office 365, Salesforce

SaaS um caminho [revolucionrio] sem volta!

1.

Sem preocupaes com o HW sobre instalao ou SO

2.

Sem preocupaes sobre perda de dados (no site remoto)

3.

Fcil interao para grupos (mesmos dados)

4.

Se o volume de dados grande ou muda frequentemente,

basta manter uma cpia no stite central

5.

Uma cpia do SW, ambiente de HW controlado => sem

aborrecimentos com compatibilidade [desenvolvedores]

6.

Uma cpia 1 => simplifica atualizaes para

desenvolvedores e sem CRs de atualizao dos usurios

20

6 RAZES PARA SAAS

SAAS S2 METODOLOGIAS
GEIS & RAILS
Atualizaes frequentes => Ciclo de Vida gil
Muitos frameworks para gil/SaaS
Djando/Python, Zend/PHP, Spring/Java
Vamos utilizar Ruby on Rails (Rails)
Rails um framework muito popular que utiliza
Ruby (e.g., Twitter, Cloudfoundry, OpenNebula)

21

Ruby, uma linguagem de script moderna: OO,

funcional, gerenciamento automtico de
memria, tipos dinmicos, reuso via mix-ins,
sntese via metaprogramao

POR QUE GASTAR TEMPO COM

RAILS?
15 semanas para aprender:
SaaS, Agile, Pair Programming, Behavior Driven
Design, LoFi UI, Storyboards, User Stories, Test
Driven Development, Enhance Legacy Code, Scrum,
Velocity, JavaScript, Design Patterns, UML,
Deployment, Security
A nica esperana contar com um ambiente
altamente produtivo (linguagens, ferramentas,
frameworks...): Acredito que Rails a melhor escolha
Sugesto: Crossing the Software Education Chasm,
A. Fox, D. Patterson, Comm. ACM, May 2012

22

http://bit.ly/1b9QbFj

PERGUNTA
Qual o argumento mais FRACO para a
popularidade das apps como SaaS do
Google ?
No perca dados: Gmail
Grupos cooperativos: Documentos
Grandes conjuntos de dados: Youtube
Sem atualizaes intrusivas ao melhorar o
app: Busca
23

1.
2.
3.
4.

PERGUNTA
Qual o argumento mais FRACO para a
popularidade das apps como SaaS do
Google ?
No perca dados: Gmail
Grupos cooperativos: Documentos
Grandes conjuntos de dados: Youtube
Sem atualizaes intrusivas ao melhorar o
app: Busca
24

1.
2.
3.
4.

25

ARQUITETURA ORIENTADA A SERVIO

(SOA)

ARQUITETURA DE SOFTWARE

26

Voc pode/consegue projetar um software de

forma que seja possvel recombinar mdulos
independentes para ofertar diferentes apps
sem muito esforo de programao?

ARQUITETURA ORIENTADA A
SERVIO
SOA: Arquitetura de Software onde todos os
componentes so projetados como servio
Apps so compostas por servios interoperveis

27

Fcil de derivar uma nova verso para um

conjunto de usurios
Tambm fcil para se recuperar de um erro de
projeto
Contraste para SW silo sem uma API interna

CEO: AMAZON SHALL USE SOA!

1. All teams will henceforth expose their data
and functionality through service interfaces.
2. Teams must communicate with each other
through these interfaces.

28

3. There will be no other form of interprocess

communication allowed: no direct linking, no
direct reads of another team's data store, no
shared-memory model, no back-doors
whatsoever. The only communication allowed
is via service interface calls over the network.

CEO: AMAZON SHALL USE SOA!

4. It doesn't matter what [API protocol]
technology you use.
5. Service interfaces, without exception, must
be designed from the ground up to be
externalizable. That is to say, the team must
plan and design to be able to expose the
interface to developers in the outside world.
No exceptions.
6. Anyone who doesn't do this will be fired.

29

7. Thank you; have a nice day!

BOOKSTORE: SILO

User profile Service

Todos os
subsistemas
dentro de uma
nica API
(Bookstore)
(Figure 1.3, Engineering Long Lasting
Software by Armando Fox and David
Patterson, Beta edition, 2012.)

reviews

users

orders

Review
Subsystem

User Profile
Service

Buying
Subsystem

Bookstore Service

30

Subsistemas
internos podem
compartilhar
dados diretamente

BOOKSTORE: SOA
Subsistemas
independentes,
como se
estivessem em
datacenters
separados

user
reviews

credit card
processing

editor
reviews

User Profile
Service

Review
Service

User Service API

(Figure 1.4, Engineering Long Lasting

Software by Armando Fox and David
Patterson, Beta edition, 2012.)

orders

Buying
Service

Bookstore Service

Favorite Books
Service
users

Social
Network
Service

31

Pode recombinar
servios para
criar novos
servios
(Favorite
Books)

users

PERGUNTA
Quais afirmaes NO so verdades sobre SOA?

32

1. SOA no afeta desempenho

2. Sistemas silo provavelmente ficam fora do ar
com uma falha, SOA deve saber lidar com
falhas parciais
3. SOA melhora a produtividade dos
desenvolvedores por meio do reuso
4. Nenhum servio pode acessar os dados de
outro servio; pode apenas fazer requisies
para estes dados atravs de uma API

PERGUNTA
Quais afirmaes NO so verdades sobre SOA?

33

1. SOA no afeta desempenho

2. Sistemas silo provavelmente ficam fora do ar
com uma falha, SOA deve saber lidar com
falhas parciais
3. SOA melhora a produtividade dos
desenvolvedores por meio do reuso
4. Nenhum servio pode acessar os dados de
outro servio; pode apenas fazer requisies
para estes dados atravs de uma API

34

COMPUTAO EM NUVEM

QUAL O HW IDEAL PARA SAAS?

Amazon, Google, Microsoft... Desenvolveram
sistemas de HW para rodar SaaS
O Que eles usam, em termos de infraestrutura de
HW: Mainframes? Supercomputers?

35

Como desenvolvedores de SW independentes

constroem apps SaaS e competem sem um
investimento em HW similar a Amazon, Google,
Microsoft?

INFRAESTRUTURA SAAS?
3 Demandas de infraestrutura para SaaS

36

1. Comunicao: permitir que os

consumidores interajam com o servio
2. Escalabilidade: flutuaes na demanda
durante adio de novos servios para
novos clientes rapidamente
3. Confiabilidade: disponibilidade contnua de
servio e comunicao 24x7

SERVIOS EM CLUSTERS
Cluster: aglomerado de computadores
conectados
1. Mais escalvel do que servidores
convencionais
2. Mais barato do que servidores convencionais
20X para equivalentes vs. Servidores maiores

3. Poucos operadores para 1000s servidores

Seleo cuidadosa de HW e SW idnticos
Monitores de Mquinas Virtuais simplifica a operao

37

4. Confiabilidade via redundncia extensiva

WAREHOUSE DE
COMPUTADORES ESCALVEIS
Clusters cresceu de 1000 para 100 mil servidores
com base na demanda do cliente para aplicativos
SaaS
Economias de escala empurraram o custo dos
grandes data centers em fatores de 3x a 8x
Comprar, hospedar, operar 100K vs 1K
Data centers tradicionais utilizados, cerca de
10% - 20%

38

Modelos de negcio baseados em pay-as-you-go

trazem benefcios concretos

COMPUTAO UTILITRIA /
COMPUTAO EM NUVEM PBLICA
Oferece computao, armazenamento,
comunicao a centavos por hora
Sem adicionais por escalabilidade
1000 computadores @ 1 hora, ou
1 computador @ 1000 horas
Iluso de infinita escalabilidade para o usurio

39

Tantos computadores quanto voc puder dispor

Exemplos: Amazon Web Services, Google App
Engine, Microsoft Azure

2013 AWS INSTANCES &

PRICES
m1.small
m1.medium
m1.large
m1.xlarge
m3.xlarge
m3.2xlarge
c1.medium
c1.xlarge
cc2.8xlarge
m2.xlarge
m2.2xlarge
m2.4xlarge
cr1.8xlarge
hi1.4xlarge
hs1.8xlarge
t1.micro
cg1.4xlarge

$0.06
$0.12
$0.24
$0.48
$0.50
$1.00
$0.15
$0.58
$2.40
$0.41
$0.82
$1.64
$3.50
$3.10
$4.60
$0.02
$2.10

1.0
2.0
4.0
8.0
8.3
16.7
2.5
9.7
40.0
6.8
13.7
27.3
58.3
51.7
76.7
0.3
35.0

Virtual
Cores

1
1
2
4
4
8
2
8
32
2
4
8
32
16
16
1
16

Compute
Units

1.0
2.0
4.0
8.0
13.0
26.0
5.0
20.0
88.0
6.5
13.0
26.0
88.0
35.0
35.0
varies
33.5

Memory
(GiB)

Storage (GB)

1.7
1 x 160
3.8
1 x 410
7.5
2 x 420
15.0
4 x 420
15.0
EBS
30.0
EBS
1.7
1 x 350
7.0
4 x 420
60.5
4 x 840
17.1
1 x 420
34.2
1 x 850
68.4
2 x 840
244.0 2 x 120 SSD
60.5 2 x 1024 SSD
117.0
24 x 2048
0.6
EBS
22.5
2 x 840

40

Per $ Ratio
Instance Type Hour to small

SUPERCOMPUTADOR PARA
ALUGAR

41

Competio dos Top 500 supercomputadores

532 Eight Extra Large (@ $2.40/hour), 17000
cores = 240 TeraFLOPS
72nd/500 supercomputer @ ~$1300 per hour
Carto de crdito => at 1000s computadores
FarmVille no AWS
Primeiro grande jogo online: 5M usurios
E se a startup tivesse que construir o data
center?
4 dias = 1M; 2 meses = 10 M; 9 meses = 75M

IBM WATSON PARA ALUGAR?

Campeo do Jeopardy
Hardware: 90 IBM Power 750 servers
3.5 GHz 8 cores/server
90 @~$2.40/hour = ~$200/hour
Custo de um advogado ou contador...
Para quais tarefas uma mquina com IA seria to
boa quanto uma pessoa muito bem treinada @
$200/hora?

42

O que isso pode significar para a sociedade?

PERGUNTA

43

Quais afirmaes NO so verdade sobre SaaS,

SOA e Computao em Nuvem?
1. Clusters so colees de servidores comuns
conectados por switches em uma LAN
2. A Internet prov a comunicao para SaaS
3. Computao em Nuvem utiliza clusters de HW
+ camadas de SW utilizando redundncia para
confiabilidade
4. Data centers privados podem custar o mesmo
que um Warehouse de Computadores
Escalveis se eles apenas se comprarem o
mesmo tipo de HW

PERGUNTA

44

Quais afirmaes NO so verdade sobre SaaS,

SOA e Computao em Nuvem?
1. Clusters so colees de servidores comuns
conectados por switches em uma LAN
2. A Internet prov a comunicao para SaaS
3. Computao em Nuvem utiliza clusters de HW
+ camadas de SW utilizando redundncia para
confiabilidade
4. Data centers privados podem custar o mesmo
que um Warehouse de Computadores
Escalveis se eles apenas se comprarem o
mesmo tipo de HW

45

SW LEGADO VS SW BONITO

ESTTICA DE PROGRAMAO
Eu me importo com o que os outros pensam
do meu cdigo?

46

Se funcionar, no importa com o que o cdigo

se parece?

SW LEGADO VS SW BONITO
Cdigo legado: SW antigo que continua em
uso (atende aos requisitos dos clientes) mas
de difcil evoluo [problemas de projeto ou
tecnologia ultrapassada]

47

__% de custo adicional de manuteno para

novas funcionalidades em SW legado
__% de custo adicional para correo de bugs
Cdigo bonito: atende as necessidades dos
clientes e fcil de evoluir

SW LEGADO VS SW BONITO
Cdigo legado: SW antigo que continua em
uso (atende aos requisitos dos clientes) mas
de difcil evoluo [problemas de projeto ou
tecnologia ultrapassada]

48

60% de custo adicional de manuteno para

novas funcionalidades em SW legado
17% de custo adicional para correo de bugs
Cdigo bonito: atende as necessidades dos
clientes e fcil de evoluir

CDIGO LEGADO: VITAL

PORM IGNORADO

49

No existe nos cursos tradicionais e nos livros

de ES
Principal resposta a uma pesquisa feita com
experts da indstria sobre o que eles acham que
deveria ser visto em um novo curso de ES
Salve trabalho pela reutilizao de cdigo
existente (e.g., open source)
Iremos falar mais sobre SW legados e padres de
programao mais tarde, no curso
Iro ajudar a entender como construir um cdigo
bonito

PERGUNTA
Que tipo de SW considerado uma falha
pica?
Cdigo bonito
Cdigo legado
Cdigo inesperadamente com vida curta
Tanto alternativas 2 e 3

50

1.
2.
3.
4.

PERGUNTA
Que tipo de SW considerado uma falha
pica?
Cdigo bonito
Cdigo legado
Cdigo inesperadamente com vida curta
Tanto alternativas 2 e 3

51

1.
2.
3.
4.

52

GARANTIA DE QUALIDADE E TESTES

QUALIDADE DE SOFTWARE
O Que qualidade de SW e como garantimos
ela? (QA)

53

V&V: Qual a diferente (se existe) entre

Verificao e Validao?

QUALIDADE DE SOFTWARE
Qualidade do produto: adequao ao uso
Valor de negcio para o cliente e o produtor
Garantia de Qualidade: processos/padres =>
produtos com alta qualidade & melhoria da qualidade
Quality Assurance

Qualidade de SW

54

1. Satisfaz necessidades do cliente: fcil de usar,

obtm respostas corretas, no falha, ...
2. Fcil para o desenvolvedor debugar e evoluir
SW QA: garante a qualidade e melhora os processos
organizao

GARANTIA [ASSURANCE]
Verificao: construmos a coisa certa?
Est de acordo com a especificao?
Ex: inspeo de cdigo, anlise esttica

Validao: construmos certa a coisa?

o que o cliente quer? A especificao est correta?
Exs: testes, animao de especificaes

Geralmente HW foca em verificao

Geralmente SW foca em validao
55

Testes -> SW Quality Assurance

TESTES
invivel termos testes exaustivos
[$$$]
Divide et Conquer: realizar
diferentes testes em diferentes
fases do desenvolvimento

56

Um nvel superior no refaz os testes do

inferior

TESTES
Testes de___________: programa [integrado]
atende suas especificaes
Teste de ____________: as interfaces entre as
unidades possuem pressupostos
consistentes, comunicam-se corretamente
Teste de ____________: atravs das unidades
individuais

57

Teste de ____________: o mtodo faz o que

era esperado fazer

TESTES
Testes de sistema ou aceitao: programa
[integrado] atende suas especificaes
Teste de integrao: as interfaces entre as
unidades possuem pressupostos
consistentes, comunicam-se corretamente
Teste de mdulo ou funcional: atravs das
unidades individuais

58

Teste de unidade ou unitrio: o mtodo faz o

que era esperado fazer

MAIS TESTES
Cobertura: % de cdigo coberto pelos testes
Testes de Regresso: automaticamente
reexecuta testes passados para atestar que
modificaes no quebram o que estava ok
Teste de Integrao Contnua: testes de
regresso contnua vs. Fases finais
gil -> Test Driven Design (TDD)

59

Escreva os testes ANTES de escrever o cdigo

que voc espera (testes guiam a codificao)

LIMITES DOS TESTES

Teste de programas podem ser utilizados
para mostrar a __________ de bugs, mas
nunca para mostrar sua _________!
Edsger W. Dijkstra

(Photo by Hamilton Richards. Used

by permission under CC-BY-SA-3.0.)

60

(recebeu em 1972 o Prmio Turing por

sua contribuio fundamental para o
desenvolvimento das Linguagens de
Programao)

LIMITES DOS TESTES

Teste de programas podem ser utilizados
para mostrar a presena de bugs, mas nunca
para mostrar sua ausncia!
Edsger W. Dijkstra

(Photo by Hamilton Richards. Used

by permission under CC-BY-SA-3.0.)

61

(recebeu em 1972 o Prmio Turing por

sua contribuio fundamental para o
desenvolvimento das Linguagens de
Programao)

PERGUNTA

62

Qual afirmao NO verdade sobre testes?

1. Com melhor cobertura de testes, voc te mais
chances de capturar falhas
2. Embora difcil de alcanar, testes com
cobertura de 100% garantem a confiabilidade
do projeto
3. Cada teste de um nvel superior delega mais
testes detalhados para os nveis inferiores
4. Testes unitrios funcionam com uma nica
classe e teste de mdulo funciona atravs das
classes

PERGUNTA

63

Qual afirmao NO verdade sobre testes?

1. Com melhor cobertura de testes, voc te mais
chances de capturar falhas
2. Embora difcil de alcanar, testes com
cobertura de 100% garantem a confiabilidade
do projeto
3. Cada teste de um nvel superior delega mais
testes detalhados para os nveis inferiores
4. Testes unitrios funcionam com uma nica
classe e teste de mdulo funciona atravs das
classes

64

PRODUTIVIDADE: CONCISO, SNTESE,

REUTILIZAO E FERRAMENTAS

PRODUTIVIDADE

65

Lei de Moore: 2X recursos/1.5 ano

Projetos de HW ficam maiores
Processadores mais rpidos e memrias maiores
Projetos de SW ficam maiores
Difcil de melhorara produtividade de HW e SW
4 tcnicas
1. Clareza via conciso
2. Sntese
3. Reutilizao
4. Automao e ferramentas

CLAREZA VIA CONCISO

1. Sintaxe: curta e de fcil leitura
assert_greater_than_or_equal_to(a,7)

66

vs _______________________________

CLAREZA VIA CONCISO

1. Sintaxe: curta e de fcil leitura

assert_greater_than_or_equal_to(a,7)
vs a.should be 7
2. Aumente o nvel de abstrao

67

Linguagens de Programao de Alto Nvel (HLL)

vs. Linguagens assembly
Gerenciamento automtico de memria (Java vs
C)
Linguagens de script: reflexo, metaprogramao

SNTESE
Sntese de Software
BitBit: gerao de cdigo para atender alguma
situao e remoo de testes condicionais

68

Estgio da pesquisa: Programao por

Exemplo

REUSO
Reutilizar cdigo ou escrever cdigo?
Tcnicas (cronologicamente)

69

1. Procedures e funes
2. Bibliotecas padronizadas (reuso de uma vez
s)
3. POO: reuso e gerenciamento de colees de
tarefas
4. Padres de projeto: reuso de uma estratgia
geral independente da implementao

AUTOMAO E FERRAMENTAS
Substituio de tarefas tediosas e manuais por
automao para economizar, melhorando a acurcia
Novas ferramentas podem tornar a vida melhor! (i.e.
Make, Ant)
Preocupaes com novas ferramentas:
Confiabilidade, Qualidade de UI...
Bons desenvolvedores devem aprender
repetidamente como usar novas ferramentas: curva
de aprendizado

70

Muitas chances na nossa proposta: Cucumber,

RSpec, Pivotal Tracker, Trello

PERGUNTA
Qual afirmao VERDADE sobre
produtividade?

71

1. Copiar e colar cdigo outra boa alternativa

para reutilizao
2. Metaprogramao ajuda a produtividade
atravs da sntese de programas
3. Entre as 4 razes para produtividade, a
primeira para HLL reuso
4. Em uma sintaxe concisa mais provvel ter
menos erros e ter melhor manutenibilidade

PERGUNTA
Qual afirmao VERDADE sobre
produtividade?

72

1. Copiar e colar cdigo outra boa alternativa

para reutilizao
2. Metaprogramao ajuda a produtividade
atravs da sntese de programas
3. Entre as 4 razes para produtividade, a
primeira para HLL reuso
4. Em uma sintaxe concisa mais provvel ter
menos erros e ter melhor manutenibilidade

DRY
Every piece of knowledge must have a
single, unambiguous, authoritative
representation within a system.
Andy Hunt and Dave Thomas, 1999
Don't Repeat Yourself (DRY)

73

No queira encontrar uma sria de locais

onde a mesma correo deva ser aplicada!
Refatore sempre seu cdigo!

SUMARIZANDO...

74

Neste curso veremos os Princpios da Engenharia de

Software demonstrados de forma prtica
Proposta de projeto para times de at 8 pessoas para
lidar com desenvolvimento de um app no paradigma
SaaS
Ciclo de Vida gil trabalhando em iteraes e
prottipos funcionais
Test Driven Development: unitrios a aceitao
Produtividade: Conciso, Sntese, Reuso,
Ferramentas & Automao
SaaS traz menos aborrecimentos para
desenvolvedores e usurios

IN0953
ENGENHARIA
DE SOFTWARE
VINICIUS CARDOSO GARCIA

SUMRIO
Processos de Desenvolvimento de SW: Planejar &
Documentar
Processos de Desenvolvimento de SW: Agile Manifesto
Falcias e Armadilhas
preciso uma equipe: Tamanho e Scrum
Programao em Pares
Viso Geral & Trs Pilares de Ruby
Tudo um objeto, Cada operao uma chamada de
mtodo

76

POO em Ruby

Cascata

Espiral

gil

77

PROCESSOS DE DESENVOLVIMENTO DE
SOFTWARE

COMO EVITAR O DESCRDITO

DO SW?
No podemos tornar a construo de
software to previsvel em termos de
cronograma, custo e qualidade como a
construo de uma ponte ou um edifcio?

78

Se sim, que tipo de processo de

desenvolvimento devemos utilizar para tornlo previsvel a este ponto?

ENGENHARIA DE SOFTWARE
Trazer a disciplina engenharia para o SW
Termo cunhado ~20 anos aps o 1 computador
Encontrar mtodos de desenvolvimento de SW to
previsveis em qualidade, custo e tempo assim como
engenharia civil

79

Plan-and-Document (Dirigido a Plano)

Antes de codificar, o gerente de projeto constri o plano
Escrever uma documentao detalhada de todas as fazes
do plano
Progresso medido/monitorado em relao ao plano
Mudanas no projeto devem ser refletidas na
documentao e possivelmente no plano

1 PROCESSO DE DESENVOLVIMENTO:
WATERFALL (1970)
5 fases do ciclo de vida Waterfall ou Processo de Desenvolvimento em Cascata
A.K.A. Big Design Up Front ou BDUF
Anlise e definio de requisitos
Projeto de sistema e software
Implementao e teste de unidade
Integrao e teste de sistema
Operao e manuteno
Primeiro modelo a organizar as atividades de desenvolvimento
Uma fase tem de estar completa antes de passar para a prxima.

80

Sadas das fases so acordadas contratualmente!

Todas as fases envolvem atividades de validao

81

COM O QUE CASCATA

FUNCIONA BEM?

COM O QUE CASCATA

FUNCIONA BEM?

82

Especificaes que no
mudam: nibus espacial
da NASA, controle de
aeronaves...

COM O QUE CASCATA

FUNCIONA BEM?
Especificaes que no
mudam: nibus espacial
da NASA, controle de
aeronaves...

83

Muitas vezes, quando o

cliente v, quer
mudanas

COM O QUE CASCATA

FUNCIONA BEM?
Especificaes que no
mudam: nibus espacial
da NASA, controle de
aeronaves...
Muitas vezes, quando o
cliente v, quer
mudanas

84

Muitas vezes, depois de

construdo a primeira
vez, os desenvolvedores
aprendem o caminho que
eles deveriam ter seguido

COM O QUE CASCATA

FUNCIONA BEM?
Plan to throw one [implementation] away;
you will, anyhow.
Fred Brooks, Jr.
(recebeu em 1999 o Prmio Turing por
suas contribuies a arquitetura dos
computadores, sistemas operacionais e
engenharia de software)

85

(Photo by Carola Lauber of SD&M

www.sdm.de. Used by permission
under CC-BY-SA-3.0.)

PROBLEMAS DO MODELO
CASCATA
Particionamento inflexvel do projeto em estgios
Dificulta a resposta aos requisitos de mudana do
cliente.
Documentos completamente elaborados so
necessrios para fazer as transies entre estgios
Apropriado somente quando os requisitos so bem
compreendidos e quando as mudanas so raras

86

Poucos sistemas de negcio tm requisitos estveis.

CICLO DE VIDA ESPIRAL (1986)

87

Combina Big Design

Up Front com
prottipos
Ao invs de
documentar todos os
requisitos no incio, vai
desenvolvendo o
documento de
requisitos atravs de
iteraes de prottipos
medida que eles so
necessrios e evoluem
com o projeto

CICLO DE VIDA ESPIRAL

O processo representado como uma espiral ao
invs de uma sequncia de atividades com
realimentao.
Cada loop na espiral representa uma fase no
processo.
Sem fases definidas, tais como especificao ou
projeto os loops na espiral so escolhidos
dependendo do que requisitado.

88

Os riscos so explicitamente avaliados e resolvidos

ao longo do processo.

CICLO DE VIDA ESPIRAL

Determine
Objectives and
Constraints

Evaluate Alternatives,
Identify and Resolve Risks

Plan Next Iteration

(Figure 1.4, Engineering Long Lasting

Software by Armando Fox and David
Patterson, 2nd Beta edition, 2013.)

Prototype 2

Develop and
verify prototype

89

Prototype 1

Operational
Proto- Prototype 3 type

SETORES DO MODELO ESPIRAL

Definio de objetivos
Objetivos especficos para a fase so identificados.
Avaliao e reduo de riscos
Riscos so avaliados e atividades so realizadas para reduzir os
riscos-chave.
Desenvolvimento e validao
Um modelo de desenvolvimento para o sistema, que pode ser
qualquer um dos modelos genricos, escolhido.
Planejamento
O projeto revisado e a prxima fase da espiral planejada.

90

Processo de Desenvolvimento vs. Processo de Gerenciamento

ESPIRAL
GOOD & BAD

Reduz as chances de mal

entedidos

Gerenciamento de
Riscos no ciclo de vida
Monitoramento do
projeto facilitado
Cronograma e custo
mais realista atravs do
tempo

Iteraes longas de 6 a
24 meses
Tempo para os clientes
mudarem de ideia

Muita documentao por

iterao
Muitas regras para
seguir, pesado para todo
projeto
Custo alto do processo
Complicado de atingir
metas de investimento e
marcos no cronograma
91

Iteraes envolvem o
cliente antes do produto
estar completo

(Figure 1.5, Engineering Long Lasting

Software by Armando Fox and David
Patterson, 2nd Beta edition, 2013.)

92

CICLO DE VIDA DO RATIONAL

UNIFIED PROCESS (RUP) (2003)

FASES DO RUP

93

4 Fases, centrado no gerenciamento de projetos

1. Concepo
Estabelecer o business case para o sistema.
2. Elaborao
Desenvolver um entendimento do domnio do
problema, arquitetura do sistema e identificar riscos
3. Construo
Projeto, programao, teste de sistema e
documentao
4. Transio
Implantar o sistema no seu ambiente operacional.

DISCIPLINAS DE ENGEHARIA
DO RUP
6 disciplinas das pessoas atravs do ciclo de vida do
projeto
1. Business Modeling
2. Requirements
3. Analysis and Design
4. Implementation
5. Test

94

6. Deployment

BOAS PRTICAS DO RUP

Desenvolver o software iterativamente
Gerenciar requisitos
Usar arquiteturas baseadas em
componentes
Modelar o software visualmente
Verificar a qualidade de software
95

Controlar as mudanas do software

RUP
GOOD & BAD

Lotes de ferramentas
da Rational (agora
IBM)
Ferramentas de apoio
a melhoria gradual do
projeto

Ferramentas so
caras (!open source)
Muitas opes para
adaptar o RUP para
uma empresa
Apenas bom para
projetos de mdia a
larga escala

96

Prticas de negcios
vinculados a
processo de
desenvolvimento

GERNCIA DE PROJETOS
DIRIGIDA A PLANO (DP)

97

DP depende do Gerente de Projeto

Escrever contrato para ganhar/vender o projeto
Recrutar equipe de desenvolvimento
Avaliar o desempenho dos engenheiros de
software, que estabelece o salrio
Estimar os custos, manter o cronograma, avaliar
os riscos e super-los
Documentar o plano de gerenciamento de
projetos
Ganhar o crdito pelo sucesso ou culpa se os
projetos esto atrasados ou acima do oramento

TAMANHO DO TIME DE DP
Adding manpower to a late software project makes it later.
Fred Brooks, Jr., The Mythical Man-Month
Leva tempo para os novos membros do time aprenderem sobre
o projeto
A comunicao do time aumenta,
deixando menos tempo para trabalhar
efetivamente

98

Para projetos grandes, o Ideal ter pequenos

grupos (4-9 pessoas) hierarquicamente
compostos

PERGUNTA

99

O que NO uma diferena chave entre os ciclos de

vida Cascata, Espiral e gil?
1. Cascata utiliza fases longas, gil utiliza iteraes
rpidas e Espiral iteraes longas
2. Cascata no possui cdigo funcional antes do fim,
Espiral e gil tem cdigo funcional em cada
iterao
3. Cascata e Espiral utilizam requisitos formalmente
escritos porm gil no utiliza nada escrito
4. Cascata e Espiral possuem fases de projeto
arquitetural porm voc no pode incorporar a
arquitetura de SW no ciclo de vida gil

PERGUNTA

100

O que NO uma diferena chave entre os ciclos de

vida Cascata, Espiral e gil?
1. Cascata utiliza fases longas, gil utiliza iteraes
rpidas e Espiral iteraes longas
2. Cascata no possui cdigo funcional antes do fim,
Espiral e gil tem cdigo funcional em cada
iterao
3. Cascata e Espiral utilizam requisitos formalmente
escritos porm gil no utiliza nada escrito
4. Cascata e Espiral possuem fases de projeto
arquitetural porm voc no pode incorporar a
arquitetura de SW no ciclo de vida gil

101

PROCESSOS DE DESENVOLVIMENTO:
GIL

PROCESSO ALTERNATIVO?
Quo preciso o Dirigido a Plano pode ser em relao
a custo, cronograma e qualidade?
DP requer extensiva documentao e planejamento e
depende da experincia do gerente

102

possvel construir software efetivamente, e com

sucesso, sem um cuidadoso planejamento e
documentao?
Como evitar o basta cortar?

QUO PRECISO SO OS
PROCESSOS DIRIGIDO A PLANOS?
IEEE Spectrum Software Wall of Shame
31 projetos: desperdiaram $17B

!"#$
&!#$

!"#$%&'()&"*'+,-(./"0'-(12234((
!"#$

'($)*+,$-($
./01+2$

%"#$

342+,$-5+6$./01+2$
%&#$

7+6*8(42+0$-6$
4.4(0-(+0$

&"#$

!"#$
'($)*+,$-($
./01+2$

%&#$

34#$562+,$-7+8$
./01+2$
96:-8$0+;6<=$-8$
2+8*>(62+0$

!"#$%&'()&"*'+,-(./%01"&(23334((

(Figure 1.6, Engineering Long Lasting

Software by Armando Fox and David
Patterson, 2nd Beta edition, 2013.)

'($)*+,$-($
./01+2$

342+,$-5+6$./01+2,$
-6$2+6*7(42+0$

3/~500 novos
projetos
cumprem os
custos e o
cronograma

103

!"#$%&'()&"*'+,-(./"01-"1(23345(

PERESS LAW
If a problem has no solution, it may not be a problem, but a
fact, not to be solved, but to be coped with over time.
Shimon Peres

(vencedor do Prmio Nobel da Paz de 1994)

104

(Photo Source: Michael Thaidigsmann, put in public domain,

See http://en.wikipedia.org/wiki/File:Shimon_peres_wjc_90126.jpg)

MTODOS GEIS
A insatisfao com o overhead que envolve os mtodos de
projeto de software dos anos de 1980 e 1990 levou a criao de
mtodos geis. Esses mtodos:
Tm foco no cdigo ao invs de no projeto.
So baseados em uma abordagem iterativa de desenvolvimento
de software.
So planejados para entregar rapidamente o software em
funcionamento e evolu-lo rapidamente para alcanar os
requisitos em constante mudana.

105

O objetivo dos mtodos geis reduzir o overhead nos

processos de software (ex. limitando a documentao) e
permitir uma resposta rpida aos requisitos em constante
mudana sem retrabalho excessivo.

AGILE MANIFESTO, 2001

Estamos descobrindo melhores formas de desenvolver
softwares e ajudar outros a faz-lo tambm. Atravs desse
trabalho, valorizamos mais:
Indivduos e interaes, ao invs de processos e
ferramentas.
Softwares que j funcionam ao invs de documentao
abrangente.
Colaborao do cliente ao invs de negociao
contratual.
Resposta a mudanas ao invs de seguir um plano.

106

O que significa que existe valor nos itens a direita, mas

que valorizamos mais os itens a esquerda.

EXTREME PROGRAMMING (XP)

UMA VERSO DO CICLO DE VIDA
GIL
Se iteraes curtas uma boa prtica, faa elas serem o
mais curtas possvel (semanas vs anos)
Se simplicidade uma boa prtica, sempre faa tudo o
mais simples possvel
Se teste uma boa prtica, teste o tempo todo. Escreve o
cdigo de teste antes de escrever o cdigo a ser testado.

107

Se inspeo uma boa prtica, inspecione o cdigo

continuamente, pela programao em pares, revezando os
pares.

CICLO DE VIDA GIL

Abraa a mudana como um fato da vida:
melhoria contnua versus fases
Desenvolvedores aperfeioam continuamente o
prottipo funcional, mas incompleto, at
satisfazer os clientes, tendo o feedback do
cliente em cada iterao (a cada ~ 2 semanas)

108

Metodologias geis do nfase a Test-Driven

Development (TDD) para reduzir erros, utilizam
Estrias do Usurio para validar requisitos do
cliente e Velocidade para medir o progresso

ITERAO GIL
(ORGANIZAO DO CURSO)
Converse com
o Cliente

Software
legado

BDD: Estrias
do Usurio

Design
Patterns

TDD: Teste
Unitrio

Implantao
na Nuvem

109

Medio da
Velocidade

AGILIDADE ENTO... E AGORA

Controverso em 2001
yet another attempt to undermine the discipline of
software engineering nothing more than an attempt
to legitimize hacker behavior.
Steven Ratkin, Manifesto Elicits Cynicism, IEEE
Computer, 2001

Aceito em 2003

110

Estudo de 2012 com 66 projetos confirmaram que a

maioria usava Metodologias geis, mesmo com times
distribudos

SIM: DIRIGIDO A PLANO

NO: GIL
[Sommerville, 2011]
importante ter uma especificao e projeto?
Os clientes esto disponveis para feedback?
O Sistema a ser desenvolvido grande?
O Sistema complexo (ex. tempo real)?
Vai ter um ciclo de vida longo?
Est utilizando ferramentas ruins?
O time est geograficamente distribudo?
A cultura do time orientada a documentao?
O Time tem um perfil fraco de desenvolvimento?
O sistema est sujeito a regulamentao externa?

111

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

DESENVOLVIMENTO GIL E
DIRIGIDO A PLANOS
Desenvolvimento dirigido a planos
Para a engenharia de software, uma abordagem dirigida a
planos, baseada em estgios de desenvolvimento separados,
com os produtos a serem produzidos em cada um desses
estgios planejados antecipadamente.
O desenvolvimento incremental possvel no modelo cascata dirigido a planos.
Iteraes ocorrem dentro das atividades.

112

Desenvolvimento gil
Especificao, projeto, implementao e teste so intercalados e
os produtos do processo de desenvolvimento so decididos
atravs de um processo de negociao, durante o processo de
desenvolvimento do software.

PERGUNTA
Qual afirmao VERDADEIRA?

113

1. A grande diferena entre gil e DP que gil

no usa requisitos
2. A grande diferena entre gil e DP medir o
progresso de encontro a um plano
3. Voc pode construir apps SaaS utilizando gil
mas no com DP
4. A grande diferena entre gil e DP a
construo de prottipos e a interao com os
clientes durante o processo

PERGUNTA
Qual afirmao VERDADEIRA?

114

1. A grande diferena entre gil e DP que gil

no usa requisitos
2. A grande diferena entre gil e DP medir o
progresso de encontro a um plano
3. Voc pode construir apps SaaS utilizando gil
mas no com DP
4. A grande diferena entre gil e DP a
construo de prottipos e a interao com os
clientes durante o processo

115

FALCIAS E ARMADILHAS

FALCIAS E ARMADILHAS
Falcia: Se um projeto de SW est falhando
em relao ao cronograma, melhore-o
adicionando pessoas!
Adicionar mais pessoas piora!
Curva de aprendizado para novas pessoas
Comunicao aumenta quando o projeto cresce, o
que reduz a disponibilidade para concluir o trabalho

116

Adding manpower to a late software project makes it later.

Fred Brooks, Jr. The Mythical Man Month

FALCIAS E ARMADILHAS

117

Falcia: O ciclo de vida gil melhor para o

desenvolvimento de SW
Bom para alguns projetos, melhor para outros
Mas no uma boa escolha para foguetes da
NASA
Pode-se aprender os princpios da ES de muitas
maneiras, e pode-se aplic-los em tantas outras,
escolha a sua forma (gil/SaaS)
Nota mental: Na sua vida profissional voc ir se
deparar com inmeras outras oportunidades,
espera-se que voc sempre aprenda algo novo

FALCIAS E ARMADILHAS
Armadilha: Ignore o custo do projeto de SW

118

Desde 0 o custo de fabricar um SW, podese inferir que 0 o custo de refazer o SW da

forma que o cliente quer
Ignore o custo de projetar e testar
Abordagem da pirataria: ningum deveria
pagar pelo desenvolvimento, apenas pela
fabricao?

(Figure 1.7, Engineering Long

Lasting Software by Armando Fox
and David Patterson,
Beta edition, 2012.)

119

CONCLUINDO: ES MUITO
MAIS DO QUE PROGRAMAO

120

PRECISO UMA EQUIPE: TAMANHO E

SCRUM

ENG SW COMO UM TIME DE

FUTEBOL
Super-

121

Era dos Programadores

Heris

ENG SW COMO UM TIME DE

FUTEBOL
Era dos Programadores
Super-Heris
Aumento de qualidade e funcionalidades
O programador no tem como resolver tudo sozinho
Carreira de sucesso
Ningum ganha jogo sozinho, quando vence, vencem
todos

Fred Brooks, Jr.

122

There are no winners on a losing team,

and no losers on a winning team.

123

TIME: MAIOR CAMPEO DA

UFSCAR

ORGANIZAO ALTERNATIVA
PARA O TIME?
Processo Dirigido a Planos requer uma extensiva
documentao e planejamento e seu sucesso
depende da experincia do gerente
Como devemos organizar um time gil?

124

Existe alguma alternativa a organizao

hierrquica com um gerente que coordena o
projeto?

SCRUM: ORGANIZAO DO
TIME

Time para Duas Pizzas (4 a 9 pessoas)

Scrum inspirado por pequenas reunies frequentes

125

15 minutos todo dia, no mesmo lugar e hora

Para aprender mais: Agile Software Development with
Scrum by Schwaber & Beedle

DAILY SCRUM AGENDA

Responda 3 perguntas nas daily scrums:

O que foi feito ontem?
O que est planejado para hoje?
H algum impedimento ou obstculo?

126

Ajuda as pessoas a identificar o que elas precisam

PAPIS DO SCRUM

127

Time: times com tamanho

2-pizza que entregam SW
Scrum Master, membro do time que
Atua como um facilitador que organiza reunies
dirias
Mantm o backlog do trabalho a ser feito e o
time focado
Grava decises e mede o processo usando o
backlog
Comunica-se com os clientes e a gerncia fora
da equipe.
Remove os impedimentos e obstculos que
impede o time de fazer progresso no projeto

PAPIS DO SCRUM

128

Product Owner: um membro do

time (no o ScrumMaster) que
representa a voz do cliente e
prioriza as histrias do usurio

RESOLVENDO CONFLITOS
e.g. Diferentes vises em uma determinada
deciso tcnica
Primeiramente liste todos os itens em que os
lados concordam
Ao invs de comear pelas diferenas
Descobriu que esto mais prximos do que
imaginavam?

Cada lado articula argumentos do outro, mesmo

que no concorde com eles

129

Evita confuses sobre termos ou suposies, que

pode ser a verdadeira causa do conflito

RESOLVENDO CONFLITOS
Confronto construtivo (Intel)
Se voc tem uma forte opinio que uma pessoa est propondo
uma soluo errada tecnicamente, voc obrigado a trazer isso
tona, mesmo que seja o seu chefe
Discordo e compromisso (Intel)
Uma vez tomada uma deciso, todos precisam abra-la e
seguir em frente
Eu discordo, mas eu vou ajudar mesmo que no concorde

130

Resoluo de conflitos muito til inclusive na vida pessoal!

SUMARIZANDO
SCRUM
O produto dividido em um conjunto de partes gerenciveis e
inteligveis.
Requisitos instveis no impedem o progresso.
Toda a equipe tem viso de tudo e consequentemente a comunicao
da equipe melhorada.
Os clientes recebem a entrega dos incrementos no tempo certo, alm
do feedback de como o produto funciona.

131

Se estabelece a confiana entre os clientes e os desenvolvedores e se

cria uma cultura positiva na qual todos acham que o projeto dar certo.

PERGUNTA

132

Qual alternativa VERDADEIRA?

1. Comparado ao Scrum, gerentes de projeto DP atuam tanto
como Scrum Master e Product Owner
2. Times devem tentar evitar conflitos a qualquer custo
3. DP pode trabalhar com times maiores do que Scrum que
reportam diretamente ao gerente de projeto
4. Conforme estudos mostraram, 84%-90% so projetos dentro
do prazo e oramento, assim gerentes DP podem prometer
aos clientes um conjunto de funcionalidades dentro de um
prazo e custo acordado.

PERGUNTA

133

Qual alternativa VERDADEIRA?

1. Comparado ao Scrum, gerentes de projeto DP atuam tanto
como Scrum Master e Product Owner
2. Times devem tentar evitar conflitos a qualquer custo
3. DP pode trabalhar com times maiores do que Scrum que
reportam diretamente ao gerente de projeto
4. Conforme estudos mostraram, 84%-90% so projetos dentro
do prazo e oramento, assim gerentes DP podem prometer
aos clientes um conjunto de funcionalidades dentro de um
prazo e custo acordado.

134

PROGRAMAO EM PARES

DUAS MENTES SO MELHORES

DO QUE UMA?
O Esteretipo do programador o
lobo solitrio que trabalha na
madrugada bebendo Red Bull
H uma forma mais social de trabalhar?

135

Quais os benefcios de ter vrias pessoas

programando juntas?
Como prevenir que uma pessoa faa todo
trabalho sozinha enquanto a outra est
navegando no facebook?

PROGRAMAO EM PARES

136

Tem objetivo de melhorar a qualidade do SW,

reduzir o tempo de concluso a partir da
formao de pares desenvolvendo o mesmo
cdigo

PROGRAMAO EM PARES

137

Sente-se lado a lado, com telas para ambos

Sem computador pessoal; muitos disponveis para
qualquer um usar
Para evitar distraes, sem leitor de email, browser, IM...

PROGRAMAO EM PARES

138

Guia entra com o cdigo e pensa

estrategicamente como completar a tarefa,
explicando as decises enquanto codifica
Observador revisa cada linha de cdigo escrita, e
atua como um dispositivo de segurana para o
guia
Observador pensa estrategicamente sobre o
problemas e desafios futuros, e faz sugestes ao
guia
Deve haver MUITA conversa e concentrao
Os papis devem se alternar

AVALIAO DA PROGRAMAO
EM PARES
PP acelera quando a complexidade da tarefa
pequena
PP eleva a qualidade quando a complexidade alta
Curiosamente, o cdigo tambm fica mais legvel
Mais esforo do que na programao solo?
Compartilhamento e conhecimento
Idiomas de programao, truques em ferramentas,
processos, tecnologias...
Muitos times prope trocar os pares por tarefa

139

Eventualmente, todos podem estar

pareados (promiscuous pairing)

PP: FAZER & NO FAZER

No mexa no seu smartphone quando for o
observador
Considere formar o par com algum com
diferente nvel de experincia que voc os dois
iro aprender algo!
Forme pares frequentemente o aprendizado
bidirecional e papis exercitam diferentes
habilidades

140

O observador exercita a habilidade de explicar

seu processo de pensamento ao guia

PERGUNTA
Qual expresso sobre Programao em Pares
VERDADEIRA?

141

1. PP mais rpida, barata e com menos esforo do

que programao solo
2. O guia trabalha nas tarefas na mo, o observador
pensa estrategicamente sobre as tarefas futuras
3. Promiscuous paring uma soluo a longo prazo
para o problema da escassez de programadores
4. O par vai, eventualmente, descobrir quem melhor
como guia e como observador e em seguida define
quem fica em cada funo

PERGUNTA
Qual expresso sobre Programao em Pares
VERDADEIRA?

142

1. PP mais rpida, barata e com menos esforo do

que programao solo
2. O guia trabalha nas tarefas na mo, o observador
pensa estrategicamente sobre as tarefas futuras
3. Promiscuous paring uma soluo a longo prazo
para o problema da escassez de programadores
4. O par vai, eventualmente, descobrir quem melhor
como guia e como observador e em seguida define
quem fica em cada funo