Contratações públicas de TI: encontro com o mercado

Gestão de contratos com métricas de resultado (serviços de software)

Xxxxxx Xxxx

Tecnologia da Informação e Telecomunicações

TRIBUNAL DE CONTAS DA UNIÃO

Secretaria-Geral de Controle-Externo

Secretaria de Fiscalização de Tecnologia da Informação

“Missão da Sefti: "Assegurar que a tecnologia da informação agregue valor ao negócio da Administração Pública Federal em beneficio da sociedade."

Roteiro da Apresentação

▪ Fracasso Total

▪ Produto Software

▪ Premissas do Contrato

▪ Escolha de Fornecedores

▪ Processo de Licitação

▪ Execução do Contrato

Fracasso Total

▪ Visão das Empresas Contratadas

▪ O valor do Ponto de Função não viabiliza a execução do

contrato;

▪ O Processo de desenvolvimento de sistemas adotado pela Petrobras é muito complexo;

▪ Excessiva quantidade de solicitação de mudança no projeto;

▪ O foco do processo estabelecido pela Petrobras é o próprio

processo e não o produto que será gerado por ele;

▪ A complexidade dos projetos não é remunerada

adequadamente.

Fracasso Total

▪ Visão da Petrobras

▪ O valor cotado pelas empresas era inexeqüível;

▪ As contratadas não implantaram um processo de gestão da qualidade

adequado;

▪ As equipes montadas pelas fábricas não tinham a experiência necessária

nos ambientes de desenvolvimento estabelecidos pela Petrobras;

▪ Não haviam recursos suficientes para atender as demandas no ritmo

necessário;

▪ Implementações diferentes do processo de desenvolvimento nas regionais

dificultavam a comunicação com as contratadas;

▪ Os instrumentos disponíveis para penalizar as fábricas pelo trabalho mau feito foram ineficientes.

▪ Não é possível trocar o parceiro sem grande ônus para Petrobras

Produto de Software

▪ Trabalho Imaterial

▪ Registro do processo

▪ Qualidade do produto

▪ Complexidade de desenvolvimento

O que você entende como SOFTWARE ?

Premissas do Contrato

▪ A Fábrica de Software é uma caixa preta;

▪ Existe apenas uma equipe de qualidade avaliando o serviço da fábrica;

▪ Existe apenas um ponto de contato para solicitar serviço da fábrica;

▪ O serviço é avaliado a partir de critérios pré- definidos e acordados com a FSW;

▪ O pagamento é calculado a partir do tamanho funcional e da complexidade de desenvolvimento.

Premissas do Contrato

Processo Iterativo Incremental

“Especificações nunca serão completamente compreendidas”

Lei de Ziv

O usuário não saberá o que ele “ quer até utilizar o sistema real (talvez nem assim)”

Lei de Xxxxxxxx

Escolha de Fornecedores

Avaliação Econômica, Financeira e Jurídica

RFI

Avaliação

Tecnica

Convite

Cadastro na Família de Contratação

Empresas Habilitadas

Critérios pré-definidos

Escolha de Fornecedores

▪ Exemplo de Informações tiradas da RFI:

▪ Usa pontos de função como métrica básica?

▪ Qual a produtividade (HS/PF)?

▪ Qual a Taxa de Entrega (PF/DU)?

▪ Quais os fatores que geram complexidade?

▪ Usa testes automatizados e integração contínua?

▪ Quantas horas como FSW Java e/ou DotNet?

Processo de Licitação

Técnico

Comercial

Reunião de Apresentação do Contrato

Menor Preço

Perguntas

2 lotes JAVA (40% e 60%)

2 lotes DotNet (40% e 60%)

Certificação (CMMI ou MPS-BR)


Declarações de Clientes de Serviços Executados

Quando enviar para FSW?

Tamanho Funcional	O tamanho funcional do software deve ser contado em pontos de função e analisados	<80	>=80 e <=500	>500
Tamanho Funcional		Desenvolvimento Interno	Fábrica de Software	Desenvolvimento Interno
Complexidade	Analisar a complexidade de desenvolvimento do software segundo os parâmetros no anexo I.	Somatório dos Pesos <= 20	Somatório dos Pesos entre 21 e 27	Somatório dos Pesos >= 28
Complexidade		Fábrica de Software	Ambos	Desenvolvimento Interno
Estabilidade dos Requisitos	Avaliar se o processo de negocio que está sendo automatizado já está consolidado. Isto influencia diretamente a estabilidade dos requisitos.	Processo de negócio mapeado e estável	Processo de negócio mapeado em estabilização	Processo de negócio não mapeado
Estabilidade dos Requisitos		Fábrica de Software	Ambos	Desenvolvimento Interno
Participação do Cliente	Verificar se a participação do cliente durante o desenvolvimento será fator decisivo para o resultado do projeto.	Não é Influenciado	O risco pode ser mitigado	Fortemente Influenciado
Participação do Cliente		Fábrica de Software	Ambos	Desenvolvimento Interno
Tolerância a Atrasos	Avaliar se o prazo é um fator critico para o sucesso do projeto	O prazo não é critico para o sucesso	O prazo pode ser revisto durante o projeto	O prazo é crítico para o sucesso
Tolerância a Atrasos		Fábrica de Software	Ambos	Desenvolvimento Interno
Abrangência do Software	Quanto maior a abrangência maior a necessidade de negociação das regras de negocio e maior a dificuldade de aprovação.	Local	Departamental	Corporativo
Abrangência do Software		Fábrica de Software	Ambos	Desenvolvimento Interno

