Extreme Programming e Qualidade de Software

(1)

Extreme Programming e

Qualidade de Software

Antonio Sergio Ferreira Bonato

Departamento de Sistemas Digitais Escola Politécnica da USP

(2)

Objetivo (I)

• mostrar que o uso de um processo de desenvolvimento de software é

fundamental para a qualidade do software;

• mostrar que o CMM é um modelo de qualidade de processo que pode ser

adotado por todos, desde que se use o bom senso;

(3)

Objetivo (II)

• mostrar, através do CMM, que a

Extreme Programming é um processo de desenvolvimento de qualidade, e

portanto, produz software de qualidade; • mostrar que o uso da XP por pequenas

empresas em pequenos projetos

propicia o desenvolvimento de software de qualidade.

(4)

Qualidade de Software

• Conjunto de características a serem

satisfeitas em um determinado grau de modo que o software atenda às

necessidades do usuário.

• As características são definidas na norma ISO 9126

(5)

Total Quality Management

• Gerência da Qualidade Total

– um processo de produção de qualidade geralmente produz um produto de

qualidade;

• A Engenharia de Software tem 2 focos:

– qualidade do processo; – qualidade do produto.

(6)

Modelos de Qualidade de

Processo

• CMM • ISO 9000-3 • SPICE • Bootstrap • Trillium

(7)

Pequenas Organizações e

Pequenos Projetos

1. Os modelos de Qualidade de Processo são adequados para pequenas

empresas e pequenas organizações? 2. O CMM é adequado?

3. O CMM é eficaz no desenvolvimento de software orientado à negócios?

(8)

Respostas

1. Sim 2. Sim 3. Sim

• Desde que os modelos sejam interpretados com bom senso!

(9)

Importância das Pequenas

Organizações

• Segundo pesquisa feita com 699

empresas filiadas ao núcleo SOFTEX em 2001, o porte das organizações é:

– 36% - micro - até 10 funcionários

– 42% - pequeno - 11 a 49 funcionários

• Quer dizer, 78% são pequenas organizações.

(10)

O que elas fazem?

• Ainda segundo a mesma pesquisa:

– 88,8% desenvolvem software;

• A maioria desenvolve software

orientado a negócios. Alguns exemplos:

– administração de serviços (31,3%); – automação comercial (30,0%);

– e-business (26,5%) – web pages (29,4%)

(11)

Grau de sucesso nos projetos

• Segundo o CHAOS Report de 2000:

– 28% dos projetos de desenvolvimento de software tiveram sucesso;

– 23% falharam totalmente;

– 49% terminaram fora do prazo, acima do orçamento e com menos funcionalidades do que o previamente combinado.

(12)

Motivos de Falha

• Falta de um processo de

desenvolvimento bem definido e conhecido por todos:

– requisitos incompletos;

– falta de envolvimento do usuário; – falta de recursos;

– expectativas irreais; – falta de planejamento.

(13)

Pequenos Projetos

• Pequeno

– 3 a 5 pessoas durante 6 meses

• Muito pequeno

• Minúsculo

• Individual

(14)

Solução?

• Pequenas organizações que conduzem pequenos projetos de desenvolvimento de software devem usar um processo de desenvolvimento de qualidade;

• Este processo pode ser a Extreme Programming?

(15)

Extreme Programming

• criada a partir de um projeto piloto na DaimlerChrysler em 1996 por Kent

Back;

• conjunto de práticas e valores que

permitem ao desenvolvedor fazer o que ele faz melhor: escrever código;

• levar as melhores práticas ao extremo; • combinar estas práticas de modo que o

(16)

Os 4 valores fundamentais

• comunicação • simplicidade • feedback

(17)

12 práticas

• o jogo do planejamento • programação aos pares • testes • refactoring • design simples • propriedade coletiva • integração contínua • cliente no local • pequenos releases • semana de 40 horas • padrões de codificação • metáfora do sistema

(18)

O Jogo do Planejamento (I)

• você não sabe tudo logo no começo;

• a idéia é: fazer um plano aproximado no princípio e refiná-lo conforme as coisas se tornam mais claras;

• o planejamento ocorre com freqüência; • artefatos:

– uma pilha de cartões com as estórias dos clientes - dirigirão as iterações do projeto – um plano aproximado do próximo release;

(19)

O Jogo do Planejamento (II)

• Os desenvolvedores tomas as decisões técnicas:

– estimam o tempo para desenvolver uma estória;

– custos do uso de várias opções tecnológicas;

