EDITAL

TRIBUNAL DE CONTAS DA UNIÃO

Secretaria de Licitações, Contratos e Patrimônio - Selip Diretoria de Licitações - Dilic

TC: 031.871/2017-8

EDITAL

Pregão Eletrônico nº 046/2018			Data de Abertura: 9/7/2018 às 14:00 no sítio xxx.xxxxxxxxxxxxxxxxxxxxx.xxx.xx
Objeto
CONTRATAÇÃO DE SERVIÇOS DE PROJETO E MANUTENÇÃO DE SOFTWARE COM PRÁTICAS ÁGEIS
Valor Total Estimado
R$ 30.904.803,84 (TRINTA MILHÕES NOVECENTOS E QUATRO MIL OITOCENTOS E TRÊS REAIS E OITENTA E QUATRO CENTAVOS)
Registro de Preços?	Vistoria	Instrumento Contratual	Forma de Adjudicação
SIM	NÃO SE EXIGE	TERMO DE CONTRATO	GLOBAL
DOCUMENTOS DE HABILITAÇÃO (VEJA SEÇÃO XIII)*
Requisitos Básicos: - Sicaf ou documentos equivalentes - Certidão do Conselho Nacional de Justiça(CNJ) - Certidão do Portal da Transparência - Certidão Negativa de Débitos Trabalhistas(TST) - Índices de Liquidez (LG, LC, SG) superiores a 1 - CCL não inferior a Xx0.000.000,00 - XX não inferior a R$3.090.480,38 - PL não inferior a 1/12 da declaração decontratos			Requisitos Específicos: - Comprovação de, no mínimo, três anos de experiência.

* O detalhamento dos documentos/requisitos de habilitação deve ser consultado na seção do instrumento convocatório acima indicada.

Lic. Exclusiva ME/EPP?	Reserv. Cota ME/EPP?	Exige Amostra/Dem.?	Dec. nº 7.174/2010?
NÃO	NÃO	NÃO	SIM
Prazo para envio da proposta/documentação
Até 24 horas após a convocação realizada pelo pregoeiro.
Pedidos de Esclarecimentos		Impugnações
Até 4/7/2018 para o endereço xxx@xxx.xxx.xx		Até 5/7/2018 para o endereço xxx@xxx.xxx.xx

-

Observações Gerais

Relação dos Itens

Descrição	Exclusiva ME/EPP?	Cota ME/EPP?	Amostra/ Demonst.?	Decreto 7.174?	Valor Estimado
Grupo 1 - Contratação de Serviços de Projeto e Manutenção de Software com práticas ágeis	Não	Não	Não	Sim	30.904.803,84

Acompanhe as sessões públicas dos Pregões do TCU pelo endereço xxx.xxxxxxxxxxxxxxxxxxxxx.xxx.xx, selecionando as opções Consultas > Pregões > Em andamento > Cód. UASG “30001”. O edital e outros anexos estão disponíveis para download no Comprasnet e também no endereço xxx.xxx.xxx.xx, opção Licitações e contratos do TCU.

TRIBUNAL DE CONTAS DA UNIÃO SECRETARIA DE LICITAÇÕES, CONTRATOS E PATRIMÔNIO

DIRETORIA DE LICITAÇÕES

EDITAL DO PREGÃO ELETRÔNICO N.º 046/2018 REGISTRO DE PREÇOS

O Tribunal de Contas da União - TCU e este Pregoeiro, designado pela Portaria- Segedam N.º 1, de 2 de janeiro de 2018, levam ao conhecimento dos interessados que, na forma da Lei n.º 10.520/2002, dos Decretos n.º 7.892/2013 e n.º 5.450/2005, da Lei Complementar n.º 123/2006 e, subsidiariamente, da Lei n.º 8.666/1993 e de outras normas aplicáveis ao objeto deste certame, farão realizar licitação na modalidade Pregão Eletrônico mediante as condições estabelecidas neste Edital.

DA SESSÃO PÚBLICA DO PREGÃO ELETRÔNICO:

DIA: 09 de julho de 2018

HORÁRIO: 14h (horário de Brasília/DF)

ENDEREÇO ELETRÔNICO: xxx.xxxxxxxxxxxxxxxxxxxxx.xxx.xx

CÓDIGO UASG: 30001

SEÇÃO I – DO OBJETO

1. A presente licitação tem como objeto a prestação presencial de serviços de projeto e de manutenção de software com práticas ágeis, conforme especificações técnicas constantes deste Edital, para o Tribunal de Contas da União (TCU) e para o Ministério da Transparência e Controladoria-Geral da União (CGU), conforme quadro abaixo:

GRUPO 1	Itens	Perfil do Posto de Trabalho	Qtd	Orgão	Turno / Carga Horária	Valor unitário mensal (R$)	Valor unitário anual (R$)	Valor total anual (R$)	Valor total para 24 meses (R$)
	1	Analista	43	TCU	Diurno	19.064,63	228.775,56	9.837.349,00	00.000.000,16
		Programador Java nível Sênior			(8h)
			9	CGU	Diurno (8h)	19.064,63	228.775,56	2.058.980,04	4.117.960,08
	2	Analista	15	TCU	Diurno	14.111,40	169.336,80	2.540.052,00	5.080.104,00
		Programador Java nível			(8h)
			6	CGU	Diurno	14.111,40	169.336,80	1.016.020,80	2.032.041,60
		Pleno			(8h)
	Total (R$)								30.904.803,84

1.1. Em caso de discordância existente entre as especificações deste objeto descritas no Comprasnet e as especificações constantes deste Edital, prevalecerão as últimas.

SEÇÃO II – DA DESPESA E DOS RECURSOS ORÇAMENTÁRIOS

2. A despesa com a execução do objeto desta licitação para o Tribunal de Contas da União (Órgão Gerenciador) é estimada em R$ 24.754.802,16 (vinte e quatro milhões setecentos e cinquenta e quatro mil oitocentos e dois reais e dezesseis centavos) e para o Ministério da Transparência e Controladoria-Geral da União é estimada em R$ 6.150.001,68 (seis milhões cento e cinquenta mil e um real e sessenta e oito centavos), conforme o orçamentoanexo.

SEÇÃO III – DA PARTICIPAÇÃO NA LICITAÇÃO

3. Poderão participar deste Pregão os interessados que estiverem previamente credenciados no Sistema de Cadastramento Unificado de Fornecedores - Sicaf e perante o sistema eletrônico provido pela Secretaria de Logística e Tecnologia da Informação do Ministério do Planejamento, Orçamento e Gestão (SLTI), por meio do sítio xxx.xxxxxxxxxxxxxxxxxxxxx.xxx.xx.

3.1. Para ter acesso ao sistema eletrônico, os interessados em participar deste Pregão deverão dispor de chave de identificação e senha pessoal, obtidas junto à SLTI, onde também deverão informar-se a respeito do seu funcionamento e regulamento e receber instruções detalhadas para sua correta utilização.

3.2. O uso da senha de acesso pela licitante é de sua responsabilidade exclusiva, incluindo qualquer transação por ele efetuada diretamente, ou por seu representante, não cabendo ao provedor do sistema ou ao TCU responsabilidade por eventuais danos decorrentes do uso indevido da senha, ainda que por terceiros.

4. Não poderão participar deste Pregão:

4.1. empresário suspenso de participar de licitação e impedido de contratar com o TCU, durante o prazo da sanção aplicada;

4.2. empresário declarado inidôneo para licitar ou contratar com a Administração Pública, enquanto perdurarem os motivos determinantes da punição ou até que seja promovida sua reabilitação;

4.3. empresário impedido de licitar e contratar com a União, durante o prazo da sanção aplicada;

4.4. empresário proibido de contratar com o Poder Público, em razão do disposto no art.72, § 8º, V, da Lei n.º 9.605/98;

4.5. empresário proibido de contratar com o Poder Público, nos termos do art. 12 da Lei n.º 8.429/92;

4.6. quaisquer interessados enquadrados nas vedações previstas no art. 9º da Lei n.º 8.666/93;

4.6.1. Entende-se por “participação indireta” a que alude o art. 9º da Lei n.º 8.666/93 a participação no certame de empresa em que uma das pessoas listadas no mencionado dispositivo legal figure como sócia, pouco importando o seu conhecimento técnico acerca do objeto da licitação ou mesmo a atuação no processo licitatório.

4.7. sociedade estrangeira não autorizada a funcionar no País;

4.8. empresário cujo estatuto ou contrato social não seja pertinente e compatível com o objeto deste Pregão;

4.9. empresário que se encontre em processo de dissolução, recuperação judicial, recuperação extrajudicial, falência, concordata, fusão, cisão, ouincorporação;

4.10. sociedades integrantes de um mesmo grupo econômico, assim entendidas aquelas que tenham diretores, sócios ou representantes legais comuns, ou que utilizem recursos materiais, tecnológicos ou humanos em comum, exceto se demonstrado que não agem representando interesse econômico em comum;

4.11. consórcio de empresa, qualquer que seja sua forma de constituição;

4.12. cooperativa de mão de obra, conforme disposto no art. 5 da Lei n.º 12.690, de 19 de julho de 2012.

5. Considerando tratar-se de contratação de serviços mediante cessão de mão de obra, conforme previsto no art. 31 da Lei nº 8.212, de 24/07/1991 e alterações e nos artigos 112, 115,

117 e 118, da Instrução Normativa – RFB nº 971, de 13/11/2009 e alterações, licitante Microempresa - ME ou Empresa de Pequeno Porte – EPP optante pelo Simples Nacional, que, porventura venha a ser contratada, não poderá se beneficiar da condição de optante e estará sujeita à retenção na fonte de tributos e contribuições sociais, na forma da legislação em vigor, em decorrência da sua exclusão obrigatória do Simples Nacional a contar do mês seguinte ao da contratação em consequência do que dispõem o artigos 17, inciso XII, 30, inciso II e 31, inciso II, da Lei Complementar nº 123, de 14 de dezembro de 2006 ealterações.

5.1. A licitante optante pelo Simples Nacional, que, porventura venha a ser contratada, após a assinatura do contrato, no prazo de 90 (noventa) dias, deverá apresentar cópia dos ofícios, com comprovantes de entrega e recebimento, comunicando a assinatura do contrato de prestação de serviços mediante cessão de mão de obra (situação que gera vedação à opção por tal regime tributário) às respectivas Secretarias Federal, Estadual, Distrital e/ou Municipal, no prazo previsto no inciso II do § 1º do artigo 30 da Lei Complementar nº 123, de 14 de dezembro de 2006 e alterações.

5.2. Caso a licitante optante pelo Simples Nacional não efetue a comunicação no prazo assinalado acima, o próprio Tribunal de Contas da União – TCU, em obediência ao princípio da probidade administrativa, efetuará a comunicação à Secretaria da Receita Federal do Brasil – RFB, para que esta efetue a exclusão de ofício, conforme disposto no inciso I do artigo 29 da Lei Complementar nº 123, de 14 de dezembro de 2006 e alterações.

5.3. A vedação de realizar cessão ou locação de mão de obra não se aplica às atividades de que trata o art. 18, § 5º-C, da Lei Complementar nº 123, de 14 de

dezembro de 2006 e alterações, conforme dispõe o art. 18, § 5º-H, da mesma Lei Complementar, desde que não exercidas cumulativamente com atividades vedadas.

SEÇÃO IV – DA VISTORIA

6. Não se exigirá que a licitante realize vistoria do local da prestação dos serviços.

SEÇÃO V – DA PROPOSTA

7. A licitante deverá encaminhar proposta, exclusivamente por meio do sistema eletrônico, até a data e horário marcados para abertura da sessão, quando então encerrar-se-á automaticamente a fase de recebimento de propostas.

7.1. A licitante deverá consignar, na forma expressa no sistema eletrônico, o valor global da proposta, já considerados e inclusos todos os tributos, fretes, tarifas e demais despesas decorrentes da execução do objeto.

7.2. A licitante deverá declarar, em campo próprio do sistema eletrônico, que cumpre plenamente os requisitos de habilitação e que sua proposta está em conformidade com as exigências do Edital.

7.3. A licitante deverá declarar, em campo próprio do Sistema, sob pena de inabilitação, que não emprega menores de dezoito anos em trabalho noturno, perigoso ou insalubre, nem menores de dezesseis anos em qualquer trabalho, salvo na condição de aprendiz, a partir dos quatorze anos.

7.4. A licitante enquadrada como microempresa ou empresa de pequeno porte deverá declarar, em campo próprio do Sistema, que atende aos requisitos do art. 3º da LC n.º 123/2006, para fazer jus aos benefícios previstos nessa lei.

7.5. A licitante apta ao exercício do direito de preferência estabelecido no Decreto n.º 7.174/2010 deverá declarar, em campo próprio do Sistema, que atende aos requisitos previstos na legislação.

7.6. A declaração falsa relativa ao cumprimento dos requisitos de habilitação, à conformidade da proposta ou ao enquadramento como microempresa ou empresa de pequeno porte ou ao direito de preferência sujeitará a licitante às sanções previstas neste Edital.

8. As propostas ficarão disponíveis no sistema eletrônico.

8.1. Qualquer elemento que possa identificar a licitante importa desclassificação da proposta, sem prejuízo das sanções previstas nesse Edital.

8.2. Até a abertura da sessão, a licitante poderá retirar ou substituir a proposta anteriormente encaminhada.

8.3. O Pregoeiro deverá suspender a sessão pública do Pregão quando constatar que a avaliação da conformidade das propostas, de que trata o art. 22, § 2º, do Decreto n.º 5.450/2005, irá perdurar por mais de um dia.

8.3.1. Após a suspensão da sessão pública, o Pregoeiro enviará, via chat, mensagens às licitantes informando a data e o horário previstos para o início da oferta de lances.

9. As propostas terão validade de 60 (sessenta) dias, contados da data de abertura da sessão pública estabelecida no preâmbulo deste Edital.

9.1. Decorrido o prazo de validade das propostas, sem convocação para assinatura da Ata de Registro de Preços, ficam as licitantes liberadas dos compromissos assumidos.

SEÇÃO VI – DA ABERTURA DA SESSÃO PÚBLICA

10. A abertura da sessão pública deste Pregão, conduzida pelo Pregoeiro, ocorrerá na data e na hora indicadas no preâmbulo deste Edital, no sítio xxx.xxxxxxxxxxxxxxxxxxxxx.xxx.xx.

11. Durante a sessão pública, a comunicação entre o Pregoeiro e as licitantes ocorrerá exclusivamente mediante troca de mensagens, em campo próprio do sistemaeletrônico.

12. Cabe à licitante acompanhar as operações no sistema eletrônico durante a sessão pública do Pregão, ficando responsável pelo ônus decorrente da perda de negócios diante da inobservância de qualquer mensagem emitida pelo sistema ou de sua desconexão.

SEÇÃO VII – DA CLASSIFICAÇÃO DAS PROPOSTAS

13. O Pregoeiro verificará as propostas apresentadas e desclassificará, motivadamente, aquelas que não estejam em conformidade com os requisitos estabelecidos neste Edital.

14. Somente as licitantes com propostas classificadas participarão da fasede lances.

SEÇÃO VIII – DA FORMULAÇÃO DE LANCES

15. Aberta a etapa competitiva, as licitantes classificadas poderão encaminhar lances sucessivos, exclusivamente por meio do sistema eletrônico, sendo imediatamente informadas do horário e valor consignados no registro de cada lance.

16. A licitante somente poderá oferecer lance inferior ao último por ela ofertado e registrado no sistema.

17. Durante o transcurso da sessão, as licitantes serão informadas, em tempo real, do valor do menor lance registrado, mantendo-se em sigilo a identificação da ofertante.

18. Em caso de empate, prevalecerá o lance recebido e registrado primeiro.

19. Os lances apresentados e levados em consideração para efeito de julgamento serão de exclusiva e total responsabilidade da licitante, não lhe cabendo o direito de pleitear qualquer alteração.

20. Durante a fase de lances, o Pregoeiro poderá excluir, justificadamente, lance cujo valor seja manifestamente inexequível.

21. Se ocorrer a desconexão do Pregoeiro no decorrer da etapa de lances, e o sistema eletrônico permanecer acessível às licitantes, os lances continuarão sendo recebidos, sem prejuízo dos atos realizados.

22. No caso de a desconexão do Pregoeiro persistir por tempo superior a 10 (dez) minutos, a sessão do Pregão será suspensa automaticamente e terá reinício somente após comunicação expressa às participantes no sítio xxx.xxxxxxxxxxxxxxxxxxxxx.xxx.xx.

23. O encerramento da etapa de lances será decidido pelo Pregoeiro, que informará, com antecedência de 1 a 60 minutos, o prazo para início do tempo de iminência.

24. Decorrido o prazo fixado pelo Pregoeiro, o sistema eletrônico encaminhará aviso de fechamento iminente dos lances, após o que transcorrerá período de tempo de até 30 (trinta) minutos, aleatoriamente determinado pelo sistema, findo o qual será automaticamente encerrada a fase de lances.

SEÇÃO IX – DO BENEFÍCIO ÀS MICROEMPRESAS E EMPRESAS DE PEQUENO PORTE

25. Após a fase de lances, se a proposta mais bem classificada não tiver sido apresentada por microempresa ou empresa de pequeno porte, e houver proposta de microempresa ou empresa de pequeno porte que seja igual ou até 5% (cinco por cento) superior à proposta mais bem classificada, proceder-se-á da seguinte forma:

25.1. a microempresa ou a empresa de pequeno porte mais bem classificada poderá, no prazo de 5 (cinco) minutos, contados do envio da mensagem automática pelo sistema, apresentar uma última oferta, obrigatoriamente inferior à proposta do primeiro colocado, situação em que, atendidas as exigências habilitatórias e observado o valor estimado para a contratação, será adjudicado em seu favor o objeto deste Pregão;

25.1.1. Caso a licitante tenha utilizado a prerrogativa de efetuar oferta de desempate, conforme art. 44, da Lei Complementar n.º 123/2006, será verificado no Portal da Transparência do Governo Federal, no endereço eletrônico xxxx://xxx.xxxxxxxxxxxxxxxxxxxxx.xxx.xx, e no Portal da Transparência do Poder Judiciário, no endereço eletrônico xxx.xxxxxxxxxxxxxxxxxxx.xxx.xx, se o somatório de ordens bancárias recebidas pela licitante, relativas ao último exercício e ao exercício corrente, até o mês anterior ao da data da licitação, fixada no preâmbulo deste Edital, já seria suficiente para extrapolar o faturamento máximo permitido, conforme art. 3º da mencionada Lei Complementar.

25.2. não sendo vencedora a microempresa ou a empresa de pequeno porte mais bem classificada, na forma da subcondição anterior, o sistema, de forma automática, convocará as licitantes remanescentes que porventura se enquadrem na situação descrita nesta condição, na ordem classificatória, para o exercício do mesmo direito;

25.3. no caso de equivalência dos valores apresentados pelas microempresas ou empresas de pequeno porte que se encontrem no intervalo estabelecido nesta condição, o sistema fará um sorteio eletrônico, definindo e convocando automaticamente a vencedora para o encaminhamento da oferta final do desempate;

25.4. a convocada que não apresentar proposta dentro do prazo de 5 (cinco) minutos, controlados pelo Sistema, decairá do direito previsto nos artigos 44 e 45 da Lei Complementar n.º 123/2006;

25.5. na hipótese de não contratação nos termos previstos nesta Seção, o procedimento licitatório prossegue com as demais licitantes.

SEÇÃO X – DO DIREITO DE PREFERÊNCIA

26. Este Pregão submete-se às regras relativas ao direito de preferência estabelecidas no Decreto n.º 7.174/2010.

27. O exercício do direito de preferência disposto no Decreto n.º 7.174/2010 será concedido após o encerramento da fase de lances, observando-se, nesta ordem, os seguintes procedimentos:

27.1. aplicam-se as regras de preferência para as microempresas e empresas de pequeno porte dispostas na Seção IX deste Edital;

27.2. não ocorrendo a contratação na forma da subcondição anterior, aplicam-se as regras de preferência previstas no art. 5º do Decreto n.º 7.174/2010, com a classificação das licitantes cujas propostas finais estejam situadas até 10% (dez por cento) acima da melhor proposta válida, para a comprovação e o exercício do direito de preferência;

27.3. convocam-se as licitantes para exercício do direito de preferência, obedecidas as regras dispostas nos incisos III e IV art. 8º do Decreto n.º 7.174/2010;

27.4. não ocorrendo a contratação na forma da subcondição anterior, o procedimento licitatório prossegue com as demais licitantes.

SEÇÃO XI – DA NEGOCIAÇÃO

28. O Pregoeiro poderá encaminhar contraproposta diretamente à licitante que tenha apresentado o lance mais vantajoso, observado o critério de julgamento e o valor estimado para a contratação.

28.1. A negociação será realizada por meio do sistema, podendo ser acompanhada pelas demais licitantes.

SEÇÃO XII – DA ACEITABILIDADE DA PROPOSTA

29. A licitante classificada provisoriamente em primeiro lugar deverá encaminhar a proposta de preço adequada ao último lance, devidamente preenchida na forma do Anexo III – Modelo de Proposta de Preços, em arquivo único, no prazo de 24 (vinte e quatro) horas, contado da convocação efetuada pelo Pregoeiro por meio da opção “Enviar Anexo” no sistema Comprasnet.

29.1. Os documentos remetidos por meio da opção “Enviar Anexo” do sistema Comprasnet poderão ser solicitados em original ou por cópia autenticada a qualquer momento, em prazo a ser estabelecido pelo Pregoeiro.

29.1.1. Os originais ou cópias autenticadas, caso sejam solicitados, deverão ser encaminhados ao Serviço de Pregão e Cotação Eletrônica do Tribunal de Contas da União, situado no Setor de Administração Federal Sul – SAFS, quadra 04, lote 1, Anexo I, sala 103, XXX 00000- 900, Brasília/DF.

29.2. A licitante que abandonar o certame, deixando de enviar a documentação indicada nesta seção, será desclassificada e sujeitar-se-á às sanções previstas neste Edital.

30. O Pregoeiro examinará a proposta mais bem classificada quanto à compatibilidade do preço ofertado com o valor estimado e à compatibilidade da proposta com as especificações técnicas do objeto.

30.1. O Pregoeiro poderá solicitar parecer de técnicos pertencentes ao quadro de pessoal do TCU ou, ainda, de pessoas físicas ou jurídicas estranhas a ele, para orientar sua decisão.

30.2. Não se considerará qualquer oferta de vantagem não prevista neste Edital, inclusive financiamentos subsidiados ou a fundo perdido.

30.3. Não se admitirá proposta que apresente valores simbólicos, irrisórios ou de valor zero, incompatíveis com os preços de mercado, exceto quando se referirem a materiais e instalações de propriedade da licitante, para os quais ela renuncie à parcela ou à totalidade de remuneração.

30.4. Não serão aceitas propostas com valores globais ou com valor unitário da mão de obra (total da planilha de custos e formação de preços para um profissional) superiores ao estimado ou com preços manifestamente inexequíveis.

30.4.1. Considerar-se-á inexequível a proposta que não venha a ter demonstrada sua viabilidade por meio de documentação que comprove que os custos envolvidos na contratação são coerentes com os de mercado do objeto deste Pregão.

30.5. Será desclassificada a proposta que:

30.5.1. não corrigir ou não justificar eventuais falhas apontadas pelo Pregoeiro;

