Desenvolvimento de SaaS / Engenharia de Software como Serviço

Prof. Vinicius Cardoso Garcia vcg@cin.ufpe.br :: @vinicius3w :: assertlab.com

Licença do materialEste Trabalho foi licenciado com uma Licença

Creative Commons - Atribuição-NãoComercial-CompartilhaIgual 3.0 Não Adaptada.

Mais informações visite: http://creativecommons.org/licenses/by-nc-sa/3.0/deed.pt

2

Download

Apresentação com anotações

http://bit.ly/ess-enacomp-2015

3

Quem sou eu?• Professor @ Cin-UFPE [Sistemas de Informação, Pós-Graduação em Ciência da Computação], Aug-2010

• 13/44 MSc; 6 (+4 co) DSc :: http://viniciusgarcia.com • ASSERT [Advanced System and Software Engineering Research Technologies] Lab :: http://assertlab.com • Ikewai [http://www.ikewai.com]: rede de business designers

• Netweaver • USTO.RE [http://usto.re] :: Smart Cloud Storage

• Chief Scientist Officer (CSO) • INES [Instituto Nacional para Ciência e Tecnologia em Engenharia de Software] :: http://www.ines.org • Engenheiro de Sistemas :: 2005 ~ 2010 @ CESAR • D.Sc. em Engenharia de Software, Feb-2010 • RiSE [Reuse in Software Engineering] Group

• 2007 –> [Startup]

4

http://amzn.to/ILF8kY

Sobre o CIn-UFPE

5

1ª IES A GANHAR O PRÊMIO

FINEP DE INOVAÇÃO

2011

PREMIADO EM 6 EDIÇÕES DA MICROSOFT IMAGINE CUP

7 X CAMPEÃO BRASILEIRO MARATONA DE PROGRAMAÇÃO

PÓS-GRADUAÇÃO

Defesa da centésima tese de Doutorado em 2006

Defesa da milésima dissertação de mestrado em 2011

Nível 6 na CAPES

Defesa da centésima dissertação de Mestrado Profissional em 2012

OUTRAS CONQUISTAS:

Prêmio Dorgival Brandão Júnior da Qualidade e Produtividade

Concursos de teses e dissertações

Asia Java Mobile Challenge

Engenharia de Software na PráticaPractical Software Engineering

6

Warm up!• O que é Engenharia de Software?

• O que faz um Engenheiro de Software? • E como ele faz?

• Qual aspecto do ciclo de vida do software consome mais recursos?

7

60% of SW total cost over lifecycle is maintenance. We'll have more to say about this later. but ironic that students/courses focus more on "greenfield" SW despite the fact your first project probably won't be, and that more $$ is spent on keeping software useful!

Ranking Top 200 Jobs ('12)1. Software Engineer 28. Civil Engineer 34. Programmer 40. Physician 47. Accountant 60. Mechanical Engineer 73. Electrical Engineer 87. Attorney

8

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

Organizes and lists the instructions for computers to process data and

solve problems in logical order. Income: $71,178

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

Researches, designs, develops and maintains software systems along with hardware development

for medical, scientific, and industrial purposes. Income: $88,142 (+25%)

Software Engineer ranks No. 1, followed by Actuary, Human Resources Manager, Dental Hygienist and Financial Planner.

Engenharia de Software• As economias de TODAS as nações desenvolvidas são dependentes

de software. • Cada vez mais sistemas são controlados por software. • A engenharia de software se dedica às teorias, métodos e

ferramentas para desenvolvimento de software profissional • Sistemas não-triviais • Com base em um conjunto de requisitos

9

Poor President Obama...

10

- top sites aim for "four nines" availability. healthcare.gov started as "one four" and is now up to "one nine"- sad thing is we could've predicted. Our students could've warned Obama!

Como evitar o descrédito?• Quais são as lições de 60 anos de Desenvolvimento de

Software? • Vamos revisar algumas abordagens ressaltando pontos fortes

e fracos • Experiência prática com uma boa abordagem para Software

como Serviço

11

Software como ServiçoSoftware as a Service (SaaS)

12

Alvos do software• SW Tradicional: código binário instalado e rodando totalmente no dispositivo do

cliente • Os usuários precisam atualizar repetidamente

• Muitas versões de hardware e muitas versões de SO • Novas versões 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 rápido, sem atualizações dos usuários?

13

Very popular topics

Rent like using doing your laundry in a service

Software como Serviço (SaaS)• SaaS entrega SW & dados como serviço através da rede via

clientes “magros” (e.g., browser) rodando no cliente • Busca, redes sociais, streaming de vídeo

• Versões SaaS de SW tradicionais • Microsoft Office 365, Salesforce

• SaaS é um caminho [revolucionário] sem volta!

14

May change SW industry by end of decade, switch of leaders and followers

6 Razões para SaaS1. Sem preocupações com o HW sobre instalação ou SO 2. Sem preocupações sobre perda de dados (no site remoto) 3. Fácil interação para grupos (mesmos dados) 4. Se o volume de dados é grande ou muda frequentemente, basta manter uma

cópia no sitio central 5. Uma cópia do SW, ambiente de HW controlado => sem aborrecimentos com

compatibilidade [desenvolvedores] 6. Uma cópia 1 => simplifica atualizações para desenvolvedores e sem CRs de

atualização dos usuários

15

Is laptop backed up? Lose my cellphone?

6 means SW changes all the time with more features

Continuously being asked to upgrade my software on my laptop

SaaS ❤ Metodologias Ágeis & Rails• Atualizações frequentes => Ciclo de Vida Ágil • Muitos frameworks para Ágil/SaaS

• Django/Python, Zend/PHP, Spring/Java

• A única esperança é contar com um ambiente altamente produtivo (linguagens, ferramentas, frameworks...) • Sugestão: “Crossing the Software Education Chasm”, A. Fox, D.

Patterson, Comm. ACM, May 2012 (http://bit.ly/1b9QbFj)16

Arquitetura Orientada a Serviço Software Oriented Architecture (SOA)

17

Arquitetura de SoftwareVocê pode/consegue projetar um software de forma que seja possível recombinar módulos independentes para ofertar diferentes apps sem muito esforço de programação?

18

Arquitetura Orientada a Serviço• SOA: Arquitetura de Software onde todos os componentes são

projetados como serviço • Apps são compostas por serviços interoperáveis

• Fácil de derivar uma nova versão para um conjunto de usuários • Também é fácil para se recuperar de um erro de projeto

• Contraste para “SW silo” sem uma API interna

19

Simply, every component can be a service. We’ll do examples of what is and what isn’t.

Combine services into new apps – tailored service is easyEasier to repair, so easy to replace components

In constrast

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.

20

Blogger at Google used to be at Amazon

Internal blog, for Google rantExternal blog

Mixed them up, and we put it into the book before he deleted entry

Amazon for all its weaknesses, does SOAGoogle, for all its strengths, doesn’t get SOA

Started as silo’d sw in 1995, then 7 years later switched to SOA via directive from Bezos, CEO and founder of AmazonBS in CS Princeton

Blogger claims one of 7 points is false; we’ll figure out which at end

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

21

Why should Iisten to CEO? What does he know? Don’t you read Dilbert? I’m smarter than the CEO. What should I follow this email?

False was 7. Bezos doesn’t care about your day. He got them with “fired”

5 points is one of best dscriptions of SOA; everything must use API

Facebook too; Facebook platform 3 years later

(Google doesn’t get it)

Bookstore: Silo

• Subsistemas internos podem compartilhar dados diretamente • User profile Service

• Todos os subsistemas “dentro” de uma única API (“Bookstore”)

22

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

edition, 2012.)

the reviews subsystem can get user profile info out of the users subsystem

3 indabilidadedent services inside the silo

Bookstore: SOA

• Subsistemas independentes, como se estivessem em datacenters separados • User Service API

• Pode recombinar serviços para criar novos serviços (“Favorite Books”)

23

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

Creates another app – group’s favorite books app from standard bookstore just another combinationEven though all inside same datacenter, SW written as if in different ones

No service can access another services data – must go through API of service

Note not a layered model of software, but a network connection

Computação em NuvemCloud Computing

24

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?

25

Infraestrutura SaaS?• 3 Demandas de infraestrutura para SaaS

1. Comunicação: permitir que os consumidores interajam com o serviço

2. Escalabilidade: flutuações na demanda durante adição de novos serviços para novos clientes rapidamente

3. Confiabilidade: disponibilidade contínua de serviço e comunicação 24x7

26

Scalability for holidaysHas to work all the time – since only in one place

Serviços em Clusters• Cluster: aglomerado de computadores conectados

1. Mais escalável do que servidores convencionais 2. Mais barato do que servidores convencionais

• 20X para equivalentes vs. Servidores maiores 3. Poucos operadores para 1000s servidores

• Seleção cuidadosa de HW e SW idênticos • Monitores de Máquinas Virtuais simplifica a operação

4. Confiabilidade via redundância extensiva

27

Originally mainframe computers, but switched to clusters at Berkeley (NOW)Expensive, how to scale, still failed sometime

Gold plated mainframe still fails, so more copies to overcome when failures, but 20X cheaper

VM help with kill program

20x cheaper so 2 or 3 times as many copies, SW handles failure

Warehouse de Computadores Escaláveis• 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 negócio baseados em pay-as-you-go trazem benefícios

concretos28

Services got popular, so had to keep scaling (100X)House – build own customer warehouse, so cheaperNetwork Bandwidth

Consolidate 100 companies into one datacenter,

2006 Bezos said should be able to sell – AWS Elastic Computing 2 (EC2)Original argument was underutilized 11 months of the year – spare cycles, became so popular

Today its reversed – Amazon now runs on Amazon Web Services

Computação Utilitária / Computação em Nuvem Pública

• Oferece computação, armazenamento, comunicação a centavos por hora • Sem adicionais por escalabilidade

• 1000 computadores @ 1 hora, ou • 1 computador @ 1000 horas

• Ilusão de infinita escalabilidade para o usuário • Tantos computadores quanto você puder dispor

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

29

No premium for scale is striking – usually much more expensive to scale

2013 AWS Instances & Prices

30

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

17 options – vary in cost 75:1, vary in performance 90:1, vary in memory size 150:1, vary in storage 300:1

Pay per hour

2006 for $0.10, now just $0.06

Computação Utilitária• Competição dos Top 500 supercomputadores • 532 Eight Extra Large (@ $2.40/hour), 17000 cores = 240 TeraFLOPS • 72nd/500 supercomputer @ ~$1300 per hour • Cartão de crédito => até 1000s computadores • FarmVille no AWS

• Primeiro grande jogo online: 5M usuários • E se a startup tivesse que construir o data center? • 4 dias = 1M; 2 meses = 10 M; 9 meses = 75M

31

CC2 = Cluster Compute Eight Extra Large

Zygna make Farmville using AWSBiggest in world; too big, too much $

Calling dell, take 6 months, AWS scale with demand

IBM Watson para alugar?• Campeão 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 máquina com IA seria tão boa quanto uma pessoa

muito bem treinada @ $200/hora? • O que isso pode significar para a sociedade?

32

Same rate as lawyers and accountants

$200 as much as IBM payed for Jeopardy champion

What is this going to mean down the road?

Might want to talk this over wine with your friends majoring in law or accounting

Great jobs for us; what about future of rest of society; ML is delivering

Processos de Desenvolvimento de Software Dirigidos a PlanosPlan-and-Document processes

33

Como evitar o descrédito do SW?• Podemos tornar a construção de software tão previsível em

termos de cronograma, custo e qualidade como a construção de uma ponte ou um edifício?

• Se sim, que tipo de processo de desenvolvimento devemos utilizar para torná-lo previsível a este ponto?

34

Engenharia de Software• Trazer a disciplina engenharia para o SW

• Termo cunhado ~20 anos após o 1º computador • Encontrar métodos de desenvolvimento de SW tão previsíveis em qualidade, custo e tempo

assim como engenharia civil

• “Plan-and-Document” (Dirigido a Plano) • Antes de codificar, o gerente de projeto constrói o plano • Escrever uma documentação detalhada de todas as fazes do plano • Progresso medido/monitorado em relação ao plano • Mudanças no projeto devem ser refletidas na documentação e possivelmente no plano

35

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

• Análise e definição de requisitos • Projeto de sistema e software • Implementação e teste de unidade • Integração e teste de sistema • Operação e manutenção

• Primeiro modelo a organizar as atividades de desenvolvimento • Uma fase tem de estar completa antes de passar para a próxima.

• Saídas das fases são acordadas contratualmente! • Todas as fases envolvem atividades de validação

36

Like falling down a waterfallLots of planning, 6-12 months or more per stepOften steps done by different peopleThrow over the wallLots of documentation in case people leave

Ciclo de Vida Espiral (1986)• Combina Big Design Up Front com

protótipos • Ao invés de documentar todos os

requisitos no início, vai desenvolvendo o documento de requisitos através de iterações de protótipos à medida que eles são necessários e evoluem com o projeto

37

Ciclo de Vida do Rational Unified Process (RUP) (2003)

38

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

Gerência 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 salário • Estimar os custos, manter o cronograma, avaliar os riscos e superá-los • Documentar o plano de gerenciamento de projetos • Ganhar o crédito pelo sucesso ou culpa se os projetos estão atrasados ou

acima do orçamento

39

Tamanho do Time de DP

• Leva tempo para os novos membros do time aprenderem sobre o projeto

• A comunicação do time aumenta, deixando menos tempo para trabalhar efetivamente

• Para projetos grandes, o Ideal é ter pequenos grupos (4-9 pessoas) hierarquicamente compostos

40

“Adding manpower to a late software project makes it later.” Fred Brooks, Jr., The Mythical Man-Month

AgileDevelopment processes

41

earliest ever lecture prep! follow along download slides

Processo Alternativo?• Quão preciso o Dirigido a Plano pode ser em relação a custo,

cronograma e qualidade? • DP requer extensiva documentação e planejamento e depende da

experiência do gerente • É possível construir software efetivamente, e com sucesso,

sem um cuidadoso planejamento e documentação? • Como evitar o “basta cortar”?

42

Quão preciso são os processos dirigido a planos?

43

!"#$

%&#$

!"#$%&'()&"*'+,-(./%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<=$-8$2+8*>(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

Figure 1.6: The first study of software projects found that 53% of projects exceeding their budgets by a factor of 2.9 and overshot their schedule by a factor of 3.2 and another 31% of software projects were cancelled before completion (Johnson 1995). The an estimated annual cost in the United States for such software projects was $100B. The second survey of 250 large projects, each with the equivalent of more than a million lines of C code, found similarly disappointing results (Jones 2004). The final survey of members of the British Computer Society found that only 130 of 1027 projects met their schedule and budget. Half of all projects were maintenance or data conversion projects and half new development project, but the successful projects divided into 127 of the former and just 3 of the latter (Taylor 2000).

Peres’s Law

44

“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 Prêmio 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)

Agile Manifesto, 2001• “We are uncovering better ways of developing SW by doing it and helping

others do it. Through this work we have come to value • Individuals and interactions over processes & tools • Working software over comprehensive documentation • Customer collaboration over contract negotiation • Responding to change over following a plan

• That is, while there is value in the items on the right, we value the items on the left more.”

45

“Extreme Programming” (XP), uma versão do ciclo de vida ágil

• If short iterations are good, make them as short as possible (weeks vs. years)

• If simplicity is good, always do the simplest thing that could possibly work

• If testing is good, test all the time. Write the test code before you write the code to test.

• If code reviews are good, review code continuously, by programming in pairs, taking turns looking over each other’s shoulders.

46

Agile lifecycle• Embraces change as a fact of life: continuous improvement vs.

phases • Developers continuously refine working but incomplete prototype

until customers happy, with customer feedback on each Iteration (every ~1 to 2 weeks)

• Agile emphasises Test-Driven Development (TDD) to reduce mistakes, written down User Stories to validate customer requirements, Velocity to measure progress

47

Working but incomplete

More iterations, the more you’ll learn

Write Tests before write code

Customer helps write SW requirements

Agilidade então... 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 distribuídos

48

It Takes a TeamSize & Scrum

49

(Engineering Software as a Service §10.1)

Eng SW como um time de futebol• Era dos Programadores Super-Heróis • Aumento de qualidade e funcionalidades

• O programador não tem como resolver tudo sozinho • Carreira de sucesso

• Ninguém ganha jogo sozinho, quando vence, vencem todos

50

“There are no winners on a losing team, and no losers on a winning team.” Fred Brooks, Jr.

Early in my career knew superhero programmers – go away for weekend and build amazing breakthroughKen Thompson, co-inventor of UNIX, won Turing Award, was a Berkeley studentBill Joy, led BSD UNIX, which was first open source project, hero programmer – wrote vi over long weekend

No longer individuals building amazing things – Linus Torvald leads open source around Linux, but not done by himself

Early – bar was lowNot that many superheroes

What does team need to win (do you need to do more than your part)

Time: Maior campeão da UFSCAR

51

Organização alternativa para o time?• Processo Dirigido a Planos requer uma extensiva documentação e

planejamento e seu sucesso depende da experiência do gerente

• Como devemos organizar um time Ágil?

• Existe alguma alternativa a organização hierárquica com um gerente que coordena o projeto?

52

SCRUM: Organização do time

• Time para “Duas Pizzas” (4 a 9 pessoas) • Scrum é inspirado por pequenas reuniões frequentes

• 15 minutos todo dia, no mesmo lugar e hora • Para aprender mais: Agile Software Development with Scrum by Schwaber & Beedle

53

Bezos, lots of companies, (2 pizza teams in more people)

Need a way to self-organizeScrum – penalty

Standup Meeting

Its 9:08, over by 9:23

What happens at meeting – go

Daily SCRUM Agenda• Responda 3 perguntas nas “daily scrums”:

1. O que foi feito ontem? 2. O que está planejado para hoje? 3. Há algum impedimento ou obstáculo?

• Ajuda as pessoas a identificar o que elas precisam

54

Go around in a circle

By understanding what each team member was doing, the team can identify work that would help others make more rapid progress

This would unblock me if you would do this first

Most is common sense

Papéis do Scrum• Time: times com tamanho 2-pizza que entregam SW • Scrum Master, membro do time que

• Atua como um facilitador que organiza reuniões diárias • Mantêm o backlog do trabalho a ser feito e o time focado • Grava decisões e mede o processo usando o backlog • Comunica-se com os clientes e a gerência fora da equipe. • Remove os impedimentos e obstáculos que impede o time

de fazer progresso no projeto

55

Not the manager – SM is supposed to be the buffer so team can concentrate

Papéis do Scrum• Product Owner: um membro do time (não é o

Scrum Master) que representa a voz do cliente e prioriza as histórias do usuário

56

Team member, not the scrum master, represents customer at daily scrums

Also prioritises user stories

Resolvendo conflitos• e.g. Diferentes visões em uma determinada decisão técnica • Primeiramente liste todos os itens em que os lados concordam

• Ao invés de começar pelas diferenças • Descobriu que estão mais próximos do que imaginavam?

• Cada lado articula argumentos do outro, mesmo que não concorde com eles • Evita confusões sobre termos ou suposições, que pode ser a verdadeira

causa do conflito

57

Resolvendo conflitos• Confronto construtivo (Intel)

• Se você tem uma forte opinião que uma pessoa está propondo uma solução errada tecnicamente, você é obrigado a trazer isso à tona, mesmo que seja o seu chefe

• Discordo e compromisso (Intel) • Uma vez tomada uma decisão, todos precisam abraçá-la e seguir em frente • “Eu discordo, mas eu vou ajudar mesmo que não concorde”

• Resolução de conflitos é muito útil inclusive na vida pessoal!

58

Programação em ParesPair Programming

59

(Engineering Software as a Service §10.2)

University is a chance to make mistakes at university

Duas mentes são melhores do que uma?• O Estereótipo do programador é o lobo solitário que

trabalha na madrugada bebendo Red Bull • Há uma forma mais social de trabalhar?

• Quais os benefícios de ter várias pessoas programando juntas?

• Como prevenir que uma pessoa faça todo trabalho sozinha enquanto a outra está navegando no facebook?

60

Programação em Pares• Goal: improve software quality, reduce time to completion by

having 2 people develop the same code • Some people (and companies) love it • Try in discussion sections to see if you do • Some students in the past have loved it and used for

projects

61

Programação em Pares

• Sente-se lado a lado, com telas para ambos • Sem computador pessoal; muitos disponíveis para qualquer um usar • Para evitar distrações, sem leitor de email, browser, IM...

62

Sarah Mei and JR Boyens at Pivotal Labs

We know that MultiTasking is distracting, so these are real workstations with no facebook, email, twitter, …

Don’t check email between 8AM and 5PM

Productivity improves

New employees say tired after 8 hours

Go home at night and don’t do programming at home

SV Management technique is buying dinner

Programação em Pares• Guia entra com o código e pensa estrategicamente como completar a tarefa,

explicando as decisões enquanto codifica • Observador revisa cada linha de código escrita, e atua como um dispositivo de

segurança para o guia • Observador pensa estrategicamente sobre o problemas e desafios futuros, e

faz sugestões ao guia • Deve haver MUITA conversa e concentração • Os papéis devem se alternar

63

Talking out loud while work (like surgeon on TV)

Driver short term, Observer long termHave to Alternatve

Avaliação da Programação em Pares• PP acelera quando a complexidade da tarefa é pequena • PP eleva a qualidade quando a complexidade é alta

• Curiosamente, o código também fica mais legível • Mais esforço do que na programação solo? • Compartilhamento de conhecimento

• Idiomas de programação, truques em ferramentas, processos, tecnologias... • Muitos times propõe trocar os pares por tarefa

• Eventualmente, todos podem estar “pareados” (“promiscuous pairing”)

64

But Pivotal Labs denies it

More senior and more junior

“promiscuous pairing”

Does it factor in distraction

PP: fazer & Não Fazer• Não mexa no seu smartphone quando for o observador • Considere formar o par com alguém com diferente nível de

experiência que você – os dois irão aprender algo! • Forme pares frequentemente – o aprendizado é bidirecional e

papéis exercitam diferentes habilidades • O observador exercita a habilidade de explicar seu processo

de pensamento ao guia 65

Concentrate on task at hand (not phone)

Great if mismatch to learn

Identificando o que está errado: smells, métricas, SOFAhttp://pastebin.com/gtQ7QcHu

66

(ESaaS §9.5)

Além da Corretude• Podemos dar feedback sobre beleza de software?

• Orientações sobre o que é belo? • Avaliações qualitativas? • Avaliações quantitativas? • Se sim, quão bem eles funcionam? • E existem ferramentas para nos apoiar?

67

Qualitativo: Code Smells• CUPA (do inglês SOFA) captura sintomas que muitas vezes indicam o

"cheiro" código: • É Curto (Short)? • Ele faz apenas Uma (One) coisa? • Será que ela tem Poucos (Few) argumentos? • É um nível consistente de Abstração (Abstraction)?

• Ex: A ferramenta reek do Rails encontra "cheiro" de código68

Code smell alerts you that something may be wrong20 to 60 code smells depending on authorityCode spend several lectures on them, but just give an idea now

Methods that don’t follow this advice will often give off several of the smells

Short – depends on language (More than 1 screenful for old monitors) – try to do one thing, and quickly grasp

old terminals used to be 24 lines by 80 characters, so short fit in one screen Today windows are tremendously larger, so not a good guideline Want to look at method and quickly figure out what it is

One thing – may just call a bunch of methods do this

Único Nível de Abstração• Tarefas complexas precisam do “dividir para conquistar" • Bandeira amarela para "encapsular essa tarefa em um método" • Como uma boa notícia, as classes e métodos deve ler “de cima para baixo"!

• Bom: começar com um resumo de alto nível dos pontos-chave, em seguida, entrar em cada ponto em detalhe

• Bom: cada parágrafo lida com um tópico • Bad: divagar, saltando entre "níveis de abstração", em vez de refino

progressivamente

69

Concentrate on Abstraction since correlated and Most rapidly makes your code start to make ugly, correleates well with other smellsDivide and Conquer: Don’t have one method that does everything. Divide into understandable pieces, and have methods call others

One that orhestrates all the work

Symptom – 1 line of code says what to do, many lines of code around it saying how to do it

One of other SOFA is mulitple rguments

Por que Muitos Argumentos é Ruim?• Difícil de obter uma boa cobertura de testes • Difícil de fazer mock/stub durante o teste • Argumentos booleanos devem ser uma bandeira amarela

• Se a função se comporta de forma diferente com base no valor booleano do argumento, talvez deva ser 2 funções

• Se os argumentos "viajam em um pacote", talvez você precisa extrair uma nova classe • Mesmo conjunto de argumentos para um monte de métodos

70

If behavior really depends on lots of arguments, then lots to test

Also makes it hard to mock/stub if many args interact

Boolean – made 1 method harder to test than 2 methods

Program X & Smellstime_setterTimeSetter#self.convert calls (y + 1) twice (Duplication) .rb -- 5 warnings:

1. TimeSetter#self.convert calls (y + 1) twice (Duplication)

2. TimeSetter#self.convert has approx 6 statements (LongMethod)

3. TimeSetter#self.convert has the parameter name 'd' (UncommunicativeName)

4. TimeSetter#self.convert has the variable name 'd' (UncommunicativeName)

5. TimeSetter#self.convert has the variable name 'y' (UncommunicativeName)

71

class  TimeSetter                def  convert(d)          y  =  1980          while  (d  >  365)  do              if  (y  %  400  ==  0  ||                      (y  %  4  ==  0  &&  y  %  100  !=  0))                  if  (d  >  366)                        d  -­‐=  366                      y  +=  1                  end              else                  d  -­‐=  365                  y  +=  1              end          end          return  y      end              end

A little Ruby goes a long way; if stare at a long time and can’t figure it out, its too long

Not DRY (y+1)

Uncommunicative variables- Suppose hebrew calendar, suppose not english

Quantitativo: Complexidade ABC• Contagens de Assignments, Branches e Condições

• Branching -> :and, :case, :else, :ir, :or, :rescue, : until, :when, :while

• Pontuação = raiz quadrada (A^2 + B^2 + C^2) • NIST (National Inst Stds. & Tech...): ≤ 20 / método • Ex: Ferramenta flog do Rails verifica a complexidade ABC

72

Branching terms are :and, :case, :else, :if, :or, :rescue, :until, :when, :while. NIST – standard for gov’t contracts

Quantitativo: Complexidade Ciclomática (McCabe)• # de caminhos linearmente independentes no código = E-N+2P (edges, nodes, connected components)

• No exemplo, E=9, N=8, P=1, so CC=3

• NIST (Natl. Inst. Stds. & Tech.): ≤ 10/módulo

73

def mymeth while(...) .... end if (...) do_something end end

Ferramenta saikuro do Rails calcula a complexidade ciclomática

a graphical measurement of the number of possible paths through the normal flow of a programNode is basic blockConnected components

Also called McCabe Complexity, after the inventor

Quantitativo: Métricas

• “Hotspots”: lugares onde várias métricas levantam bandeiras vermelhas •add require 'metric_fu' to Rakefile•rake metrics:all

• Considere as métricas com um grão de sal • Como cobertura, melhor para identificar onde há oportunidade de melhoria

74

Metric Tool Target scoreCode-to-test ratio rake stats ≤ 1:2C0 (statement) coverage SimpleCov 90%+Assignment-Branch-Condition score

flog < 20 per method

Cyclomatic complexity saikuro < 10 per method (NIST)

Several tools point to difficulties than get your attention

Ano Bissexto & Quantitativo• ABC contou 23

(>20 então é um problema))

