PRECIFICAÇÃO DE CONTRATOS DE FÁBRICA DE SOFTWARE POR PONTOS DE FUNÇÃO E NÃO POR ESFORÇO
PRECIFICAÇÃO DE CONTRATOS DE FÁBRICA DE SOFTWARE POR PONTOS DE FUNÇÃO E NÃO POR ESFORÇO
XXXXXXXXX XXXXXXX XX XXXXX XXXXX0 XXXXXXX XX XXXXX XXXXXXXX0
Resumo: A legislação e as Instruções Normativas respaldam a contratação de serviço de Tecnologia da Informação e Comunicação no âmbito da Administração Pública Federal. Contudo, algumas ponderações precisam ser levantadas para responder se os contratos atendem ou não a contento à necessidades dos órgãos contratantes. Esse referido trabalho aborda a questão da métrica de Ponto de Função que mede o tamanho dos requisitos funcionais, mas não mensura o esforço empreendido por parte da contratada. Também levantou-se que existem alguns tipos de contratos, mas que a complexidade dos mesmos inviabilizam a utilização por órgãos públicos e contratadas. Os modelos dos contratos celebrados entre a administração pública e as empresas vencedoras, encaixam-se como preço, prazo e escopo fixo, que segundo a literatura, não é bom nem para o contratante e nem para a contratada.
PALAVRAS-CHAVE: Fábrica de Software, Métrica, Ponto de Função.
1. Introdução
A legislação e as Instruções Normativas (IN) permitem que a Administração Pública federal contrate atividades meios para prestação de serviço, uma dessas atividades são contratos de Tecnologia da Informação e Comunicação (TIC). Um dos objetos de contrato é o desenvolvimento e manutenção de software, que é feito por meio de contratação de Fábrica de Software.
A literatura aborda alguns tipos de contratos para desenvolvimento de software. Xxxxx (2013) aborda a referida problemática de contratos no âmbito da Administração Pública Federal, e reforça que “para cumprir limites de preço e escopo, os fornecedores, muitas vezes, são levados a degradar o resultado”, ou seja, a qualidade do produto é alterada.
1 Graduado em Análise e Desenvolvimento de Sistemas pela Universidade do Estado do Amazonas – UEA, Cursando Mestrando Profissionalem Engenharia de Software pelo instituto CESAR, servidor público federal (SUFRAMA) e fiscal técnico de contrato de fábrica de software.
2 Bacharel em Ciência da COmputação, Cursando Mestrando Profissionalem Engenharia de Software pelo instituto CESAR, servidor público federal (SUFRAMA) e fiscal técnico de contrato de fábrica de software.
Busca-se respostas para a questão dos contratos que geralmente tem escopo, preço e prazo fixos, mas o plano e o cronograma são difíceis de serem seguidos. As variáveis fixas tendem a comprometer a qualidade do produto, que é a única que não pode ser mutável.
Este artigo tem como objetivo fazer um levantamento dos contratos abordados na literatura e averiguar se os mesmos podem ser utilizados em contratos celebrados entre órgãos da administração pública e prestadoras de serviços de Fábrica de Software.
Outro objeto desse referido estudo é quanto a questão da mensuração de pagamento por meio da métrica de Ponto de Função, uma vez que o Ponto de Função mede o tamanho do software e não propriamente o esforço empreendido pela contratada. Portanto, além dessa seção introdutória, este artigo está dividido em seção 2 - Revisão de Literatura; Seção 3 - Levantamento e Seção 4 - Conclusão.
2. Métrica de Software
Segundo Pressman (2016) define métricas como "uma medida quantitativa do grau em que um sistema, componente ou processo possui um determinado atributo". O objetivo das métricas de software é controlar e identificar eficientemente os parâmetros essenciais que afetam o desenvolvimento de software Almeida, Monteiro e Furtado (2018) .
O objetivo da métrica é identificar os parâmetros determinantes que afetam o desenvolvimento, dessa forma, é possível traçar uma forma de mensuração para quantificar o tamanho funcional e com isso definir um preço a ser pago. No Âmbito da administração pública federal a métrica é uma forma para mensurar o tamanho funcional que será contratado e pago
Almeida, Monteiro e Furtado (2018) salientam que métricas de software podem ser usadas para obter amplas variedades de informações sobre qualidade do produto, tamanho funcional e estimativa de custo. Ainda Xxxxxxx, Xxxxxxxx e Furtado (2018), as medições precisam ser monitoradas, cujo objetivo é garantir que as mudanças não impactem no resultado do produto.
As métricas de software referem-se a uma grande variedade de medidas e é hoje algo muito comum, embora a engenharia de software está longe de ter uma medição padrão amplamente aceita e com resultados que não contenham em seu âmbito nenhum fator subjetivo. A métrica é a medida do atributo de alguma entidade, no caso deste documento, será tratada a métrica de software, que é a medida de alguma propriedade do software.
Conforme AUTOR acima, existem muitas formas de métricas que podem ser utilizadas para inúmeros objetivos. Sommerville (2011).
Uma métrica de software é uma característica de um sistema de software, documentação de sistema ou processo de desenvolvimento que pode ser objetivamente medido. Exemplos de métricas incluem: o tamanho de um produto em linhas de código; o índice Fog (GUNNING, 1962), que e uma medida da legibilidade de uma passagem de texto escrito; o número de
defeitos relatados em um produto de software entregue, e o número de pessoas/dia requerido para desenvolver um componente de sistema.
No âmbito da administração pública Russo et al (2018) aborda dois tipos de métricas no qual os denomina de modelos: Contracts with Function Points e Contracts with Scrum Sprints. O primeiro, proporciona objetividade no processo de avaliação, pois mensura o tamanho da funcionalidade. Já o segundo, o valor econômico não é determinado FPA, mas sim pelas iterações de desenvolvimento. No que tange a qualidade, o FPA computa se o software computa uma certo número de funcionalidades. Já o segundo, funciona como um processo do Scrum.
2.1 Contratos de Software
Laakkonen (2014) lista os seguintes tipos de contratos: Fixed price agile, Time and materials in agile, Target-cost and agile, Fixed price per unit of work. Book et. al (2016) complementa com os seguintes modelos: Fixed Price per Iteration, Fixed Price per (Whatever) Point, Money for Nothing, Change for Free, Shared Pain/Shared Gain, Multi-stage Contract Models.
Xxxxx et al (2018) elenca as seguintes possibilidades de contratos: “fixed price, fixed scope, fixed time; fixed price, fixed time, negotiable scope; paying for effort as it gets spent. If the requirements are volatile and there is mutual trust among producer and consumer this is the best situation; max price with payment on incremental acceptance; incremental delivery with payment on incremental acceptance price for each unit delivered, for instance a fixed fee for function point; base fee for each unit delivered, plus a low fee per hour, in order to incentive developers to early delivery”.
Para Xxxxxxxxx os contratos de preço, escopo e prazo fixos não são ideias para o fornecedor nem para o cliente, pois geralmente os projetos dificilmente seguem o plano e o cronograma. Entretanto, alguns clientes preferem esse tipo de contrato, principalmente os clientes relacionados a governo.
2.1.2 Preço Fixo e escopo fixo (PFEF)
Conforme Uchoa (2013) “o contrato PFEF define um preço total fixo para um produto definido, serviço ou resultado a ser fornecido”. Para Xxxxxx e Vodde (2010), contratos e projetos de preço fixo – que com frequência também apresentam escopo fixo e, pior, duração fixa – devem ser evitados.
A ponderação feita por Xxxxxx e Vodde (2010) se dá pelo fato de que os projetos são contratados com escopo, preço e prazos fixos, mas geralmente o plano e o cronograma do projeto não são estáticos, ou seja, caso hajam mudanças em uma das variáveis, deixará de ser fixo, isso influenciará no resultado do produto, pois é a única coisa que é imutável no projeto, que é qualidade do produto.
Desta forma Uchoa (2013) alerta que “para cumprir limites de preço e escopo, os fornecedores, muitas vezes, são levados a degradar o resultado geral do trabalho reduzindo a qualidade do código, eliminando testes, e assim por diante”.
A ideia de Xxxxx (2013) reforça que quando uma das variáveis do projeto é mudada e/ou estendida, o resultado final é alterado.
2.2.2 Contrato por Sprint (CS)
Em alguns órgãos da Administração Pública se faz contrato de preço, escopo e tempo fixos, mas se exige entregas por Sprints que é um dos princípios do Scrum. Segundo Xxxxxxxxx (2013) apud Uchoa 2013 “neste tipo de contratação o pagamento de cada Sprint deve ter um preço fixo e deve ser calculado de acordo com a velocidade de trabalho da equipe se as metas forem alcançadas”.
No âmbito da Administração Pública, os contratos de Tecnologia da Informação seguem a Instrução Normativa 01/2019. Logo, a Sprint é uma adaptação do Scrum, é utilizado, pois facilita a quebra dos projetos em etapas menores.
Segundo Xxxxxxxxx 2013 apud Uchoa 2013 “neste tipo de contratação o pagamento de cada Sprint deve ter um preço fixo e deve ser calculado de acordo com a velocidade de trabalho da equipe se as metas forem alcançadas”. Apesar de os órgãos públicos não terem esse tipo de contrato, mas é uma das formas de se utilizar esse mecanismo, pois os projetos de software são divididos em iterações.
2.2.3 Pontos de Função
A métrica de Ponto de Função PF, é uma técnica que mede o tamanho da funcionalidade do software. No âmbito da Administração Pública Federal, os órgãos que utilizam essa métrica. Xxxxxxx Xxxxxxx, Xxxxxxxx e Furtado (2018) conceitua PF.
“Análise de Ponto de Função, ou métrica PF,é uma técnica de medição do tamanho funcional de um software.Essas funções são operações extraídas dos requisitos funcionais gerados a partir da visão do usuário. A partir dessa medição é possível estimar o esforço para implementação do sistema utilizando Ponto de Função que é a unidade de medida desta técnica”.
Segundo Uchôa (2013) “O ponto de função é uma métrica de tamanho funcional de projetos de software (SLTI/MPOG, 2012) que possibilita a estimativa do esforço e do prazo requeridos para o desenvolvimento de um sistema”. O PF possibilita mensurar o tamanho da funcionalidade funcional do software, não necessariamente o esforço empreendido.
Ainda Xxxxx (2013) “O TCU sugere que se considere medida de pontos de função na definição do método para quantificar os volumes de serviços a demandar ao longo dos contratos”. A métrica de PF não mensura o esforço empreendido pela Fábrica de Software, mas permite aos fiscais técnicos de contratos e auditores um melhor controle das demandas.
3. Desenvolvimento
A IN 01/2019 que “Dispõe sobre o processo de contratação de soluções de Tecnologia da Informação e Comunicação - TIC pelos órgãos e entidades
integrantes do Sistema de Administração dos Recursos de Tecnologia da Informação - SISP do Poder Executivo Federal”, o artigo 8 desta referida IN, estabelece que o processo de contratação de TIC siga as respectivas fases, conforme a Figura 1.
Figura 1: Processo de Contratação de Solução de TIC - IN 01/2019
A Figura 1 ilustra os macroprocessos a serem seguidos no processo de contratação de uma solução de TIC, dentre as quais a fábrica de software faz parte desse serviço.
A elaboração do Termo de Referência ou Projeto Básico se dá na fase de planejamento da contratação, nesse artefato são listados os pré requisitos que nortearão o contrato da empresa vencedora do processo licitatório. A nomenclatura Termo de Referência vem do Decreto 3.555/2000 Art. 8.
“I - o termo de referência é o documento que deverá conter elementos capazes de propiciar a avaliação do custo pela Administração, diante de orçamento detalhado, considerando preços praticados no mercado, considerando preços praticados no mercado, a definição dos métodos, a estratégia de suprimento e o prazo de execução do contrato”.
No Termo de Referência é especificado o objeto do contrato e como o mesmo deverá ser executado. No que tange a contratos de Fábrica de Software, os requisitos definidos neste artefato (TR) subsidiam o futuro contrato.
Ressalta-se que no TR já vem especificado o valor total de Pontos de Função a serem utilizados, assim como o valor em real específico por cada PF. Ressalta- se que a administração Pública paga pelo valor da funcionalidade e não pelo esforço feito para desenvolvê-la, conforme colocado por Xxxxxxx e Furtado (2018).
4. Conclusão
A legislação e as instruções normativas permitem a contratação de serviço meio no âmbito da Administração Pública, a Fábrica de Software é um desses serviços são contratados para desenvolver e manter os software existentes.
Este trabalho fez um levantamento de contratos de fábrica de software cujo pagamento é feito mediante ao tamanho da funcionalidade desenvolvida, nesse caso não se leva em consideração o esforço empreendido pela empresa. Também foram levantados alguns tipos de contratos abordados na literatura, mas que não se utiliza no âmbito público.
Identificou-se que no âmbito da da administração pública, utiliza-se contratos de preço, escopo e prazo fixos. Portanto, esses modelos não é a melhor alternativa, pois o plano e cronograma do projeto são mutáveis o que pode afetar a qualidade do produto. Logo, precisa de modelos de acordo com a legislação vigente, mas que as variáveis sejam flexíveis, de modo que a qualidade seja imutável.
5.Referências
XXXXXXX, X. X. XXXXXXXX, XXXXXXX, XXXXXX. Análise sobre métricas nos contratos de fábricas de software no âmbito da administração pública federal. Rio de Janeiro: Albatroz, 2019.
CONTRATAÇÃO DE DESENVOLVIMENTO ÁGIL DE SOFTWARE PELO
GOVERNO Xxxxxxxxx Xxxxxxx Xxxxx.
Xxxxxxxxx Xxxxxxx Xxxxx. CONTRATAÇÃO DE DESENVOLVIMENTO ÁGIL DE SOFTWARE PELO GOVERNO. Dissertação (Mestrado) - UFRJ/ COPPE/ Programa de Engenharia de Sistemas e Computação, 2013.
XXXXXX, Xxxxx; XXXXX, Bas. Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum. [S.l.]: Addison-Wesley Professional, 2010.
IN01. Ministério da Economia/Secretaria Especial de Desburocratização, Gestão e Governo Digital/Secretaria de Governo Digital. <xxxxx://xxx.xx.xxx.xx/xxxxxxx/-
/asset_publisher/Kujrw0TZC2Mb/content/id/70267659/do1-2019-04-05-instrucao- normativa-n-1-de-4-de-abril-de-2019-70267535>.
Xxxxxxxxx, Xxxxxxxxx. Contracts in Agile Software Development. Degree Programme of Computer Science and Engineering 2014.
Xxxxx, Xxxxxx, Xxxxxxxx Xxxxxxxx, Xxxxx Xxxxxxxxxx. Contracting Agile Developments for Mission Critical Systems in the Public Sector. 2018 ACM/IEEE 40th International Conference on Software Engineering: Software Engineering in Society.
DECRETO Nº 3.555, DE 8 DE AGOSTO DE 2000.
<xxxx://xxx.xxxxxxxx.xxx.xx/xxxxxx_00/xxxxxxx/x0000.xxx>.
Xxxx, Xxxxxxxx, Xxxxx, Xxxxxx, Xxxxxxxx, Xxxxxxx. Tamed Agility,Agile Contract Models. Pragmatic Contracting and Collaboration in Agile Software Projects 2016.
SOMMERVILLE, I. Software Engineering (Vol. 9). Xxxxxxx, 2011.
Xxxxxxxx, X. X. (2016). Software engineering : a practitioner’s approach. 9aed. New York: Higher Education.