IN0953 ENGENHARIA DE SOFTWARE VINICIUS CARDOSO GARCIA

LICENA DO MATERIAL

Este Trabalho foi licenciado com uma Licena Creative Commons - Atribuio-NoComercial-

CompartilhaIgual 3.0 No Adaptada.

Mais informaes visite

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

2

DOWNLOAD

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

3

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/ 4

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

5

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

6

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/

7

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.

8

SE PREPARANDO PARA O CURSO

9

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:

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

10

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

Sees 1-35 do GitImmersion tutorial (http://gitimmersion.com/lab_01.html) na sua VM.

11

INTRODUO A ENGENHARIA DE SOFTWARE

12

RANKING TOP 200 JOBS ('12)

1. Software Engineer 28. Civil Engineer 38. Nurse 40. Physician 47. Accountant 60. Mechanical Engineer 73. Electrical Engineer 87. Attorney

104. Airline Pilot 133. Fashion Designer 137. High School Teacher 163. Police Officer 173. Flight Attendant 185. Firefighter 196. Newspaper Reporter 200. Lumberjack

InformationWeek 5/15/12. Based on salary, stress levels, hiring outlook, physical demands, and work environment (www.careercast.com) 1

3

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

Sistemas no-triviais Com base em um conjunto de requisitos

14

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

2005: abandonado aps 5 anos de trabalho => desperdcio de $170M Exploso do foguete Ariane 5

1996 => desperdiou $370M

15

COMO EVITAR O DESCRDITO?

Quais so as lies de 60 anos de Desenvolvimento de Software? Vamos revisar algumas abordagens ressaltando pontos fortes e fracos Experincia prtica com uma boa abordagem para Software como Servio

16

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?

Ciclo de releases rpido, sem atualizaes dos usurios?

18

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

Microsoft Office 365, Salesforce SaaS um caminho [revolucionrio] sem volta!

19

6 RAZES PARA SAAS

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

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) Ruby, uma linguagem de script moderna: OO, funcional, gerenciamento automtico de memria, tipos dinmicos, reuso via mix-ins, sntese via metaprogramao

21

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

http://bit.ly/1b9QbFj

22

PERGUNTA

Qual o argumento mais FRACO para a popularidade das apps como SaaS do Google ?

1. No perca dados: Gmail 2. Grupos cooperativos: Documentos 3. Grandes conjuntos de dados: Youtube 4. Sem atualizaes intrusivas ao melhorar o

app: Busca

23

PERGUNTA

Qual o argumento mais FRACO para a popularidade das apps como SaaS do Google ?

1. No perca dados: Gmail 2. Grupos cooperativos: Documentos 3. Grandes conjuntos de dados: Youtube 4. Sem atualizaes intrusivas ao melhorar o

app: Busca

24

25

ARQUITETURA ORIENTADA A SERVIO (SOA)

ARQUITETURA DE SOFTWARE

Voc pode/consegue projetar um software de forma que seja possvel recombinar mdulos independentes para ofertar diferentes apps sem muito esforo de programao?

26

ARQUITETURA ORIENTADA A SERVIO

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

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

27

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.

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.

28

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. 7. Thank you; have a nice day!

29

reviews users orders

Review Subsystem

User Profile Service

Buying Subsystem

Bookstore Service

BOOKSTORE: SILO

Subsistemas internos podem compartilhar dados diretamente

User profile Service Todos os subsistemas dentro de uma nica API (Bookstore)

30 (Figure 1.3, Engineering Long Lasting Software by Armando Fox and David

Patterson, Beta edition, 2012.)

Bookstore Service

users

User Profile Service

user reviews

Review Service

editor reviews orders

Buying Service

credit card processing

users

Social Network Service

Favorite Books Service

BOOKSTORE: SOA

Subsistemas independentes, como se estivessem em datacenters separados

User Service API Pode recombinar servios para criar novos servios (Favorite Books)

31 (Figure 1.4, Engineering Long Lasting

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

PERGUNTA

Quais afirmaes NO so verdades sobre SOA? 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

32

PERGUNTA

Quais afirmaes NO so verdades sobre SOA? 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

33

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? Como desenvolvedores de SW independentes constroem apps SaaS e competem sem um investimento em HW similar a Amazon, Google, Microsoft?

35

INFRAESTRUTURA SAAS?

3 Demandas de infraestrutura para SaaS 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

36

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

4. Confiabilidade via redundncia extensiva

37

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% Modelos de negcio baseados em pay-as-you-go trazem benefcios concretos

38

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 Tantos computadores quanto voc puder dispor

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

39

2013 AWS INSTANCES & PRICES

40

Instance Type Per

Hour $ Ratio to small

Virtual Cores

Compute Units

Memory (GiB) Storage (GB)

m1.small $0.06 1.0 1 1.0 1.7 1 x 160 m1.medium $0.12 2.0 1 2.0 3.8 1 x 410 m1.large $0.24 4.0 2 4.0 7.5 2 x 420 m1.xlarge $0.48 8.0 4 8.0 15.0 4 x 420 m3.xlarge $0.50 8.3 4 13.0 15.0 EBS m3.2xlarge $1.00 16.7 8 26.0 30.0 EBS c1.medium $0.15 2.5 2 5.0 1.7 1 x 350 c1.xlarge $0.58 9.7 8 20.0 7.0 4 x 420 cc2.8xlarge $2.40 40.0 32 88.0 60.5 4 x 840 m2.xlarge $0.41 6.8 2 6.5 17.1 1 x 420 m2.2xlarge $0.82 13.7 4 13.0 34.2 1 x 850 m2.4xlarge $1.64 27.3 8 26.0 68.4 2 x 840 cr1.8xlarge $3.50 58.3 32 88.0 244.0 2 x 120 SSD hi1.4xlarge $3.10 51.7 16 35.0 60.5 2 x 1024 SSD hs1.8xlarge $4.60 76.7 16 35.0 117.0 24 x 2048 t1.micro $0.02 0.3 1 varies 0.6 EBS cg1.4xlarge $2.10 35.0 16 33.5 22.5 2 x 840

SUPERCOMPUTADOR PARA ALUGAR 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

41

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? O que isso pode significar para a sociedade?

42

PERGUNTA

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

43

PERGUNTA

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

44

45

SW LEGADO VS SW BONITO

ESTTICA DE PROGRAMAO

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

Se funcionar, no importa com o que o cdigo se parece?

46

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]

__% 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

47

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]

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