• Complexidade do código 4 (≤ 10 então não é um problema)

75

class  TimeSetter                def  convert(d)          y  =  1980          while  (d  >  365)  do              if  (y  %  400  ==  0  ||                      (y  %  4  ==  0  &&  y  %  100  !=  0))                  if  (d  >  366)                        d  -­‐=  366                      y  +=  1                  end              else                  d  -­‐=  365                  y  +=  1              end          end          return  y      end              end

Ano Bissexto Revisado & Métricasprivate def self.leap_year?(year) year % 400 == 0 || (year % 4 == 0 && year % 100 != 0) endend

• Reek: No Warnings • Flog (ABC):

• TimeSetter.convert = 11 • TimeSetter.leap_year? = 9

• Saikuro (Code Complexity) = 5

76

class TimeSetter def self.convert(day) year = 1980 while (day > 365) do if leap_year?(year) if (day >= 366) day -= 366 end else day -= 365 end year += 1 end return year end

Comentários devem descrever coisas que NÃO são óbvias a partir do código "por quê", não "o quê"

77

* This means 2 things for writing comments: * Don't just repeat what's obvious from the code * Do think about what's not obvious (low level and high level): * The units for variables, invariants * Design issues that went through your mind while you were writing the code: why the code is written this way. * Subtle problems that required a particular implementation * Abstractions: * Goal is to write classes and other code that hides complexity: easier to use than to write * Abstractions won't be obvious from implementation; comments should describe these (should be simple). * For example, what do I need to know to invoke a procedure? I shouldn't have to read the code of a procedure before calling