– organização da equipe; – o risco de cada estória;

(20)

O Jogo do Planejamento (III)

• Os clientes tomam as decisões de negócio:

– escopo (as estórias para um release e as estórias de cada iteração);

– datas dos releases;

– prioridades (quais as funcionalidades

devem ser desenvolvidas antes, baseados em valor para o negócio)

(21)

Programação aos Pares

• pares de desenvolvedores escrevem todo o código;

• improdutivo? Fowler diz: “Seria, se a

tarefa mais demorada fosse a digitação”

– todas as decisões envolvem 2 cérebros; – pelo menos duas pessoas conhecem cada

parte do sistema;

– menos chances de duas pessoas serem negligentes;

– o código é revisto por pelo menos uma pessoa.

(22)

Testes (I)

• teste de unidade

– escrito pelo desenvolvedor antes de escrever o código;

– escrever código que passe no teste;

– não pode integrar código antes de passar no teste;

(23)

Testes (II)

• teste de aceitação

– escrito pelo cliente logo após escrever a estória;

– diz se o sistema tem as funcionalidades que deveria ter;

– deve ser executado freqüentemente, para ver se nenhuma funcionalidade foi perdida na integração;

(24)

Refactoring

• atividade de melhorar o código sem mudar a funcionalidade;

• tentar simplificar o código;

• tentar implementar funcionalidades de maneira mais fácil;

• pode ser feito antes ou depois de implementar uma funcionalidade;

• leva em consideração o fato de que você aprende durante o

(25)

Design Simples

• Sempre usar o design mais simples que funcione:

– rode todos os testes;

– não tenha código duplicado; – comunique as intenções dos

programadores claramente;

– contenha o menor número possível de classes e métodos.

(26)

Propriedade Coletiva do Código

• todos podem mudar o código para melhorá-lo;

• todos são responsáveis pelo código; • quem quebra alguma coisa deve

consertá-la;

(27)

Integração Contínua

• evita os pesadelos da integração;

• integrar várias vezes ao dia - passou no teste de unidade, integra;

• facilita os teste: se parou de funcionar, então o que eu acabei de integrar deve ser o culpado;

(28)

Cliente no Local

• um cliente deve sempre estar

disponível para esclarecer estórias e tomar decisões de negócio;

• as estórias nunca contam tudo; • comunicação face-a-face;

(29)

Pequenos Releases

• os releases devem ser os menores

possíveis, e mesmo assim terem valor para o negócio;

• liberar um release o mais cedo possível;

• pequenos releases fornecem feedback concreto do cliente mais rápido.

(30)

Semana de 40 horas

• o exato número de horas não é importante;

• programadores cansados cometem mais erros;

• horas extras não são uma resposta a um problema no projeto; são apenas um sintoma de um problema maior.

(31)

Padrões de codificação

• sem padrão de codificação é difícil:

– fazer refactoring;

– trocar os pares de programadores; – ir rápido.

• serve para facilitar a comunicação; • não dever ser extenso, mas apenas

(32)

Metáfora do Sistema

• é para XP o que muitas metodologias chamam de arquitetura;

• mostra o modo como o sistema

trabalha, onde cada parte se encaixa e qual a forma que devem ter;

(33)

Quando usar XP

• melhor do que code and fix; • projetos pequenos;

• equipes pequenas - não funcionam bem com equipes grandes;

• uso de orientação a objetos;

• desenvolvedores responsáveis e motivados;

(34)

Capability Maturity Model

• um modelo de cinco níveis que prescreve prioridades de melhoria de processo para organizações que produzem software;

• testado em diversas organizações, de diversos tamanhos, pelo mundo afora;

• aceito pela comunidade de software como padrão de processos capazes de produzir software confiável e de qualidade.

(35)

Críticas ao CMM

• muito grande (aproximadamente 500 páginas);

• feito para grandes organizações e grandes projetos;

• rígido e burocrático;

• mas, se interpretado com bom senso, pode ser usado por pequenas

(36)

OS 5 níveis do CMM

• nível 1 - inicial: nenhum processo; • nível 2 - repetível: foco em

gerenciamento de projeto;

• nível 3 - definido: foco em processos de engenharia e no suporte organizacional; • nível 4 - gerenciado: foco na qualidade

dos processos e do produto;

• nível 5 - otimizado: foco na melhoria contínua do processo.

(37)

Estrutura do CMM

• 18 processos chave (KPAs),

distribuídos pelos 4 níveis superiores;