48

CDIGO LEGADO: VITAL PORM IGNORADO 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

49

PERGUNTA

Que tipo de SW considerado uma falha pica?

1. Cdigo bonito 2. Cdigo legado 3. Cdigo inesperadamente com vida curta 4. Tanto alternativas 2 e 3

50

PERGUNTA

Que tipo de SW considerado uma falha pica?

1. Cdigo bonito 2. Cdigo legado 3. Cdigo inesperadamente com vida curta 4. Tanto alternativas 2 e 3

51

52

GARANTIA DE QUALIDADE E TESTES

QUALIDADE DE SOFTWARE

O Que qualidade de SW e como garantimos ela? (QA) V&V: Qual a diferente (se existe) entre Verificao e Validao?

53

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 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

54

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 Testes -> SW Quality Assurance

55

TESTES

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

Um nvel superior no refaz os testes do inferior

56

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 Teste de ____________: o mtodo faz o que era esperado fazer

57

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 Teste de unidade ou unitrio: o mtodo faz o que era esperado fazer

58

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)

Escreva os testes ANTES de escrever o cdigo que voc espera (testes guiam a codificao)

59

LIMITES DOS TESTES

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

Edsger W. Dijkstra

60 (Photo by Hamilton Richards. Used by permission under CC-BY-SA-3.0.)