30.5.2. não respeitar a remuneração mínima para os perfis profissionais denominados “Analista Programador Java nível Sênior” e “Analista Programador Java nível Pleno” estabelecidos neste Edital.

SEÇÃO XIII – DA HABILITAÇÃO

31. A habilitação das licitantes será verificada por meio do Sicaf (habilitação parcial) e da documentação complementar especificada neste Edital.

32. As licitantes que não atenderem às exigências de habilitação parcial no Sicaf deverão apresentar documentos que supram tais exigências.

33. Realizada a habilitação parcial no Sicaf, será verificado eventual descumprimento das vedações elencadas na Condição 4 da Seção III – Da Participação na Licitação, mediante consulta ao:

33.1. Sicaf, a fim de verificar a composição societária das empresas e certificar eventual participação indireta que ofenda ao art. 9º, III, da Lei n.º 8.666/93;

33.2. Cadastro Nacional de Condenações Cíveis por Atos de Improbidade Administrativa, mantido pelo Conselho Nacional de Justiça – CNJ, no endereço eletrônico xxx.xxx.xxx.xx/xxxxxxxxxxx_xxx/xxxxxxxxx_xxxxxxxxx.xxx;

33.3. Cadastro Nacional das Empresas Inidôneas e Suspensas – CEIS, no endereço eletrônico xxx.xxxxxxxxxxxxxxxxxxxxx.xxx.xx/xxxx.

34. As consultas previstas na Condição anterior realizar-se-ão em nome da sociedade empresária licitante e também de eventual matriz ou filial e de seu sóciomajoritário.

35. Efetuada a verificação referente ao cumprimento das condições de participação no certame, a habilitação das licitantes será realizada mediante a apresentação da seguinte documentação complementar, para fins de comprovação de qualificação econômico-financeira:

35.1. Balanço Patrimonial do último exercício social exigível, apresentado na forma da lei e regulamentos na data de realização deste Pregão, vedada sua substituição por balancetes ou balanços provisórios, podendo ser atualizado por índices oficiais quando encerrados há mais de 3 (três) meses da data da sessão pública de abertura deste processo licitatório;

35.2. Demonstração do Resultado do Exercício (DRE) relativa ao último exercício social exigível, apresentado na forma da lei;

35.3. Declaração de contratos firmados com a iniciativa privada e com a Administração Pública cujo objeto seja prestação de serviços mediante a disponibilização de empregado de maneira exclusiva, na forma de posto de trabalho, vigentes na data da sessão pública de abertura deste Pregão, conforme modelo constante no Anexo IX;

35.4. prova de inexistência de débitos inadimplidos perante a Justiça do Trabalho, mediante a apresentação de certidão negativa, nos termos do Título VII-A da Consolidação das Leis do Trabalho, aprovada pelo Decreto-Lei nº 5.452, de 1º de maio de 1943, tendo em vista o disposto no art. 3º da Lei nº 12.440, de 7 de julho de 2011;

35.5. Certidão negativa de feitos sobre falência, recuperação judicial ou recuperação extrajudicial, expedida pelo distribuidor da sede da sociedade empresária licitante.

36. Os documentos exigidos para fins de qualificação econômico-financeira deverão comprovar o seguinte:

36.1. Índices de Liquidez Geral (LG), Liquidez Corrente (LC) e Solvência Geral (SG) superiores a 1;

36.2. Capital Circulante Líquido (CCL) ou Capital de Giro (Ativo Circulante – Passivo Circulante) de, no mínimo, 16,66% (dezesseis inteiros e sessenta e seis centésimos por cento) do valor estimado para a contratação;

36.3. Patrimônio Líquido (PL) igual ou superior a 10% (dez por cento) do valor estimado para a contratação; e

36.4. Patrimônio Líquido igual ou superior a 1/12 (um doze avos) do valor total dos contratos firmados com a Administração Pública e com a iniciativa privada cujo objeto seja prestação de serviços mediante a disponibilização de empregado de maneira exclusiva, na forma de posto de trabalho, vigentes na data da sessão pública de abertura deste Pregão.

37. Caso o valor total constante na declaração de que trata a Subcondição 35.3 apresente divergência percentual superior a 10% (dez por cento), para mais ou para menos, em relação à receita bruta discriminada na Demonstração de Resultado do Exercício (DRE), a licitante deverá apresentar as devidas justificativas no Anexo IX.

37.1. Se as justificativas não forem entregues concomitantemente à documentação, o Pregoeiro fixará prazo para a sua apresentação.

38. Para fins de qualificação técnico-operacional:

38.1. Comprovação de, no mínimo, 3 (três) anos de experiência na execução de serviços de desenvolvimento de software, comprovados por meio de atestados ou declarações de capacidade técnica, cópias de contratos, registros em órgãos oficiais, ou outros documentos idôneos.

39. O Pregoeiro poderá consultar sítios oficiais de órgãos e entidades emissores de certidões, para verificar as condições de habilitação das licitantes.

40. Os documentos que não estejam contemplados no Sicaf deverão ser remetidos em conjunto com a proposta de preços indicada na Condição 29, em arquivo único, por meio da opção “Enviar Anexo” do sistema Comprasnet, no mesmo prazo estipulado na mencionada condição.

40.1. Os documentos remetidos por meio da opção “Enviar Anexo” do sistema Comprasnet poderão ser solicitados em original ou por cópia autenticada a qualquer momento, em prazo a ser estabelecido pelo Pregoeiro.

40.1.1. Os originais ou cópias autenticadas, caso sejam solicitados, deverão ser encaminhados ao Serviço de Pregão e Cotação Eletrônica do Tribunal de Contas da União, situado no Setor de Administração Federal Sul – SAFS, Xxxxxx 00, Xxxx 0, Xxxxx X, xxxx 000, XXX 00000- 000, Xxxxxxxx/XX.

40.2. Os documentos encaminhados deverão estar em nome da licitante, com indicação do número de inscrição no CNPJ.

40.3. Todos os documentos emitidos em língua estrangeira deverão ser entregues acompanhados da tradução para língua portuguesa, efetuada por tradutor juramentado, e também devidamente consularizados ou registrados no cartório de títulos e documentos.

40.4. Documentos de procedência estrangeira, mas emitidos em língua portuguesa, também deverão ser apresentados devidamente consularizados ou registrados em cartório de títulos e documentos.

40.5. Em se tratando de filial, os documentos de habilitação jurídica e regularidade fiscal deverão estar em nome da filial, exceto aqueles que, pela própria natureza, são emitidos somente em nome da matriz.

40.6. Em se tratando de microempresa ou empresa de pequeno porte, havendo alguma restrição na comprovação de regularidade fiscal e trabalhista, será assegurado o prazo de 5 (cinco) dias úteis, prorrogável por igual período, para a regularização da documentação, a realização do pagamento ou parcelamento do débito e a emissão de eventuais certidões negativas ou positivas com efeito de certidão negativa.

40.6.1. O prazo para regularização fiscal e trabalhista será contado a partir da divulgação do resultado da fase de habilitação.

40.6.2. A prorrogação do prazo previsto poderá ser concedida, a critério da administração pública, quando requerida pela licitante, mediante apresentação de justificativa.

40.7. A não regularização da documentação, no prazo previsto na subcondição anterior, implicará decadência do direito ao registro de preços e à contratação, sem prejuízo das sanções previstas neste Edital, e facultará ao Pregoeiro convocar as licitantes remanescentes, na ordem de classificação.

41. Se a proposta não for aceitável, se a licitante não atender às exigências de habilitação, o Pregoeiro examinará a proposta subsequente e assim sucessivamente, na ordem de classificação, até a seleção da proposta que melhor atenda a este Edital.

42. Constatado o atendimento às exigências fixadas neste Edital, a licitante será declarada vencedora.

SEÇÃO XIV – DA DEMONSTRAÇÃO DOS SERVIÇOS

43. Não se exigirá demonstração dos serviços ofertados.

SEÇÃO XV – DO RECURSO

44. Declarada a vencedora, o Pregoeiro abrirá prazo de 30 (trinta) minutos, durante o qual qualquer licitante poderá, de forma imediata e motivada, em campo próprio do sistema, manifestar sua intenção de recurso.

44.1. A falta de manifestação no prazo estabelecido autoriza o Pregoeiro a adjudicar o objeto à licitante vencedora.

44.2. O Pregoeiro examinará a intenção de recurso, aceitando-a ou, motivadamente, rejeitando-a, em campo próprio do sistema.

44.3. A licitante que tiver sua intenção de recurso aceita deverá registrar as razões do recurso, em campo próprio do sistema, no prazo de 3 (três) dias, ficando as demais licitantes, desde logo, intimadas a apresentar contrarrazões, também via sistema, em igual prazo, que começará a correr do término do prazo da recorrente.

45. Para efeito do disposto no § 5º do artigo 109 da Lei n.º 8.666/1993, fica a vista dos autos do TC 031.871/2017-8 franqueada aos interessados.

46. As intenções de recurso não admitidas e os recursos rejeitados pelo Pregoeiro serão apreciados pela autoridade competente.

47. O acolhimento do recurso implicará a invalidação apenas dos atos insuscetíveis de aproveitamento.

SEÇÃO XVI – DA ADJUDICAÇÃO E HOMOLOGAÇÃO

48. O objeto deste Pregão será adjudicado pelo Pregoeiro, salvo quando houver recurso, hipótese em que a adjudicação caberá à autoridade competente para homologação.

49. A homologação deste Pregão compete ao Secretário-Geral de Administração do Tribunal de Contas da União.

50. O objeto deste Pregão será adjudicado à vencedora do grupo de itens.

SEÇÃO XVII – DO REGISTRO DE PREÇOS

51. O Tribunal de Contas da União é o órgão gerenciador responsável pela condução do conjunto de procedimentos para registro de preços e gerenciamento da Ata de Registro de Preços dele decorrente.

51.1. A Selip/Segedam será a unidade responsável pelos atos de controle e administração da Ata de Registro de Preços decorrentes desta licitação.

52. São órgãos participantes os órgãos ou entidades da administração pública que participam dos procedimentos iniciais do Sistema de Registro de Preços e integram a Ata de Registro de Preços.

53. O órgão participante será responsável pela manifestação de interesse em participar do registro de preços, no módulo Intenção de Registro de Preços – IRP do sistemaComprasnet.

54. A Ata de Registro de Preços será de uso exclusivo do Tribunal de Contas da União (TCU) e do Ministério da Transparência e Controladoria-Geral da União (CGU).

54.1. Não será permitida futura adesão de outros órgãos públicos, tendo em vista as peculiaridades da contratação.

55. Por ocasião da homologação da licitação, será incluído, na respectiva Ata de Registro de Preços na forma de anexo, o registro das licitantes não desclassificadas que aceitarem cotar os bens ou serviços com preços iguais aos da licitante vencedora na sequência da classificação do certame, excluído o percentual referente à margem de preferência, quando o objeto não atender aos requisitos previstos no art. 3º da Lei n.º 8.666/93.

56. Homologado o resultado deste Pregão, a licitante mais bem classificada será convocada para assinar a Ata de Registro de Preços, no prazo de até 5 (cinco) dias úteis, contado da data do recebimento do documento oficial de convocação.

56.1. O prazo para que a licitante mais bem classificada compareça após ser convocada, poderá ser prorrogado, uma única vez, por igual período, desde que ocorra motivo justificado e aceito pelo Tribunal de Contas da União.

56.2. É facultado ao TCU, quando a convocada não assinar a Ata de Registro de Preços no prazo e condições estabelecidos, convocar as licitantes remanescentes, na ordem de classificação, para fazê-lo em igual prazo, nos termos do parágrafo único do art. 13 do Decreto n.º 7.892/2013.

57. Publicada na Imprensa Oficial, a Ata de Registro de Preços implicará compromisso de fornecimento nas condições estabelecidas, conforme disposto no artigo 14 do Decreto n.º 7.892/2013.

58. A existência de preços registrados não obriga a Administração a contratar, facultando-se a realização de licitação específica para a aquisição pretendida, assegurada preferência ao fornecedor registrado em igualdade de condições.

59. O prazo de validade improrrogável da Ata de Registro de Preços é de 12 (doze) meses, contado da data da sua assinatura, excluído o dia do começo e incluído o dovencimento.

60. Durante a vigência da Ata, os preços registrados serão fixos e irreajustáveis, exceto nas hipóteses decorrentes e devidamente comprovadas das situações previstas na alínea “d” do inciso II do art. 65 da Lei n.º 8.666/1993 ou no artigo 17 do Decreto n.º 7.892/2013.

60.1. Nessa hipótese, a Administração, por razão de interesse público, poderá optar por cancelar a Ata e iniciar outro processo licitatório.

61. Quando o preço registrado se tornar superior ao preço praticado no mercado por motivo superveniente, o órgão gerenciador convocará os fornecedores para negociarem a redução dos preços aos valores praticados pelo mercado.

61.1. Os fornecedores que não aceitarem reduzir seus preços aos valores praticados pelo mercado serão liberados do compromisso assumido, sem aplicação de penalidade.

61.2. A ordem de classificação dos fornecedores que aceitarem reduzir seus preços aos valores de mercado observará a classificação original.

62. Quando o preço de mercado se tornar superior aos preços registrados e o fornecedor não puder cumprir o compromisso, o órgão gerenciador poderá:

62.1. liberar o fornecedor do compromisso assumido, caso a comunicação ocorra antes do pedido de fornecimento, e sem aplicação da penalidade se confirmada a veracidade dos motivos e comprovantes apresentados; e

62.2. convocar os demais fornecedores para assegurar igual oportunidade de negociação.

63. Não havendo êxito nas negociações previstas na Condição anterior, o órgão gerenciador deverá proceder à revogação da Ata de Registro de Preços, adotando as medidas cabíveis para obtenção da contratação mais vantajosa.

64. O registro do fornecedor será cancelado quando:

64.1. descumprir as condições da Ata de Registro de Preços;

64.2. não retirar a nota de empenho ou instrumento equivalente no prazo estabelecido pela Administração, sem justificativa aceitável;

64.3. não aceitar reduzir o seu preço registrado, na hipótese deste se tornar superior àqueles praticados no mercado; ou

64.4. sofrer sanção prevista nos incisos III ou IV do caput do art. 87 da Lei n.º 8.666, de 1993, ou no art. 7º da Lei n.º 10.520, de 2002.

65. O cancelamento de registros nas hipóteses previstas nas Subcondições 64.1, 64.2 e

64.4 será formalizado por despacho do órgão gerenciador, assegurado o contraditório e a ampla defesa.

66. O cancelamento do registro de preços poderá ocorrer por fato superveniente, decorrente de caso fortuito ou força maior, que prejudique o cumprimento da Ata, devidamente comprovados e justificados:

66.1. por razão de interesse público; ou

66.2. a pedido do fornecedor.

67. Em qualquer das hipóteses anteriores que impliquem a alteração da Ata registrada, concluídos os procedimentos de ajuste, o TCU fará o devido apostilamento na Ata de Registro de Preços e informará aos fornecedores registrados a nova ordem de classificação.

68. A Ata de Registro de Preços, decorrente desta licitação, será cancelada, automaticamente, por decurso do prazo de sua vigência.

SEÇÃO XVIII – DO INSTRUMENTO CONTRATUAL

69. Depois de assinada a Ata de Registro de Preços, o fornecedor registrado poderá ser convocado, a qualquer tempo durante a vigência da Ata, para assinatura do contrato, dentro do prazo de 5 (cinco) dias úteis, contado da data do recebimento do documento oficial de convocação, sob pena de decair o direito à contratação, sem prejuízo das sanções previstas neste Edital.

69.1. Poderá ser acrescentada ao contrato a ser assinado qualquer vantagem apresentada pelo fornecedor registrado em sua proposta, desde que seja pertinente e compatível com os termos deste Edital.

70. O prazo para a assinatura do contrato poderá ser prorrogado uma única vez, por igual período, quando solicitado pelo fornecedor registrado durante o seu transcurso, desde que ocorra motivo justificado e aceito pelo TCU.

71. Por ocasião da assinatura do contrato, verificar-se-á por meio do Sicaf e de outros meios se a licitante vencedora mantém as condições de habilitação.

SEÇÃO XIX – DAS SANÇÕES

72. A licitante ficará impedida de licitar e contratar com a União e será descredenciada no Sicaf, pelo prazo de até 5 (cinco) anos, sem prejuízo de multa de até 30% (trinta por cento) do valor estimado para a contratação e demais cominações legais, nos seguintes casos:

72.1. cometer fraude fiscal;

72.2. apresentar documento falso;

72.3. fizer declaração falsa;

72.4. comportar-se de modo inidôneo;

72.5. não assinar a Ata de Registro de Preços no prazo estabelecido;

72.6. não assinar o contrato no prazo estabelecido;

72.7. deixar de entregar a documentação exigida no certame; e,

72.8. não mantiver a proposta.

73. Para os fins da subcondição 72.4, reputar-se-ão inidôneos atos como os descritos nos artigos 90, 92, 93, 94, 95 e 97 da Lei n.º 8.666/93.

SEÇÃO XX – DOS ESCLARECIMENTOS E DA IMPUGNAÇÃO AO EDITAL

74. Até 2 (dois) dias úteis antes da data fixada para abertura da sessão pública, qualquer pessoa, física ou jurídica, poderá impugnar o ato convocatório deste Pregão mediante petição a ser enviada exclusivamente para o endereço eletrônico xxx@xxx.xxx.xx, até as 19 horas, no horário oficial de Brasília/DF.

75. O Pregoeiro, auxiliado pelo setor técnico competente, decidirá sobre a impugnação no prazo de 24 (vinte e quatro) horas.

76. Acolhida a impugnação contra este Edital, será designada nova data para a realização do certame, exceto quando, inquestionavelmente, a alteração não afetar a formulação das propostas.

77. Os pedidos de esclarecimentos devem ser enviados ao Pregoeiro até 3 (três) dias úteis antes da data fixada para abertura da sessão pública, exclusivamente para o endereço eletrônico xxx@xxx.xxx.xx.

78. As respostas às impugnações e aos esclarecimentos solicitados serão disponibilizadas no sistema eletrônico para os interessados.

SEÇÃO XXI – DISPOSIÇÕES FINAIS

79. Ao Secretário-Geral de Administração do Tribunal de Contas da União compete anular este Pregão por ilegalidade, de ofício ou por provocação de qualquer pessoa, e revogar o certame por considerá-lo inoportuno ou inconveniente diante de fato superveniente, mediante ato escrito e fundamentado.

79.1. A anulação do Pregão induz à da Ata de Registro de Preços, bem como à do contrato.

79.2. As licitantes não terão direito à indenização em decorrência da anulação do procedimento licitatório, ressalvado o direito do contratado de boa-fé de ser ressarcido pelos encargos que tiver suportado no cumprimento docontrato.

80. É facultado ao Pregoeiro ou à autoridade superior, em qualquer fase deste Pregão, promover diligência destinada a esclarecer ou completar a instrução do processo, vedada a inclusão posterior de informação ou de documentos que deveriam ter sido apresentados para fins de classificação e habilitação.

81. No julgamento das propostas e na fase de habilitação, o Pregoeiro poderá sanar erros ou falhas que não alterem a substância das propostas e dos documentos e a sua validade jurídica, mediante despacho fundamentado, registrado em ata e acessível a todos, atribuindo-lhes validade e eficácia para fins de classificação e habilitação.

81.1. Caso os prazos definidos neste Edital não estejam expressamente indicados na proposta, eles serão considerados como aceitos para efeito de julgamento deste Pregão.

82. Os documentos eletrônicos produzidos com a utilização de processo de certificação disponibilizada pela ICP-Brasil, nos termos da Medida Provisória n.º 2.200-2, de 24 de agosto de

2001, serão recebidos e presumidos verdadeiros em relação aos signatários, dispensando-se o envio de documentos originais e cópias autenticadas em papel.

83. Em caso de divergência entre normas infralegais e as contidas neste Edital, prevalecerão as últimas.

84. Este Pregão poderá ter a data de abertura da sessão pública transferida por conveniência do TCU, sem prejuízo do disposto no art. 4, inciso V, da Lei n.º10.520/2002.

SEÇÃO XXII – DOS ANEXOS

85. São partes integrantes deste Edital os seguintes anexos:

85.1. Anexo I - Termo de Referência;

85.2. Anexo II – Orçamento Estimativo;

85.3. Anexo III – Modelo de Proposta de Preços;

85.4. Anexo IV – Exemplo de Planilha de Custos e Formação de Preços com Memória de Cálculo;

85.5. Anexo V – Processo de Desenvolvimento de Projeto e de Manutenção de Software;

85.6. Anexo VI – Níveis Mínimos de Serviço e Cálculo de Pagamento;

85.7. Anexo VII – Modelos de Ordem de Serviço e de Aditivo;

85.8. Anexo VIII – Termo de Compromisso de Manutenção de Sigilo e Respeito às Normas de Segurança Vigentes no TCU e Declaração de Ciência do Termo de Manutenção de Sigilo e Respeito às Normas de Segurança Vigentes;

85.9. Anexo IX – Modelo de Declaração de Contratos Firmados com a Iniciativa Privada e com a Administração Pública;

85.10. Anexo X – Modelo de Termo de Recebimento Definitivo;

85.11. Anexo XI – Manual de Medição Funcional de Software;

85.12. Anexo XII – Modelo de Relatório de Medição Estimativa de Tamanho Funcional;

85.13. Anexo XIII – Modelo de Relatório de Contagem Funcional Detalhada;

85.14. Anexo XIV – Guia de Melhores Práticas de Medição Funcional de Software;

85.15. Anexo XV – Minuta da Ata de Registro de Preços;

85.16. Anexo XVI – Minuta do Contrato;

85.17. Anexo XVII – Modelo de Carta de Fiança Bancária para Garantia de Execução Contratual.

SEÇÃO XXIII – DO FORO

86. As questões decorrentes da execução deste Instrumento, que não possam ser dirimidas administrativamente, serão processadas e julgadas na Justiça Federal, no Foro da cidade de Brasília/DF, Seção Judiciária do Distrito Federal, com exclusão de qualquer outro, por mais privilegiado que seja, salvo nos casos previstos no art. 102, inciso I, alínea “d” da Constituição Federal.

Brasília, 27 de junho de 2018 XXXXXX XXXXXXXX XXXXX XX XX XXXXXX

Pregoeiro

ANEXO I – TERMO DE REFERÊNCIA

1. Objeto

1.1. Prestação presencial de serviços de projeto e de manutenção de software com práticas ágeis, conforme especificações técnicas constantes deste Edital, para o Tribunal de Contas da União (TCU) e para o Ministério da Transparência e Controladoria-Geral da União (CGU), conforme quadro abaixo:

GRUPO 1	Itens	Perfil do Posto de Trabalho	Qtd	Orgão	Turno / Carga Horária	Valor unitário mensal (R$)	Valor unitário anual (R$)	Valor total anual (R$)	Valor total para 24 meses (R$)
	1	Analista	43	TCU	Diurno	19.064,63	228.775,56	9.837.349,00	00.000.000,16
		Programador Java nível Sênior			(8h)
			9	CGU	Diurno (8h)	19.064,63	228.775,56	2.058.980,04	4.117.960,08
	2	Analista	15	TCU	Diurno	14.111,40	169.336,80	2.540.052,00	5.080.104,00
		Programador Java nível			(8h)
			6	CGU	Diurno	14.111,40	169.336,80	1.016.020,80	2.032.041,60
		Pleno			(8h)
	Total (R$)								30.904.803,84

