southernscope: a solução australiana para os projetos de desenvolvimento de sistemas

www.metricas.com.br

southernSCOPE: A Solução Australiana para os Projetos de Desenvolvimento

de Sistemas

ISLIG-Rio www.bfpug.com.br/islig-rio/PMI Information Systems Local Interest Group - Rio

Mauricio Aguiar, [email protected]

www.metricas.com.br slide 2 22/11/2001

O Estado de Victoria, Australia


Histórico

O governo do Estado de Victoria, Australia, possui um orçamento anual para software da ordem de US$ 26 milhões. (Cerca de R$ 66 milhões)

É lider nacional na utilização da TI para prover serviços aos cidadãos.

Assim como outras organizações, tem enfrentado sérios problemas no desenvolvimento de software.


Histórico

Anteriormente, os preços eram fixos nas contratações de desenvolvimento.

Os fornecedores cotavam preços baixos nas licitações, a fim de ganhar o contrato, na expectativa de que o cliente solicitasse muitas alterações no decorrer do projeto.

Essas alterações eram cobradas a um preço alto, de modo a compensar o preço baixo original.


Histórico

A solução adotada foi a contratação baseada em um preço fixo por ponto de função.

Com base em uma especificação preliminar, é licitado o preço por ponto de função.

O fornecedor é escolhido com base no preço oferecido e na capacitação técnica.


Histórico

O pagamento é efetuado com base no

preço por ponto de função contratado,

no tamanho do software entregue e nas

modificações solicitadas ao longo do

projeto.


Histórico

Foi definido um processo para o

gerenciamento de projetos utilizando a

solução adotada - southernSCOPE.

O trabalho teve início em 1996, tornou-

se padrão para o Estado e foi avaliado

em 2000.

Os resultados foram considerados

positivos.


Histórico

Um pequeno número de projetos havia utilizado o método (cerca de 10).

Todos foram completados com variação máxima de 10% em relação ao orçado.

Comparativamente, os custos ficaram entre os 20% menores da indústria.

Alto nível de satisfação do usuário.

Controle do projeto nas mãos dos clientes.


Nosso Desafio

Como obter resultados Como obter resultados

semelhantes ao do Estado de semelhantes ao do Estado de

Victoria, aqui?Victoria, aqui?


Estratégia

Os projetos de software normalmente ultrapassam o orçamento.

Há diversas causas para isso.

A contratação baseada em um preço por ponto de função combate várias dessas causas.

O resultado é que os projetos são mais facilmente concluídos dentro do orçamento.


Uma História de Poucos Sucessos

Fonte: The Standish Group International, 1997 www.standishgroup.com\chaos.html

0%

20%

40%

60%

80%

100%

Small Medium Large

Companies

Failed

Problems

Success


Problemas dos Projetos

As causas mais comuns para o fracasso

dos projetos são:

– Falta de informações do usuário

– Requisitos incompletos

– Mudanças nos requisitos

– Falta de apoio gerencial

– Incompetência tecnológica

– Expectativas pouco realísticas


Minimizando os Problemas

Contratando-se software com base no southernSCOPE, pode-se reduzir ou eliminar:




– Falta de apoio gerencial

– Incompetência tecnológica



Componentes da Solução

Utilizar pontos de função.

Licitar o preço por pontos de função com

base em um documento de escopo.

Envolver um gerente de escopo

independente.

Estabelecer uma baseline.

Controlar as mudanças e o seu impacto.


O Que é um Ponto de Função?

É uma medida da funcionalidade fornecida aos usuários pelo software.

Arquivos de Interface ExternaEntrada Externa

Saída Externa

Consulta Externa

Aplicativo Sendo Considerado

Outros Aplicativos

Saída Externa

Entrada Externa

Consulta Externa

ArquivoLógicoInterno


O Que é Preço por Ponto de Função?

Da mesma forma que na construção civil o preço é fixado por metro quadrado, ele pode ser estabelecido por ponto de função.

Na construção teremos preços por M2 diferentes para pintura, colocação de piso, etc.

No desenvolvimento, o preço poderá variar segundo diversos fatores: plataforma tecnológica, linguagens utilizadas, metodologia de desenvolvimento, recursos disponíveis, etc.


O Que Contém o Documento de Escopo?

O documento de escopo deve conter uma descrição preliminar do modelo conceitual de dados e da funcionalidade abrangida pelo sistema.

Por exemplo:– Diagrama E-R preliminar