Bad Comments

78

// Add one to i. i++;

// Lock to protect against concurrent access.SpinLock mutex;

// This function swaps the panels. void swap_panels(Panel* p1, Panel* p2) {...}

* Most software is poorly documented * A lot of code has no comments at all * Many open source projects set a very bad example * When present, comments often not helpful * Many people think comments are a bad idea * Not useful * Out of date * Clutter the code * "Just let me read the code!"

Comments (cont)• Comentários devem ter um nível de abstração maior do que o código

79

# Scan the array to see if the symbol exists

not

# Loop through every array index, get the# third value of the list in the content to# determine if it has the symbol we are looking# for. Set the result to the symbol if we# find it.

* The biggest problem is that most people don't know how to write comments.* "My code is self-documenting" (one of the great lies) There are many other facets of writing good documentation, but this one rule will get you most of the way.

Armando agrees with Why?* Alas, can’t scale

Introdução a Behavior-Driven Design & User Stories

80

Next ChapterBeen preparing for building SaaS apps; now ready to build

Por que projetos de SW falham?• Não atendem a necessidade dos clientes

• Não é o que eles pediram/querem • Ou os projetos estão atrasados/atrasam • Ou estão acima do orçamento (custo) • Ou são difíceis de manter e evoluir • Ou todas as alternativas acima • Como o Metodologias Ágeis tentar evitar este fracasso?