2. Orçamento estimativo

2.1. Valor total previsto da aquisição para o Tribunal de Contas da União é de R$ 24.754.802,16 (vinte e quatro milhões setecentos e cinquenta e quatro mil oitocentos e dois reais e dezesseis centavos) e para o Ministério da Transparência e Controladoria-Geral da União é de R$ 6.150.001,68 (seis milhões cento e cinquenta mil e um real e sessenta e oito centavos), conforme dados orçamentários presentes no Anexo II - Orçamento Estimativo, discriminando a relação de itens e respectivos quantitativos.

3. Especificação técnica

3.1. A CONTRATADA deverá prestar presencialmente serviços de projeto e manutenção de software seguindo processo definido no Anexo V – Processo de Desenvolvimento de Projeto e de Manutenção de Software e que prevê a adoção de práticas ágeis, como Scrum, Extreme Programming (XP) e Kanban, respeitando os padrões técnicos adotados no Tribunal.

3.2. Os serviços serão prestados por meio de profissionais da CONTRATADA alocados exclusivamente para o Tribunal, na forma de postos de trabalho. Cada profissional fará o papel de membro de equipe de desenvolvimento previsto no Scrum, enquanto os demais papeis, como ScrumMaster e Product Owner (PO), dentre outros, serão desempenhados por representantes do Tribunal.

3.3. O Tribunal demandará à CONTRATADA a alocação de profissionais por meio de abertura de Ordem de Serviço (OS), que poderá ser do tipo PROJETO ou MANUTENÇÃO.

3.4. A quantidade de postos de trabalho demandados à empresa deverá constar na abertura da OS.

3.5. O somatório de postos de trabalho previstos em todas as Ordens de Serviço não poderá exceder o quantitativo máximo de postos de trabalho previstos no edital.

3.6. O pagamento do serviço estará vinculado ao atendimento dos níveis mínimos de serviço exigidos, conforme regras constantes no Anexo VI – Níveis Mínimos de Serviço e Cálculo de Pagamento.

3.7. O serviço deverá ser prestado, em regra, nos dias úteis e dentro do horário normal de funcionamento do Tribunal, que é de 8h as 20h.

3.7.1. Excepcionalmente, sem custo adicional, o Tribunal poderá autorizar a execução do serviço em dia não útil ou fora do horário normal de funcionamento do TCU.

3.7.2. A seu critério, o Tribunal poderá especificar intervalo (“janela”) de horário para prestação do serviço mais restrito que o horário normal de funcionamento do TCU para determinados projetos ou sistemas, desde que mantenha, ao menos, 8h30min (oito horas e trinta minutos) contínuos no novo horário.

3.8. Cada posto de trabalho previsto nesta contratação deverá cumprir 8 horas de expediente diário dentro do horário de funcionamento normal do Tribunal que é das 8 às 20 horas, observada a legislação trabalhista vigente.

3.9. Não haverá remuneração adicional do TCU à CONTRATADA no caso de execução de jornada de trabalho diária superior a 8 (oito) horas.

3.10. O Tribunal definirá, por Ordem de Serviço, os dias e horários em que ocorrerão as reuniões e demais atividades previstas no processo de desenvolvimento de software que requerem a presença de todos os profissionais da CONTRATADA. Estas definições poderão ser alteradas durante a execução da ordem de serviço, mediante comunicação prévia à CONTRATADA.

4. Preposto

4.1. No prazo de 5 (cinco) dias úteis após a assinatura do contrato, a CONTRATADA deverá indicar, mediante declaração, um preposto, aceito pela fiscalização e que seja distinto dos profissionais que irão prestar o serviço, para representá-la administrativamente durante o período de vigência do contrato, sempre que for necessário. Na declaração deverá constar o nome completo, nº do CPF e do documento de identidade, além dos dados relacionados à sua qualificação profissional.

4.2. O preposto deverá possuir ao menos ensino médio completo, ter experiência em gestão de serviços terceirizados e conhecimentos acerca de processo de desenvolvimento de software baseado em Scrum e Kanban.º

4.2.1. A qualificação do preposto deverá ser comprovada por meio de certificado(s) e/ou comprovante(s) de conclusão de curso e currículo atualizado.

4.3. O preposto deverá estar apto a esclarecer as questões relacionadas às faturas dos serviços prestados e demais assuntos relativos à execução contratual.

4.4. A CONTRATADA orientará o seu preposto quanto à necessidade de acatar as orientações do Tribunal, inclusive quanto ao cumprimento dos normativos internos.

4.5. O preposto deverá participar de reuniões sempre que solicitado pelo Tribunal para discutir o andamento da execução contratual.

5. Atividades a serem executadas pela CONTRATADA

5.1. Poderá ser solicitada no âmbito do serviço contratado a execução das seguintes atividades:

5.1.1. Codificação de software;

5.1.2. Testes de software (ex: teste de unidade, integração, sistema/funcional, aceitação/estória, carga, desempenho, vulnerabilidade, usabilidade, acessibilidade);

5.1.3. Análise e projeto de software orientado a objetos;

5.1.4. Levantamento e análise de requisitos funcionais e não-funcionais, incluindo requisitos de acessibilidade;

5.1.5. Modelagem de dados (modelo lógico e físico);

5.1.6. Controle de versões de código-fonte de software e geração de builds;

5.1.7. Instalação e configuração básica de servidor de aplicação em ambiente de não produção (ex: desenvolvimento, homologação, etc) e publicação (deploy) dos sistemas desenvolvidos nestes ambientes;

5.1.8. Apoio ao Product Owner (PO) na definição e especificação de requisitos (refinamento dos itens do backlog do produto);

5.1.9. Participação ativa nas reuniões e demais práticas inerentes ao desenvolvimento ágil;

5.1.10. Medição do software produzido conforme manual de métricas do TCU e requisitos definidos no Edital;

5.1.11. Transferência de conhecimento acerca do projeto para a equipe do TCU;

5.1.12. Manutenção de software codificado em tecnologias Java consideradas legadas (ex.: JSP, Java Beans, Struts).

6. Qualificação dos profissionais da CONTRATADA

6.1. O enquadramento de profissional no perfil “Analista-Programador Java de nível Sênior” para o âmbito desta contratação requer o atendimento, no mínimo, das seguintes exigências:

6.1.1. Formação acadêmica:

a) Graduação em curso de nível superior na área de Tecnologia da Informação, ou conclusão de qualquer curso de nível superior acompanhado de certificado de

curso de pós-graduação (especialização, mestrado ou doutorado) na área de Tecnologia da Informação de, no mínimo, 360 horas.

6.1.2. Conhecimentos técnicos:

a) Linguagens de programação para plataforma Java. Ex: Java, Xxxxxx, Groovy.

b) Princípios e práticas de desenvolvimento de software ágil, incluindo o Manifesto Ágil, Scrum, Extreme Programming (XP) e Kanban.º

c) Análise de requisitos funcionais e não-funcionais, padrões de projeto (enterprise integration patterns, design patterns, microservices patterns), modelagem de dados relacional.

d) Arquitetura de aplicações para ambiente web, arquitetura em três camadas, modelo MVC.

e) Domain-driven design (DDD).

f) Integração entre sistemas: Mensageria, Web services, REST, EJB, Apache Camel.

g) Microservices, Hypermedia as the Engine of Application State - Hateoas.

h) Javascript e Typescript.

i) AngularJS 2 e Bootstrap.

j) HTML 5, ECMAScript 6 ou superior, CSS 3, Less e Sass.

k) User Experience (UX) e conceitos de usabilidade.

l) Interfaces responsivas.

m) NodeJS e Express.

n) Ecossistema Docker.

o) Kubernetes.

p) Springboot e Spring MVC.

q) Flyway ou Liquibase.

r) Vagrant.

s) Ansible ou Chef ou Puppet ou Saltstack.

t) Packer.

u) Conhecimentos básicos de Administração Unix.

v) Publicação de aplicações em plataformas como serviço (Platform as a service - PaaS).

w) Integração contínua (continuous integration), test-driven development (TDD), acceptance test-driven development (ATDD), especificação por exemplo, refactoring, entrega contínua (continuous delivery).

x) Testes de software: teste de unidade, integração, sistema/funcional, aceitação/estória, carga, desempenho, vulnerabilidade, usabilidade, acessibilidade. Automatização de testes funcionais, de unidade e de carga com ferramentas de software. Testes de unidade em Java com a ferramenta JUnit 4 ou superior. Automatização de testes funcionais com a ferramenta Selenium Webdriver 2.4 ou superior e com Protractor. Testes de carga com JMeter 2 ou superior.

y) Programação Java para Web: JEE 6 ou superior, JSE 8 ou superior, JSF versões

1.2 e 2.x, Hibernate 3 ou superior e Spring Framework 3 ou superior.

z) Análise estática de código com a ferramenta SonarQube 5.0 ousuperior. aa) Construção de consultas a bancos de dados em linguagem SQL.

bb) Conceitos de controle de versão de código-fonte e uso das ferramentas Subversion 1.6 ou superior e GIT 2 ou superior.

cc) Eclipse versão Mars ou superior. dd) Intellij.

6.1.3. Competências comportamentais:

a) Proatividade, capacidade de trabalho em equipe, capacidade de autogerenciamento e tomada de decisão, capacidade de comunicação (capacidade de se expressar oralmente e por escrito com precisão e clareza e de compreender com facilidade mensagens escritas e faladas).

6.2. O enquadramento de profissional no perfil “Analista-Programador Java de nível Pleno” para o âmbito desta contratação requer o atendimento, no mínimo, das seguintes exigências:

6.2.1. Formação acadêmica:

a) Graduação em curso de nível superior na área de Tecnologia da Informação, ou conclusão de qualquer curso de nível superior acompanhado de certificado de curso de pós-graduação (especialização, mestrado ou doutorado) na área de Tecnologia da Informação de, no mínimo, 360 horas.

6.2.2. Conhecimentos técnicos:

a) Linguagens de programação para plataforma Java. Ex: Java, Xxxxxx, Groovy.

b) Princípios e práticas de desenvolvimento de software ágil, incluindo o Manifesto Ágil, Scrum, Extreme Programming (XP) e Kanban.º

c) Análise de requisitos funcionais e não-funcionais, padrões de projeto (enterprise integration patterns, design patterns, microservices patterns), modelagem de dados relacional.

d) Arquitetura de aplicações para ambiente web, arquitetura em três camadas, modelo MVC.

e) Domain-driven design (DDD).

f) Integração entre sistemas: Mensageria, Web services, REST, EJB.

g) Javascript.

h) AngularJS e Bootstrap.

i) HTML 5, Javascript, CSS3.

j) Conceitos de usabilidade.

k) Spring MVC.

l) Publicação de aplicações em plataformas como serviço (Platform as a service - PaaS).

m) Integração contínua (continuous integration), test-driven development (TDD), acceptance test-driven development (ATDD), especificação por exemplo, refactoring, entrega contínua (continuous delivery).

n) Programação Java para Web: JEE 6 ou superior, JSE 8 ou superior, JSF versões

1.2 e 2.x, Hibernate 3 ou superior e Spring Framework 3 ou superior.

o) Análise estática de código com a ferramenta SonarQube 5.0 ou superior.

p) Testes de software: teste de unidade, integração, sistema/funcional, aceitação/estória, carga, desempenho, vulnerabilidade, usabilidade, acessibilidade. Automatização de testes funcionais, de unidade e de carga com ferramentas de software. Testes de unidade em Java com a ferramenta JUnit 4 ou superior. Automatização de testes funcionais com a ferramenta Selenium Webdriver 2.4 ou superior. Testes de carga com JMeter 2 ou superior.

q) Construção de consultas a bancos de dados em linguagem SQL.

r) Conceitos de controle de versão de código-fonte e uso das ferramentas Subversion 1.6 ou superior e GIT 2 ou superior.

s) Eclipse versão Mars ou superior.

t) Intellij.

6.2.3. Competências comportamentais:

a) Proatividade, capacidade de trabalho em equipe, capacidade de iniciativa e autogerenciamento, capacidade de comunicação (capacidade de se expressar oralmente e por escrito com precisão e clareza e de compreender com facilidade mensagens escritas e faladas).

6.3. No caso de ferramentas de apoio ao desenvolvimento de software, frameworks, bibliotecas de software e boas práticas de desenvolvimento, entre outros, que o Tribunal venha a adotar no seu processo de desenvolvimento, os profissionais de ambos os níveis terão prazo de 22 dias úteis para se adaptar ao seu uso.

6.3.1. Exemplos de ferramentas de apoio, frameworks, bibliotecas de software ou boas práticas as quais este item se refere:

a) JBehave / Concordion / Spock.

b) Continuous deployment.

c) NoSQL (ex: Elasticsearch, MongoDB, Hadoop).

d) Xxxxx.

e) React.

7. Medição do tamanho funcional do software desenvolvido

7.1. A medição do tamanho funcional do software desenvolvido para fins de aferição do cumprimento dos níveis de serviço (Anexo VI) será de responsabilidade da CONTRATADA e será realizada conforme Manual de Medição de Software do Tribunal (Anexo XI).

7.2. A medição deverá ser realizada por especialista da CONTRATADA certificado em Ponto de Função (Certified Function Point Specialist – CPFS) pelo International Function Point Users’ Group (IFPUG) e será posteriormente validada pelo TCU. Não será obrigatório que o especialista esteja ocupando um dos postos de trabalho previstos no contrato.

7.3. A realização desta atividade não reduzirá a produtividade esperada nem os demais níveis mínimos de serviço exigidos (Anexo VI - Níveis Mínimos de Serviço e Cálculo de Pagamento), devendo o seu custo ser incluído pela CONTRATADA no item V – “Lucros e despesas indiretas” de sua proposta de preços (Anexo III – Modelo de Proposta de Preços).

7.4. O profissional da CONTRATADA que estiver desenvolvendo o software deverá repassar as informações necessárias ao especialista que realizará a medição do seu tamanho funcional e também à equipe do TCU que fará a sua validação.

7.4.1. A seu critério, o TCU poderá validar e considerar para fins de aferição de níveis de serviço somente parte da medição em tamanho funcional apresentada pela empresa desde que a não conferência do restante não ocasione prejuízo no pagamento devido à CONTRATADA.

7.5. As medições realizadas pelo especialista da CONTRATADA deverão ser registradas no relatório de contagem, conforme modelo constante no Anexo XIII – Modelo de Relatório de Contagem Funcional Detalhada ou sistema de informações gerenciais que o Tribunal utilize. O Tribunal apenas aceitará relatórios de contagem assinados pelo especialista em pontos de função da CONTRATADA.

7.6. Caso o TCU identifique inconsistências no relatório de contagem, esse será devolvido à CONTRATADA para os devidos ajustes.

7.7. Divergências técnicas a respeito das contagens realizadas deverão ser sanadas diretamente entre o especialista da CONTRATADA e o TCU. Cabe ao Tribunal o posicionamento técnico final sobre o tema. Após definida a correta aplicação dos conceitos divergentes, a decisão tomada será registrada no Guia de Melhores Práticas de Contagem de Medição Funcional do TCU (Anexo XII) para futura referência, caso a mesma divergência ocorra novamente.

7.8. O Manual de Medição de Software do TCU (Anexo XI) pode sofrer atualizações em decorrência da evolução do IFPUG/CPM, da metodologia NESMA/EFPA e do surgimento de novos requisitos legais ou novos requisitos definidos pelos usuários gestores das aplicações. As atualizações no manual de contagem apenas serão aplicadas nas medições realizadas posteriormente à sua efetivação e comunicação à CONTRATADA.

7.9. A definição de fronteiras entre aplicações para fins de utilização da técnica de pontos de função é de responsabilidade exclusiva do TCU.

7.10. A evolução das aplicações, entrada em produção de novas aplicações ou mudanças de requisitos dos usuários podem representar alteração nas fronteiras das aplicações. Uma nova definição de fronteiras apenas será utilizada nas medições após a sua disponibilização para a CONTRATADA.

8. Acompanhamento dos serviços

8.1. A prestação do serviço será realizada de acordo com o processo de desenvolvimento de software previsto no Anexo V – Processo de Desenvolvimento de Projeto e de Manutenção de Software e será acompanhada por equipe técnica do TCU.

8.2. Além da fiscalização da execução do contrato, a equipe do Tribunal realizará também atividades inerentes aos demais papeis previstos no processo de desenvolvimento (ex: Scrum Master, Product Owner, etc) e ainda outras atividades que forem necessárias ao sucesso do projeto e à sustentabilidade do software produzido após o término do contrato.

8.3. Após a alocação de novo profissional da CONTRATADA para ocupação de posto de trabalho, caso o TCU identifique que o profissional não atenda aos requisitos de qualificação deste Termo de Referência, o Tribunal notificará a não-conformidade à CONTRATADA, que terá prazo de 10 (dez) dias úteis para adoção das providências cabíveis.

8.3.1. A qualificação do profissional será avaliada por meio de análise curricular e pela capacidade de execução de tarefas concretas no âmbito da prestação doserviço.

8.4. A alocação de profissional pela CONTRATADA que não atenda aos requisitos de qualificação técnica exigidos por 3 (três) vezes consecutivas no âmbito da mesma Ordem de Serviço ou por 6 (seis) vezes alternadas no período de 8 (oito) meses no âmbito do contrato poderá caracterizar inexecução parcial do contrato.

8.5. O Tribunal, a seu critério, em virtude de fatores como prazo do projeto, volume e ritmo de demandas, poderá solicitar a redução ou o acréscimo de postos de trabalho na OS, por meio de aditivo à Ordem de Serviço, respeitando os limites máximos permitidos.

8.6. Feita a solicitação de aumento ou redução dos postos de trabalho da Ordem de Serviço, o prazo que a CONTRATADA terá para efetuar a alteração demandada será o mesmo previsto para ocupação inicial dos postos de trabalho quando da abertura de Ordem de Serviço.

8.7. O Tribunal poderá, a seu critério, prorrogar este prazo, mediante solicitação da CONTRATADA devidamente justificada.

8.8. Caso não seja especificado prazo distinto, dependendo da situação particular, a CONTRATADA deverá resolver impropriedade identificada na execução do serviço contratado no prazo de 10 (dez) dias úteis.

9. Ausências e substituições de profissional da CONTRATADA

9.1. Todo profissional da CONTRATADA deve possuir a qualificação mínima exigida, conforme este Termo de Referência, inclusive aqueles alocados temporariamente pela empresa para cobrir ausências eventuais de outros postos de trabalho.

9.1.1. Em regra, o Tribunal não remunerará a CONTRATADA por postos de trabalho não ocupados, observadas as regras do Anexo VI – Níveis Mínimos de Serviço e Cálculo de Pagamento.

9.2. A taxa mínima exigida de ocupação dos postos de trabalho e sua relação com os níveis mínimos de serviço estão definidas no Anexo VI – Níveis Mínimos de Serviço e Cálculo de Pagamento.

10. Término da prestação do serviço

10.1. No interesse da Administração, o Tribunal poderá antecipar ou prorrogar o término da Ordem de Serviço, devendo comunicar a CONTRATADA com antecedência mínima de 22 (vinte e dois) dias úteis.

10.1.1. No caso de antecipação de término, durante o período entre a comunicação do Tribunal e o término efetivo do Ordem de Serviço, a CONTRATADA deverá continuar prestando o serviço regularmente, atendendo as demandas restantes e efetuando a transferência de conhecimento acerca do software produzido para a equipe do TCU.

11. Segurança da informação

11.1. Confidencialidade

11.1.1. A CONTRATADA deverá respeitar a classificação das informações produzidas ou custodiadas pelo Tribunal que vier a ter acesso por necessidade do serviço. Para isso a CONTRATADA deverá assinar o Termo de compromisso de manutenção de sigilo e respeito às normas de segurança vigentes no TCU de acordo com o modelo indicado no Anexo VIII.

11.1.2. A CONTRATADA deve solicitar aos seus profissionais alocados na execução dos serviços a assinatura de declaração de ciência das normas de segurança vigentes, de acordo com modelo indicado no Anexo VIII.

11.2. Boas práticas relativas à segurança da informação durante o desenvolvimento.

11.2.1. A CONTRATADA, na execução dos serviços contratados, deverá observar boas práticas relativas à segurança da informação, especialmente as indicadas nos normativos internos do TCU em todas as atividades executadas durante o ciclo de desenvolvimento das aplicações.

11.2.2. A CONTRATADA deve providenciar cópia para todos os profissionais alocados na execução dos serviços da Política Corporativa de Segurança da Informação do TCU e das demais normas disponibilizadas pelo Tribunal, bem como zelar pela observância dessas normas.

12. Local de execução

12.1. O serviço deverá ser prestado presencialmente na Sede do TCU em Brasília/DF.

13. Unidade responsável pelo Termo de Referência

13.1. Secretaria de Soluções de Tecnologia da Informação – STI.

ANEXO II – ORÇAMENTO ESTIMATIVO

GRUPO 1	Itens	Perfil do Posto de Trabalho	Qtd	Orgão	Turno / Carga Horária	Valor unitário mensal (R$)	Valor unitário anual (R$)	Valor total anual (R$)	Valor total para 24 meses (R$)
	1	Analista	43	TCU	Diurno	19.064,63	228.775,56	9.837.349,00	00.000.000,16
		Programador Java nível Sênior			(8h)
			9	CGU	Diurno (8h)	19.064,63	228.775,56	2.058.980,04	4.117.960,08
	2	Analista	15	TCU	Diurno	14.111,40	169.336,80	2.540.052,00	5.080.104,00
		Programador Java nível			(8h)
			6	CGU	Diurno	14.111,40	169.336,80	1.016.020,80	2.032.041,60
		Pleno			(8h)
	Total (R$)								30.904.803,84

Analista Programador Java nível Sênior
Jornada	40 h
Turno	Diurno
I - COMPOSIÇÃO DA REMUNERAÇÃO (R$)
Salário base			R$ 9.836,06
SUB-TOTAL DA REMUNERAÇÃO (R$)			R$ 9.836,06
TOTAL DA REMUNERAÇÃO (R$)			R$ 9.836,06
II - ENCARGOS SOCIAIS INCIDENTES SOBRE A REMUNERAÇÃO (R$)
GRUPO A - ENCARGOS
A.01 SEGURIDADE SOCIAL		0,00%	R$ 0,00
A.02 FGTS		8,00%	R$ 786,88
A.03 SESI/SESC		1,50%	R$ 147,54
A.04 SENAI/SENAC		1,00%	R$ 98,36
A.05 INCRA		0,20%	R$ 19,67
A.06 SEBRAE		0,60%	R$ 59,02
A.07 Salário Educação		2,50%	R$ 245,90
A.08 Riscos Ambientais do Trabalho – RAT x FAP		1,00%	R$ 98,36
TOTAL - GRUPO A - ENCARGOS		14,80%	R$ 1.455,74
XXXXX X
X.00 00x Salário		8,333%	R$ 819,64
B.02 Férias (sem o abono de 1/3)		8,333%	R$ 819,64
B.03 Xxxxx Xxxxxx Xxxxxxxxxx		1,918%	R$ 188,66
B.04 Auxílio Doença		1,370%	R$ 134,75