(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

61 (Photo by Hamilton Richards. Used by permission under CC-BY-SA-3.0.)

(recebeu em 1972 o Prmio Turing por sua contribuio fundamental para o desenvolvimento das Linguagens de Programao)

PERGUNTA

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

62

PERGUNTA

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

63

64

PRODUTIVIDADE: CONCISO, SNTESE, REUTILIZAO E FERRAMENTAS

PRODUTIVIDADE

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

65

CLAREZA VIA CONCISO

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

vs _______________________________

66

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

Linguagens de Programao de Alto Nvel (HLL) vs. Linguagens assembly

Gerenciamento automtico de memria (Java vs C)

Linguagens de script: reflexo, metaprogramao

67

SNTESE

Sntese de Software BitBit: gerao de cdigo para atender alguma

situao e remoo de testes condicionais Estgio da pesquisa: Programao por Exemplo

68

REUSO

Reutilizar cdigo ou escrever cdigo? Tcnicas (cronologicamente)

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

69

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

Muitas chances na nossa proposta: Cucumber, RSpec, Pivotal Tracker, Trello

70

PERGUNTA

Qual afirmao VERDADE sobre produtividade?

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

71

PERGUNTA

Qual afirmao VERDADE sobre produtividade?

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

72

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)

No queira encontrar uma sria de locais onde a mesma correo deva ser aplicada!

Refatore sempre seu cdigo!

73

SUMARIZANDO...

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

74

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 POO em Ruby

76

PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE

Cascata Espiral gil

77

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? Se sim, que tipo de processo de desenvolvimento devemos utilizar para torn-lo previsvel a este ponto?

78

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

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

79

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.

Sadas das fases so acordadas contratualmente! Todas as fases envolvem atividades de validao

80

COM O QUE CASCATA FUNCIONA BEM?

81

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

82

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

83

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 Muitas vezes, depois de construdo a primeira vez, os desenvolvedores aprendem o caminho que eles deveriam ter seguido

84

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)

(Photo by Carola Lauber of SD&M www.sdm.de. Used by permission under CC-BY-SA-3.0.)

85

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

Poucos sistemas de negcio tm requisitos estveis.

86

CICLO DE VIDA ESPIRAL (1986)

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

87

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. Os riscos so explicitamente avaliados e resolvidos ao longo do processo.

88

CICLO DE VIDA ESPIRAL

Determine Objectives and

ConstraintsEvaluate Alternatives,

Identify and Resolve Risks

Plan Next Iteration Develop and verify prototype

Proto-type 1

Proto-type 2

Proto-type 3

Opera-tionalProto-type

(Figure 1.4, Engineering Long Lasting Software by Armando Fox and David Patterson, 2nd Beta edition, 2013.)

89

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.

Processo de Desenvolvimento vs. Processo de Gerenciamento

90

ESPIRAL GOOD & BAD

Iteraes envolvem o cliente antes do produto estar completo

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

CICLO DE VIDA DO RATIONAL UNIFIED PROCESS (RUP) (2003)

(Figure 1.5, Engineering Long Lasting Software by Armando Fox and David Patterson, 2nd Beta edition, 2013.) 92

FASES DO RUP

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.

93

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 6. Deployment

94

BOAS PRTICAS DO RUP

Desenvolver o software iterativamente Gerenciar requisitos Usar arquiteturas baseadas em componentes Modelar o software visualmente Verificar a qualidade de software Controlar as mudanas do software

95

RUP GOOD & BAD

Prticas de negcios vinculados a processo de desenvolvimento 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

GERNCIA DE PROJETOS DIRIGIDA A PLANO (DP) 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

97

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 Para projetos grandes, o Ideal ter pequenos grupos (4-9 pessoas) hierarquicamente compostos

98

PERGUNTA

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

99

PERGUNTA

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

100

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

possvel construir software efetivamente, e com sucesso, sem um cuidadoso planejamento e documentao?

Como evitar o basta cortar?

102

QUO PRECISO SO OS PROCESSOS DIRIGIDO A PLANOS?

IEEE Spectrum Software Wall of Shame 31 projetos: desperdiaram $17B

103

!"#$

%$

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

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

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

!"#$

%$

&!#$

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

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

342+,$-5+6$./01+2$

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

!"#$

