ANEXO I

ANEXO I

ENCARTE A: TERMO DE REFERÊNCIA

CAPÍTULO 1. DO OBJETO

1.1. O objeto da presente licitação é a escolha da proposta mais vantajosa para a contratação de empresa especializada na prestação de serviços de Tecnologia da Informação na forma de serviço continuado presencial e não presencial compreendendo Fábrica de Software sem dedicação exclusiva de mão de obra.

1.2. Contratação de empresa para prestação de serviços de Tecnologia da Informação para atender às necessidades do Conselho de Arquitetura e Urbanismo do Brasil – CAU/BR, de acordo com as especificações, padrões técnicos de desempenho e qualidade estabelecidos neste Termo de Referência, contemplando as atividades de projeto, sustentação, serviço e documentação de sistemas de informação, na modalidade Fábrica de Software (FSW), baseado nas práticas e princípios das “metodologias ágeis”.

1.3. Serviços que Compõem a Solução e Estimativa de Volume.

GRUPO	ITEM	DESCRIÇÃO DO ITEM	UNIDADE	QUANTIDADE ESTIMADO	VALORES MÁXIMO ESTIMADOS (EM REAIS/POR ITEM
					UNITÁRIO (R$)	TOTAL (R$)
		Serviços técnicos
	1	de desenvolvimento de sistemas e aplicativos	PF (Ponto de Função)	14.000	R$ XXX,XX	R$ XXX.XXX,XX
		mobile
		Serviços técnicos	PFS (Ponto de Função Sustentado)
	2	de sustentação de sistemas e aplicativos		7.000	R$ XX,XX	R$ XXX.XXX,XX
		mobile
1		Serviços técnicos de	UST (Unidade de Serviço Técnico)
	3	desenvolvimento portais, transferência de		7.000	R$ XXX,XX	R$ XXX.XXX,XX
		Conhecimento e
		Consultoria em TI
	4	Serviços técnicos de sustentação de portais	USTS (Unidade de Serviço Técnico Sustentável)	3.500	R$ XX,XX	R$ XXX.XXX,XX
Total						R$ X.XXX.XXX,XX

Tabela 01: Quantitativo e Valores Estimados

CAPÍTULO 2. DA JUSTIFICATIVA E OBJETO DA CONTRATAÇÃO

2.1. Os Conselhos de Arquitetura e Urbanismo vêm se tornando um conjunto autárquico cada vez mais orientado aos resultados, o que envolve o desenvolvimento de melhorias contínuas em seus processos, desde as fases iniciais do trabalho de planejamento e implantação de ações, até o gerenciamento de maneira controlada, o que irá auxiliar a atuação do órgão de várias maneiras;

2.2. A Tecnologia da Informação (TI) é, cada vez mais, um fator crítico para as organizações do setor público ou privado. Ciente desse fato, o CAU/BR realizará essa contratação para suportar sua estrutura de atuação no âmbito dos serviços prestados pelo Centro de Serviços Compartilhados do CAU (CSC-CAU), atuando para atendimento do volume de demandas, gerenciamento e prestação de contas aos Entes do compartilhamento;

2.3. Por não dispor de quadro próprio de profissionais especializados em TI para as atividades de desenvolvimento e manutenção de sistemas e portais, o CAU/BR recorre à contratação de

empresa especializada, que também encontra respaldo no Decreto 2.271/97, Art. 1º, §1º (preconiza-se a execução preferencialmente indireta das atividades de informática, restringindo no §2º as atividades que estejam contempladas no plano de cargos do órgão).

2.4. Além de sua previsão no PDTI - Plano Diretor de Tecnologia da Informação - do CAU/BR, a contratação dos serviços técnicos de Tecnologia da Informação em Desenvolvimento de Sistemas permitirá ao CAU o atendimento às suas necessidades de sistemas de informação atuais e futuras, bem como:

2.4.1.1. Melhorar o processo de desenvolvimento e sustentação de sistemas de informação do CAU, baseado nas premissas do Processo de Software do SISP/SLTI, garantindo execução de novos projetos, bem como a continuidade dos projetos e necessidades de sustentação já identificados e/ou iniciados pela Gerência de Serviços Compartilhados (GESC);

2.4.1.2. Alavancar melhorias no relacionamento entre o CAU e usuários dos sistemas, proporcionando maior celeridade no atendimento de demandas relacionadas às necessidades de sistemas de informação do CAU; e

2.4.1.3. Executar a metrificação de todas as demandas provenientes das áreas usuárias.

2.4.1.4. Soma-se a este aspecto o fato da metodologia aplicável ao atual contrato estar obsoleta, e prejudicando o pleno atendimento das necessidades de desenvolvimento de software do CAU. Por meio do novo contrato será possível aplicar métodos mais atuais utilizados pelo mercado, dando maior vazão às entregas estabelecidas pelo Conselho.

CAPITULO 3. DESCRIÇÃO DA SOLUÇÃO

3.1. A presente contratação visa a atender as necessidades do Conselho de Arquitetura e Urbanismo do Brasil CAU/BR, através do provimento de serviços de desenvolvimento, manutenção, sustentação de softwares e portais, cujos itens estão divididos da seguinte forma:

Item	Unidade de Medida	Descrição
1	Ponto de Função - PF	Unidade de medida de tamanho funcional de software novo (sistemas e aplicativos mobile).
2	Ponto de Função Sustentado PFS	Unidade de medida de tamanho funcional de software sustentado (sistemas e aplicativos mobile).
3	Unidade de Serviço Técnico – UST	Unidade de medida de esforço que será aplicada aos serviços de desenvolvimento de portais.
4	Unidade de Serviço Técnico de Sustentação - USTS	Unidade de medida de esforço que será aplicada aos serviços de sustentação de portais.

Tabela 02: Unidades de Medidas

3.1.1. ITEM 1: serviços técnicos especializados de desenvolvimento e manutenção de soluções de software, na modalidade “Fábrica de Software”, na forma de serviços continuados presenciais e não presenciais, em regime de empreitada por preço unitário, remunerados segundo a métrica de Ponto de Função (PF), sem garantia de consumo mínimo, de acordo com as especificações e os padrões de desempenho e qualidade estabelecidos pelo Conselho de Arquitetura e Urbanismo do Brasil - CAU/BR neste Termo de Referência.

3.1.1.1. Desenvolvimento: projeto de desenvolvimento de um novo sistema ou aplicativo mobile, ou de um ou mais módulos de um sistema/aplicativo já existente, de acordo com as práticas ágeis.

3.1.1.2. Manutenção Evolutiva: compreende melhorias em sistemas e aplicativos já existentes, como a inclusão de novas funcionalidades, alteração e exclusão de funcionalidades já existentes, e manutenções evolutivas na arquitetura ou em qualquer outro aspecto não funcional que necessite ser melhorado.

3.1.1.3. Manutenção Adaptativa: adequação do sistema às mudanças de ambiente operacional, compreendendo hardware e software básico, mudanças de versão, linguagem e SGBD (Sistema de Gerenciamento de Banco de Dados), que não impliquem em inserção, alteração ou exclusão de funcionalidades sob o ponto de

vista do usuário. Compreende também as melhorias com a finalidade de promover maior desempenho, manutenibilidade e usabilidade do sistema.

3.1.1.4. Implantação de Sistema: contempla a implantação e adaptação de sistemas ou aplicativos desenvolvidos internamente e demais localidades do CAU/BR.

3.1.1.5. Sustentação sob Demanda: contempla todos os serviços descritos no Item

2 (Prestação de serviços técnicos de sustentação dos sistemas e aplicativos mobile), mas na modalidade "sob demanda", que necessitem da atuação, desde que os sistemas e aplicativos não estejam contemplados pelo Catálogo de Sistemas e Aplicativos Sustentados.

3.1.2. ITEM 2: serviços técnicos especializados de sustentação de soluções de software, na modalidade “fábrica de sustentação”, na forma de serviços continuados presenciais e não presenciais, em regime de empreitada por preço unitário, remunerados segundo a métrica de Ponto de Função Sustentado (PFS), sem garantia de consumo mínimo, de acordo com as especificações e os padrões de desempenho e qualidade estabelecidos Conselho de Arquitetura e Urbanismo do Brasil - CAU/BR neste Termo de Referência.

3.1.2.1. Manutenção Corretiva: contempla análise e correção de falhas ou defeitos de sistemas em produção, abrangendo comportamentos inadequados que causem problemas de uso ou mau funcionamento do sistema e quaisquer desvios em relação aos requisitos aprovados pela área demandante da solução.

3.1.2.2. Apuração Especial: contempla os serviços de inclusão (carga de dados), alteração, consulta ou exclusão no banco de dados de produção, elaboração de relatórios, levantamento de informações complementares e não disponibilizados de forma automática via sistemas ou para possibilitar o correto funcionamento de uma funcionalidade.

3.1.2.3. Suporte ao Usuário: esclarecimento ou auxílio pontual na utilização correta dos sistemas, bem como a concessão de acesso e permissões para usuários utilizarem os sistemas.

3.1.2.4. Apoio à Produção: suporte para análise, diagnóstico e resolução de incidentes visando solução e proposta de melhoria, se couber, para tratamento das causas de problemas.

3.1.2.5. Apoio Técnico: suporte na implantação de processos e de ferramentas, participar de reuniões técnicas e de quaisquer iniciativas que visem a melhoria da sustentação de sistemas.

3.1.3. Item 3 (UST) – Prestação de serviços técnicos de desenvolvimento de portais, transferência de Conhecimento e Consultoria em TI, sem garantia de consumo mínimo, conforme condições, quantidades e exigências estabelecidas neste instrumento.

3.1.3.1. Esses serviços serão dimensionados segundo a métrica Unidade de Serviço Técnico - UST, conforme disposto no Catálogo de Serviços para Desenvolvimento/Melhorias e Sustentação de Portais, transferência de Conhecimento e Consultoria em TI, Tabela 1, Encarte M deste Termo de Referência. Esse catálogo possui quantidades pré-definidas de UST de acordo com critérios que definem a complexidade para cada atividade de solicitação. As atividades que compõe os serviços de desenvolvimento de portais se encontram nesse anexo. Os serviços do item 3 serão realizados sob demanda e sem garantia de consumo mínimo.

3.1.3.2. Para efeitos deste documento, considera-se o termo "portal" para todo sistema que apresentar páginas web estáticas e/ou serem desenvolvidos por meio de Sistemas Gerenciadores de Conteúdo.

3.1.4. Item 4 (USTS) – Prestação de serviços técnicos de sustentação de portais. Esses serviços serão realizados por meio de desembolso mensal, um valor fixo para a realização de sustentação dos portais baseando-se na quantidade total de páginas estáticas dos portais da CONTRATANTE, conforme levantamento disposto no Catálogo de Portais Sustentados versão 1.0 Encarte N deste Termo de Referência, sendo utilizada a métrica de Unidade de Serviço Técnico Sustentado (USTS). As modalidades que compõe os serviços de sustentação de portais estão dispostas no

Catálogo de Serviços para Desenvolvimento/Melhorias e Sustentação de Portais, no Encarte N deste Termo de Referência.

3.2. Cenário Atual

3.2.1. As últimas contratações de serviços de desenvolvimento, manutenção e sustentação de sistemas de informação foram realizadas pelo CAU/BR nos anos de 2014 e 2018, como resultado dos contratos n° 33/2014 e n° 03/2019. Os quantitativos e as métricas inicialmente contratados foram:

CONTRATO

DURAÇÃO

VIGÊNCIA

VOLUME (EM PF)

VOLUME (EM UST)

VALOR GLOBAL

n° 33/2014

48 MESES

2018

10.000

-

R$ 8.013.500,00

n° 03/2019

24 MESES

2020

5.000

1.000

R$ 4.798.193,75

Tabela 03: Contratos CAU/BR

3.2.2. Considerando a situação desses contratos, em face da necessidade de ampliação da capacidade de atendimento às demandas e da necessidade de promover aprimoramento do modelo técnico-gerencial em vigor, a área requisitante apresentou Documento de Oficialização de Demanda a partir do qual, em conformidade com as disposições da Instrução Normativa n° 01/2019, de 04 de abril de 2019, da Secretaria de Governo Digital do Ministério da Economia, foi realizado o planejamento da presente contratação.

3.3. Descrição das necessidades

3.3.1. Em linhas gerais, as necessidades a serem atendidas pela pretensão contratual são as seguintes:

a) Provimento de serviços de desenvolvimento e manutenção de soluções de softwares para atendimento, por intermédio da área requisitante, às demandas do Conselho de Arquitetura e Urbanismo do Brasil – CAU/BR;

b) Provimento de serviços de sustentação de soluções de software para atendimento, por intermédio da área requisitante, às necessidades do Conselho de Arquitetura e Urbanismo do Brasil – CAU/BR;

c) Aprimoramento técnico-gerencial do planejamento, da execução, do monitoramento, do suporte e da evolução do ambiente e das soluções de software do Conselho de Arquitetura e Urbanismo do Brasil – CAU/BR;

d) Aprimoramento do controle e da conformidade sobre serviços, resultados, processos e contratos relacionados à área de sistemas de informação do Conselho de Arquitetura e Urbanismo do Brasil – CAU/BR; e

e) Ampliação da aprendizagem organizacional e da maturidade em atividades de engenharia de software.

3.4. Justificativa do volume a ser contratado

3.4.1. Considerando os resultados do ESTUDO TÉCNICO PRELIMINAR da contratação, a necessidade estimada de serviços para cada período de 12 (doze) meses, conforme suas métricas específicas, é a seguinte:

ITEM	DESCRIÇÃO DO ITEM	UNIDADE		QUANTIDADE ANUAL ESTIMADA (CAU/BR)
1	Serviços técnicos de desenvolvimento de sistemas e aplicativos mobile	PF	14.000
2	Serviços técnicos de sustentação de sistemas e aplicativos mobile	PFS	7.000
3	Serviços técnicos de desenvolvimento portais	UST	7.000
4	Serviços técnicos de sustentação de portais	USTS	3.500

Tabela 04: Estimativas de Valores por Unidade de Medida

3.5. Alinhamento com as estratégias organizacionais

3.5.1. A contratação pretendida encontra-se em harmonia ao PDTI - Plano Diretor de Tecnologia da Informação - do CAU/BR, a contratação dos serviços técnicos de Tecnologia da Informação em Desenvolvimento de Sistemas permitirá ao CAU o atendimento às suas necessidades de sistemas de informação atuais e futuras, bem como:

3.5.2. Melhorar o processo de desenvolvimento e sustentação de sistemas de informação do CAU, baseado nas premissas do Processo de Software do SISP/SLTI, garantindo execução de novos projetos, bem como a continuidade dos projetos e necessidades de sustentação já identificados e/ou iniciados pela Gerência de Serviços Compartilhados (GESC); e

3.5.3. Alavancar melhorias no relacionamento entre o CAU e usuários dos sistemas, proporcionando maior celeridade no atendimento de demandas relacionadas às necessidades de sistemas de informação do CAU.

3.6. Alinhamento com leis, normas e regulamentos

3.6.1. Na elaboração do Estudo Técnico Preliminar foram observadas as seguintes fontes legais e normativas:

3.6.2. Lei Federal n° 8.666/1993: institui normas gerais para licitações e contratos na Administração Pública e dá outras providências;

3.6.3. Lei Federal nº 10.520/2002: institui a modalidade de licitação denominada pregão eletrônico para aquisição de bens e serviços comuns e dá outras providências;

3.6.4. Lei Federal nº 12.846/2013: dispõe sobre a responsabilização administrativa e civil de pessoas jurídicas pela prática de atos contra a administração pública, nacional ou estrangeira, e dá outras providências;

3.6.5. Lei Complementar n° 123/2006: institui o Estatuto Nacional da Microempresa e da Empresa de Pequeno Porte, e dá outras providências;

3.6.6. Decreto nº 7.174/2010: regulamenta a contratação de bens e serviços de informática e automação pela administração pública federal, direta ou indireta, pelas fundações instituídas ou mantidas pelo Poder Público e pelas demais organizações sob o controle direto ou indireto da União;

3.6.7. Decreto n° 7.579/2011: dispõe sobre o Sistema de Administração dos Recursos de Tecnologia da Informação - SISP, do Poder Executivo federal;

3.6.8. Decreto 7.746/2012: regulamenta o art. 3º da Lei nº 8.666, de 21 de junho de 1993, para estabelecer critérios e práticas para a promoção do desenvolvimento nacional sustentável nas contratações realizadas pela administração pública federal direta, autárquica e fundacional e pelas empresas estatais dependentes, e institui a Comissão Interministerial de Sustentabilidade na Administração Pública – CISAP;

3.6.9. Decreto n° 7.903/2013: estabelece a aplicação de margem de preferência em licitações realizadas no âmbito da administração pública federal para aquisição de equipamentos de tecnologia da informação e comunicação que menciona;

3.6.10. Decreto n° 8.4202015: regulamenta a Lei nº 12.846, de 1º de agosto de 2013, que dispõe sobre a responsabilização administrativa de pessoas jurídicas pela prática de atos contra a administração pública, nacional ou estrangeira e dá outras providências;

3.6.11. Decreto nº 9.507/2018: dispõe sobre a execução indireta, mediante contratação, de serviços da administração pública federal direta, autárquica e fundacional e das empresas públicas e das sociedades de economia mista controladas pela União;

3.6.12. Decreto nº 9.739/2019: estabelece medidas de eficiência organizacional para o aprimoramento da administração pública federal direta, autárquica e fundacional, estabelece normas sobre concursos públicos e dispõe sobre o Sistema de Organização e Inovação Institucional do Governo Federal – SIORG;

3.6.13. Instrução Normativa SLTI/MP nº 05, de 27 de junho de 2014: dispõe sobre os procedimentos administrativos básicos para a realização de pesquisa de preços para a aquisição de bens e contratação de serviços em geral e suas alterações;

3.6.14. Instrução Normativa SEGES/MP n° 05, de 26 de maio de 2017: dispõe sobre as regras e diretrizes do procedimento de contratação de serviços sob o regime de execução indireta no âmbito da Administração Pública federal direta, autárquica e fundacional;

3.6.15. Instrução Normativa SEGES/ME n° 01, de 10 de janeiro de 2019: dispõe sobre Plano Anual de Contratações de bens, serviços, obras e soluções de tecnologia da informação e comunicações no âmbito da Administração Pública federal direta, autárquica e fundacional e sobre o Sistema de Planejamento e Gerenciamento de Contratações;

3.6.16. Instrução Normativa SGD/ME nº 01, de 4 de abril de 2019: dispõe sobre o processo de contratação de soluções de Tecnologia da Informação e Comunicação - TIC pelos órgãos e entidades integrantes do Sistema de Administração dos Recursos de Tecnologia da Informação - SISP do Poder Executivo Federal; e

3.6.17. Instrução Normativa SGD/ME n° 02, de 4 de abril de 2019: Regulamenta o art. 9º-A do Decreto nº 7.579, de 11 de outubro de 2011, e o art. 22, § 10 do Decreto nº 7.892, de 23 de janeiro de 2013, e dispõe sobre a composição e as competências do Colegiado Interno de Referencial Técnico; e

3.6.18. Portaria Normativa n° 74, de 2 de outubro de 2019: Dispõe sobre Plano Anual de Contratações de bens e serviços no âmbito do Conselho de Arquitetura e Urbanismo do Brasil (CAU/BR) e dá outras providências.

3.7. Requisitos dos Serviços do GRUPO 1 ITEM 1

3.7.1. ITEM 1 (PF) – Prestação de serviços técnicos de planejamento, desenvolvimento e implantação de sistemas e aplicativos mobile dimensionados segundo a métrica de Análise de Pontos de Função com base no Manual de Práticas de Contagem de Pontos de Função - CPM-IFP UG (versão 4.3.1 ou superior) e, complementarmente o Roteiro de Métricas de Software do SISP (versão 2.2 ou superior) e Guia de Contagem de Pontos de Função do MP (versão 1 ou superior) ou Guia de Contagem de Pontos de Função definido pela CONTRATANTE.

3.7.2. Este item abrangerá os serviços de desenvolvimento, evolução/adaptação, implantação e sustentação de sistemas e aplicativos mobile sob demanda.

3.7.3. Segue abaixo a descrição de cada modalidade:

3.7.4. Desenvolvimento: projeto de desenvolvimento de um novo sistema ou aplicativo mobile, ou de um ou mais módulos de um sistema/aplicativo já existente, de acordo com as práticas ágeis.

3.7.5. Manutenção Evolutiva: compreende melhorias em sistemas e aplicativos já existentes, como a inclusão de novas funcionalidades, alteração e exclusão de funcionalidades já existentes, e manutenções evolutivas na arquitetura ou em qualquer outro aspecto não funcional que necessite ser melhorado.

3.7.6. Manutenção Adaptativa: adequação do sistema às mudanças de ambiente operacional, compreendendo hardware e software básico, mudanças de versão, linguagem e SGBD (Sistema de Gerenciamento de Banco de Dados), que não impliquem em inserção, alteração ou exclusão de funcionalidades sob o ponto de vista do usuário. Compreende também as melhorias com a finalidade de promover maior desempenho, manutenibilidade e usabilidade do sistema.

3.7.7. Implantação de Sistema: contempla a implantação e adaptação de sistemas ou aplicativos desenvolvidos externamente.

3.7.8. Sustentação sob Demanda: contempla todos os serviços descritos no Item 2 (sustentação de sistemas e aplicativos mobile), mas na modalidade "sob demanda", que necessitem da atuação de forma emergencial, desde que os sistemas e aplicativos não estejam contemplados pelo Catálogo de Sistemas e Aplicativos Sustentados.

3.7.9. Os serviços técnicos de desenvolvimento deverão ser prestados de acordo com as especificações, padrões técnicos de desempenho e qualidade estabelecidos pelo CONTRATANTE, solicitados mediante Ordens de Serviço e/ou software específico de gerenciamento de demandas. Serão realizados sob demanda, limitados ao quantitativo máximo estimado anual, sem garantia de consumo mínimo, de acordo com os critérios estabelecidos neste Edital e seus Encartes.

3.7.10. Segue abaixo figura do macro-processo para desenvolvimento de sistemas e aplicativos mobile, conforme o Processo de Gestão de Demandas de Desenvolvimento Ágil de Software:

Imagem 01: Macro-processo para desenvolvimento

3.7.11. O Processo de Gestão de Demandas de Desenvolvimento Ágil de Software indicado na figura 1 acima encontra-se descrito na MGDS-CAU do CAU/BR.

3.7.12. Para o caso da modalidade Sustentação Sob Demanda, o macro-processo acima não será aplicado por se tratar dos serviços descritos no Item 2 (Sustentação de sistemas e aplicativos mobile).

3.7.13. A critério do CONTRATANTE, demandas na modalidade Manutenção Evolutiva poderão ser consideradas como Projeto de Desenvolvimento, de forma que deverá seguir o rito dos processos indicados no Processo de Gestão de Demandas de Desenvolvimento Ágil de Software.

3.7.14. Manutenções Evolutivas deverão ser atendidas em conformidade com o macro- processo descrito a seguir:

3.7.15. Cadastrar e Priorizar demandas no Backlog

3.7.16. As demandas de maior prioridade devem ser posicionadas acima das de menor prioridade.

3.7.17. Especificação

3.7.18. Deve ser verificado se a descrição da demanda é suficiente para a elaboração de sua especificação e implementação. Se forem necessárias mais informações sobre a demanda, a equipe deverá entrar em contato com o demandante para que ele aprimore sua descrição.

3.7.19. Verificar também se a granularidade da demanda está de acordo ou se devem ser criadas novas demandas a partir dela;

3.7.20. Após a especificação da demanda ser finalizada, a Fábrica de Software deverá realizar a contagem estimada dos pontos de função decorrentes da manutenção.

3.7.21. Cabe a CONTRATANTE decidir se ela deve ser fragmentada em mais demandas e seguir o fluxo de Manutenções Evolutivas ou se deve ser criado um novo Projeto de Desenvolvimento.

3.7.22. Aprovação

3.7.23. O demandante e os fiscais/gestor do contrato deverão verificar a especificação e os custos associados à demanda. Cabendo a eles aprovar ou não, a partir da análise de seu orçamento.

3.7.24. Desenvolvimento e Teste.

3.7.25. Com a demanda aprovada, a Fábrica de Software inicia o desenvolvimento do que foi especificado.

3.7.26. Após o desenvolvimento da demanda, a Fábrica de Software irá realizar o teste de integração para verificar se a implementação está correta.

3.7.27. Verificação da Qualidade

3.7.28. Garantir que a entrega (demanda) está conforme os padrões da CONTRATANTE, necessidades da área demandante, se os artefatos relativos à demanda foram

devidamente elaborados e possui a qualidade esperada para a implantação (avaliação da qualidade das entregas.

3.7.29. Homologação do Usuário

3.7.30. Disponibilização da demanda em ambiente de homologação para testes do demandante.

3.7.31. Validar a entrega junto a área demandante, buscando aprovação do produto para ser implantado.

3.7.32. Se durante a homologação o demandante encontrar alguma não-conformidade em relação a demanda solicitada, ele deverá relatar para a Fábrica de Software que deve implementar as correções necessárias. É importante ressaltar que as não- conformidades relatadas estejam em conformidade com o escopo da demanda, não devendo implicar em correções em outras funcionalidades fora do escopo.

3.7.33. Implantação em produção

3.7.34. Implantar a manutenção efetuada no ambiente de produção.

3.7.35. Realizar a contagem detalhada dos pontos de função decorrentes da manutenção.

3.7.36. Artefatos

3.7.37. A CONTRATANTE irá solicitar a elaboração de artefatos de planejamento e desenvolvimento como complemento a entrega do produto (sistema ou aplicativo desenvolvido).

3.7.38. Os artefatos mínimos a serem entregues, de competência da CONTRATADA, para a modalidade de projeto de desenvolvimento de sistemas ou de aplicativos mobile, estão descritos no Processo de Gestão de Demandas de Desenvolvimento Ágil de Software na MGDS-CAU do CAU/BR, para cada processo informado na Figura 1 acima.

3.7.39. Os artefatos dos sistemas que passaram por manutenção evolutiva deverão ser atualizados conforme alterações de regras de negócio, sendo sua atualização exigida como complemento à entrega do produto.

3.7.40. Os artefatos mínimos a serem entregues, de competência da CONTRATADA, para a modalidade de Manutenção Evolutiva, estão descritos abaixo conforme o processo de Gestão de Demandas de Manutenção de Software:

3.7.41. Especificação

3.7.42. Documento de Manutenção Evolutiva e Documentação de Requisitos (Histórias de Usuários), Planilha de contagem estimada.

3.7.43. Aprovação do Usuário

3.7.44. Documento oficializando a aprovação ou não da execução da demanda após análise de seus prazos e custos.

3.7.45. Desenvolvimento e Teste

3.7.46. Código Fonte; Documento de Requisitos atualizado; Modelo de Dados atualizado; Script de banco de dados atualizado e Evidências de Teste.

3.7.47. Verificação da Qualidade

3.7.48. Relatório de Qualidade.

3.7.49. Homologação do Usuário

3.7.50. Plano de implantação.

3.7.51. Implantação em produção

3.7.52. Planilha de contagem detalhada.

3.7.53. Para a modalidade de Sustentação Sob Demanda, a documentação deverá ser atualizada. Serão solicitados como artefatos dessa modalidade um relatório informando qual ou quais serviços de sustentação foram realizados e a solução ou resposta aplicada.

3.7.54. Processo de Faturamento

3.7.55. Os serviços serão medidos e pagos utilizando-se a métrica de Análise de Pontos de Função com base no Manual de Práticas de Contagem de Pontos de Função - CPM- IFPUG (versão 4.3.1 ou superior), e complementarmente o Roteiro de Métricas de Software do SISP (versão 2.2 ou superior) e Guia de Contagem de Pontos de Função do MP (versão 1 ou superior) ou Guia de Contagem de Pontos de Função definido pela CONTRATANTE.

3.7.56. A solicitação de serviços de desenvolvimento e implantação de sistemas e aplicativos mobile sob demanda, Sustentação sob Demanda e Manutenção Evolutiva poderá dar-

se por meio de Ordem de Serviço ou por meio de um software específico de gerenciamento de demandas definido pelo CONTRATANTE.

3.7.57. Segue abaixo Tabela informando a Distribuição da Remuneração segundo as fases\processos executados para cada tipo de demanda:

Distribuição da Remuneração por Fases
Tipo de Demanda	Fase	Remuneração	Artefato de formalização
Serviços de desenvolvimento e implantação de sistemas e aplicativos mobile (Levantamento de Requisitos)	Requisitos	15%	Ordem de Serviço e/ou software específico de gerenciamento de demandas
Serviços de desenvolvimento e implantação de sistemas e aplicativos mobile (Projetos)	Entrega em Homologação	60%	Ordem de Serviço e/ou software específico de gerenciamento de demandas
	Entrega em Produção	20%
	Encerramento do Projeto	5%
Serviços de Manutenção Evolutiva e Manutenção Adaptativa	Implantação em Produção	100%	Ordem de Serviço ou software específico de gerenciamento de demandas
Serviços de Sustentação Sob Demanda	Implantação em Produção	100%	Ordem de Serviço ou software específico de gerenciamento de demandas

Tabela 05: Distribuição da Remuneração por Fases

3.7.58. Conforme a tabela acima, o faturamento para serviços de desenvolvimento e implantação de sistemas e aplicativos mobile:

3.7.59. O equivalente a 15% da quantidade total de PF por OS/Demanda, com os devidos ajustes de NMS, será faturado após o levantamento dos requisitos dos serviços de desenvolvimento e implantação de sistemas e aplicativos mobile.

3.7.60. O equivalente a 60% da quantidade total de PF por OS/Demanda, com os devidos ajustes de NMS, será faturado após a entrega de todos artefatos requisitados, assim como o código-fonte, e homologado pela área demandante.

3.7.61. O equivalente a 20% da quantidade total de PF por OS/Demanda, com os devidos ajustes de NMS, será faturado após a implantação e ateste da solução em ambiente de produção.

3.7.62. E o equivalente aos 5% finais da remuneração dos serviços serão faturados logo após o encerramento do Projeto, conforme definições da metodologia de gerenciamento de projetos do CONTRATANTE.

3.7.63. Serviços de Manutenção Evolutiva e Manutenção Adaptativa: o equivalente a 100% da remuneração de todo o produto será faturado após a implantação e ateste dos entregáveis em ambiente de produção.

3.7.64. Serviços de Sustentação sob Demanda (sistemas, aplicativos ou portais): o serviço será 100% faturado na entrega completa do serviço de sustentação que foi executado.

3.7.65. A remuneração será calculada considerando a quantidade de PF a serem produzidos em cada OS ou demanda, o preço do Ponto de Função e o percentual a ser remunerado de acordo com a execução das fases\processos executados para cada tipo de demanda, conforme item 16.6.16.1.

Os serviços somente serão faturados após consenso das contagens detalhadas aferidas entre a CONTRATADA e o CONTRATANTE, conforme disposto no Item 3.11 desse Termo de Referência.

3.7.66. Os projetos de desenvolvimento ou chamados de manutenção evolutiva que forem formalmente cancelados antes da entrega em ambiente de qualidade ou homologação, serão remunerados em 15% do valor estimado na Ordem de Serviço ou Chamado, relativos ao planejamento e/ou execução parcial.

3.7.67. A estimativa inicial, que antecede a abertura da Ordem de Serviço ou execução de manutenção evolutiva sob demanda, será executada pela CONTRATADA sem qualquer ônus para a CONTRATANTE.

3.8. Requisitos dos Serviços do GRUPO 1 ITEM 2

3.8.1. ITEM 2 (PFS) – Prestação de serviços técnicos de sustentação dos sistemas e aplicativos mobile que estiverem no ambiente de produção. A métrica utilizada será o Ponto de Função Sustentado - PFS, que é baseada no tamanho funcional apurado para as soluções sustentadas.

3.8.2. Este item abrangerá os serviços de: manutenção corretiva, apuração especial, suporte ao usuário, apoio à produção e apoio técnico.

3.8.3. Segue abaixo a descrição de cada serviço:

3.8.4. Manutenção Corretiva: contempla análise e correção de falhas ou defeitos de sistemas em produção, abrangendo comportamentos inadequados que causem problemas de uso ou mau funcionamento do sistema e quaisquer desvios em relação aos requisitos aprovados pela área demandante da solução.

3.8.5. Apuração Especial: contempla os serviços de inclusão (carga de dados), alteração, consulta ou exclusão no banco de dados de produção, elaboração de relatórios, levantamento de informações complementares e não disponibilizados de forma automática via sistemas ou para possibilitar o correto funcionamento de uma funcionalidade.

3.8.6. Suporte ao Usuário: esclarecimento ou auxílio pontual na utilização correta dos sistemas, bem como a concessão de acesso e permissões para usuários utilizarem os sistemas.

3.8.7. Apoio à Produção: suporte para análise, diagnóstico e resolução de incidentes visando solução e proposta de melhoria, se couber, para tratamento das causas de problemas.

3.8.8. Apoio Técnico: suporte na implantação de processos e de ferramentas, participar de reuniões técnicas e de quaisquer iniciativas que visem a melhoria da sustentação de sistemas.

3.8.9. Os serviços técnicos de sustentação deverão ser prestados de acordo com as especificações, padrões técnicos de desempenho e qualidade estabelecidos pelo CONTRATANTE, podendo ser solicitados

3.8.10. mediante Ordens de Serviço ou software específico de gerenciamento de demandas/chamados. Serão realizados por meio de desembolso mensal (um valor fixo para a realização de sustentação de uma solução de software ou um conjunto delas) conforme a relação de sistemas e aplicativos mobile em produção dispostos no Catálogo de Sistemas e Aplicativos Sustentados versão 1.0, Encarte O deste Termo de Referência, limitados ao quantitativo máximo anual estimado para a sustentação, de acordo com os critérios estabelecidos no Edital e seus Anexos.

3.8.11. Será utilizado uma ferramenta definida pelo CONTRATANTE para abertura, acompanhamento e encerramento de chamados de sustentação, com prazos para atendimento especificados no Item 8.1.1.1 e seus respectivos subitens desse Termo de Referência.

3.8.12. O Catálogo de Sistemas e Aplicativos Sustentados não é restritivo, podendo ser atualizado com a remoção de sistemas e/ou aplicativos, ou a inclusão, considerando as especificações abaixo:

3.8.13. Para sistemas ou aplicativos desenvolvidos em contrato anterior a este Termo de Referência, que estejam fora do Catálogo de Sistemas e Aplicativos Sustentados, após análise do CONTRATANTE sobre a necessidade, serão incluídos no Catálogo no mês de referência subsequente após contado o prazo mínimo de 30 dias corridos após comunicação oficial de inclusão à CONTRATADA, para absorção do conhecimento.

3.8.14. Novos sistemas e aplicativos desenvolvidos pela CONTRATADA atual serão automaticamente incluídos no Catálogo de Sistemas e Aplicativos Sustentados, no

mês subsequente ao encerramento formal do projeto, a não ser que haja manifestação contrária da CONTRATANTE.

3.8.15. Novos sistemas ou aplicativos, assim como novas funcionalidades de sistemas ou aplicativos já existentes, que forem desenvolvidos pela CONTRATADA, estarão cobertos pela garantia descrita no Item 11.12.3, devendo a sustentação abranger serviços de manutenção corretiva, independente da inclusão ou não no Catálogo de Sistemas e Aplicativos Sustentados.

3.8.16. Todas as bases de dados utilizadas pelos sistemas sustentados estarão abarcadas pelos serviços de sustentação do Item 3.8.1 - ITEM 2 (PFS).

3.8.17. Artefatos

3.8.18. A CONTRATANTE irá solicitar a elaboração de artefatos de sustentação como complemento à entrega da solução (sistema ou aplicativo sustentado).

usuário ou outros artefatos da solução.

3.8.19.1. Serão solicitados como entregas deste item:

3.8.19. A documentação dos sistemas sustentados deverá ser atualizada conforme a descrição do serviço realizado, especificando, caso haja, alterações em histórias de

Modalidade	Artefato	Descrição	Periodicidade
Todas modalidades	Relatório de Atividades	Relatório com informações quantitativas das demandas atendidas durante o mês de referência, assim como informações gerais sobre cada chamado, análises temporais sobre o tempo que ficou em cada fila de atendimento, lições aprendidas e sugestões de melhoria.	Ao final do mês de referência
Manutenção Corretiva	Código-fonte atualizado - Scripts - Arquivos de configuração	correções e/ou scripts de banco de dados utilizados e/ou demais arquivos de configuração	Por chamado/demanda
Apuração Especial	- Scripts - Relatórios - Dados extraídos	Script utilizado para execução da transação no banco de dados e/ou relatórios no formato demandado e/ou arquivos com os dados extraídos	Por chamado/demanda
Suporte ao usuário	Relatório de atividades	Esse relatório deve conter o que foi realizado, e poderá ser feito por meio do sistema utilizado para gerenciamento das demandas.	Por chamado/demanda
Apoio à Produção	- Relatório Técnico	Esse relatório deve conter o que foi realizado, e poderá ser feito por meio do sistema utilizado para gerenciamento das demandas.	Por chamado/demanda

Tabela 06: Artefatos Sustentação de Sistemas

3.8.19.2. A execução e entrega dos artefatos serão flexibilizadas por meio de ferramenta específica escolhida a critério do CONTRATANTE.

3.8.19.3. Processo de Faturamento

3.8.19.4. Esses serviços serão realizados por meio de desembolso mensal (um valor fixo para a realização de sustentação de uma solução de software ou um conjunto delas) conforme a relação de sistemas e aplicativos mobile em produção dispostos no Catálogo de Sistemas e Aplicativos Sustentados versão 1.0, Encarte O deste Termo de Referência.

3.8.19.5. No modelo de mensuração do PFS é determinado um valor fixo mensal para a realização de sustentação de uma solução de software ou um conjunto delas para o mês de referência.

3.8.19.6. Os serviços são faturados de forma fixa mensal com base no tamanho funcional apurado para as soluções sustentadas constantes do Catálogo de Sistemas e Aplicativos Sustentados multiplicado pelo valor unitário do Ponto de Função Sustentado.

3.8.19.7. O CONTRATANTE, a qualquer momento, poderá solicitar recontagem do tamanho funcional de qualquer sistema sustentado. A recontagem deverá seguir a técnica de Análise de Pontos de Função conforme Item 6.11.

3.8.19.8. Caso seja verificado aumento ou redução do tamanho funcional do sistema, os volumes de PFS de faturamento serão reajustados para os meses subsequentes da validação. Para os meses já faturados não caberá novo faturamento ou ajustes de pagamentos.

3.8.19.9. Para calcular a quantidade de PFS necessária, é levantada a lista de sistemas ativos, em produção, que o órgão julgar necessário utilizar os serviços de sustentação em momento oportuno. Essa lista deu origem ao Catálogo de Sistemas e Aplicativos Sustentados versão 1.0, contendo a indicação do sistema e o respectivo tamanho funcional.

3.8.19.10. Serão faturados os chamados de sustentação atendidos no período de 1 (um) mês.

3.8.19.11. Os serviços de sustentação serão faturados após a respectiva aferição do Nível Mínimo de Serviço ao final do período de sustentação.

3.8.19.12. A remuneração será calculada conforme item 17.6.11.1.

3.9. Requisitos dos Serviços do GRUPO 1 ITEM 3

3.9.1. ITEM 3 (UST) – Prestação de serviços técnicos de desenvolvimento e manutenção evolutiva/melhorias de portais. Esses serviços serão dimensionados segundo a métrica Unidade de Serviço Técnico - UST, conforme disposto no Catálogo de Serviços para Desenvolvimento/Melhorias e Sustentação de Portais, Item 3, Encarte M deste Termo de Referência.

3.9.2. Detalhamento

3.9.3. Para efeitos deste documento, considera-se o termo "portal" para todo sistema que apresentar páginas web estáticas e/ou serem desenvolvidos por meio de Sistemas Gerenciadores de Conteúdo (CMS).

3.9.4. Este item abrangerá os serviços de desenvolvimento e manutenção evolutiva/melhorias de portais, ambos sob demanda.

3.9.5. Para os serviços do item 3.9.4, serão realizadas as etapas de Planejamento/Projeto de Desenvolvimento e Desenvolvimento e Implantação, as atividades passíveis de solicitação e execução para essas etapas estão descritas no Item 3, Tabela 1, do Catálogo de Serviços para Desenvolvimento/Melhorias e Sustentação de Portais (Encarte M deste Termo de Referência).

3.9.6. Esse Catálogo de Serviços possui quantidades pré-definidas de UST de acordo com critérios que definem a complexidade para cada atividade de solicitação. Os critérios que definem a complexidade para cada atividade estão descritos no Catálogo de Serviços para Desenvolvimento/Melhorias e Sustentação de Portais, Item 1, Tabela 1, Encarte M deste Termo de Referência.

3.9.7. Os serviços técnicos de desenvolvimento e manutenção evolutiva/melhorias de portais deverão ser prestados de acordo com as especificações, padrões técnicos de desempenho e qualidade estabelecidos pelo CONTRATANTE, solicitados mediante Ordens de Serviço e/ou software específico de gerenciamento de demandas. Serão realizados sob demanda, limitados ao quantitativo máximo estimado anual, sem garantia de consumo mínimo, de acordo com os critérios estabelecidos no Edital e seus Anexos.

3.9.8. A CONTRATADA deverá apresentar proposta de processo de desenvolvimento de portais, com práticas ágeis, a ser apreciada pela CONTRATANTE para avaliação e posterior aprovação do modelo sugerido, desde que esteja alinhada às regras de faturamento e níveis mínimos de serviço deste documento.

3.9.9. Artefatos

3.9.10. A CONTRATANTE irá solicitar a elaboração de artefatos como complemento a entrega do produto (Portal desenvolvido e/ou evoluído).

3.9.11. Além do código-fonte, a CONTRATADA deverá entregar os seguintes artefatos: relatório técnico de atividades, documento de visão, protótipo funcional e não-funcional, documento de interface e plano de implantação, ou outros artefatos conforme o processo adotado pelo CONTRATANTE.

3.9.12. A CONTRATADA deverá disponibilizar toda a documentação e softwares que compõem os portais produzidos, necessários para a sua instalação e utilização, por meio da entrega de manuais de instrução, customização e operação dos eventuais equipamentos e recursos relacionados aos produtos/entregáveis.

3.9.13. Processo de Faturamento

3.9.14. Para os serviços de desenvolvimento e manutenção evolutiva/melhorias de portais, o equivalente a 100% da remuneração de todo o produto será faturado após a implantação e ateste dos entregáveis do Portal em ambiente de produção.

3.9.15. A remuneração será calculada conforme a Unidade de Serviço Técnico (UST) disposta para cada serviço constante do Item 1, Tabela 3, do Catálogo de Serviços para Desenvolvimento/Melhorias e Sustentação de Portais multiplicado pelo valor unitário, estabelecido em contrato, da UST para o serviço, aferido o valor percentual do ajuste a ser praticado em razão dos resultados, com a aferição dos níveis mínimos de serviço, conforme a seguir:

Fórmula:

Remuneração OS = (Qnt UST x Preço UST) - Ajuste NMS

Onde:

Remuneração OS = valor, em reais, a ser pago pelos serviços executados em uma Ordem de Serviço do respectivo mês de referência.

Qnt UST = quantidade total de UST's conforme disposto no Item 1, Tabela 3 do Catálogo de Serviços.

Preço UST = valor unitário, estabelecido em contrato, da UST para o serviço. Ajuste NMS = valor percentual do ajuste a ser praticado em razão dos resultados, com a aferição dos níveis mínimos de serviço.

3.10. Requisitos dos Serviços do GRUPO 1 ITEM 4

3.10.1. ITEM 4 (USTS) – Prestação de serviços técnicos de sustentação de portais. Esses serviços serão dimensionados segundo a métrica Unidade de Serviço Técnico Sustentado (USTS), que é baseada na quantidade total de páginas estáticas para os portais sustentados.

3.10.2. Detalhamento

3.10.3. Este item abrangerá os serviços de: manutenção corretiva e adaptativa, suporte ao usuário e suporte na administração. Os itens passíveis de solicitação e execução que compõe os serviços de sustentação de portais estão dispostos no Catálogo de Serviços para Desenvolvimento/Melhorias e Sustentação de Portais, Item 1, Tabela 3, Encarte M deste Termo de Referência.

3.10.4. Segue abaixo a descrição de cada serviço:

3.10.5. Manutenção Corretiva e Adaptativa: contempla análise e correção de falhas ou defeitos de portais em produção, abrangendo comportamentos inadequados que causem problemas de uso ou mau funcionamento do portal e quaisquer desvios em relação aos requisitos aprovados pela área demandante da solução.

3.10.6. Suporte ao Usuário: esclarecimento ou auxílio pontual na utilização correta dos portais, bem como a concessão de acesso e permissões para usuários utilizarem os portais.

3.10.7. Suporte na administração: suporte para configuração, atualização e instalação de plugins nos sistemas gerenciadores de conteúdo, assim como apoio na administração do sistema gerenciador e alterações na identidade visual.

3.10.8. Os serviços técnicos de sustentação deverão ser prestados de acordo com as especificações, padrões técnicos de desempenho e qualidade estabelecidos pelo CONTRATANTE, podendo ser solicitados mediante Ordens de Serviço ou software específico de gerenciamento de demandas/chamados. Serão realizados por meio de

desembolso mensal, um valor fixo para a realização de sustentação dos portais baseando-se na quantidade total/média de páginas estáticas dos portais da CONTRATANTE, conforme a relação de portais em produção dispostos no Catálogo de Portais Sustentados versão 1.0 (Encarte C deste Termo de Referência), limitados ao quantitativo máximo anual estimado para a sustentação, de acordo com os critérios estabelecidos no Edital e seus Anexos.

3.10.9. Será utilizado uma ferramenta definida pelo CONTRATANTE para abertura, acompanhamento e encerramento de chamados de sustentação, com prazos para atendimento especificados no item 17.7 deste Termo de Referência.

3.10.10. O Catálogo de Portais Sustentados não é restritivo, podendo ser atualizado com a inclusão ou remoção de novos portais, conforme as especificações abaixo:

3.10.11. Para portais desenvolvidos em contrato anterior a este Termo de Referência, que estejam fora do Catálogo de Portais Sustentados, após análise do CONTRATANTE sobre a necessidade, serão incluídos no Catálogo no mês de referência subsequente após contado o prazo mínimo de 30 dias corridos após comunicação oficial de inclusão à CONTRATADA, para absorção do conhecimento.

3.10.12. Novos portais desenvolvidos pela CONTRATADA atual serão automaticamente incluídos no Catálogo de Portais Sustentados, no mês subsequente ao encerramento formal do projeto.

3.10.13. Novos portais, assim como novas funcionalidades de portais já existentes, que forem desenvolvidos pela CONTRATADA, estarão cobertos pela garantia descrita no Item 17.6.28.3, devendo a sustentação abranger serviços de manutenção corretiva, independente da inclusão ou não no Catálogo de Portais Sustentados.

3.10.14. Artefatos

3.10.15. A CONTRATANTE irá solicitar a elaboração de artefatos de sustentação como complemento à entrega da solução (portal sustentado).

3.10.16. A documentação dos portais sustentados deverá ser atualizada de acordo com cada modalidade.

3.10.17. Serão solicitados como entregas deste item:

Modalidade	Artefato	Descrição	Periodicidade
Todas modalidades	Relatório de Atividades	Relatório com informações quantitativas das demandas atendidas durante o mês de referência, assim como informações gerais sobre cada chamado, análises temporais sobre o tempo que ficou em cada fila de atendimento, lições aprendidas e sugestões de melhoria.	Ao final do mês de referência
Manutenção Corretiva e adaptativa	- Código-fonte atualizado - Scripts - Arquivos de configuração	Código-fonte com as atualizações decorrentes das correções e/ou scripts de banco de dados utilizados e/ou demais arquivos de configuração	Por chamado/demanda
Suporte ao usuário	Relatório de atividades	Esse relatório deve conter o que foi realizado, e poderá ser feito por meio do sistema utilizado para gerenciamento das demandas.	Por chamado/demanda
Suporte na administração	- Relatório Técnico	Esse relatório deve conter o que foi realizado, e poderá ser feito por meio do sistema utilizado para gerenciamento das demandas.	Por chamado/demanda

Tabela 07: Artefatos Sustentação de Portais

3.10.18. A execução e entrega dos artefatos serão flexibilizadas por meio de ferramenta específica escolhida a critério do CONTRATANTE.

3.10.19. Processo de Faturamento

3.10.20. Esses serviços serão realizados por meio de desembolso mensal (um valor fixo para a realização de sustentação de uma solução de portal ou um conjunto delas) conforme a relação de portais em produção dispostos no Catálogo de Portais Sustentados versão 1.0 (Anexo C deste Termo de Referência).

3.10.21. No modelo de mensuração do USTS é determinado um valor fixo mensal para a realização de sustentação de uma solução de portal ou um conjunto delas para o mês de referência.

3.10.22. Os serviços serão faturados de forma fixa mensal com base na quantidade/média de páginas de cada portal, apurada para os portais sustentados constantes do Catálogo de Portais Sustentados, e multiplicado pelo fator conforme abaixo:

3.10.23. Quantidade mensal de USTS = Quantidade Páginas * 8

3.10.24. O CONTRATANTE, a qualquer momento, poderá solicitar recontagem de páginas de qualquer portal sustentado.

3.10.25. Caso seja verificado aumento ou redução da quantidade de páginas, os volumes de USTS de faturamento serão reajustados para os meses subsequentes da validação. Para os meses já faturados não caberá novo faturamento ou ajustes de pagamentos.

3.10.26. Para calcular a quantidade de USTS necessária, é levantada a lista de portais ativos, em produção, que o órgão julgar necessário utilizar os serviços de sustentação em momento oportuno. Essa lista deu origem ao Catálogo de Portais Sustentados versão 1.0, contendo a indicação do portal e a respectivo quantidade de páginas.

3.10.27. Serão faturados os chamados de sustentação atendidos no período de 1 (um) mês.

3.10.28. Os serviços de sustentação serão faturados após a respectiva aferição do Nível Mínimo de Serviço ao final do período de sustentação.

3.10.29. A remuneração será calculada conforme a seguir: Fórmula:

Remuneração OS = (USTS x Preço USTS) - Ajuste NMS

Onde:

Remuneração OS = valor, em reais, a ser pago pelos serviços executados em uma Ordem de Serviço do respectivo mês de referência.

USTS (Unidade de Serviço Técnico Sustentado) = quantidade total de USTS conforme aplicação da fórmula disposta no item 3.10.22 e o quantitativo de páginas disposto no Catálogo de Portais Sustentados.

Preço USTS = valor unitário, estabelecido em contrato, da USTS para o serviço. Ajuste NMS = valor percentual do ajuste a ser praticado em razão dos resultados, com a aferição dos níveis mínimos de serviço.

3.11. Aferições e Contagem Detalhada

3.11.1. Os serviços somente serão faturados após consenso das Contagens Detalhadas aferidas entre a CONTRATADA e o CONTRATANTE.

3.11.2. As contagens serão dimensionadas segundo Análise de Pontos de Função com base no Manual de Práticas de Contagem de Pontos de Função - CPM-IFPUG (versão 4.3.1 ou superior ), e complementarmente o Roteiro de Métricas de Software do SISP (versão 2.2 ou superior) e Guia de Contagem de Pontos de Função do MP (versão 1 ou superior) ou Guia de Contagem de Pontos de Função definido pela CONTRATANTE.

3.11.3. Em caso de divergência ou ambiguidade entre os guias e roteiros citados no item 3.11.2, prevalecerão, preferencialmente, as regras citadas nos documentos dispostos conforme a ordem a seguir:

• Termo de Referência;

• Roteiro de Métricas de Software do SISP (versão 2.2 ou superior); e

• Manual de Práticas de Contagem de Pontos de Função - CPM-IFPUG (versão

4.3.1 ou superior).

3.11.4. A critério do CONTRATANTE, no que tange o Guia de Contagem de Pontos de Função do MP (versão 1 ou superior) poderá ser complementado por meio de uma

comunicação formal à CONTRATADA, desde que seja mantido o alinhamento com a métrica e com os guias e roteiros adotados pela CONTRATANTE.

3.11.5. O CONTRATANTE realizará a validação da contagem detalhada entregue pela CONTRATADA.

3.11.6. Em caso de aferições iguais entre CONTRATADA e CONTRATANTE, por obviedade, não será necessário a realização do consenso.

3.11.7. Havendo divergência superior à 5% (cinco por cento) entre as Contagens Detalhadas, o consenso se dará da seguinte forma:

3.11.8. A CONTRATADA, em até 03 (três) dias úteis após o envio da aferição realizada pela CONTRATANTE, deverá manifestar concordância ou discordância das aferições realizadas pelo CONTRATANTE.

3.11.9. Em caso de não manifestação por parte da CONTRATADA, será considerada CONCORDÂNCIA TÁCITA.

3.11.10. Em caso de manifestação de concordância por parte da CONTRATADA ou após a concordância tácita, a Contagem Detalhada será atualizada com base no valor aferido pela CONTRATANTE.

3.11.11. Em caso de manifestação de discordância, por parte da CONTRATADA, a mesma deverá encaminhar a exposição dos motivos ao CONTRATANTE que irá convocar uma Reunião de Xxxxxxxx, em no máximo 03 (três) dias úteis após a manifestação da discordância. Caso a divergência prevaleça, prevalecerá a contagem aferida pela CONTRATANTE.

3.11.12. Nas contagens cuja divergência seja inferior ou igual a 5% (cinco por cento) do total da Contagem Detalhada, prevalecerá a menor delas.

CAPÍTULO 4. DA CLASSIFICAÇÃO DOS SERVIÇOS E FORMA DE SELEÇÃO DO FORNECEDOR

4.1. Trata-se de serviço comum de caráter continuado SEM fornecimento de mão de obra em regime de dedicação exclusiva, a ser contratado mediante licitação, na modalidade pregão, em sua forma eletrônica.

4.2. Os serviços a serem contratados enquadram-se nos pressupostos do Decreto n° 9.507, de 21 de setembro de 2018, não se constituindo em quaisquer das atividades, previstas no art. 3º do aludido decreto, cuja execução indireta é vedada.

4.3. A prestação dos serviços não gera vínculo empregatício entre os empregados da Contratada e a Administração Contratante, vedando-se qualquer relação entre estes que caracterize pessoalidade e subordinação direta.

CAPÍTULO 5. REQUISITOS DA CONTRAÇÃO

5.1. O conjunto de características e especificações necessárias e suficientes para definir a solução de TIC a ser contratada (requisitos) foi elaborado de acordo com o ESTUDO TÉCNICO PRELIMINAR, considerando o disposto no art. 16 da IN-01/2019/SGD, conforme a seguir descritos.

5.1.1. Requisitos legais

5.1.1.1. A CONTRATADA deve observar o cumprimento de todas as leis e normas aplicáveis ao OBJETO, em especial atenção àquelas relacionadas ao pagamento das obrigações empresariais relacionadas à encargos fiscais, trabalhistas e previdenciários.

5.1.2. Requisitos de garantia e de manutenção

5.1.2.1. A CONTRATADA deverá prestar a GARANTIA TÉCNICA dos serviços entregues durante todo o período de vigência do CONTRATO (incluindo as eventuais prorrogações contratuais) e adicionalmente, durante 90 (noventa) dias após o encerramento do CONTRATO. O prazo será contado a partir do aceite definitivo do produto, o que engloba todos os seus entregáveis. O atendimento de demandas de GARANTIA TÉCNICA não é remunerável.

5.1.2.2. Por entregáveis entendem-se os produtos e artefatos entregues na execução dos serviços, não se restringindo as condições descritas neste Termo de Referência e quaisquer outros produtos entregues pela CONTRATADA necessários à instalação e execução dos softwares desenvolvidos no CAU/BR.

5.1.2.3. A identificação e a comunicação da Fábrica de Software dos sistemas desenvolvidos deverão ser efetuadas dentro do período de garantia, devendo a totalidade dos defeitos

reportados ser corrigida pela CONTRATADA, ainda que a conclusão do serviço extrapole o período da garantia.

5.1.2.4. Durante o período de GARANTIA TÉCNICA, caberá à CONTRATADA o apontamento de aferições originados de erros cometidos durante os serviços contratados ou decorrentes de integração às soluções desenvolvidas e ao ambiente computacional do CAU/BR, sem ônus adicional para o CONTRATANTE.

5.1.2.5. Para o caso de eventuais defeitos introduzidos pelos sistemas desenvolvidos previstas no item anterior, mesmo os apresentados em outras partes da solução de Fábrica de Software, serão aplicados os mesmos critérios quanto à garantia e à correção.

5.1.3. Requisitos de segurança da informação

5.1.3.1. Os serviços contratados deverão ser prestados em conformidade com leis, normas e diretrizes vigentes no âmbito da Administração Pública Federal relacionadas à Segurança da Informação e Comunicações (SIC); em especial atenção ao Decreto Federal n° 3.505, de 13 de junho de 2000, à Instrução Normativa GSI/PR n° 01, de 13 de junho de 2008 (e suas normas complementares) e à Política de Segurança da Informação e Comunicações do CONTRATANTE.

5.1.3.2. A CONTRATADA deverá credenciar junto ao CONTRATANTE seus profissionais que venham a ser designados para prestar serviços de forma presencial, bem como aqueles autorizados a retirar e/ou entregar documentos junto ao CONTRATANTE. Assim como deverá identificar qualquer equipamento de sua propriedade que venha a ser instalado nas dependências do CONTRATANTE, utilizando placas de controle patrimonial, selos de segurança, etc.

5.1.3.3. A CONTRATADA deverá comprometer-se, por si e por seus funcionários, em documento formal, a aceitar e aplicar rigorosamente todas as normas e procedimentos de segurança implementados no ambiente de Tecnologia da Informação do CONTRATANTE – inclusive com a assinatura de TERMO de responsabilidade e manutenção de sigilo.

5.1.3.4. A CONTRATADA deverá adotar critérios adequados para o processo seletivo de profissionais que irão atuar diretamente na execução do OBJETO, com o propósito de evitar a incorporação de perfis que possam comprometer a segurança ou credibilidade do CONTRATANTE.

5.1.3.5. A CONTRATADA deverá comunicar ao CONTRATANTE, com a antecedência mínima necessária, qualquer ocorrência de transferência, remanejamento ou demissão de funcionários envolvidos diretamente na execução do CONTRATO, para que seja providenciada a revogação de todos os privilégios de acesso aos sistemas, informações e recursos do CONTRATANTE porventura colocados à disposição para realização dos serviços contratados.

5.1.4. Requisitos de arquitetura tecnológica

5.1.4.1. O CONTRATANTE fornecerá à CONTRATADA:

a) Acesso físico às dependências relacionadas à prestação dos serviços;

b) Acesso lógico e os respectivos privilégios adequados nos sistemas, aplicações e ferramentas necessárias a perfeita execução dos serviços, exclusivamente para os profissionais diretamente envolvidos em sua execução;

c) Instalações, mobiliário e estações de trabalho necessárias à execução dos serviços, não sendo permitido à CONTRATADA alocar nas dependências do CONTRATANTE representantes que não atuem na execução do CONTRATO; e

d) Acesso às soluções de hardware e software de sua propriedade necessárias à execução das atividades contratadas, não desobrigando a CONTRATADA de fornecer eventuais soluções de software especificadas na contratação (quando for o caso).

5.1.4.2. À CONTRATADA caberá fornecer todos os demais recursos e condições técnicas necessárias à execução dos serviços, incluindo ferramentas específicas, materiais de apoio, materiais de identificação, equipamentos de proteção individual, etc. Com relação ao uso dos recursos de impressão do CONTRATANTE, a CONTRATADA somente efetuará as impressões estritamente associadas às atividades técnicas vinculadas aos serviços demandados pelo CONTRATANTE. Com relação ao uso de recursos de telefonia do CONTRATANTE a CONTRATADA deverá manter controle das ligações telefônicas (locais, nacionais, internacionais, celulares) realizadas pela sua equipe com finalidade de apoio e suporte à execução dos serviços contratados.

5.1.4.3. Com relação ao uso de recursos tecnológicos (hardware e/ou software) da CONTRATADA no ambiente do CONTRATANTE, a CONTRATADA deverá observar que, no caso da CONTRATADA optar por utilizar e ou instalar alguma solução tecnológica no ambiente para a prestação de serviços, fica obrigada a solicitar a autorização prévia à

implementação para que o CONTRATANTE decida a respeito da adequação e possa adotar todas as providências cabíveis à eventual implementação.

5.1.4.4. A solicitação por parte da CONTRATADA deverá incluir o projeto detalhado de implementação da solução, informando sua descrição, escopo de atuação, infraestrutura necessária, documentação de licenciamento e propriedade, benefícios e vantagens, os recursos profissionais e tecnológicos envolvidos, prazos e níveis de acesso necessários.

5.1.4.5. Toda solução tecnológica instalada nas dependências do CONTRATANTE, a pedido da CONTRATADA, será de livre acesso de consulta aos representantes indicados pelo CONTRATANTE que, ocasionalmente e quando aplicável, pode contemplar – além dos servidores da área de Tecnologia da Informação, equipe de fiscalização contratual e representantes de órgão internos/externos de controle.

5.1.4.6. Caberá à CONTRATADA toda providência junto ao fabricante/fornecedor e/ou detentor da propriedade intelectual da solução tecnológica quanto à ciência e/ou autorização (se aplicável) das condições de uso do produto nas dependências do CONTRATANTE, afastando qualquer interpretação de aquisição da solução tecnológica pelo CONTRATANTE e/ou uso não autorizado.

5.1.4.7. No caso de uma solução implementada pela CONTRATADA causar instabilidade/indisponibilidade do ambiente computacional, ficando comprovada culpa, esta poderá sofrer sanções administrativas e contratuais cabíveis, além de responder por eventuais prejuízos decorrentes. A CONTRATADA assume todos e quaisquer ônus financeiros referente às eventuais reclamações/processos judiciais de fabricantes/fornecedores da solução tecnológica licenciada para a CONTRATADA contra o uso destas nas dependências do CONTRATANTE.

5.1.5. Requisitos sociais, culturais e ambientais

5.1.5.1. No que couber, visando a atender ao disposto na legislação aplicável – em destaque às Instruções Normativas 05/2017/SEGES e 01/2019/SGD – a CONTRATADA deverá priorizar, para a execução dos serviços, a utilização de bens que sejam no todo ou em partes compostos por materiais recicláveis, atóxicos e biodegradáveis.

5.1.6. Requisitos de responsabilidade empresarial

5.1.6.1. Nos termos do Capítulo V (arts. 41 e 42) do Decreto n° 8.420, de 18 de março de 2015, é fortemente recomendável que a CONTRATADA desenvolva PROGRAMA DE INTEGRIDADE, que consiste num conjunto de “mecanismos e procedimentos internos de integridade, auditoria e incentivo à denúncia de irregularidades e na aplicação efetiva de códigos de ética e de conduta, políticas e diretrizes com objetivo de detectar e sanar desvios, fraudes, irregularidades e atos ilícitos praticados contra a administração pública, nacional ou estrangeira”.

CAPÍTULO 6. DA VISTORIA PARA LICITAÇÃO

6.1. Para o correto dimensionamento e elaboração de sua PROPOSTA, os LICITANTES deverão realizar VISTORIA TÉCNICA nas instalações do local de centralização dos serviços (conforme encarte I), acompanhado por servidor designado para esse fim. Quando autorizadas, as VISTORIAS TÉCNIAS poderão ser realizadas de segunda à sexta-feira, no horário entre 09:00 horas às 17:00 horas, com duração mínima estimada de 02 (duas) horas, devendo o agendamento ser efetuado previamente pelo telefone (61) XXX-XXXX/XXX ou através do e-mail XXX@XXX.xxx.xx.

6.1.1. Na VISTORIA TÉCNICA serão apresentadas aos LICITANTES as seguintes informações – cujo nível de sensibilidade ou detalhamento não permitem sua divulgação junto a esse TERMO DE REFERÊNCIA:

CAPÍTULO 7. MODELO DE EXECUÇÃO DO OBJETO

7.1. Metodologia de Trabalho

7.1.1. A execução de todo e qualquer serviço deverá ser precedida da solicitação formal do titular da unidade demandante ou pelo gestor do respectivo sistema de informação e da aprovação do Gestor do contrato, em conformidade com as deliberações e priorizações aprovadas pelo CG-CSC e previstas no Plano Diretor de Tecnologia da Informação vigente;

7.1.2. A empresa CONTRATADA deverá realizar vistoria prévia no local da prestação dos serviços, conforme item 7.2 deste Termo de Referência. Caso não ocorra a vistoria, o CAU/BR não aceitará, em nenhuma hipótese, reclamações ou alegações futuras de desconhecimento;

7.1.2. O processo de demanda deverá ocorrer em conformidade com o art. 33 da IN 01 2019/SLTI-MP.

7.2. Local da Prestação do Serviço

7.2.1.Todos os serviços contratados deverão considerar como sede do CAU/BR as instalações localizadas na cidade de Brasília/DF.

7.2.2.Os serviços serão executados nas dependências da empresa CONTRATADA, na cidade de Brasília/DF ou excepcionalmente, nos demais estados da federação, de acordo com a necessidade do CAU/BR e de comum acordo com a CONTRATADA.

7.2.3.A obrigatoriedade da CONTRATADA em manter a execução dos serviços na mesma cidade do CAU/BR está relacionada à utilização de metodologia de desenvolvimento baseado em práticas ágeis, que pressupõe a facilidade de comunicação entre o demandante e a equipe de desenvolvimento da CONTRATADA;

7.2.4.A critério do CAU/BR, e em caráter excepcional, alguns serviços e/ou atividades poderão ser executados fora das dependências do CAU/BR (sede de CAU/UF, parceiros, outras empresas contratadas, etc.).

7.2.5.Considerando a experiência com o atual contrato de fábrica de software, a equipe da CONTRATADA que for atuar em manutenções corretivas e de defeito devem, a critério do CONTRATANTE, executar os serviços nas dependências do CAU/BR;

7.2.6.A critério do CONTRATANTE poderá haver a alocação de times de desenvolvimento de projetos nas dependências do CAU/BR, mantidas as condições previstas no item 7.2.8.

7.2.7.Quando os serviços estiverem sendo realizados nas dependências do CAU/BR, os profissionais da empresa CONTRATADA sempre exercerão suas atribuições com acompanhamento e orientação do Preposto ou Líder Técnico, responsável pela realização dos serviços contratados;

7.2.8.Quando os serviços estiverem sendo realizados nas dependências do CAU/BR, esse fornecerá apenas espaço físico e acesso à rede lógica;

7.2.9.Independentemente do local de prestação de serviços, em nenhuma hipótese, haverá diferenciação no preço pago pelos serviços;

7.2.10. Na hipótese de alocação de recursos (pessoal, equipamentos, etc.) fora das dependências do CAU/BR, ainda que parciais, o CAU/BR deverá analisar e aprovar a estratégia de atendimento ofertada pela CONTRATADA, especialmente quanto à existência de adequada infraestrutura no local em que serão prestados os serviços, e verificará também outras condições;

7.2.11. Para viabilizar e apoiar a execução remota dos serviços contratados, quando for o caso, a CONTRATADA deverá prover e manter sem custo adicional ao CONTRATO um CANAL DE COMUNICAÇÃO DEDICADO, utilizando link seguro ponto-a-ponto, implementado com recursos de segurança (criptografado) e com velocidade de comunicação adequada e satisfatória para a prestação dos serviços. A velocidade do link de dados deverá ser compatível com a característica e o volume de dados trafegados em virtude da execução dos serviços. Assim como a CONTRATADA deve zelar pela disponibilidade desse acesso dedicado, provendo redundâncias, se for o caso, uma vez que a indisponibilidade do canal de acesso poderá impactar a disponibilidade, os níveis mínimos de serviço e, consequentemente, os resultados da CONTRATADA.

7.2.12. Mediante comunicação prévia, os serviços poderão ser realizados em local designado pelo CONTRATANTE, em qualquer das sedes dos CAU/UF. Nesses casos, os custos de deslocamento e hospedagem dos colaboradores da CONTRATADA serão ressarcidos pelo CONTRATANTE, nos moldes previstos na Resolução CAU/BR nº 47/2013 e suas alterações (disponível em xxxx://xxxxxxxxxxxxx.xxxxx.xxx.xx);

7.2.13. A critério do CAU/BR poderão participar das reuniões terceiros que, devido à necessidade do serviço, atuem em algumas etapas do desenvolvimento ou ainda dependam das reuniões como insumo para a execução dos seus trabalhos;

7.2.14. Não obstante ser a empresa CONTRATADA a única e exclusiva responsável pela execução dos serviços, o CAU/BR reserva-se o direito de, sem que de qualquer forma restrinja a plenitude dessa responsabilidade, exercer a mais ampla e completa fiscalização.

CAPÍTULO 8. MODELO DE GESTÃO DO CONTRATO E CRITÉRIOS DE MEDIÇÃO

8.1. Gestão Contratual

8.1.1. Para cumprir as atividades de gestão e fiscalização do CONTRATO o CONTRATANTE designará servidores (titulares e substitutos) para executar os seguintes papéis:

a) Gestor do Contrato: servidor com atribuições gerenciais, designado para coordenar e comandar o processo de gestão e fiscalização da execução contratual, indicado por autoridade competente;

b) Fiscal Técnico: servidor representante da Área de Tecnologia da Informação, indicado pela autoridade competente dessa área para fiscalizar tecnicamente o contrato;

c) Fiscal Requisitante: servidor representante da Área Requisitante da Solução, indicado pela autoridade competente dessa área para fiscalizar o contrato do ponto de vista funcional da Solução de Tecnologia da Informação; e

d) Fiscal Administrativo: servidor representante da Área Administrativa, indicado pela autoridade competente dessa área para fiscalizar o contrato quanto aos aspectos administrativos.

8.1.1.1. A gestão de todo o processo de execução dos serviços deverá ser realizada mediante Ordens de Serviços (OS) emitidas pelo CAU/BR à empresa CONTRATADA, utilizando a ferramenta de Gestão de Demandas de TI;

8.1.1.2. A ferramenta deverá ser disponibilizada pela empresa CONTRATADA, em conformidade com as orientações contidas na IN/SLTI nº. 01/2019 e na MGDS-CAU, sem custos extras para o CAU/BR;

8.1.1.3. A empresa CONTRATADA, a critério do CAU/BR e quando formalmente solicitado, deverá utilizar ferramenta de gestão da execução dos serviços e demandas própria do CONTRATANTE, ou especificamente contratada por ele para este fim.

8.1.1.4. A gestão do contrato far-se-á representar, durante a execução do contrato e será acompanhada e fiscalizada por representantes do CAU/BR (Gestor do contrato, Fiscal Técnico, Fiscal Requisitante e Fiscal Administrativo) especialmente designados que anotarão em registro próprio todas as ocorrências. Os papéis e responsabilidades seguem os procedimentos da MGDS do CAU. 9.2. Nos termos do art. 67 da Lei nº 8.666/93 e IN SLTI/MP nº 01/2019 os serviços de gestão, acompanhamento e fiscalização serão executados por servidores especialmente designados pela Presidência do CAU/BR, conforme os papéis e responsabilidades do Gestor, Fiscais Requisitante, Técnico e Administrativo, permitida a assistência de terceiros.

8.1.1.5. O contrato estabelecerá em suas cláusulas todas as condições, obrigações e responsabilidades entre as partes, em conformidade com o Termo de Referência e a Proposta de Preços da empresa CONTRATADA.

8.1.1.6. A presença da fiscalização do CAU/BR não elide nem diminui a responsabilidade da empresa CONTRATADA em relação ao disposto na Lei nº 8.666/93, assim como no fiel atendimento das cláusulas contratuais.

8.1.1.7. As decisões e providências que ultrapassarem a competência do Gestor e dos Fiscais serão solicitadas aos seus superiores em tempo hábil para a adoção das medidas convenientes.

8.2. Papéis e Responsabilidades

8.2.1. Gestor do Contrato Entidade: CAU/BR Responsabilidades:

a) Realizar reunião inicial com a participação dos Fiscais (Técnico, Requisitante e Administrativo), com preposto da empresa CONTRATADA e demais integrantes do corpo técnico indicados pelo CONTRATANTE;

b) Assinar todas as Ordens de Serviço, Termos de Recebimento Provisório e Termos de Recebimento Definitivo;

c) Monitorar a execução contratual;

d) Conduzir a transição contratual e o encerramento do contrato;

e) Encaminhar a indicação de aplicação de sanções;

f) Autorizar o pagamento de notas fiscais mediante solicitação encaminhada pelo preposto da empresa CONTRATADA;

g) Encaminhar à Área Administrativa eventuais pedidos de modificação contratual;

h) Acompanhar a manutenção do histórico de gerenciamento do contrato;

i) Autorizar o envio à Área Administrativa, com antecedência, mínima de 60 dias do término do contrato, solicitação de aditamento contratual, com base na documentação contida no histórico de gerenciamento do contrato e nos princípios da manutenção da necessidade, economicidade e oportunidade da contratação, explicitando os motivos para tal aditamento.

8.2.2. Fiscal Técnico

Entidade: Coordenadoria de TI (CORTI) Responsabilidades:

a) Assinar todas as Ordens de Serviço, Termos de Recebimento Provisório e Termos de Recebimento Definitivo;

b) Emitir o Termo de Recebimento Definitivo;

c) Autorizar em conjunto com o fiscal requisitante o faturamento dos serviços;

d) Conferir os indicadores de nível de desempenho e a aplicação das glosas;

e) Identificar a não conformidade com os termos contratuais e indicar ao Gestor a aplicação de sanções e penalidades;

f) Verificar manutenção das condições de habilitação da CONTRATADA;

g) Manter o histórico de gerenciamento do contrato, contendo registros formais de todas as ocorrências positivas e negativas da execução do contrato, por ordem cronológica e histórica;

h) Solicitar à Área Administrativa, com antecedência mínima de 60 dias do término do contrato, aditamento contratual, com base na documentação contida no histórico de gerenciamento do contrato e nos princípios da manutenção da necessidade, economicidade e oportunidade da contratação, explicitando os motivos para tal aditamento.

8.2.3. Fiscal Requisitante

Entidade: Coordenadoria do SICCAU (CORSICCAU) Responsabilidades:

a) Assinar todas as Ordens de Serviço e Termos de Recebimento Provisório;

b) Validar o escopo da OS;

c) Solicitar para a fábrica de métricas a contagem estimada e detalhada da OS;

d) Xxxxx nas reuniões de consenso com a CONTRATADA;

e) Emitir as Ordens de Serviço e o Termo de Recebimento Provisório;

f) Calcular os indicadores de nível de desempenho dos serviços e glosas;

g) Indicar os colaboradores de sua coordenadoria que atuarão como donos do produto (product owners);

h) Avaliar em conjunto com o dono do produto a qualidade dos serviços entregues, as conformidades e as justificativas de acordo com os critérios de aceitação;

i) Autorizar em conjunto com o fiscal técnico o faturamento dos serviços;

j) Identificar a não conformidade com os termos contratuais e indicar ao Fiscal Técnico a aplicação de sanções e penalidades;

k) Verificar a manutenção da necessidade, economicidade e oportunidade da contratação.

8.2.4. Dono do Produto (product owner)

Entidade: Coordenadoria do SICCAU (CORSICCAU) Responsabilidades:

a) Elaborar o escopo da OS a partir das informações da área requisitante;

b) Analisar o roadmap, o backlog e, se necessário, a contagem de pontos de função apresentada pela CONTRATADA;

c) Atuar nas reuniões de consenso com a CONTRATADA;

d) Analisar o mapeamento de riscos, se necessário;

e) Aprovar ou rejeitar os artefatos ou produtos entregues pela CONTRATADA;

f) Retirar os impedimentos registrados pela CONTRATADA;

g) Registrar na ferramenta de gestão de demandas os erros e refinamentos necessários;

h) Realizar o 1° e 2° ciclos de homologação;

i) Identificar a não conformidade com a execução da OS e indicar ao Fiscal Requisitante a aplicação de sanções e penalidades.

8.2.5. Responsável da Área Requisitante Entidade: Unidades do CAU/BR e CAU/UF Responsabilidades:

a) Descrever suas necessidades e demais informações para a elaboração do escopo;

b) Aprovar o escopo da OS;

c) Autorizar a abertura da OS;

d) Informar as regras de negócio referentes à sua OS;

e) Aprovar ou rejeitar em conjunto com o dono do produto os artefatos ou produtos entregues pela CONTRATADA;

f) Assinar as Ordens de Serviço e Termos de Recebimento Provisórios da sua unidade.

8.2.6. Fiscal Administrativo Entidade: CAU/BR Responsabilidades:

a) Verificar aderência aos termos contratuais;

b) Verificar manutenção das condições classificatórias e de habilitação;

c) Verificar as regularidades fiscais, trabalhistas e previdenciárias para fins de pagamento.

8.2.7. Preposto

Entidade: Empresa CONTRATADA Responsabilidades:

a) Acompanhar a execução do contrato;

b) Xxxxx como interlocutor principal junto o CAU/BR;

c) Receber, diligenciar, encaminhar e responder as principais questões técnicas, legais e administrativas referentes ao andamento contratual.

8.3. Execução e Acompanhamento dos Serviços

8.3.1.Para cada OS criada, a CONTRATADA deverá gerar os artefatos previstos, de acordo com o respectivo cronograma e dentro dos padrões de qualidade e de compatibilidade técnica, conforme as definições especificadas na Ordem de Serviço, na MGDS-CAU, neste Termo de Referência e demais anexos.

8.3.2.Caso não tenha sido iniciada nenhuma atividade para uma determinada OS, esta poderá ser cancelada com a devida justificativa.

8.3.3.Os prazos para execução dos serviços deverão ser definidos considerando-se como limites máximos aqueles definidos na tabela de Níveis de Serviço (item 17.6 deste Termo de Referência), sendo formalizados nas respectivas OS. O atraso no cumprimento dos prazos estabelecidos resultará na aplicação das penalidades previstas neste Termo de Referência e no contrato. Caso necessário e a critério do Gestor do contrato, esse prazo poderá ser motivadamente estendido para garantir a boa execução dos serviços.

8.3.4.O indicador utilizado para a gestão dos prazos de execução das OS será: Indicador de Demandas entregues dentro do Prazo – IDP.

8.3.5.A empresa CONTRATADA deverá prover o CAU/BR de informação detalhada da execução dos serviços, por meio de ferramenta de Gestão de Demandas de TI (OS), em tempo real, com acesso protegido por senha e nível de acesso previamente definido. A ferramenta deverá ficar disponível 24 horas por dia, durante 7 dias por semana, ininterruptamente.

8.3.6.Em casos de execução dos serviços de forma emergencial, os horários da execução serão definidos em documento próprio estabelecido pelo CAU/BR, e consignados no âmbito da documentação da Ordem de Serviço respectiva.

8.3.7.A empresa CONTRATADA para execução do objeto fica responsável pela manutenção do software de Gestão de Demandas de TI em funcionamento, sem erros, durante toda a vigência do contrato.

8.3.8.Em caso de solicitação pelo CAU/BR, a empresa CONTRATADA se obriga, ainda, a disponibilizar anualmente novas consultas e/ou relatórios na ferramenta de acompanhamento dos serviços, equivalentes ao máximo de 50 PF (cinquenta pontos de função) anuais, sem custo adicional.

8.3.9.Sempre que solicitado pelo CAU/BR e obrigatoriamente ao término da vigência do contrato, a empresa CONTRATADA transferirá a base de dados histórica de todos os serviços, juntamente com o modelo e dicionário de dados do software, em mídia digital, formato de arquivo texto ou outro previamente acordado entre as partes.

8.3.10. Os dados constantes em todas as ferramentas de acompanhamento de demandas fornecidas pela CONTRATADA são de propriedade do CAU/BR e devem ser fornecidos de forma estruturada e passiva de consulta ao CAU/BR durante todo o período de vigência do contrato e até 6 meses após seu fim.

8.3.11. A Ferramenta de Gestão de Demandas de TI é requisito necessário à Gestão de Demandas (OS) da Fábrica de Software e deverá ser fornecida pela CONTRATADA sem custos adicionais para o CAU/BR.

8.3.12. O acesso à ferramenta deverá ser disponibilizado em até 30 dias corridos após a assinatura do contrato, preferencialmente em software livre. Pode ser customizável, selecionada em comum acordo com o CAU/BR, com interface totalmente WEB e prover relatórios de ocorrências, atendimentos e níveis de serviço com várias perspectivas.

8.3.13. O sistema deverá fornecer informação detalhada do andamento da execução dos serviços demandados e, abertura, acompanhamento de fases, quando necessário, e fechamento dos chamados.

8.3.14. Para as fases de Teste e Homologação, poderão ser registradas no sistema, as não conformidades evidenciadas, bem como anexar artefatos, controlar estado, realizando fluxo de aprovação.

8.3.15. As funcionalidades requeridas poderão, a critério da CONTRATADA, ser atendidas por sistemas distintos, desde que contenham todos os requisitos exigidos neste Termo de Referência e possam ser integrados para acesso em um mesmo ambiente.

8.3.16. O sistema deverá possuir acesso protegido às informações por senha e conexão segura, ou outro método equivalente.

8.3.17. A ferramenta de gestão deve permitir diferentes níveis de acesso para os usuários do CAU/BR e da CONTRATADA, e enviar e-mails com notificações de acordo com ações específicas e para o público definido.

8.3.18. A ferramenta deve permitir o cadastro do horário de trabalho e do calendário com os dias úteis para o cálculo de tempo de execução;

8.3.19. O Sistema de gestão de demandas será submetido à avaliação da Gerência de Serviços Compartilhados do CAU/BR, que poderá, a qualquer tempo, solicitar ajustes e/ou modificações de forma a adequá-lo às suas necessidades, possuindo, no mínimo, as informações e funcionalidades relacionadas a seguir:

8.3.20. Abertura de OS pelo CAU/BR, selecionando o tipo da demanda conforme previsto neste TR e na MGDS-CAU;

8.3.21. No caso de defeito, ou seja, manutenção corretiva em garantia, também será aberta uma OS, porém não haverá pagamento pela demanda;

8.3.22. Identificação da criticidade quando se tratar de manutenção corretiva ou defeito;

8.3.23. Cálculo do prazo máximo de início e de atendimento de acordo com o tipo de demanda, nível de criticidade (quando se tratar de manutenção corretiva ou defeito) e quantidade de pontos de função ou de horas (quando aplicável);

8.3.24. Permitir gerar o arquivo no formato PDF da OS conforme modelo presente no Encarte C desse Termo de Referência;

8.3.25. Identificação do projeto e/ou sistema(s) envolvidos mediante cadastro prévio de sistemas/aplicações existentes no CAU/BR;

8.3.26. Possibilidade de anexar arquivos à demanda (OS);

8.3.27. Registro da situação do atendimento (workflow) e percentual de realização dos serviços (conforme evolução/status da demanda – real time), e em conformidade com a MGDS do CAU;

8.3.28. No caso de demanda de defeito deve ser informada a ordem de serviço que apresentou o defeito;

8.3.29. Permitir, quando aplicável, registro pela FSW do cronograma de execução, bem como aprovação ou recusa pelo CAU/BR;

8.3.30. Registro de impedimento de execução pela FSW;

8.3.31. Registro de retirada de impedimento pelo CAU/BR;

8.3.32. Registro da conclusão a entrega pela FSW;

8.3.33. Permitir o informe, bem como a anexação dos documentos ou artefatos gerados no decorrer da execução do serviço pela FSW;

8.3.34. Registro de aceite ou recusa do artefato ou produto intermediário pelo CAU/BR;

8.3.35. Registro do 1°ciclo e 2° ciclo de homologação pelo CAU/BR;

8.3.36. Registro pelo CAU/BR da quantidade de erros encontrados na entrega;

8.3.37. Registro pelo CAU/BR da quantidade de melhorias ou aperfeiçoamentos encontrados na entrega;

8.3.38. Registro da quantidade de Pontos de Função (PF) estimada e detalhada calculada pela FSW;

8.3.39. Registro da quantidade de PF estimada e detalhada calculada pela Fábrica de Métricas e informada pelo CAU/BR;

8.3.40. Cálculo da quantidade de dias úteis de execução com a FSW, descontando os tempos de impedimentos ou de homologação com o CAU/BR, porém considerando que as recusas registradas pelo CAU/BR retomam a contagem do tempo de execução da FSW;

8.3.41. Registro pelo CAU/BR da publicação nos ambientes de homologação e produção;

8.3.42. Encerramento da demanda após o aceite do CAU/BR e cálculo do período de garantia após a publicação em ambiente de produção;

8.3.43. Registros de problemas e comentários;

8.3.44. Emissão em arquivo PDF e registro da emissão dos Termos de Recebimento Provisório (TRP) conforme modelo no ENCARTE D desse TR;

8.3.45. Emissão em arquivo PDF e registro da emissão do Termo de Recebimento Definitivo (TRD) conforme modelo do ENCARTE E desse TR;

8.3.46. Autorização pelo CAU/BR de faturamento parcial ou integral;

8.3.47. Indicação pela FSW da nota fiscal, data de emissão e valor faturado da OS;

8.3.48. Armazenamento histórico de todas as informações, assim como uma referência às versões de todos os documentos utilizados;

8.3.49. Relatório com o cronograma de todas as OS, contendo:

8.3.50. Datas de início e fim de cada tarefa/atividade - prevista e realizada na execução do serviço;

8.3.51. Xxxxxx exigidos para as entregas – data e descrição dos entregáveis;

8.3.52. Identificação de atividades pendentes;

8.3.53. Andamento do serviço ou projeto e de suas tarefas/atividades.

8.3.54. Registro da data de emissão do TRP, do TRD e dos valores faturados.

8.3.55. Relatório de controle do contrato com exibição do saldo de pontos de função e valor;

8.3.56. Gráfico de acompanhamento de OS por tipo e status;

8.3.57. Localização de OS através de busca textual e filtros;

8.3.58. Emissão de relatórios com múltiplos critérios de seleção (filtros).

8.4. Entrega, Avaliação e Recebimento

8.4.1. A entrega do objeto previsto na OS deverá ser realizado pela empresa CONTRATADA dentro do prazo máximo previsto na tabela de Níveis de Serviço – item 17.6 deste Termo de Referência;

7.O recebimento dos serviços será realizado conforme estipulado no art. 73 da Lei nº 8.666/93, e de acordo com os itens a seguir:

8.4.2.O Termo de Recebimento Provisório (TRP) é o instrumento utilizado para atestar as entregas parciais ou totais do objeto da OS;

8.4.3.O Termo de Recebimento Definitivo (TRD) é o instrumento final de ateste do serviço contratado na OS, emitido quando todas as entregas previstas na OS forem recebidas e validadas pelo CAU/BR;

8.4.4.A empresa CONTRATADA poderá apresentar justificativa formal sobre eventuais atrasos ou paralisação dos serviços. Serão aplicáveis sanções quando as justificativas não forem apresentadas ou quando julgadas improcedentes;

8.4.5.Utilizando a ferramenta de gestão de demandas, o colaborador do CSC responsável pela demanda recebe ou rejeita as entregas parciais ou totais do objeto da OS;

8.4.6.Caso a entrega tenha sido aceita, o Fiscal Requisitante, utilizando a mesma ferramenta, emitirá o Termo de Recebimento Provisório (TRP), conforme modelo no Encarte D desse Termo de Referência, classificando como “Recebido”;

8.4.7.Caso a entrega seja rejeitada, a demanda volta para a CONTRATADA e a contagem do tempo de execução é retomada;

8.4.8.A partir da data de entrega dos serviços e/ou artefatos previstos na OS, o CAU/BR terá até 15 dias úteis para emitir o Termo de Recebimento Provisório (TRP) da OS;

8.4.9.A aceitação da entrega indica que o objeto da OS, parcial ou total, foi entregue com todos os requisitos, artefatos e critérios previstos na OS, bem como o atendimento à Metodologia de Gestão em Desenvolvimento de Software do CAU/BR (MGDS-CAU), versão

3.0 ou superior;

8.4.10. A rejeição da entrega indica que o objeto da OS, parcial ou total, foi entregue com pendência(s) ou qualidade dos produtos entregues aquém da aceitável;

8.4.11. O TRD da etapa de desenvolvimento “Implantação” conterá os indicadores IDP (indicador de demanda entregue dentro do prazo) e PD (índice de pontos com defeito) apurados e as glosas caso seja apurado descumprimento dos níveis mínimos de serviço;

8.4.12. O Fiscal Requisitante após a vistoria que comprove a adequação do objeto aos termos contratuais, emitirá na ferramenta de gestão de demandas o Termo de Recebimento Definitivo (TRD) (Encarte E), que consistirá em uma declaração formal de que o objeto total da OS foi aceito;

8.4.13. O Termo de Recebimento Definitivo (TRD) (Encarte E) referente ao objeto da OS só será emitido se todas as entregas (Termo de Recebimento Provisório) tiverem sua classificação como “Recebido”;

8.4.14. Após a emissão do Termo de Recebimento Provisório (TRP) e classificação de todo o objeto da OS como “Recebido”, o CAU/BR terá um prazo máximo de 05 (cinco) dias úteis, quando o prazo para a execução do serviço for de até 20 (vinte) dias úteis (inclusive), para emitir o Termo de Recebimento Definitivo (TRD). Quando o prazo de execução do serviço for maior que 20 (vinte) dias úteis, o prazo para emissão do Termo de Recebimento Definitivo (TRD) será de 25% (vinte e cinco por cento) do tempo de execução do serviço (em dias úteis), limitados a 90 (dias);

8.4.15. A emissão do TRP autoriza o pagamento do percentual de esforço da etapa de desenvolvimento recebida pelo CAU/BR, conforme detalhado na MGDS-CAU e considerando as premissas estabelecidas no Roteiro de Métricas de Software do Sistema de Administração dos Recursos de Tecnologia da Informação - SISP;

8.4.16. A emissão do TRD registra o atendimento integral da OS, conforme especificado.

8.5. Forma de Execução / Fornecimento

8.5.1.A empresa CONTRATADA será responsável pela execução dos serviços e seu acompanhamento diário no tocante a qualidade e níveis de serviço alcançados com vistas a efetuar eventuais ajustes e correções.

CAPÍTULO 9. MATERIAIS A SEREM DISPONIBILIZADOS

9.1. Para a perfeita execução dos serviços, a CONTRATADA deverá disponibilizar os materiais, equipamentos, ferramentas e utensílios necessários, nas quantidades estimadas e qualidades a seguir estabelecidas, promovendo sua substituição quando necessário:

a) Para viabilizar e apoiar a execução remota dos serviços contratados, quando for o caso, a CONTRATADA deverá aumentar o link DEDICADO, mantendo a segurança ponto-a-ponto, implementado com recursos de segurança (criptografado) e com velocidade de comunicação adequada e satisfatória para a prestação dos serviços. A velocidade do link de dados deverá ser compatível com a característica e o volume de dados trafegados em virtude da execução dos serviços. Assim como a CONTRATADA deve zelar pela disponibilidade desse acesso dedicado, provendo redundâncias, se for o caso, uma vez que a indisponibilidade do canal de acesso poderá impactar a disponibilidade, os níveis mínimos de serviço e, consequentemente, os resultados da CONTRATADA; e

b) Ferramenta de controle das demandas de Fábrica de Software.

CAPÍTULO 10. INFORMAÇÕES RELEVANTES PARA O DIMENSIONAMENTO DA PROPOSTA

10.1. A demanda do órgão tem como base as seguintes características:

GRUPO	ITEM	DESCRIÇÃO DO ITEM	UNIDADE	QUANTIDADE ESTIMADO
1	1	Serviços técnicos de desenvolvimento de sistemas e aplicativos mobile	PF (Ponto de Função)	14.000
	2	Serviços técnicos de sustentação de sistemas e aplicativos mobile	PFS (Ponto de Função Sustentado)	7.000
	3	Serviços técnicos de desenvolvimento portais, transferência de Conhecimento e Consultoria em TI	UST (Unidade de Serviço Técnico)	7.000
	4	Serviços técnicos de sustentação de portais	USTS (Unidade de Serviço Técnico Sustentável)	3.500

Tabela 08: Quantitativo Estimado

CAPÍTULO 11. DA ESPECIFICAÇÃO TÉCNICA

11.1. Os requisitos relativos a cada demanda de sistema de informação serão discutidos e determinados no momento de sua solicitação, por meio de Ordem de Serviço (OS) específica, conforme a MGDS-CAU e modelo no Encarte C deste TR obedecidas, ainda, as demais disposições deste Termo de Referência.

11.2. De acordo com as características de cada demanda, poderá, excepcionalmente, haver exceções nos requisitos e recomendações listadas neste Termo de Referência, mantidos os objetos e condições do contrato. Nesses casos, essas exceções serão discutidas e determinadas quando da efetivação da demanda, por meio de Ordem de Serviço (OS) específica.

11.3. Requisitos Internos

11.3.1. A Metodologia de Gestão em Desenvolvimento de Software do Conselho de Arquitetura e Urbanismo (MGDS-CAU) foi desenvolvida no intuito de nortear o processo de comunicação com a empresa CONTRATADA e os requisitantes (CAU/BR e CAU/UFs), bem com indicar os artefatos e produtos que podem ser solicitados por demanda;

11.3.2. A MGDS-CAU prevê todos os artefatos ou produtos possíveis de serem solicitados por tipo de demanda. Os artefatos e produtos obrigatórios sempre deverão ser entregues. Os artefatos e produtos opcionais poderão ser solicitados a qualquer tempo, dependendo da necessidade do CAU;

11.3.3. À GESC, reserva-se ao direito de revisar, sempre que julgar necessário, sua MGDS, podendo esse processo de revisão incluir e/ou excluir documentos específicos. Para esses casos:

11.3.3.1. Os documentos já entregues até a data de publicação da revisão da MGDS-CAU manterão o padrão da solicitação da demanda;

11.3.3.2. Os documentos ainda não entregues na data de publicação da revisão da MGDS- CAU adotarão o padrão indicado pela GESC;

11.3.4. A Política de Segurança da Informação do CAU/BR e seu Regulamento Interno de Segurança da Informação deverão ser cumpridos pela empresa CONTRATADA e estão disponíveis no endereço eletrônico xxx.xxxxx.xxx.xx/xx- content/uploads/2012/07/portarianormativa49.pdf;

11.3.5. As funcionalidades desenvolvidas deverão oferecer a usabilidade e acessibilidade necessárias para garantir seu uso por usuários com diversos níveis de familiaridade com o computador, em especial por aqueles de baixo grau de instrução. Todas as mensagens e textos digitais devem estar em língua portuguesa, de forma clara e objetiva;

11.3.6. Nas ações relativas à manutenção e evolução dos sistemas deverão ser considerados pela CONTRATADA critérios de usabilidade, padrões de navegação, facilidade de codificação,

facilidade de manutenção, robustez, segurança, facilidade de aprendizado, reusabilidade e portabilidade na escolha das soluções a serem implantadas.

11.4. Requisitos Externos

11.4.1. Para a elaboração de qualquer demanda de software (Projeto, Manutenção e/ou Serviço), a CONTRATADA deverá cumprir os seguintes requisitos pertinentes aos padrões da Estratégia de Governança Digital, disponível no site xxxx://xxx.xxxxxxxxxxxxxxxxx.xxx.xx:

11.4.1.1. Atender aos requisitos e recomendações de padronização dos Padrões Web em Governo Eletrônico (e-PWG) descritos nas últimas versões dos guias: “Cartilha de Codificação”, “Cartilha de Redação Web” e “Cartilha de Usabilidade”;

11.4.1.2. Atender aos requisitos e recomendações de padronização descritos na última versão do Modelo de Acessibilidade em Governo Eletrônico (e-MAG);

11.4.1.3. Atender às recomendações de padronização descritas na última versão disponível do guia e-ARQ - Modelo de Requisitos para Sistemas Informatizados de Gestão Arquivística de Documentos;

11.4.1.4. Atender à integração com outros sistemas e interoperação entre sistemas, mesmo que externos ao CAU, e deverão ser realizados, sempre que tecnicamente viável, por intermédio de WebService, seguindo os padrões estabelecidos pela última versão do guia e- Ping – Padrões de Interoperabilidade de Governo Eletrônico; conforme as Portarias Normativas SLTI/MP nº 5, de 14 de julho de 2005, e nº 3, de 07 de maio de 2007;

11.4.1.5. Aderir às regulamentações da Infraestrutura de Chaves Públicas Brasileira - ICP- Brasil, conforme a Medida Provisória nº 2.200-2, de 24 de agosto de 2001, quando houver necessidade de utilização de certificação digital.

11.5. Requisitos da Solução

11.5.1. Os serviços constantes do objeto deverão ser executados por profissionais com conhecimento técnico necessário para empreender a migração de sistemas legados e processo de desenvolvimento das soluções (projeto, sustentação e/ou serviço) e exigirão conhecimento em engenharia de software, gerenciamento de projeto de software com práticas ágeis, em consonância com aqueles definidos pela Gerência de Serviços Compartilhados (GESC) deste órgão

11.5.2. Os serviços deverão prever a utilização dos ambientes (infraestrutura) de desenvolvimento, teste, homologação e produção.

11.5.3. Os ambientes atualmente estão distribuídos da seguinte forma:

11.5.3.1. Ambiente de desenvolvimento – Disposto na CONTRATADA;

11.5.3.2. Ambiente de teste e ambiente de homologação – Dispostos no CONTRATANTE;

11.5.3.3. Ambiente de Produção – Disposto em Datacenter na nuvem.

11.5.4. A empresa CONTRATADA deverá considerar a possibilidade de, em casos específicos, utilizar componentes que tratem de informações georreferenciadas.

11.5.5. Os serviços poderão ser prestados tanto no ambiente da CONTRATADA quanto nas dependências do CONTRATANTE, variando a condição de acordo com os requisitos especificados. Em regra, visando evitar o deslocamento de servidores do CAU/BR, os serviços que demandem interação direta e contínua entre a equipe da CONTRATADA e o CONTRATANTE deverão ser executados presencialmente, no ambiente do Conselho de Arquitetura e Urbanismo do Brasil.

11.6. Arquitetura Técnica Atual

11.6.1. Esta arquitetura poderá, a critério do CAU/BR, ser atualizada e/ou expandida a qualquer tempo:

11.6.1.1. BD:

a) PostgreSQ;

b) PostGIS;

c) MySQL.

11.6.1.2. Plataformas de Linguagens:

a) PHP;

b) Java/WEB;

c) PL/PGSQL;

d) Java/Web Service/XML.

11.6.1.3. Sistema Operacional:

a) LINUX;

b) Windows Server.

11.6.1.4. Serviço de Diretório

a) AD (Active Directory) da Microsoft;

b) Samba – LDAP.

11.6.1.5. Serviço de Aplicação

a) Apache 2 (ou superior);

b) Xxxxxx 0 (ou superior);

c) JBoss Seam.

11.6.1.6. Ferramentas:

11.6.2. No intuito de automatizar o processo de comunicação, a contratada deverá fornecer uma aplicação própria, que permita o acompanhamento e controle de todo o ciclo de desenvolvimento de software definido pelo CAU/BR, devendo possuir as seguintes características:

11.6.3. Abertura de Ordem de Serviços, por meio de formulário web, devendo possibilitar o acompanhamento por meio de histórico das ações;

11.6.4. As Ordens de Serviço deverão conter todas as informações necessárias ao gerenciamento do projeto, como o tempo de início, estimativa nas métricas estabelecidas e prazos, nome das pessoas envolvidas e cronograma do projeto associando as responsabilidades;

11.6.5. Permitir o controle de saldo, tanto de PF, PFS, UST e USTS quanto das notas de empenho vinculadas ao contrato;

11.6.6. Permitir a geração de relatórios de execução contratual, contendo minimamente: valor em execução, valor executado, valor disponível;

11.6.7. Permitir a geração do Relatório de Ordens de Serviço Homologadas por período;

11.6.8. Permitir monitorar os projetos por meio de acesso seguro via WEB;

11.6.9. Permitir a rastreabilidade de artefatos produzidos de acordo com os entregáveis no catálogo de serviços, com registros e rastreamento on-line, com a interface integrada à ferramenta utilizada como repositório (Ex. Git, SVN, dentre outras similares);

11.6.10. 5 Permitir a gestão de demandas, planejamento de projeto e acompanhamento de atividades;

11.6.11. Permitir o acompanhamento de defeitos (“bugs”);

11.6.12. Apresentar painéis de Indicadores (“dashboards”) executivos;

11.6.13. Armazenar as documentações dos projetos, código fonte e histórico de builds em um mesmo repositório;

11.6.14. Indicadores de progresso do ciclo de desenvolvimento dos produtos através de Portal Web;

11.6.15. Possibilidade de criar novos relatórios / dashboards, utilizando recursos da própria

11.6.16. ferramenta, sem a necessidade de adicionar componentes para esta finalidade;

11.6.17. Possibilidade de usar planilhas eletrônicas como ferramenta de extração de relatórios gerenciais a partir das métricas coletadas pela ferramenta;

11.6.18. Permitir o controle de backlogs dos sistemas, releases, sprints, fluxo do Kanban; e

7.6.20 A provedora deverá apresentar sistema próprio para a execução de todos os itens citados acima.

11.7. Ambiente Tecnológico Atual

11.7.1. O ambiente de infraestrutura atual é composto de servidores corporativos com sistemas operacionais predominantemente na plataforma SO Linux;

11.7.2. Com relação aos serviços, o CAU detém softwares que compõem o “Pacote Microsoft Office”, dentre os quais se destacam: Microsoft Windows Server e Microsoft Exchange em nuvem;

11.7.3. Sob o aspecto do ambiente das estações de trabalho, utiliza-se o sistema operacional Microsoft Windows 7, 8 e 10 e como “suíte de escritório” o pacote e MS Office.

11.8. Continuidade dos Serviços / Transição Contratual

11.8.1. No intuito de garantir a continuidade dos serviços, bem como para garantir o processo de transição contratual, a CONTRATADA deverá apresentar Plano de Transferência de Conhecimento (Técnico e/ou Capacitação) e ainda, sob a supervisão e em conjunto com a GESC, executar o Plano de Transição Contratual em conjunto com o CAU/BR, nos termos do item 11.11 deste Termo de Referência.

11.8.2. Transferência de Conhecimento – Técnico

11.8.2.1. A empresa CONTRATADA deverá promover o repasse de todo o conhecimento técnico adquirido ou produzido na execução dos serviços para os técnicos designados pelo CAU/BR;

11.8.2.2. A transferência de conhecimento, no uso das soluções desenvolvidas pela empresa CONTRATADA, deverá ser viabilizada sem ônus adicional para o CAU/BR, conforme Plano de Transferência de Conhecimento fornecido pela empresa CONTRATADA, em eventos específicos de transferência de conhecimento técnico, preferencialmente em ambiente disponibilizado pelo CAU/BR, e baseado em documentos técnicos e/ou manuais específicos da solução desenvolvida. O cronograma e horários dos eventos deverão ser previamente aprovados pelo CAU/BR;

11.8.2.3. A empresa CONTRATADA deverá descrever a metodologia, conforme o Plano de Transferência de Conhecimento, que será utilizada para transferir conhecimento aos técnicos recebedores (empregados do CAU/BR e CAU/UFs), os quais poderão ser multiplicadores do conhecimento transferido a outros técnicos e/ou a usuários finais. O CAU/BR poderá solicitar ajustes caso a metodologia proposta não alcance os objetivos estabelecidos neste Termo de Referência;

11.8.2.4. A transferência de conhecimento, independentemente do número de técnicos indicados pelo CAU/BR, deverá ser focada na solução adotada para uma demanda específica ou de uma forma geral, de forma que haja transferência do conhecimento da tecnologia utilizada em todo o processo de desenvolvimento do sistema. Ao final da transferência, técnicos recebedores deverão estar capacitados para realizarem a instalação, a manutenção e a evolução das funcionalidades do sistema caso necessários;

11.8.2.5. Este plano deverá conter a revisão de toda a documentação gerada de todos os serviços prestados, acrescido de outros documentos que, não sendo artefatos previstos, sejam adequados ao correto entendimento do serviço executado.

11.9. Transferência interna de conhecimento técnico da empresa CONTRATADA

11.9.1. A empresa CONTRATADA deverá promover o repasse de conhecimento aos novos profissionais que vierem a compor a equipe técnica responsável pela execução das demandas do CAU/BR, para que, nos casos de substituição dos responsáveis pela execução de serviços em andamento, os problemas relacionados à continuidade e qualidade dos serviços prestados sejam minimizados;

11.9.2. O processo de transferência deverá envolver especificações técnicas e detalhadas, contendo: funcionalidades, requisitos, classes, configurações, ambientes de software, dependências entre sistemas e outras utilizadas no desenvolvimento e manutenção dos sistemas utilizados no CAU/BR.

11.10. Transferência de Conhecimento – Capacitação

11.10.1. Quando necessário, o CAU/BR poderá solicitar à empresa CONTRATADA o repasse periódico do conhecimento sobre a utilização das funcionalidades e/ou sistemas entregues;

11.10.2. Processo de Homologação (usuários):

11.10.2.1. Sempre que a demanda tiver a indicação da necessidade de homologação assistida, ou seja, de ter o acompanhamento físico (on-site) de representante da empresa CONTRATADA junto com os usuários, será realizado o processo de homologação assistida da solução desenvolvida (salvo quando o CAU/BR julgar que não se faz necessário).

11.10.2.2.A indicação da necessidade de que seja realizado o processo de Homologação Assistida poderá ser sinalizada inclusive no processo de especificação de requisitos/regras de negócio.

11.11. Ações para Transição e Encerramento Contratual

Id	Ação	Responsável	Data Início	Data Fim
1	Realização do planejamento da contratação – renovação ou nova Fábrica de Software.	GESC	180 dias antes do término contratual	60 dias antes do término contratual
2	Repasse de conhecimentos	CONTRATADA	90 dias antes	15 dias antes do

Id	Ação	Responsável	Data Início	Data Fim
	técnicos sobre os produtos entregues.		do término contratual	término contratual
3	Entrega das versões finais dos produtos, de todos os artefatos produzidos, incluindo documentação.	CONTRATADA	30 dias antes do término contratual	15 dias antes do término contratual
4	Envio do plano de entregas pendentes, contendo cronograma e ações para entregas das parcelas em aberto das ordens de serviços.	CONTRATADA	30 dias antes do término do contrato	15 dias antes do término do contrato
5	Envio de lista de pendências das atividades em aberto com orientações para possibilitar a continuidade dos trabalhos.	CONTRATADA	10 dias antes do término contratual	Término contratual
6	Recuperação de todos os documentos classificados ou que devam permanecer com o CAU/BR.	CONTRATANTE	10 dias antes do término do contrato	Término do contrato
7	Recuperação de todos os recursos ou acesso aos recursos de propriedade do CAU/BR	CONTRATANTE	10 dias antes do término do contrato	Término do contrato
8	Cancelamento de todos perfis de acesso da CONTRATADA ao ambiente computacional do CAU/BR providos durante a execução do contrato	GESC	Término do contrato	Término do contrato

Tabela 09: Transição e Encerramento Contratual

11.11.1. A empresa CONTRATADA deverá promover transição contratual e repassar para o CAU/BR e/ou para outra empresa por este indicada, todos os dados, documentos e elementos de informação utilizados na execução dos serviços. Tal procedimento deverá ser realizado em evento formal no período equivalente aos últimos 3 (três) meses de vigência do contrato resultante do presente edital.

11.12. Requisitos Temporais

11.12.1. A garantia do sistema cobrirá todas as entregas parciais, sprints ou releases, inclusive nos casos em que haja a publicação em produção antes da emissão do Termo de Recebimento Definitivo – TRD. Após a formalização da conclusão total da demanda por meio da respectiva emissão do TRD, haverá a cobertura de todas as funcionalidades que compõe a demanda pelo prazo de 120 dias.

11.12.2. Para as demandas classificadas como manutenção corretiva, o prazo de atendimento 7deverá ser conforme seu Nível de Serviço previsto no item 17.7 deste Termo de Referência.

11.13. Requisitos Operacionais

11.13.1. Por questões de segurança, fica a CONTRATADA obrigada a apresentar todas e quaisquer informações e documentações dos profissionais indicados para realizar os serviços nas dependências do CAU/BR (in loco);

11.13.2. É proibida a veiculação de publicidade, direta ou indiretamente relacionada com os serviços constantes deste Termo de Referência, salvo se houver prévia autorização por escrito do CAU/BR;

11.13.3. Por se tratar de contratação que possibilita acesso a informações institucionais do CAU/BR, deve ser formalizado Termo de Confidencialidade entre as partes, conforme Encarte F deste documento, visando garantir a integridade, confidencialidade, autenticidade e sigilo das informações que venha a ter conhecimento no exercício de suas atribuições, e que a CONTRATADA o exija dos seus empregados que prestarem serviços no ambiente do CONTRATANTE;

11.13.4. Ao CAU/BR se reserva o direito de proceder ao levantamento e/ou à confirmação de informações pertinentes à idoneidade de qualquer profissional que venha a ser indicado para a prestação dos serviços;

11.13.5. Os serviços devem ser executados em conformidade com a legislação e normas técnicas aplicáveis.

11.14. Requisitos de Qualidade

11.14.1. Os produtos desenvolvidos pela empresa CONTRATADA deverão atender, além dos demais critérios e requisitos já previstos neste Termo de Referência, os requisitos de qualidade destacados nos itens a seguir:

11.14.1.1.Funcionalidade: desenvolver soluções que atendam às necessidades explícitas e implícitas dos requisitantes, quando o software estiver sendo utilizado sob condições especificadas;

11.14.1.2.Usabilidade: desenvolver interface visual simples, intuitiva e voltada para WEB e APP, contemplando a funcionalidade de ajuda ao usuário através de hints nos principais campos das telas e/ou help on-line, e os demais requisitos de acessibilidade, no que couber, previstos no e-Mag;

11.14.1.3.Confiabilidade: Capacidade do produto de software de manter um nível de desempenho e segurança especificados;

11.14.1.4.Eficiência: Capacidade do produto de software de apresentar desempenho apropriado, relativo à quantidade de recursos usados;

11.14.1.5.Disponibilidade: os sistemas em produção deverão estar disponíveis em tempo integral, 24 (vinte e quatro) horas por dia e sete dias por semana;

11.14.1.6.Integridade: os sistemas de informação deverão manter os dados íntegros, controlando os acessos simultâneos à base de dados e respeitando os princípios ACID – Atomicidade, Consistência, Isolamento e Durabilidade;

11.14.1.7.Portabilidade: os sistemas de informação deverão funcionar corretamente, no mínimo, nos navegadores Mozilla Firefox 52.0 (ou superior), Internet Explorer 11.0 (ou superior) e Google Chrome 60.0 (ou superior);

11.14.1.8.Manutenibilidade: a documentação, inclusive do código-fonte, gerado pela empresa CONTRATADA deverá ser clara e completa. Os sistemas de informação desenvolvidos e/ou sustentados pela empresa CONTRATADA deverão seguir o padrão de nomenclatura de objetos de banco de dados já adotado pelo CAU/BR.

11.15. Teste

11.15.1. Teste do Aplicativo

11.15.1.1.A MGDS do CAU descreve o procedimento da etapa de testes, os artefatos esperados e as responsabilidades da CONTRATADA e do CONTRATANTE; 11.15.1.2.Entende-se como Teste de Aplicativo a execução controlada do aplicativo, verificando se o seu comportamento ocorre de acordo com o especificado no serviço, buscando assim, evidenciar o alcance dos resultados e dos padrões estabelecidos na especificação funcional;

11.15.1.3.Os casos de testes elaborados pela CONTRATADA devem possuir os cenários de teste abarcando 100% das regras de negócio criadas ou modificadas pela ordem de serviço; 11.15.1.4.A CONTRATADA deve entregar, junto com os artefatos construídos, toda a documentação contendo os cenários de teste, os scripts de testes unitários utilizando o PHPUnit ou similar, os scripts de testes automatizados utilizando o SELENIUM IDE ou similar, a filmagem dos cenários que não puderam ser automatizados e as bases de dados de testes que servirão de subsídio para as atividades de auditoria do trabalho de teste e dos testes de aceitação;

11.15.1.5.O CAU/BR realizará, no ambiente de homologação, os testes de aceitação da ordem de serviço, focando no atingimento dos requisitos aparentes para o usuário final, a fim de verificar o funcionamento do aplicativo em ambiente semelhante ao de produção. Serão utilizados os scripts automatizados com dados similares ao ambiente de produção. Esses scripts devem ajudar a reduzir o tempo dos testes realizados pelo CAU/BR. Sempre que possível, é recomendado utilizar outros scripts automatizados para permitir a validação de outras partes do sistema.

11.15.2. Teste Unitário

11.15.2.1.A empresa CONTRATADA deverá criar alterar e executar os testes unitários sobre cada componente do produto de software construído, baseado no escopo da ordem de serviço e conforme os casos de testes elaborados pela empresa CONTRATADA;

11.15.2.2.Entende-se como Teste Unitário aquele realizado isoladamente sobre a menor unidade do projeto de software (por exemplo: um método), que deve abranger pelo menos as técnicas de teste Caixa Preta e Caixa Branca;

00.00.0.0.Xx melhores práticas de desenvolvimento enfatizam a necessidade de testes unitários de forma sistêmica, ou seja, a criação das assertivas de testes unitários que devam ser satisfeitas ou não satisfeitas, utilizando os pontos críticos (máximo, mínimo, intervalos e variações) de maiores probabilidades de erros;

11.15.2.4.A partir dos testes unitários desenhados, executa-se a criação das funcionalidades e, em seguida, executa-se a bateria de testes unitários automatizados;

11.15.2.5.É importante que o teste unitário seja desenhado e codificado antes da criação da funcionalidade a ser testada, utilizando o conceito de TDD (Test Driven Development / Desenvolvimento Orientado a Teste), parte da metodologia XP (Extreming Programming). Isso garante que os testes não sejam viciados e baseados na funcionalidade desenvolvida (ainda não validada), mas sim na regra de negócio especificada (validada pelo CAU/BR).

11.15.2.6.Os sistemas do CAU utilizam PHP, em sua maioria. Logo, é indicado utilizar o PHPUnit: framework mais consagrado para testes unitários em PHP. O PHPUnit suporta várias abstrações que facilitam a escrita, apresentação e validação de testes – Mocking, Assertions, Anotations, Data Providers, Cobertura de Código e Integração com o Selenium.

Imagem 02: Exemplo de Relatório de Cobertura de Testes do PHPUnit

11.15.2.7.Em especial quanto ao Laravel, a integração com o PHPUnit é nativa e aumenta o intervalo e abrangência de testes unitários nativos do PHPUnit, sendo assim, mais fácil de implementar testes unitários.

11.15.3. Teste Integrado

11.15.3.1.Entende-se como Teste Integrado aquele realizado através da navegação de forma progressiva e ordenada pelas telas ou estruturas internas do software, onde seus elementos são combinados e testados para avaliação das suas interações;

11.15.3.2.O Teste Integrado é de responsabilidade da CONTRATADA e deverá ocorrer nos ambientes de desenvolvimento (mantido pela CONTRATADA) e de testes (mantido pelo CAU/BR), antecipando problemas que viriam a ocorrer após a implantação no ambiente de produção;

11.15.3.3.Os testes unitários do PHPUnit devem ser integrados no Jenkins, permitindo a execução sempre a cada publicação de uma versão (build) nos ambientes de homologação e produção. Se os testes unitários rodados no Jenkins não passarem, a build será reprovada, não afetando o ambiente destino;

11.15.3.4.A funcionalidade criada ou alterada pela CONTRATADA deve passar nos novos testes unitários e nos testes unitários legados, já existentes, de forma regressiva.

11.15.4. Realização de Testes Exploratórios Automatizados

11.15.4.1.Entende-se como testes automatizados aqueles realizados de forma integrada e gerenciados, visando o incremento da qualidade, menos tempo e menos custo;

11.15.4.2.Os testes automatizados deverão contemplar os Testes Funcionais e Testes Não- Funcionais;

11.15.4.3.É de responsabilidade da CONTRATADA a automação dos testes cobrindo os cenários de testes especificados, correspondentes a 100% das regras de negócio criadas ou modificadas pela ordem de serviço;

11.15.4.4.Quando comprovadamente não for possível automatizar, será permitido à CONTRATADA filmar a execução do cenário de teste no ambiente de testes, comprovando assim sua realização;

11.15.4.5.A CONTRATADA poderá utilizar a ferramenta de automação de testes que escolher, sem, contudo, gerar qualquer ônus para o CAU/BR;

11.15.4.6.Atualmente é utilizada a ferramenta Selenium IDE, que possibilita gravar, editar e depurar os testes integrados ao navegador Firefox. Ela é importante para a automatização de scripts de passos a serem feitos no navegador de tal forma que o testador apenas modifica algumas variáveis a serem testadas e o script executa todo o resto, apontando erros ou sucesso.

11.15.4.7.A empresa CONTRATADA deverá entregar junto com os artefatos construídos, toda a documentação contendo as evidências de teste, que servirão de subsídio para as atividades de auditoria do trabalho de teste realizado pela CONTRATADA. Essa auditoria poderá ser realizada pelo CAU/BR, pela CONTRATADA ou por empresa designada pelo CONTRATANTE.

11.15.5. Integração Contínua

11.15.5.1.O CAU/BR, hoje, possui um bom nível de integração contínua utilizando as ferramentas GIT, XXXXXXX e a lógica de ambientes de teste, homologação e produção.

11.15.5.2.Atualmente todas ordens de serviços disponibilizadas pela atual empresa CONTRATADA de fábrica de software (FSW) passam pelo seguinte processo:

11.15.5.2.1. Criação de uma branch com o nome „OS-123‟ derivada da branch corrente de produção;

11.15.5.2.2. A branch „OS-123‟ é colocada pela FSW em um ambiente de testes específico; 11.15.5.2.3. A branch „OS-123‟ é testada isoladamente nesse ambiente de testes pela equipe da FSW;

11.15.5.2.4. Em seguida, o CAU/BR homologa a Ordem de Serviço (OS) seguindo os procedimentos do 1° ciclo de homologação descritos na MGDS do CAU;

11.15.5.2.5. Após o aceite pelo CAU/BR da „OS-123‟ em ambiente de testes, ela será enviada para o ambiente de homologação pelo CAU/BR. Será realizado um merge novamente com a branch corrente de produção;

11.15.5.2.6. Se não houvesse o passo anterior, uma OS ao ser enviada para produção iria desatualizada (sem as alterações das outras demandas que já foram para produção no intervalo de tempo de implementação da referida Ordem de Serviço);

11.15.5.2.7. A „OS-123‟ é homologada sozinha no ambiente de homologação seguindo os procedimentos do 2° ciclo de homologação descritos na MGDS do CAU;

11.15.5.2.8. A „OS-123‟ é enviada para Produção;

11.15.5.3.Outro agente importante que é utilizado hoje no CAU/BR é o Jenkins, que auxilia na integração contínua, fazendo o controle de builds, configuração de ambientes, automatização de rotinas específicas para cada ambiente e, será utilizado na execução da bateria de testes unitários com a avaliação de sucesso ou falha para decisão automática de subir a build ou não para o ambiente.

11.15.6. Homologação

11.15.6.1.O processo de homologação (funcional e não-funcional) deverá ocorrer nos ambientes do CAU/BR em 2 (dois) ciclos, conforme detalhado na MGDS do CAU; 11.15.6.2.Quando indicado na ordem de serviço, o processo de homologação será assistido pela empresa CONTRATADA, sem ônus adicional para o CAU/BR;

11.15.6.3.O CAU/BR exigirá todos os artefatos referentes à etapa de testes descritos na MGDS do CAU;

11.15.6.4.O CAU/BR poderá recusar a OS em que os cenários de testes elaborados pela CONTRATADA e demais artefatos e produtos não contemplarem 100% das regras de negócios criadas ou alteradas pela OS.

CAPÍTULO 12. DAS OBRIGAÇÕES E RESPONSABILIDADES DO CONTRATANTE

12.1. Nomear o Gestor e Fiscais Técnico, Administrativo e Requisitante, nos termos do § 1º do art. 30 da IN SLTI/MP nº 01/2019, para acompanhar e fiscalizar a execução do contrato;

12.2. Vetar o emprego de qualquer produto que considerar incompatível com as especificações apresentadas na proposta da empresa CONTRATADA, e que seja inadequado, nocivo ou possa danificar seus bens patrimoniais;

12.3. Disponibilizar ambientes computacionais de teste, homologação e produção (infraestrutura) de modo a viabilizar o cumprimento das exigências de aceite do produto contidas neste Termo de Referência;

12.4. Encaminhar formalmente por meio da ferramenta de Gestão de Demandas à empresa CONTRATADA as Ordens de Serviço (OS) para a execução das demandas deste TR;

12.5. Proporcionar, quando cabível, as facilidades necessárias, para que a empresa CONTRATADA possa cumprir as condições estabelecidas no Termo de Referência;

12.6. Permitir acesso dos profissionais da empresa CONTRATADA às suas dependências, equipamentos, softwares e sistemas de informação sob sua responsabilidade e necessários para a execução dos serviços;

12.7. Verificar o cumprimento dos requisitos de qualificação profissional dos técnicos da empresa CONTRATADA que atuarem na prestação dos serviços;

12.8. Prestar as informações e os esclarecimentos pertinentes ao serviço que venham a ser solicitados pelos profissionais da empresa CONTRATADA ou o seu preposto;

12.9. Aplicar à empresa CONTRATADA as sanções administrativas regulamentares e contratuais cabíveis;

12.10. Receber os serviços entregues pela empresa CONTRATADA, que estejam em conformidade com a OS, conforme inspeções a serem realizadas e emitir Termo de Recebimento Provisório (TRP);

12.11. Aceitar os objetos entregues pela empresa CONTRATADA e que estejam em conformidade com a OS, conforme inspeções a serem realizadas e emitir Termo de Recebimento Definitivo (TRD);

12.12. Rejeitar, com a devida justificativa, qualquer serviço executado em desacordo com as especificações e obrigações assumidas pela empresa CONTRATADA;

12.13. Efetuar o devido pagamento à empresa CONTRATADA, dentro dos prazos preestabelecidos, pela efetiva execução do contrato, desde que cumpridas todas as formalidades, exigências, condições e preços pactuados no contrato;

12.14. Comprometer-se a disponibilizar pessoal técnico para o recebimento da transferência de conhecimento (repasse técnico).

12.15. Conferir toda a documentação técnica gerada e apresentada durante a execução dos serviços, efetuando o seu atesto quando a documentação estiver em conformidade com os padrões de informação e qualidade exigidos;

12.16. Exigir o imediato afastamento do ambiente do CAU/BR, de qualquer profissional e/ou preposto da empresa CONTRATADA que, por justas razões, vier a desmerecer a confiança, embarace a fiscalização ou, ainda, que venha a se comportar de modo inconveniente ou incompatível com o serviço contratado;

12.17. Notificar à empresa CONTRATADA, formal, circunstanciada e tempestivamente, as ocorrências ou anormalidades verificadas durante a execução do contrato, para que sejam adotadas as medidas necessárias, bem como imperfeições, falhas ou irregularidades constatadas no objeto pactuado, para que sejam adotadas as medidas corretivas necessárias;

12.18. Decidir e adotar as medidas julgadas cabíveis, em tempo hábil, que ultrapassem a competência do Gestor do contrato;

12.19. Notificar à empresa CONTRATADA das manutenções corretivas relativas ao período de garantia, por Ordem de Serviço específica e/ou notificação por e-mail;

12.20. Notificar formalmente à empresa CONTRATADA sobre cada uma das advertências advindas das reincidências de atrasos na entrega das manutenções corretivas;

12.21. Aplicar penalidades à empresa CONTRATADA quando do não cumprimento dos prazos previstos de entrega para cada demanda;

12.22. Permitir acesso aos ambientes tecnológicos do CAU/BR pelos profissionais da empresa CONTRATADA que executarem os serviços de forma remota, quando existirem;

12.23. Utilizar o sistema definido entre as partes como solução para ferramenta de Gestão de Demandas de TI (OS).

CAPÍTULO 13. DAS OBRIGAÇÕES E RESPONSABILIDADES DA CONTRATADA

13.1. A empresa CONTRATADA obrigar-se-á a:

13.1.1. Cumprir fielmente as obrigações assumidas em contrato, iniciando e prestando os serviços no prazo estipulado, na forma e nas condições pactuadas, em estrita conformidade com as especificações, prazos e condições estabelecidas nos termos contratuais e na sua proposta;

13.1.2. Participar de reuniões com o Gestor do contrato para alinhamento de expectativas contratuais e entrega de documentos relativos aos serviços contratados;

13.1.3. Disponibilizar para o CAU/BR a ferramenta de Gestão de Demandas de TI (OS) em até 30 (trinta) dias corridos a contar da data da assinatura do contrato, nos termos estabelecidos no capítulo 8 e demais disposições deste Termo de Referência;

13.1.4. Manter seus funcionários devidamente identificados quando da execução de qualquer serviço nas dependências do CAU/BR referente ao objeto contratado observando as normas de segurança (interna e de conduta);

13.1.5. Manter no CAU/BR um Líder Técnico ou Preposto, quando os serviços forem executados nas instalações do CAU/BR, que atuará como seu representante principal, e será responsável pelo acompanhamento da execução do contrato por parte da empresa CONTRATADA, tendo como atribuições, entre outras relativas à adequada execução do contrato, participar de reuniões, zelar pela qualidade dos serviços prestados e pelo bom desempenho dos profissionais da empresa CONTRATADA;

13.1.6. Executar fielmente o objeto contratual de acordo com as normas legais e recomendações técnicas;

13.1.7. Garantir o objeto contratado nos prazos estabelecidos, nas condições e preços consignados em sua proposta comercial devendo estar inclusos todos os custos, impostos, taxas e demais encargos pertinentes à formação do preço;

13.1.8. Responder pelos danos de qualquer natureza que venham a sofrer seus empregados, terceiros ou o CAU/BR, em razão de acidentes, ou de ação, ou de omissão dolosa ou culposa de seus empregados;

13.1.9. Manter, durante a vigência do contrato, todas as condições de habilitação e qualificação para contratar com a Administração Pública, apresentando sempre que exigido os comprovantes de regularidade;

13.1.10. Ter pleno conhecimento de todas as condições e peculiaridades inerentes aos serviços a serem executados não podendo invocar posteriormente desconhecimento para cobrança de serviços extras;

13.1.11. Cumprir com as normas de segurança e medicina do trabalho durante possível estadia dos seus profissionais nas instalações do CONTRATANTE;

13.1.12. Comunicar, ao Gestor do contrato, por escrito, qualquer anormalidade verificada relacionada aos bens e serviços fornecidos ao CAU/BR e prestar os devidos esclarecimentos sempre que solicitados;

13.1.13. Formalizar a indicação de preposto da empresa, e substituto eventual, como seu representante legal incluindo nome, cargo, números de telefone e endereços eletrônicos para, em tempo integral durante o período de vigência do contrato, sem ônus adicional, administrar, acompanhar, supervisionar e controlar todo e qualquer assunto relativo aos serviços contratados, respondendo por todos os atos e fatos gerados ou provocados pelos seus funcionários;

13.1.14. Arcar com todas as despesas, diretas ou indiretas, encargos trabalhistas, previdenciários, fiscais e comerciais decorrentes do cumprimento das obrigações assumidas no contrato, sem qualquer ônus ao CAU/BR;

13.1.15. Sujeitar-se a ampla e irrestrita fiscalização e prestar todos os esclarecimentos solicitados;

13.1.16. Operacionalizar em seu estabelecimento o ambiente de desenvolvimento com ferramentas e tecnologias adequadas, sem qualquer custo para o CAU/BR. Esse ambiente, por sua vez, deverá estar em pleno funcionamento conforme exigências deste Termo de Referência dentro de 30 (trinta) dias a partir da assinatura do contrato, sendo facultada ao CAU/BR a sua inspeção;

13.1.17. Configurar e/ou instalar no ambiente do CAU, mediante autorização do CONTRATANTE, as ferramentas necessárias para garantir o perfeito funcionamento das demandas entregues, sendo que a eventual necessidade de uso de ferramentas externas a serem adquiridas pela CONTRATADA, nos termos definidos neste Termo de Referência, não serão objeto de pagamentos adicionais pelo CONTRATANTE;

13.1.18. Solicitar autorização prévia do CAU/BR para incorporar, nos serviços entregues, componentes de software que não sejam de propriedade do CAU/BR. Caso sejam utilizados componentes de mercado baseados em software livre, essa informação deverá constar da documentação técnica entregue;

13.1.19. Garantir que todas as entregas efetuadas estejam compatíveis e totalmente aderentes aos produtos utilizados pelo CAU/BR. Cabe à CONTRATADA dar ciência ao CAU/BR, sobre o uso de ferramentas cuja versão seja diferente daquelas previstas e em uso na empresa, cabendo a este autorizar ou não;

13.1.20. Manter a compatibilidade, evoluindo e adaptando-se às possíveis atualizações das versões dos sistemas operacionais, linguagens de desenvolvimento ou ferramentas de apoio ao desenvolvimento (aberto, de sua propriedade ou de seu direito de uso) promovidas pelo CAU/BR, segundo a necessidade e conveniência administrativa, sem quaisquer custos adicionais para o CAU/BR;

13.1.21. Adotar procedimentos no seu ambiente de desenvolvimento, que garantam a segurança das informações e a continuidade das operações, em conformidade com os parâmetros da NBR-ISO/IEC 27001, e manter documentação atualizada de sua Política de Segurança de Informações;

13.1.22. Seguir a Metodologia de Gestão em Desenvolvimento de Software do Conselho de Arquitetura e Urbanismo (MGDS-CAU), versão 3.0 ou superior;

13.1.23. Comprometer-se a realizar todas as atividades, entregar todos os artefatos previstos dentro dos prazos e qualidade previstos;

13.1.24. Zelar pelo cumprimento dos prazos estipulados para entrega dos artefatos, início dos testes, correções e reincidências, sendo o não atendimento a estes prazos passível de aplicação das penalidades previstas;

13.1.25. Xxxxxxxx, sem ônus para o CAU/BR, sempre que solicitada, todas as informações referentes à execução das Ordens de Serviço, solicitações realizadas via e-mail ou quaisquer outras informações pertinentes à execução da(s) demanda(s);

13.1.26. Atender prontamente a quaisquer reclamações realizadas pelo CAU/BR durante o contrato;

13.1.27. Realizar, periodicamente ou sempre que solicitada, reuniões de acompanhamento das demandas;

13.1.28. Apresentar pelo menos 3 (três) propostas de linha visual (layout/interface gráfica) para as demandas de serviços ou desenvolvimento, que envolvam a identidade visual (layout/interface gráfica). A empresa CONTRATADA deverá realizar os ajustes solicitados pelo CAU/BR que se façam necessários para a escolha e validação de uma das propostas de linha visual;

13.1.29. Elaborar protótipos funcionais de tela, quando aplicável, e buscar sua validação com os usuários antes de iniciar a etapa de codificação;

13.1.30. Comprometer-se a manter, ao longo de todo contrato, profissionais com os perfis e qualificações solicitados, atendendo a qualquer tempo os requisitos exigidos para sua habilitação e qualificação neste Termo de Referência;

13.1.31. Disponibilizar a formalização dos procedimentos de instalação do serviço executado nos ambientes do CAU/BR (por intermédio das instruções para publicação da OS nos ambientes de homologação e produção, utilizando a integração contínua), contemplando todas

as atividades técnicas necessárias, em todas as plataformas tecnológicas envolvidas, para que a solução desenvolvida esteja plenamente operacional no referido ambiente;

13.1.32. Detalhar e repassar para o CAU/BR, conforme sua orientação e seu interesse, sem qualquer custo adicional, todo o conhecimento técnico utilizado na implementação dos serviços prestados;

13.1.33. Acompanhar todo o processo de implantação das soluções (entrada em produção) on-site (presencialmente nas dependências do CAU/BR), de forma a solucionar os possíveis imprevistos no resultado da execução das atividades descritas nas instruções para publicação da OS nos ambientes de homologação e produção;

13.1.34. Atualizar o sistema de versionamento do CAU/BR, de forma que a qualquer tempo este possa ser consultado pelo CAU/BR e este possa obter as informações necessárias;

13.1.35. Atender aos requisitos de confidencialidade e direito de distribuição, uso e propriedade das soluções desenvolvidas;

13.1.36. Assumir a responsabilidade por todos os encargos previdenciários e as obrigações sociais previstos na legislação social e trabalhista em vigor, obrigando-se a saldá-los na época própria, uma vez que os seus empregados não manterão nenhum vínculo empregatício com o CAU/BR;

13.1.37. Impedir que os profissionais alocados na prestação dos serviços se pronunciem em nome do CAU/BR;

13.1.38. Designar novo preposto, sempre que a gestão ou fiscalização do contrato solicitar formalmente;

13.1.39. Assumir a responsabilidade por todas as providências e obrigações estabelecidas na legislação específica de acidentes de trabalho, quando, em ocorrência da espécie, forem vítimas os seus empregados quando da prestação dos serviços ou em conexão com ela, ainda que acontecido em dependência do CAU/BR, inclusive por danos causados a terceiros;

13.1.40. Assumir todos os encargos de possível demanda trabalhista, cível ou penal, relacionadas à prestação dos serviços, originariamente ou vinculada por prevenção, conexão ou contingência;

13.1.41. Assumir a responsabilidade pelos encargos fiscais e comerciais resultantes da adjudicação deste processo licitatório;

13.1.42. Arcar com os ônus resultantes de quaisquer ações, demandas, custos e despesas decorrentes de contravenção, seja por culpa sua ou de quaisquer de seus empregados ou prepostos, obrigando-se, outrossim, a quaisquer responsabilidades decorrentes de ações judiciais ou extrajudiciais de terceiros, que lhe venham a ser exigidas por força da lei, ligadas ao cumprimento do contrato a ser firmado;

13.1.43. Arcar com qualquer prejuízo causado à Administração ou a terceiros por seus empregados ou transportadora durante a entrega do objeto;

13.1.44. Corrigir qualquer erro de código ou defeito do sistema, conforme prazo de garantia previsto em contrato;

13.1.45. Identificar os empregados que forem atuar nas dependências do CAU/BR ou locais de prestação de serviço indicados pelo CAU/BR;

13.1.46. Responsabilizar-se por todos os custos com pessoal, diárias, passagens e comunicações, necessários à perfeita execução dos serviços previstos no Termo de Referência, observadas as condições indicadas no item 8.2;

13.1.47. Atualizar o andamento das Ordens de Serviço na ferramenta de Gestão de Demandas de TI - OS (Ordens de Serviço) disponibilizada;

13.1.48. Afastar, imediatamente, o profissional que seja considerado inapto para os serviços a serem prestados, seja por incapacidade técnica, atitude inconveniente, falta de urbanidade ou que venha a transgredir as normas disciplinares do CAU/BR;

13.1.49. Adaptar-se a processos de trabalho, tecnologias, sistemas ou procedimentos definidos pelo CAU/BR como padrão;

13.1.50. Não suspender ou interromper, salvo motivo de força maior ou caso fortuito, sem que sejam justificados e aceitos pelo CAU/BR, os serviços solicitados;

13.1.51. Observar os padrões Arquiteturais, de Segurança e de Qualidade dos artefatos;

13.1.52. Entregar ao CAU/BR, durante o período de transição inicial, relação nominal de todos dos profissionais que atuarão na execução deste contrato, fornecendo os dados pessoais

necessários e o seu papel de trabalho. Essa relação deverá ser mantida atualizada durante toda a vigência do contrato;

13.1.53. Permitir que o correio eletrônico e a navegação em sítios da Internet a partir do ambiente de rede do CAU/BR, a exclusivo critério do CAU/BR, possam ser objeto de controle e auditoria;

13.1.54. Comunicar, com antecedência mínima de 5 (cinco) dias, qualquer ocorrência de transferência, remanejamento ou demissão dos profissionais alocados na execução dos serviços, para que seja providenciada a revogação de todos os privilégios de acesso aos sistemas, informações e recursos do CAU/BR porventura colocados à disposição para realização dos serviços contratados;

13.1.55. Cumprir e garantir que seus profissionais estejam aderentes à Política de Segurança da Informação em TI do CAU/BR e demais normas de conduta e de uso das instalações e equipamentos estabelecidos;

13.1.56. Comprovar imediatamente, quando exigido pelo CAU/BR, a qualificação dos profissionais alocados aos serviços objeto desta contratação;

13.1.57. Adequar e manter o nível de prestação dos serviços técnicos de TI em sintonia com as alterações na plataforma tecnológica ou processos de trabalho, tão logo seja comunicada pelo CAU/BR;

13.1.58. Observar e atender a todas as normas e instruções emanadas pelo CAU/BR, além de toda a legislação pertinente que regule a prestação dos serviços;

13.1.59. Corrigir, sem custos adicionais, os defeitos ou as imperfeições dos serviços executados, durante todo o exercício do contrato, conforme prazos previstos no Termo de Referência;

13.1.60. Elaborar e executar plano de capacitação contínua de seus profissionais, às suas expensas, nas áreas de interesse dos serviços sempre que se fizer necessário, considerando as mudanças de plataforma tecnológica ou processos de trabalho;

13.1.61. Manter sigilo (publicação integral ou parcial de documentos, especificação técnica ou qualquer outro artefato previsto);

13.1.62. Acatar todas as disposições contidas no edital, sob pena de incorrer em descumprimento total ou parcial do objeto contratado;

13.1.63. Comunicar previamente à empresa CONTRATANTE sobre as alterações na plataforma de tecnologia da informação ou processos de trabalho.

CAPÍTULO 14. DA SUBCONTRATAÇÃO

14.1. Não será admitida a subcontratação para este objeto licitado.

CAPÍTULO 15. ALTERAÇÃO SUBJETIVA

15.1. É admissível a fusão, cisão ou incorporação da contratada com/em outra pessoa jurídica, desde que sejam observados pela nova pessoa jurídica todos os requisitos de habilitação exigidos na licitação original; sejam mantidas as demais cláusulas e condições do contrato; não haja prejuízo à execução do objeto pactuado e haja a anuência expressa da Administração à continuidade do contrato.

CAPÍTULO 16. CONTROLE E FISCALIZAÇÃO DA EXECUÇÃO

16.1. O contrato será fiscalizado conforme as especificações constantes deste Termo de Referência considerando a classificação das demandas e definição de prazos e os indicadores aferidos mensalmente.

CAPÍTULO 17. CONTROLE E FISCALIZAÇÃO DA EXECUÇÃO

17.1. Aderência à MGDS-CAU

17.1.1. Índice de entrega dentro do prazo (IDP)

17.1.1.1. O cumprimento dos prazos previstos no Item 17.7 será avaliado por meio do Indicador de Demandas entregues dentro do Prazo (IDP), onde será aplicado o Fator de Redução por Atraso (FRA), considerando os seguintes critérios:

17.1.1.1.1. O serviço entregue com o IDP > (maior) que o limite estabelecido nos níveis de serviço será remunerado com a aplicação do Fator de Redução por Atraso (FRA) conforme a fórmula: FRA = (IDP – 30) * 1% (um por cento);

17.1.1.1.2. O Fator de Redução por Atraso (FRA) não poderá ultrapassar o valor equivalente a 1, ou seja, 30% (trinta por cento) do valor da OS, sem prejuízo da aplicação de multa compensatória em face de eventuais prejuízos causados para o CAU/BR;

17.1.1.2. No cálculo do IDP deverão ser descontados os dias úteis utilizados eventualmente pelo CAU/BR para a solução de impedimentos e homologação de artefatos e produtos.

17.1.1.3. Caso o CAU/BR recuse uma entrega, o tempo de execução da OS será retomado.

17.1.2. Índice de Pontos com Defeito (PD)

17.1.2.1. A qualidade do serviço entregue pela empresa CONTRATADA será avaliada por meio do Índice de Pontos de Função com Defeito (PD), sendo o serviço classificado pelo CAU/BR, no processo de recebimento da OS, de acordo com os seguintes critérios:

a) Homologado em um dos ciclos: quando o produto final for recebido integralmente pelo CAU/BR sem erros com relação ao que foi especificado, bem como os refinamentos detectados forem, a critério do CAU/BR, realizados em outra OS;

b) Homologado com ressalvas: quando durante a homologação for detectado no produto final somente erros de texto ou de mensagens que devem ser corrigidos na mesma OS. Neste caso a OS é devolvida para correção e o tempo de execução da OS será retomado sem incremento do prazo inicial previsto, porém os erros não serão apontados para o cálculo do PD. É possível detectar refinamentos, ou seja, corrigir os desvios não especificados inicialmente para que o produto atenda às necessidades dos usuários. Os refinamentos não serão pontuados no cálculo do PD e podem ser corrigidos na mesma OS ou em outra. Caso seja construído na mesma OS a CONTRATADA deve apresentar a proposta de dias úteis para a execução dos refinamentos e, caso seja aprovado pelo CAU/BR, o prazo previsto será aumentado;

c) Não-conforme: quando o produto final recebido apresentar ao menos um erro com relação ao que foi especificado em algum dos ciclos de homologação. Será apontado um erro para cada travamento, impedimento de prosseguir com o teste, regra de negócio ou de apresentação não atendida ou cenário de teste com resultado diferente do esperado. Também será considerado não-conforme os descumprimentos da MGDS do CAU.

17.1.2.2. A não-conformidade da OS sujeitará a empresa CONTRATADA às penalidades previstas neste documento e no contrato;

17.1.2.3. Concluídos os ajustes por parte da empresa CONTRATADA, o CAU/BR emitirá o Termo de Recebimento Provisório (TRP), aplicando os redutores pelos erros identificados, conforme a seguir:

a) Índice PD acima do limite tolerável de 0,25 (vinte e cinco décimos), na emissão do Termo de Recebimento Provisório (TRP) da etapa de desenvolvimento “Implantação”, será aplicado Fator Redutor por Xxxx (FRE) conforme a fórmula: FRE = PD * 0,5.

b) O Fator de Redução por Xxxx (FRE) não poderá ultrapassar o valor equivalente a 1, ou seja, 30% (trinta por cento) do valor da OS, sem prejuízo da aplicação de multa compensatória em face de eventuais prejuízos causados para o CAU/BR;

17.1.2.4. O FRA e FRE serão somados e aplicados como glosa da OS, limitados ao valor de 100% dessa ordem, sem prejuízo de aplicação de multa compensatória em face de eventuais prejuízos causados para o CAU/BR;

17.1.2.5. O faturamento do serviço entregue pela empresa CONTRATADA, autorizada pela emissão do Termo de Recebimento Definitivo (TRD), somente estará autorizado pela emissão do Termo de Recebimento Provisório (TRP) ou quando recebido por decurso de prazo.

17.2. Fábrica de Software (FSW)

17.2.1. Serão consideradas aceitas e recebidas as demandas do tipo Projeto, Sustentação e Serviço de sistemas de informação que estiverem de acordo com as especificações e critérios estabelecidos na OS, na MGDS CAU, bem como com as condições deste Termo de Referência;

17.2.2. Os serviços entregues com qualidade abaixo da esperada (PD) e além do prazo previsto (IDP) sofrerão redução do valor remuneratório, de acordo com os fatores estabelecidos no Capítulo 17.

17.3. Termo de Recebimento Provisório (TRP)

17.3.1. A emissão do Termo de Recebimento Provisório (TRP) contemplará entregas que contenham todos os artefatos previstos, no caso dos códigos-fontes, disponibilizados no ambiente do CAU/BR (desenvolvimento e/ou homologação), de forma que seja possível o início do processo de homologação técnica e/ou funcional da solução.

17.4. Termo de Recebimento Definitivo (TRD)

17.4.1. O Termo de Recebimento Definitivo (TRD) será emitido após a realização de todas as entregas vinculadas a OS, desde que testadas, aprovadas e ocorrida a transferência de conhecimento e tecnologia, este último quando for necessário para o entendimento da solução entregue;

17.4.2. Ao montante previsto no Termo de Recebimento Definitivo (TRD) serão aplicados os fatores de redução (FRA e FRE) previstos neste Termo de Referência; esses redutores serão aplicados em função da ocorrência de erros e/ou atrasos nas entregas efetuadas pela empresa CONTRATADA;

17.4.3. A emissão do TRP ou TRD por decurso de prazo autoriza o pagamento, mas não dá por aceita a entrega, cabendo a emissão posterior do TRP ou TRD (classificados com “Recebido” ou “Rejeitado”), nos casos em que se aplicar, a consequente devolução do serviço à empresa CONTRATADA para ajustes, não eximindo a empresa CONTRATADA de executar a transferência de conhecimento, bem como a aplicação devida da redução do valor de pagamento à empresa CONTRATADA em decorrência do não cumprimento das metas estabelecidas aos indicadores IDP e PD.

17.4.4. O decurso de prazo será considerado quando não for lavrado o Termo de Recebimento Definitivo (TRD) dentro do prazo contratual, respeitadas as definições da MGDS- CAU e do “Roteiro de Métrica de Software” do SISP v.2.2 (ou superior). Neste caso, o serviço será considerado como “Recebido”, desde que a empresa comunique ao CAU/BR formalmente nos 15 (quinze) dias anteriores à exaustão do prazo contratual.

17.5. Inspeções e Diligências

17.5.1. O CAU/BR se reserva o direito de, a qualquer tempo, realizar diligência no ambiente físico da empresa CONTRATADA ou solicitar quaisquer documentações complementares visando aferir se todas as obrigações de ordem técnica, pessoal qualificado, operacional ou administrativa, bem como se a manutenções das condições de habilitação estão sendo cumpridas.

17.6 Níveis de Serviço

17.6.1. Níveis Mínimos de Serviço - Item 1 - Desenvolvimento de sistemas e aplicativos mobile

17.6.1.1. O esforço empreendido pela CONTRATADA na prestação dos serviços de desenvolvimento e manutenção de soluções de software será mensurado e remunerado por meio da métrica de PONTO DE FUNÇÃO (PF), de acordo com este Termo de Referência, pelas definições complementares do Roteiro de Métricas de Software do SISP (disponível em: xxxx://xxx.xxxx.xxx.xx/xxxxxxxx/) e pelos padrões internacionais definidos pelo Manual de Práticas de Contagem de Ponto de Função (Function Point Counting Practices Manual – CPM) do International Function Point Users Group (IFPUG) – todos em suas versões mais recentes e considerando eventuais atualizações que venham a ser aplicadas no decurso da execução contratual. Sobre o valor remunerável incidirão eventuais descontos/glosas resultantes de resultados dos indicadores de níveis mínimos de serviço exigidos (Acordo de Nível de Serviço)

17.6.1.2. Tal métrica foi adotada considerando as disposições legais e normativas aplicáveis às contratações públicas de Tecnologia da Informação por órgãos e entidades da Administração Pública Federal, considerando a análise de alternativas realizada no ESTUDO TÉCNICO PRELIMINAR e considerando o disposto na Súmula TCU n° 269, in verbis:

“Nas contratações para a prestação de serviços de tecnologia da informação, a remuneração deve estar vinculada a resultados ou ao atendimento de níveis de serviço, admitindo-se o pagamento por hora trabalhada ou por posto de serviço somente quando as características do objeto não o permitirem, hipótese em que a excepcionalidade deve estar prévia e adequadamente justificada nos respectivos processos administrativos”. [Súmula TCU n° 269]

17.6.1.3. Ainda, em atenção ao disposto no Item 3.2 do Anexo da Instrução Normativa 01/2019/SGD/ME, todas as atividades inerentes ao ciclo de vida de desenvolvimento e

manutenção de software estão incluídas na métrica de pagamento em função dos resultados e produtos entregues, de forma que o CONTRATANTE não efetuará pagamentos adicionais por quaisquer atividades já incluídas no escopo desses serviços.

17.6.2. Modelo de execução

17.6.2.1. Os serviços do ITEM 1 (desenvolvimento e manutenção de soluções de software) serão executados sob demanda, mediante abertura de ORDENS DE SERVIÇO dimensionadas segundo a métrica de PONTO DE FUNÇÃO (PF), sem garantia de consumo mínimo.

17.6.2.2. A execução dos serviços de desenvolvimento e manutenção de soluções de software pela CONTRATADA deve compreender processos, atividades e cerimônias ágeis – de acordo com as definições da Metodologia de Gestão em Desenvolvimento de Software (MGDS-CAU/BR).

17.6.3. Prazos e formas de encaminhamento de demandas

17.6.3.1. Para os serviços de desenvolvimento e manutenção de soluções de software (ITEM 1) estão previstos 2 (dois) tipos de ORDEM DE SERVIÇO (O.S.):

a) ORDEM DE SERVIÇO DE PLANEJAMENTO (O.S. PLANEJAMENTO); e

b) ORDEM DE SERVIÇO DE DESENVOLVIMENTO (O.S. DESENVOLVIMENTO).

17.6.3.2. Para cada ORDEM DE SERVIÇOS DE PLANEJAMENTO podem derivar tantas ORDENS DE SERVIÇO DE DESENVOLVIMETNO quantas forem necessárias sendo, tendo como referência, no mínimo, uma para cada RELEASE.

17.6.3.3. A critério do CONTRATANTE – considerando o nível de complexidade, o volume demandado e as características de cada projeto – a ORDEM DE SERVIÇO DE PLANEJAMENTO pode ser dispensada, sendo encaminhadas diretamente ORDENS DE SERVIÇO DE DESENVOLVIMENTO.

17.6.3.4. O quadro a seguir resume a correlação entre os tipos de demanda, as formas de encaminhamento e o percentual remunerável por fase:

Demanda	Forma de Encaminhamento	Percentual Remunerável
Serviços de desenvolvimento e manutenção de soluções de software	ORDEM DE SERVIÇO DE PLANEJAMENTO	10% (dez por cento)
	ORDEM DE SERVIÇO DE DESENVOLVIMENTO	90% (noventa por cento)

Tabela 10: Tipos de Demanda

17.6.3.5. A critério do CONTRATANTE, nas situações viáveis e considerando o nível de complexidade, o volume demandado e as características de cada projeto, poderão ser dispensadas as ORDENS DE SERVIÇO DE PLANEJAMENTO – situações às quais serão emitidas diretamente as ORDENS DE SERVIÇO DE DESENVOLVIMENTO, cujo percentual remunerável será obviamente de 100% das unidades de serviço homologadas.

Das Ordens de Serviço de Planejamento

17.6.3.6. Abertas à critério do CONTRATANTE, as ORDENS DE SERVIÇO DE PLANEJAMENTO terão como produto, no mínimo, a análise de viabilidade do projeto, a estimativa de tamanho funcional da solução, a apresentação do backlog do produto e o planejamento dos ciclos de desenvolvimento (releases/sprints).

17.6.4. Dos prazos de execução das ordens de serviço de planejamento

17.6.4.1. Os prazos para atendimento das ORDENS DE SERVIÇO DE PLANEJAMENTO baseiam-se na complexidade da demanda, de acordo com o quadro seguinte:

Níveis de Complexidade	Critérios	Prazos
Demandas de Alta complexidade	Solicitações que tratam do desenvolvimento de novas soluções de software e/ou de soluções que demandam envolvimento de mais de uma área de negócio e/ou de soluções que demandam integração com outros sistemas e/ou soluções que visam a atender requisitos legais definidos em decretos, leis, portarias ou editais	15 (quinze) dias úteis
Demandas de Média	Solicitações que tratam de	10 (dez) dias úteis

Níveis de Complexidade	Critérios	Prazos
complexidade	manutenções evolutivas e/ou adaptativas e/ou soluções que envolvem mais de uma área de negócio
Demandas de Baixa complexidade	Solicitações que tratam de manutenções evolutivas e/ou adaptativas e/ou soluções que envolvem uma única área de negócio e/ou soluções que possuem escopo limitado a até 3 (três) ciclos de desenvolvimento	5 (cinco) dias úteis

Tabela 11: Prazos de Atendimento das OSs

17.6.4.2. A contagem de prazos de execução de ORDENS DE SERVIÇO DE PLANEJAMENTO será interrompida quando fatores externos de domínio do CONTRATANTE impeçam o avanço da execução. Nesses casos, a CONTRATADA deve comunicar, registrar e documentar (prover evidências) formalmente as restrições/impedimentos – cabendo exclusivamente ao CONTRATANTE decidir sobre as justificativas e suspender a contagem de prazos.

17.6.4.3. Os prazos predefinidos serão formalizados nas respectivas ORDENS DE SERVIÇO e seu descumprimento resultará na aplicação de reduções à remuneração da CONTRATADA em função dos NÍVEIS DE SERVIÇOS contratados.

17.6.4.4. Como ocorre em relação a todos os demais produtos da prestação dos serviços, os resultados dos das ORDENS DE SERVIÇO DE PLANEJAMENTO serão objeto de avaliação pelo CONTRATANTE, de acordo com os critérios negociais e técnicos contratados.

17.6.5. Da remuneração das ordens de serviço de planejamento.

17.6.5.1. A remuneração pelo esforço empreendido pela CONTRATADA na execução das ORDENS DE SERVIÇO DE PLANEJAMENTO será de 10% (dez por cento) do tamanho funcional estimado em PONTOS DE FUNÇÃO da demanda planejada.

17.6.5.2. No âmbito de um mesmo PROJETO ou DEMANDA, considerando que o planejamento integra o CICLO DE VIDA de desenvolvimento dos produtos de software, os valores efetivamente pagos à CONTRATADA pela execução das ORDENS DE SERVIÇO DE PLANEJAMENTO serão COMPENSADOS (deduzidos) nas ORDENS DE SERVIÇO DE DESENVOLVIMENTO imediatamente subsequentes.

17.6.5.3. Executado o PLANEJAMENTO, nas hipóteses em que o CONTRATANTE decidir não realizar o DESENVOLVIMENTO, os valores pagos na ORDEM DE SERVIÇO DE PLANEJAMENTO não deverão ser restituídos e nem compensados em outros projetos, bem como os valores já compensados não serão alterados.

17.6.5.4. Executado o PLANEJAMENTO e iniciado o DESENVOLVIMENTO, nas hipóteses em que o CONTRATANTE decidir não o concluir, os valores pagos na ORDEM DE SERVIÇO DE PLANEJAMENTO já compensados (deduzidos) não serão objeto de alteração/reavaliação.

17.6.6. Das solicitações de serviço.

17.6.6.1. Antes de iniciar a fase de DESENVOLVIMENTO, o CONTRATANTE emitirá, para cada demanda, uma SOLICITAÇÃO DE SERVIÇO (SS) para planejamento do atendimento pela CONTRATADA – contendo as informações necessárias e suficientes para compreensão da necessidade de negócio.

17.6.6.2. Após o recebimento da SOLICITAÇÃO DE SERVIÇO, a CONTRATADA deverá iniciar junto à área de negócio requisitante a confecção do PLANO DE EXECUÇÃO contendo o planejamento do atendimento. O prazo para a conclusão dessa atividade será de até 5 (cinco) dias úteis para todas as SOLICITAÇÕES DE SERVIÇO.

17.6.6.3. Como resultado desse trabalho, a CONTRATADA deve apresentar no PLANO DE EXECUÇÃO o planejamento do RELEASE com as entregas por SPRINT, a estimativa de tamanho funcional e o prazo necessário para execução da demanda. O PLANO DE EXECUÇÃO será objeto de avaliação pelo CONTRATANTE. Devendo a CONTRATADA

ajustá-lo a partir dos apontamentos do CONTRATANTE, quando for o caso. Em nenhuma hipótese, as SOLICITAÇÕES DE SERVIÇO são objeto de remuneração.

17.6.7. Das Ordens de Serviço de Desenvolvimento

17.6.7.1. As datas previstas no planejamento do RELEASE, contempladas na fase de PLANEJAMENTO ou no PLANO DE EXECUÇÃO, para início e término do DESENVOLVIMENTO irão compor as ORDENS DE SERVIÇO DE DESENVOLVIMENTO – as quais serão registradas e encaminhadas à CONTRATADA para início da execução das atividades do ciclo do DESENVOLVIMENTO.

17.6.7.2. A fim de evitar a abertura de DESENVOLVIMENTOS com escopo demasiadamente amplo, de modo a mitigar o risco dos projetos, o volume máximo permitido para cada ORDEM DE SERVIÇO DE DESENVOLVIMENTO será de até 100 (cem) PONTOS DE FUNÇÃO.

17.6.7.3. Considerando que a aceitação de mudanças é um dos aspectos essenciais dos métodos ágeis, as ORDENS DE SERVIÇO DE DESENVOLVIMENTO podem apresentar variação entre o volume planejado e aquele efetivamente entregue – sendo este último objeto de validação na etapa de homologação. Porém, visando garantir o necessário PLANEJAMENTO ORÇAMENTÁRIO, as alterações não poderão exceder a 30% (trinta por cento) à MAIOR em relação ao volume inicialmente planejado.

17.6.7.4. Nas situações às quais o volume a ser executado ultrapassar o LIMITE de 30% estabelecido acima, a CONTRATADA deverá solicitar a abertura de uma nova ORDEM DE SERVIÇO DE DESENVOLVIMENTO para o quantitativo excedente. Em qualquer circunstância o PLANEJAMENTO do(s) ciclo(s) deve ser mantido sempre atualizado.

17.6.7.5. Caso o CONTRATANTE motive o cancelamento de ORDENS DE SERVIÇO DE DESENVOLVIMENTO cuja execução já tenha sido iniciada a CONTRATADA fará jus ao recebimento proporcional do esforço dedicado, de acordo com o tamanho funcional efetivamente aferido e limitado ao valor total da ORDEM DE SERVIÇO. O pagamento fica condicionado à homologação pelo CONTRATANTE dos artefatos solicitados e entregues pela CONTRATADA de SPRINTS já concluídas.

17.6.7.6. Caso o cancelamento de ORDENS DE SERVIÇO DE DESENVOLVIMENTO seja motivado pela CONTRATADA não haverá qualquer tipo de pagamento proporcional e nem prejuízo à eventual aplicação de glosas e sanções cabíveis.

17.6.7.7. Integra o pacote de entregáveis das ORDENS DE SERVIÇO DE DESENVOLVIMENTO a medição do tamanho funcional, em Pontos de Função, da solução desenvolvida. Como ocorre em relação a todos os demais produtos da prestação dos serviços, os resultados das ORDENS DE SERVIÇO DE DESENVOLVIMENTO serão objeto de avaliação pelo CONTRATANTE, de acordo com os critérios negociais e técnicos contratados.

17.6.8. Dos prazos de execução das ordens de serviço de desenvolvimento

17.6.8.1. O planejamento da execução de ORDENS DE SERVIÇO DE DESENVOLVIMENTO deverá considerar os seguintes prazos máximos de acordo com o volume em PONTOS DE FUNÇÃO líquidos (já considerados os deflatores):

Tamanho do Projeto	Prazo máximo (em dias úteis)
Até 4 PF	5 dias
4 a 8 PF	10 dias
8 a 10 PF	13 dias
11 a 20 PF	25 dias
21 a 30 PF	37 dias
31 a 40 PF	50 dias
41 a 50 PF	62 dias
51 a 60 PF	75 dias
61 a 70 PF	82 dias
71 a 85 PF	90 dias
86 a 99 PF	99 dias

Tabela 12: Planejamento de Execução das OSs

17.6.8.2. Os prazos estipulados na tabela acima foram baseados no Roteiro de Métricas de Software do SISP, adequados ao ambiente do CONTRATANTE e acolhidos em seus padrões e processos internos.

17.6.8.3. Nas situações às quais o volume executado exceder ao planejado, dentro dos limites e condições do item anterior, os prazos de execução da respectiva ORDEM DE SERVIÇO DE DESENVOLVIMENTO refletirão proporcionalmente a variação aplicada ao tamanho funcional. Em qualquer circunstância o planejamento do(s) ciclo(s) deve ser mantido sempre atualizado.

17.6.8.4. Os prazos predefinidos serão formalizados nas respectivas ORDENS DE SERVIÇO e seu descumprimento resultará na aplicação de reduções à remuneração da CONTRATADA em função dos NÍVEIS DE SERVIÇOS contratados.

17.6.8.5. A contagem do tempo de atendimento será interrompida quando, por algum fator externo que impeça o avanço no atendimento, a OS for colocada como pendente, sendo necessário que a CONTRATADA informe os motivos da pendência com as devidas evidências e a CONTRATANTE autorize justificadamente a paralisação.

17.6.9. Do recebimento dos serviços

17.6.9.1. O recebimento definitivo das ORDENS DE SERVIÇO de desenvolvimento e manutenção de soluções de software será efetivado após homologação negocial e técnica pelo CONTRATANTE – iniciada apenas após a entrega total de todos os produtos contemplados.

17.6.9.2. Caso sejam identificados erros e/ou inconformidades, a CONTRATADA deverá corrigi-los e reapresentar os entregáveis corrigidos ao CONTRATANTE, sem prejuízo da incidência de NÍVEIS DE SERVIÇO e considerando que a contagem de prazos não será interrompida nas ocorrências de necessidades de correção de erros e inconformidades.

17.6.10. Do monitoramento da execução

17.6.10.1. A CONTRATADA deverá, sem ônus adicional ao CONTRATANTE, sempre que solicitada, fornecer as informações necessárias e atualizadas referentes à execução de ORDENS DE SERVIÇO, bem como inserir essas informações em sistema informatizado hábil, a critério do CONTRATANTE, durante o período de vigência do CONTRATO.

17.6.10.2. Ao término do CONTRATO, ou sempre que solicitado pelo CONTRATANTE, a CONTRATADA fornecerá dados e informações históricas de todas as ORDENS DE SERVIÇO por ela recebidas, prestação de contas e informações sobre homologação de produtos, assim como as versões dos artefatos integrantes e complementares, em mídia digital, formato de arquivo-texto ou outro meio previamente acordado com o CONTRATANTE.

17.6.11. Modelo de remuneração

17.6.11.1. Considerando a forma de encaminhamento das demandas e medição, o Serviço de Desenvolvimento e Manutenção de Sistemas será remunerado por ORDEM DE SERVIÇO, dimensionadas e calculadas segundo a métrica de Pontos de Função. Assim, a remuneração de cada ORDEM DE SERVIÇO será calculada considerando a quantidade de Pontos de Função dimensionados, o preço unitário de cada Ponto de Função e o percentual remunerável por fase, da seguinte forma:

𝑫𝑺𝑾𝑰𝒕𝒆𝒎 𝟏= {[(𝑸𝒕𝒅𝒆𝑷𝑭𝒉 𝒙 𝑷𝑭𝑼𝒏𝒊𝒕á𝒓𝒊𝒐) *𝑵𝑴𝑺𝑨𝒋𝒖𝒔𝒕𝒆] − 𝑭𝒂𝒔𝒆𝑨𝒋𝒖𝒔𝒕𝒆}

DSW Item 2: Remuneração Serviço de Desenvolvimento e Manutenção de Softwares, por Ordem de Serviço

Qtde PFh: Volume de Pontos de Função homologados (em Ponto de Função)

PF Unitário: Valor unitário do Ponto de Função definido em Contrato (para o Item 1)

NMS Ajuste: Ajuste (redução/glosa) em função dos resultados dos Níveis Mínimos de Serviço

Fase Ajuste: Ajuste (desconto) de valores eventualmente pagos na Ordem de Serviço de

Planejamento

17.6.11.2. Para fins de cálculo do volume de serviços, só serão pagos os serviços efetivamente RECEBIDOS DEFINITIVAMENTE pelo CONTRATANTE. Em nenhuma hipótese haverá antecipação ou adiantamento de pagamentos à CONTRATADA.

17.6.12. Critérios para cálculo e aplicação de reduções à remuneração

17.6.12.1. Nas ocorrências de descumprimento de metas dos NÍVEIS DE SERVIÇO os ajustes à remuneração serão apurados em face da aplicação dos respectivos critérios de redução de cada INDICADOR, considerando o afastamento em relação às metas e/ou aos parâmetros estabelecidos e resultando no abatimento de valores financeiros em face da parcela remunerável do serviço.

17.6.12.2. As eventuais reduções à remuneração serão aplicadas até o limite de 20% (vinte por cento) da parcela remunerável (por ORDEM DE SERVIÇO), podendo o CONTRATANTE aplicar acumuladamente outras sanções administrativas cabíveis, quando for o caso, exceto nas situações em que restar comprovado que a CONTRATADA não concorreu de maneira omissiva e/ou comissiva para o não cumprimento do ACORDO DE NÍVEL DE SERVIÇO.

17.6.13. Níveis Mínimos de Serviço para o Ponto de Função (PF)

17.6.13.1. Os NÍVEIS MÍNIMOS DE SERVIÇO (ou NÍVEIS DE SERVIÇO) definem critérios objetivos e mensuráveis cuja finalidade é aferir e avaliar os resultados dos serviços contratados e o desempenho da CONTRATADA., conforme apresentado mais adiante. Neles encontram-se definidos: a maneira pela qual estes fatores serão avaliados; o nível mínimo aceitável; e os descontos a serem aplicados na fatura mensal, quando o serviço prestado não alcançar o nível esperado.

17.6.13.2. Os NÍVEIS DE SERVIÇOS devem ser considerados e entendidos pelas CONTRATADA como um compromisso e comprometimento de qualidade que está assumindo para a prestação dos serviços. Portanto, no decorrer da execução contratual a CONTRATADA deverá monitorar continuamente seus indicadores, zelando pela qualidade dos serviços e pela efetiva entrega de resultados.

17.6.13.3. Eventualmente poderão existir impedimentos técnicos para o atendimento dos prazos previamente estabelecidos para uma demanda ou indicador. Nesses casos, a CONTRATADA deverá notificar formalmente o CONTRATANTE – ficando a critério exclusivo deste último avaliar os impedimentos, assim como acatar ou rejeitar as justificativas apresentadas.

17.6.13.4. As apurações dos INDICADORES de NÍVEIS DE SERVIÇO deverão constar dos RELATÓRIOS DE SERVIÇO fornecidos pelo Sistema de Gestão de Demandas ou outro formato definido pelo CONTRATANTE, onde deverá ser possível verificar a efetividade da prestação dos serviços e permitir a depuração do processo.

17.6.13.5. Durante o período de execução do contrato os serviços estarão sendo avaliados, quanto ao atendimento dos índices estabelecidos, que poderão ser revistos e sofrer adequações e aprimoramentos ao longo do tempo.

17.6.13.6. Às ocorrências de descumprimento do ACORDO DE NÍVEL DE SERVIÇO a CONTRATADA poderá interpor justificativas técnicas embasadas em fatos e circunstâncias objetivas, cabendo ao CONTRATANTE avaliar e decidir sobre as alegações. Quando acatadas as justificativas o CONTRATANTE poderá desconsiderar a(s) ocorrência(s) de descumprimento em questão, ajustar os prazos avaliados ou, ainda, suspender a aplicação de eventuais ajustes, quando for o caso.

17.6.13.7. A interposição de justificativas técnicas deverá ser realizada de forma específica para cada caso concreto, não serão admitidas e nem serão objeto de consideração as justificativas que façam referência às ocorrências, fatos ou circunstâncias de modo genérico.

17.6.13.8. A superação de uma ou mais metas do indicador não poderá ser utilizada para compensar o não atendimento de outras metas no mesmo período e/ou o não atendimento da mesma meta em outro período.

17.6.13.9. A ocorrência de reiteradas falhas no cumprimento de prazos, produtividade e de qualidade dos serviços, caracterizará desídia da CONTRATADA e ensejará a aplicação de penalidades nas modalidades e tipos previstos na Lei nº. 8.666/93, Capítulo IV, Seção II, artigos 86 a 88, que terão natureza de sanção e serão objeto de processo administrativo próprio – garantido o contraditório e a ampla defesa.

17.6.14. Indicadores dos níveis de serviço

17.6.14.1. Os indicadores de nível mínimo de serviço previstos para os serviços do ITEM 1 (PRESTAÇÃO DE SERVIÇOS DE DESENVOLVIMENTO E MANUTENÇÃO DE SOLUÇÕES DE SOFTWARE) são:

17.6.14.2. Índice de pontualidade execução de demandas de desenvolvimento e manutenção de soluções de software.

ÍNDICE DE PONTUALIDADE NA EXECUÇÃO DE DEMANDAS DE DESENVOLVIMENTO E MANUTENÇÃO DE SOLUÇÕES DE SOFTWARE (INS-A.1)
Objetivo	Avaliar a capacidade da CONTRATADA em atender às demandas de desenvolvimento e manutenção de soluções de software de acordo com os prazos contratados, aferindo os prazos executados em cada demanda
Aplicação	Todas as ORDENS DE SERVIÇO (O.S. PLANEJAMENTO E O.S.

ÍNDICE DE PONTUALIDADE NA EXECUÇÃO DE DEMANDAS DE DESENVOLVIMENTO E MANUTENÇÃO DE SOLUÇÕES DE SOFTWARE (INS-A.1)
	DESENVOLVIMENTO), individualmente
Periodicidade	Por ORDEM DE SERVIÇO
Fonte	Sistema de Gestão de Demandas ou outra ferramenta hábil
Fórmula	INS-A.1 = [(PRAZO EXECUTADO / PRAZO CONTRATADO) – 1]
Parâmetros		Níveis de Ajuste
		INS-A.1 (1)	INS-A.1 (2)	INS-A.1 (3)	INS-A.1 (4)
		INS-A.1 < 5%	INS-A.1 ≥5% <25%	INS-A.1 ≥25% <50%	INS-A.1 ≥50% <70%
		ACEITÁVEL (sem aplicação de ajustes)	Redução de 5% (por Ordem de Serviço)	Redução de 10% (por Ordem de Serviço)	Redução de 20% (por Ordem de Serviço)
Aplicação de Advertência: Caso o resultado do INS-A.1 seja ≥ 100% além do ajuste/glosa a CONTRATADA está sujeita a receber a sanção administrativa de ADVERTÊNCIA, sem prejuízo da aplicação de outras sanções caso haja reincidência ou nas demais situações previstas.

Tabela 13: índice de Pontualidade

17.6.14.3. A superação de uma ou mais metas do indicador não poderá ser utilizada para compensar o não atendimento de outras metas no mesmo período e/ou o não atendimento da mesma meta em outro período.

17.6.14.4. Às eventuais ocorrências de descumprimento das metas dos níveis de serviço a CONTRATADA poderá apresentar suas justificativas técnicas, devidamente embasadas em fatos e circunstâncias comprovadas, juntamente com o relatório de serviço. Caberá exclusivamente ao CONTRATANTE avaliar as justificativas, quando apresentadas, podendo efetivar ou suspender a aplicação do(s) ajuste(s) em questão – assim como decidir acerca de outras medidas de gestão contratual cabíveis.

17.6.14.5. Índice de qualidade dos produtos de desenvolvimento e manutenção de soluções de software.

ÍNDICE DE QUALIDADE DOS PRODUTOS DE DESENVOLVIMENTO E MANUTENÇÃO DE SOLUÇÕES DE SOFTWARE (INS-A.2)
Objetivo	Avaliar a qualidade dos produtos de desenvolvimento e manutenção de soluções de software, aferindo o volume de rejeições de cada demanda entregue, independentemente do tipo (requisitos técnicos, negociais, implementação etc.)
Aplicação	Todas as ORDENS DE SERVIÇO (O.S. PLANEJAMENTO E O.S. DESENVOLVIMENTO), individualmente
Periodicidade	Por ORDEM DE SERVIÇO
Fonte	Sistema de Gestão de Demandas ou outra ferramenta hábil
Fórmula	INS-A.2 = Quantidade de rejeições
Parâmetros		Níveis de Ajuste
		INS-A.2 (1)	INS-A.2 (2)	INS-A.2 (3)	INS-A.2 (4)
		INS-A.2 ≤1	INS-A.2 >1 e ≤ 2	INS-A.2 > 2 e ≤5	INS-A.2 > 5
		ACEITÁVEL (sem aplicação de ajustes)	Redução de 5% (por Ordem de Serviço)	Redução de 10% (por Ordem de Serviço)	Redução de 20% (por Ordem de Serviço)
Aplicação de Advertência: Caso o resultado do INS-A.1 seja ≥ 100% além do ajuste/glosa a CONTRATADA está sujeita a receber a sanção administrativa de ADVERTÊNCIA, sem prejuízo da aplicação de outras sanções caso haja reincidência ou nas demais situações previstas.

Tabela 14: índice de Qualidade

17.6.14.6. A superação de uma ou mais metas do indicador não poderá ser utilizada para compensar o não atendimento de outras metas no mesmo período e/ou o não atendimento da mesma meta em outro período.

17.6.14.7. Às eventuais ocorrências de descumprimento das metas dos níveis de serviço a CONTRATADA poderá apresentar suas justificativas técnicas, devidamente embasadas em fatos e circunstâncias comprovadas, juntamente com o relatório de serviço. Caberá exclusivamente ao CONTRATANTE avaliar as justificativas, quando apresentadas, podendo efetivar ou suspender a aplicação do(s) ajuste(s) em questão – assim como decidir acerca de outras medidas de gestão contratual cabíveis.

17.6.15. Níveis Mínimos de Serviço - Item 2 - Sustentação de sistemas e aplicativos mobile

17.6.15.1. O esforço empreendido pela CONTRATADA na prestação dos serviços de desenvolvimento e manutenção de soluções de software será mensurado e remunerado por meio da métrica de PONTO DE FUNÇÃO SUSTENTADO (PFS). Sobre o valor remunerável incidirão eventuais descontos/glosas resultantes de resultados dos indicadores de níveis mínimos de serviço exigidos (NÍVEIS DE SERVIÇO).

17.6.15.2. Tal métrica foi adotada considerando as disposições legais e normativas aplicáveis às contratações públicas de Tecnologia da Informação por órgãos e entidades da Administração Pública Federal, considerando a análise de alternativas realizada no ESTUDO TÉCNICO PRELIMINAR e considerando o disposto na Súmula TCU n° 269, in verbis:

“Nas contratações para a prestação de serviços de tecnologia da informação, a remuneração deve estar vinculada a resultados ou ao atendimento de níveis de serviço, admitindo-se o pagamento por hora trabalhada ou por posto de serviço somente quando as características do objeto não o permitirem, hipótese em que a excepcionalidade deve estar prévia e adequadamente justificada nos respectivos processos administrativos”. [Súmula TCU n° 269]

17.6.15.3. Durante a vigência do CONTRATO, o CONTRATANTE poderá incluir ou excluir soluções de software do seu portfólio. As inclusões poderão ser feitas, por exemplo, à medida que novos sistemas desenvolvidos pela FÁBRICA DE SOFTWARE forem publicados em ambiente de produção e estiverem em uso pelo demandante.

17.6.15.4. Ainda, em atenção ao disposto no Item 3.2 do Anexo da Instrução Normativa 01/2019/SGD/ME, todas as atividades inerentes à sustentação de soluções de software estão incluídas na métrica de pagamento em função dos resultados e produtos entregues, de forma que o CONTRATANTE não efetuará pagamentos adicionais por quaisquer atividades já incluídas no escopo desses serviços.

17.6.15.5. Para os serviços de sustentação de soluções de software (ITEM 2) estão previstos 2 (dois) tipos de ORDENS DE SERVIÇO (O.S.):

a) ORDEM DE SERVIÇO DE SUSTENTAÇÃO MENSAL (O.S. SUSTENTAÇÃO MENSAL); e

b) ORDEM DE SERVIÇO DE SUSTENTAÇÃO SOB DEMANDA (O.S. SUSTENTAÇÃO SOB DEMANDA).

17.6.15.6. É de inteira responsabilidade do CONTRATANTE a gestão da relação dos sistemas que deverão compor a O.S. SUSTENTAÇÃO MENSAL (baseline), a existência da

O.S. SUSTENTAÇAÕ SOB DEMANDA é necessária para dar flexibilidade à essa gestão – sendo considerada exceção ao fluxo principal da sustentação.

17.6.15.7. Os acionamentos dos serviços de sustentação para as soluções de software cobertas pela ORDEM DE SERVIÇO DE SUSTENTAÇÃO MENSAL serão classificados conforme a sua prioridade, de acordo com sua urgência ou impacto, levando em consideração os seguintes parâmetros:

a) A urgência com que as mesmas devem ser resolvidas;

b) O impacto que o não atendimento pode causar ao negócio; e

c) O atendimento prioritário a grupos de usuários com necessidades diferenciadas - usuários VIPs.

17.6.15.8. No que tange às requisições de tratamento de incidentes e manutenção de disponibilidade, estabilidade e desempenho, a classificação e os prazos de atendimento são os seguintes:

Demanda	Prioridade	Enquadramento *	Prazo de Triagem **	Prazo de Solução ***
		Requisição de
Serviços de		serviço relacionada a
sustentação de soluções de	Alta	programas críticos ou com	Até 02:00 hora	Até 08:00 horas
software:		paralisação na
requisições de		solução de
incidentes e		software.
manutenção de		Requisição de
disponibilidade,		serviço sem
estabilidade e desempenho.	Média	paralisação na solução de	Até 04:00 horas	Até 24: horas
		software, mas
		com
		comprometimento

Demanda	Prioridade	Enquadramento *	Prazo de Triagem **	Prazo de Solução ***
		de alguma(s)
		funcionalidade(s).
		Requisição de
		serviço sem
		paralisação na
	Baixa	solução de software e sem	Até 12:00 horas	Até 48:00 horas
		comprometimento
		de funcionalidade
		específicas.
(*) Os tipos de demandas enumerados na tabela são exemplificativos e não esgotam os exemplos de atividades que não estão associadas à funcionalidade de software, os casos omissos serão avaliados pelo CONTRATANTE. (**) Tempo, em horas corridas, decorrido após a comunicação do incidente à CONTRATADA. (***) Tempo, em horas corridas, decorrido após o início do atendimento até a solução da requisição pela CONTRATADA.

Tabela 15: Classificação e Prazos de Atendimento

17.6.15.9. O PRAZO DE TRIAGEM é o tempo necessário para que a CONTRATADA disponibilize o atendimento à demanda com o devido registro da solicitação no sistema de gestão de demandas e/ou adote as medidas de sua competência para iniciar o tratamento da demanda. O PRAZO DE SOLUÇÃO é o tempo máximo para a solução do chamado, contado do momento do registro da solicitação até o fechamento dela no sistema de gestão de demandas da CONTRATANTE. Sendo assim, o TEMPO TOTAL para cada atendimento será o resultado da soma da TRIAGEM e ATENDIMENTO, de acordo com a prioridade.

17.6.15.10. Para os acionamentos dos serviços de sustentação o atendimento deverá ser imediato, não havendo prazo de planejamento e considerando os prazos estabelecidos e os NÍVEIS MÍNIMOS DE SERVIÇO – uma vez que se trata de sistemas em ambiente de produção.

17.6.15.11. Os chamados (requisições/incidentes/solicitações) originados nas áreas de negócio serão encaminhados para a fila de atendimento da CONTRATADA. O CONTRATANTE poderá, a seu critério, fazer a triagem inicial para qualificar as solicitações como manutenção de disponibilidade, estabilidade e desempenho ou intervenção tempestiva ou pontual. Caso essa triagem não seja feita pelo CONTRATANTE, ou por sistema informatizado hábil, será de responsabilidade da CONTRATADA fazê-la.

17.6.15.12. Todos os chamados serão registrados inicialmente com a prioridade MÉDIA e poderão ser reclassificados de acordo com a necessidade do CONTRATANTE. Os chamados originados do grupo de usuários VIP não poderão ser reclassificados pela CONTRATADA, já que serão classificados originalmente de acordo com esse critério de prioridade.

17.6.15.13. A reclassificação de demandas será feita prioritariamente pelo CONTRATANTE, nesse caso, não cabe mudança na prioridade pela CONTRATADA. Caso a reclassificação seja realizada pela CONTRATADA, limitada a uma única reclassificação por demanda, caberá ao CONTRATANTE a realização de auditorias para identificar possíveis desvios.

17.6.15.14. A contagem de prazos de execução de ORDENS DE SERVIÇO DE SUSTENTAÇÃO será interrompida quando fatores externos de domínio do CONTRATANTE impeçam o avanço da execução. Nesses casos, a CONTRATADA deve comunicar, registrar e documentar (prover evidências) formalmente as restrições/impedimentos – cabendo exclusivamente ao CONTRATANTE decidir sobre as justificativas e suspender a contagem de prazos.

17.6.15.15. Para os serviços de garantia, que se dará em toda vigência contratual, as correções de defeitos seguirão os mesmos prazos estabelecidos na tabela acima.

17.6.15.16. Os prazos podem ser eventualmente prorrogados mediante solicitação formal e justificada da CONTRATADA, desde que aceita pelo CONTRATANTE. Caso seja necessário, o CONTRATANTE poderá determinar, de ofício, a prorrogação de algum prazo descrito nos itens mencionados, desde que seja medida de interesse público motivada.

17.6.15.17. A investigação de incidentes pelo serviço de sustentação engloba também avaliação das configurações dos servidores de aplicação e containers (logs, parâmetros e estatísticas), bem como parâmetros e logs do servidor de banco de dados de produção. Quando o diagnóstico do incidente apontar necessidade de intervenção na configuração do

ambiente de infraestrutura (hardware e software) da CONTRATANTE no qual a aplicação se insere, a CONTRATADA deverá indicar quais mudanças contextuais provocaram essa necessidade. Neste caso, a área de infraestrutura de TI da CONTRATANTE analisará as justificativas da CONTRATADA. Caso esteja de acordo, adotará as medidas cabíveis para corrigir o problema. Caso contrário reencaminhará o incidente e o devolverá para o tratamento adequado por parte da CONTRATADA sem que a contagem do tempo de atendimento dos incidentes seja interrompida.

17.6.15.18. A CONTRATADA é responsável por a absorver o conhecimento do negócio e do código-fonte de cada solução sustentada.

17.6.16. Ordens de serviço de sustentação mensal

17.6.16.1. O CONTRATANTE abrirá, a seu critério, ORDENS DE SERVIÇOS DE SUSTENTAÇÃO MENSAL para o serviço de sustentação de soluções de software – constando a relação dos sistemas a serem sustentados e seu respectivo tamanho funcional. Nessa relação poderão ser incluídos, a critério do CONTRATANTE, soluções completas e/ou módulos de soluções.

17.6.16.2. Durante a vigência de uma ORDEM DE SERVIÇO DE SUSTENTAÇÃO MENSAL o CONTRATANTE poderá, a seu critério, promover a inserção de novos sistemas na baseline de sustentação – efetuando a remuneração de forma proporcional aos dias cobertos (pro-rata- die).

17.6.16.3. O tamanho funcional da baseline de sistemas a serem sustentados deverá sempre levar em conta a medida funcional em pontos de função homologada pela CONTRATANTE. O CONTRATANTE não irá remunerar a CONTRATADA retroativamente pelo tamanho funcional do parque de soluções de software. A remuneração será sempre pela tabela mais atualizada informada na ORDEM DE SERVIÇO DE SUSTENTAÇÃO MENSAL.

17.6.16.4. É de responsabilidade da CONTRATADA, sem que isso represente custo adicional ao CONTRATO, a atualização de dados/informações e outras atividades operacionais sobre métricas de software da baseline dos sistemas – incumbindo ao CONTRATANTE administrar e auditar essas informações. Assim, ao final do atendimento de cada ORDEM DE SERVIÇO de Sustentação, Desenvolvimento ou Manutenção caberá à CONTRATADA a análise do impacto da alteração realizada na baseline do sistema impactado, sua atualização e apresentação ao CONTRATANTE para validação.

17.6.16.5. Mensalmente, dentro do escopo do serviço contratado, a CONTRATADA deverá atualizar os registros históricos da prestação de seus serviços e apresentar à CONTRATANTE todas as informações sobre as atividades realizadas durante cada período de faturamento (como RELATÓRIO TÉCNICO), discriminando, pelo menos, a disponibilidade mensal de cada um dos sistemas sustentados, todos os chamados de suporte e incidentes com respectivos tempos de atendimento e as intervenções realizadas no mês.

17.6.16.6. Todos os chamados abertos na vigência de uma ORDEM DE SERVIÇO DE SUSTENTAÇÃO MENSAL devem ser finalizados durante a própria ORDEM DE SERVIÇO, desde que os prazos previstos do chamado não extrapolem sua vigência. Para os chamados com atendimento no final da vigência, o prazo máximo para finalização do atendimento será o próximo ciclo de faturamento (próxima O.S.). Nos casos que não for possível o fechamento, a CONTRATADA deverá justificar o atraso.

17.6.17. Critérios de administração da baseline de sustentação

17.6.17.1. Na última semana de cada mês Grupo de Trabalho composto por representantes do CONTRATANTE revisará a relação de sistemas a serem sustentados mensalmente. Os critérios utilizados para retirada ou inclusão de sistemas levarão em consideração questões técnicas, negociais e sazonais.

17.6.17.2. Considerando o contexto atual em que o CAU/BR não irá renovar o contrato e necessita manter o sistema listado abaixo com melhores métricas que serão inseridas na OS MENSAL DE SUSTENTAÇÃO, já no PERÍODO DE TRANSIÇÃO previsto neste Termo de Referência:

O.S. MÍNIMA DE SUSTENTAÇÃO MENSAL PARA O PERÍODO DE TRANSIÇÃO
Sistema	Tamanho Funcional (PF)
SICCAU CORPORATIVO/PROFISSIONAL	4.500

Tabela 16: OS Mínima Sustentação Mensal

17.6.17.3. A tabela apresentada acima contempla a necessidade mínima de sistemas críticos que apresentam histórico de sustentação. No entanto, novos sistemas podem ser inseridos, conforme a necessidade do CAU/BR e a atualização da baseline.

17.6.17.4. Após o período de transição a OS MENSAL DE SUSTENTAÇÃO poderá ser composta pelos seguintes sistemas:

O.S. DE SUSTENTAÇÃO MENSAL PREVISTA APÓS O PERÍODO DE TRANSIÇÃO
Sistema	Tamanho Funcional (PF)
SICCAU CORPORATIVO/PROFISSIONAL	4.500

Tabela 17: OS Sustentação Mensal

17.6.17.5. A tabela apresentada contempla a necessidade atual de sistemas críticos que apresentam histórico de sustentação. No entanto, sistemas podem ser inseridos ou suprimidos, conforme a necessidade do CAU/BR e a atualização da baseline.

17.6.18. Ordens de serviço de sustentação sob demanda

17.6.18.1. As ORDENS DE SERVIÇO DE SUSTENTAÇÃO SOB DEMANDA consistem na solicitação de serviços de sustentação de soluções de software que não constam na lista de soluções da O.S. DE SUSTENTAÇÃO MENSAL – modalidade que poderá ser acionada pelo CONTRATANTE a seu exclusivo critério e a qualquer tempo, sendo que os serviços solicitados serão detalhados na respectiva ORDEM DE SERVIÇO e devem estar cobertos pelo escopo das atividades contempladas no ITEM 2 desta contratação, consideradas as especificidades de cada solução.

17.6.18.2. Este serviço será remunerado com base no tamanho funcional do escopo da funcionalidade e/ou da solução de SOFTWARE que será sustentada sob demanda OU, no caso de demandas que não estejam relacionadas a uma funcionalidade, será fixado um quantitativo padrão de acordo com a complexidade da demanda e de acordo com a seguinte tabela:

Demanda	Níveis de Complexidade	Tipos de Demanda *	QTDE EM PFS
Serviços de sustentação de soluções de software sob demanda	Alta	Análise e solução de incidentes, apoio à produção, migração de dados, otimização de ambientes e melhorias nos scripts de bancos de dados existentes	20 PFS (por demanda)
	Média	Apuração especial e operação de sistemas	10 PFS (por demanda)
	Baixa	Suporte ao usuário, produção de parecer técnico, atualização de documentação.	5 PFS (por demanda)
(*) Os tipos de demandas enumerados na tabela são exemplificativos e não esgotam os exemplos de atividades que não estão associadas à funcionalidade de software, os casos omissos serão avaliados pelo CONTRATANTE.

Tabela 18: Tamanho Funcional

17.6.19. Modelo de remuneração

17.6.19.1. O FATURAMENTO dos serviços será composto pela soma das duas seguintes formas:

a) Volume de serviços prestados em função da ORDEM DE SERVIÇO DE SUSTENTAÇÃO MENSAL, baseada na baseline de sustentação definida pelo CONTRATANTE, a partir da aplicação da seguinte fórmula:

𝑶𝑺 𝑰𝒕𝒆𝒎 𝟐= [(𝑩𝒂𝒔𝒆𝒍𝒊𝒏𝒆𝑷𝑭× 𝑷𝑭𝑺𝑼𝒏𝒊𝒕á𝒓𝒊𝒐) - 𝑵𝑴𝑺𝑨𝒋𝒖𝒔𝒕𝒆]

OSM Item 2: Remuneração da ORDEM DE SERVIÇO DE SUSTENTAÇÃO MENSAL do Serviço de Sustentação de Soluções de Software.

Baseline PF: Volume funcional das Soluções Sustentadas (em Pontos de Função).

PFS Unitário: Valor unitário do Ponto de Função Sustentado, definido em Contrato para o Item 2. NMS Ajuste: Ajuste (redução/glosa) em função dos resultados dos indicadores de Níveis Mínimos

de Serviço.

b) Volume de serviços prestados em função das ORDENS DE SERVIÇOS DE SUSTENTAÇÃO SOB DEMANDA atendidas pela CONTRATADA, a partir da aplicação da seguinte fórmula:

𝑶𝑺𝑫𝑰𝒕𝒆𝒎 𝟐= [(𝑷𝑭𝑺𝑬𝒙𝒆𝒄𝒖𝒕𝒂𝒅𝒐× 𝑷𝑭𝑺𝑼𝒏𝒊𝒕á𝒓𝒊𝒐) - 𝑵𝑴𝑺𝑨𝒋𝒖𝒔𝒕𝒆]

OSD Item 2: Remuneração da ORDEM DE SERVIÇO DE SUSTENTAÇÃO SOB DEMANDA do

Serviço de Sustentação de Soluções de Software.

PFS Executado: Volume de serviços executados e homologados (em Pontos de Função Sustentados).

PFS Unitário: Valor unitário do Ponto de Função Sustentado, definido em Contrato para o Item 2. NMS Ajuste: Ajuste (redução/glosa) em função dos resultados dos indicadores de Níveis Mínimos

de Serviço.

17.6.19.2. Para fins de cálculo do volume de serviços, só serão considerados para pagamento os serviços RECEBIDOS DEFINITIVAMENTE pelo CONTRATANTE. Em nenhuma hipótese haverá antecipação ou adiantamento de pagamentos à CONTRATADA.

17.6.19.3. Havendo viabilidade técnica e operacional, a critério do CONTRATANTE, poderá ser autorizado o FATURAMENTO CONJUNTO dos serviços – desde que a apuração dos valores ocorra de forma individual, obedecidos os critérios específicos de cada subitem.

17.6.20. Critérios para cálculo e aplicação de reduções à remuneração

17.6.20.1. Nas ocorrências de descumprimento de metas do ACORDO DE NÍVEL DE SERVIÇO os ajustes à remuneração serão apurados em face da aplicação dos respectivos critérios de redução de cada INDICADOR, considerando o afastamento em relação às metas e/ou aos parâmetros estabelecidos e resultando no abatimento de valores financeiros em face da parcela remunerável do serviço.

17.6.20.2. As eventuais reduções à remuneração serão aplicadas até o limite de 20% (vinte por cento) da parcela remunerável (por ORDEM DE SERVIÇO), podendo o CONTRATANTE aplicar acumuladamente outras sanções administrativas cabíveis, quando for o caso, exceto nas situações em que restar comprovado que a CONTRATADA não concorreu de maneira omissiva e/ou comissiva para o não cumprimento do ACORDO DE NÍVEL DE SERVIÇO.

17.6.21. Níveis Mínimos de Serviço PFS

17.6.21.1. Os NÍVEIS MÍNIMOS DE SERVIÇO (ou NÍVEIS DE SERVIÇO) definem critérios objetivos e mensuráveis cuja finalidade é aferir e avaliar os resultados dos serviços contratados e o desempenho da CONTRATADA., conforme apresentado mais adiante. Neles encontram-se definidos: a maneira pela qual estes fatores serão avaliados; o nível mínimo aceitável; e os descontos a serem aplicados na fatura mensal, quando o serviço prestado não alcançar o nível esperado.

17.6.21.2. Os NÍVEIS DE SERVIÇOS devem ser considerados e entendidos pelas CONTRATADA como um compromisso e comprometimento de qualidade que está assumindo para a prestação dos serviços. Portanto, no decorrer da execução contratual a CONTRATADA deverá monitorar continuamente seus indicadores, zelando pela qualidade dos serviços e pela efetiva entrega de resultados.

17.6.21.3. Eventualmente poderão existir impedimentos técnicos para o atendimento dos prazos previamente estabelecidos para uma demanda ou indicador. Nesses casos, a CONTRATADA deverá notificar formalmente o CONTRATANTE – ficando a critério exclusivo deste último avaliar os impedimentos, assim como acatar ou rejeitar as justificativas apresentadas.

17.6.21.4. As apurações dos INDICADORES de NÍVEIS DE SERVIÇO deverão constar dos RELATÓRIOS DE SERVIÇO fornecidos pelo Sistema de Gestão de Demandas ou outro formato definido pelo CONTRATANTE, onde deverá ser possível verificar a efetividade da prestação dos serviços e permitir a depuração do processo.

17.6.21.5. Durante o período de execução do contrato os serviços estarão sendo avaliados, quanto ao atendimento dos índices estabelecidos, que poderão ser revistos e sofrer adequações e aprimoramentos ao longo do tempo.

17.6.21.6. Às ocorrências de descumprimento do ACORDO DE NÍVEL DE SERVIÇO a CONTRATADA poderá interpor justificativas técnicas embasadas em fatos e circunstâncias objetivas, cabendo ao CONTRATANTE avaliar e decidir sobre as alegações. Quanto acatadas as justificativas, o CONTRATANTE poderá desconsiderar a(s) ocorrência(s) de descumprimento em questão, ajustar os prazos avaliados ou, ainda, suspender a aplicação de eventuais ajustes, quando for o caso.

17.6.21.7. A interposição de justificativas técnicas deverá ser realizada de forma específica para cada caso concreto, não serão admitidas e nem serão objeto de consideração as justificativas que façam referência às ocorrências, fatos ou circunstâncias de modo genérico.

17.6.21.8. A superação de uma ou mais metas do indicador não poderá ser utilizada para compensar o não atendimento de outras metas no mesmo período e/ou o não atendimento da mesma meta em outro período.

17.6.21.9. A ocorrência de reiteradas falhas no cumprimento de prazos, produtividade e de qualidade dos serviços, caracterizará desídia da CONTRATADA e ensejará a aplicação de penalidades nas modalidades e tipos previstos na Lei nº. 8.666/93, Capítulo IV, Seção II, artigos 86 a 88, que terão natureza de sanção e serão objeto de processo administrativo próprio – garantido o contraditório e a ampla defesa.

17.6.22. Indicadores de nível de serviço

17.6.22.1. Índice de cumprimento de prazos de sustentação mensal de soluções de software:

ÍNDICE DE CUMPRIMENTO DE PRAZOS DE SUSTENTAÇÃO MENSAL DE SOLUÇÕES DE SOFTWARE (INS-B.1)
Objetivo	Avaliar a capacidade da CONTRATADA em atender aos prazos contratados para os serviços de sustentação de soluções de software, aferindo os prazos executados de acordo com o nível de prioridade das solicitações.
Aplicação	ORDENS DE SERVIÇO DE SUSTENTAÇÃO MENSAL
Periodicidade	Por ORDEM DE SERVIÇO, de acordo com o período de faturamento
Fonte	Sistema de Gestão de Demandas ou outra ferramenta hábil
Fórmula	INS-B.1 = [(Qtde de solicitações atendidas no prazo x 100) / Qtde total de solicitações recebidas]
Parâmetros		Metas
		Para solicitações de Prioridade Alta	Para solicitações de prioridade Média	Para solicitações de prioridade Baixa
		INS-B.1 ≥ 99%	INS-B.1 ≥ 95%	INS-B.1 ≥ 90%
		Atender, no mínimo, 99% das solicitações de prioridade ALTA no prazo	Atender, no mínimo, 95% das solicitações de prioridade MÉDIA no prazo	Atender, no mínimo, 90% das solicitações de prioridade BAIXA no prazo
		Ajuste
		1,00% (um por cento) de redução/glosa a cada 1,00% (um ponto percentual) fora da meta, por parâmetro.
Aplicação de Advertência: Caso o resultado do INS-B.1 seja ≤ 70% para quaisquer dos níveis de prioridade além do ajuste/glosa a CONTRATADA está sujeita a receber a sanção administrativa de ADVERTÊNCIA, sem prejuízo da aplicação de outras sanções caso haja reincidência ou nas demais situações previstas.

Tabela 20: Cumprimento de Prazos de Sustentação Mensal

17.6.22.2. A superação de uma ou mais metas do indicador não poderá ser utilizada para compensar o não atendimento de outras metas no mesmo período e/ou o não atendimento da mesma meta em outro período.

17.6.22.3. Às eventuais ocorrências de descumprimento das metas dos níveis de serviço a CONTRATADA poderá apresentar suas justificativas técnicas, devidamente embasadas em fatos e circunstâncias comprovadas, juntamente com o relatório de serviço. Caberá exclusivamente ao CONTRATANTE avaliar as justificativas, quando apresentadas, podendo efetivar ou suspender a aplicação do(s) ajuste(s) em questão – assim como decidir acerca de outras medidas de gestão contratual cabíveis.

17.6.23. Índice de qualidade das entregas dos serviços de sustentação mensal de soluções de software

ÍNDICE DE QUALIDADE DAS ENTREGAS DE SUSTENTAÇÃO MENSAL DE SOLUÇÕES DE SOFTWARE (INS-B.2)
Objetivo	Avaliar a qualidade dos produtos de sustentação mensal de soluções software, aferindo o volume de rejeições de cada demanda entregue, independentemente do tipo (requisitos técnicos, negociais, implementação etc.)
Aplicação	Todas as ORDENS DE SERVIÇO DE SUSTENTAÇÃO MENSAL homologadas (aceitas)
Periodicidade	Por ORDEM DE SERVIÇO, por período de faturamento
Fonte	Sistema de Gestão de Demandas ou outra ferramenta hábil
Fórmula	INS-B.2 = [(Qtde de Rejeições x 100) / Qtde total de chamados atendidos]
Parâmetros		Níveis de Ajustes
		INS-B.2 (1)	INS-B.2 (2)	INS-B.2 (3)	INS-B.2 (4)	INS-B.2 (5)
		INS-B.2 <5%	INS-B.2 ≥5% e <10%	INS-B.2 ≥10% e < 20%	INS-B.2 ≥20% e <30%	INS-B.2 ≥30%
		ACEITÁVEL (sem aplicação de ajustes)	Redução de 5% (por Ordem de Serviço Mensal)	Redução de 10% (por Ordem de Serviço Mensal)	Redução de 15% (por Ordem de Serviço Mensal)	Redução de 20% (por Ordem de Serviço Mensal)
Aplicação de Advertência: Além da eventual aplicação de ajustes/glosas em função dos resultados dos indicado INS-B.2, caso qualquer chamado apresente individualmente mais de 3 (três) recusas, a CONTRATADA está sujeita a receber a sanção administrativa de ADVERTÊNCIA, sem prejuízo da aplicação de outras sanções caso haja reincidência ou nas demais situações previstas.

Tabela 21: índice de Qualidade de Sustentação Mensal

17.6.23.1. A superação de uma ou mais metas do indicador não poderá ser utilizada para compensar o não atendimento de outras metas no mesmo período e/ou o não atendimento da mesma meta em outro período.

17.6.23.2. Às eventuais ocorrências de descumprimento das metas dos níveis de serviço a CONTRATADA poderá apresentar suas justificativas técnicas, devidamente embasadas em fatos e circunstâncias comprovadas, juntamente com o relatório de serviço. Caberá exclusivamente ao CONTRATANTE avaliar as justificativas, quando apresentadas, podendo efetivar ou suspender a aplicação do(s) ajuste(s) em questão – assim como decidir acerca de outras medidas de gestão contratual cabíveis.

17.6.24. Índice de satisfação do usuário com os serviços de sustentação de soluções de software

ÍNDICE DE SATISFAÇÃO DO USUÁRIO COM OS SERVIÇOS DE SUSTENTAÇÃO DE SOLUÇÕES DE SOFTWARE (INS-B.3)
Objetivo	Avaliar o nível de satisfação dos usuários requisitantes dos serviços de sustentação de soluções de software em relação à percepção da qualidade de serviço entregue pela CONTRATADA.
Aplicação	ORDENS DE SERVIÇO DE SUSTENTAÇÃO MENSAL
Periodicidade	Por ORDEM DE SERVIÇO, em cada período de faturamento
Fonte	Sistema de Gestão de Demandas ou outra ferramenta hábil
Fórmula	INS-B.3 = [(Qtde de Chamados com avaliação insatisfatória x 100) / Qtde total de Chamados Atendidos]
Parâmetros
Aplicação de Advertência: Caso o resultado da aplicação do INS-B.3 seja > 30%, além do ajuste/glosa a CONTRATADA está sujeita a receber a sanção administrativa de ADVERTÊNCIA, sem prejuízo da aplicação de outras sanções caso haja reincidência ou nas demais situações previstas.

INS-B.3 (1)	INS-B.3 (2)	INS-B.3 (3)
INS-B.3 < 10%	INS-B.3 ≥10% e <15%	INS-B.3 ≥15%
ACEITÁVEL (sem aplicação de ajustes)	Redução de 5% [por Ordem de Serviço]	Redução de 10% [por Ordem de Serviço]

Tabela 22: índice de Satisfação do Usuário de Serviços de Sustentação

17.6.24.1. Serão consideradas avaliações INSATISFATÓRIAS as solicitações/requisições com pesquisa preenchida como INSATISFEITO no questionário de avaliação aplicado ao usuário requisitante. Demandas atendidas são aquelas fechadas com avaliação do usuário ou automaticamente pelo Sistema de Gestão de Demandas adotado pelo CONTRATANTE. Caso

o usuário requisitante não tenha avaliado o atendimento dentro do prazo limite máximo definido, será aplicada automaticamente a avalição SATISFEITO.

17.6.24.2. A superação de uma ou mais metas do indicador não poderá ser utilizada para compensar o não atendimento de outras metas no mesmo período e/ou o não atendimento da mesma meta em outro período.

17.6.24.3. Às eventuais ocorrências de descumprimento das metas dos níveis de serviço a CONTRATADA poderá apresentar suas justificativas técnicas, devidamente embasadas em fatos e circunstâncias comprovadas, juntamente com o relatório de serviço. Caberá exclusivamente ao CONTRATANTE avaliar as justificativas, quando apresentadas, podendo efetivar ou suspender a aplicação do(s) ajuste(s) em questão – assim como decidir acerca de outras medidas de gestão contratual cabíveis.

17.6.25. Índice de pontualidade na execução de sustentação de sistemas sob demanda

ÍNDICE DE PONTUALIDADE NA EXECUÇÃO DE SUSTENTAÇÃO DE SOLUÇÕES DE SOFTWARE SOB DEMANDA (INS-C.1)
Objetivo	Avaliar a capacidade da CONTRATADA em atender aos prazos contratados para os serviços de sustentação de soluções de software, aferindo os prazos executados de acordo com o nível de prioridade das solicitações
Aplicação	ORDENS DE SERVIÇO DE SUSTENTAÇÃO SOB DEMANDA
Periodicidade	Por ORDEM DE SERVIÇO, individualmente
Fonte	Sistema de Gestão de Demandas ou outra ferramenta hábil
Fórmula	INS-C.1 = [(ΣTotal de horas de atraso por prioridade) x (% de redução conforme prioridade)]
		Metas
			PARA
		PARA SOLICITAÇÕES	SOLICITAÇÕES DE	PARA SOLICITAÇÕES DE
		DE PRIORIDADE ALTA	PRIORIDADE	PRIORIDADE BAIXA
			MÉDIA
		INS-C.1 < 1:00	INS-C.1 < 1:00	INS-C.1 < 1:00
			Atraso máximo
Parâmetros		Atraso máximo acumulado menor que	acumulado menor que 1:00 para as	Atraso máximo acumulado menor que 1:00 para as
		1:00 para as solicitações	solicitações de	solicitações de prioridade
		de prioridade ALTA	prioridade MÉDIA	BAIXA
		Ajuste	Ajuste	Ajuste
		Redução de 0,20% por hora de atraso acumulada	Redução de 0,10% por hora de atraso acumulada	Redução de 0,05% por hora de atraso acumulada
Aplicação de Advertência: Caso o resultado da aplicação do INS-C.1 seja > 30%, além do ajuste/glosa a CONTRATADA está sujeita a receber a sanção administrativa de ADVERTÊNCIA, sem prejuízo da aplicação de outras sanções caso haja reincidência ou nas demais situações previstas.

Tabela 23: índice de Pontualidade na Execução de Sustentação

17.6.25.1. A superação de uma ou mais metas do indicador não poderá ser utilizada para compensar o não atendimento de outras metas no mesmo período e/ou o não atendimento da mesma meta em outro período.

17.6.25.2. Às eventuais ocorrências de descumprimento das metas dos níveis de serviço a CONTRATADA poderá apresentar suas justificativas técnicas, devidamente embasadas em fatos e circunstâncias comprovadas, juntamente com o relatório de serviço. Caberá exclusivamente ao CONTRATANTE avaliar as justificativas, quando apresentadas, podendo efetivar ou suspender a aplicação do(s) ajuste(s) em questão – assim como decidir acerca de outras medidas de gestão contratual cabíveis.

17.6.26. Índice de qualidade das entregas de sustentação de soluções de software sob demanda

ÍNDICE DE QUALIDADE DAS ENTREGAS DE SUSTENTAÇÃO DE SOLUÇÕES DE SOFTWARE SOB DEMANDA (INS-C.2)
Objetivo	Avaliar a qualidade dos produtos de sustentação de soluções software sob demanda, aferindo o volume de rejeições de cada demanda entregue, independentemente do tipo (requisitos técnicos, negociais, implementação etc.).
Aplicação	Todas as ORDENS DE SERVIÇO DE SUSTENTAÇÃO SOB DEMANDA homologadas (aceitas)
Periodicidade	Por ORDEM DE SERVIÇO, individualmente

ÍNDICE DE QUALIDADE DAS ENTREGAS DE SUSTENTAÇÃO DE SOLUÇÕES DE SOFTWARE SOB DEMANDA (INS-C.2)
Fonte	Sistema de Gestão de Demandas ou outra ferramenta hábil
Fórmula	INS-C.2 = Quantidade de rejeições
Parâmetros
Aplicação de Advertência: Além da eventual aplicação de ajustes/glosas, caso qualquer solicitação apresente individualmente mais de 3 (três) recusas, a CONTRATADA está sujeita a receber a sanção administrativa de ADVERTÊNCIA, sem prejuízo da aplicação de outras sanções caso haja reincidência ou nas demais situações previstas.

Níveis de Ajuste
INS-C.2 = 1	INS-C.2 = 2	INS-C.2 ≥ 3
ACEITÁVEL (sem aplicação de ajustes)	Redução de 10% [por Ordem de Serviço]	Redução de 20% [por Ordem de Serviço]

Tabela 24: índice de Qualidade das Entregas de Sustentação

17.6.26.1. A superação de uma ou mais metas do indicador não poderá ser utilizada para compensar o não atendimento de outras metas no mesmo período e/ou o não atendimento da mesma meta em outro período.

17.6.26.2. Às eventuais ocorrências de descumprimento das metas dos níveis de serviço a CONTRATADA poderá apresentar suas justificativas técnicas, devidamente embasadas em fatos e circunstâncias comprovadas, juntamente com o relatório de serviço. Caberá exclusivamente ao CONTRATANTE avaliar as justificativas, quando apresentadas, podendo efetivar ou suspender a aplicação do(s) ajuste(s) em questão – assim como decidir acerca de outras medidas de gestão contratual cabíveis.

17.6.27. Níveis Mínimos de Serviço - Item 3 - Desenvolvimento de portais

17.6.27.1. Os níveis mínimos de serviço (NMS) para os serviços de desenvolvimento de portais serão aferidos após a entrega final da solução em ambiente de produção ou após a entrega e validação em homologação, a critério do CONTRATANTE.

17.6.27.2. Para os serviços de planejamento e desenvolvimento serão considerados os seguintes indicadores: Indicador de Prazo de Entrega de Portais (IPEP) e Indicador de Qualidade de Portais para o Usuário (IPQU).

17.6.27.3. Indicador de Prazo de Entrega de Portais – IPEP

17.6.27.4. O Indicador de Prazo de Entrega de Portais (IPEP) tem como finalidade a aferição da pontualidade em que os artefatos e código-fonte foram entregues.

17.6.27.5. É dever da CONTRATADA entregar os produtos requisitados conforme os prazos definidos a seguir:

Subitem	Modalidade	Atividade	Praza Dias Corridos / Complexidade
			Baixa	Média	Alta
		1.1 Definir escopo
		inicial de projeto
		1.2 Especificar Requisitos. Documentar objetivos e requisitos de projetos de portais;
1	Planejamento e Projeto de Desenvolvimento	1.3 Especificar Arquitetura de Informação	5	7	12
		1.4 Especificar Identidade Visual. Produzir identidade visual dos portais
		1.5 Especificar Perfis e Permissões de Usuários
		1.6 Especificar Solução Técnica
		1.7 Criar arquitetura da informação para

Subitem	Modalidade	Atividade	Praza Dias Corridos / Complexidade
			Baixa	Média	Alta
		portais
		1.8 Modelar dados para os projetos de portais;
		1.9 Especificar Integração e Implantação
		1.10 Especificar Migração
		2.1 Implementar Arquitetura de Software
		2.2 Implementar Interface. Definir, implementar e customizar temas para portais
2	Desenvolvimento e Implantação	2.3 Implementar Customização. Customizar funcionalidades nativas de ambientes de portais, aquelas já disponíveis	15	20	30
		pela ferramenta
		2.4 Realizar Migração de Conteúdo
		2.5. Realizar transferência de conhecimento e material de suporte. Produzir e organizar os
		documentos relativos
		aos projetos de
		portais

Tabela 25 - Prazos para as atividades de desenvolvimento de portais

17.6.27.6. A complexidade para cada serviço solicitado utilizará os critérios quantidade de atividades requisitadas e quantidade de páginas estáticas criadas ou desenvolvidas no produto.

17.6.27.7. A complexidade será definida conforme tabela a seguir:

Complexidade	Quantidade de Páginas
Quantidade de atividades	1 a 10	11 a 25	>25
1 a 3	BAIXA	BAIXA	MÉDIA
4 a 7	BAIXA	MÉDIA	ALTA
8 a 10	MÉDIA	ALTA	ALTA

Tabela 26 - Definição de Complexidade

Quantidade de atividades: Quantidade de atividades solicitadas para execução do serviço

Quantidade de páginas: Quantidade de páginas criadas ou desenvolvidas no produto

17.6.27.8. Para aferição do Indicador de Prazo de Entrega de Portais (IPEP), aplica-se o seguinte cálculo.

17.6.27.9. Fórmula:

17.6.27.10. Onde:

TempoExecução: quantidade de dias corridos do início da demanda até a entrega dos artefatos e código-fonte.

Prazo: quantidade de dias corridos que foram estimados para a execução da demanda. DataInício: dia em que a demanda iniciou a execução, contando a partir do primeiro dia subsequente.

DataEntrega: dia em que os últimos artefatos da execução da demanda forem entregues e o código-fonte disponibilização para implantação em ambiente de qualidade e/ou homologação. DiasEntrave: quantidade de dias corridos em que a execução da demanda ficou totalmente parada, devido à algum impedimento negocial ou tecnológico que sejam de responsabilidade do CONTRATANTE.

DiasCorreção: quantidade de dias corridos que a CONTRATADA levou para corrigir as entregas, após identificação de falhas nos artefatos e/ou código-fonte.

LTIPEP = 10% (limite tolerável aplicado à fórmula)

17.6.27.11. É de responsabilidade da CONTRATADA indicar e evidenciar os dias em que a demanda ficou parada devido à algum impedimento negocial ou tecnológico, para fins de aferição do IPEP.

17.6.27.12. Indicador de Qualidade de Portais para o Usuário - IQPU

17.6.27.13. Para aferição do Indicador de Qualidade de Portais para o Usuário (IQPU), aplica- se o seguinte cálculo:

17.6.27.14. Fórmula:

17.6.27.15. Onde:

qtdUST = quantidade de UST da demanda QFF = quantidade de falhas funcionais

QFNF = quantidade de falhas não funcionais QFI = quantidade de falhas de interface PesoQFF = 3; PesoQFNF = 2; PesoQFI = 1

LTIQPU = 5% (limite tolerável aplicado à fórmula)

17.6.27.16. No processo de desenvolvimento ou evolução de portais, a identificação de falhas poderá ocorrer em dois momentos distintos: no ateste de qualidade realizada pelo CONTRATANTE ou na homologação do produto, realizada pelo usuário demandante.

17.6.27.17. Em ambos os momentos, se falhas forem identificadas, a entrega será considerada rejeitada, uma vez que não passa no critério de consistência.

17.6.27.18. A quantidade de falhas é cumulativa, independente do momento em que foram identificadas.

17.6.27.19. Para fins deste documento, o termo "falha" refere-se a qualquer não-conformidade com o que foi requisitado, assim como erros e defeitos apresentados pelo sistema ou aplicativo.

17.6.28. Níveis Mínimos de Serviço - Item 4 - Sustentação de portais

17.6.28.1. Os níveis mínimos de serviço (NMS) para os serviços de sustentação de portais serão aferidos após o término do mês de referência para a sustentação.

17.6.28.2. Para os serviços de sustentação serão considerados os seguintes indicadores: Indicador de Prazo para Sustentação de Portais (IPSP) e Indicador de Nível de Satisfação do Usuário (ISU).

17.6.28.3. Os prazos para execução dos serviços de sustentação de portais são aplicados conforme tabela abaixo:

Subitem	Modalidade	Atividade	Prazo
1	Manutenções corretivas e adaptativas	1.1. Correção de bugs ou erros em nível dos recursos visuais, conteúdo web, portlets ou funcionalidades, plug-in, hook e similares. Corrigir e alterar portais em ambiente de produção; Correção de links quebrados.	Crítico: 04 (quatro) horas Não crítico: 08 (oito) horas
		1.2. Ajustes ou correções em figuras, fotos, logomarcas
2	Suporte ao Usuário	2.1. Transferência de conhecimento e esclarecimentos de dúvidas. Treinar moderadores e publicadores de conteúdo.	08 (oito) horas
		2.2. Gerenciar permissões e administrar usuários, grupos, workflow e papéis;
		2.3. Publicação de informes, imagens, banners, ícones, links ou vídeos nos portais	04 (quatro) horas
3	Suporte na Administração	2.4. Configurar portais (alterar títulos, configurar o editor visual, plugins, configurar regras de conteúdo, etc.);	08 (oito) horas
		2.5. Atualizar versões do CMS e seus plugins;	40 (quarenta) horas
		2.6. Apoiar na restauração de backup	12 (doze) horas
		2.7. Apoiar na administração e manutenção dos Portais. Auxiliar as equipes de suporte na implantação do portal em ambiente de homologação e produção, de forma a garantir a disponibilidade e a continuidade da operação destes portais.	08 (oito) horas
		2.8. Aplicação de layout de acordo com a Identidade Padrão de Comunicação Digital do Governo Federal em ambiente e conteúdo pré- existente

Tabela 27 - Prazos para as atividades de sustentação de portais

17.6.28.4. Para aferição do Indicador de Prazo para Sustentação, aplica-se o seguinte cálculo:

17.6.28.5. Fórmula:

17.6.28.6. Onde:

chamados: quantidade de chamados abertos para sustentação.

corretivas: quantidade de chamados categorizados como manutenções corretivas. corretivasFP: quantidade de chamados de manutenções corretivas encerradas fora do prazo admitido.

outrosChamados: quantidade de chamados categorizados como suporte ao usuário ou suporte na administração.

outrosChamadosFP: quantidade de chamados de suporte ao usuário e suporte na administração encerrados fora do prazo admitido.

pesocorretivas = 7; pesooutros = 3

LTIPS = 5% (limite tolerável aplicado à fórmula)

17.6.28.7. O IPSP deverá ser aferido em um período mensal definido a partir do início do contrato.

17.6.28.8. Os quantitativos utilizados na fórmula para aferição devem considerar apenas os chamados concluídos no período do mês de referência, independente se o chamado foi aberto naquele mês.

17.6.29. Indicador de Nível de Satisfação do Usuário - ISU

17.6.29.1. Para a aferição do Indicador de Nível de Satisfação do Usuário para os serviços de sustentação de portais, segue a aferição abaixo:

17.6.29.2. Para aferição do Indicador de Nível de Satisfação do Usuário, será utilizada uma analogia à metodologia NPS (Net Promoter Score), a qual utiliza escalas para mensurar a satisfação do usuário.

17.6.29.3. O cálculo considerará uma escala variável, a critério do CONTRATANTE, conforme a ferramenta que será utilizada para avaliação.

17.6.29.4. A escala poderá variar de inúmeras formas, mas sempre manterá uma proporção para fins de cálculo. Em uma escala crescente, considera-se a seguinte proporção:

• Avaliações negativas: 60% primeiros níveis;

• Avaliações neutras: 20% dos níveis logo após as avaliações negativas; e

• Avaliações positivas: 20% dos últimos níveis da escala.

17.6.29.5. Para esclarecer a divisão da escala, a imagem abaixo utiliza como exemplo uma escala de 1 a 10:

17.6.29.6. No exemplo acima, foi utilizado a escala 1 a 10, mas outras escalas poderão ser utilizadas, desde que as proporções 60/20/20 sejam mantidas, como por exemplo: escala 1 a 5, escala nominal [horrível, ruim, regular, bom, ótimo], etc.

17.6.29.7. Conforme prega a metodologia NPS, o cálculo para aferição considerará apenas as avaliações negativas e positivas.

17.6.29.8. Para aferição do Indicador de Nível de Satisfação do Usuário, aplica-se o seguinte cálculo:

17.6.29.9. Fórmula:

17.6.29.10. A tabela a seguir especifica as faixas de classificação para o valor do ISU, e o respectivo ajuste do nível mínimo de serviço:

Faixa de valor para o resultado do ISU	Acréscimo no valor final do Ajuste NMS
Maior ou igual a 50%	n/a
Maior ou igual a 40% e menor que 50%	5%
Maior ou igual a 30% e menor que 40%	7,5%
Maior ou igual a 20% e menor que 30%	10%
Menor que 20%	15%

Tabela 28 - Faixas de classificação para o valor do ISU e ajuste do nível mínimo de serviço

17.6.29.11. O ISU deverá ser aferido em um período mensal definido a partir do início do contrato.

17.6.29.12. Os quantitativos utilizados na fórmula para aferição do ISU devem considerar apenas os chamados avaliados durante o mês de referência, independente se o chamado foi aberto naquele mês.

17.7. Prazo de Atendimento

17.7.1. Os serviços deverão ser iniciados de acordo com os prazos estabelecidos a seguir:

Projeto, Sustentação (exceto manutenção corretiva) e Serviço
Tamanho do serviço em Pontos de Função	Prazo máximo para início do serviço (em dias úteis)
1 a 49	2 dias
50 a 149	5 dias

150 a 500	7 dias
Acima de 500	15 dias

Tabela 29 – Prazo de Atendimento Projetos / Sustentação

Sustentação (Manutenção Corretiva)
Criticidade	Característica	Início de Atendimento
Nível 1	Incidente com paralisação do sistema ou comprometimento grave de dados, processo ou ambiente.	Em até 06 (seis) horas corridas após informado o incidente / paralisação à CONTRATADA.
Nível 2	Incidente sem paralisação do sistema, porém, com comprometimento mediano de dados, processo ou ambiente.	Em até 24 (vinte e quatro) horas corridas após informado o incidente/paralisação à CONTRATADA.
Nível 3	Incidente sem paralisação do sistema e pequeno ou nenhum comprometimento de dados, processo ou ambiente.	Em até 72 (setenta e duas) horas corridas após informado o incidente/paralisação à CONTRATADA.

Tabela 29 – Prazo de Atendimento Sustentação

17.7.2. Prazos de Atendimento Projeto e Sustentação;

17.7.2.1. Para demanda maior ou igual a 100 PF; Cálculo do Prazo (mês) = V^t*21 (dias úteis); Onde:

V: tamanho do projeto em Pontos de Função. t: 0,32

17.7.2.2. Para demanda menor que 100 PF

Tamanho do Projeto	Prazo máximo (em dias úteis)
Até 4 PF	5 dias
4 a 8 PF	10 dias
8 a 10 PF	13 dias
11 a 20 PF	25 dias
21 a 30 PF	37 dias
31 a 40 PF	50 dias
41 a 50 PF	62 dias
51 a 60 PF	75 dias
61 a 70 PF	82 dias
71 a 85 PF	90 dias
91 a 99 PF	99 dias

Tabela 30 – Demanda Ponto de Função

17.7.2.3. A empresa CONTRATADA poderá solicitar, ainda, um prazo adicional, quando justificada e comprovada a necessidade, em função de complexidade do serviço a ser executado, ficando a critério do CAU/BR, aceitar ou não as justificativas e o novo prazo apresentado pela empresa CONTRATADA.

17.7.2.4. O prazo adicional deverá ser solicitado em até, no máximo, 1 (um) dia útil após o recebimento da OS e, no caso de aceito pelo CAU/BR, será adicionado ao prazo total do serviço ou projeto contratado;

17.7.2.5. Caso a justificativa não atenda ao CAU/BR, prevalecerá o prazo inicialmente estipulado;

17.7.2.6. A solicitação de prazo adicional para atendimento não justifica a suspensão do atendimento pela empresa CONTRATADA e, durante o julgamento da solicitação pelo CAU/BR, ficam mantidas as condições estipuladas para o serviço;

17.7.2.7. Caso o prazo de execução proposto pela empresa CONTRATADA não atenda às necessidades do CAU/BR novos prazos poderão ser apresentados.

17.8. Estimativa de volume de bens/serviços

17.8.1. Após avaliação baseada em levantamento dos sistemas de informação em utilização no CAU/BR e a necessidade de novos sistemas de informação, bem como a definição determinada pelo Colegiado de Governança do CSC, a estimativa de Pontos de Função previstos para a execução em 12 (doze) meses é de em média 3.500 (três e quinhentos mil).

17.8.2. Toda a documentação está prevista nas etapas acima descritas, sem ônus adicional ao CAU/BR.

17.8.3. A remuneração dos serviços demandados considerará os percentuais (%) de esforços executados.

17.8.4. Para cada ponto de função das demandas do tipo “Serviço”, quando não mensuráveis pela técnica de Análise em Pontos de Função pelo “Roteiro de Métrica de Software” do SISP

v.2.2 (ou superior) (xxxx://xxx.xxxxxxxxxxxxxxxxx.xxx.xx) e o “Function Point Counting Practices Manual (CPM)”, versão 4.3.1 (ou superior), deverá ser considerada e equivalência do ponto de função com o esforço de desenvolvimento conforme abaixo:

Equivalência do Ponto de Função para o esforço de desenvolvimento das demandas do tipo “Serviço”
Demandas do tipo “Serviço”	Equivalência de Esforço (produtividade)
01 um) Ponto de Função de Serviço	(07 sete) horas

Tabela 31 – Equivalência do Ponto de Função

17.8.5. Toda a documentação para a demanda do tipo “Serviço” deverá estar prevista no esforço (produtividade) indicado para sua execução.

17.8.6. Para cada Ponto de Função (PF) sua equivalência de esforço (produtividade) em horas é de 07 (sete) horas, o cálculo das frações obedecerá ao que segue.

17.8.6.1. Para cálculo do pagamento das demandas do tipo “Serviço”:

a) Caso o Serviço esteja contemplado no Roteiro de Métricas do SISP v 2.2 (ou superior), considerar a fórmula existente neste Roteiro;

b) Para os casos não tratados no Roteiro de Métricas do SISP v 2.2 (ou superior), considerar a seguinte fórmula:

Equivalência em PF = (Esforço da Atividade (H)/7) * Valor do PF de Serviço

17.9. Prazos e Condições

17.9.1. O prazo máximo para entrega dos serviços será o previsto no item 17.7 deste Termo de Referência;

17.9.2. O objeto do contrato deverá ser disponibilizado no ambiente do CAU/BR, com todos os artefatos previstos, no prazo pactuado e será recebido da seguinte forma:

a) Provisoriamente: até 15 (quinze) dias após o ato de entrega, para efeito de posterior verificação da conformidade da demanda com o requisitado na Ordem de Serviço;

b) Definitivamente: 5 (cinco) dias úteis para as demandas com prazo de entrega previsto em até 20 dias (úteis) e nas demais em até 25% do prazo de entrega (contados em dia útil) a partir do recebimento provisório (TRP) e após a verificação da qualidade e quantidade do material e sua consequente aceitação, mediante a emissão do Termo de Recebimento Definitivo assinado pelas partes.

17.9.3. Os problemas identificados nas demandas serão formalmente informados ao preposto, considerando todas as exigências deste Termo de Referência (técnicas e recebimento). A empresa CONTRATADA será notificada a proceder à devida regularização ou correção das demandas não aceitas pelo CAU/BR, e deverá iniciar as correções em prazo não superior a 5 (cinco) dias corridos, contados da notificação da rejeição.

17.9.4. Somente após a verificação da compatibilidade entre o objeto contratado e o executado, bem como a qualidade e a integridade dos serviços prestados, o CAU/BR emitirá o Termo de Recebimento Definitivo (TRD).

17.9.5. Para o recebimento definitivo das demandas, além da verificação da conformidade com a MGDS-CAU, serão consideradas as metas alcançadas dos níveis de serviço IDP e IP;

17.9.6. O recebimento provisório ou definitivo não exclui a responsabilidade civil pela solidez e segurança do serviço, nem a ético-profissional pela perfeita execução do contrato, dentro dos limites estabelecidos pela lei.

CAPÍTULO 18. DO PAGAMENTO

18.1. O pagamento será efetuado pela CONTRATANTE no prazo máximo de 10 (dez) dias úteis, contados do atesto da Nota Fiscal/Fatura.

18.2. Os pagamentos serão realizados após a apresentação do documento fiscal exigível em conformidade com a legislação de regência e com eles as informações sobre o banco, agência e número da conta corrente da CONTRATADA.

18.2.1. A CONTRATADA deverá encaminhar o documento fiscal exigível, discriminando todas as importâncias devidas, correspondentes aos serviços efetivamente prestados.

18.2.2. O documento fiscal referido no subitem 17.1 deverá destacar as retenções previstas na Instrução Normativa RFB nº 1.234, de 11 de janeiro de 2012 e demais legislações pertinentes. A retenção também será realizada nos moldes da Lei Complementar nº 116/2003 e outras legislações de regência.

18.2.3. Na hipótese de a CONTRATADA ser optante do Simples, a fim de fazer incidir a não retenção de tributos, conforme art. 4º, XI, da Instrução Normativa RFB nº 1.234/2012, deverá anexar à fatura declaração devidamente assinada por seu representante legal, sob as penas da lei.

18.3. Recebido o documento fiscal exigível, o CAU/BR providenciará sua aferição e, após aceitação dos serviços prestados, efetuará o pagamento no prazo de 10 (dez) dias úteis, contados do atesto da respectiva nota fiscal/fatura.

18.4. O atraso no pagamento do documento fiscal emitido, desde que a CONTRATADA não tenha concorrido de alguma forma para tanto, sujeitará o CAU/BR ao pagamento de juros moratório de 0,5% (cinco décimos por cento) ao mês, até o efetivo pagamento, além da devida atualização monetária.

18.5. O CAU/BR reserva-se no direito de não efetuar o pagamento se, no ato da atestação, a prestação dos serviços não atender as situações descritas neste Termo de Referência, inclusive no caso de a CONTRATADA deixar de apresentar a documentação de regularidade fiscal para com o Fundo de Garantia por Tempo de Serviço, Instituto Nacional do Seguro Social, as Fazendas Públicas Federal, Estadual ou do Distrito Federal e Municipal, e regularidade trabalhista.

18.6. O CAU/BR não pagará qualquer valor não constante ou fora dos critérios estabelecidos neste Termo de Referência.

18.7. Nenhum pagamento será efetuado à CONTRATADA enquanto pendente de liquidação qualquer obrigação financeira em virtude de penalidade ou inadimplência contratual, sem que isso gere direito à alteração dos preços, ou de compensação financeira por atraso de pagamento. O CAU/BR poderá deduzir do montante a pagar os valores correspondentes a multas ou indenizações devidas pela CONTRATADA, conforme este Termo de Referência.

18.8. Havendo erro na emissão do documento de cobrança ou circunstância que impeça a liquidação da despesa, como rasuras, entrelinhas, ou falta de algum dos documentos, a nota fiscal/fatura será devolvida à CONTRATADA e o pagamento ficará pendente até que sejam sanados os problemas.

18.8.1. Nesta hipótese, o prazo para pagamento será reiniciado após a regularização da situação ou reapresentação dos documentos, não acarretando quaisquer ônus para o CAU/BR.

18.9. A simples existência da relação contratual sem a contraprestação do serviço não enseja nenhum pagamento à CONTRATADA.

18.10. O CAU/BR não se responsabilizará pelo pagamento de quaisquer serviços realizados sem a solicitação e autorização do fiscal do contrato.

18.11. Nos casos de eventuais atrasos de pagamento, desde que a Contratada não tenha concorrido, de alguma forma, para tanto, fica convencionado que a taxa de compensação financeira devida pela Contratante, entre a data do vencimento e o efetivo adimplemento da parcela é calculada mediante a aplicação da seguinte fórmula:

EM = I x N x VP, sendo:

EM = Encargos moratórios;

N = Número de dias entre a data prevista para o pagamento e a do efetivo pagamento;

VP = Valor da parcela a ser paga.

I = Índice de compensação financeira = 0,00016438, assim apurado:

I = (TX) I = ( 6 / 100 ) I = 0,00016438 TX = Percentual da taxa anual = 6%

CAPÍTULO 19. REAJUSTE

19.1. Decorrido o prazo de 12 (doze) meses da data da apresentação da proposta, poderá a CONTRATADA fazer jus ao reajuste do valor contratual que deverá retratar a variação efetiva do custo de produção ou dos insumos utilizados na consecução do objeto contratual, limitado pelo Índice Nacional de Preços ao Consumidor (INPC), na forma do que dispõem o art. 40, XI, da Lei nº 8.666, de 1993 e os art. 2º e 3º da Lei nº 10.192, de 2001.

19.2. Os reajustes deverão ser precedidos de solicitação da CONTRATADA.

19.3. A CONTRATADA poderá exercer, perante o CONTRATANTE, seu direito ao reajuste dos preços do contrato até a data da prorrogação contratual subsequente.

19.3.1. Caso a CONTRATADA não solicite tempestivamente o reajuste e prorrogue o contrato sem pleiteá-lo, ocorrerá a preclusão do direito de reajustar.

19.4. O CONTRATANTE deverá assegurar-se de que os preços contratados são compatíveis com aqueles praticados no mercado, de forma a garantir a continuidade da contratação mais vantajosa.

CAPÍTULO 20. GARANTIA DA EXECUÇÃO

20.1. A inobservância do prazo fixado para apresentação da garantia acarretará a aplicação de multa de 0,07% (sete centésimos por cento) do valor total do contrato por dia de atraso, até o máximo de 2% (dois por cento).

20.1.1. O atraso superior a 25 (vinte e cinco) dias autoriza a Administração a promover a rescisão do contrato por descumprimento ou cumprimento irregular de suas cláusulas, conforme dispõem os incisos I e II do art. 78 da Lei n. 8.666 de 1993.

20.1.2. A validade da garantia, qualquer que seja a modalidade escolhida, deverá abranger um período de 90 dias após o término da vigência contratual, conforme item 3.1 do Anexo VII-F da IN SEGES/MP nº 5/2017.

20.2. A garantia assegurará, qualquer que seja a modalidade escolhida, o pagamento de:

20.2.1. prejuízos advindos do não cumprimento do objeto do contrato e do não adimplemento das demais obrigações nele previstas;

20.2.2. prejuízos diretos causados à Administração decorrentes de culpa ou dolo durante a execução do contrato;

20.2.1.1. multas moratórias e punitivas aplicadas pela Administração à contratada; e

20.1.3. obrigações trabalhistas e previdenciárias de qualquer natureza e para com o FGTS, não adimplidas pela contratada, quando couber.

20.1.4. A modalidade seguro-garantia somente será aceita se contemplar todos os eventos indicados no item anterior, observada a legislação que rege a matéria.

20.1.4.1. A garantia em dinheiro deverá ser efetuada em favor da Contratante, em conta específica na Caixa Econômica Federal, com correção monetária.

20.1.4.2. Caso a opção seja por utilizar títulos da dívida pública, estes devem ter sido emitidos sob a forma escritural, mediante registro em sistema centralizado de liquidação e de custódia autorizado pelo Banco Central do Brasil, e avaliados pelos seus valores econômicos, conforme definido pelo Ministério da Fazenda.

20.1.4.3. No caso de garantia na modalidade de fiança bancária, deverá constar expressa renúncia do fiador aos benefícios do artigo 827 do Código Civil.

20.1.4.4. No caso de alteração do valor do contrato, ou prorrogação de sua vigência, a garantia deverá ser ajustada à nova situação ou renovada, seguindo os mesmos parâmetros utilizados quando da contratação.

20.1.4.5. Se o valor da garantia for utilizado total ou parcialmente em pagamento de qualquer obrigação, a Contratada obriga-se a fazer a respectiva reposição no prazo máximo de 30 (trinta) dias úteis, contados da data em que for notificada.

20.1.4.6. A Contratante executará a garantia na forma prevista na legislação que rege a matéria.

20.1.5. Será considerada extinta a garantia:

20.1.5.1. com a devolução da apólice, carta fiança ou autorização para o levantamento de importâncias depositadas em dinheiro a título de garantia, acompanhada de declaração da Contratante, mediante termo circunstanciado, de que a Contratada cumpriu todas as cláusulas do contrato;

20.1.5.2. no prazo de 90 (noventa) dias após o término da vigência do contrato, caso a Administração não comunique a ocorrência de sinistros, quando o prazo será ampliado, nos termos da comunicação, conforme estabelecido na alínea "h2"do item 3.1 do Anexo VII-F da IN SEGES/MP n. 05/2017.

20.1.5.3. O garantidor não é parte para figurar em processo administrativo instaurado pela contratante com o objetivo de apurar prejuízos e/ou aplicar sanções à contratada.

20.1.5.4. A contratada autoriza a contratante a reter, a qualquer tempo, a garantia, na forma prevista no neste Edital e no Contrato.

CAPÍTULO 21. DAS SANÇÕES E PENALIDADES

21.1. Comete infração administrativa nos termos da Lei nº 10.520, de 2002, a CONTRATADA que:

21.1.1. inexecutar total ou parcialmente qualquer das obrigações assumidas em decorrência da contratação;

21.1.2. ensejar o retardamento da execução do objeto;

21.1.3. falhar ou fraudar na execução do contrato;

21.1.4. comportar-se de modo inidôneo; ou

21.1.5. cometer fraude fiscal.

21.2. Pela inexecução total ou parcial do objeto deste contrato, a Administração pode aplicar à CONTRATADA as seguintes sanções:

21.2.1. Advertência por escrito, quando do não cumprimento de quaisquer das obrigações contratuais consideradas faltas leves, assim entendidas aquelas que não acarretam prejuízos significativos para o serviço contratado;

21.2.2. Multa de:

21.2.2.1. 0,1% (um décimo por cento) até 0,2% (dois décimos por cento) por dia sobre o valor adjudicado em caso de atraso na execução dos serviços, limitada a incidência a 15 (quinze) dias. Após o décimo quinto dia e a critério da Administração, no caso de execução com atraso, poderá ocorrer a não-aceitação do objeto, de forma a configurar, nessa hipótese, inexecução total da obrigação assumida, sem prejuízo da rescisão unilateral da avença;

21.2.2.2. 0,1% (um décimo por cento) até 10% (dez por cento) sobre o valor adjudicado, em caso de atraso na execução do objeto, por período superior ao previsto no subitem acima, ou de inexecução parcial da obrigação assumida;

21.2.2.3. 0,1% (um décimo por cento) até 15% (quinze por cento) sobre o valor adjudicado, em caso de inexecução total da obrigação assumida;

21.2.2.4. 0,2% a 3,2% por dia sobre o valor mensal do contrato, conforme detalhamento constante das tabelas 1 e 2, abaixo; e

21.2.2.5. 0,07% (sete centésimos por cento) do valor do contrato por dia de atraso na apresentação da garantia (seja para reforço ou por ocasião de prorrogação), observado o máximo de 2% (dois por cento). O atraso superior a 25 (vinte e cinco) dias autorizará a Administração CONTRATANTE a promover a rescisão do contrato;

21.2.2.6. as penalidades de multa decorrentes de fatos diversos serão consideradas independentes entre si.

21.2.3. Suspensão de licitar e impedimento de contratar com o órgão, entidade ou unidade administrativa pela qual a Administração Pública opera e atua concretamente, pelo prazo de até dois anos;

21.2.4. Sanção de impedimento de licitar e contratar com órgãos e entidades da União, com o consequente descredenciamento no SICAF pelo prazo de até cinco anos

21.2.4.1. A Sanção de impedimento de licitar e contratar prevista neste subitem também é aplicável em quaisquer das hipóteses previstas como infração administrativa no subitem 19.1 deste Termo de Referência.

21.2.5. Declaração de inidoneidade para licitar ou contratar com a Administração Pública, enquanto perdurarem os motivos determinantes da punição ou até que seja promovida a reabilitação perante a própria autoridade que aplicou a penalidade, que será concedida sempre que a Contratada ressarcir a Contratante pelos prejuízos causados;

21.3. As sanções previstas nos subitens 19.1.1 e 19.1.2 poderão ser aplicadas à CONTRATADA juntamente com as de multa, descontando-a dos pagamentos a serem efetuados.

21.4. Para efeito de aplicação de multas, às infrações são atribuídos graus, de acordo com as tabelas 1 e 2:

Tabela 1

GRAU	CORRESPONDÊNCIA
1	0,2% ao dia sobre o valor mensal do contrato
2	0,4% ao dia sobre o valor mensal do contrato
3	0,8% ao dia sobre o valor mensal do contrato
4	1,6% ao dia sobre o valor mensal do contrato
5	3,2% ao dia sobre o valor mensal do contrato

Tabela 2

INFRAÇÃO
ITEM	DESCRIÇÃO	GRAU
1	Permitir situação que crie a possibilidade de causar dano físico, lesão corporal ou consequências letais, por ocorrência;	05

INFRAÇÃO
2	Suspender ou interromper, salvo motivo de força maior ou caso fortuito, os serviços contratuais por dia e por unidade de atendimento;	04
3	Manter funcionário sem qualificação para executar os serviços contratados, por empregado e por dia;	03
4	Recusar-se a executar serviço determinado pela fiscalização, por serviço e por dia;	02
5	Retirar funcionários ou encarregados do serviço durante o expediente, sem a anuência prévia do CONTRATANTE, por empregado e por dia;	03
Para os itens a seguir, deixar de:
6	Registrar e controlar, diariamente, a assiduidade e a pontualidade de seu pessoal, por funcionário e por dia;	01
7	Cumprir determinação formal ou instrução complementar do órgão fiscalizador, por ocorrência;	02
8	Substituir empregado que se conduza de modo inconveniente ou não atenda às necessidades do serviço, por funcionário e por dia;	01
9	Cumprir quaisquer dos itens do Edital e seus Anexos não previstos nesta tabela de multas, após reincidência formalmente notificada pelo órgão fiscalizador, por item e por ocorrência;	03
10	Indicar e manter durante a execução do contrato os prepostos previstos no edital/contrato;	01
11	Providenciar treinamento para seus funcionários conforme previsto na relação de obrigações da CONTRATADA	01

21.5. Também ficam sujeitas às penalidades do art. 87, III e IV da Lei nº 8.666, de 1993, as empresas ou profissionais que:

21.5.1. tenham sofrido condenação definitiva por praticar, por meio dolosos, fraude fiscal no recolhimento de quaisquer tributos;

21.5.2. tenham praticado atos ilícitos visando a frustrar os objetivos da licitação;

21.5.3. demonstrem não possuir idoneidade para contratar com a Administração em virtude de atos ilícitos praticados.

21.6. A aplicação de qualquer das penalidades previstas realizar-se-á em processo administrativo que assegurará o contraditório e a ampla defesa à CONTRATADA, observando-se o procedimento previsto na Lei nº 8.666, de 1993, e subsidiariamente a Lei nº 9.784, de 1999.

21.7. As multas devidas e/ou prejuízos causados à Contratante serão deduzidos dos valores a serem pagos, ou recolhidos em favor da União, ou deduzidos da garantia, ou ainda, quando for o caso, serão inscritos na Dívida Ativa da União e cobrados judicialmente.

21.7.1. Caso a Contratante determine, a multa deverá ser recolhida no prazo máximo de 10 (dez) dias, a contar da data do recebimento da comunicação enviada pela autoridade competente.

21.8. Caso o valor da multa não seja suficiente para cobrir os prejuízos causados pela conduta do licitante, a União ou Entidade poderá cobrar o valor remanescente judicialmente, conforme artigo 419 do Código Civil.

21.9. A autoridade competente, na aplicação das sanções, levará em consideração a gravidade da conduta do infrator, o caráter educativo da pena, bem como o dano causado à Administração, observado o princípio da proporcionalidade.

21.10. Se, durante o processo de aplicação de penalidade, se houver indícios de prática de infração administrativa tipificada pela Lei nº 12.846, de 1º de agosto de 2013, como ato lesivo à administração pública nacional ou estrangeira, cópias do processo administrativo necessárias à apuração da responsabilidade da empresa deverão ser remetidas à autoridade competente, com despacho fundamentado, para ciência e decisão sobre a eventual instauração de investigação preliminar ou Processo Administrativo de Responsabilização - PAR.

21.11. A apuração e o julgamento das demais infrações administrativas não consideradas como ato lesivo à Administração Pública nacional ou estrangeira nos termos da Lei nº 12.846, de 1º de agosto de 2013, seguirão seu rito normal na unidade administrativa.

21.12. O processamento do PAR não interfere no seguimento regular dos processos administrativos específicos para apuração da ocorrência de danos e prejuízos à Administração Pública Federal resultantes de ato lesivo cometido por pessoa jurídica, com ou sem a participação de agente público.

21.13. As penalidades serão obrigatoriamente registradas no SICAF.

CAPÍTULO 22. CONTRATADA QUALIFICAÇÃO

22.1. As empresas, deverão comprovar a qualificação técnica, por meio de Atestados de Capacidade Técnica expedido por pessoa jurídica de direito público ou privado, comprovando que a Licitante executou serviços de desenvolvimento e manutenção de sistemas, de forma satisfatória com aplicação de Nível Mínimo de Serviços (NMS), com transferência de conhecimento, em um período de 12 (doze) meses consecutivos.

22.2. Os Atestados deverão conter, a tabela a seguir (quantas forem necessárias) com informações dos projetos executados:

Tipo de Informação	Conteúdo
1.Informações da Empresa Licitante	Nome comercial/ CNPJ/Endereço
2. Identificação do Projeto/Sistema.	Nome do Projeto/Sistema.
3. Tamanho do Projeto/Sistema.	Tamanho em Pontos de Função.
4. Consumo do Projeto/Sistema.	Quantidade de Pontos de Função efetivamente consumidos pelo projeto/sistema.
5.Qualificação dos serviços que retrate o bom atendimento na execução do objeto.	Descrever a qualificação dos serviços prestados, que qualifique o bom atendimento na execução do objeto, detalhando todas as atividades realizadas.
6. Plataforma Tecnológica.	Descrição da linguagem e SGBD utilizados.
7. Período de realização do(s) serviço(s).	Mês/ano de início e fim do(s) serviço(s).
8. Informações sobre o uso do modelo.	Constando a informação sobre o uso do regime de Fábrica de Software.

Tipo de Informação	Conteúdo
9. Descrição sucinta do(s) projeto(s).	Constando a identificação dos projetos, com descrições sucintas, contendo as etapas de Ciclo de Desenvolvimento/Manutenção executadas e a utilização de metodologia formal.
10. Dados do responsável pelas informações.	Nome / E-mail / Telefone do responsável pelos contatos técnicos do cliente (pessoa vinculada ao cliente responsável pelos contatos relativos ao projeto).
11. Informações da Empresa/Órgão Público que emitiu o atestado e assinatura.	Nome comercial / CNPJ / Endereço / Telefone e E-mail da empresa privada / Órgão Público e cargo ocupado pelo signatário do atestado.

Tabela 32: Documentação Contratual

22.3. O(s) Atestado(s) de Capacidade Técnica deverão indicar a quantidade de Pontos de Função ou Unidade de Serviço Técnico realizadas pela licitante em qualquer período consecutivo de 12 (doze) meses, em data não anterior há 48 meses da realização do certame.

22.4. A exigência de 12 meses consecutivos visa evitar que o somatório de atestados acumulados durante um longo período de tempo atinja o quantitativo exigido sem, no entanto, comprovar a capacidade logística e operacional da CONTRATADA em executar o volume de serviço previsto.

22.5. Trata-se de dimensionamento de prazo relacionada à comprovação da capacidade de execução do objeto, aceita como legítima pelo Tribunal de Contas da União conforme Acórdão nº 2.048/2006 -Plenário e Acórdão nº 1.287/2008 – Plenário.

22.6. Um atestado poderá comprovar mais de uma experiência exigida. Será(ão) considerado(s) apenas o(s) atestado(s) apresentado(s) relacionado(s) à prestação de serviços compatíveis ao objeto ora contratado.

22.7. Os atestados de capacidade técnica, documentações e comprovações necessárias para que a Administração comprove a veracidade das informações deverão conferir com o CNPJ da empresa Licitante.

22.8. O pregoeiro poderá solicitar os documentos originais não-digitais quando oportuno ou conveniente para resguardar a integridade do procedimento licitatório.

22.9. Os documentos que não puderem ser apresentados por motivos de sigilo, deverão ser apresentados, em síntese, com indicação dos requisitos exigidos e serão verificados por meio de diligência.

22.10. Não serão aceitos atestados de capacidade técnica contendo cópias exatas das exigências deste Termo de Referência no lugar da especificação clara e inequívoca dos serviços que foram ou que estão sendo prestados pela Licitante.

22.11. No caso de atestados emitidos por empresa da iniciativa privada, não serão considerados válidos aqueles emitidos por empresas pertencentes ao mesmo grupo empresarial da Licitante.

22.12. Serão consideradas como pertencentes ao mesmo grupo empresarial as empresas controladas ou controladoras da empresa Licitante, e ainda as que tenham pelo menos uma pessoa física ou jurídica como sócia em comum.

22.13. Caso a licitante classificada, provisoriamente, em primeiro lugar apresente preço inferior a 70% (setenta por cento) do valor total estimado para a contratação, essa terá que demonstrar a exequibilidade de seus preços, apresentando a seguinte documentação complementar:

a) Contrato ou contratos medidos por pontos de função e regidos por níveis de serviço, acompanhados de notas fiscais e declaração do tomador dos serviços que comprovem a execução satisfatória de serviços similares aos previstos, com preço unitário do ponto de função igual ou inferior ao ofertado pelo licitante;

b) Registros ou evidências que comprovem a adoção de processos de desenvolvimento aderentes à norma ISO NBR 15.504, compatíveis com os níveis de maturidade CMM-3 ou CMMi-Dev 3 ou XXX.Xx nível C, na localidade em que foi prevista a realização da parcela mais significativa das atividades de desenvolvimento.

22.14. Admite-se mais de um atestado com vistas a comprovar o atendimento a todos os requisitos de capacidade técnica que asseguram a similaridade do objeto.

22.15. Os atestados referir-se-ão a contratos já concluídos ou já decorrido no mínimo um ano do início de sua execução, exceto se houver sido firmado para ser executado em prazo inferior, apenas aceito mediante a apresentação do contrato.

22.16. Os atestados deverão referir-se a serviços prestados no âmbito de sua atividade econômica principal ou secundária especificadas no contrato social vigente.

22.17. O licitante disponibilizará todas as informações necessárias à comprovação da legitimidade dos atestados apresentados, apresentando, dentre outros documentos, cópia do contrato que deu suporte à contratação, endereço atual da contratante e local em que foram prestados os serviços.

22.18. Para o total dos pontos de função atestados, destinados à comprovação da qualificação técnica, será permitido o cômputo de pontos de função em contratos/clientes distintos, desde que executados num mesmo período consecutivo de 12 (doze) meses.

22.19. A contagem de pontos de função dos atestados deve ser baseada na técnica de Análise de Ponto de Função (APF) do International Function Point Users‟ Group (IFPUG), realizada por especialista certificado em Ponto de Função CFPS (Certified Function Point Specialist) pelo IFPUG, com certificação válida no período da contagem.

22.20. Conforme previsto na Lei 8.666, no art. 43 § 3° e em consonância com as orientações e determinações do Tribunal de Contas da União, os Atestados de Capacidade Técnica apresentados serão objeto de diligência para verificação de autenticidade de seu conteúdo, momento em que serão solicitados ao emitente dos atestados documentos e evidências que descrevam e comprovem a execução dos serviços ali declarados.

22.21. A recusa do emitente do atestado em prestar esclarecimentos, informações, fornece documentos comprobatórios, etc., desconstituirá o atestado de capacidade técnica e poderá configurar prática de falsidade ideológica, ensejando comunicação ao Ministério Público Federal e abertura de Processo Administrativo Disciplinar, para fins de apuração de responsabilidade, em atendimento aos termos do Acórdão nº. 1724/2010-Plenário:

Recomendar ao Ministério da Educação que preveja expressamente, em seus futuros Instrumentos convocatórios para aquisição de bens e serviços de TI, possibilidades de aplicação de sanções no que tange à apresentação de atestados de capacidade técnica incompatíveis com o objeto do certame, buscando, de antemão, inibir a participação de empresas que não satisfaçam as condições editalícias e/ou interfiram negativamente no normal andamento de qualquer ato da licitação.

22.22. O processo de diligenciar, além de absolutamente regular e legalmente prevista, vem recebendo do TCU reiteradas recomendações no sentido de que seja aplicada, a exemplo dos julgados que transcrevemos com os nossos destaques:

ACÓRDÃO Nº 0747-10/11-P

(xxxxx://xxxxxx.xxx.xxx.xx/xxxxxxxxxxxxx/XxxxxxXxxxxxxxx?xxxx(X C-0747-10/11-P)%5bNUMD%5d%5bB001%5d)

9.1. conhecer da presente representação, com amparo no art. 113, § 1º, da Lei nº 8.666, de 21 de junho de 1993, e art. 237, inciso VII, do Regimento Interno do TCU, para, no mérito, considerá-la improcedente;

[PROPOSTA DE DELIBERAÇÃO]

3. Por meio do expediente de fls. 1/47 (peça 1), aponta a representante, em suma, as seguintes irregularidades:

[...]

3.3. a diligência realizada pela pregoeira, no intuito de aclarar informações referentes ao atestado de capacidade técnica apresentado pela [licitante omissis], teria permitido a obtenção de dados que deveriam constar originariamente da proposta;

3.4. os requisitos de qualificação técnica não teriam sido comprovados, mesmo após as diligências realizadas;

[...]

3. Por meio do expediente de fls. 1/47 (peça 1), aponta a representante, em suma, as seguintes irregularidades:

[...]

3.3. a diligência realizada pela pregoeira, no intuito de aclarar informações referentes ao atestado de capacidade técnica apresentado pela [licitante omissis], teria permitido a obtenção dedados que deveriam constar originariamente da proposta;

3.4. os requisitos de qualificação técnica não teriam sido comprovados, mesmo após as diligências realizadas;

[...]

ACÓRDÃO Nº 4827-32/09-2

9.6. determinar:

9.6.1. à Coordenação-Geral de Logística e Administração do MDS – CGLA que:

9.6.1.9. atente à possibilidade de promoção de diligência pela comissão ou autoridade superior, em qualquer fase da licitação, para esclarecer ou complementar a instrução do processo licitatório, vedada a inclusão posterior de documento ou informação que deveria constar originariamente da proposta, em conformidade com o § 3º do art. 43 da Lei 8.666/1993;

ACÓRDÃO Nº. 5857-37/09-1

9.5. determinar, com fulcro no art. 18 da Lei nº 8.443/1992, à CORE/FUNASA/MS que:

[...]

9.5.3 nas licitações que executar, promova, sempre que necessário, diligência destinada a esclarecer ou a complementar a instrução do processo, nos termos do art. 43, § 3°, da Lei 8.666/93, de preferência, previamente à execução dos atos de homologação e adjudicação do objeto da licitação;

22.23. No processo de diligência serão colhidas evidências que comprovem a capacidade técnica, tais como: relatórios, registros de reunião, impressão das telas dos aplicativos e sistemas, documentação de projetos (planejamento de projeto, planos de gestão, documentos de requisitos, diagramas, especificações técnicas, padrões, dentre outros) para a devida comprovação dos serviços atestados.

22.24. Serão buscadas, ainda, evidências da utilização de melhores práticas de Governança de TI alinhadas a Gerenciamento de Projetos, Desenvolvimento de Software e Segurança da Informação (PMBOK, ITIL v.3, CMMI, MPSBR, COBIT5, ISO/IEC 27002, ISO/IEC 27001, ISO/IEC 20000, ISO/IEC 15504, ISO/IEC 12207, ISO/IEC 9196 ou equivalentes), conforme tabela a seguir:

Processos utilizados na prestação dos serviços	Anexar Documentos comprobatórios (relatórios, registros de reunião, impressão das telas dos aplicativos e sistemas)
Gerenciamento do Escopo	Descrição do processo de Gerenciamento do Escopo. Implementação das práticas de: Planejamento do escopo. Detalhamento do escopo. Verificação do escopo. Rastreabilidade de Requisitos Controle de mudanças do escopo.
Gerenciamento de Riscos	Descrição do processo de Gerenciamento de Riscos. Implementação das práticas de: Planejamento do gerenciamento dos riscos. Identificação dos riscos. Análise qualitativa dos riscos. Planejamento de resposta aos riscos.
Revisões Técnicas	Implementação das práticas de: Planejamento das Revisões Técnicas. Execução das revisões técnicas

Processos utilizados na prestação dos serviços	Anexar Documentos comprobatórios (relatórios, registros de reunião, impressão das telas dos aplicativos e sistemas)
	Acompanhamento das revisões técnicas.
Implantação	Descrição do processo de Implantação Documentos: Manual ou Guia de Implantação; Registros de transferência de conhecimento Termos homologação e Aceite do Produto
Manutenção	Descrição do processo de Manutenção: Evidências: Procedimentos de manutenção Avaliação de indicadores de desempenho Registros de atualização de versões decorrentes de manutenção

Tabela 33: Gerenciamento de Serviços

22.25. A volumetria a ser comprovada encontra-se aderente às orientações do Tribunal de Contas da União, consagrada a partir de 2003, consoante Acórdão 1.284/2003-Plenário e outros julgados os quais transcrevemos:

Acórdão 1949/2008-Plenário

[...]

ACORDAM os Ministros do Tribunal de Contas da União, reunidos em Sessão Plenária, ante as razões expostas pelo Relator, em:

[...]

9.2. determinar à Prefeitura Municipal de Xxxxxxx xx Xxxxxxx (MT) que, nas próximas licitações e contratações custeadas com recursos federais:

[..]

9.2.4. para fins de comprovação da qualificação técnica dos licitantes, abstenha-se de estabelecer percentuais mínimos acima de 50% dos quantitativos dos itens de maior relevância da obra ou serviço, salvo em casos excepcionais, devidamente justificados no processo administrativo relativo à licitação, previamente à publicação do respectivo edital, ou no próprio edital e em seus anexos, em observância ao disposto nos arts. 37, XXI, da Constituição Federal; 3º, § 1º, I, e 30, II, da Lei nº 8.666/1993;

Acórdão 717/2010-Plenário

[...]

ACORDAM os Ministros do Tribunal de Contas da União, reunidos em sessão de Plenário, ante as razões expostas pelo Relator, em:

[ ...]

9.3. determinar ao Ministério do Trabalho e Emprego que:

9.3.1. abstenha-se de estabelecer, em futuros editais de licitação, como requisito de qualificação técnico-operacional, percentuais mínimos acima de 50% dos quantitativos dos itens de maior relevância da obra ou serviço, salvo em casos excepcionais, cujas justificativas para tal extrapolação deverão estar tecnicamente explicitadas, ou no processo licitatório, previamente ao lançamento do respectivo edital, ou no próprio edital e seus anexos, em observância ao inciso XXI do art. 37 da Constituição Federal, ao inciso I do § 1º do art. 3º e inciso II do art. 30 da Lei 8.666/93 e à jurisprudência deste Tribunal, estabelecida a partir do Acórdão 1284/2003-TCU - Plenário;

Acórdão 1.432/2010-Plenário

[...]

ACORDAM os Ministros do Tribunal de Contas da União, reunidos em Sessão do Plenário, ante as razões expostas pelo Relator, em:

[...]

9.8. determinar ao Governo do Estado do Tocantins que, nas futuras licitações, envolvendo a aplicação de verbas federais,

limite as exigências de atestados de capacidade técnico- operacional aos mínimos que garantam a qualificação técnica das empresas para a execução das obras objeto do processo licitatório, devendo absterse de estabelecer exigências excessivas, que possam restringir indevidamente a competitividade dos certames, a exemplo da comprovação de experiência em percentual superior a 50% (cinquenta por cento) dos quantitativos a executar, cumprindo o que prescreve o art. 37 da Constituição Federal e o art. 3º da Lei nº 8.666/1993;

Acórdão 1695/2011-Plenário

ACORDAM os Ministros do Tribunal de Contas da União, reunidos em Sessão do Plenário, ante as razões expostas pelo Relator, em:

9.3. determinar à Secex/SP que:

[...]

9.4. realize as diligências necessárias para identificar os responsáveis pelas seguintes irregularidades, referentes à restrição ao caráter competitivo e infringência ao princípio da isonomia, insculpido no art. 37, caput, da Constituição Federal; promovendo, posteriormente, as devidas audiências:

[...]

9.4.4 - exigência excessiva de apresentação de atestados, por parte das licitantes, comprovando a execução de, no mínimo, 437,63 TR num único contrato, tendo em vista que, no Senac Tiradentes, unidade que exige maior qualificação técnica, são necessários apenas 213,8 TR, sendo suficiente que, em consonância com o entendimento deste Tribunal, a participante do certame demonstre ter capacidade para executar 50% dos serviços exigidos na unidade de Tiradentes, ou seja, 106 TR, vez que a exigência de comprovação da qualificação técnica deve ser pertinente e compatível com o objeto da licitação ou da contratação direta e indispensável ao cumprimento do objeto (destacamos)

22.26. Requisitos de capacidade técnica, através de Atestados para o GRUPO 1, deverão comprovar que a Licitante:

a) executou serviços de desenvolvimento e manutenção de sistemas, de forma satisfatória com aplicação de Níveis Mínimos de Serviço (NMS), com transferência de conhecimento, em um período de 12 (doze) meses consecutivos.

b) executou pelo menos 2.500 (dois mil e quinhentos) Pontos de Função em serviços de desenvolvimento ou manutenção de software em plataforma web, utilizando a linguagem PHP com framework com suporte ao modelo de três camadas (Model, View e Controller).

c) executou pelo menos 2.500 (dois mil e quinhentos) Pontos de Função em serviços de desenvolvimento ou manutenção de software em plataforma web, utilizando a linguagem Java, com framework com suporte ao modelo de três camadas (Model, View e Controller).

d) executou pelo menos 500 (quinhentos) Pontos de Função em serviços de desenvolvimento ou manutenção de software em plataforma web, utilizando a plataforma .NET, realizados em qualquer período consecutivo de doze meses.

e) desenvolveu aplicações e softwares em qualquer linguagem integrado com solução de geoprocessamento, utilizando qualquer banco de dados com suporte a dados espaciais.

f) desenvolveu e entregou pelo menos um sistema novo, de volume funcional igual ou superior a 800 (oitocentos) Pontos de Função, com a aceitação do produto pela empresa/órgão/entidade que a contratou.

g) implementou software com autenticação de usuários em serviço de diretório, como Open Lightweight Directory Access Protocol (OpenLDAP) ou Active Directory (AD).

h) implementou software ou serviços com a arquitetura SOA (Service Oriented Architecture) para a implementação de web services, por SOAP (Simple Object Access Protocol) ou REST (Representational State Transfer).

i) realizou testes unitários, de integração e de segurança nos softwares desenvolvidos ou manutenidos.

j) executou atividades de: elicitação de requisitos, análise, projeto, codificação, testes, documentação, implantação, configuração e treinamento.

k) prestou serviços de desenvolvimento e manutenção evolutiva e corretiva de portais ou sítios de pessoas jurídicas de direito público ou privado, e que tenha utilizado os Sistemas de Gerenciamento de Conteúdo (CMS) Joomla! ou Wordpress e linguagem de programação PHP; e

l) tem experiência na utilização de sistema para controle das demandas de desenvolvimento ou manutenção de sistemas, em período ininterrupto de um ano, e com o registro de, pelo menos, 150 (cento e cinquenta) registros diferentes de Ordens de Serviço na sua base de dados. Forma de comprovação: Por meio de consultas, relatórios e gráficos gerados pela ferramenta, com funcionalidades conforme item 7.6.1.6 deste Termo de Referência.

22.26.1 Para fins de comprovação, com vistas a permitir a comparação e somatório de atestados, também serão considerados atestados referentes a serviços executados pela modalidade de ponto de função ou por Unidade de Serviço Técnico. Nestes casos, devem ser considerados para fins de conversão, a proporção de 1 (um) ponto de função para 7 (sete) UST.

22.27. A Contratada apresentará, sob as penas da lei, na assinatura do contrato, certificação vigente e expedida por instituição devidamente qualificada e autorizada:

a) Certificado de Maturidade de Processos Capability Maturity Model (CMM) nível 3 ou superior; ou

b) Certificado de Maturidade de Processo Capability Maturity Model Integrator (CMMI) nível 3 ou superior; ou

c) Certificado do Programa de Melhoria de Processo do Software Brasileiro (MPS-Br) nível “C” ou superior.

22.27.1 A comprovação deste item, no caso do CMMI-Dev, se dará por meio de cópia autenticada do certificado emitido por uma agência certificadora independente (agências credenciadas pelo Software Engineering te - xxxx://xxx.xxx.xxx.xxx) ou seu representante no Brasil. Para a certificação MPS/BR, a comprovação se dará por meio de cópia autenticada do certificado de qualidade MPS-BR emitido pela SOFTEX ou parceiro autorizado.

22.27.3. O CMMI é um modelo criado pelo SEI (Software Engineering Institute) para ser um guia destinado a melhorar os processos organizacionais e as habilidades desses em gerenciar o desenvolvimento, a aquisição e a manutenção de sistemas. O CMMI organiza as práticas, que já são consideradas efetivas, em uma estrutura que visa auxiliar a organização a estabelecer prioridades para melhoria e também fornece um guia para a implementação dessas melhorias.

22.27.4. A adoção do modelo CMMI como ferramenta no gerenciamento de projetos de software é muito comentada e requisitada, inclusive na administração pública. Todos os requisitos deste Padrão Internacional são genéricos e planejados para serem aplicáveis a todas as organizações, não importando tipo, tamanho ou produtos providos.

22.27.5. Sua aplicabilidade advém da necessidade de que a estrutura organizacional Contratada esteja orientada a processos de qualidade em conformidade com os padrões internacionais, reduzindo os riscos e contribuindo para um processo de desenvolvimento mais eficiente e seguro.

22.27.6. Da mesma forma, cada nível de maturidade do MPS/BR possui suas áreas de processo, onde são analisados os processos fundamentais (gerência de requisitos, desenvolvimento de requisitos, solução técnica, instalação e liberação do produto, entre outros), processos organizacionais (gerência de projeto, análise de decisão e resolução, gerência de riscos, avaliação, melhoria e definição do processo organizacional gerência quantitativa do projeto, análise e resolução de causas, entre outros) e os processos de apoio (garantia de qualidade, gerência de configuração, validação, medição, verificação, treinamento).

22.27.7. O nível de maturidade comprovado através da certificação CMM/CMMI nível 3 ou MPS-Br nível “C” significa que os processos da Contratada certificada são bem caracterizados e compreendidos e são descritos em padrões, procedimentos, ferramentas e métodos. O conjunto de processos padronizados da Contratada, que é a base para o nível 3 de maturidade, é definido e aprimorado continuamente. Esses processos padronizados são utilizados para estabelecer consistência através da empresa. Em níveis inferiores de maturidade, inclusive no nível 2, os padrões, descrições de processos e procedimentos podem ser bem diferentes em cada instância particular do processo (por exemplo, num projeto específico). No nível 3 de maturidade, os padrões, descrições de processos e procedimentos para um projeto são adaptados do conjunto de processos padrão da empresa para se adequarem ao projeto ou unidade organizacional, sendo, por isso, mais consistentes.

22.27.8. Não obstante, o TCU já entendeu ser plenamente possível incluir exigência de apresentação da certificação no momento da assinatura do contrato, vejamos:

(ACÓRDÃO 3663/2013 – PLENÁRIO)

“VISTOS, relatados e discutidos estes autos da Representação formulada pela empresa Sigma Dataserv Informática S/A, com fundamento no artigo 113, § 1º, da Lei n. 8.666/1993, contra o Pregão Eletrônico n. 5/2013, promovido pela Secretaria de Economia e Finanças – SEF, do Comando do Exército, destinado à contratação de serviços de desenvolvimento e manutenção de sistemas de informação.

ACORDAM os Ministros do Tribunal de Contas da União, reunidos em Sessão Extraordinária do Plenário, ante as razões expostas pelo Relator, em:

(...)

9.4. dar ciência à Secretaria de Economia e Finanças do Comando do Exército de que a exigência de certificados (CMMI, XXX.XX) não é admitida pela jurisprudência majoritária deste Tribunal, na fase de habilitação; entretanto, tais certificados podem ser exigidos, na fase de execução contratual, com a devida justificativa, nas condições previstas no Acórdão 5736/2011-1ªC; outrossim é lícita a inclusão, na especificação técnica dos serviços a serem realizados, dos resultados esperados, segundo modelos de qualidade de processo, tais como CMMI ou XXX.XX;”

22.27.9. Ainda em julgado mais recente, o TCU assim se manifestou no (ACÓRDÃO Nº 2300/2015 – PLENÁRIO):

“Considerando as conclusões da Sefti (peça nº 67) de que: (a) não procede a alegada incongruência entre os itens 10.2.1.2 e

10.10.2 do Termo de Referência, uma vez que as exigências de certificação de maturidade de processos no CMMI nível 3 ou similar (item 10.2.1.2) e de atestado de capacidade técnica (item 10.10.2) são independentes e o fato de uma empresa atender a um dos itens não garante que também atenda ao outro;

(b) diversos julgados do TCU admitem a exigência de apresentação de certificado de maturidade de processos CMMI nível 3, XXX.XX nível C ou similar (item 10.2.1.2) , como condição para assinatura de contrato, desde que devidamente justificada e desde que o órgão contratante demonstre que se encontra apto a avaliar, técnica e qualitativamente, os artefatos e produtos gerados pela contratada, não procedendo a afirmativa quanto a ser pacífico o entendimento desta Casa em relação a tal requisito somente poder ser admitido para efeito de pontuação em regimes de técnica ou técnica e preço; (c) o CAU/BR justificou a exigência como forma de evitar a repetição de problemas enfrentados por aquele Conselho com a antiga prestadora, destacando a unidade técnica os indicativos de que os serviços licitados no PE 1/2014 estão sendo desenvolvidos pela atual contratada conforme as expectativas do ente contratante;

(...)

ACORDAM os Ministros do Tribunal de Contas da União, reunidos em Sessão de Plenário, por unanimidade, em:

a) com fundamento no § 1º do art. 113 da Lei 8.666/1993 e no inc. VII do art. 237 do Regimento Interno desta Casa, conhecer da presente Representação, por preencher os requisitos de admissibilidade, para, no mérito, considerá-la improcedente;”

22.27.10. Registre-se por fim que a Secretaria de Fiscalização de Tecnologia da Informação do TCU expediu e publicou a Nota Técnica/SEFTI/TCU nº. 05/2010, versão 1.0. Dentre os entendimentos ali consagrados destacamos:

Entendimento III. É vedada a exigência de avaliação (ou “certificado”) de qualidade de processo de software, a exemplo de CMMI ou XXX.XX, como requisito para habilitação em licitação, por ausência de previsão legal, por implicar em despesas anteriores à contratação e desnecessárias à competição e por ferir a isonomia, restringindo injustificadamente a competição

22.28. Requisitos de Capacitação e Experiência dos Profissionais

22.28.1. Requisitos da metodologia de trabalho

22.28.1.1. A metodologia de trabalho tem como principal referência, além das disposições descritas neste TERMO DE REFERÊNCIA e dos requisitos específicos do ITEM 1, o processo de desenvolvimento de software do CONTRATANTE (MGDS-CAU) que define os fluxos de trabalho, os prazos de entrega, os entregáveis mínimos, a documentação de referência e os demais padrões de projeto aplicáveis – incumbindo à CONTRATADA executá-lo e ao

22.28.1.2. Devido ao seu caráter intrinsecamente dinâmico, os documentos de referência da metodologia de trabalho poderão ser revisados a qualquer tempo pelo CONTRATANTE durante a execução contratual, sendo dever da CONTRATADA adaptar-se às mudanças –

podendo o CONTRATANTE, a seu critério e conforme a necessidade do processo, definir e aplicar período de transição para implementação das eventuais alterações.

22.29 Requisitos de experiência profissional e formação das equipes

22.29.1. A CONTRATADA deverá disponibilizar EQUIPES DE DESENVOLVIMENTO, por MATRIZ DE NEGÓCIO para a execução do ITEM 1 (Serviços de desenvolvimento e manutenção de soluções de software), da seguinte forma:

OBJETO	MATRIZ DE NEGÓCIO	QTDE MÍNIMA DE EQUIPES*
Serviços de desenvolvimento e manutenção de soluções de software (GRUPO 1)	Sistema de Informação e Comunicação do CAU – SICCAU	01 (uma) Equipe
(*) O quantitativo mínimo de equipes por matriz de negócio é apenas um referencial mínimo e poderá ser revisto pelo CONTRATANTE, a seu critério, e/ou ampliado pela CONTRATADA de acordo com o volume de demandas e a capacidade produtiva das equipes.

Tabela 34: Matriz de Negócios

22.29.2. Cada EQUIPE DE DESENVOLVIMENTO deverá ser composta, no mínimo, pelos seguintes PERFIS PROFISSIONAIS:

EQUIPE	PERFIS MÍNIMOS	QTDE MÍNIMA*
EQUIPE DE DESENVOLVIMENTO	ARQUITETO DE SOFTWARE/ SCRUM MASTER	01 (um) Profissional
	ANALISTA DE REQUISITOS	01 (um) Profissional
	ENGENHEIRO DE SOFTWARE / DESENVOLVEDOR	01 (um) Profissional
(*) O quantitativo mínimo de profissionais por equipe é apenas um referencial mínimo e poderá ser revisto pelo CONTRATANTE, a seu critério, e/ou ampliado pela CONTRATADA de acordo com o volume de demandas e a capacidade produtiva das equipes.

Tabela 35: Equipe de Desenvolvimento

22.29.3. Os profissionais diretamente envolvidos na prestação dos serviços deverão atender aos requisitos definidos a seguir, por PERFIL PROFISSIONAL:

a) Para a GERÊNCIA TÉCNICA:

PERFIL	PREPOSTO / GERENTE TÉCNICO DE DESENVOLVIMENTO
FORMAÇÃO:	Nível Superior completo na área de Tecnologia da Informação com diploma fornecido por instituição de ensino superior reconhecido pelo Ministério da Educação OU nível superior em qualquer área de formação com pós-graduação (especialização, mestrado ou doutorado) na área de Tecnologia da Informação em curso com carga horária mínima de 360 horas, reconhecido pelo MEC.
CONHECIMENTOS:	Conhecimentos sólidos das melhores práticas de mercado em desenvolvimento de software (ISO 9000:2000, PMBoK, ISO 17799, ISO 20000, XXX 00000, XXX 9126, CMMI, XXX.Xx, ITIL, COBIT, Governança de TI).
EXPERIÊNCIA:	Experiência comprovada de, pelo menos, 05 (cinco) anos em coordenação de projetos de Tecnologia da Informação.
CERTIFICAÇÕES TÉCNICAS:	Certificação Project Management Professional (PMP) emitido pelo Project Management Institute (PMI) OU Certificação Ágil (PSM, CSM, ASF, SFC, ACP ou outra similar).

Tabela 36: Preposto / Gerente Técnico

b) Para as EQUIPES DE DESENVOLVIMENTO:

PERFIL	ARQUITETO DE SOFTWARE / SCRUM MASTER
FORMAÇÃO:	Nível Superior completo na área de Tecnologia da Informação com diploma fornecido por instituição de ensino superior reconhecido pelo Ministério da Educação OU nível superior em qualquer área de formação com pós-graduação (especialização, mestrado ou doutorado) na área de Tecnologia da Informação em curso com carga horária mínima de 360 horas, reconhecido pelo MEC.
CONHECIMENTOS:	Deve possuir conhecimentos sólidos em metodologias ágeis.

PERFIL	ARQUITETO DE SOFTWARE / SCRUM MASTER
EXPERIÊNCIA:	Experiência comprovada de, pelo menos, 03 (três) anos no papel de Scrum Master.
CERTIFICAÇÕES TÉCNICAS:	Certificação Ágil (PSM, CSM, ASF, SFC, ACP), ou equivalente, no mínimo.

Tabela 38: Analista de Requisitos

Tabela 37: Arquiteto de Softwares / Scrum Master

PERFIL	ANALISTA DE REQUISITOS
FORMAÇÃO:	Nível Superior completo na área de Tecnologia da Informação com diploma fornecido por instituição de ensino superior reconhecido pelo Ministério da Educação OU nível superior em qualquer área de formação com pós-graduação (especialização, mestrado ou doutorado) na área de Tecnologia da Informação em curso com carga horária mínima de 360 horas, reconhecido pelo MEC.
CONHECIMENTOS:	Deve possuir conhecimento sólidos em engenharia de requisitos de software.
EXPERIÊNCIA:	Experiência comprovada de, pelo menos, 03 (três) anos em Análise de Requisitos, especificamente em projetos de desenvolvimento e de manutenção de software. Sendo, no mínimo, 01 (um) ano de experiência em projetos com metodologias ágeis.
CERTIFICAÇÕES TÉCNICAS:	Certificação CPRE (Certified Professional for Requirements Engineering) Foundation Level, ou equivalente, no mínimo.

PERFIL	ENGENHEIRO DE SOFTWARE
FORMAÇÃO:	Nível Superior completo na área de Tecnologia da Informação com diploma fornecido por instituição de ensino superior reconhecido pelo Ministério da Educação OU nível superior em qualquer área de formação com pós-graduação (especialização, mestrado ou doutorado) na área de Tecnologia da Informação em curso com carga horária mínima de 360 horas, reconhecido pelo MEC.
CONHECIMENTOS:	Deve possuir conhecimentos sólidos em engenharia de soluções de software, programação em plataformas PHP e testes de software.
EXPERIÊNCIA:	Experiência comprovada de, pelo menos, 03 (três) anos em desenvolvimento de software em linguagem PHP e experiência em testes unitários de software.
CERTIFICAÇÕES TÉCNICAS:	Não há exigências específicas.

Tabela 39: Engenheiro de Software

22.29.4. Ainda quanto às EQUIPES DE DESENVOLVIMENTO, fica estabelecido - Na forma do disposto no item 11.7.2 do TERMO DE REFERÊNCIA – que o dimensionamento da(s) equipe(s) é de inteira responsabilidade da CONTRATADA; considerando a estimativa de demandas do serviço, a produtividade adequada, o atendimento aos prazos estabelecidos e os requisitos de qualidade a serem atendidos e que, de acordo com a especificidade de cada projeto, poderão ser alocados outros perfis profissionais adequados, tais como, para atendimento às demandas de desenvolvimento e/ou manutenção de aplicações mobile, desenvolvimento e/ou manutenção de aplicações com tecnologia de georreferenciamento e outras.

c) Para os demais profissionais diretamente envolvidos na execução dos serviços ao CONTRATANTE:

EQUIPE DE SUSTENTAÇÃO DE SOLUÇÕES DE SOFTWARE
	PERFIL:	ADMINISTRADOR DE DADOS
	FORMAÇÃO:	Nível Superior completo na área de Tecnologia da Informação com
		diploma fornecido por instituição de ensino superior reconhecido pelo
		Ministério da Educação OU nível superior em qualquer área de
		formação com pós-graduação (especialização, mestrado ou
A.		doutorado) na área de Tecnologia da Informação em curso com carga horária mínima de 360 horas, reconhecido pelo MEC.
	CONHECIMENTOS:	Não há exigências específicas
	EXPERIÊNCIA:	Experiência de, pelo	menos,	02	(dois)	anos	na	função	de
		Administrador de Dados.

	CERTIFICAÇÕES TÉCNICAS:	Não há exigências específicas.
B.	PERFIL:	GERENTE DE CONFIGURAÇÃO E MUDANÇA
	FORMAÇÃO	Nível Superior completo na área de Tecnologia da Informação com diploma fornecido por instituição de ensino superior reconhecido pelo Ministério da Educação OU nível superior em qualquer área de formação com pós-graduação (especialização, mestrado ou doutorado) na área de Tecnologia da Informação em curso com carga horária mínima de 360 horas, reconhecido pelo MEC.
	CONHECIMENTOS:	Não há exigências específicas
	EXPERIÊNCIA:	Experiência comprovada de, pelo menos, 03 (três) anos em gerência de configuração, mudança e ambiente utilizando as melhores práticas do mercado e ferramentas de apoio à Disciplina de Gerência e Configuração de Mudanças.
	CERTIFICAÇÕES TÉCNICAS:	Não há exigências específicas.
C:	PERFIL:	ANALISTA DE SEGURANÇA
	FORMAÇÃO:	Nível Superior completo na área de Tecnologia da Informação com diploma fornecido por instituição de ensino superior reconhecido pelo Ministério da Educação OU nível superior em qualquer área de formação com pós-graduação (especialização, mestrado ou doutorado) na área de Tecnologia da Informação em curso com carga horária mínima de 360 horas, reconhecido pelo MEC.
	CONHECIMENTOS:	Proteção de Dados – GDPR/LGPD.
	EXPERIÊNCIA:	Experiência comprovada de, pelo menos, 03 (três) anos em Segurança da Informação.
	CERTIFICAÇÕES TÉCNICAS:	ISO 27001.
D.	PERFIL:	ANALISTA DE TESTES E QUALIDADE
	FORMAÇÃO:	Nível Superior completo na área de Tecnologia da Informação com diploma fornecido por instituição de ensino superior reconhecido pelo Ministério da Educação OU nível superior em qualquer área de formação com pós-graduação (especialização, mestrado ou doutorado) na área de Tecnologia da Informação em curso com carga horária mínima de 360 horas, reconhecido pelo MEC.
	CONHECIMENTOS:	Não há exigências específicas.
	EXPERIÊNCIA:	Experiência comprovada de, pelo menos, 03 (três) anos em qualidade de software contemplando elaboração de Planejamento e Execução de Testes funcionais e estáticos, bem como em automatização de testes e testes de desempenho.
	CERTIFICAÇÕES TÉCNICAS:	Certificação CTFL Agile Tester (preferencialmente) ou Certificação CTFL Foundation (Certified Tester Foundation Level), ou equivalentes, no mínimo.

Tabela 40: Equipe de Sustentação de Soluções de Software

22.29.5. Requisitos de disponibilidade e presencialidade

22.29.5.1. Para o GRUPO 1 (Serviços de desenvolvimento e manutenção de soluções de software), as atividades de gerenciamento de projeto, levantamento de requisitos, gerência de configuração, implantação e outras atividades que demandem iteração direta e contínua com o CONTRATANTE deverão, preferencialmente, ser executadas de forma presencial no endereço de referência para prestação dos serviços.

22.29.5.2 A prestação de serviços não envolve “dedicação exclusiva de mão de obra” – nos termos do art. 17 da IN 05/SEGES/MPDG de 26/05/2017 – uma vez que a CONTRATADA poderá compartilhar os recursos humanos e materiais disponíveis para execução simultânea de outros contratos. A prestação dos serviços não gera vínculo empregatício entre os

empregados da CONTRATADA e a ADMINISTRAÇÃO, vedando-se qualquer relação entre estes que caracterize pessoalidade e subordinação direta.

CAPÍTULO 23. CRITÉRIOS DE SELEÇÃO DO FORNECEDOR

23.1. Os critérios de aceitabilidade de preços serão:

23.2. Valor Global: R$xxx,00 (indicar por extenso)

23.3. Valores unitários: conforme planilha de composição de preços anexa ao edital.

23.4. O critério de julgamento da proposta é o menor preço global.

23.5. As regras de desempate entre propostas são as discriminadas no edital.

23.6. É obrigatório o estabelecimento de parâmetros objetivos para análise da comprovação (atestados de capacidade técnico-operacional) de que a licitante já tenha fornecido bens pertinentes e compatíveis em características, quantidades e prazos com o objeto da licitação (art. 30, inciso II, da Lei 8.666/1993).

23.7. Assim, a exigência de comprovação da capacidade técnico-operacional dos licitantes, no que diz respeito à qualificação técnica, deve estará restrita ao mínimo indispensável à execução do objeto, nos termos estabelecidos pelo art. 37, inc. XXI, da Constituição Federal.

23.8. Cabe à Administração, portanto, em cada caso concreto, avaliar a real necessidade de exigir os documentos arrolados no art. 30 da Lei nº 8.666/93, inclusive no que diz respeito à capacidade técnica-operacional, e em que medida. Para fins de verificação da qualificação técnica, a Administração poderá exigir dos licitantes a apresentação de atestados de desempenho anterior que demonstrem sua capacidade técnica.

23.9. Visando preservar a competitividade do certame, todavia, tal exigência somente será válida relativamente de maior relevância e valor significativo do objeto, nos termos do art. 30, inc. I, § 1º da Lei nº 8.666/93. Assim, considerando as características da pretensão contratual, a Equipe de Planejamento da Contratação considera adequada a aplicação dos requisitos para os atestados de capacidades técnica nos termos constantes no Capítulo 22 deste Termo de Referência.

CAPÍTULO 24. DA ESTIMATIVA DE PREÇOS

24.1. A estimativa de preço da contratação foi realizada pela EQUIPE DE PLANEJAMENTO DA CONTRATAÇÃO para elaboração do orçamento detalhado, composta por preços unitários e fundamentada em PESQUISA DE PREÇOS realizada em conformidade com os procedimentos administrativos estabelecidos na Instrução Normativa SLTI/MP n° 05, de 27 de julho de 2014, e suas atualizações. Os documentos utilizados para embasar a pesquisa de preços dos quais obteve-se o seguinte resultado consolidado:

Estimativa de Preços da Contratação
Grupo	Item	Descrição do Item	Unidade	Quantidade Total (12 meses)	Valores Máximos (Em Reais / Por Item
					Unitário	Total
		Serviços de
		desenvolvimento
	1	e manutenção de soluções de	PF	14.000	R$	R$
		software
1		Serviços de sustentação de
	2	soluções de	PFS	7.000	R$	R$
		software
	3	Serviços	UST	7.000	R$	R$
		técnicos de

Estimativa de Preços da Contratação
		desenvolvimento portais, transferência de Conhecimento e Consultoria em TI
	4	Serviços técnicos de sustentação de portais	USTS	3.500	R$	R$
Valor Global Estimado						R$

Tabela 41: Estimativa de Preço

CAPÍTULO 25: DA DOTATAÇÃO ORÇAMENTÁRIA

25.1. As despesas correrão à conta da dotação orçamentária do Conselho de Arquitetura e Urbanismo do Brasil (CAU/BR), a saber:

Fonte: Rubrica Orçamentária - 6.2.2.1.1.01.04.04.031 – Serviços de Manutenção Sistema de Informática.

Centro de Custo: 4.02.08.001 - ATIVIDADE - Desenvolvimento e Manutenção das Atividades do CSC

CAPÍTULO 26: DO PRAZO, LOCAL E FORMA DE ENTREGA

26.1. A contratada terá o prazo máximo de entrega estipulado em conformidade com o Item 03 deste Termo de Referência para entrega dos serviços, contados a partir da data do recebimento da Nota de Empenho, a empresa que não cumprir o prazo estipulado sofrerá as sanções previstas na Lei n 8.666/1993 e no Termo de Referência.

26.2. A entrega deverá ser feita em documento formal impresso e cópia digital: CD ou DVD. O documento formal. Local de entrega: XXX Xxxxxx 0, Xxxxx X, Xxxxxxx 00 - Xxxxxxxx Xxxxx Dourada, salas 401 a 409, em Brasília/DF, nos dias úteis das 8:30h às 12:30h e das 14h às 18h.

26.3. A entrega dos serviços será acompanhada e fiscalizada por representante do CONTRATANTE, com vistas à verificação da conformidade dos serviços com as especificações constantes neste Termo de Referência e anexos.

CAPÍTULO 27: DA RESPONSABILIDADE CIVIL

27.1. A CONTRATADA responderá por quaisquer prejuízos ou danos, por culpa ou dolo, causados por seus empregados ou prepostos ao CAU/BR e/ou a terceiros, em decorrência da prestação dos serviços, seja a que título for;

27.2. O CAU/BR estipulará prazo para a devida reparação, a depender da gravidade e extensão dos danos.

CAPÍTULO 28. DO CONTRATO

28.1. Após a adjudicação e homologação do procedimento licitatório, convocar-se-á o licitante vencedor para assinatura do instrumento contratual, que deverá ocorrer, impreterivelmente, no prazo de até 5 (cinco) dias úteis, a contar da comunicação, sob pena de decair do direito à contratação e sem prejuízo das sanções previstas neste Termo de Referência e no art. 81 da Lei nº 8.666, de 1993.

28.2. O prazo para assinatura do contrato poderá, em situação excepcionalíssima, ser prorrogado uma única vez, por igual período, quando solicitado pelo licitante vencedor em até 48h (quarenta e oito horas), a contar do recebimento da comunicação constante do item 21.1, desde que ocorra motivo relevante e aceito pelo CAU/BR.

28.3. Na celebração do contrato e caso haja renovações, serão exigidas as mesmas condições de habilitação.

28.4. O contrato a ser assinado com o licitante vencedor terá vigência de 12 (doze) meses, contados da data da assinatura, podendo, atendidos a oportunidade e conveniência do CAU/BR, e sob condições vantajosas, ser prorrogado mediante termo aditivo, por iguais e

sucessivos períodos, nos termos do art. 57, II, da Lei nº 8.666, de 1993.

28.5. Pela inexecução total ou parcial do contrato poderá, garantidos o contraditório e a ampla defesa, ser aplicada à CONTRATADA as sanções de que tratam os arts. 86 a 88 da Lei nº 8.666, de 1993, bem como as sanções e penalidades previstas neste Termo de Referência.

CAPÍTULO 29. DO PRAZO DE VIGÊNCIA

29.1. O xxxxx xx xxxxxxxx xx xxxxxxxx xxxx xx 00 (xxxxxxxx x xxxx) meses, contados da data da assinatura podendo, a critério da CONTRATANTE e sob condições vantajosas, ser prorrogado mediante termo aditivo, por sucessivos períodos, nos termos do art. 57, II, da Lei nº 8.666/1993.

29.2. A CONTRATADA fica obrigada a aceitar, nas mesmas condições contratuais, os acréscimos ou supressões que se fizerem necessários até o limite de 25% (vinte e cinco por cento) do valor inicial atualizado do contrato, conforme legislação vigente.

CAPÍTULO 30. DA PROPRIEDADE, SIGILO E RESTRIÇÕES

30.1. Direito de Propriedade

30.1.1. A empresa CONTRATADA deverá manter sigilo, sob pena de responsabilidade civil, penal e administrativa, sobre todo e qualquer assunto de interesse do CAU/BR ou de terceiros de que tomar conhecimento em razão da execução do contrato, respeitando todos os critérios estabelecidos, aplicáveis aos dados, informações, regras de negócios, documentos, entre outros pertinentes;

30.1.2. A empresa CONTRATADA deverá manter sigilo absoluto sobre quaisquer dados, informações, códigos-fonte, artefatos, contidos em quaisquer documentos e em quaisquer mídias, incluindo os coletores de dados e seus meios de armazenamento, de que venha a ter conhecimento durante a execução dos trabalhos de levantamento de requisitos, construção, implantação e execução dos serviços, não podendo, sob qualquer pretexto divulgar, reproduzir ou utilizar, sob pena de lei, independentemente da classificação de sigilo conferida pelo CAU/BR a tais documentos;

30.1.3. O CAU/BR, para todos os efeitos da aplicação da Lei n.º 9.609/98, que dispõe sobre a proteção da propriedade intelectual de programa de computador, e regulamentos correlatos, é o único proprietário dos produtos entregues pela prestadora de serviços;

30.1.4. O CAU/BR terá o direito de propriedade intelectual do software e respectivos componentes, bem como de todos os artefatos gerados nas etapas de fabricação de forma permanente, sendo permitido, a qualquer tempo, distribuir, alterar e utilizar o software sem limitações de quaisquer licenças restritivas;

30.1.5. Todo produto resultante de análise, código-fonte, documentação, objetos, bibliotecas, classes, rotinas e outros, serão de propriedade intelectual e exclusiva do CAU/BR, não podendo ser reproduzidos ou utilizados para quaisquer outras finalidades;

30.1.6. A empresa CONTRATADA deverá ceder ao CAU/BR o direito patrimonial e a propriedade intelectual de toda e qualquer documentação e produtos gerados antes do recebimento definitivo dos serviços prestados;

30.1.7. A empresa CONTRATADA deverá manter sigilo dos dados e das informações confidenciais a que tiver acesso;

30.1.8. A empresa CONTRATADA deverá manter o sigilo e a confidencialidade dos dados que serão utilizados pelo software;

30.1.9. Acerca dos sistemas e bases de dados existentes na instituição que compõem o escopo do objeto de que trata este TR, o CAU/BR irá permitir à empresa CONTRATADA livre acesso aos códigos-fonte e dados mediante assinatura de Termo de Confidencialidade (Encarte F);

30.1.10. Os artefatos do sistema serão de uso proprietário do CAU/BR, inclusive seus códigos-fonte e documentação;

30.1.11. As soluções desenvolvidas estarão sob licença de uso restrito ao CAU/BR, protegidos por direitos autorais e de propriedade. A cópia, redistribuição, engenharia reversa e modificação do software proprietário são proibidas por parte da empresa CONTRATADA sem anuência do CAU/BR;

30.1.12. Os dados, artefatos, softwares e informações da organização não poderão ser

distribuídos, divulgados e comercializados pela empresa CONTRATADA.

30.2. Condição de Manutenção de Sigilo

30.2.1. A empresa CONTRATADA deve cumprir normas estabelecidas no Regulamento Interno de Segurança da Informação do CAU/BR para o acesso, manuseio, tratamento, controle e proteção das informações e dados (disponível em xxxx://xxxxxxxxxxxxx.xxxxx.xxx.xx);

30.2.2. A empresa CONTRATADA deve adotar critérios para sigilo, uso e proteção das informações, além da adoção de mecanismos físicos de proteção aos equipamentos e dispositivos utilizados na execução do contrato;

30.2.3. É de responsabilidade exclusiva da empresa CONTRATADA aferir e adotar critérios para avaliação da vida pregressa dos seus funcionários, certificando-se que estes tenham comportamento irrepreensível e idoneidade moral inatacável, com o propósito de evitar a incorporação no contrato de pessoas com características e/ou antecedentes que possam comprometer a segurança ou credibilidade do CAU/BR;

30.2.4. A empresa CONTRATADA e seus empregados devem manter sigilo absoluto sobre informações, dados e documentos que venham a ter conhecimento quando da realização dos serviços, para isso será formalizado Termo de Compromisso (Encarte F) e Termo de Ciência (Encarte G).

30.3. Mecanismos Formais de Comunicação

30.3.1. Solicitações formais por escrito para fornecimento, emissão de Nota Fiscal, pedidos de esclarecimentos e demais solicitações relacionadas com o objeto serão feitas pelo Gestor ou pelo Fiscal do contrato à empresa CONTRATADA;

30.3.2. A empresa CONTRATADA deverá propor um plano de comunicação, que contenha os procedimentos e responsáveis aos quais devem ser dirigidas as comunicações formais no âmbito da execução contratual. O plano deverá ser aprovado e aceito pelo CAU/BR;

30.3.3. A empresa CONTRATADA se obriga a disponibilizar, em até 30 (trinta) dias a contar da assinatura do contrato, sem custo adicional para o CAU/BR, os seguintes canais de atendimento a partir da entrega do primeiro Termo de Compromisso, do contrato:

a) Telefone;

b) E-mail;

c) Ferramenta de Gestão de Demandas de TI (OS);

d) Ferramenta de Gestão de Defeitos (Ticket);

e) Central para acionamento das ocorrências de pronto atendimento (equipe de Sustentação).

30.3.4. Os canais e-mail e/ou ferramenta de Gestão de Demandas de TI (OS) deverão prever recepção e tratamento diferenciado das demandas, por tipo de serviço e por criticidade e a possibilidade de acompanhamento pelo CAU/BR de todo o processo de atendimento;

30.3.5. A ferramenta de Gestão de Demandas de TI (OS) deverá prover ao CAU/BR informação detalhada da execução dos serviços, em tempo real, com conexão segura, bem como permitir ao CAU/BR acompanhar a execução e verificar os índices de desempenho dos serviços contratados;

30.3.6. A comunicação entre as partes envolvidas no processo de atendimento das demandas deve ser, preferencialmente, por Ordem de Serviço registrada pela ferramenta de Gestão de Demanda, sendo prevista comunicação por e-mail, reuniões presenciais e suas respectivas atas;

30.3.7. A empresa CONTRATADA fica responsável pela manutenção da(s) ferramenta(s) de comunicação em funcionamento, sem erros, durante toda a vigência do contrato;

30.3.8. No período máximo de 15 dias, deverão ser realizadas reuniões de acompanhamento, onde deverão estar presentes o Preposto indicado pela empresa CONTRATADA, o Gestor do contrato, os fiscais do contrato e demais envolvidos ou interessados.

CAPÍTULO 31. DA PROVA DE CONCEITO

31.1. A empresa licitante provisoriamente classificada em primeiro lugar será informada via chat a data e a hora da prova de conceito que deverá realizar como parte do processo licitatório;

31.2. A empresa licitante terá o prazo máximo de 10 (dez) dias úteis, em horário comercial, a contar da data marcada para a prova de conceito, descrita no item anterior, para concluir a prova de conceito estipulada pelo CAU/BR;

31.3. A empresa licitante é responsável em prover todos os recursos computacionais necessários para realização da prova de conceito, incluindo hardwares e softwares com respectivas licenças a serem utilizados para execução da prova de conceito;

31.4. O CAU/BR, não disponibilizará recursos computacionais de apoio à empresa licitante, como acesso à Internet, periféricos, softwares, entre outros;

31.5. Não caberá ao CONTRATANTE, sob qualquer hipótese, o pagamento de qualquer valor ou indenização em virtude da realização da demonstração, seja ela rejeitada ou não. Portanto, todos os custos decorrentes da participação na Prova de Conceito ficarão a cargo da LICITANTE;

31.6. A Prova de Conceito consiste em executar 1 (uma) OS - Ordem de Serviço, contendo demandas fictícias totalizando no máximo 10 (dez) pontos de função, a título de prova de conceito a qual se destinará à verificação da conformidade e qualidade dos artefatos produzidos e do desempenho técnico do licitante;

31.7. A solução de software será avaliada em máquina virtual configurada pela empresa licitante contendo solução de software desenvolvida, conforme requisitos especificados pelo CAU/BR na prova de conceito;

31.8. Caso o CAU/BR emita o aceite da OS, será confirmada a classificação;

31.9. Caso o CAU/BR emita a recusa da OS em função do resultado de sua validação, a empresa licitante participante da Prova de Conceito terá sua proposta desclassificada, e será chamada a próxima empresa licitante habilitada, para executar o proposto na Prova de Conceito e, assim sucessivamente seguindo a ordem da prévia classificação e habilitação no processo licitatório;

31.10. Este ciclo será repetido até que o CAU/BR adjudique um licitante no certame;

31.11. Caso nenhum licitante seja aprovado na prova de conceito o CAU/BR fará novo processo licitatório;

31.12. Os documentos constantes da prova de conceito serão entregues para a empresa licitante na data marcada para realização da prova de conceito;

31.13. É de responsabilidade da empresa licitante a obtenção de todas as informações do ambiente especificado pelo CAU/BR necessárias para execução da prova de conceito;

31.14. O “Checklist da Avaliação e Resultado” da prova de conceito, constante no Encarte L deste Termo de Referência, contém todos os critérios que serão usados para pontuar e indicar se a empresa licitante foi ou não aprovada;

31.15. Os requisitos que deverão ser implementados, que declaram as restrições e especificam a qualidade mínima da solução de software serão descritos no documento “Requisitos Funcionais e Não Funcionais”;

31.16. A “Planilha de Contagem de Pontos de Função” conterá todas as funcionalidades da solução de software que deverão ser desenvolvidas no qual a empresa licitante registrará a quantidade de pontos de função por funcionalidade;

31.17. Serão disponibilizados à empresa licitante, durante o período da Prova de Conceito, artefatos para proporcionar maior esclarecimento ao processo, sendo estes:

a) Checklist da Avaliação e Resultado da Prova de Conceito;

b) Documento de Visão;

c) Especificação de Requisitos Funcionais e não-funcionais;

d) Regras de Negócio;

e) Diagrama de Caso de Uso;

f) Planilha de Contagem de Pontos de Função;

g) Templates da MGDS-CAUBR.

31.18. A solução de software desenvolvida e demais artefatos constantes da prova de conceito a serem entregues pela empresa licitante serão avaliados conforme consta no item referente ao Checklist da Avaliação;

31.19. Os artefatos requisitados pela Prova de Conceito e que serão avaliados pelo Checklist da Avaliação são os que seguem:

a) Planilha de Contagem de Pontos de Função (Preenchida);

b) Casos de Uso Detalhado;

c) Casos de Testes

d) Documento de Mensagem;

e) Documento de Arquitetura;

f) Testes Unitários;

g) Termo de Entrega do Produto;

h) Código Fonte;

i) Mídia Digital – CD (Contendo todos os artefatos das alíneas anteriores).

31.20. Os artefatos produzidos pela empresa licitante serão avaliados com base nos templates fornecidos pelo CAU/BR;

31.21. A empresa licitante será automaticamente reprovada na prova de conceito caso entregue algum artefato que não tenha sido gerado a partir dos templates fornecido pelo CAU/BR;

31.22. Após a entrega dos artefatos e da solução de software para avaliação, não serão permitidas quaisquer alterações neles;

31.23. A empresa licitante deverá fornecer, antes da avaliação dos artefatos e produto de software, uma cópia, em mídia digital para arquivamento, contendo todos os artefatos produzidos durante a prova de conceito;

31.24. A cópia ficará em posse do CAU/BR e fará parte dos autos do certame, juntamente com os demais documentos do processo;

31.25. A validação dos itens do checklist será realizada por grupo técnico de servidores do CAU/BR, sendo a empresa licitante responsável em comprovar o atendimento dos itens;

31.26. As justificativas e observações relativas aos itens a serem avaliados no checklist serão preenchidos pelos servidores do CAU/BR;

31.27. Será permitido o acompanhamento da avaliação a quaisquer interessados, desde que não haja quaisquer interferências na condução do processo e em número de pessoas condizente com as instalações do local onde será realizada a sessão.

31.28. A máquina física onde estiver sendo executada a solução de software desenvolvida deverá, no momento da avaliação, estar desconectada da rede local e da internet, totalmente isolada de qualquer comunicação externa;

31.29. A avaliação do software que venha fazer uso da internet durante sua a execução não isenta a responsabilidade e possíveis penalidades da empresa licitante pelo mal funcionamento do software avaliado;

31.30. Será desclassificada a LICITANTE:

31.30.1. Que não realizar a demonstração solicitada, na data estabelecida.

31.30.2. Que não atender algum dos itens obrigatórios do Checklist “Itens Eliminatórios”;

31.30.3. Que não atingir o valor, igual ou maior, de 80% (oitenta por cento) do valor do Índice de conformidade da prova de conceito de acordo com a fórmula abaixo:

Índice de Conformidade = (Qtd. Pontos Obtidos / Qtd. Total de Pontos Possíveis) x 100 Onde:

Qtd. Pontos Obtidos: Quantidade de itens do checklist pontuados pelo licitante, de acordo com os requisitos descritos pelo CONTRATANTE;

Qtd. Total de Ponto Possíveis: Quantidade total pontos possíveis de obter dentro do checklist entregue pelo CONTRATANTE.

31.31. A Pontuação obtida nos “Itens Pontuadores” poderá ser “Integral” (100% da pontuação do item em questão), “Parcial” (50% da pontuação do item em questão) ou “Nenhuma” (0% da pontuação do item em questão). Sendo que:

31.31.1. A pontuação “Integral” será obtida caso o CAUBR julgue que a solução da licitante está em total conformidade com o que foi solicitado no item avaliado;

31.31.2. A pontuação “Parcial” será obtida caso o CAUBR julgue que a solução da licitante apresenta desconformidade PONTUAL e que não prejudica e nem compromete a essência do que foi solicitado no item avaliado;

31.31.3. A pontuação “Nenhuma” será obtida caso o CAUBR julgue que a solução da licitante apresente algo totalmente diferente do solicitado e/ou que apresente erros relevantes na solução apresentada.

31.32. A LICITANTE que, devidamente convocada para a Prova de Conceito, não comparecer e nem apresentar justificativa para essa falta, além de ser desclassificada no certame, ficará sujeita às sanções previstas no art. 7º da Lei nº 10.520, de 2002, respeitado o rito para a aplicação de penalidades.

31.33. O Pregoeiro do CAU/BR considerará como vencedora a proposta que apresentar o menor preço global, após ser considerada classificada na Prova de Conceito e cumpridos os requisitos da habilitação.

CAPÍTULO 32. DAS DISPOSIÇÕES FINAIS

32.1. Esclarecimentos relativos ao Termo de Referência serão prestados pela Gerência Administrativa, no horário de 9h00 às 12h00 e 14h00 às 18h00, no endereço SCS Quadra 02, Bloco “C”, Xxxxxxx 00, Xxxx 000 a 409, Edifício Serra Dourada, CEP: 00000-000, no telefone:

(00) 0000-0000 ou, ainda, por e-mail, no endereço eletrônico xxxxxxxxx@xxxxx.xxx.xx.

À consideração superior,

Brasília-DF, XX de XXXXX de 2020.

XXXXXX XXXXXXX

Gerente do CSC

De acordo. Aprovo o Termo de Referência nos moldes delineados, à vista de todo o

detalhamento descrito e encaminho à Comissão de Licitação para as providências devidas quanto a elaboração do edital de licitação e demais procedimentos.

XXXXXXX XXXXXXX

Gerente Executivo do CAU/BR

ENCARTE B: MGDS-CAU

METODOLOGIA DE GESTÃO EM DESENVOLVIMENTO DE SOFTWARE DO CONSELHO DE ARQUITETURA E URBANISMO (VERSÃO 3.0)

1. Introdução

A Gerência de Serviços Compartilhados (GESC) vem desenvolvendo ações voltadas à implementação dos direcionamentos estratégicos definidos pelos órgãos orientadores, normativos e fiscalizadores do Governo Federal para a Administração Pública.

Neste sentido, a GESC, de forma planejada, vem trabalhando na padronização, simplificação e divulgação da estratégia de melhoria contínua dos processos organizacionais que visam o uso racional da tecnologia da informação.

A Metodologia de Gestão em Desenvolvimento de Software (MGDS) do CAU está inserida em um contexto organizacional de gestão dos serviços de projeto, sustentação, serviços, inclusive documentação e metrificação de sistemas de informação para este Conselho.

Esta metodologia tem o objetivo de estabelecer procedimentos para a gestão dos processos e serviços previstos dentro do escopo de Fábrica de Software (FSW), responsável por executar os serviços de desenvolvimento e manutenção de sistemas utilizando práticas de métodos ágeis e Fábrica de Métrica (FM), responsável por realizar a contagem de pontos de função das ordens de serviço para a FSW.

De acordo com as diretrizes do PDTI do CAU/BR, visando permitir o aumento ou diminuição de investimentos com sistemas informatizados de acordo com a necessidade dos entes do Centro de Serviços Compartilhados – CSC-CAU, os serviços de desenvolvimento de software serão realizados de forma terceirizada, com a contratação de uma fábrica de software. Já para realizar a medição do serviço executado pela fábrica de software será CONTRATADA uma fábrica de métricas. Conforme descrito no Roteiro de Métricas de Software do SISP, versão 2.2, uma das principais dificuldades e desafios na adoção de métodos ágeis em contratação de desenvolvimento de software é definir um modelo de remuneração que seja equilibrado, remunerando de forma justa o esforço da CONTRATADA para atender o volume de refinamentos e mudanças em funcionalidades e, ao mesmo tempo, não onerando de forma excessiva o CAU/BR, contratante do serviço. Ou seja, o valor pago deve corresponder aos serviços recebidos e o ciclo do processo ágil de desenvolvimento de software não deve influenciar negativamente o ciclo de faturamento do projeto.

É importante observar que, conforme a Súmula TCU 269, a remuneração nas contratações de serviços de Tecnologia da Informação deve estar vinculada à entrega de resultados e ao atendimento de níveis de serviço. Portanto, é relevante que o modelo de remuneração do contrato firmado defina os níveis de serviço e os critérios de qualidade para a aceitação dos resultados entregues ao final das sprints do processo ágil.

Portanto, todo o processo de medição citado neste MGDS deve ser complementado com as práticas definidas no capítulo 7, denominado de “Contagem de Pontos de Função no Desenvolvimento de Software utilizando Métodos Ágeis” do Roteiro de Métricas já citado.

2. Conceitos

Para alinhar o entendimento no cenário de desenvolvimento de software com métodos ágeis utilizando a remuneração de FSW por produto entregue medido em pontos de função, é importante alinhar os seguintes conceitos:

• Release: É um ciclo que perpassa pelas fases do processo de desenvolvimento de software com o objetivo de entregar, ao final do ciclo, um produto pronto a ser colocado em produção para uso. A duração de cada release será definida pelo Fiscal Técnico, coordenador do CSC que atenderá à demanda, na fase de planejamento do projeto/manutenção, conforme seu backlog priorizado, de forma a garantir uma entrega de valor antecipada aos usuários. O conjunto de releases forma o roadmap do produto.

• Sprint: É uma unidade de período de tempo fixo (time box) dentro do release, com datas de início e fim pré-definidas, dentro da qual é executado um conjunto de atividades de desenvolvimento previamente estabelecidas, gerando ao final um incremento do produto aceito, testado, homologado e potencialmente implantável, ou seja passível de publicação em ambiente de produção e disponibilização para os usuários. A sprint não deve ser menor que 2 (duas) semanas e maior que 4 (quatro) semanas e, à guisa do release, será definida pelo

requisitante em conjunto com o Product Owner (PO) responsável pela demanda, na fase de planejamento do projeto/manutenção.

• Ciclo de Pagamento: período definido para fins de pagamento e apuração dos resultados entregues, podendo consistir de uma iteração (sprint), de um conjunto de iterações, de um release ou ainda de uma demanda. Considerando os critérios adotados para o projeto, como o tamanho da iteração (sprint), o tamanho do release, a produtividade da equipe do projeto e a expectativa de fluxo de caixa da CONTRATADA, para manter seu equilíbrio econômico- financeiro no atendimento do contrato, deve se realizar o faturamento por iteração (sprint), por grupo de iterações, por release ou por demanda, desde que sempre devidamente associado aos produtos entregues e aceitos de uma ordem de serviço. Esta MGDS permite o pagamento parcial por etapa entregue após a emissão do Termo de Recebimento Provisório - TRP.

• Produto Pronto: Visando a remuneração da CONTRATADA a partir da medição de resultados gerados em um “ciclo de pagamento”, entende-se que um produto está “pronto” se foi entregue e aceito. Cabe observar que o desenvolvimento de uma funcionalidade pode perpassar mais de uma sprint e conter várias funcionalidades prontas e validadas em sprints diferentes. Nesse caso, a funcionalidade só será considerada para fins de pagamento ao final do ciclo de pagamento em que estiver com todas as suas funcionalidades componentes prontas, testadas, homologadas e aceitas.

• Refinamentos: são quaisquer mudanças ocorridas sobre uma função transacional ou de dados já previamente trabalhada(s) na release corrente (seja por meio de uma inclusão, alteração ou exclusão), provocadas pelo aprofundamento, detalhamento e complementação de requisitos durante o processo de desenvolvimento.

• TAG: Forma de organizar arquivos de diferentes sprints ou releases para a publicação em ambientes de teste, homologação ou produção.

3. Processo de Software

O CAU, no contexto de sua metodologia (MGDS), se valerá de processos de apoio para sua execução de forma a garantir sua qualidade. Conceitos utilizados nesse documento:

• Funcionalidade: Capacidade do produto de software de prover funções que atendam às necessidades explícitas e implícitas, quando o software estiver sendo utilizado sob condições especificadas;

• Confiabilidade: Capacidade do produto de software de manter um nível de desempenho especificado, quando usado em condições especificadas;

• Usabilidade: Capacidade do produto de software de ser compreendido, aprendido, operado e atraente ao usuário, quando usado sob condições especificadas;

• Eficiência: Capacidade do produto de software de apresentar desempenho apropriado, relativo à quantidade de recursos usados, sob condições especificadas;

• Manutenibilidade: Capacidade do produto de software de ser modificado. As modificações podem incluir correções, melhorias ou adaptações do software devido a mudanças no ambiente e nos seus requisitos ou especificações funcionais;

• Portabilidade: Capacidade do produto de software de ser transferido de um ambiente para outro;

• Gerência de configuração: possui o propósito de estabelecer e manter a integridade de todos os produtos de trabalho (artefato) de um processo do projeto;

• Garantia da qualidade: possui o propósito de prover garantia de que os produtos e processos estão em conformidade com os requisitos especificados e satisfazem aos planos e regras estabelecidas;

• Verificação: possui o propósito de confirmar que os produtos e/ou serviços refletem os requisitos especificados;

• Validação: possui o propósito de confirmar que os requisitos para o uso específico de um produto e/ou serviço são atendidos;

• Erro: é a diferença entre o valor obtido e o valor esperado, ou seja, qualquer estado intermediário incorreto ou resultado inesperado na execução do programa constitui um erro;

• Revisão conjunta: possui o propósito de manter o entendimento (gerencial comum com os

stakeholders);

• Auditoria: possui o propósito de determinar independentemente a conformidade dos produtos e processos contra os requisitos definidos;

• Resolução de problema: possui o propósito de assegurar que todos os problemas levantados sejam analisados e resolvidos;

• Contrato: todo e qualquer ajuste entre órgãos ou entidades da Administração Pública e particulares, em que haja um acordo de vontades para a formação de vínculo e a estipulação de obrigações recíprocas.

• GAD: O GAD é a ferramenta utilizada pela GESC para receber demandas dos entes do CSC.

• Área de Negócio:

• Dono do Produto (product owner): colaborador do CSC indicado para ser o responsável pela demanda.

• Matriz GUT: ferramenta de avaliação de criticidade que consiste em aplicar uma nota de 1 a 5 para gravidade, urgência e tendência. A prioridade da demanda é calculada multiplicando as notas.

• Documento de Escopo: possui a visão do produto e o roadmap com os releases da demanda, que serão incluídas nas versões do produto.

O processo de desenvolvimento ágil do CAU/BR se baseia no processo descrito no “Guia de Projetos de Software com Práticas Ágeis do SISP (Sistema de Administração dos Recursos de Tecnologia da Informação)” e utiliza o modelo de referência da figura abaixo:

Figura: Modelo de referência de projetos de software com práticas ágeis do SISP

Recomenda-se frequentemente a consulta ao modelo de referência citado para aprofundamento nos conceitos, ferramentas e técnicas, de modo a complementar a aplicação desta MGDS.

4. Tipos de demandas

I) Projeto

Pode ser classificado como (conforme o guia do SISP 2.2):

a. Projeto de desenvolvimento: Consiste no projeto para desenvolver e entregar a primeira versão de uma aplicação de software. Seu tamanho funcional é a medida das funcionalidades entregues ao usuário no final do projeto. Também se considera as funcionalidades de conversão de dados, caso seja requisitado no projeto a migração ou carga inicial de dados para a nova aplicação.

b. Projeto de melhoria: Consiste no esforço necessário para o atendimento de uma demanda de evolução ou melhoria funcional com tamanho significativo (igual ou superior a 100 pontos de função) e/ou alta criticidade para o processo de negócio do CAU/BR. Seu tamanho funcional é a medida das funcionalidades incluídas, alteradas e excluídas ao final do projeto. Também se considera as funcionalidades de conversão de dados, caso seja requisitado a migração ou carga inicial de dados no projeto de melhoria.

II) Manutenção

Consiste em demandas de sustentação e manutenção dos sistemas existentes abaixo de 100 pontos de função. Tem o objetivo de evoluir e manter, o maior tempo possível, sem falhas os sistemas/aplicações em produção. Pode ser classificado como:

a. Manutenção evolutiva: evoluções (melhorias) de sistemas de informação, visando implementar novas funcionalidades, alterar ou excluir funcionalidades existentes, promover a melhoria de performance, a manutenibilidade e usabilidade do sistema, melhorando sua aplicabilidade, eficiência e usabilidade dentro da organização;

b. Manutenção adaptativa: São consideradas nesta categoria as demandas de manutenção adaptativa associadas a solicitações que envolvem aspectos não funcionais, sem alteração em requisitos funcionais. Seguem alguns exemplos:

• Aumentar a quantidade de linhas por página em um relatório;

• Colocar paginação em um relatório;

• Limitar a quantidade de linhas por página em uma consulta existente;

• Permitir exclusões múltiplas em uma funcionalidade que antes só possibilitava a exclusão de um item;

• Adaptação de uma funcionalidade para possibilitar a chamada por um webservice ou para outro tipo de integração com outros sistemas;

• Replicação de funcionalidade: chamar uma consulta existente em outra tela da aplicação;

• Alteração na aplicação para adaptação às alterações realizadas na interface com rotinas de integração com outros softwares, por exemplo, alteração em sub-rotinas chamadas por este software;

• Modificar o servidor a ser acessado em uma funcionalidade de download de arquivo;

• Adequar mensagem do sistema que em algumas telas apresenta “Usuário Não está Habilitado a ver esta Página”, para que passe a enviar uma mensagem mais adequada ao fato do usuário não possuir mais uma sessão ativa e ainda estar navegando no sistema. A demanda deve ser contada como manutenção adaptativa considerando as funcionalidades impactadas. Observe que trata-se de mudança em validação com regra de negócio não funcional.

c. Manutenção de interface: mudança de interface (layout), por exemplo: fonte de letra, cores de telas, logotipos, mudanças de botões na tela, mudança de posição de campo ou texto na tela. Também se enquadram nessa categoria as seguintes manutenções:

• Mudanças de texto em mensagens de erro, validação, aviso, alerta, confirmação de cadastro ou conclusão de processamento;

• Mudança em texto estático de e-mail enviado para o usuário em uma funcionalidade de cadastro. A demanda deve ser contada como manutenção em interface na funcionalidade de cadastro;

• Alteração de título de um relatório;

• Alteração de labels de uma tela de consulta.

d. Manutenção corretiva: implementação de ajustes no código de sistemas de informação com o intuito de corrigir defeitos e/ou deficiências que foram encontrados durante sua utilização, ou seja, nos sistemas em produção. Para isso, a empresa CONTRATADA deverá adotar ações de contorno que minimizem o impacto de falhas e/ou paradas no processo de negócio do Conselho e, principalmente, ações definitivas que garantam a continuidade do negócio, aumentando a confiança nos sistemas e reduzindo a necessidade de novos investimentos. Para esse tipo de demanda não será elaborado um escopo e realizada contagem estimada de pontos de função, devendo a CONTRATANTE abrir um ticket/ordem de serviço com as evidências de erros e/ou problemas e a CONTRATADA iniciar o atendimento conforme os prazos definidos nos níveis de serviço.

e. Verificação de erro: As verificações de erro ou análise e solução de problemas são as demandas referentes a todo comportamento anormal ou indevido apontado pelo cliente nos sistemas aplicativos. Neste caso, a equipe de desenvolvimento da CONTRATADA se mobilizará para encontrar as causas do problema ocorrido. Se for constatado algum erro de sistema, a demanda será atendida como manutenção corretiva ou defeito, conforme vigência da garantia.

f. Garantia: Quando o sistema em produção tiver sido desenvolvido pela CONTRATADA, a manutenção corretiva será assim classificada se estiver no período de cobertura e em conformidade com as demais condições de garantia previstas em contrato e nesta MGDS.

III) Serviço

Os serviços de sistemas de informação serão demandas pontuais solicitadas pelo CAU, que não envolvam tarefas e/ou atividades já previstas nas demandas do tipo: projeto ou sustentação, mas que dependam de conhecimento técnico sobre o(s) sistema(s);

São exemplos de serviço de sistemas de informação:

• Desenvolvimento e/ou manutenção de documentação dos Sistemas Legados;

• Configuração de ambiente;

• Publicação de conteúdo estático intranet e/ou internet;

• Desenvolvimento de script de banco de dados;

• Consultoria destinado à análise de regras de negócio a serem implementadas em soluções de TI ou para elaboração do documento de escopo, visão e roadmap do produto, dentre outros;

• Demais serviços considerados atividades sem contagem de pontos de função especificados no Roteiro de Métricas de Software do SISP.

5. Viabilidade da demanda

A aprovação da demanda estabelecerá um acordo formal entre a GESC e os usuários requisitantes para o escopo do produto a ser desenvolvido. A demanda deve considerar as premissas e diretrizes do PDTIC - Plano Diretor de Tecnologia da Informação e Comunicação e estar coerente com o mapa estratégico do CAU.

Com o objetivo de mitigar riscos, é importante a participação da GESC desde a concepção das ações dos projetos institucionais que envolvam soluções de tecnologia da informação, estabelecendo uma arquitetura de software estável que poderá ser desenvolvida ou mantida em termos tecnológicos, considerando os requisitos, limitações e restrições identificadas.

6. Macro Processo: Gestão em Desenvolvimento de Software

DIAGRAMA 1: MACROPROCESSO

Descrição dos procedimentos existentes no processo, exceto para demandas do tipo manutenção corretiva e serviços

ANÁLISE PRÉVIA

SEQ.	AÇÕES (descrição)	COORDENAÇÃO/ FUNÇÃO	SAÍDA OU PRODUTO
1	1.1. As áreas requisitantes devem descrever, de forma detalhada, sua necessidade e objetivos de negócio. Deverá especificar na demanda o ganho e o impacto corporativo, bem como as expectativas de prazo e custo, caso existam. A demanda deverá ser encaminhada para a unidade responsável na Gerência do CSC (GESC), indicando o representante da área de negócio que será o responsável designado para atuar em conjunto com o dono do produto (product owner) durante o ciclo de desenvolvimento da demanda de desenvolvimento de software.	Responsável da Área Requisitante	Protocolo ou demanda do GAD (gerenciador avançado de demandas).
2	2.1. O responsável na GESC avalia se a demanda possui as informações necessárias e se pode ser implementada. 2.2. Se a demanda não for viável, o chamado é fechado ou o protocolo é respondido indicando a inviabilidade e seus motivos. Neste caso o processo é encerrado. 2.3. Se a demanda for viável, o coordenador indica um colaborador para ser o dono do produto (product owner).	Coordenador do CSC ou responsável que avaliará a demanda.	Indicação de viabilidade da demanda. Dono do produto designado.
3	3.1. O dono do produto realiza a avaliação de criticidade da demanda usando a técnica GUT. 3.2. A demanda com a criticidade calculada é incluída na lista de backlog.	Dono do Produto	Demanda priorizada. Lista de backlog do produto atualizada.
4	4.1. A área Requisitante é comunicada da criticidade calculada e informada quanto ao prazo estimado para que a demanda seja iniciada. 4.2. A demanda fica aguardando a sua inclusão no Roadmap de execução do produto, considerando a priorização atribuída.	Coordenador do CSC ou responsável que avaliará a demanda.	Registro da priorização no protocolo ou GAD. Inclusão na demanda no Roadmap do produto.

SEQ.	AÇÕES (descrição)	COORDENAÇÃO/ FUNÇÃO	SAÍDA OU PRODUTO
5	5.1. O dono do produto entrevista o responsável da área requisitante e elabora o documento de escopo. Esse processo é cíclico e repetido até que todas as funcionalidades estejam mapeadas. Por essa razão o dono do produto e a área requisitante devem identificar as funcionalidades e características que geram valor e priorizá-las para inclusão nos releases do produto. 5.2. Sempre que necessário, a coordenadoria de TI será consultada para identificar os impactos das novas funcionalidades no produto, realizando planejamento das adequações quanto aos ativos de TI.	Dono do Produto Responsável da Área Requisitante Coordenadoria de TI	Documento de escopo. Roadmap do produto atualizado. Documento de adequações quanto aos ativos de TI.
6	6.1 O coordenador abre a ordem de serviço para a Fábrica de Métricas realizar a contagem estimada de pontos de função por release. 6.2 O coordenador apresenta ao Responsável da Área Requisitante o escopo, a contagem de pontos de função total e/ou por release, o custo e o prazo para execução. 6.3 Caso os custos e/ou prazos para execução da demanda não sejam aprovados pela área requisitante, a demanda é encerrada sem êxito. 6.4 O escopo aprovado deverá ser assinado pelo Dono do Produto e pelo Responsável da Área Requisitante.	Coordenador do CSC ou responsável pela demanda. Responsável da Área Requisitante;	Ordem de serviço para Fábrica de Métricas. Contagem estimada de pontos de função. Registro da informação no protocolo ou GAD. Documento de escopo atualizado e assinado. Roadmap do produto atualizado.
7	7.1. Aprovado o escopo, é criada a ordem de serviço na FSW para a construção do Projeto ou da Evolução. 7.1.1. A OS preferencialmente conterá todas as sprints de um release, e quando não for possível, deve contemplar, preferencialmente, ao menos duas sprints (colocar junto aos conceitos aplicáveis ao contrato – OS por release e OS por Sprint – SISP 7.1 e 7.2); 7.2 Autorizam a OS: o Fiscal Técnico e o Gerente de Projeto da Fábrica de Software; 7.3 Os documentos gerados nas etapas anteriores e relevantes para a execução da demanda devem ser encaminhados à FSW na OS.	Fiscal Técnico Gerente de Projeto da Fábrica de Software (FSW)	Ordem de Serviço para Fábrica de Software (FSW); Roadmap do produto atualizado;

PLANEJAMENTO E ENGENHARIA DE REQUISITOS

SEQ.	AÇÕES (descrição)	COORDENAÇÃO/ FUNÇÃO	SAÍDA OU PRODUTO
8	8.1. O representante da FSW recebe a OS e inicia sua execução. Devem ser observados: os níveis de serviço do contrato, a documentação solicitada na OS e a lista de artefatos e produtos especificado nesta MGDS para o tipo de demanda da OS. 8.1.1 A FSW indica os profissionais do time de desenvolvimento e agenda com o dono do produto preferencialmente para o primeiro dia de início de execução da OS a primeira reunião de entendimento e detalhamento da demanda.	Fábrica de Software (FSW) Dono do Produto	Artefatos / Produtos de acordo com o tipo da demanda Backlog do produto atualizado.

SEQ.	AÇÕES (descrição)	COORDENAÇÃO/ FUNÇÃO	SAÍDA OU PRODUTO
	8.2 A FSW planeja a execução da ordem de serviço, identificando as atividades necessárias de acordo com os produtos que devem ser entregues e elabora o(s) sprint(s) backlog(s). 8.3. O gerente do projeto ou líder do time de desenvolvimento deve apresentar o cronograma inicial para execução do sprint backlog para a aprovação dos envolvidos na demanda. Em caso de divergência serão realizadas reuniões de consenso. 8.3.1 O gerente de projeto pode apresentar uma contagem de pontos de função estimados e caso haja divergência, solicitar o replanejamento. Se comprovado e aceitos os argumentos, a OS pode ser alterada e replanejada, mediante autorização do Dono do Produto.
9	9.1.1 O gerente do projeto e o time de desenvolvimento da FSW devem iniciar o entendimento do escopo do projeto, detalhando a visão do produto, os objetivos de negócio, as características chaves do produto, o backlog do produto e o roadmap do produto. 9.1.2 O gerente do projeto deverá iniciar o planejamento do projeto considerando o roadmap apresentado na OS e detalhar o plano cronológico de liberação de releases. Esse é o momento para fazer os ajustes iniciais no roadmap do produto e no backlog do produto, caso o dono do produto concorde. 9.1.3 O dono do produto deverá garantir que foram documentados os critérios de aceitação do produto, que estão fortemente relacionados aos requisitos não funcionais e funcionais especificados. 9.1.3.1 O mapeamento de riscos deverá ser aprovado pelo Dono do Produto e pelo Fiscal Técnico. 9.1.3.1. O documento de arquitetura de software, quando aplicável, deve ser aprovado pelo Coordenadoria de TI do CSC. 9.2 Considerando que em demandas de manutenção abaixo de 100 PF as incertezas são menores, o processo de entendimento do time de desenvolvimento da FSW deve ser executado com maior celeridade.	Fábrica de Software (FSW) Dono do Produto (Product Owner)	Artefatos / Produtos da demanda de projeto. Sprint backlog elaborado Backlog do produto atualizado
10	10.1 Se demanda de manutenção (exceto corretiva): 10.1.1 Considerando que em demandas de manutenção abaixo de 100 PF as incertezas são menores, o processo de entendimento do time de desenvolvimento da FSW pode ser executado com maior celeridade. É esperado que em uma reunião com duração de 4 (quatro) horas seja possível entender escopo da manutenção e definir as atividades e apresentar o sprint backlog.	Fábrica de Software (FSW) Dono do Produto (product owner)	Artefatos / Produtos da demanda de manutenção. Sprint backlog elaborado Backlog do produto atualizado

ANÁLISE - PROJETO TÉCNICO - TESTE

SEQ.	AÇÕES (descrição)	COORDENAÇÃO/ FUNÇÃO	SAÍDA OU PRODUTO
11	11.1. O time de desenvolvimento executa as atividades planejadas, interage com o dono do produto quando necessário. Durante a sprint o time de desenvolvimento e o Scrum Master (ambos da FSW) realizam as reuniões diárias, registram as evoluções no kanban, e sinaliza quando os produtos ou artefatos devem ser homologados. O produto deve ser apresentado na reunião de demonstração da iteração. 11.2. A FSW, a critério do CAU, deve publicar o produto em um dos ambientes de testes e o time de teste da FSW deve: 11.2.1. Executar a publicação dos scripts unitários; 11.2.2. Elaborar a massa de testes; 11.2.3. Elaborar o script de automação de testes; 11.2.4. Realizar a filmagem com as evidências de testes que não puderam ser automatizados na opção acima. 11.3. O time de desenvolvimento deve garantir que o processo de teste verificou todos os critérios de aceitação, que estão relacionados aos requisitos não funcionais e funcionais especificados por meio das regras de negócio e de apresentação, bem como que o produto está atendendo às necessidades dos usuários. 11.4.Caso o produto passe no processo de testes da FSW, o produto e os artefatos de testes são disponibilizadas para o dono do produto.	Fábrica de Software (FSW) Dono do Produto (product owner)	Artefatos / Produtos de acordo com o tipo da demanda; Kanban atualizado; Sprint backlog atualizado; Backlog do produto atualizado; Roadmap atualizado;
12	12.1. O dono do produto aceita ou rejeita a entrega. O dono do produto deve validar se o produto atende às necessidades dos usuários e verificar se os artefatos construídos estão de acordo com as especificações. 12.2. Em caso de rejeição pelo dono do produto, o mesmo deve indicar individualmente os refinamentos necessários, ou seja, reportar as correções para que o produto atenda às necessidades dos usuários, e os erros encontrados em relação ao que foi especificado. Esse apontamento será usado para calcular os índices de qualidade. 12.2.1. Em caso de divergência entre a FSW e o dono do produto, será realizada reunião de consenso. 12.2.2. Os erros obrigatoriamente precisam ser corrigidos para a emissão do termo de recebimento provisório. Os refinamentos podem ser executados na sprint atual ou nas próximas sprints, releases ou ordens de serviço.	Fábrica de Software (FSW) Dono do Produto (product owner)	Produtos da etapa de testes de acordo com o tipo de demanda. Tempo de execução da OS registrado; Erros identificados apontados.

HOMOLOGAÇÃO

SEQ.	AÇÕES (descrição)	COORDENAÇÃO/ FUNÇÃO	SAÍDA OU PRODUTO
13	13.1. Na homologação, o dono do produto elabora o Termo de Recebimento Provisório – TRP e sinaliza para validação do Fiscal Técnico. 13.2. O Fiscal Técnico aceita o TRP – Termo de Recebimento Provisório autorizando o faturamento da OS de acordo com o percentual de esforço da etapa aceita. 13.3. Na homologação de artefatos específicos da disciplina de engenharia de software, o dono do produto pode solicitar o apoio da Coordenadoria de TI (CORTI) do CSC. São exemplos destes artefatos: Documento de arquitetura de software, Modelo de dados e Dicionários de dados. 13.4 Na homologação de regras e do produto, o dono do produto pode solicitar o apoio do responsável da área requisitante.	Fiscal Técnico Dono do Produto Responsável da Área Requisitante	Artefatos / Produtos de acordo com o tipo da demanda; Kanban atualizado; Tempo de execução da OS registrado; TRP
15	15.1 O dono do produto deve realizar a homologação validando o atingimento dos critérios de aprovação. 15.2. No 1º ciclo de homologação o dono do produto utilizará o mesmo ambiente de testes. O dono do produto pode complementar os testes com outros cenários com o objetivo de responder às seguintes perguntas: “Estamos construindo o produto certo?” “Estamos construindo certo o produto?” 15.3 Caso não seja homologado, o dono do produto deve seguir o fluxo do diagrama nº 4.	Dono do produto	Artefatos / Produtos de acordo com o tipo da demanda; Kanban atualizado; Sprint backlog atualizado; Backlog do produto atualizado; Roadmap atualizado; Tempo de execução da OS registrado; Erros identificados apontados.
16	16.1. Caso seja homologado, o dono do produto deve: 16.1.1. Decidir em conjunto com o Fiscal Técnico e com o Responsável da Área Requisitante se haverá a publicação da demanda, sendo esta realizada inicialmente no ambiente de homologação. 16.1.1.1. A homologação deve demonstrar o incremento do software para a Área Requisitante. 16.1.2. A publicação do produto pode ser postergada para ocorrer juntamente com outras sprints de um mesmo release.	Dono do produto Fiscal Técnico Responsável da Área Requisitante	Artefatos / Produtos de acordo com o tipo da demanda; Kanban atualizado; Sprint backlog atualizado; Backlog do produto atualizado; Roadmap atualizado;
17	00.0.Xx caso de publicação do produto: 17.1.2. O Fiscal Técnico deve planejar a publicação da TAG no ambiente de homologação e17.2. solicitar a TAG para a FSW; 17.2.1.O dono do produto deve solicitar a	Fiscal Técnico Dono do produto Responsável da Área Requisitante FSW CORTI	Artefatos / Produtos de acordo com o tipo da demanda; Kanban atualizado;

	elaboração do boletim ou aviso da RIA (rede integrada de atendimento) divulgando a publicação do produto; 17.2.2.1 A CORTI deve publicar a TAG e demais artefatos ou produtos no ambiente de homologação, incluindo os scripts de teste; 17.2.2.2. O dono do produto deve realizar o 2º ciclo de homologação no ambiente de homologação. O objetivo é fazer o último ciclo de testes de aceitação, usando os scripts automatizados com dados similares ao ambiente de produção. Estes scripts devem ajudar a reduzir o tempo dos testes. Sempre que possível é recomendado utilizar outros scripts automatizados para permitir a validação do impacto em outras partes do sistema. 17.2.2.3 O Responsável da Área Requisitante poderá participar do 2º ciclo de homologação. 17.3. Se o produto não for homologado: 17.3.1. Caso não seja homologado, o dono do produto deve seguir o fluxo diagrama 4.	RIA	Sprint backlog atualizado; Backlog do produto atualizado; Roadmap atualizado; TAG do produto; Boletim ou aviso da RIA Tempo de execução da OS registrado; Xxxxx identificados apontados;
19	19.1 A FSW ao final de cada sprint deve realizar a reunião de retrospectiva com o objetivo de identificar os pontos fortes e fracos, as oportunidades e os impedimentos detectados durante a execução da sprint. O resultado da retrospectiva deve ser apresentado ao CAU.	FSW Fiscal Técnico Fiscal Administrativo Dono do Produto Gestor do contrato	Sugestões de melhoria e ajustes no processo

SEQ.	AÇÕES (descrição)	COORDENAÇÃO/ FUNÇÃO	SAÍDA OU PRODUTO
20	20.1. Caso o produto seja homologado no 2º ciclo: 20.1.1. O Fiscal Técnico deve planejar a publicação da TAG no ambiente de produção; 20.1.2. A CORTI publica a TAG em ambiente de produção; 20.1.3 O dono do produto e o Fiscal Técnico registram o atendimento da demanda nas ferramentas de gestão (exemplos: sistema de controle de OS da FSW, GAD, protocolo, etc.) e comunicam os envolvidos; 20.1.4. Erros encontrados no ambiente de produção serão corrigidos por meio de OS de defeito, caso em garantia, ou por OS de manutenção corretiva.	Fiscal Técnico; Dono do produto; CORTI	Contagem detalhada de PF; Documento de Manutenção ;
21	21.1. Após a publicação em produção da última sprint do release: 21.1.1. O Fiscal Técnico abre a ordem de serviço para a Fábrica de Métricas (FM) realizar a contagem detalhada de pontos de função da OS; 21.1.1.1. Caso exista divergência entre a contagem detalhada da FSW e da FM, pode ser solicitada uma reunião de consenso. A quantidade de PF apurada no consenso é utilizada para o faturamento da OS. 21.1.2. O Fiscal Técnico calcula os índices de qualidade do contrato e emite o TRD – Termo de Recebimento Definitivo indicando os	Fiscal Técnico; Fiscal Administrativo; Gestor do contrato; FSW; FM;	Contagem Detalhada; TRD;

IMPLANTAÇÃO

SEQ.	AÇÕES (descrição)	COORDENAÇÃO/ FUNÇÃO	SAÍDA OU PRODUTO
	resultados apurados e a glosa caso exista. 21.1.3. O Fiscal Administrativo valida e aceita o TRD – Termo de recebimento definitivo, verificando se há necessidade de aplicação de penalidade e cumprindo as demais formalidades previstas no contrato. 21.1.4. Concluídos os procedimentos do item anterior, o Fiscal Administrativo autoriza o faturamento final da OS e o processo é encerrado.

Descrição dos procedimentos existentes no processo, para demandas do tipo manutenção corretiva e serviços

SEQ.	AÇÕES (descrição)	COORDENAÇÃO/ FUNÇÃO	SAÍDA OU PRODUTO
1	1.1. As áreas requisitantes devem descrever, de forma detalhada, sua necessidade e objetivos de negócio. Deverá especificar na demanda o ganho e o impacto corporativo, bem como as expectativas de prazo e custo, caso existam. A demanda deverá ser encaminhada para a unidade responsável na Gerência do CSC (GESC), indicando o representante da área de negócio que será o responsável designado para atuar em conjunto com o dono do produto (product owner) durante o ciclo de desenvolvimento da demanda de desenvolvimento de software.	Responsável da Área Requisitante	Protocolo ou demanda do GAD (gerenciador avançado de demandas).
2	2.1. O responsável na GESC avalia se a demanda possui as informações necessárias e se pode ser implementada. 2.2. Se a demanda não for viável, o chamado é fechado ou o protocolo é respondido indicando a inviabilidade e seus motivos. Neste caso o processo é encerrado. 2.3. Se a demanda for viável, o coordenador indica um colaborador para ser o dono do produto (product owner).	Coordenador do CSC ou responsável que avaliará a demanda.	Indicação de viabilidade da demanda. Dono do produto designado.
3	3.1. O dono do produto realiza a avaliação de criticidade da demanda usando a técnica GUT. 3.2. A demanda com a criticidade calculada é incluída na lista de backlog.	Dono do Produto	Demanda priorizada. Lista de backlog do produto atualizada.
4	4.1. A área Requisitante é comunicada da criticidade calculada e informada quanto ao prazo estimado para que a demanda seja iniciada. 4.2. A demanda fica aguardando a sua inclusão no Roadmap de execução do produto, considerando a priorização atribuída.	Coordenador do CSC ou responsável que avaliará a demanda.	Registro da priorização no protocolo ou GAD. Inclusão na demanda no Roadmap do produto.
5	5.1. Efetuado o escopo simplificado, é criada a ordem de serviço na FSW para a construção da Sustentação ou do serviço. 5.1.1. A OS preferencialmente conterá todas as sprints de um release, e quando não for possível, deve contemplar, preferencialmente,	Fiscal Técnico Gerente de Projeto da Fábrica de Software (FSW)	Ordem de Serviço para Fábrica de Software (FSW); Roadmap do

SEQ.	AÇÕES (descrição)	COORDENAÇÃO/ FUNÇÃO	SAÍDA OU PRODUTO
	ao menos duas sprints (colocar junto aos conceitos aplicáveis ao contrato – OS por release e OS por Sprint – SISP 7.1 e 7.2); 5.2 Autorizam a OS: o Fiscal Técnico e o Gerente de Projeto da Fábrica de Software; 5.3 Os documentos gerados nas etapas anteriores e relevantes para a execução da demanda devem ser encaminhados à FSW na OS.		produto atualizado;
6	6.1. O representante da FSW recebe a OS e inicia sua execução. Devem ser observados: os níveis de serviço do contrato, a documentação solicitada na OS e a lista de artefatos e produtos especificado nesta MGDS para o tipo de demanda da OS. 6.1.1 A FSW indica os profissionais do time de desenvolvimento e agenda com o dono do produto preferencialmente para o primeiro dia de início de execução da OS a primeira reunião de entendimento e detalhamento da demanda. 6.2 A FSW planeja a execução da ordem de serviço, identificando as atividades necessárias de acordo com os produtos que devem ser entregues e elabora o(s) sprint(s) backlog(s). 6.3 O gerente de projeto pode apresentar uma contagem de pontos de função estimados, e efetuar o planejamento.	Fábrica de Software (FSW) Dono do Produto	Artefatos / Produtos de acordo com o tipo da demanda Backlog do produto atualizado.
7	7.1. O gerente do projeto e o time de desenvolvimento da FSW devem iniciar o entendimento do escopo, detalhando a visão do produto, os objetivos de negócio, as características chaves do produto, o backlog do produto e o roadmap do produto. 7.1.2 O dono do produto deverá garantir que foram documentados os critérios de aceitação do produto, que estão fortemente relacionados aos requisitos não funcionais e funcionais especificados. 7.2 Considerando que em demandas de manutenção abaixo de 100 PF as incertezas são menores, o processo de entendimento do time de desenvolvimento da FSW deve ser executado com maior celeridade.	Fábrica de Software (FSW) Dono do Produto (Product Owner)	Artefatos / Produtos da demanda de projeto. Sprint backlog elaborado Backlog do produto atualizado
8	8.1. O time de desenvolvimento executa as atividades planejadas, interage com o dono do produto quando necessário. Durante a sprint o time de desenvolvimento e o Scrum Master (ambos da FSW) realizam as reuniões diárias, registram as evoluções no kanban, e sinaliza quando os produtos ou artefatos devem ser homologados. O produto deve ser apresentado na reunião de demonstração da iteração. 8.2. A FSW, a critério do CAU, deve publicar o produto em um dos ambientes de testes e o time de teste da FSW deve: 8.2.1. Executar a publicação dos scripts unitários; 8.2.2. Elaborar a massa de testes; 8.2.3. Elaborar o script de automação de testes; 8.2.4. Realizar a filmagem com as evidências de	Fábrica de Software (FSW) Dono do Produto (product owner)	Artefatos / Produtos de acordo com o tipo da demanda; Kanban atualizado; Sprint backlog atualizado; Backlog do produto atualizado; Roadmap atualizado;

SEQ.	AÇÕES (descrição)	COORDENAÇÃO/ FUNÇÃO	SAÍDA OU PRODUTO
	testes que não puderam ser automatizados na opção acima. 8.3. O time de desenvolvimento deve garantir que o processo de teste verificou todos os critérios de aceitação, que estão relacionados aos requisitos não funcionais e funcionais especificados por meio das regras de negócio e de apresentação, bem como que o produto está atendendo às necessidades dos usuários. 8.4.Caso o produto passe no processo de testes da FSW, o produto e os artefatos de testes são disponibilizadas para o dono do produto.
9	9.1. O dono do produto aceita ou rejeita a entrega. O dono do produto deve validar se o produto atende às necessidades dos usuários e verificar se os artefatos construídos estão de acordo com as especificações. 9.2. Em caso de rejeição pelo dono do produto, o mesmo deve indicar individualmente os refinamentos necessários, ou seja, reportar as correções para que o produto atenda às necessidades dos usuários, e os erros encontrados em relação ao que foi especificado. Esse apontamento será usado para calcular os índices de qualidade. 9.2.1. Em caso de divergência entre a FSW e o dono do produto, será realizada reunião de consenso. 9.2.2. Os erros obrigatoriamente precisam ser corrigidos para a emissão do termo de recebimento provisório. Os refinamentos podem ser executados na sprint atual ou nas próximas sprints, releases ou ordens de serviço.	Fábrica de Software (FSW) Dono do Produto (product owner)	Produtos da etapa de testes de acordo com o tipo de demanda. Tempo de execução da OS registrado; Erros identificados apontados.
10	10.1. Na homologação, o dono do produto elabora o Termo de Recebimento Provisório – TRP e sinaliza para validação do Fiscal Técnico. 10.2. O Fiscal Técnico aceita o TRP – Termo de Recebimento Provisório autorizando o faturamento da OS de acordo com o percentual de esforço da etapa aceita. 10.3. Na homologação de artefatos específicos da disciplina de engenharia de software, o dono do produto pode solicitar o apoio da Coordenadoria de TI (CORTI) do CSC. São exemplos destes artefatos: Documento de arquitetura de software, Modelo de dados e Dicionários de dados. 10.4 Na homologação de regras e do produto, o dono do produto pode solicitar o apoio do responsável da área requisitante.	Fiscal Técnico Dono do Produto Responsável da Área Requisitante	Artefatos / Produtos de acordo com o tipo da demanda; Kanban atualizado; Tempo de execução da OS registrado; TRP
11	11.1 O dono do produto deve realizar a homologação validando o atingimento dos critérios de aprovação. 11.2. No 1º ciclo de homologação o dono do produto utilizará o mesmo ambiente de testes. O dono do produto pode complementar os testes com outros cenários com o objetivo de responder às seguintes perguntas:	Dono do produto	Artefatos / Produtos de acordo com o tipo da demanda; Kanban atualizado; Sprint backlog

SEQ.	AÇÕES (descrição)	COORDENAÇÃO/ FUNÇÃO	SAÍDA OU PRODUTO
	“Estamos construindo o produto certo?” “Estamos construindo certo o produto?” 15.3 Caso não seja homologado, o dono do produto deve seguir o fluxo diagrama nº 4		atualizado; Backlog do produto atualizado; Roadmap atualizado; Tempo de execução da OS registrado; Erros identificados apontados.
12	12.1. Caso seja homologado, o dono do produto deve: 12.1.1. Decidir em conjunto com o Fiscal Técnico e com o Responsável da Área Requisitante se haverá a publicação da demanda, sendo esta realizada inicialmente no ambiente de homologação. 12.1.1.1. A homologação deve demonstrar o incremento do software para a Área Requisitante.	Dono do produto Fiscal Técnico Responsável da Área Requisitante	Artefatos / Produtos de acordo com o tipo da demanda; Kanban atualizado; Sprint backlog atualizado; Backlog do produto atualizado; Roadmap atualizado;
13	13.1 No caso de publicação do produto: 13.1.2. O Fiscal Técnico deve planejar a publicação da TAG no ambiente de homologação e 13.2. solicitar a TAG para a FSW; 13.2.1 O dono do produto deve solicitar a elaboração do boletim ou aviso da RIA (rede integrada de atendimento) divulgando a publicação do produto, caso necessário. 13.2.2 A CORTI deve publicar a TAG e demais artefatos ou produtos no ambiente de homologação, incluindo os scripts de teste; 13.2.2.1. O dono do produto deve realizar o 2º ciclo de homologação no ambiente de homologação. 13.3. Se o produto não for homologado: 13.3.1. Caso não seja homologado, o dono do produto deve seguir o fluxo do diagrama 4.	Fiscal Técnico Dono do produto Responsável da Área Requisitante FSW CORTI RIA	Artefatos / Produtos de acordo com o tipo da demanda; Kanban atualizado; Sprint backlog atualizado; Backlog do produto atualizado; Roadmap atualizado; TAG do produto; Boletim ou aviso da RIA Tempo de execução da OS registrado; Erros identificados apontados;
14	14.1. Caso o produto seja homologado no 2º ciclo: 14.1.1. O Fiscal Técnico deve planejar a publicação da TAG no ambiente de produção; 14.1.2. A CORTI publica a TAG em ambiente de produção; 14.1.3 O dono do produto e o Fiscal Técnico registram o atendimento da demanda nas	Fiscal Técnico; Dono do produto; CORTI	Contagem detalhada de PF; Documento de Manutenção;