81

Ciclo de Vida Ágil :: Revisão• Trabalhar em estreita colaboração, de forma contínua com as partes interessadas na

elaboração de requisitos, testes • Usuários, clientes, desenvolvedores, programadores de manutenção, operadores,

gestores de projectos... • Manter um protótipo de trabalho (funcional) durante a implantação de novos recursos a

cada iteração • Tipicamente a cada 1 ou 2 semanas • Em vez de cinco fases principais, meses de duração

• Verifique com as partes interessadas sobre o que está próximo, para garantir a construção da coisa certa (vs. verificar)

82

Behavior-Driven Design (BDD)• BDD faz perguntas sobre o comportamento da app antes e durante o

desenvolvimento, para reduzir falhas de comunicação • Validação vs. Verificação

• Requisitos escritos como histórias de usuário • Leves descrições de como a app é utilizada

• BDD concentra-se no comportamento de execução da aplicação ao invés da sua implementação • Test-Driven Design ou TDD (em breve) testa a implementação

83

User Stories• 1-3 sentenças em linguagem natural (cotidiana)

• Se encaixa em um cartão 3"x5" • Escrito por/com cliente

• Formato "connextra": • nome do recurso/característica (feature) • Como um [tipo de stakeholder], • Para que [eu possa alcançar algum objetivo], • Eu quero [fazer alguma tarefa] • As 3 frases devem estar lá, podem estar em qualquer ordem