B.05 Acidente de Trabalho		0,329%	R$ 32,36
B.06 Faltas Legais		0,274%	R$ 26,95
B.07 Férias sobre Licença Maternidade		0,056%	R$ 5,51
B.08 Licença Paternidade		0,021%	R$ 2,07
TOTAL - GRUPO B		20,634%	R$ 2.029,57
GRUPO C
C.01 Xxxxx Xxxxxx Xxxxxxxxxx		0,417%	R$ 41,02
C.02 Indenização Adicional		0,167%	R$ 16,43
C.03 Indenização (rescisão sem justa causa – multa de 40% do FGTS)		3,200%	R$ 314,75
C.04 Indenização (rescisão sem justa causa – contribuição de 10% do FGTS)		0,800%	R$ 78,69
C.05 Abono de Férias - 1/3 constitucional		2,778%	R$ 273,25
C.06 Abono de Férias - 1/3 constitucional sobre licença maternidade		0,019%	R$ 1,87
TOTAL - GRUPO C		7,381%	R$ 726,00
GRUPO D
D.01 Incidência dos encargos do grupo A sobre o grupo B		3,054%	R$ 300,38
TOTAL - GRUPO D		3,054%	R$ 300,38
GRUPO E
E.01 Incidência do FGTS sobre o aviso prévio indenizado		0,033%	R$ 3,25
E.02 Incidência do FGTS sobre o período médio de afastamento superior a 15 dias motivado por acidente do trabalho		0,026%	R$ 2,56
E.03 Incidência de FGTS sobre férias 1/3 constitucional		0,222%	R$ 21,84
TOTAL - GRUPO E		0,281%	R$ 27,64
GRUPO F
F.01 Incidência dos encargos do Grupo A sobre os valores constantes da base de cálculo referente ao salário maternidade		0,099%	R$ 9,70
TOTAL - GRUPO F		0,099%	R$ 9,70
TOTAL - ENCARGOS SOCIAIS (R$)		46,248%	R$ 4.549,03
VALOR TOTAL DE REMUNERAÇÃO + ENCARGOS SOCIAIS (R$)			R$ 14.385,09
III - INSUMOS
Uniforme			R$ 0,00
Auxílio alimentação			R$ 369,60
Vale transporte			R$ 0,00
Desconto legal sobre transporte (máximo 6% do salário-base)			-R$ 0,00
TOTAL - INSUMOS (R$)			R$ 369,60

TOTAL DE REMUNERAÇÃO + ENCARGOS SOCIAIS + INSUMOS (R$)			R$ 14.754,69
IV - LDI E TRIBUTAÇÃO
LUCRO E DESPESAS INDIRETAS (LDI)
Despesas Administrativas/Operacionais		7,78%	R$ 765,25
Lucro		10,55%	R$ 1.037,70
TOTAL - LUCRO E DESPESAS INDIRETAS		18,33%	R$ 1.802,95
TRIBUTAÇÃO SOBRE FATURAMENTO
INSS		4,50%	R$ 857,91
ISS		5,00%	R$ 953,23
COFINS		3,00%	R$ 571,94
PIS		0,65%	R$ 123,92
TOTAL - TRIBUTAÇÃO SOBRE FATURAMENTO		13,15%	R$ 2.507,00
PREÇO MENSAL PARA 1 (UM) EMPREGADO (R$)			R$ 19.064,63
Quantidade de profissionais deste perfil			52
PREÇO MENSAL POR PERFIL PROFISSIONAL (R$)		R$ 991.360,76
PREÇO ANUAL POR PERFIL PROFISSIONAL (R$)		R$ 11.896.329,12

Analista Programador Java nível Pleno
Jornada	40 h
Turno	Diurno
I - COMPOSIÇÃO DA REMUNERAÇÃO (R$)
Salário base			R$ 7.222,19
SUB-TOTAL DA REMUNERAÇÃO (R$)			R$ 7.222,19
TOTAL DA REMUNERAÇÃO (R$)			R$ 7.222,19
II - ENCARGOS SOCIAIS INCIDENTES SOBRE A REMUNERAÇÃO (R$)
GRUPO A - ENCARGOS
A.01 SEGURIDADE SOCIAL		0,00%	R$ 0,00
A.02 FGTS		8,00%	R$ 577,78
A.03 SESI/SESC		1,50%	R$ 108,33
A.04 SENAI/SENAC		1,00%	R$ 72,22
A.05 INCRA		0,20%	R$ 14,44
A.06 SEBRAE		0,60%	R$ 43,33
A.07 Salário Educação		2,50%	R$ 180,55
A.08 Riscos Ambientais do Trabalho – RAT x FAP		1,00%	R$ 72,22

TOTAL - GRUPO A - ENCARGOS		14,80%	R$ 1.068,88
XXXXX X
X.00 00x Salário		8,333%	R$ 601,83
B.02 Férias (sem o abono de 1/3)		8,333%	R$ 601,83
B.03 Xxxxx Xxxxxx Xxxxxxxxxx		1,918%	R$ 138,52
B.04 Auxílio Doença		1,370%	R$ 98,94
B.05 Acidente de Trabalho		0,329%	R$ 23,76
B.06 Faltas Legais		0,274%	R$ 19,79
B.07 Férias sobre Licença Maternidade		0,056%	R$ 4,04
B.08 Licença Paternidade		0,021%	R$ 1,52
TOTAL - GRUPO B		20,634%	R$ 1.490,23
GRUPO C
C.01 Xxxxx Xxxxxx Xxxxxxxxxx		0,417%	R$ 30,12
C.02 Indenização Adicional		0,167%	R$ 12,06
C.03 Indenização (rescisão sem justa causa – multa de 40% do FGTS)		3,200%	R$ 231,11
C.04 Indenização (rescisão sem justa causa – contribuição de 10% do FGTS)		0,800%	R$ 57,78
C.05 Abono de Férias - 1/3 constitucional		2,778%	R$ 200,63
C.06 Abono de Férias - 1/3 constitucional sobre licença maternidade		0,019%	R$ 1,37
TOTAL - GRUPO C		7,381%	R$ 533,07
GRUPO D
D.01 Incidência dos encargos do grupo A sobre o grupo B		3,054%	R$ 220,55
TOTAL - GRUPO D		3,054%	R$ 220,55
GRUPO E
E.01 Incidência do FGTS sobre o aviso prévio indenizado		0,033%	R$ 2,38
E.02 Incidência do FGTS sobre o período médio de afastamento superior a 15 dias motivado por acidente do trabalho		0,026%	R$ 1,88
E.03 Incidência de FGTS sobre férias 1/3 constitucional		0,222%	R$ 16,03
TOTAL - GRUPO E		0,281%	R$ 20,29
GRUPO F
F.01 Incidência dos encargos do Grupo A sobre os valores constantes da base de cálculo referente ao salário maternidade		0,099%	R$ 7,13
TOTAL - GRUPO F		0,099%	R$ 7,13
TOTAL - ENCARGOS SOCIAIS (R$)		46,248%	R$ 3.340,15

VALOR TOTAL DE REMUNERAÇÃO + ENCARGOS SOCIAIS (R$)			R$ 10.562,34
III - INSUMOS
Uniforme			R$ 0,00
Auxílio alimentação			R$ 369,60
Vale transporte			R$ 0,00
Desconto legal sobre transporte (máximo 6% do salário-base)			-R$ 0,00
TOTAL - INSUMOS (R$)			R$ 369,60
TOTAL DE REMUNERAÇÃO + ENCARGOS SOCIAIS + INSUMOS (R$)			R$ 10.931,94
IV - LDI E TRIBUTAÇÃO
LUCRO E DESPESAS INDIRETAS (LDI)
Despesas Administrativas/Operacionais		7,78%	R$ 561,89
Lucro		10,55%	R$ 761,94
TOTAL - LUCRO E DESPESAS INDIRETAS		18,33%	R$ 1.323,83
TRIBUTAÇÃO SOBRE FATURAMENTO
INSS		4,50%	R$ 635,01
ISS		5,00%	R$ 705,57
COFINS		3,00%	R$ 423,34
PIS		0,65%	R$ 91,72
TOTAL - TRIBUTAÇÃO SOBRE FATURAMENTO		13,15%	R$ 1.855,64
PREÇO MENSAL PARA 1 (UM) EMPREGADO (R$)			R$ 14.111,40
Quantidade de profissionais deste perfil			21
PREÇO MENSAL POR PERFIL PROFISSIONAL (R$)			R$ 296.339,40
PREÇO ANUAL POR PERFIL PROFISSIONAL (R$)		R$ 3.556.072,80

Observações:

1. Remuneração mínima aceitável para profissional com perfil “Analista Programador Java nível Sênior”: R$ 9.448,51.

2. Remuneração mínima aceitável para o profissional com perfil “Analista Programador Java nível Pleno”: R$ 7.101,30.

3. Os patamares salariais mínimos previstos nos subitens 1 e 2 serão reajustados nos mesmos termos que os salários dos trabalhadores da categoria previstos na convenção coletiva de trabalho vinculada à proposta comercial da CONTRATADA.

4. O quantitativo de postos de trabalho é estimativo e não constitui compromisso de demanda por parte da CONTRATANTE.

XXXXX XXX – MODELO DE PROPOSTA DE PREÇOS

1. Tendo em vista as peculiaridades desta contratação, apresentam-se os esclarecimentos referentes às planilhas estimativas, os quais deverão ser observados pelas licitantes quando da elaboração de suas propostas de preços.

2. As licitantes deverão apresentar a proposta de preço sintética na forma do Quadro 1 deste anexo, juntamente com uma planilha de custos e formação de preços para cada perfil profissional, ou seja, uma planilha para o Analista Programador Java nível Sênior e outra para o Analista Programador Java nível Pleno utilizando o modelo também apresentado neste anexo.

3. Na elaboração das planilhas as licitantes deverão observar convenção coletiva de trabalho, ou outra norma coletiva mais benéfica, aplicável à categoria envolvida na contratação e à qual a licitante esteja obrigada em convenção coletiva de trabalho, ou outra norma coletiva mais benéfica, aplicável à categoria envolvida na contratação e à qual a licitante esteja obrigada.

4. O Anexo IV contém planilha de exemplo com memória de cálculo explicativa para subsidiar a elaboração da proposta de preço pela licitante. Cabe destacar que valores identificados como exemplificativos e estimativos e demais elementos dependentes de aspectos particulares da empresa (ex.: regime tributário) deverão ser ajustados pela licitante, observados os dispositivos aplicáveis deste edital e a legislação vigente.

5. Na hipótese de eventual repactuação do contrato, somente serão considerados os itens previstos nas respectivas planilhas.

6. Ainda que, em acordo ou convenção coletiva da categoria, haja previsão de reajuste escalonado de salários, a CONTRATADA aplicará aos salários dos empregados que prestam serviços à CONTRATANTE os mesmos índices concedidos na repactuação contratual, independentemente da data de admissão do empregado nos quadros da CONTRATADA.

7. O LDI (Lucros e Despesas Indiretas) constante das planilhas de composição de custos e formação de preços engloba o lucro e as despesas administrativas e operacionais (Acórdão 2.369/2011-TCU-Plenário).

8. O item B.03 - Xxxxx prévio trabalhado será zerado após o primeiro ano de vigência do contrato.

Quadro 1 – Modelo de proposta de preço sintética

Perfil do Posto de Trabalho	Qtd	Turno / Carga Horária	Valor unitário mensal (R$)	Valor unitário anual (R$)	Valor total anual (R$)	Valor total para 24 meses (R$)
Analista Programador Java nível Sênior		Diurno (8h)
Analista Programador Java nível Pleno		Diurno (8h)
Total (R$)

MODELO DE PLANILHA DE CUSTOS E FORMAÇÃO DE PREÇOS

(nº do item do objeto - perfil profissional)
Jornada	40 h
Turno	Diurno
I - COMPOSIÇÃO DA REMUNERAÇÃO
Salário base			R$
SUB-TOTAL DA REMUNERAÇÃO			R$
TOTAL DA REMUNERAÇÃO			R$
II - ENCARGOS SOCIAIS INCIDENTES SOBRE A REMUNERAÇÃO
GRUPO A - ENCARGOS
A.01 SEGURIDADE SOCIAL		%	R$
A.02 FGTS		%	R$
A.03 SESI/SESC		%	R$
A.04 SENAI/SENAC		%	R$
A.05 INCRA		%	R$
A.06 SEBRAE		%	R$
A.07 Salário Educação		%	R$
A.08 Riscos Ambientais do Trabalho – RAT x FAP		%	R$
TOTAL - GRUPO A - ENCARGOS		%	R$
GRUPO B
B.01 13º Salário		%	R$
B.02 Férias (sem o abono de 1/3)		%	R$
B.03 Xxxxx Xxxxxx Trabalhado		%	R$
B.04 Auxílio Doença		%	R$
B.05 Acidente de Trabalho		%	R$
B.06 Faltas Legais		%	R$
B.07 Férias sobre Licença Maternidade		%	R$
B.08 Licença Paternidade		%	R$
TOTAL - GRUPO B		%	R$
GRUPO C
C.01 Xxxxx Xxxxxx Xxxxxxxxxx		%	R$
C.02 Indenização Adicional		%	R$
C.03 Indenização (rescisão sem justa causa – multa de 40% do FGTS)		%	R$
C.04 Indenização (rescisão sem justa causa – contribuição de 10% do FGTS)		%	R$
C.05 Abono de Férias - 1/3 constitucional		%	R$
C.06 Abono de Férias - 1/3 constitucional sobre licença maternidade		%	R$
TOTAL - GRUPO C		%	R$

GRUPO D
D.01 Incidência dos encargos do grupo A sobre o grupo B		%	R$
TOTAL - GRUPO D		%	R$
GRUPO E
E.01 Incidência do FGTS sobre o aviso prévio indenizado		%	R$
E.02 Incidência do FGTS sobre o período médio de afastamento superior a 15 dias motivado por acidente do trabalho		%	R$
E.03 Incidência de FGTS sobre férias 1/3 constitucional		%	R$
TOTAL - GRUPO E		%	R$
GRUPO F
F.01 Incidência dos encargos do Grupo A sobre os valores constantes da base de cálculo referente ao salário maternidade		%	R$
TOTAL - GRUPO F		%	R$
TOTAL - ENCARGOS SOCIAIS		%	R$
VALOR TOTAL DE REMUNERAÇÃO + ENCARGOS SOCIAIS			R$
III - INSUMOS
Uniforme			R$
Auxílio alimentação			R$
Vale transporte			R$
Desconto legal sobre transporte (máximo 6% do salário-base)			R$
TOTAL - INSUMOS			R$
TOTAL DE REMUNERAÇÃO + ENCARGOS SOCIAIS + INSUMOS			R$
V - LDI E TRIBUTAÇÃO
LUCRO E DESPESAS INDIRETAS (LDI)
Despesas Administrativas/Operacionais		%	R$
Lucro		%	R$
TOTAL - LUCRO E DESPESAS INDIRETAS		%	R$
TRIBUTAÇÃO SOBRE FATURAMENTO
INSS		%	R$
ISS		%	R$
COFINS		%	R$
PIS		%	R$
TOTAL - TRIBUTAÇÃO SOBRE FATURAMENTO		%	R$

PREÇO MENSAL PARA 1 (UM) PROFISSIONAL (POSTO)		R$
Quantidade de profissionais deste perfil		qtde
PREÇO MENSAL POR PERFIL PROFISSIONAL (R$)		R$
PREÇO ANUAL POR PERFIL PROFISSIONAL (R$)		R$

ANEXO IV – EXEMPLO DE PLANILHA DE CUSTOS E FORMAÇÃO DE PREÇOS COM MEMÓRIA DE CÁLCULO

Analista Programador Java nível Sênior
Jornada	40 h
Turno	Diurno
I - COMPOSIÇÃO DA REMUNERAÇÃO (R$)
Salário base			R$ 9.836,06
SUB-TOTAL DA REMUNERAÇÃO (R$)			R$ 9.836,06
TOTAL DA REMUNERAÇÃO (R$)			R$ 9.836,06
II - ENCARGOS SOCIAIS INCIDENTES SOBRE A REMUNERAÇÃO (R$)
GRUPO A - ENCARGOS
A.01 SEGURIDADE SOCIAL		0,00%	R$ 0,00
A.02 FGTS		8,00%	R$ 786,88
A.03 SESI/SESC		1,50%	R$ 147,54
A.04 SENAI/SENAC		1,00%	R$ 98,36
A.05 INCRA		0,20%	R$ 19,67
A.06 SEBRAE		0,60%	R$ 59,02
A.07 Salário Educação		2,50%	R$ 245,90
A.08 Riscos Ambientais do Trabalho – RAT x FAP		1,00%	R$ 98,36
TOTAL - GRUPO A - ENCARGOS		14,80%	R$ 1.455,74
XXXXX X
X.00 00x Salário		8,333%	R$ 819,64
B.02 Férias (sem o abono de 1/3)		8,333%	R$ 819,64
B.03 Xxxxx Xxxxxx Xxxxxxxxxx		1,918%	R$ 188,66
B.04 Auxílio Doença		1,370%	R$ 134,75
B.05 Acidente de Trabalho		0,329%	R$ 32,36
B.06 Faltas Legais		0,274%	R$ 26,95
B.07 Férias sobre Licença Maternidade		0,056%	R$ 5,51
B.08 Licença Paternidade		0,021%	R$ 2,07
TOTAL - GRUPO B		20,634%	R$ 2.029,57
GRUPO C
C.01 Xxxxx Xxxxxx Xxxxxxxxxx		0,417%	R$ 41,02
C.02 Indenização Adicional		0,167%	R$ 16,43
C.03 Indenização (rescisão sem justa causa – multa de 40% do FGTS)		3,200%	R$ 314,75

C.04 Indenização (rescisão sem justa causa – contribuição de 10% do FGTS)		0,800%	R$ 78,69
C.05 Abono de Férias - 1/3 constitucional		2,778%	R$ 273,25
C.06 Abono de Férias - 1/3 constitucional sobre licença maternidade		0,019%	R$ 1,87
TOTAL - GRUPO C		7,381%	R$ 726,00
GRUPO D
D.01 Incidência dos encargos do grupo A sobre o grupo B		3,054%	R$ 300,38
TOTAL - GRUPO D		3,054%	R$ 300,38
GRUPO E
E.01 Incidência do FGTS sobre o aviso prévio indenizado		0,033%	R$ 3,25
E.02 Incidência do FGTS sobre o período médio de afastamento superior a 15 dias motivado por acidente do trabalho		0,026%	R$ 2,56
E.03 Incidência de FGTS sobre férias 1/3 constitucional		0,222%	R$ 21,84
TOTAL - GRUPO E		0,281%	R$ 27,64
GRUPO F
F.01 Incidência dos encargos do Grupo A sobre os valores constantes da base de cálculo referente ao salário maternidade		0,099%	R$ 9,70
TOTAL - GRUPO F		0,099%	R$ 9,70
TOTAL - ENCARGOS SOCIAIS (R$)		46,248%	R$ 4.549,03
VALOR TOTAL DE REMUNERAÇÃO + ENCARGOS SOCIAIS (R$)			R$ 14.385,09
III - INSUMOS
Uniforme			R$ 0,00
Auxílio alimentação			R$ 369,60
Vale transporte			R$ 0,00
Desconto legal sobre transporte (máximo 6% do salário-base)			-R$ 0,00
TOTAL - INSUMOS (R$)			R$ 369,60
TOTAL DE REMUNERAÇÃO + ENCARGOS SOCIAIS + INSUMOS (R$)			R$ 14.754,69
V - LDI E TRIBUTAÇÃO
LUCRO E DESPESAS INDIRETAS (LDI)
Despesas Administrativas/Operacionais		7,78%	R$ 765,25
Lucro		10,55%	R$ 1.037,70
TOTAL - LUCRO E DESPESAS INDIRETAS		18,33%	R$ 1.802,95

TRIBUTAÇÃO SOBRE FATURAMENTO
INSS		4,50%	R$ 857,91
ISS		5,00%	R$ 953,23
COFINS		3,00%	R$ 571,94
PIS		0,65%	R$ 123,92
TOTAL - TRIBUTAÇÃO SOBRE FATURAMENTO		13,15%	R$ 2.507,00
PREÇO MENSAL PARA 1 (UM) EMPREGADO (R$)			R$ 19.064,63
Quantidade de profissionais deste perfil			52
PREÇO MENSAL POR PERFIL PROFISSIONAL (R$)			R$ 991.360,76
PREÇO ANUAL POR PERFIL PROFISSIONAL (R$)		R$ 11.896.329,12

Memória de Cálculo

1. Mão de Obra – Remuneração

1.1. Salário exemplificativo de R$ 9.836,06 para o perfil profissional.

2. Encargos sociais incidentes sobre a remuneração

2.1. Cálculos do Grupo A

Item	%	Fundamento
A.01 – SEGURIDADE SOCIAL	0,000%	Lei 12.546/2011
A.02 – FGTS	8,000%	Art. 15, Lei nº 8.036/90 e Art. 7º, III, CF.
A.03 – SESI/SESC	1,500%	Art. 30, Lei 8.036, de 11 de maio de 1990.
A.04 – SENAI/SENAC	1,000%	Art. 1º, caput, Decreto-Lei 6.246, de 1944 (SENAI) e art. 4º, caput do Decreto-Lei 8.621, de 1946. (SENAC).
A.05 – INCRA	0,200%	Art. 1°, I, 2 c/c art. 3°, ambos do Decreto-Lei 1.146, de 31 de dezembro de 1970.
A.06 – SEBRAE	0,600%	Art. 8º, Lei 8.029, de 12 de abril de 1990.
A.07 – Salário Educação	2,500%	Art. 3º, Inciso I, Decreto 87.043, de 22 de março de 1982.

A.08 – Riscos Ambientais do Trabalho RAT X FAP:

A.08 = RAT x FAP, em que:

RAT – 1% (Desenvolvimento de programas de computador sob encomenda - código 6201-5/00.

Anexo V do Decreto nº 3.048/1999); FAP – 1,000 (Padrão).

A.08 = RAT x FAP = 1 x 1,000 = 1,000%. Encargos do Grupo A= 14,80%

Observação: A licitante deve preencher o item A.08 das planilhas de composição de custos e formação de preços com o valor de seu FAP, a ser comprovado no envio de sua proposta adequada ao lance vencedor, mediante apresentação da GFIP ou outro documento apto a fazê- lo. Caso o FAP seja declarado acima de 1,000, o custo a maior deverá ser suportado pela CONTRATADA.

2.2. Cálculos do Grupo B