– nível 2: RM, SPP, SPTO, SSM, SQA, SCM – nível 3: OPF, OPD, TP, ISM, SPE, IC, PR – nível 4: QPM, SQM

– nível 5: DP, TCM, PCM

(38)

RM - Requirements Management

• Os objetivos da Gerência de Requisitos são:

• Objetivo 1: Os requisitos de software são

controlados para estabelecer uma baseline que será usada como base tanto para o desenvolvimento quanto para atividades de gerência.

• Objetivo 2: Os planos de desenvolvimento,

os produtos e todas as atividades são mantidos em consistência com os requisitos de software.

(39)

RM com bom senso

• Documentar os requisitos e os

compromissos assumidos, mesmo que seja em apenas uma folha de papel.

(40)

RM e XP

• estórias

• cliente no local

(41)

SPP - Software Project Planning

• Os objetivos da KPA Planejamento de

Projeto de Software são:

• Objetivo 1: As estimativas de software são documentadas para uso no planejamento e acompanhamento do projeto.

• Objetivo 2: O projeto de software tem as suas atividades e compromissos associados planejados e documentados.

• Objetivo 3: Os grupos e indivíduos que tenham alguma relação com o desenvolvimento do software conhecem os compromissos assumidos e concordam com eles.

(42)

SPP com bom senso

• Fazer um plano básico que contenha as principais atividades a serem realizadas, bem como os produtos gerados por cada uma delas. Revisar o plano conforme o projeto estiver em andamento.

(43)

SPP e XP

• jogo do planejamento

• pequenos releases

(44)

SPTO - Software Project

Tracking & Oversight

• Os objetivos da KPA Acompanhamento e

Supervisão de Projeto de Software são:

• Objetivo 1: É feito um acompanhamento do

realizado com relação ao que foi planejado.

• Objetivo 2: Quando o andamento do projeto desvia de maneira significativa do que foi planejado ações corretivas são executadas e gerenciadas até a sua conclusão efetiva.

• Objetivo 3: Eventuais mudanças de

compromissos de quaisquer natureza são negociadas e concordadas por todos os grupos afetados.

(45)

SPTO com bom senso

• Comparar o que foi feito com o que foi planejado. Atualizar o plano de maneira simples. As tarefas devem ser pacotes binários: ou terminadas ou não terminadas. Uma tarefa 87% pronta é sinal de chute.

• Se o projeto estiver saindo da linha, parar e replanejar.

(46)

SPTO e XP

• o grande gráfico visual (the big

visual chart);

• velocidade do projeto;

• estórias (compromissos);

• pequenos releases;

(47)

SSM - Software Subcontract

Management

• Os objetivos da Gerência de Subcontratação

de Software são:

• Objetivo 1: O contratante seleciona

subcontratados qualificados.

• Objetivo 2: O contratante e o subcontratado concordam quanto aos compromissos assumidos mutuamente.

• Objetivo 3: O contratante e o subcontratado mantém comunicação permanente.

(48)

SSM com bom senso

• Pequenas organizações geralmente não subcontratam.

• Se subcontratarem, escolher organizações competentes e gerenciar seu trabalho.

(49)

XP e SSM

(50)

SQA - Software Quality

Assurance

• Os objetivos da Garantia de Qualidade de

Software são:

• Objetivo 1: As atividades de SQA são planejadas.

• Objetivo 2: Os produtos e atividades em uso atendem a todos os padrões, normas e requisitos aplicáveis.

• Objetivo 3: Todos os grupos afetados são

informados das atividades do grupo de SQA e dos seus relatórios.

• Objetivo 4: Não conformidades encontradas e não resolvidas no contexto do projeto são tratadas pela gerência superior.

(51)

SQA com bom senso

• Verificar se os requisitos e os padrões estão sendo atendidos.

(52)

SQA e XP

(53)

SCM - Software Configuration

Management

• Os objetivos da Gerência de Configuração de

Software são:

• Objetivo 1: As atividades de SCM são planejadas.

• Objetivo 2: Produtos de trabalho selecionados, os itens de configuração, são identificados, controlados e tornados disponíveis.

• Objetivo 3: As mudanças dos itens de

configuração são controladas.

• Objetivo 4: Os grupos afetados e indivíduos são mantidos informados da situação e conteúdo do

(54)

SCM com bom senso

• Estabelecer baselines e controlar sua mudança.

(55)

SCM e XP

• propriedade coletiva do código (parcialmente);

• pequenos releases (parcialmente); • integração contínua (parcialmente);