Execução do Contrato

Código fonte funcionando;

Diagrama físico de banco de dados atualizado; Dicionário de dados atualizado;

Documento de Arquitetura atualizado;

Diagrama de classe de analise (modelo de domínio);

Definição de Requisitos

Empacota- mento da Demanda

Iteração

Desempa- cotamento do Produto

Homologação

Implantação

Documento de Visão;

Documento de Regra de Negócios; Glossário;

Documento de Produto; Diagramas de Casos de Uso; Especificações de Casos de Uso; Especificação Suplementar/ Identidade Visual.

Petrobras Petrobras e Contratada Contratada

Código fonte funcionando; Diagrama físico de banco de dados; Dicionário de dados;

Documento de Arquitetura;

Diagrama de classe de analise (modelo de domínio); Help on-line;

Testes automatizados

Execução do Contrato

Prazo e Custo Previstos pelo SCL

Prazo e Custo Previstos pela Fábrica

Reunião Final de Iteração

Teste do Software

Iteração

Reunião Inicio de Iteração

Aceitação dos Requisitos

Elicitação de Requisitos

Pré-Venda

Pagamento

da Iteração

Teste de Aceitação da Iteração

....

Repete N vezes

A Fábrica é Informada da Previsão de Demanda

Assinatura da ASP

Envio do software e da Documentação

Verificação do Software

Inspeção da Documentação

Pagamento Software verificado

Pagamento Software Homologado

Aferição dos Indicadores

Pagamento após período de garantia

Passagem de conhecimento

Verificação da Correção

Acertos no software

Correção de Erros (Garantia)

Solicitação de Correção

Homologação com o Cliente

Execução do Contrato

Até o final da

Homologação

Até o final da

Garantia

Petrobras

Petrobras e Contratada

Contratada

Cálculo do Prazo e Custo

Cálculo do Prazo

Prazo de Entrega = Tamanho Funcional do Software / Taxa de Entrega

Cálculo do Custo

Produtividade = Total de Horas Trabalhadas / Tamanho Funcional do

Software (PF)

Esforço = (Tamanho Funcional do Software + Funcionalidades Não

Mensuráveis em PF) * Produtividade

Cálculo do Prazo

Plataforma de Desenvolvimento	Taxa de Entrega usada até a 2ª (PF/Dia Útil)	Taxa de Entrega usada a partir da 2ª demanda (PF/Dia Útil)
JAVA	2,0	2,5
DotNet	2,4	2,8

Cálculo do Prazo

Exemplo:

Tamanho funcional: 200 PF

Ambiente de desenvolvimento: Java

Prazo de Entrega = 200 / 2,5 Prazo de Entrega = 80 dias úteis

Aproximadamente 110 dias corridos

Quantidade de Iterações = 110/30 4 iterações

Cálculo do Custo

Características

Adoção da arquitetura padrão

Compatibilidade com mais de um browser

Teste com vários perfis de usuário

Uso de Base de dados Integrada da PETROBRAS ou externa

Complexidade do algoritmo

Quantidade de CRUDs

Natureza do projeto

Aplicação Multi-idioma

Faixa de pesos	Produtividade (HS /PF)
8 a 10	6
11 a 14	7
15 a 19	8
20 a 27	10
28 a 35	12

Produtividade = Total de Horas Trabalhadas / (Tamanho Funcional do Software + Funcionalidades Não Mensuráveis em PF)

Cálculo do Custo

Exemplo:

Tamanho funcional: 200 PF Ambiente de desenvolvimento: Java Pontuação das Características: 15

Produtividade = 8 horas de serviço/PF Esforço = 200 * 8 = 1.600 horas de serviço

Imaginando que uma Hora de serviço corresponda a R$ 100,00, então teremos

Custo da ASP = R$ 160.000,00

Estratégia de Pagamento

Indicadores e Descontos

▪ Prazo de Entrega de Solução

TEV = Total de Erros / (PF do software / 100)

▪ Taxa de Erros Verificados

TEV = Total de Erros / (PF do software / 100)

▪ Prazo de Correção de Erros

PCE = (Quantidade de solicitações atrasadas / Quantidade total de solicitações realizadas) * 100

Ponto de Função Equivalente

Item	Base de Caçulo	Fator de Equivalência em PF
Layout de telas e arquivos: contempla alterações de layout de telas ou arquivos sem que haja alteração de funcionalidade.	Quantidade de itens alterados	0,04
Campos e Variáveis: Contempla a inclusão, alteração ou exclusão de campos e variáveis em programas e tabelas sem que tenha havido mudança na funcionalidade.	Quantidade de campos	0,08
Mensagens: Contempla alteração em mensagens de retorno para o usuário.	Quantidade de mensagens alteradas	0,04
Dados “Hard Coded”: Contempla a inclusão, alteração ou exclusão de dados pertencentes a listas (combobox ou list Box) ou tabelas físicas.	Quantidade de dados	0,04
“Code Table: Contempla a necessidade de criação, alteração ou exclusão de “Code Table” e as respectivas funcionalidades que as mantem.	Inclusão de Tabela	1,00
	Alteração de Tabela	0,50
	Exclusão de Tabela	0,30
	Inclusão de Funcionalidade	0,30
	Alteração de Funcionalidade	0,20
	Exclusão de Funcionalidade	0,10