%"#$

&"#$

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

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

34#$562+,$-7+8$./01+2$

96:-8$0+;6(62+0$

(Figure 1.6, Engineering Long Lasting Software by Armando Fox and David Patterson, 2nd Beta edition, 2013.)

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

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

104

(vencedor do Prmio Nobel da Paz de 1994)

(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.

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. 1

05

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. O que significa que existe valor nos itens a direita, mas que valorizamos mais os itens a esquerda.

106

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. Se inspeo uma boa prtica, inspecione o cdigo continuamente, pela programao em pares, revezando os pares.

107

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) 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

108

ITERAO GIL (ORGANIZAO DO CURSO)

109

Converse com o Cliente

Software legado

Design Patterns

BDD: Estrias do Usurio

TDD: Teste Unitrio

Medio da Velocidade

Implantao na Nuvem

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

Estudo de 2012 com 66 projetos confirmaram que a maioria usava Metodologias geis, mesmo com times distribudos

110

SIM: DIRIGIDO A PLANO NO: GIL 1. importante ter uma especificao e projeto? 2. Os clientes esto disponveis para feedback? 3. O Sistema a ser desenvolvido grande? 4. O Sistema complexo (ex. tempo real)? 5. Vai ter um ciclo de vida longo? 6. Est utilizando ferramentas ruins? 7. O time est geograficamente distribudo? 8. A cultura do time orientada a documentao? 9. O Time tem um perfil fraco de desenvolvimento? 10. O sistema est sujeito a regulamentao externa?

111

[Sommerville, 2011]

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. 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.

112

PERGUNTA

Qual afirmao VERDADEIRA? 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

113

PERGUNTA

Qual afirmao VERDADEIRA? 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

114

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

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

117

FALCIAS E ARMADILHAS

Armadilha: Ignore o custo do projeto de SW Desde 0 o custo de fabricar um SW, pode-se 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?

118

CONCLUINDO: ES MUITO MAIS DO QUE PROGRAMAO

119 (Figure 1.7, Engineering Long Lasting Software by Armando Fox

and David Patterson, Beta edition, 2012.)

120

PRECISO UMA EQUIPE: TAMANHO E SCRUM

ENG SW COMO UM TIME DE FUTEBOL

Era dos Programadores Super-Heris

121

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

122

There are no winners on a losing team, and no losers on a winning team.

Fred Brooks, Jr.

TIME: MAIOR CAMPEO DA UFSCAR

123

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? Existe alguma alternativa a organizao hierrquica com um gerente que coordena o projeto?

124

SCRUM: ORGANIZAO DO TIME

Time para Duas Pizzas (4 a 9 pessoas) Scrum inspirado por pequenas reunies frequentes

15 minutos todo dia, no mesmo lugar e hora Para aprender mais: Agile Software Development with

Scrum by Schwaber & Beedle

125

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?

Ajuda as pessoas a identificar o que elas precisam

126

PAPIS DO SCRUM

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

127

PAPIS DO SCRUM

Product Owner: um membro do time (no o ScrumMaster) que representa a voz do cliente e prioriza as histrias do usurio

128

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 Evita confuses sobre termos ou suposies, que

pode ser a verdadeira causa do conflito

129

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

Resoluo de conflitos muito til inclusive na vida pessoal!

130

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. 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.

131

PERGUNTA

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.

132

PERGUNTA

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.

133

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?

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?

135

PROGRAMAO EM PARES

Tem objetivo de melhorar a qualidade do SW, reduzir o tempo de concluso a partir da formao de pares desenvolvendo o mesmo cdigo

136

PROGRAMAO EM PARES

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...

137

PROGRAMAO EM PARES

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

138

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 Eventualmente, todos podem estar

pareados (promiscuous pairing)

139

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

O observador exercita a habilidade de explicar seu processo de pensamento ao guia

140

PERGUNTA

Qual expresso sobre Programao em Pares VERDADEIRA?

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

141

PERGUNTA

Qual expresso sobre Programao em Pares VERDADEIRA?

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

142