Item	%	Memória de cálculo	Fundamento
B.01 – 13º Salário	8,333%	[(1/12)] = 8,333%	Art. 7º, VIII, CF/88
B.02 – Férias	8,333%	[(1/12]] = 8,333%	Art. 7º, XVII, CF/88
B.03 – Aviso prévio trabalhado1	1,918%	(7/365) = 1,918 %	Art. 7º, XXI, CF/88, 477, 487 e ss. da CLT
B.04 – Auxílio Doença2	1,370%	{[(5/365)} = 1,370%	Art. 59 e ss. da Lei nº 8.213/91
B.05 – Acidente de trabalho3	0,329%	(15/365)x0,08 = 0,329%	Art. 19 a 23 da Lei nº 8.213/91
B.06 – Faltas legais4	0,274%	(1/365) = 0,274%	Art. 473 da CLT
B.07 – Férias sobre licença maternidade5	0,056%	[(1/12)x0,02x(4/12)] = 0,056%	Impacto do item férias sobre a licença maternidade
B.08 – Licença paternidade6	0,021%	(5/365)x0,015 = 0,021%	Art. 7º, XIX, CF/88 e 10, §1º, da ADCT
Total	20,634 %

1 Redução de 7 dias ou de 2h por dia para 100 % dos empregados. Percentual relativo a contrato de 12 (doze) meses.

2 Estimativa de 5 (cinco) dias de licença por ano.

3 Estimativa de 1 (uma) licença de 15 (quinze) dias por ano para 8% (oito por cento) dos empregados.

4 Estimativa de 1 (uma) ausência por ano.

5 Estimativa de 2% (dois por cento) dos empregados usufruindo de 4 (quatro) meses de licença por ano.

6 Estimativa de 1,5% (um inteiro e cinco décimos por cento) dos empregados usufruindo 5 (cinco) dias da licença por ano.

2.3. Cálculos do Grupo C

Item	%	Memória de cálculo	Fundamento
C.01 – Aviso prévio indenizado1	0,417%	[0,05x(1/12)] = 0,417%	Art. 7º, XXI, CF/88, 477, 487 e ss. CLT
C.02 – Indenização adicional2	0,167%	[0,02x(1/12)] = 0,167%	Art. 9º da Lei nº 7.238, de 1984
C.03 – Indenização 40% FGTS (100%)3	3,200%	(1x0,40x0,08) = 3,200%	Art. 18, §1º da Lei 8.036/90
C.04 – Indenização 10% FGTS (100%)4	0,800%	(1x0,10x0,08) = 0,800%	Art. 1º da Lei Complementar nº 110/01
C.05 – Abono de Férias - 1/3 constitucional	2,778%	[(1/3)/12] = 2,778%	Art. 7º, XVII, CF/88
C.06 – Abono de Férias - 1/3 constitucional sobre licença maternidade	0,019%	[(1/3)/12]x0,02x(4/12)] = 0,019%	Art. 7º, XVII, CF/88
Total	7,381%

1 Estimativa de que 5% (cinco por cento) dos empregados serão substituídos durante um ano.

2 Estimativa de que 2% (dois por cento) dos empregados serão demitidos em situação de recebimento de indenização adicional.

3 Multa de 40% do FGTS em relação aos trabalhadores contratados.

4 Contribuição de 10% do FGTS em relação aos trabalhadores contratados.

2.4. Cálculos do Grupo D

D.01 – Encargos do Grupo A sobre os Encargos do Grupo B D.01 = 0,148 x 0,20634 = 3,054%;

2.5. Cálculos do Grupo E

Item	%	Memória de cálculo	Fundamento
E.01 – Inc. do FGTS exclusivamente sobre o aviso prévio indenizado.	0,033%	A.02 x C.01 = (0,08x0,00417) = 0,033%	Súmula nº 305 do TST
E.02 – FGTS sobre afastamento superior a 15 dias por acidente de trabalho.1	0,026%	A.02 x B.05 = (0,08x0,0033) = 0,026%	Lei 8.036, de 1990, art. 15, §5º

E.03 – FGTS sobre abono de Férias - 1/3 constitucional.	0,222%	A.02 x C.05 = (0,08x0,02778) = 0,222%	Lei 8.036, de 1990, art. 15, §5º
Total	0,281%

1 Estimativa de que 8% (oito por cento) dos empregados sofrerão acidentes durante o ano, com ausência média de 30 dias durante o ano. O percentual do FGTS (8%) será aplicado somente sobre os 15 dias restantes do afastamento, porque os 15 primeiros dias já foram calculados no item B.05.

2.6. Cálculos do Grupo F

F.01 – Encargos do Grupo A sobre salário maternidade

F.01 = (Encargos Grupo A) x (Remuneração) x 4/12 x 2%, em que:

Encargos do Grupo A = 0,1480

4/12 = período de 4 meses de licença em um ano;

2% = Estimativa de que 2% dos empregados usufruirão da licença maternidade de 4 meses em um ano.

F.01 = 0,34800x(4/12)x(2/100) = 0,099%;

Total Encargos Sociais = Total Grupo A (14,800%) + Total Grupo B (20,634%) + Total Grupo C (7,381%) + Total Grupo D (3,054%) + Total Grupo E (0,281%)+ Total Grupo F (0,099%) = 46,248%

3. Insumos:

3.1. Uniformes: Não há, da parte da CONTRATANTE, exigência de uniforme para o profissional terceirizado.

3.2. Auxílio Alimentação: Valor exemplificativo.

3.3. Vale transporte: Não foi previsto vale transporte em função do valor estimado da remuneração do profissional.

3.3.1. Dedução legal do vale transporte: O valor da dedução do vale transporte deve obedecer o art. 4º, parágrafo único da Lei 7.418, de 16 de dezembro de 1985 (desconto máximo de 6% do salário-base). Dado este desconto máximo permitido, não foi previsto vale transporte em função do valor estimado da remuneração do profissional.

4. Lucro e Despesas Indiretas e Tributação sobre Faturamento

Lucro e Despesas Indiretas - LDI:

4.1. Para fins de estimativa da CONTRATANTE, em Lucro e Despesas Indiretas - LDI, foram consideradas as despesas administrativas e operacionais e a margem de lucro. Os valores de 7,78% e 10,55% para estes itens, respectivamente, são exemplificativos e devem ser ajustados na proposta de preço da licitante.

4.1.1. Obs.: Eventuais custos não previstos expressamente na memória de cálculo devem ser cobertos pelo LDI (Lucro e Despesas Indiretas).

Tributação sobre Faturamento

4.2. Os tributos (ISS, COFINS e PIS) foram definidos utilizando o regime de tributação de Lucro PRESUMIDO. A licitante deve elaborar sua proposta e, por conseguinte, sua planilha com base no regime de tributação ao qual estará submetida durante a execução docontrato.

ANEXO V – PROCESSO DE DESENVOLVIMENTO DE PROJETO E DE MANUTENÇÃO DE SOFTWARE

1 Introdução

1.1 O processo de desenvolvimento de software que será utilizado no âmbito deste contrato é baseado no Scrum e no Kanban e contém práticas de Extreme Programming (XP).

1.2 Considerando que estes modelos e práticas são de amplo conhecimento e se encontram descritos em vasta literatura, trataremos neste documento das particularidades do processo adotado no TCU.

2 Papéis e responsabilidades

2.1 Product Owner (PO)

2.1.1 O papel de Product Owner (PO) será exercido, em regra, por representante da unidade gestora da solução de TI a ser desenvolvida.

2.2 ScrumMaster

2.2.1 O papel de ScrumMaster será exercido por servidor do TCU.

2.3 Equipe de desenvolvimento

2.3.1 O papel de equipe de desenvolvimento será exercido pelos profissionais da CONTRATADA.

2.3.2 A equipe de desenvolvimento será responsável por executar as tarefas do backlog do produto respeitando a priorização definida pelo Product Owner (PO).

2.3.3 A distribuição de tarefas priorizadas do backlog do produto entre os seus membros é responsabilidade da própria equipe de desenvolvimento.

2.3.4 A equipe de desenvolvimento deve entrar em contato com a equipe do TCU sempre que houver dúvidas acerca de tarefas a serem executadas e que for necessário obter feedback para produto de software desenvolvido.

2.3.5 Durante todo o projeto, a equipe de desenvolvimento deverá transferir continuamente conhecimentos acerca do sistema em construção para a equipe do TCU.

2.4 Equipe técnica de apoio ao projeto

2.4.1 O ScrumMaster contará com equipe técnica do Tribunal para apoiá-lo na condução do projeto, para absorver o conhecimento acerca do sistema e para executar outras tarefas que

visem o sucesso do projeto e a sustentabilidade do sistema produzido após o término do contrato.

2.4.2 O tamanho da desta equipe de apoio deverá ser dimensionada considerando fatores como as características técnicas e de negócio do projeto, o tamanho da equipe técnica da CONTRATADA, o ritmo do projeto, entre outros.

2.4.3 A equipe técnica será responsável também por exigir respeito aos padrões técnicos de desenvolvimento de software adotados no Tribunal e adotar as providências cabíveis em caso de descumprimento.

3 Backlog do Produto

3.1 Os requisitos do software a ser desenvolvido serão decompostos em estórias de usuários que, por sua vez, poderão ser subdivididas em tarefas. Este refinamento será feito no decorrer do projeto de acordo com a prioridade dos requisitos do software.

3.2 Os requisitos do software, as estórias de usuários e as tarefas compõem o backlog do produto.

3.3 Também são incluídas no backlog do produto eventuais manutenções corretivas e adaptativas que venham a ser necessárias no software.

3.4 O backlog do produto será priorizado pelo Product Owner (PO).

4 Sprints

4.1 As sprints terão duração entre 1 a 4 semanas, de acordo com as características do projeto específico.

4.2 A duração das sprints e o dia e a duração das reuniões de planejamento, revisão e retrospectiva das sprints serão definidas pelo TCU no início do projeto. Estas definições poderão ser alteradas posteriormente, a critério do Tribunal, mediante comunicação prévia à equipe de desenvolvimento da CONTRATADA.

4.3 O critério para aceitar cada tarefa como “pronta” (finalizada, done) será definido para cada projeto e, quando necessário, de forma particular para cada tarefa.

5 Entrega e Homologação Contínuas

5.1 Seguindo a prática de entrega contínua (continuous delivery), incrementos ao software serão constantemente entregues para homologação do Tribunal.

5.2 Os incrementos aceitos comporão a versão homologada do software, enquanto os incrementos rejeitados retornarão para o backlog do produto.

6 Principais boas práticas de desenvolvimento adotadas

6.1 Domain-driven design (DDD), integração contínua (continuous integration), test-driven development (TDD), acceptance test-driven development (ATDD), especificação por exemplo, refactoring, entrega contínua (continuous delivery), programação em pares, behaviour driven development (BDD).

7 Principais ferramentas de apoio, frameworks e bibliotecas de software adotados

7.1 Eclipse versão Kepler, Intellij, AngularJS, Spring 3, Hibernate 3, Subversion 1.6, Concordion 1.1, JUnit 4, JMeter 2, Selenium Webdriver 2.4, JSF versões 1.2 e 2.0, SonarQube 5.0, Jenkins 1.5, GIT 2, HSQLDB (HyperSQL DataBase) 2.3.

8 Plataforma de infraestrutura de aplicações

8.1 Red Hat JBoss Enteprise Application Platform versão 6.

8.2 Undertow provido pelo Spring Boot.

8.3 Tomcat provido pelo Spring Boot.

8.4 Jetty provido pelo Spring Boot.

8.5 Nginx.

ANEXO VI – NÍVEIS MÍNIMOS DE SERVIÇO E CÁLCULO DE PAGAMENTO

1 Níveis de serviço

1.1 Índice de Evolução do Sistema (IES)

1.1.1 Os níveis de serviço de OS do tipo PROJETO serão representados por indicador de desempenho denominado Índice de Evolução do Sistema (IES), que será a média ponderada de 3 componentes:

Componente do IES	Peso
Índice de Produtividade (IP)	0,45
Índice de Qualidade (IQ)	0,40
Avaliação do Product Onwer (APO)	0,15

1.1.2 O Índice de Evolução do Sistema - IES será aferido em períodos de 1 a 2 meses, em momento escolhido pelo TCU, e obrigatoriamente ao término da Ordem de Serviço.

1.1.3 Adicionalmente, há níveis mínimos de serviço exigidos para alguns componentes do IES isoladamente, conforme item 1.1.28 – “Descontos a serem aplicados de acordo com o índice de cumprimento dos níveis de serviço”.

1.1.4 Índice de Produtividade (IP)

1.1.5 O Índice de Produtividade (IP) é composto por dois itens: Item de Controle de Produtividade em Tamanho Funcional (ICPTF) e Item de Controle de Produtividade em Linhas de Código (ICPLC). Estes itens serão aferidos comparando a produtividade no período de aferição com a produtividade-base estabelecida neste Anexo do Edital.

1.1.6 A divisão do peso do IP entre seus dois componentes encontra-se no quadro a seguir:

Componente do IP	Peso
Item de Controle de Produtividade em Tamanho Funcional (ICPTF)	0,25
Item de Controle de Produtividade em Linhas de Código (ICPLC)	0,20
Peso Total do IP	0,45

1.1.7 A produtividade será estabelecida em termos de dias de efetiva ocupação de posto de trabalho, unidade esta que será identificada por DIA-DESENVOLVEDOR.

1.1.7.1 Por exemplo, se em um dado período de aferição tivermos 40 dias de efetiva ocupação de 6 postos de trabalho, haverá neste período 240 DIAS-DESENVOLVEDOR.

1.1.7.2 Não serão considerados aqueles dias em que não houver efetiva prestação do serviço, como finais de semana e feriados, em regra.

1.1.8 Item de Controle de Produtividade em Tamanho Funcional (ICPTF)

1.1.9 Para calcular o Item de Controle de Produtividade em Tamanho Funcional (ICPTF) deverá ser medido primeiro o Tamanho da Evolução Funcional (TEF), que é o quantitativo de pontos de função correspondente aos aprimoramentos realizados na versão atual do software em relação à versão anterior, de acordo com o Manual de Medição de Software do TCU (Anexo XI).

1.1.9.1 Por versão atual considera-se aquela versão do software que contiver os aprimoramentos homologados pelo Product Owner (PO) até a data final do período escolhido pelo TCU para aferição do Índice de Evolução do Sistema (IES).

1.1.9.2 Por versão anterior do sistema entende-se aquela analisada e medida na aferição imediatamente anterior do IES.

1.1.9.3 Eventuais aprimoramentos no software, como inclusões, alterações ou exclusões de funcionalidades, que forem realizadas em versões intermediárias do software e que não sejam identificáveis ao se comparar a versão atual com a versão anterior do sistema não serão consideradas no cálculo do TEF e, consequentemente, do ICPTF.

1.1.9.3.1 Para ilustrar esta regra, consideremos o seguinte cenário:

a) O TCU realizou a primeira aferição do IES;

b) Na próxima sprint foi acrescentado o campo C1-A na tela T1, os campos C2-A e C2-B na tela T2 e o campo C3-A na tela T3.

Tela	Campo(s) acrescentados em relação à versão anterior da tela
T1	X0-X
X0	X0-X / X0-X
X0	X0-X

c) O Product Owner (PO) homologou as alterações realizadas na sprint.

d) Na próxima sprint, o campo C2-B da tela T2 foi excluído, foi acrescentado o campo C3-B na tela T3 e não houve alteração na tela T1.

Tela	Campo(s) acrescentados em relação à versão anterior da tela
T1	X0-X
X0	X0-X / X0X
X0	X0-X / X0-X

e) O PO novamente homologou estas alterações.

f) TCU decidiu aferir o IES novamente.

g) Nesta nova aferição, serão consideradas somente a inclusão do campo C1-A na tela T1, a inclusão do campo C2-A na tela T2 e a inclusão dos campos C3-A e C3-B na tela T3 para efeito do cálculo do TEF. Ou seja, nem a inclusão do campo C2-B na tela T2 e nem a sua posterior exclusão serão consideradas para fins de apuração da produtividade em tamanho funcional.

Tela	Campo(s) acrescentados em relação à versão anterior da tela
T1	X0-X
X0	X0-X
X0	X0-X / X0-X

1.1.10 A produtividade no período em tamanho funcional será obtida dividindo o Tamanho da Evolução Funcional (TEF) do sistema pela quantidade de DIAS-DESENVOLVEDOR do período de aferição.

1.1.11 O Item de Controle de Produtividade em Tamanho Funcional (ICPTF) será calculado dividindo a produtividade no período em tamanho funcional pela produtividade-base estabelecida neste Anexo do Edital.

1.1.12 Caso o resultado do cálculo do ICPTF seja maior que 150%, será adotado 150% para o valor deste Item de Controle. Caso a soma do ICPTF com o ICPLC seja maior que 100% do IP, será considerado 100% do valor do IP.

1.1.13 Item de Controle de Produtividade em Linhas de Código (ICPLC)