• Ideia: histórias de usuário podem ser formuladas como testes de aceitação antes que o código seja escrito

84

Dave Patterson created this imageFrom HCI community

Por que cartão 3x5?• (a partir da comunidade de User Interface) • Nonthreatening => todos os stakeholders participam do brainstorming • Fácil de reorganizar => todos os stakeholders participam na definição

de prioridades • Como histórias devem ser curtas, fica fácil de mudar durante o

desenvolvimento • Muitas vezes temos novos insights durante o desenvolvimento

85

Diferentes stakeholders podem descrever o mesmo comportamento de formas diferentes

• Veja quais dos meus amigos estão indo para um show • Como admirador de show • Para que eu possa apreciar o show com meus amigos • Eu quero ver qual dos meus amigos do Facebook estão indo a um determinado show

• Mostrar patrono de amigos do Facebook • Como gerente de bilheteria • Para que eu possa induzir um patrono para comprar um bilhete • Eu quero mostrar-lhe qual de seus amigos do Facebook está indo para um

determinado show

86

Product Backlog• Sistemas reais tem 100s de histórias de usuário • Backlog: histórias de usuário ainda não concluídas • Priorizar os itens mais valiosos • Organizar para que eles correspondam ao SW liberado ao

longo do tempo

87

Problemas Relacionados (Related Issue)