(56)

OPF - Organization Process

Focus

• Os objetivos da KPA Foco no Processo

Organizacional são:

• Objetivo 1: Atividades de desenvolvimento e melhoria do processo de software são coordenadas através da organização.

• Objetivo 2: Os pontos fortes e fracos dos processos de software utilizados são identificados com relação a um processo padrão.

• Objetivo 3: Atividades de desenvolvimento e melhoria do processo de software em nível organizacional são planejadas.

(57)

OPF com bom senso

• Atribuir a responsabilidade de melhoria e manutenção do processo de desenvolvimento para alguém.

(58)

OPF e XP

• OPF é tratada pela XP no nível de equipe, e não no nível organizacional;

• a filosofia de adoção de uma prática da XP por vez implica em questões de processo organizacional.

(59)

OPD - Organization Process

Definition

• Os objetivos da KPA Definição do Processo

Organizacional são:

• Objetivo 1: Um processo de software padrão para a organização é desenvolvido e mantido.

• Objetivo 2: Informações relacionadas ao uso do processo de software padrão da organização pelos projetos de software são coletadas, revistas e tornadas disponíveis.

(60)

OPD com bom senso

• Documentar o processo de desenvolvimento de software, em alto nível e de maneira e objetiva.

(61)

OPD e XP

• a XP pode ser adotada como processo padrão, mas isso está fora do escopo da XP;

(62)

TP - Training Program

• Os objetivos do Programa de Treinamento são:

• Objetivo 1: As atividades de treinamento são planejadas.

• Objetivo 2: Treinamento para desenvolver as habilidades e o conhecimento necessários para realização de tarefas técnicas e de gerência de projeto é fornecido.

• Objetivo 3: Indivíduos do grupo de engenharia de software e grupos relacionados ao software recebem o treinamento necessário para desempenharem suas tarefas.

(63)

TP com bom senso

• Os desenvolvedores tem que dominar as técnicas que utilizam.

• O treinamento não precisa ser em sala de aula. Atividades de mentoring muitas vezes são mais eficientes.

(64)

TP e XP

• TP e XP: parcialmente tratado devido a grande quantidade de livros, sites,

(65)

ISM - Integrated Software

Management

• Os objetivos da Gerência Integrada de Software são:

• Objetivo 1: O processo de software

definido para um determinado projeto é uma versão adaptada do processo de software padrão da organização.

• Objetivo 2: O projeto é planejado e

gerenciado conforme o processo de software definido para o projeto.

(66)

ISM com bom senso

• Nem todos os projetos exigem o uso do mesmo processo. Por isso, o processo original da organização tem que poder ser adaptado para as necessidades do projeto.

(67)

ISM e XP

(68)

SPE - Software Product

Engineering

• Os objetivos da Engenharia de Produto de Software são:

• Objetivo 1: As tarefas de engenharia de

software são definidas, integradas e realizadas consistentemente para produzir software.

• Objetivo 2: Produtos de trabalho de software são mantidos consistentes uns com os outros.

(69)

SPE com bom senso

• Use sempre um processo de desenvolvimento consistente, mesmo para pequenos projetos. Não queime fases. Considere este processo quando for fazer o planejamento.

• Sempre gaste mais tempo com análise de requisitos, design e planejamento dos testes.

(70)

SPE e XP

SPE é amplamente tratada pela XP: • metáfora;

• design simples; • refactoring;

• turnê da naftalina (mothball tour); • padrões de codificação;

• testes de unidade; • testes de aceitação;

(71)

IC - Intergroup Coordination

• Os objetivos da KPA Cordenação Entre Grupos são:

• Objetivo 1: Todos os grupos afetados concordam com os requisitos do cliente.

• Objetivo 2: Todos os grupos afetados concordam com os compromissos entre os grupos de engenharia.

• Objetivo 3: Os grupos de engenharia identificam, acompanham e resolvem questões intergrupos.

(72)

IC com bom senso

• Comunique-se com seu cliente. • Registre compromissos.

(73)

IC e XP

• cliente no local;

(74)

PR - Peer Reviews

• Os objetivos das Revisões por Pares são:

• Objetivo 1: As atividades de revisão por

pares são planejadas.

• Objetivo 2: Os defeitos dos artefatos de

(75)

PR com bom senso

• Submeta sempre todo trabalho a alguma espécie de revisão.

• Inspeções geralmente são o modo mais adequado.

(76)

PR e XP

(77)

QPM - Quantitative Process