1.1.14 Para calcular o Item de Controle de Produtividade em Linhas de Código (ICPLC) primeiro será contabilizada a quantidade de linhas de código alteradas no software no período de aferição, com apoio da ferramenta GIT (xxxxx://xxx-xxx.xxx/).

1.1.14.1 É considerada linha de código alterada uma nova linha inserida ou uma linha existente que foi modificada. Não serão contabilizadas linhas removidas, linhas em branco e alterações com intuito de somente aumentar artificialmente o ICPLC.

1.1.15 A produtividade no período em linhas de código será obtida dividindo essa quantidade de linhas de código pela quantidade de DIAS-DESENVOLVEDOR do período de aferição.

1.1.16 O Item de Controle de Produtividade em Linhas de Código (ICPLC) será calculado dividindo a produtividade no período em linhas de código pela produtividade-base estabelecida neste Anexo do Edital.

1.1.17 Caso o resultado do cálculo do ICPLC seja maior que 150%, será adotado 150% para o valor deste Item de Controle. Caso a soma do ICPTF com o ICPLC seja maior que 100% do IP, será considerado 100% do valor do IP.

1.1.18 Índice de Qualidade (IQ)

1.1.19 O Índice de Qualidade (IQ) será obtido a partir de indicadores de qualidade do código- fonte do software aferidos com apoio da ferramenta SonarQube, versão 5.0 ou superior.

1.1.20 Cada indicador possui meta a ser alcançada.

1.1.21 Os indicadores de qualidade do código-fonte com suas respectivas metas estão relacionados no quadro a seguir:

Grupo	Indicador	Unidade	Meta
Projeto	Complexity / file	média total	<= 10
	Complexity / class	média total	<= 10
	Complexity / function	média total	<= 3
	Duplications	%	<= 4%
	Security Issue Tags	unidades	=0

	Technical Debt ratio	%	<= 2,5%
	SQALE RATING	Nota	=A
Violações de código (possíveis bugs, estilo de codificação, más práticas de codificação):	Critical Issues	unidades	=0
	Blocker Issues	unidades	=0
Indicadores relacionados a testes	Unit Tests Coverage - camada negócio / Impl	%	>=70%
	Unit Test Success	%	>=100%
	Skipped Tests	unidades	=0

1.1.22 O Índice de Qualidade (IQ) será calculado dividindo a quantidade de indicadores que alcançaram as suas respectivas metas pelo quantitativo total de indicadores.

1.1.23 Caso algum indicador seja depreciado ou removido em futura versão do SonarQube que venha a ser adotada pelo Tribunal e não seja substituído por indicador equivalente nesta mesma ferramenta, ele deixará de ser considerado para fins de aferição do cumprimento de níveis mínimos de serviço no âmbito desta contratação.

1.1.24 Problemas de qualidade no código-fonte do software pré-existentes à abertura da OS serão desconsiderados na aferição do Índice de Qualidade (IQ).

1.1.25 Avaliação do Product Owner (APO)

1.1.26 Considerando os princípios e valores do desenvolvimento ágil, o Product Owner (PO) do projeto deverá avaliar os seguintes aspectos da prestação do serviço.

Item	Avaliação
1 - Periodicidade de entrega de software para homologação (preferência por períodos entre 1 a 4 semanas)	Entregas realizadas em período igual ou menor a 4 semanas: [ ] 4 – Todas [ ] 3 – Maioria [ ] 2 – Metade [ ] 1 – Minoria [ ] 0 – Nenhuma

2 - Receptividade da equipe de desenvolvimento a mudança de requisitos, mesmo em estágio avançado de desenvolvimento	[ ] 4 – Não houve resistência à nenhuma solicitação de mudança de requisitos [ ] 3 – Não houve resistência à maioria das solicitações de mudança de requisitos [ ] 2 – Não houve resistência à metade das solicitações de mudança de requisitos [ ] 1 – Não houve resistência à minoria das solicitações de mudança de requisitos [ ] 0 – Houve resistência a todas às solicitações de mudança de requisitos
3 - Manutenção pela equipe de desenvolvimento de diálogo contínuo e eficiente com o Product Owner para esclarecer dúvidas e obter feedback	Eventual falta de comunicação da equipe de desenvolvimento com o PO ocasionou: [ ] 4 – nenhuma falha ou desvio [ ] 3 – falha ou desvio na minoria das entregas [ ] 2 – falha ou desvio na metade das entregas [ ] 1 – falha ou desvio na maioria das entregas [ ] 0 – falha ou desvio em todas as entregas
Comentários adicionais (optativo)

1.1.27 O valor final da Avaliação do Product Owner (APO) será obtido da seguinteforma: APO = (Valor do Item 1 + Valor do Item 2 + Valor do Item 3) / 12

1.1.28 Descontos a serem aplicados de acordo com o índice de cumprimento dos níveis de serviço‌

1.1.29 O quadro a seguir mostra o desconto a ser aplicado no faturamento da Ordem de Serviço (OS) de acordo com o Índice de Evolução do Sistema (IES):

Índice de Evolução do Sistema (IES)	Desconto sobre o valor de faturamento da OS
Igual ou superior a 80%	0%
Igual ou superior a 70% e inferior a 80%	10%
Igual ou superior a 60% e inferior a 70%	20%
Igual ou superior a 50% e inferior a 60%	30%
Inferior a 50%	40%

1.1.30 O quadro a seguir mostra o desconto a ser aplicado no faturamento da OS de acordo com níveis mínimos de serviço de componentes do IES, sem prejuízo a outros eventuais descontos previstos neste Edital:

Componente do IES	Nível de serviço	Desconto sobre o valor de faturamento da OS
Índice de Qualidade (IQ)	Igual ou superior a 50%	0%
	Igual ou superior a 25% e inferior a 50%	5%
	Inferior a 25%	10%
Avaliação do Product Owner (APO)	Igual ou superior a 50%	0%
	Igual ou superior a 25% e inferior a 50%	5%
	Inferior a 25%	10%

1.1.31 Descontos a serem aplicados na primeira aferição do Índice de Evolução do Sistema (IES)

1.1.32 Excepcionalmente, na primeira aferição do Índice de Evolução do Sistema (IES) da Ordem de Serviço (OS), caso o período considerado não ultrapasse mais que um terço do período total da OS, os descontos a serem aplicados no faturamento da Ordem de Serviço considerarão os do quadro a seguir.

Índice de Evolução do Sistema (IES)	Desconto sobre o valor de faturamento da OS
Igual ou superior a 60%	0%
Igual ou superior a 50% e inferior a 60%	10%
Igual ou superior a 40% e inferior a 50%	20%
Inferior a 40%	30%

Componente do IES	Nível de serviço	Desconto sobre o valor de faturamento da OS
Índice de Qualidade (IQ)	Igual ou superior a 50%	0%
	Igual ou superior a 25% e inferior a 50%	5%
	Inferior a 25%	10%
Avaliação do Product Owner (APO)	Igual ou superior a 50%	0%
	Igual ou superior a 25% e inferior a 50%	5%
	Inferior a 25%	10%

1.1.33 Produtividade-base

1.1.34 Nos quadros a seguir temos a produtividade-base em tamanho funcional e em linhas de código que serão utilizadas na aferição do cumprimento do Índice de Evolução do Sistema (IES):

Produtividade-base em Tamanho Funcional	Produtividade-base em Linhas de Código
0,56 Pontos de Função / DIA-DESENVOLVEDOR	33,33 Linhas de Código / DIA-DESENVOLVEDOR

1.2 Índice de Manutenção de Sistema (IMS)

1.2.1 Os níveis de serviço de OS do tipo MANUTENÇÃO serão representados por indicador de desempenho denominado Índice de Manutenção de Sistema (IMS), que será a média ponderada de 3 componentes:

Componente do IMS	Peso
Índice de Produtividade de Manutenção (IP-M)	0,45
Índice de Qualidade de Manutenção (IQ-M)	0,40
Avaliação do Product Onwer - Manutenção (APO-M)	0,15

1.2.2 O Índice de Manutenção do Sistema - IMS será aferido em períodos de 1 a 2 meses, em momento escolhido pelo TCU, e obrigatoriamente ao término da Ordem de Serviço.

1.2.3 Adicionalmente, há níveis mínimos de serviço exigidos para alguns componentes do IMS isoladamente, conforme item 1.2.25 – “Descontos a serem aplicados de acordo com o índice de cumprimento dos níveis de serviço”.

1.2.4 Índice de Produtividade de Manutenção (IP-M)

1.2.5 O Índice de Produtividade de Manutenção (IP-M) é composto por dois itens: Item de Controle de Produtividade em Tamanho Funcional de Manutenção (ICPTF-M) e Item de Controle de Produtividade em Linhas de Código de Manutenção (ICPLC-M). Estes itens serão aferidos comparando a produtividade no período de aferição com a produtividade- base estabelecida neste Anexo do Edital.

1.2.6 A divisão do peso do IP entre seus dois componentes encontra-se no quadro a seguir:

Componente do IP-M	Peso
Item de Controle de Produtividade em Tamanho Funcional de Manutenção (ICPTF-M)	0,25
Item de Controle de Produtividade em Linhas de Código de Manutenção (ICPLC- M)	0,20
Peso Total do IP-M	0,45

1.2.7 A produtividade será estabelecida em DIA-DESENVOLVEDOR como no caso do Índice de Evolução do Sistema - IES.

1.2.8 Item de Controle de Produtividade em Tamanho Funcional de Manutenção(ICPTF-M)

1.2.9 Para calcular o Item de Controle de Produtividade em Tamanho Funcional de Manutenção (ICPTF-M), deve ser feita, em princípio, a medição detalhada em pontos de função de cada demanda de manutenção atendida e homologada no período, de acordo com o Manual de Medição de Software do TCU (Anexo XI).

1.2.10 Caso o resultado do cálculo do ICPTF-M seja maior que 150%, será adotado 150% para o valor deste Item de Controle. Caso a soma do ICPTF-M com o ICPLC-M seja maior que 100% do IP-M, será considerado 100% do valor do IP-M.

1.2.11 Entretanto, considerando o custo da medição detalhada em pontos de função de grande volume de demandas de manutenção, esta medição somente será realizada em caráter excepcional, a pedido de uma das partes contratuais para defesa de seus interesses.

1.2.11.1.1 Por exemplo, o Tribunal poderá exigir a medição detalhada caso haja indícios de que a produtividade da CONTRATADA esteja abaixo do exigido neste Edital. Por outro lado, a CONTRATADA poderá exigir a medição detalhada caso o TCU reclame do desempenho do serviço prestado no âmbito de uma Ordem de Serviço.

1.2.12 Não sendo solicitada a medição detalhada, adotar-se-á 100% de cumprimento do ICPTF- M.

1.2.13 Item de Controle de Produtividade em Linhas de Código de Manutenção(ICPLC-M)

1.2.14 O cálculo do Item de Controle de Produtividade em Linhas de Código de Manutenção (ICPLC-M) considerará a quantidade de linhas de código alteradas no período de aferição para atendimento das demandas de manutenção.

1.2.15 Este cálculo será feito de modo similar ao do Item de Controle de Produtividade em Linhas de Código (ICPLC).

1.2.16 Caso o resultado do cálculo do ICPLC -M seja maior que 150%, será adotado 150% para o valor deste Item de Controle. Caso a soma do ICPTF-M com o ICPLC-M seja maior que 100% do IP-M, será considerado 100% do valor do IP-M.

1.2.17 Índice de Qualidade de Manutenção (IQ-M)

1.2.18 O Índice de Qualidade de Manutenção (IQ) será obtido a partir do parâmetro

Maintainability Rating da ferramenta SonarQube, versão 5.0 ou superior.

1.2.19 Esse parâmetro reflete o débito técnico do software e seu valor é definido dentro de uma escala de A a E, sendo A a melhor nota e E a pior nota, conforme documentação da ferramenta (xxxxx://xxxx.xxxxxxxxx.xxx/xxxxxxx/XXXXX/XxxxxxxXxxxxxxxxxx#XxxxxxXxxxxxxxxxx- Maintainability).

1.2.20 Em síntese, a meta de qualidade em OS de MANUTENÇÃO é não reduzir a nota do parâmetro Maintainability Rating que o software manutenido possuía no momento da abertura da Ordem de Serviço.

1.2.21 O valor do Índice de Qualidade de Manutenção (IQ-M) será obtido a partir da seguinte fórmula:

IQ-M = 100% - (número de rebaixamentos de nota * 25%)

1.2.22 Por exemplo, se o software possuía inicialmente Maintainability Rating = A e no momento da aferição do IQ-M a nota passou a ser C, ocorreram 2 (dois) rebaixamentos de nota.

1.2.23 Avaliação do Product Owner – Manutenção (APO-M)

1.2.24 Considerando os princípios e valores do desenvolvimento ágil, o Product Owner (PO) do sistema manutenido deverá avaliar os seguintes aspectos da prestação doserviço.

Item	Avaliação
1. Estabilidade das modificações realizadas	Eventual erro no atendimento das demandas ocasionou:
	[ ] 4 – nenhum erro em produção
	[ ] 3 – até 1 falha em produção
	[ ] 2 – até 3 falhas em produção
	[ ] 1 – até 5 falhas em produção
	[ ] 0 – mais que 5 falhas em produção
2 - Manutenção pela equipe de desenvolvimento de diálogo contínuo e eficiente com o Product Owner para esclarecer dúvidas e obter feedback	Eventual falta de comunicação da equipe de desenvolvimento com o PO ocasionou: [ ] 4 – nenhuma falha ou desvio [ ] 3 – falha ou desvio na minoria das entregas [ ] 2 – falha ou desvio na metade das entregas [ ] 1 – falha ou desvio na maioria das entregas [ ] 0 – falha ou desvio em todas as entregas
Comentários adicionais (optativo)

1.2.25 O valor final da Avaliação do Product Owner - Manutenção (APO-M) será obtido da seguinte forma:

APO-M = (Valor do Item 1 + Valor do Item 2) / 8‌

1.2.26 Descontos a serem aplicados de acordo com o índice de cumprimento dos níveis de serviço

1.2.27 O quadro a seguir mostra o desconto a ser aplicado no faturamento da Ordem de Serviço (OS) de acordo com o Índice de Manutenção do Sistema (IMS):

Índice de Manutenção do Sistema (IMS)	Desconto sobre o valor de faturamento da OS
Igual ou superior a 80%	0%
Igual ou superior a 70% e inferior a 80%	10%
Igual ou superior a 60% e inferior a 70%	20%
Igual ou superior a 50% e inferior a 60%	30%
Inferior a 50%	40%

1.2.28 O quadro a seguir mostra o desconto a ser aplicado no faturamento da OS de acordo com níveis mínimos de serviço de componentes do IMS, sem prejuízo a outros eventuais descontos previstos neste Edital:

Componente do IMS	Nível de serviço	Desconto sobre o valor de faturamento da OS
Avaliação do Product Owner - Manutenção (APO-M)	Igual ou superior a 50%	0%
	Igual ou superior a 25% e inferior a 50%	5%
	Inferior a 25%	10%

1.2.29 Descontos a serem aplicados na primeira aferição do Índice de Manutenção do Sistema (IMS)

1.2.30 Excepcionalmente, na primeira aferição do Índice de Manutenção do Sistema (IMS) da Ordem de Serviço (OS), caso o período considerado não ultrapasse mais que um terço do período total da OS, os descontos a serem aplicados no faturamento da Ordem de Serviço considerarão os do quadro a seguir.

Índice de Manutenção do Sistema (IMS)	Desconto sobre o valor de faturamento da OS
Igual ou superior a 60%	0%
Igual ou superior a 50% e inferior a 60%	10%
Igual ou superior a 40% e inferior a 50%	20%
Inferior a 40%	30%

Componente do IMS	Nível de serviço	Desconto sobre o valor de faturamento da OS
Avaliação do Product Owner - Manutenção (APO-M)	Igual ou superior a 50%	0%
	Igual ou superior a 25% e inferior a 50%	5%
	Inferior a 25%	10%

1.2.31 Produtividade-base

1.2.32 Nos quadros a seguir temos a produtividade-base em tamanho funcional e em linhas de código que serão utilizadas na aferição do cumprimento do Índice de Manutenção do Sistema (IMS):

Produtividade-base em Tamanho Funcional (Manutenção)	Produtividade-base em Linhas de Código (Manutenção)
0,42 Pontos de Função / DIA-DESENVOLVEDOR	25 Linhas de Código / DIA-DESENVOLVEDOR

1.3 Taxa Efetiva de Ocupação dos Postos de Trabalho da Ordem de Serviço (TEOPT)

1.3.1 Juntamente com a aferição do Índice de Evolução do Sistema (IES) será verificada a Taxa Efetiva de Ocupação dos Postos de Trabalho - TEOPT (quantidade de membros da equipe técnica da CONTRATADA) previstos na Ordem de Serviço.

1.3.2 A TEOPT será a calculada dividindo a ocupação efetiva dos postos de trabalho (em dias- desenvolvedor) pela ocupação total prevista para este período (também em dias- desenvolvedor).

1.3.3 O quadro a seguir mostra o desconto adicional a ser aplicado no faturamento mensal da Ordem de Serviço de acordo com a TEOPT, sem prejuízo do desconto a ser aplicado por dia de não-ocupação de posto de trabalho, conforme previsto na Cláusula Décima Sexta do Anexo XVI – Minuta do Contrato do Pregão n.º /20 :

Taxa Efetiva de Ocupação dos Postos de Trabalho previstos na OS (TEOPT)	Desconto sobre o valor do faturamento mensal da OS
Igual ou superior a 80%	0%
Igual ou superior a 50% e inferior a 80%	80% - TEOPT
Inferior a 50%	40%

1.3.4 O Tribunal, a seu critério, poderá desconsiderar período de não-ocupação de posto de trabalho para efeito de aferição da Taxa Efetiva de Ocupação dos Postos de Trabalho (TEOPT) caso o profissional que ocupe regularmente o posto se ausente por razão que não enseje desconto salarial de acordo com a legislação trabalhista vigente.

1.3.5 Excepcionalmente, caso os resultados obtidos no período de aferição do Índice de Evolução do Sistema corresponderem a, no mínimo, 80% do IES considerando 100% de TEOPT, serão desconsideradas eventuais não-ocupações de postos de trabalho até o limite de 5% da ocupação total prevista para o período para efeito de desconto por não preenchimento do posto de trabalho (Cláusula Décima Sexta do Anexo XVI – Minuta do Contrato do Pregão n.º /20 ) e para efeito do cálculo do TEOPT.

2 Inexecução parcial do contrato por descumprimento de nível de serviço

2.1 Poderá caracterizar inexecução parcial do contrato:

2.1.1 Descumprimentos de níveis mínimos de serviço no âmbito da mesma Ordem de Serviço que tenham ensejado desconto total igual ou superior a 20% (vinte por cento) do valor de faturamento da OS em dois faturamentos consecutivos ou por três faturamentos em seis faturamentos consecutivos dessa OS.

2.1.2 Não alcance de meta do mesmo indicador de qualidade no âmbito da mesma Ordem de Serviço, em três faturamentos consecutivos ou por quatro faturamentos em seis faturamentos consecutivos dessa OS.

2.1.3 Descumprimentos de níveis mínimos de serviço que tenham ensejado desconto total igual ou superior a 20% (vinte por cento) do valor de faturamento da OS em três faturamentos dessa OS ou de OS distintas no período de 6 (seis) meses no âmbito do contrato.

2.1.4 Tentativa de burla de mecanismos de aferição dos níveis de serviço previstos neste Edital.

ANEXO VII – MODELOS DE ORDEM DE SERVIÇO E DE ADITIVO

	TRIBUNAL DE CONTAS DA UNIÃO	Nº da OS
	Ordem de Serviço – Contrato nº /     Objeto: Serviços de projeto e de manutenção de software com práticas ágeis
Tipo de OS		( ) Projeto ( )Manutenção
Nome do Projeto/Sistema(s)
Data de Abertura
Data Prevista de Término
Quantitativo de Postos de Trabalho:		( ) Analista Programador Java nível Sênior ( ) Analista Programador Java nível Pleno
Representantes do TCU:		Nome - Matrícula (Representante da área de negócio - demandante) Nome - Matrícula (Gestor ou Fiscal do Contrato)
Ciência do representante da empresa:		Nome – Cargo na empresa

	TRIBUNAL DE CONTAS DA UNIÃO	Nº da OS
	Aditivo nº    à Ordem de Serviço – Contrato nº /     Objeto: Serviços de projeto e de manutenção de software com práticas ágeis
Tipo de OS:		( ) Projeto ( )Manutenção
Data do Aditivo:
Tipo:		( ) Aumento de posto(s) de trabalho de Analista Programador Java nível Sênior ( ) Aumento de posto(s) de trabalho de Analista Programador Java nível Pleno ( ) Redução de posto(s) de trabalho de Analista Programador Java nível Sênior ( ) Redução de posto(s) de trabalho de Analista Programador Java nível Pleno ( ) Prorrogação do Término da OS para   / / _   ( ) Antecipação do Término da OS para / /
Representantes do TCU		Nome - Matrícula (Representante da área de negócio - demandante) Nome - Matrícula (Gestor ou Fiscal do Contrato)
Ciência do representante da empresa:		Nome – Cargo na empresa

Obs: Estes modelos poderão ser alterados ou eventualmente substituídos por sistema informatizado visando melhor adequação à execução contratual.

ANEXO VIII - TERMO DE COMPROMISSO DE MANUTENÇÃO DE SIGILO E RESPEITO ÀS NORMAS DE SEGURANÇA VIGENTES NO TCU E DECLARAÇÃO DE CIÊNCIA DO TERMO DE MANUTENÇÃO DE SIGILO E DAS NORMAS DE SEGURANÇA VIGENTES

TERMO DE COMPROMISSO DE MANUTENÇÃO DE SIGILO E RESPEITO ÀS NORMAS DE SEGURANÇA VIGENTES NO TCU

A empresa [nome da empresa], pessoa jurídica com sede em [endereço], inscrita no CNPJ/MF com o n.º [CNPJ], neste ato representada na forma de seus atos constitutivos, doravante denominada simplesmente CONTRATADA, por tomar conhecimento de informações sobre o ambiente computacional do Tribunal de Contas da União – TCU, aceita as regras, condições e obrigações constantes do presente Termo.

1. O objetivo deste Termo de Confidencialidade e Sigilo é prover a necessária e adequada proteção às informações restritas de propriedade exclusiva do TCU reveladas à CONTRATADA em razão da execução dos serviços objeto do contrato N.º [xx/aaaa], doravante denominado simplesmente CONTRATO, bem como assegurar o respeito às normas de segurança vigentes naquele órgão durante a realização dos serviços.

2. A expressão “informação restrita” abrangerá toda informação escrita, oral ou de qualquer outro modo apresentada, tangível ou intangível, podendo incluir, mas não se limitando a: técnicas, projetos, especificações, desenhos, cópias, diagramas, fórmulas, modelos, amostras, fluxogramas, croquis, fotografias, plantas, programas de computador, discos, disquetes, fitas, contratos, planos de negócios, processos, projetos, conceitos de produto, especificações, amostras de ideia, clientes, nomes de revendedores e/ou distribuidores, preços e custos, definições e informações mercadológicas, invenções e ideias, outras informações técnicas, financeiras ou comerciais, dentre outros.

3. A CONTRATADA compromete-se a não reproduzir e/ou dar conhecimento a terceiros, sem a anuência formal e expressa do TCU, das informações restritas reveladas.

4. A CONTRATADA compromete-se a não utilizar, bem como a não permitir que seus diretores, consultores, prestadores de serviços, empregados e/ou prepostos utilizem, de forma diversa da prevista no CONTRATO, as informações restritas reveladas.

5. A CONTRATADA deverá cuidar para que as informações reveladas fiquem limitadas ao conhecimento dos diretores, consultores, prestadores de serviços, empregados e/ou prepostos que estejam diretamente envolvidos nas discussões, análises, reuniões e demais atividades relativas à prestação de serviços ao TCU, devendo cientificá-los da existência deste Termo e da natureza confidencial das informações restritas reveladas.

6. A CONTRATADA declara conhecer e se compromete a seguir e divulgar entre seus colaboradores envolvidos na execução do CONTRATO a Política Corporativa de Segurança da Informação do TCU (PCSI/TCU) e normativos correlatos.

7. A CONTRATADA possuirá ou firmará acordos por escrito com seus diretores, consultores, prestadores de serviços, empregados e/ou prepostos cujos termos sejam suficientes a garantir o cumprimento de todas as disposições do presente Termo, conforme especificado no instrumento convocatório do processo licitatório que deu origem ao CONTRATO.

8. A CONTRATADA obriga-se a informar imediatamente ao TCU qualquer violação das regras de sigilo estabelecidas neste Termo que tenha ocorrido por sua ação ou omissão, independentemente da existência de dolo.

9. A quebra do sigilo das informações restritas reveladas, devidamente comprovada, sem autorização expressa do TCU, possibilitará a imediata rescisão de qualquer contrato firmado entre o TCU e a CONTRATADA sem qualquer ônus para o TCU. Nesse caso, a CONTRATADA, estará sujeita, por ação ou omissão, ao pagamento ou recomposição de todos os danos e perdas sofridos pelo TCU, inclusive os de ordem moral, bem como as de responsabilidades civil e criminal respectivas, as quais serão apuradas em regular processo judicial ouadministrativo.

10. O presente Termo tem natureza irrevogável e irretratável, permanecendo em vigor desde a data de acesso às informações restritas do TCU.

E, por aceitar todas as condições e as obrigações constantes do presente Termo, a CONTRATADA assina o presente termo através de seus representantes legais.

Brasília/DF,     de         de 20    .

[nome da empresa]

Nome/Cargo

DECLARAÇÃO DE CIÊNCIA DO TERMO DE MANUTENÇÃO DE SIGILO E DAS NORMAS DE SEGURANÇA VIGENTES

Por meio desta, o(a) Sr(a) [nome do(a) diretor, consultor, prestador de serviço, empregado ou preposto], CPF            , ocupante do cargo [cargo que ocupa] na empresa [Nome (Razão Social) da empresa], CNPJ [número do CNPJ da empresa], declara sob as penas da Lei, ter tomado conhecimento do TERMO DE COMPROMISSO DE MANUTENÇÃO DE SIGILO E RESPEITO

ÀS NORMAS DE SEGURANÇA VIGENTES NO TCU, emitido por aquela empresa por ocasião da assinatura do contrato N.ºo /20 , e se compromete a seguir, naquilo que lhe couber, todas as disposições do referido Termo.

Local e data

Assinatura

XXXXX XX – MODELO DE DECLARAÇÃO DE CONTRATOS FIRMADOS COM A INICIATIVA PRIVADA E COM A ADMINISTRAÇÃO PÚBLICA

Declaramos que a empresa                             , inscrita

no CNPJ (MF) nº               , possui os seguintes contratos firmados com a iniciativa privada e administração pública:

Órgão/Empresa	Nº Contrato/ Aditivo	Vigência		Valor Total Atual do Contrato
		Início	Término
Valor Total dos Contratos (Atualizados)

Local e data

Assinatura e carimbo do emissor

COMPROVAÇÃO DA SUBCONDIÇÃO 36.4.

Cálculo demonstrativo visando comprovar que o patrimônio líquido é igual ou superior a 1/12 (um doze avos) do valor dos contratos firmados com a administração pública e com a iniciativa privada.

Valor do Patrimônio Líquido x 12 > 1 Valor total dos contratos

Obs.: Esse resultado deverá ser superior a 1.

COMPROVAÇÃO DA CONDIÇÃO 37.

Cálculo demonstrativo da variação percentual do valor total constante na declaração de contratos firmados com a iniciativa privada e com a Administração Pública em relação à receita bruta informada na DRE.

(Valor da receita bruta – Valor total dos contratos) x 100 = X% Valor da receita bruta

Obs.: Caso o percentual encontrado seja maior que 10% (positivo ou negativo), a licitante deverá apresentar as devidas justificativas.

ANEXO X – MODELO DE TERMO DE RECEBIMENTO DEFINITIVO

	TRIBUNAL DE CONTAS DA UNIÃO	Contrato: /    Nº da OS:      Nº de Receb. na OS:
	Termo de Recebimento Definitivo OS de PROJETO
1 - Dados básicos
1.1 Período considerado:   /   /    a   /   /     1.2 Período considerado em meses:    1.3 Quantidade de dias úteis no período:    1.4 Quantidade de DIAS-DESENVOLVEDOR realizados no período:    1.5 Quantidade de DIAS-DESENVOLVEDOR esperados no período a:    1.6 Quantidade de DIAS-DESENVOLVEDOR – perfil sênior - realizados no período:    1.7 Quantidade de DIAS-DESENVOLVEDOR – perfil sênior - esperados no período b:    1.8 Quantidade de DIAS-DESENVOLVEDOR – perfil pleno - realizados noperíodo:    1.9 Quantidade de DIAS-DESENVOLVEDOR – perfil pleno - esperados no período c:    a Quantidade total de membros definido na OS x quantidade de dias úteis no período (item 1.3) b Quantidade de postos de nível sênior definido na OS x quantidade de dias úteis no período (item 1.3) c Quantidade de postos de nível pleno definido na OS x quantidade de dias úteis no período (item 1.3)
2 – Taxa Efetiva de Ocupação dos Postos de Trabalho previstos na OS (TEOPT)
2.1 TEOPT (item 1.4 / 1.5) =    /    =     % 2.2 TEOPT sênior (item 1.6 / 1.7) =    /     =     % 2.3 TEOPT pleno (item 1.8 / 1.9) =    /     =     %

3 - Itens homologados pelo Product Owner (PO) no período
	3.1 Descrição	3.2 Quantidade de Pontos de Função
	3.3 Tamanho da Evolução Funcional (TEF)
	4 – Índice de Produtividade (IP)
	4.1 Produtividade no período em tamanho funcional =    /     =     a 4.2 Item de Controle de Produtividade em Tamanho Funcional (ICPTF) =    /    =    b 4.3 Total de Linhas de Código Alteradas no período =      4.4 Produtividade no período em linhas de código =    /    = c 4.5 Item de Controle de Produtividade em Linhas de Código (ICPLC) =    /    = d a (Item 3.3) / (Item 1.4) b (Item 4.1) / Produtividade-base em Tamanho Funcional c (Item 4.3) / (Item 1.4) d (Item 4.1) / Produtividade-base em Linhas de Código e (Item 4.2) * 0,25 + (Item 4.5) * 0,20

5 – Índice de Qualidade (IQ)

Grupo	Indicador	Unidade	Meta	Valor Obtido	Alcançou a meta? (S / N)
Projeto	Complexity / file	média total	<= 10
	Complexity / class	média total	<= 10
	Complexity / function	média total	<= 3
	Duplications	%	<= 4%
	Security Issue Tags	unidades	=0
	Technical Debt ratio	%	<= 2,5%
	SQALE RATING	Nota	=A
Violações de código (possíveis bugs, estilo de codificação, más práticas de codificação):	Critical Issues	unidades	=0
	Blocker Issues	unidades	=0
Indicadores relacionados a testes	Unit Tests Coverage - camada negócio / Impl	%	>=70%
	Unit Test Success	%	>=100%
	Skipped Tests	unidades	=0

5.1 Total de Indicadores que alcançaram a meta =   

5.2 Total de Indicadores = 12

5.3 Índice de Qualidade (IQ) =    / 12 =    % a

a (Item 5.1) / 12

6 Avaliação do Product Owner (APO)
	Item	Avaliação
	1 - Periodicidade de entrega de software para homologação (preferência por períodos entre 1 a 4 semanas)	Entregas realizadas em período igual ou menor a 4 semanas: [ ] 4 – Todas [ ] 3 – Maioria [ ] 2 – Metade [ ] 1 – Minoria [ ] 0 – Nenhuma
	2 - Receptividade da equipe de desenvolvimento a mudança de requisitos, mesmo em estágio avançado de desenvolvimento	[ ] 4 – Não houve resistência à nenhuma solicitação de mudança de requisitos [ ] 3 – Não houve resistência à maioria das solicitações de mudança de requisitos [ ] 2 – Não houve resistência à metade das solicitações de mudança de requisitos [ ] 1 – Não houve resistência à minoria das solicitações de mudança de requisitos [ ] 0 – Houve resistência a todas às solicitações de mudança de requisitos
	3 - Manutenção pela equipe de desenvolvimento de diálogo contínuo e eficiente com o Product Owner para esclarecer dúvidas e obter feedback	Eventual falta de comunicação da equipe de desenvolvimento com o PO ocasionou: [ ] 4 – nenhuma falha ou desvio [ ] 3 – falha ou desvio na minoria das entregas [ ] 2 – falha ou desvio na metade das entregas [ ] 1 – falha ou desvio na maioria das entregas [ ] 0 – falha ou desvio em todas as entregas
	Comentários adicionais (optativo)
	6.1 APO = (Valor do Item 1 + Valor do Item 2 + Valor do Item 3) / 12 =    %
7 Índice de Evolução do Sistema (IES)
7.1 IES = (0,25 x ICPTF) + (0,20 x ICPLC) + (0,40 x IQ) + (0,15 x APO) IES = (0,25 x     ) + (0,20 x     ) + (0,40 x     ) + (0,15 x    ) =

8 – Valor a pagar

8.1 Valor mensal previsto para a OS: R$       

8.2 Valor mensal correspondente aos postos de nível sênior a: R$      

8.3 Valor mensal correspondente aos postos de nível pleno b: R$      

8.4 Desconto por não-ocupação de posto de trabalho - sênior: c

8.5 Desconto por não-ocupação de posto de trabalho - pleno: d

8.6 Desconto adicional por infração ao nível mínimo de serviço exigido para TEOPT =   % e

( ) Foi aplicada exceção prevista no Anexo VI ao calcular os itens 8.4, 8.5 e 8.6

8.7 Desconto a ser aplicado em função do ICPTF =   % f

8.8 Desconto a ser aplicado em função do IQ =   % g

8.9 Desconto a ser aplicado em função do APO = _ % h

8.10 Desconto a ser aplicado em função do IES = _   % i

8.11 Subtotal de descontos a serem aplicados por não alcance de NMS =    % j

8.12 Valor a pagar = [ (Item 8.1 Valor mensal previsto para a OS) x

(1.2 Período considerado em meses) -

(Desconto por não-ocupação de posto de trabalho - sênior) – (Desconto por não-ocupação de posto de trabalho - pleno) ] x

(100% - Item 6.11).

Valor a pagar = R$         

a Ver Cláusula 15ª do Anexo XVI – Minuta do Contrato do Pregão n.º   /20 . b Ver Cláusula 15ª do Anexo XVI – Minuta do Contrato do Pregão n.º   /20 .

c Item 8.2 x (100% - (item 2.2)), observando exceções previstas no Anexo VI – Níveis mínimos de serviço e cálculo de pagamento.

d Item 8.3 x (100% - (item 2.3)), observando exceções previstas no Anexo VI – Níveis mínimos de serviço e cálculo de pagamento.

e Ver Anexo VI – Níveis Mínimos de Serviço e Cálculo de Pagamento.

f, g, h, i Ver regra para primeira aferição no âmbito da OS e para segunda aferição em seguida do Anexo VI – Níveis Mínimos de Serviço e Cálculo de Pagamento.

j Item 8.6 + item 8.7 + item 8.8 + item 8.9 + item 8.10.

9 Fiscalização Administrativa
9.1 ( ) Regularidade Fiscal, Trabalhista e Previdenciária – 1ª parte a 9.2 ( ) Comprovação de pagamento de salários (respeitando o limite salarial mínimo estabelecido no Projeto Básico), inclusive férias e 00x xxxxxxx, xxxxxx xxxxxxx, xx xxxx- transporte e de vale-alimentação b 9.3 ( ) Extratos comprobatórios do recolhimento do FGTS e da contribuição social previdenciária (INSS) c 9.4 ( ) Guias da Previdência Social e Guias de Recolhimento do Fundo de Garantia do Tempo de Serviço e Informações à Previdência social com comprovante de entrega d Os documentos referentes aos itens         encontram-se juntados a este processo. a Portaria-TCU nº 297/2012, art. 7º, incisos I a V, observado o § 2º. b Portaria-TCU nº 297/2012, art. 7º, inc. VI e art. 13. c Portaria-TCU nº 297/2012, art. 7º, inc. VII e artigos 10 e 11. d Portaria-TCU nº 297/2012, art. 7º, inc. VIII
Representantes do TCU:	Nome - Matrícula (Representante da área de negócio - demandante) Nome - Matrícula (Gestor ou Fiscal do Contrato)
Ciência do representante da empresa:	Nome – Cargo na empresa

	TRIBUNAL DE CONTAS DA UNIÃO	Contrato: /    Nº da OS:      Nº de Receb. na OS:
	Termo de Recebimento Definitivo OS de MANUTENÇÃO
1 - Dados básicos
1.1 Período considerado:   /   /    a   /   /     1.2 Período considerado em meses:    1.3 Quantidade de dias úteis no período:    1.4 Quantidade de DIAS-DESENVOLVEDOR realizados no período:    1.5 Quantidade de DIAS-DESENVOLVEDOR esperados no período a:    1.6 Quantidade de DIAS-DESENVOLVEDOR – perfil sênior - realizados no período:    1.7 Quantidade de DIAS-DESENVOLVEDOR – perfil sênior - esperados no período b:    1.8 Quantidade de DIAS-DESENVOLVEDOR – perfil pleno - realizados noperíodo:    1.9 Quantidade de DIAS-DESENVOLVEDOR – perfil pleno - esperados no período c:    a Quantidade total de membros definido na OS x quantidade de dias úteis no período (item 1.3) b Quantidade de postos de nível sênior definido na OS x quantidade de dias úteis no período (item 1.3) c Quantidade de postos de nível pleno definido na OS x quantidade de dias úteis no período (item 1.3)
2 – Taxa Efetiva de Ocupação dos Postos de Trabalho previstos na OS (TEOPT)
2.1 TEOPT (item 1.4 / 1.5) =    /    =     % 7.1 TEOPT sênior (item 1.6 / 1.7) =    /   =    % 2.3 TEOPT pleno (item 1.8 / 1.9) =    /   =    %
3 – Demandas atendidas e homologados pelo Product Owner (PO) no período
3.1 Descrição 3.2 Quantidade de Pontos de Função (se foi solicitada a medição detalhada)

4 – Índice de Produtividade de Manutenção (IP-M)

4.1 Produtividade no período em tamanho funcional =    /     =     a

4.2 Item de Controle de Produtividade em Tamanho Funcional de Manutenção (ICPTF-M) =

   /   = b

4.3 Total de Linhas de Código Alteradas no período =     

4.4 Produtividade no período em linhas de código =    /     = c

4.5 Item de Controle de Produtividade em Linhas de Código de Manutenção (ICPLC-M) =

   /   = d

a (Item 3.3) / (Item 1.4)

b (Item 4.1) / Produtividade-base em Tamanho Funcional – Manutenção ou 100% caso não tenha sido solicitada a medição detalhada

c (Item 4.3) / (Item 1.4)

d (Item 4.1) / Produtividade-base em Linhas de Código – Manutenção e (Item 4.2) * 0,25 + (Item 4.5) * 0,20

5 – Índice de Qualidade de Manutenção (IQ-M)

Maintainability Rating na Maintainability Número de abertura da OS Rating atual rebaixamentos de

nota

3.3 Total de Pontos de Função (TPF)

5.1 Índice de Qualidade de Manutenção (IQ-M) = 100% - (número de rebaixamentos de nota * 25%) =   %
6 Avaliação do Product Owner (APO)
	Item	Avaliação
	1. Estabilidade das modificações realizadas	Eventual erro no desenvolvimento das demandas ocasionou: [ ] 4 – nenhum erro em produção [ ] 3 – até 1 falha em produção [ ] 2 – até 3 falhas em produção [ ] 1 – até 5 falhas em produção [ ] 0 – mais que 5 falhas em produção
	2 - Manutenção pela equipe de desenvolvimento de diálogo contínuo e eficiente com o Product Owner para esclarecer dúvidas e obter feedback	Eventual falta de comunicação da equipe de desenvolvimento com o PO ocasionou: [ ] 4 – nenhuma falha ou desvio [ ] 3 – falha ou desvio na minoria das entregas [ ] 2 – falha ou desvio na metade das entregas [ ] 1 – falha ou desvio na maioria das entregas [ ] 0 – falha ou desvio em todas as entregas
	Comentários adicionais (optativo)
	6.1 APO = (Valor do Item 1 + Valor do Item 2) / 8 =   %
7 Índice de Manutenção do Sistema (IMS)
7.1 IES = (0,25 x ICPTF-M) + (0,20 x ICPLC-M) + (0,40 x IQ-M) + (0,15 x APO-M) IES = (0,25 x     ) + (0,20 x     ) + (0,40 x     ) + (0,15 x    ) =

8 – Valor a pagar

8.1 Valor mensal previsto para a OS: R$       

8.2 Valor mensal correspondente aos postos de nível sênior a: R$      

8.3 Valor mensal correspondente aos postos de nível pleno b: R$      

8.4 Desconto por não-ocupação de posto de trabalho - sênior: c

8.5 Desconto por não-ocupação de posto de trabalho - pleno: d

8.6 Desconto adicional por infração ao nível mínimo de serviço exigido para TEOPT =   % e

( ) Foi aplicada exceção prevista no Anexo VI ao calcular os itens 8.4, 8.5 e 8.6

8.7 Desconto a ser aplicado em função do ICPTF =   % f

8.8 Desconto a ser aplicado em função do IQ =   % g

8.9 Desconto a ser aplicado em função do APO = _ % h

8.10 Desconto a ser aplicado em função do IES = _   % i

8.11 Subtotal de descontos a serem aplicados por não alcance de NMS =    % j

8.12 Valor a pagar = [ (Item 8.1 Valor mensal previsto para a OS) x

(1.2 Período considerado em meses) -

(Desconto por não-ocupação de posto de trabalho - sênior) – (Desconto por não-ocupação de posto de trabalho - pleno) ] x

(100% - Item 8.11).

.

Valor a pagar = R$         

a Ver Cláusula 15ª do Anexo XVI – Minuta do Contrato do Pregão n.º   /20 . b Ver Cláusula 15ª do Anexo XVI – Minuta do Contrato do Pregão n.º   /20 .

c Item 8.2 x (100% - (item 2.2)), observando exceções previstas no Anexo VI – Níveis mínimos de serviço e cálculo de pagamento.

d Item 8.3 x (100% - (item 2.3)), observando exceções previstas no Anexo VI – Níveis mínimos de serviço e cálculo de pagamento.

e Ver Anexo VI – Níveis Mínimos de Serviço e Cálculo de Pagamento.

f, g, h, i Ver regra para primeira aferição no âmbito da OS e para segunda aferição em seguida do Anexo VI – Níveis Mínimos de Serviço e Cálculo de Pagamento.

j Item 8.6 + item 8.7 + item 8.8 + item 8.9 + item 8.10.

9 Fiscalização Administrativa
9.1 ( ) Regularidade Fiscal, Trabalhista e Previdenciária – 1ª parte a 9.2 ( ) Comprovação de pagamento de salários (respeitando o limite salarial mínimo estabelecido no Projeto Básico), inclusive férias e 00x xxxxxxx, xxxxxx xxxxxxx, xx xxxx- transporte e de vale-alimentação b 9.3 ( ) Extratos comprobatórios do recolhimento do FGTS e da contribuição social previdenciária (INSS) c 9.4 ( ) Guias da Previdência Social e Guias de Recolhimento do Fundo de Garantia do Tempo de Serviço e Informações à Previdência social com comprovante de entrega d Os documentos referentes aos itens         encontram-se juntados a este processo. a Portaria-TCU nº 297/2012, art. 7º, incisos I a V, observado o § 2º. b Portaria-TCU nº 297/2012, art. 7º, inc. VI e art. 13. c Portaria-TCU nº 297/2012, art. 7º, inc. VII e artigos 10 e 11. d Portaria-TCU nº 297/2012, art. 7º, inc. VIII.
Representantes do TCU:	Nome - Matrícula (Representante da área de negócio - demandante) Nome - Matrícula (Gestor ou Fiscal do Contrato)
Ciência do representante da empresa:	Nome – Cargo na empresa

Obs: Estes modelos poderão ser alterados ou eventualmente substituídos por sistema informatizado visando melhor adequação à execução contratual.

ANEXO XI - MANUAL DE MEDIÇÃO FUNCIONAL DE SOFTWARE

1. Introdução

Este manual visa definir as regras de contagem funcional a serem utilizadas pela Secretaria de Soluções de TI – STI/TCU durante o processo de desenvolvimento e manutenção de software tanto em projetos internos quanto externos o Tribunal.

A definição e o estabelecimento de métricas são fundamentais para o dimensionamento de um projeto e para o acompanhamento de seu desenvolvimento. A partir das informações obtidas com o uso de métricas, pode-se avaliar a qualidade do processo de desenvolvimento e verificar o resultado da utilização de uma técnica ou ferramenta. Por essa razão, os sistemas de verificação de qualidade, como a norma ISO 9000:2000 e o CMMI, normalmente exigem a definição de métricas.

A medição funcional é um termo geral para métodos de dimensionamento de software baseados nas funções requeridas pelos usuários.

A norma ISO/IEC 14143 foi desenvolvida para garantir que todos os métodos de medição de tamanho funcional sejam baseados em conceitos similares e se comportem de maneira similar.

O presente manual se baseia na métrica Pontos de Função definida pelo IFPUG no Manual de Práticas de Contagem (CPM) versão 4.3.1 (IFPUG, 2010), e na métrica EFPA definida pela Nesma no documento Function Point Analysis for Software Enhancement versão 1.0. Logo, conceitos e detalhes das métricas devem ser buscados nos documentos citados, desde que não conflitantes com os explicitados neste manual.

Traz também a possibilidade de dimensionamento de software pela métrica Elementos Funcionais (EF) proposta por XXXXXX e HERNANDES (2013) e suas submétricas Elementos Funcionais de Transação (EFt) e Elementos Funcionais de Dados (EFd), que se baseiam na métrica Pontos de Função, mas sem algumas de suas deficiências.

Complementa este manual o guia “Melhores Práticas de Medição Funcional” do TCU. É comum o surgimento de dúvidas e divergências em contagens funcionais, tendo em vista ser a visão do usuário, alvo da medição, subjetiva. Nesses casos, as interpretações validadas e

acordadas são registradas no guia, que será constituído ao longo do tempo. Esse guia tem como objetivo preservar as decisões para referência futura, eliminando o retrabalho e divergências.

Para efeito deste manual, os termos “projeto de melhoria” e “projeto de desenvolvimento” do método FSM do IFPUG equivalem aos termos “caso de melhoria” e “caso de desenvolvimento” respectivamente. Preferiu-se usar essa terminologia para não haver confusão com o conceito de projeto já empregado na metodologia de desenvolvimento do TCU.

O presente manual trata inicialmente do processo de contagem. Em seguida apresenta algumas considerações sobre a utilização da métrica no processo de terceirização. Por fim, apresenta um glossário com algumas definições de conceitos usados no corpo deste manual.

2. Processo De Medição De Software

2.1. Determinação Do Tipo De Medição

2.1.1. Quanto ao alvo da medição

Consiste na qualificação do alvo da medição. Podemos medir as funcionalidades envolvidas em casos de desenvolvimento ou de manutenção e também as funcionalidades presentes em uma aplicação. Detalhamos nesta seção os tipos de medição quanto ao alvo.

2.1.1.1. Caso de desenvolvimento

Situação de criação de demanda do usuário relativa a uma nova aplicação. O tamanho funcional de um caso de desenvolvimento mede a funcionalidade fornecida aos usuários finais do software quando da sua primeira instalação. Isso significa que essa medição também abrange as eventuais funções de conversão de dados necessárias à implantação da aplicação.

Os componentes para o cálculo do tamanho funcional de um caso de desenvolvimento são:

• Funcionalidades da aplicação requisitadas pelo usuário para o caso (FInc) – funções utilizadas após a instalação do software para satisfazer as necessidades correntes do negócio do usuário;

• Funcionalidades de conversão requisitada pelo usuário para o caso (FConv) – funções disponíveis no momento da instalação da aplicação para converter dados ou fornecer outros requisitos de conversão especificados pelo usuário, como relatórios de verificação de conversão e rotinas de migração. Após a instalação, essas funções não serão mais usadas.

A fórmula de cálculo do tamanho funcional do caso de desenvolvimento (FDes) é a seguinte:

FDes = FInc + FConv

2.1.1.2. Caso de melhoria ou redesenvolvimento

Trata-se da situação em que uma aplicação já foi desenvolvida, mas o usuário solicita algum tipo de manutenção adaptativa, evolutiva ou mesmo corretiva ou trata-se da situação em que o usuário solicita o redesenvolvimento total ou parcial de uma aplicação existente. O tamanho funcional de um caso de melhoria ou redesenvolvimento mede as funções adicionadas, modificadas ou excluídas da aplicação pelo caso e também as eventuais funções de conversão de dados. Também podem ser incluídas no escopo de um caso de melhoria ou redesenvolvimento funcionalidades que serão alvo somente de teste, tendo em vista possuírem alto acoplamento com as funcionalidades integrantes da melhoria ou redesenvolvimento.

2.1.1.3. Aplicação

Situação em que se deseja dimensionar o tamanho funcional disponibilizado para o usuário em uma determinada aplicação ou de parte da mesma.

2.1.2. Quanto ao método de medição

2.1.2.1. Medição indicativa

Este método é utilizado antes da iniciação de um projeto de desenvolvimento de software. Na contagem indicativa, em conformidade com o trabalho Early Function Point Counting, publicado pela Nesma, admite-se que já foram identificadas as funções de dados do projeto: AIEs e ALIs. O método atribui então 35 FP para cada ALI e 15 FP para cada AIE identificado, sendo esses números obtidos conforme o detalhamento a seguir.

O método considera como premissa a complexidade média para todos os tipos de função da APF. E ainda, cada ALI representa 10 FP e tem associadas 3 entradas externas para inclusão, alteração e exclusão dos dados do arquivo (12 FP), 2 consultas externas (8 FP) e 1 saída externa, correspondente a relatório com totalizações (5 FP), perfazendo o total de 35 FP. Além disso, cada AIE (7 FP) tem associadas 2 consultas externas, correspondentes a uma consulta detalhada e uma lista dos dados da tabela (8 FP), alcançando os 15 FP utilizados pelo método.

Para uma contagem indicativa em elementos funcionais, deve-se considerar 25 EF para cada ALI e 12 EF para cada AIE.

2.1.2.2. Medição estimativa

O objetivo específico dessa contagem, baseada no método da Nesma, é determinar o tamanho funcional do software de modo a sustentar ações gerenciais para planejamento do projeto, a partir de um segundo detalhamento do escopo do software a ser desenvolvido, o que permite resultado mais próximo da realidade.

Em uma fase geralmente posterior do ciclo de desenvolvimento, quando já são conhecidas, em linhas gerais, todas as funcionalidades do sistema, deverá ser utilizado o método de contagem estimativa, publicado pela Nesma, que preconiza a identificação de todos os tipos de função da APF, considerando baixa a complexidade para as funções de dados ALI e AIE, e média para as funções transacionais EE, SE e CE.

Para uma contagem estimativa em elementos funcionais, deve-se considerar o tamanho equivalente a 75% do tamanho em pontos de função assumindo complexidade baixa para as funções de dados ALI e AIE, e média para as funções transacionais EE, SE e CE. Ou seja, uma medição estimativa em elementos funcionais equivale a 75% de uma medição estimativa em pontos de função.

2.1.2.3. Contagem detalhada

A contagem detalhada se dá através da identificação, classificação e mensuração das funcionalidades no escopo da medição.

Para que uma funcionalidade seja considerada na contagem, ela deve estar formalmente registrada em artefatos indicados na metodologia de desenvolvimento do TCU como requisito da aplicação alvo da medição.

2.2. Identificação Do Escopo Da Medição E Da Fronteira Da Aplicação

2.2.1. Escopo da medição

O escopo define o conjunto de funções que serão alvo da medição e pode abranger uma ou mais aplicações.

2.2.2. Fronteira da aplicação

Na área de tecnologia da informação, o termo “aplicação” é usado, de modo geral, como sinônimo de programa executável pelo usuário. São exemplos: Word, Excel, Calculadora, Faturamento, Vendas, etc. O termo “aplicação” é ainda usado como sinônimo para módulo, componente, subsistema, sistema, sistema aplicativo ou sistema de informação. Os desenvolvedores costumam segmentar um conjunto de funções relacionadas em visões tecnológicas. São exemplos: plataforma física (computador de grande porte ou microcomputador) e arquitetura de projeto (web, cliente-servidor, etc.).

Mas isso não é uma aplicação. Uma aplicação tem que ser definida segundo a visão do usuário, de acordo com os requisitos de negócio. Não são consideradas questões técnicas voltadas à implementação física. Segundo o CPM, uma aplicação é um conjunto coeso de dados e procedimentos automatizados que suportam um objetivo de negócio, podendo consistir de um ou mais componentes, módulos ou subsistemas.

A correta identificação de uma aplicação (delimitada por sua fronteira) é fundamental para o emprego consistente da métrica, evitando-se contagens superdimensionadas ou subdimensionadas. A fronteira da aplicação pode ser entendida como a interface conceitual que delimita o software que será medido e seus usuários. O posicionamento incorreto da fronteira pode alterar a perspectiva da medição de uma visão lógica (visão funcional) para uma visão física. As principais consequências disso são a contagem duplicada de transações e arquivos de dados, a contagem incorreta de funções de transferência de dados e dificuldade na contagem de arquivos. Uma fronteira de aplicação não pode ser subdivida por contextos gerenciais de desenvolvimento, por exemplo, interno e externo ao órgão.

A fronteira é determinada com base na visão do usuário. O foco está no que o usuário pode entender e descrever. A fronteira entre aplicações relacionadas está baseada nas áreas funcionais separadas como pode ser visto pelo usuário, não em considerações técnicas. Observe dados de medição correlatos, tais como esforço, custo e defeitos. As fronteiras consideradas para medições funcionais e para os outros dados de medição tendem a ser as mesmas.

As aplicações são distribuídas em áreas de negócio do usuário, e pode existir uma ou mais aplicações em cada área de negócio. Compete à Secretaria que desenvolve sistemas no TCU definir e atualizar a lista de aplicações. Segue lista não exaustiva de aplicações existentes no TCU:

Gestão de Aquisição, Guarda e Controle de Bens de Consumo e Patrimoniais (Adm - área administrativa); Gestão de Atos de Concessão (CE - área de controle externo); Gestão de Contratos (Adm); Gestão de Apreciações (CE); Gestão de Fiscalizações (CE); Gestão de Fundos de Participação Constitucionais (CE); Gestão de Jurisprudência (CE); Gestão de Pessoas (área de infraestrutura - infra); Gestão de Processos e Documentos (CE), Gestão de Recursos Humanos (Adm); Gestão de Saúde Médica (Adm); Gestão de Tomadas de Contas Especiais (CE); Gestão do Portal (Infra).

2.3. Identificação Das Funções de Dados

As funções de dado representam as funcionalidades fornecidas ao usuário a fim de atender às suas necessidades de persistência de dados internos e externos à aplicação. São classificadas em arquivo lógico interno (ALI) e arquivo de interface externa (AIE).

O termo arquivo não significa um arquivo do sistema operacional, mas sim um grupo de dados logicamente relacionados, reconhecido pelo usuário. Um arquivo para a medição funcional pode estar mapeado em um ou mais arquivos físicos ou em tabelas do banco de dados e recebe a denominação de arquivo lógico.

Em casos de desenvolvimento, os ALIs e os AIEs só podem ser contados uma única vez para a fronteira da aplicação.

Em casos de melhoria, serão contados sempre que forem objetos de manutenção no escopo da medição.

A identificação dos arquivos lógicos deve seguir os seguintes passos:

• Identificação dos arquivos lógicos.

• Classificação de cada arquivo lógico como ALI ou AIE.

2.3.1. Identificação dos arquivos lógicos

Os requisitos de armazenamento, funcionais e não funcionais, de uma aplicação são classificados em dados de negócio, dados de referência e dados de código, conforme definição do CPM.

Devem ser descartados os dados de código, também chamados metadados, que são uma implementação de requisitos técnicos e não devem influenciar o tamanho funcional da aplicação.

Contudo, não devem ser descartados os dados de referência, pois suportam regras de negócio enquanto que dados de código podem ter o código substituído pela respectiva descrição nos objetos de negócio em que são utilizados sem que o seu significado seja alterado.

É preciso avaliar como uma entidade candidata é utilizada pelas transações e a sua dependência em relação a outras entidades.

É importante verificar como os processos elementares da aplicação mantêm essas entidades. A inclusão e exclusão conjunta de determinado grupo de dados de entidades é um forte indicador que esse grupo deve ser considerado um único arquivo lógico. A alteração de dados normalmente está direcionada apenas para uma única entidade; consequentemente, ela não é uma orientação efetiva para agrupar entidades. Os processos elementares de extração que consultam essas entidades devem ser verificados bem como se essas entidades também são consultadas conjuntamente.

Entidades com alto grau de dependência também podem indicar um único arquivo lógico. Cada uma das entidades dependentes pode ser um tipo de registro a ser considerado na determinação da complexidade desse arquivo lógico. Por exemplo, tanto a entidade Nota Fiscal quanto a entidade Itens da Nota isoladamente não são arquivos lógicos, contudo, em conjunto, elas são um arquivo lógico.

As abstrações identificadas na atividade de análise do processo de desenvolvimento do TCU são candidatas a arquivos lógicos em uma aplicação e devem passar pelo crivo das regras de identificação para a correta avaliação, conforme CPM.

2.3.2. Classificação de cada arquivo lógico como ALI ou AIE

A diferença básica entre um arquivo lógico interno (ALI) e um arquivo de interface externa (AIE) é que um AIE não é mantido pela aplicação sendo contada. O AIE está conceitualmente fora da fronteira da aplicação enquanto o ALI está dentro da mesma.

2.3.2.1. Regras de classificação de arquivo lógico interno

Para que determinada função seja identificada como um ALI, todas as regras seguintes devem ser válidas:

• O grupo de dados ou informações de controle é logicamente relacionado e identificável pelo usuário dentro do escopo da medição;

• O grupo de dados é mantido dentro da fronteira da aplicação sendo contada;

• Sua principal intenção é armazenar dados mantidos através de um ou mais processos elementares dentro da fronteira da aplicação sendo contada.

2.3.2.2. Regras de classificação de arquivo de interface externa

Para que determinada função seja contada como um arquivo de interface externa, todas as regras seguintes devem ser válidas:

• O grupo de dados ou informações de controle é logicamente relacionado e identificável pelo usuário dentro do escopo da medição;

• O grupo de dados é referenciado pela aplicação sendo contada, porém é externo a ela;

• O grupo de dados não é mantido pela aplicação sendo contada;

• O grupo de dados é mantido por outra aplicação, isto é, deve ser um ALI para outra aplicação;

• Sua principal intenção é armazenar dados referenciados através de um ou mais processos elementares que estiverem dentro da fronteira da aplicação sendo contada.

Conforme IFPUG (2015), no caso de dados retornados pela Aplicação A de múltiplos AIEs, para a Aplicação B, os campos (TD – Tipos de Dados) e subagrupamentos de dados (TR - Tipos de Registro) são determinados pela visão lógica dos dados do aplicativo B e os atributos realmente utilizados. Se este for considerado um grupo lógico de dados, ele é contado como um AIE no aplicativo B, independentemente da visão do aplicativo A. Se for considerado mais do que um grupo lógico de dados no aplicativo B, seria contado como mais de um AIE. O CPM afirma que os dados devem ser "identificados em um ALI em uma ou mais outras aplicações". Não estipula que lá apenas seja um ALI para um AIE.

2.3.3. Regras de contagem de campos (TD - Tipos de Dado)

Na contagem de campos (TD) que atravessam a fronteira deve-se abstrair dos detalhes de armazenamento físico da informação, considerando-se sempre a visão do usuário, o

reconhecimento por parte do usuário do tipo de dados em questão. As seguintes regras devem ser válidas para contagem de tipos de dados:

• Deve-se contar cada campo único reconhecido pelo usuário e não repetido, mantido ou recuperado de um ALI ou AIE por meio da execução de um processo elementar.

• Quando duas aplicações mantêm ou referenciam o mesmo ALI/AIE, devem ser contados apenas os campos utilizados pela aplicação em análise.

• Deve-se contar cada campo solicitado pelo usuário para estabelecer um relacionamento com outro arquivo lógico (ALI ou AIE).

As considerações a seguir assumem que os tipos de dados são reconhecidos pelo usuário, não repetidos e mantidos por algum processo elementar:

• Campos do tipo data devem ser contados como um único tipo de dado, mesmo que estejam separados em múltiplos campos (dia, mês e ano).

• Uma imagem anterior a uma atualização de um grupo de “n” campos mantidos para propósitos de auditoria é contada como um tipo de dado da imagem anterior e “n” tipos de dados para os campos, totalizando assim “n+1” tipos de dados. No caso da solução de auditoria utilizada pelo TCU, também são contados n+1 tipos de dados, pois conceitualmente equivale à mesma abordagem, i.e., apesar de ter 2n campos físicos, os dados anteriores poderiam estar contidos em uma única imagem do conjunto de itens de dados anteriores à atualização.

• Xxxxxx calculados e armazenados em um ALI também devem ser contados como tipos de dados.

• Campos do tipo timestamp devem ser contados como tipos de dados.

• Caso a chave estrangeira seja composta por vários campos, cada um deles deve ser contado como um tipo de dado.

• Quando um único arquivo lógico é composto por mais de uma tabela no banco de dados, a chave estrangeira usada para estabelecer o relacionamento entre estas tabelas não deve ser contada mais de uma vez como tipo de dado.

• Os dados de código não devem ser contados como tipos de dados. Os dados de referência devem ser contados normalmente como tipos de dados.

2.3.4. Regras de contagem de subagrupamentos (TR - Tipos de Registro)

As seguintes regras devem ser utilizadas para determinar o número de subagrupamentos de dados (tipos de registro - TR) de um ALI ou AIE.

• Deve-se contar um tipo de registro para cada subgrupo (ou subtipo), obrigatório ou opcional, de um ALI ou AIE.

• Se não houver nenhum subgrupo, deve-se contar o próprio ALI ou AIE como um tipo de registro.

2.3.5. Considerações para funções de dado em casos de melhoria

Uma função de dado é considerada modificada e integrante do escopo de medição de um caso de melhoria se ela for modificada em sua estrutura, ou seja, campos devem ser acrescentados, excluídos ou terem algum atributo alterado. A seguir, são apresentados os procedimentos corretos para algumas situações bem comuns.

• Se a mudança envolve apenas a alteração dos dados armazenados em um arquivo, não se pode considerar que o arquivo foi alterado em sua estrutura, não sendo contado no caso de melhoria.

• Se um campo foi adicionado a um ALI ou AIE, e ele não é mantido ou referenciado na aplicação, então não houve alteração desse arquivo dentro da aplicação alvo da medição. Para confirmar se o campo é utilizado na aplicação ou não, procure alguma função transacional que tenha sido criada ou alterada para manipular esse campo.

• Se uma aplicação passa a manter ou referenciar um campo já existente e que antes não era utilizado, então se considera que o ALI ou AIE foi alterado para essa aplicação (mesmo que não haja nenhuma alteração física no arquivo).

• Se um campo é adicionado, alterado ou excluído de um ALI ou AIE pertencente a várias aplicações e elas referenciam ou mantêm o campo, essa alteração de funcionalidade é contada para cada uma das aplicações.

• Se um arquivo físico ou tabela foi criado pelo caso de melhoria, não necessariamente resultará em um novo ALI ou AIE. Essa tabela pode ser também um novo tipo de registro em um ALI ou AIE existente. Ou também pode não representar nada do ponto de vista do usuário. Devem ser revisadas sempre as regras de identificação das funções de dado.

2.4. Identificação Das Funções Transacionais

As funções transacionais representam as funcionalidades de processamento de dados fornecidas pela aplicação ao usuário. São processos elementares e únicos. Transações semelhantes, que são constituídas do mesmo processo elementar, devem ser consideradas instâncias de uma única função transacional, devendo ser contadas uma única vez dentro de uma aplicação.

As funções transacionais são classificadas em entradas externas, saídas externas e consultas externas.

2.4.1. Regras para determinar se um processo elementar é único

Em todas as funções transacionais, para determinar se devemos contar mais de um processo, uma ou mais das três proposições devem obrigatoriamente ser verdadeiras:

• A lógica de processamento é diferente da executada por outros processos elementares da aplicação. A exceção é quanto à ordenação, ou seja, dois relatórios, cuja diferença seja apenas a ordenação dos dados, constituem um único processo elementar;

• O conjunto de tipos de dados identificado é diferente do identificado para outros processos elementares da aplicação;

• Os ALI e AIE referenciados são diferentes dos arquivos referenciados por outros processos elementares da aplicação.

2.4.2. Regras de identificação de entrada externa (EE)

Para que uma função transacional seja classificada como entrada externa, ela deve atender a todas as regras abaixo:

• Ser um processo elementar;

• Processar dados ou informações de controle originadas fora da fronteira da aplicação;

• Ter como principal intenção manter um ou mais arquivos lógicos internos e/ou alterar o comportamento da aplicação.

2.4.3. Regras de identificação de saída externa (SE)

Para que uma função transacional seja classificada como saída externa, ela deve atender a todas as regras abaixo:

• Ser um processo elementar;

• Enviar dados ou informações de controle para fora da fronteira da aplicação;

• Ter como principal intenção apresentar informações ao usuário através de lógica de processamento que não seja apenas uma simples recuperação de dados ou informações de controle. Sua lógica de processamento deve obrigatoriamente conter cálculo, ou criar dados derivados, ou manter um arquivo lógico interno, ou alterar o comportamento da aplicação.

2.4.4. Regras de identificação de consulta externa (CE)

Para que uma função transacional seja classificada como consulta externa, ela deve atender a todas as regras abaixo:

• Ser um processo elementar.

• Enviar dados ou informações de controle para fora da fronteira da aplicação.

• Ter como principal intenção apresentar informações ao usuário através da simples recuperação de dados ou informações de controle de ALIs e/ou AIEs. Sua lógica de processamento não deve conter fórmula matemática ou cálculo, tampouco criar dados derivados. Nenhum ALI pode ser mantido durante seu processamento, nem o comportamento da aplicação pode ser alterado.

2.4.5. Regras de contagem de campos (TD – Tipos de Dado)

As seguintes regras devem ser válidas na contagem de campos (TD - Tipos de Dados):

• Deve-se contar um tipo de dado para cada campo, não repetido e reconhecido pelo usuário, que entra ou sai pela fronteira da aplicação e necessário à conclusão do processo;

• Se um campo tanto entra quanto sai pela fronteira da aplicação, deve ser contado uma única vez;

• Os campos que durante o processo elementar são recuperados ou derivados pela aplicação e armazenados em um ALI, mas não atravessam a fronteira da aplicação, não devem ser contados como tipos de dados;

• Deve-se contar um único tipo de dado para a capacidade de envio para fora da fronteira da aplicação de uma mensagem de resposta da aplicação, indicando um erro verificado durante o processamento, a confirmação da sua conclusão ou a verificação de seu prosseguimento;

• Deve-se contar um tipo de dado para a capacidade de especificar uma ação a ser tomada, mesmo que haja múltiplos meios de ativar o mesmo processo, deve ser contado apenas um tipo de dado;

• Não devem ser contados literais, como título de relatórios, cabeçalhos, etc., como tipo de dados;

• Não devem ser contadas variáveis de paginação ou campos automáticos gerados pela aplicação.

2.4.6. Regras de contagem para arquivo referenciado (AR)

As seguintes regras devem ser válidas na contagem de um arquivo referenciado. As duas primeiras, que tratam da atualização de arquivos, não são aplicáveis para consultas externas.

• Deve-se contar um arquivo referenciado para cada ALI mantido;

• Deve-se contar apenas um arquivo referenciado para cada ALI que seja tanto mantido quanto lido;

• Deve-se contar um arquivo referenciado para cada ALI ou AIE lido durante o processamento.

2.4.7. Considerações para funções transacionais em casos de melhoria

Uma função transacional é considerada modificada e integrante do escopo de medição de um caso de melhoria quando há alteração em alguns dos seguintes itens:

• Tipos de dados: se eles foram adicionados, excluídos ou alterados da função. Se houve alteração apenas de elementos visuais, como literais, cores e formatos, não se considera que a função foi alterada.

• Arquivos referenciados: se eles foram adicionados, excluídos ou alterados pela função.

• Lógica de processamento: uma transação pode ter várias lógicas de processamento, basta que uma delas seja alterada, excluída ou adicionada para que se considere a função como modificada. Embora a ordenação seja a única lógica de processamento que não é suficiente para determinar a unicidade de uma transação, sua alteração também determina uma alteração na função.

2.5. Mensuração Do Tamanho Funcional De Cada Função

Identificadas as funcionalidades que integram o escopo da medição, o próximo passo é derivar efetivamente o tamanho funcional associado a cada função.

2.5.1. Mensuração do tamanho funcional em elementos funcionais e suas submétricas

A métrica Elementos Funcionais (EF) proposta por Xxxxxx e Xxxxxxxxx (2013) baseia-se nos conceitos da métrica Pontos de Função, mas sem algumas de suas falhas conhecidas relativas à forma de cálculo. A métrica foi construída em pós-graduação patrocinada pelo TCU de servidor da Casa junto à Universidade de Brasília. O trabalho foi selecionado no 27º Simpósio Brasileiro de Engenharia de Software em outubro de 2013 e publicado tanto na base digital do Institute of Electrical and Electronic Engineers (IEEE Xplore) quanto na edição de número 135 da Revista do TCU em 2016. E foi premiado internamente no TCU com o prêmio de Trabalho Inovador no ano de 2015.

Cada tipo de funcionalidade tem sua fórmula de cálculo (ver tabela abaixo) baseada nos quantitativos de atributos funcionais: AR (Arquivos Referenciados), TD (Tipo de Dado) e TR (Tipo de Registro). Em caso de manutenção evolutiva, deve-se considerar os atributos funcionais afetados pela alteração (conceito aplicado também na Nesma). Em caso de exclusão

de uma funcionalidade, o tamanho assume o valor da constante, uma vez que não há atributos especificamente impactados por essa operação. Tanto desenvolvimentos quanto manutenções de software são medidos da mesma forma.

Funcionalidade	Fórmula derivada
ALI	EFd = 1,75 + 0,96*TR + 0,12*TD
AIE	EFd = 1,25 + 0,65*TR + 0,08*TD
SE	EFt = 1,00 + 0,81*AR + 0,13*TD
EE	EFt = 0,75 + 0,91*AR + 0,13*TD
CE	EFt = 0,75 + 0,76*AR + 0,10*TD

Tabela 1 - Fórmulas de cálculo de elementos funcionais por tipo de funcionalidade

A métrica Elementos Funcionais, EF, resulta da soma dos Elementos Funcionais de Transação, EFt, com os Elementos Funcionais de Dados, EFd. Essas submétricas representam respectivamente os elementos funcionais associados a transações (CE, EE e SE) e a dados (AIE e ALI).

2.5.2. Mensuração do tamanho funcional em pontos de função

2.5.2.1. Mensuração em pontos de função de desenvolvimento de funcionalidade

Para se dimensionar o desenvolvimento de uma funcionalidade em pontos de função é necessário primeiro classificar a sua complexidade e depois derivar, conforme tabela abaixo, o número de pontos de função a partir das complexidades identificadas.

Tabela 2 – Pontos de função por complexidade e tipo de função

Funções	Complexidade
	Baixa	Média	Alta
AIE	5 FP	7 FP	10 FP
ALI	7 FP	10 FP	15 FP
CE	3 FP	4 FP	6 FP
EE	3 FP	4 FP	6 FP
SE	4 FP	5 FP	7 FP

2.5.2.1.1. Classificação da complexidade de funções de dado

Cada função de dado é classificada com relação à sua complexidade em baixa, média e alta. A complexidade das funções de dado é determinada pela quantidade de tipos de dados

(campos) e tipos de registro (subgrupos de dados dentro do arquivo) visíveis ao usuário na fronteira da aplicação.

Quantidade de tipos de registro (TR)	Quantidade de tipos de dados (TD)
	1 a 19	20 a 50	51 ou mais
1	Baixa	Baixa	Média
2 a 5	Baixa	Média	Alta
6 ou mais	Média	Alta	Alta

A tabela a seguir deve ser usada para derivação da complexidade das funções de dado. Tabela 3 – Complexidade das funções de dado

2.5.2.1.2. Classificação da complexidade de funções transacionais

Cada função transacional é classificada com relação à sua complexidade em baixa, média e alta. As funções transacionais têm sua complexidade determinada pela quantidade de tipos de dados (campos) e arquivos referenciados (ALI ou AIE), conforme tabelas apresentadas aseguir.

As tabelas a seguir devem ser usadas para derivação da complexidade das transações de acordo com seu tipo.

Tabela 4 – Complexidade das entradas externas

Quantidade de arquivos referenciados (AR)	Quantidade de tipos de Dados (TD)
	1 a 4	5 a 15	16 ou mais
0 a 1	Baixa	Baixa	Média
2	Baixa	Média	Alta
3 ou mais	Média	Alta	Alta

Tabela 5 – Complexidade das saídas externas e consultas externas

Quantidade de arquivos referenciados (AR)	Quantidade de tipos de Dados (TD)
	1 a 5	6 a 19	20 ou mais
0 a 1	Baixa	Baixa	Média
2 a 3	Baixa	Média	Alta
4 ou mais	Média	Alta	Alta

2.5.2.2. Mensuração em Pontos de função de manutenção evolutiva de funcionalidade O dimensionamento de pontos de função em um caso de melhoria de uma funcionalidade

(no contexto deste manual, o termo ‘melhoria’ significa mudança funcional) baseia-se nas regras definidas pela Nesma, versão 1.0, que define a unidade ponto de função de melhoria (EFP - Enhancement Function Point). Valem as definições deste manual em caso de conflito com a Nesma. Assim, um ponto de função (PF ou FP) será equivalente a um ponto de função de melhoria (EFP).

2.5.2.2.1. Dimensionamento de EFP em funcionalidades incluídas

Segundo a Nesma, as funcionalidades incluídas em um caso de melhoria serão dimensionadas usando o método FSM padrão do IFPUG. Ou seja, o fator de impacto será 1.

EFPinc = FPinc * 1 Em que:

EFPinc – pontos de função de melhoria da funcionalidade envolvida FPinc – pontos de função da funcionalidade envolvida

2.5.2.2.2. Dimensionamento de EFP em funcionalidades de conversão de dados

Segundo a Nesma, as funcionalidades de conversão em um caso de melhoria serão dimensionadas usando o método FSM padrão do IFPUG. Ou seja, o fator de impacto será 1.

EFPconv = FPconv * 1 Em que:

EFPconv – pontos de função de melhoria da funcionalidade de conversão envolvida FPconv – pontos de função da funcionalidade de conversão envolvida.

2.5.2.2.3. Dimensionamento de EFP em funcionalidades excluídas

Para funções excluídas, um fator de impacto de 0,4 é usado. O número de pontos de função de melhoria para uma única função excluída é determinado da seguinte forma:

EFPexc = 0,4 * FPexc Em que:

EFPexc – pontos de função de melhoria da funcionalidade excluída FPexc – pontos de função da funcionalidade excluída

2.5.2.2.4. Dimensionamento de EFP em funcionalidades alteradas 2.5.2.2.4.1. Funções dedados

As funções de dados que mudam são identificadas e o tamanho de cada função de dados após a mudança é determinado.

Para funções de dados que mudem estruturalmente, um fator de impacto é calculado a partir da porcentagem de elementos de dados mudados. A porcentagem de mudança é definida como a razão definida pelo número de elementos de dados modificados dividido pelo número de elementos de dados originais:

Porcentagem de mudança = Número de TDs incluídos/alterados/excluídos x 100

Número de TDs na função de dados original O fator de impacto FI é obtido da tabela abaixo usando a porcentagem de mudança em

número de elementos de dados:

Tabela 6 – Fatores de impacto para funções de dados

Porcentagem de TDs	<=33%	<=67%	<=100%	>100%
Fator de impacto (FI)	0,25	0,50	0,75	1,00

Se uma função de dados mudar de tipo (por exemplo, um AIE se tornar um ALI), um valor de 0,4 é usado para o fator de impacto.

Mudanças de tipo precisam ser avaliadas também para identificar mudanças no número de elementos de dados. Se o número de elementos de dados mudar juntamente com o tipo, o fator de impacto devido à mudança no número de elementos de dados deve ser determinado. O valor do fator de impacto devido à mudança no tipo é comparado com aquele devido à mudança no número de elementos de dados e o maior valor é usado no cálculo dos pontos de função de melhoria.

Se um AIE ou um ALI for dividido em duas (ou mais) funções de dados, uma função de dados excluída e duas (ou mais) adicionadas são contadas.

Se um AIE e um ALI são combinados, duas funções de dados excluídas e uma função de dados adicionada são contadas.