• Spike • Investigação corriqueira em uma técnica ou problema • e.g. spike on recommendation algorithms

• Após a spike concluída, o código deve ser descartado • "Agora que sei o que utilizar, vou fazer certo!"

88

Points, Velocity, and Pivotal Tracker89

Produtividade e Ferramentas• Queremos evitar grande esforço de planejamento nas

Metodologias Ágeis? Se sim, como estimar o tempo sem um plano?

• Histórias do Usuário podem ser usadas para medir o progresso no projeto?

• O que uma ferramenta deve fazer para ajudar a medição de progresso para Metodologias Ágeis?

90

Medindo Produtividade• Uma medida de produtividade da equipe: calcular a média de

histórias/semana? • Mas algumas histórias são muito mais difíceis do que outras

• Avalie cada história de usuário com antecedência em uma escala numérica simples • 1 para histórias simples, 2 para histórias médias, 3 para histórias

muito complexas • Velocidade: número médio de pontos/semana

91

Start with this 3 point scale

Why good idea?See what you actually accomplish in points per week vs. what you guess as optimistic programmersTeams learns to get estimate difficulty of user story (gave a story 1 point but took 2 weeks; why was it hard? Learn from mistakes)

Mais sobre Pontos• Depois de ganhar a experiência, a escala Fibonnaci é uma boa sugestão: 1, 2, 3, 5,

