The economics of software quality

®

IBM Software Group

© 2009 IBM Corporation

The Economics of Software Quality

IBM Software Group | Rational software

2

Software é importante

Como estamos ?

As nossas dificuldades

Os impactos

Possíveis Caminhos


3

Software é importante


4

90% das inovações são baseados em sistemas eletro/eletronicos 80% dessas inovações são baseadas em software

F-22 Raptor, released in 2003, contém 1.7 milhões de linhas de código

Produtos inteligentes estão mudando o planeta ...

E o software é cada vez mais importante para esses produtos


5

Software é importante ...


6



7


Atualmente as pessoas iniciam o uso de computadores aos 6 anos

60% dos adolescentes, aos 16 anos, usam computadores

65% da população dos EUA utiliza software embarcado (smart phones, computadores, GPS, carros, ...)

100% da população dos EUA tem seus dados armazenados em algum tipo de base de dados

Produtos importantes do nosso dia-a-dia são totalmente controlados por Software

A “Internet das Coisas” revoluciona o nosso relacionamento com os produtos

A falta de qualidade em Software hoje não impacta apenas números errados informados o final do mês, como a algum tempo atrás......


8

Como estamos ?


9

Como estamos ...Dados da industria mundial de software


10

1. Finding and fixing Bugs

2. Cancelled Projects

3. Producing English Words

4. Security flaws and attacks

5. Requirements changes

6. Programming Codes

7. Customer Suport

8. Meeting and communication

9. Project Management

10. Renovation and migration

11. Innovation

12. Assembling reusable components

Onde está o esforço no desenvolvimento de software...

Cancelamentos tardios


11

1. Unstable, changing requirements (95%)

2. Inadequate quality control and poor quality measures (90%)

3. Inadequate progress tracking (85%)

4. Inadequate cost and schedule estimating (80%)

5. False promises by marketing and sales personnel (80%)

6. Rejecting good schedule estimates for arbitrary dates (75%)

7. Informal, unstructured development (70%)

8. Inexperienced clients who can't articulate requirements (60%)

9. Inexperienced project managers (50%)

10. Inadequate tools for quality/analysis, lack of inspections (55%)

11. Reusing assets filled with bugs (30%)

12. Inexperienced, unqualified software engineering teams (20%)

Porque os projetos atrasam ?


12

O grande desafio é entregar software com qualidadeA história é repleta de erros de budget, prazos e funcionalidade

“Business leaders and CIOs are under pressure to enable their teams to become catalysts for change. However, change is outpacing their ability to deliver.

They are reorienting their teams to focus on ROI and quantified business outcomes and to mitigate risk and reduce costs.”

– IBM CIO Survey, 2011

Aumentando o valor do software nos negócios

“Somente 22% dos executivos identificam ligação entre TI e os negócios”

“49% dos projetos gastam mais do que o planejado e 62% não são entregues na data combinada”

“30% do custo dos projetos de TI são gastos em re-trabalho e requisitos mal

escritos”

“50% dos projetos de TI não entregam exatamente o que foi

acordado”


13

Definição de QualidadeImportante para estabelecer o contrato entre o usuário e o desenvolvedor

1. Elegância, boa aparência

2. Capacidade de uso para vários propósitos

3. Satisfazer os requisitos do usuário

4. Menor número possível de defeitos

5. Alta eficiência das atividades de remoção de defeitos

6. Alto grau de confiabilidade

7. Fácil de aprendizagem e fácil de usar

8. Guias de uso claro

9. Acesso fácil ao suporte ao usuário

10.Rápida remoção dos defeitos reportados


14

Importante para Medir a QualidadePara estar em um contrato, os indicadores de qualidade devem ter algmas características

1. Ser previsível

2. Possível de ser medida

3. Oficial e Auditável (possível de ser provada)

4. Possível de ser melhorada

5. Ser válida para todas as entregas

6. Válida para todas as fases do processo

7. Expandida para todos os tipos de tecnologias


15

O que se procura com a QualidadeVisão de um usuário final interno

• Redução de cancelamento de projetos

• Redução de atrasos

• Redução de custos

• Satisfação do usuário

• Entregas mais rápidas

• Menor custo na manutenção

• Redução na resistência dos usuários para novas funcionalidades

• Menor custo no suporte ao usuário


16

As nossas dificuldades


17

Diminuir os custos em TI

Muitas tarefas manuais

Ambientes complexos

Times distribuídos e não conectados

Dificuldade em coordenar e comunicar

Diferença entre o status

real e o visível do projeto

Entregas distribuídas

Processos não adaptados e complexos