Management

• Os objetivos da Gerência Quantitativa do Processo são:

• Objetivo 1: As atividades de gerenciamento

quantitativo de processo são planejadas.

• Objetivo 2: A performance do processo definido para um projeto é controlada quantitativamente.

• Objetivo 3: A capacitação do processo de

software padrão da organização é conhecida em termos quantitativos.

(78)

QPM com bom senso

• Definir poucas métricas simples e coerentes.

• Coletá-las com disciplina.

(79)

QPM e XP

(80)

SQM - Software Quality

Management

• Os objetivos da Gerência de Qualidade de Software são:

• Objetivo 1: As atividades de gerenciamento de qualidade de software são planejadas.

• Objetivo 2: Metas mensuráveis para a qualidade do software e suas prioridades são definidas.

• Objetivo 3: O progresso verdadeiro em direção ao atingimento das metas de qualidade para os produtos de software é quantificado e gerenciado.

(81)

SQM com bom senso

• Usando-se as metas coletadas na KPA QPM, definir metas de qualidade a atingir.

(82)

SQM e XP

(83)

DP - Defect Prevention

• Os objetivos da Prevenção de Defeitos são:

• Objetivo 1: As atividades de prevenção de

defeitos são planejadas.

• Objetivo 2: As causas comuns dos defeitos

são procuradas e identificadas.

• Objetivo 3: As causas comuns dos defeitos

(84)

DP com bom senso

• Identificar as causas dos defeitos e prevenir que ocorram novamente.

(85)

DP e XP

(86)

TCM - Technology Change

Management

• Os objetivos da KPA Gerência de Mudança Tecnológica são:

• Objetivo 1: A incorporação de mudanças

tecnológicas é planejada.

• Objetivo 2: Novas tecnologias são avaliadas para se determinar seus efeitos em termos de qualidade e produtividade.

• Objetivo 3: Novas tecnologias apropriadas são transferidas para as práticas normais da organização.

(87)

TCM com bom senso

• Identificar novas tecnologias e

introduzí-las na organização de maneira ordenada.

(88)

TCM e XP

• Fazer sempre projetos piloto. • Coletar as métricas padrão da

organização.

• Medir o impacto do uso da nova tecnologias nestas métricas.

(89)

PCM - Process Change

Management

• Os objetivos da Gerência de Mudança no Processo são:

• Objetivo 1: A melhoria contínua do processo é planejada.

• Objetivo 2: Toda a organização participa das atividades de melhoria de processo de software. • Objetivo 3: O processo de software padrão da

organização e os processos de software adaptados para os projetos são melhorados continuamente.

(90)

PCM com bom senso

• Manter um programa de sugestões. • Avaliar o uso de novas práticas em

(91)

PCM e XP

(92)

Resumo

R M X X O P F X Q P M -S P P X X O P D X S Q M -S P T O X X T P -S -S M - - I S M - - D P X S Q A X S P E X X T C M -S C M X I C X X P C M -P R X X KPAs nível 2 satisfação KPAs nível 3 satisfação KPAs nível 4/5 satisfação

(93)

Conclusão

• XP tem foco nos aspectos técnicos, enquanto CMM tem foco nos aspectos gerenciais;

• no ambiente apropriado, XP trata muitas KPAs do nível 2 e 3;

• uso questionável para sistemas críticos ou de alta confiabilidade;

• XP é um processo disciplinado;

• XP e CMM podem ser considerados

complementares - CMM diz o quê; XP diz

(94)

Bibliografia (I)

• Fowler, Martin - The New Methodology - Software Development Magazine - Dezembro/2000

• Beck, Kent Extreme Programming Explained Addison Wesley -2000

• Miller, Roy W.; Collins, Christopher T. - XP Distilled - IBM DeveloperWorks - Março/2001

• Paulk, Mark C. Extreme Programming from a CMM Perspective -IEEE Software - Novembro/Dezembro 2001

• Paulk, Mark C. Using the Software CMM With Good Judgment -ASQ Software Quality Professional - Junho de 1999

(95)

Bibliografia (II)

• CMU/SEI - The Capability Maturity Model: guidelines for improving the software process - Addison Wesley - 1994 • MINISTÉRIO DA CIÊNCIA E TECNOLOGIA. Secretaria de

Política de Informática. Sociedade SOFTEX. Levantamento do Universo das Associadas SOFTEX. Brasilia. Ago 2001

• The Standish Group International. The CHAOS Report. Dennis, MA, 2000.