8 • (Cada novo número é a soma dos dois anteriores) • Na Ustore, 8 é extremamente rara

• Equipes atribuem valor: voto, mantendo-se os dedos simultaneamente, tirar média • Se uma grande discordância aparece (2 e 5), tem que discutir mais sobre a

história

92

How decide points – rock, paper, scissors – everyone says how many points a story is, and see if agreeGroup says average and record so can see how well you did - rather

Mais sobre Pontos• ≥ 5 => divida a história em histórias mais simples

• backlog não muito exigente • Não importa se a velocidade é 5 ou 10 pontos por iteração

• Desde que seja consistente • A ideia é melhorar a auto-avaliação e sugerir um número de

iterações para um dado conjunto de features

93

At Ustore, break into multiple storiesEvery time there is a SW concept, some builds a tool to implement idea to make it easy to do

Pivotal Tracker• Calcula a velocidade para o time e gerencia as HU: Current, Backlog, Icebox

94

Pivotal Labs brought us Pivotal TrackerBookkeeping for user stories, as long as doing that, might as well calculate velocityUpper right corner is team velocity (10)

Very easy to useCurrentDoneBacklog (not shown) – what work on nextIcebox – invent more stories than will ever implement (frozen)Pivotal will move things from backlog to current automatically and assign people to the tasks

Top to bottom is prioritized order (except in icebox, it is random)

Pivotal Tracker• Priorizar histórias de usuários pela localização: Current, Backlog, Icebox • Quando concluído, mova para o painel Done • Pode adicionar pontos de release lógicos, assim podemos descobrir

quando um release realmente vai acontecer • pontos pendentes / velocidade

• Epic (com o próprio painel) • Combine as histórias de usuário relacionadas • Ordenadas independente das histórias do usuário no Backlog

95

Epic: give software engineers the big picture of where the application is in the development process with regard to big feature

Will put into backlog with Release Point

Tracker will estimate when Release Point looks to be

Tell customer as go along

Rastreie papéis• Desenvolvedores não decidem quando a história foi completada

• Clique no botão Finish, que a envia ao "Product Owner" (como em uma equipe Scrum)

• PO avalia a história do usuário e então decide • Aceitar, que marca história de usuário como feita, ou • Rejeitar, que marca história com a necessidade de ser

reiniciada pelo desenvolvedor96

Follow scrum roles, Product owner signs offWe use it for the book

Pivotal Tracker: Features vs. Chores• Features

• Histórias de usuários que fornecem valor de negócio verificável para o cliente • "Adicionar checkbox de concordo à página" • Pontos valiosos e, portanto, deve ser estimado

• Chores • HU que são necessárias, mas não fornecem nenhum valor óbvio diretamente ao

cliente • "Descubra porque a suíte de testes é tão lenta" • Não há pontos

97

Team Cyberspace Whiteboard• Tracker permite anexar documentos às HUs (e.g., LoFi UI) • Wiki no repositório Github • Google Drive: criação colaborativa e visualização de diagramas,

apresentações, planilhas e documentos de texto • Campfire: web-based service for password-protected online chat