Prazos curtos/ time to market

Ser “Compliance”

Times pequenos

Pressão da concorrência

Faltam os objetivos

estratégicos

Porque é difícil entregar software com qualidade ?


18

Os impactos


19

Entendimento do problema

• Dificuldade em descrever os requisitos• Aprovação não formal dos requisitos• Várias versões de requisitos gerando erros funcionais

Desenvolvimento

• Falta de processos automatizados – falta de padrão• Falta de gerência das tarefas de desenvolvimento• Dificuldade de comunicação com times distribuídos

Qualidade• Projetos de testes não gerenciados• Falta escopo para testes (o que testar ?)• Montar ambientes de testes é caro e complexo

Entrega• Instalação de versão errada• Instalação da versão certa no lugar errado• Instalação da versão certa no lugar certo de maneira errada

Quais são os problemas gerados ?


20

Possíveis Caminhos


21

Possíveis Caminhos

Balancear os investimentos


22

Problemas

Qualidade baixa

Baixa previsibilidade

Atrasos

Custo alto

Retrabalho

Dificuldade em prever

Soluções

Ferramentas

Pessoas

Processos

Baixa produtividade

Caminhos para a solução Investir nos três componentes da solução


25

E geralmente as nossas prioridades são outras

Ferramentas

Processo

Pessoas


26

Várias situações geram atritos, duvidas, desmotivação, confusão, ...


27

A minha priorização hoje é:

Organiza e padroniza

Automatiza

Pessoas Processo Ferramentas


28

Possíveis Caminhos

Princípios básicos


29

Simplicidade

Padronização

Valor para o negócio

Todas ao caminhos devem ser guiados por...

Agilidade


30

Destaque para “Valor para o Negócio”

Diminuir Custos

Aumentar a Qualidade

Ganhar Mercado

Diminuir Riscos

Estratégias do negócio

Cumprir a legislação

Valor para o negócio


31

Portfolio Management

Project Management

Product Management

Performance Management

“Fazer a coisa certa”

“No tempo certo, no

prazo certo e com escopo

adequado”

“Fazer certo”

“Medir a performance

versus os objetivos do

negócio”

Destaque para “Estratégia do Negócio”

Estratégias do negócio


32

Possíveis Caminhos

Medir sempre


33

Porque investir em Produtividade ?Conhecer a si mesmo Saber onde estão os maiores gastos para priorizar as melhorias


34

Porque investir em Produtividade ?Calcular em reais os ganhos com investimentos em produtividade

R$ 0,00

R$ 2.000.000,00

R$ 4.000.000,00

R$ 6.000.000,00

R$ 8.000.000,00

R$ 10.000.000,00

R$ 12.000.000,00

R$ 14.000.000,00

R$ 16.000.000,00

Inicial Ano I Ano II Ano III

Beneficios

Investimentos


35

20

200

Re

lati

ve

Co

st

to R

ep

air

AcceptanceTest

Unit TestCodingDesignAnalysis

0

Maintenance

1-2

105

50Time not spent in requirements is time

spent in rework (at cost x200)

Stage in which Requirements Error Is Discovered

Os indicadores do mercado mostram que o ROI em solução para gerência de requisitos é muito vantajoso

Porque investir em Requisitos ?


37

Produtividade do time aumenta em até 50% Menor número de horas para as tarefas

Diminui o retrabalho

Menor consumo de máquina de produção para o desenvolvimento

Diminui o tempo da empresa em lançar novos produtos

A colaboração entre os times aumenta em até 25%* Diminui o tempo de custo de reuniões e viagens

Menor custo para resolver problemas relativo a falta de entendimento

Melhora na qualidade das entregas em 12%*

Reduz custo do defeito em produção

Reduz custo na solução dos defeitos

Melhora a satisfação do cliente final

Melhora na governança dos projetos em 12%

Evita gastos com melhor visibilidade dos projetos

Análise de Retorno de Investimento para os projetos


38


3939

© Copyright IBM Corporation 2009. All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in these materials may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. IBM, the IBM logo, Rational, the Rational logo, Telelogic, the Telelogic logo, and other IBM products and services are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others.

Learn more at:IBM Rational softwareRational launch announcementsRational Software Delivery PlatformAccelerate change & deliveryDeliver enduring qualityEnable enterprise modernization

Rational trial downloadsdeveloperWorks RationalLeading InnovationIBM Rational TVIBM Business PartnersIBM Rational Case Studies

Ensure Web security & complianceImprove project successManage architectureManage evolving requirementsSmall & midsized businessTargeted solutions

The economics of software quality

Technology

Transcript of The economics of software quality