– Descrição sumária das entidades, relacionamentos e principais atributos

– DFD nível 1, ou principais casos de uso.


O Que Contém o Documento de Escopo?

O documento de escopo deve conter,

ainda:

– Objetivo do projeto

– Identificação dos envolvidos

– Ambiente técnico para o software

– Prazo almejado


O Que é um Gerente de Escopo?

É uma organização independente, experiente em mensuração de software e gerenciamento de projetos de software.– Conduz a estimativa preliminar que irá constar

do documento de escopo.

– Conduz a contagem que irá servir de baseline para o projeto.

– Analisa, mede, avalia o impacto e contabiliza as mudanças aprovadas.

– Atua como mediadora entre o cliente e o desenvolvedor, nas questões referentes ao escopo do projeto.


O Que é a Baseline?

Baseline (linha de base) é a especificação do software obtida após o detalhamento dos requisitos.

– O tamanho do software é obtido através de contagem da baseline.

– Uma vez estabelecida a baseline, as mudanças são controladas e cobradas.


O Que São Mudanças?

Mudanças são alterações solicitadas pelo cliente após o estabelecimento da baseline.

As mudanças são analisadas e medidas pelo gerente de escopo, que avalia seu impacto sobre o projeto.

Uma vez aprovadas, são contabilizadas pelo gerente de escopo.


Visão Simplificada do southernSCOPE

T am anho In ic ia l E s tim ado= 2000 P F

P reço po r P F con tra tado

T am anho In ic ia l C on tra tado= 2200 P F

P ropos ta eO rçam en to

D e ta lham entodos R equ is itos

C ons trução

E n trega 1 = 500 P F

E n trega n (fina l) =2500 P F

Gerência de Escopo

A ná lise

M ed ição A prov ação

C on tab ilização

.

.


Comparação do Desenvolvimento Típico com o southernSCOPE

INÍCIO DO PROJETO

ANÁLISE DEREQUISITOS DO

SOFTWARE

DESIGN DA ARQUITETURA

CONSTRUÇÃO

QA / TESTE DOSISTEMA

IMPLEMENTAÇÃO

Business CaseEnvolver analista

(preço fixo)Envolver desenvolvedor

Pagar preço contratadoMAIS mudanças

(chegar a um acordo?)

Controle de MudançaNEGOCIADO

Identificar necessidadeEnvolver gerente de escopo

(estimativas iniciais - tamanho, custo, prazo)Documento de Escopo do ProjetoEnvolver desenvolvedor

($$ por ponto de função) Especificação de Requisitos

Contagem de Pontos de Função Baseline

Controle de Mudança MEDIDO

(Gerente de Escopo)

Pagar o preço do software entregue MAIS mudanças documentadas

Típico (preço fixo) southernSCOPE


Soluções

Como os Problemas São Como os Problemas São

ResolvidosResolvidos


Risco Tecnológico Minimizado

Os desenvolvedores

estabelecem seu preço

por ponto de função

para a tecnologia

especificada.

Os desenvolvedores estabelecem seu preço

a partir de sua capacidade técnica, o que

minimiza a incompetência tecnológica


Expectativas Mais Realísticas

A contagem de pontos de função requer

uma especificação mais detalhada, o

que minimiza:



A ligação direta entre a funcionalidade e

o orçamento minimiza:



Gerenciamento das Mudanças

A abordagem southernSCOPE inclui

procedimentos para a monitoração das

mudanças, o que ajuda a minimizar:


De uma forma geral, os clientes

entendem que a utilização do preço por

ponto de função facilita o controle das

mudanças.


Conclusões

Utilizando-se o método tradicional de

preço fixo, o projeto...

– Provavelmente ultrapassará o orçamento

– Produzirá resultados difíceis de medir

Com o southernSCOPE...

– O orçamento provavelmente será respeitado

– Os resultados serão facilmente mensuráveis

(em pontos de função)


Mais Informações

Com Mauricio Aguiar (IFPUG / BFPUG)

– [email protected]

Com Terry Wright (Governo de Victoria)

– [email protected]

Na Internet– www.go.vic.gov.au/sthnscope.htm (inglês)

– www.bfpug.com.br/islig-rio/ (português, em construção)

Esta palestra: na Seção “Artigos”


Mauricio Aguiar, CFPS

Presidente do BFPUG

Diretor do IFPUG

ti MÉ[email protected]

www.metricas.com.br

southernscope: a solução australiana para os projetos de desenvolvimento de sistemas

Documents