rooms (http://campfirenow.com) • Telegram (http://telegram.org); Slack (http://slack.com); Google

Hangout…98

SMART User Stories 99

Criando Histórias do Usuário

• Como você sabe se você tem uma história do usuário boa ou ruim? • Tamanho certo? • Não é muito difícil? • Vale a pena?

100

SMART HU• Specific • Measurable • Achievable (idealmente, implementado em 1 iteração) • Relevant (“os 5 porque's”) • Timeboxed (saber quando desistir)

101

Specific & Measurable• Cada cenário deve ser testável

• Implica em conhecer boas entradas e existir os resultados esperados

• Anti-exemplo: "UI deve ser user-friendly" • Exemplo: Given/When/Then.

1. Dada alguma condição de partida específica(s), 2. Quando eu faço X, 3. Em seguida, uma ou mais coisas devem acontecer

102

Achievable• Completar em 1 iteração • Se não puder entregar recurso na 1 iteração, entregar

subconjunto de histórias • Sempre apontar para o código de trabalho @ final de iteração • Se <1 história por iteração, precisamos melhorar estimativa

pontual por história

103

Relevant: “business value”• Descubra o valor de negócio, ou mate a HU:

• Proteger as receitas • Aumentar a receita • Gerenciar o custo • Aumentar o valor da marca • Tornar o produto notável/reconhecido • Fornecer mais valor agregado aos seus clientes

• Um bom exemplo: http://wiki.github.com/aslakhellesoy/cucumber

104

5 "Porquê’s" para encontrar relevância• Show patron’s Facebook friends

• As a box office manager • So that I can induce a patron to buy a ticket • I want to show her which Facebook friends are going to a given show

1. Why? 2. Why? 3. Why? 4. Why? 5. Why?

105

Why add the Facebook feature? As box office manager, I think more people will go with friends and enjoy the show more.Why does it matter if they enjoy the show more? I think we will sell more tickets.Why do you want to sell more tickets? Because then the theater makes more money.Why does theater want to make more money? We want to make more money so that we don’t go out of business.Why does it matter that theater is in business next year? If not, I have no job.

5 Porquê’s para encontrar relevância1. Why add the Facebook feature? As box office manager, I think more people

will go with friends and enjoy the show more. 2. Why does it matter if they enjoy the show more? I think we will sell more

tickets. 3. Why do you want to sell more tickets? Because then the theater makes more

money. 4. Why does theater want to make more money? We want to make more money

so that we don’t go out of business. 5. Why does it matter that theater is in business next year? If not, I have no job.

106

Timeboxed• Pare a HU quando ultrapassar orçamento tempo

• Desista, divida em histórias menores ou reagende o que for deixado de lado

• Para evitar subestimar o tamanho do projeto • Pivotal Tracker rastreia a velocidade, o que ajuda a evitar

esta subestimação

107

Lo-Fi UI Sketches and Storyboards108

Construindo UI com sucesso• Apps SaaS vezes atrapalham usuários • As histórias de usuário precisam de Interfaces de Usuário (UI - User

Interface) • Como conseguir clientes para participar de projetos de UI que se

sintam felizes quando finalizado o projeto? • Evite WISBNWIW* em UI? • Versão UI de cartões 3x5?

• Como mostrar a interatividade sem a construção de protótipo?109

* What-I-Said-But-Not-What-I-Want

Projeto de UI em SaaS

• Sketches UI: lápis e papel para desenhar ou “Lo-Fi UI”

110

Lo-Fi: low fidelity

Exemplo de Lo-Fi UI

111

(Figure 4.3, Engineering Long Lasting Software by Armando Fox and David Patterson, Alpha edition,

2012.)

Storyboards

• Necessitam mostrar como a UI muda a partir de ações dos usuários

• IHC (HCI) => “storyboards” • Como cenas em um filme • Mas sem ser "linear"

112

HCI, Human-Computer Interaction

Exemplo de Storyboard para Software

113

(Figure 4.4, Engineering Long Lasting Software by Armando Fox and David Patterson, Alpha edition,

2012.)

Lo-Fi para HTML• É entediante construir sketches & storyboards,

porém mais fácil do que construir HTML! • Além disso, menos intimidador para stakeholders não-técnicos =>

incentivador à sugestão de modificações de UI se não houver código por trás

• Uma maior probabilidade de sucesso com a UI final • Próximos passos: CSS (Cascading Style Sheets)

• Melhorar a aparência depois de funcionando

114

Estimativa de Custo Ágil115

(Engineering Software as a Service §7.4)

Estimativa de Custo Ágil

• O mundo real precisa estimar o custo antes de assinar qualquer termo de compromisso de um projeto

• Se não houver um planejamento nas Metodologias Ágeis, como eu posso estimar o custo de um projeto?

116

Modelo da Ustore• A Ustore ensina Metodologias Ágeis aos clientes • Utilizando Metodologias Ágeis, a Ustore, por exemplo, nunca se

compromete a entregar as features X, Y, and Z até a data D • Ao invés disso, são comprometidos recursos para trabalhar da forma mais

eficiente possível até a data D • Clientes trabalham com o time para definir as prioridades

continuamente até a data D • Ainda assim, necessitamos de estimativas para o projeto

117

Estimativa Ágil da Ustore1. Telefonema de ~1 hora para explicar o método

• Esforço conjunto, compromisso do cliente, … 2. Visitas do cliente de ~1.5 horas para definição/entendimento do escopo

• Clientes leva designer, desenvolvedor, projetos • Qualquer coisa para clarificar o que precisa estar pronto

• Ustore leva 2 engenheiros para fazer perguntas • Identificar o que adiciona incerteza à estimativa

3. Engenheiros tomam ½ hora para estimar as semanas • Pequena vs. grande incerteza: 20-22 vs. 18-26 semanas

4. Custo da oferta como tempo e material para o cliente

118

Alguns links para o futuro…• A biblioteca do Desenvolvedor de Software dos dias de hoje • Ensinando Engenharia de Software na Prática, Parte I • Ensinando Engenharia de Software na Prática, Parte II • Computers Are The Future, But Does Everyone Need To Code? • Conselhos de um velho programador antissocial e ranzinza • Evoluindo uma Arquitetura inteiramente sobre APIs: o caso da SoundCloud • Especial: 8 sites gratuitos para aprender programação por conta própria • 12 Sites That Will Teach You Coding for Free

119

ObrigadoProf. Vinicius Cardoso Garcia

vcg@cin.ufpe.br :: @vinicius3w :: assertlab.com120