Tribunal Regional Eleitoral de São Paulo
ESTUDO TÉCNICO PRELIMINAR 
Modelo v. 4.0
SEI nº 0059990-77.2022.6.26.8000

Contratação de desenvolvimento e sustentação do Sistema Nacional de Condenações Eleitorais
São Paulo, março de 2023.

Histórico de Revisões
Data	Versão	Descrição	Autor	
27/03/2023	1.0	Finalização da primeira versão do documento	Cândido Luís Dias Ferreira, Taís Rigon Belintani 	
24/11/2023	1.1	Alterações em vários pontos para adequação ao TR	Cândido Luís Dias Ferreira 	
27/11/2023	1.2	Correção da numeração	Cândido Luís Dias Ferreira 	
30/11/2023	1.3	Correção de somas de valores de salários de squad, nos itens 4.6.3.1 e 6.2	Cândido Luís Dias Ferreira	
XX/XX/20XX	2.0	Revisão do documento após análise jurídica	XXXXXXXXXXXX	
ESTUDO TÉCNICO PRELIMINAR 

INTRODUÇÃO	
O Estudo Técnico Preliminar tem por objetivo identificar e analisar os cenários para o atendimento da demanda que consta no Documento de Oficialização da Demanda, bem como demonstrar a viabilidade técnica e econômica das soluções identificadas, fornecendo as informações necessárias para subsidiar o respectivo processo de contratação. É o documento que descreve as análises realizadas em relação às condições da contratação em termos de necessidades, requisitos, alternativas, escolhas, resultados pretendidos e demais características, e que demonstra a viabilidade técnica e econômica da contratação.

Referência: Guia de Contratações de TIC do Poder Judiciário (CNJ/ v. 4.0)	

1 – IDENTIFICAÇÃO	
Trata-se da contratação de prestação de serviços especializados em desenvolvimento, manutenção evolutiva,   e sustentação de sistemas para produção de um sistema nacional para o gerenciamento de condenações e multas eleitorais, conforme Acordo de Cooperação Técnica TSE nº 81/2022, a ser utilizado por toda a Justiça Eleitoral, padronizando o tratamento das condenações eleitorais, além de permitir economia de escala, por se tratar de um único sistema para todos os tribunais regionais eleitorais, os quais não perceberão custos adicionais para o seu uso, tendo como objetivos: o tratamento de multas para mesário faltoso; tratamento de multas para eleitor ausente às urnas; tratamento de multas criminais; tratamento de multas eleitorais e processuais; tratamento de condenações que não geram pagamento ao erário; geração de GRU para pagamento de multas; cálculo do valor e parcelamento das multas; emissão de relatórios e avisos; emissão de quitação eleitoral; emissão de quitação, geração, consulta e atualização de GRU pela internet para parte interessada; integração com sistema PJe; integração com sistema ELO e ou cadastro eleitoral;  integração com sistema SICO; integração com sistema do executivo federal; gestão das condenações inseridas no sistema; cadastramento de condenações; acompanhamento de condenações; informação ao público externo sobre dados de condenações (valores arrecadados, totais de condenações por tipo, faixa de datas e instâncias).	

2 – DEFINIÇÃO E ESPECIFICAÇÃO DAS NECESSIDADES E REQUISITOS	

Identificação das necessidades de negócio	
2.1	Ver Anexo I e II (documento de arquitetura candidata e glossário).	

Identificação das necessidades tecnológicas	
2.2	A aplicação deverá ser responsiva, isto é, deverá ser possível acessá-la tanto de um computador quanto de dispositivos móveis.	
2.3	Deverá ser utilizado padrão arquitetural definido pelo TSE, o qual inclui as tecnologias  Git; Java - jdk8u322 (recomendável) ou superior;  NodeJS 12.x.x (recomendável); Angular 12.x.x (recomendável) ou superior; Spring Boot - 2.6.10 (recomendável) ou superior; Jboss 7.3 (recomendável) ou superior; Rancher + Openshift; Docker; Kubernetes; 3scale RedHat.	
2.4	As abordagens para desenvolvimento devem  ser compatíveis com as utilizadas no TSE, tais como: SOLID; Test Driven Development (TDD); Domain-Driven Design (DDD); Clean Architecture; Arquitetura Hexagonal; ferramentas de qualidade de código; a metodologia ágil de desenvolvimento (framework ágil e portarias e manuais respectivos), desenvolvimento seguro.	
2.5	Na produção do sistema deverá ser utilizada infraestrutura do TSE, incluindo-se: sistema de controle de versões (Git); software Redmine; ferramenta de autenticação/autorização; mecanismo de captcha.	
2.6	Como podem ocorrer atualizações na plataforma do TSE, as versões dos softwares devem ser confirmadas no momento do desenvolvimento do sistema.	

Demais requisitos necessários e suficientes à escolha da solução de TIC	
2.7	Time scrum para desenvolvimento e sustentação do sistema.	
2.8	A equipe scrum realizará os trabalhos de desenvolvimento e sustentação de forma híbrida, podendo atuar tanto nas dependências do TRE-SP quanto fora das unidades da Justiça Eleitoral.	
2.9	As cerimônias do Scrum, tais como planejamento e revisão de sprint,  nas quais são necessárias as participações das áreas de negócio da CONTRATANTE realizar-se-ão preferencialmente por videoconferência. Nessas cerimônias toda a squad alocada para a sprint deve participar.	
2.9.1	A critério da CONTRATANTE, sempre que for necessário, as reuniões realizar-se-ão de forma presencial, na sede do TRE-SP, com despesas de deslocamento e hospedagem custeadas pela CONTRATADA.	
2.10	Um gerente de contrato (preposto) deverá estar disponível todos os dias úteis, no horário das 11h00 às 19h00, para contato com o TRE-SP durante o contrato. Esse profissional, com conhecimento suficiente em gestão de contratos de projetos de desenvolvimento de sistemas, deverá representar a CONTRATADA perante o CONTRATANTE e desempenhar as atividades administrativas de gerenciamento do contrato, tais como: receber as demandas, alocar e coordenar as equipes da CONTRATADA para a execução das demandas, assegurar que o projeto seja executado  no prazo, com todos os objetivos alcançados, em conformidade com o acordo de nível de serviço, apresentar relatório de conclusão dos serviços que comporão a fatura mensal e outras atividades pertinentes. 	
2.11	Nos casos em que um profissional não atender às qualificações técnicas e ou comportamentais necessárias ao bom andamento do projeto, a CONTRATANTE poderá solicitar, sem ônus, a troca do profissional. Visando reduzir o impacto da mudança, a troca de um profissional deverá ser feita antes de se iniciar uma sprint nova.	
2.12	Por não se tratar de um sistema de gestão documental, não será necessária a adesão ao Modelo de Requisitos para Sistemas Informatizados de Gestão de Processos e Documentos do Poder Judiciário (Moreq-Jus).	
2.13	No que couber, o Modelo Nacional de Interoperabilidade, MNI, deve ser utilizado para o desenvolvimento do sistema.	
2.14	A contratação inclui a posse, por parte da Justiça Eleitoral, da propriedade intelectual do sistema, incluindo-se todos os códigos fontes, scripts, bibliotecas e componentes de software utilizados.	
2.15	Não será permitido o uso de bibliotecas e componentes de software ou serviços de tecnologia da informação e comunicação que impliquem pagamentos adicionais ao desenvolvimento do sistema. De modo análogo, não será permitido para o desenvolvimento e operação do sistema o pagamento de licenças e serviços supervenientes ao desenvolvimento do sistema.	
2.16	A CONTRATADA deve concordar com os termos de confidencialidade da Justiça Eleitoral e garantir a privacidade dos dados obtidos para desenvolvimento e testes do sistema.	
2.17	A CONTRATADA deverá oferecer treinamento para as áreas envolvidas, com instruções escritas e no formato de vídeos, considerando-se os diversos perfis de utilização.	
2.18	A concessão à CONTRATADA de perfis de acesso ao ambiente oficial da CONTRATANTE poderá ser revisada durante a execução do contrato, assegurando-se à CONTRATADA perfis de acesso em ambientes de desenvolvimento e homologação. Após o fim do contrato, os perfis de acesso e outros dados necessários para desenvolvimento da solução serão eliminados, conforme a política de segurança da informação vigente.	
2.19	A critério da CONTRATANTE, os trabalhos de desenvolvimento e sustentação realizar-se-ão de forma híbrida, tanto nas dependências do TRE-SP quanto fora das unidades da Justiça Eleitoral. Quando houver o uso de locações não pertencentes à CONTRATANTE, a responsabilidade e custos serão da CONTRATADA.	
2.20	A CONTRATADA garantirá os produtos e serviços entregues pelo período de 90 (noventa) dias, contados a partir do recebimento definitivo da última Sprint do contrato.	
2.21	Antes e durante o período de garantia, a CONTRATADA deverá corrigir quaisquer defeitos encontrados nos serviços e produtos entregues. Um defeito consiste, dentre outros, em imperfeições, ausência de artefatos ou documentos obrigatórios, ou ainda, em quaisquer ocorrências que impeçam o funcionamento normal da solução, ou que não se apresentem compatíveis aos níveis mínimos de serviço exigidos.	
2.22	O prazo de vigência da contratação será de 1 (um) ano, podendo ser prorrogado, a critério da CONTRATANTE.	

3 – ESTIMATIVA DA DEMANDA – QUANTIDADE DE BENS E SERVIÇOS	

3.1	Será contratada empresa para desenvolver, oferecer treinamento para uso do sistema (turma única) e sustentar o Sistema de Condenações Eleitorais por meio de abordagens ágeis. 

3.1.1 O formato de trabalho para desenvolvimento e manutenção evolutiva será por equipe scrum, dentro dos limites concebidos para o sucesso do projeto, conforme definido a seguir:
1.	Scrum master: um, nível sênior;
2.	Analistas de testes:  mínimo um e máximo três; nível sênior;
3.	Analista de Negócios/Requisitos:  um, nível sênior;
4.	Desenvolvedores full stack:  mínimo quatro e máximo oito; nível sênior;
5.	Arquitetos de software:  um, nível sênior, com conhecimentos nas arquiteturas e tecnologias utilizadas pelo TSE (indicadas acima em Identificação das necessidades tecnológicas); 
6.	Administrador de base de dados: um, nível sênior.

3.1.2 A sustentação será executada por um desenvolvedor full stack sênior alocado exclusivamente para o serviço.

3.1.3 A composição da equipe responsável para oferecer o treinamento para uso do sistema ficará por conta da CONTRATADA.

3.2    As sprints terão duração de dez dias úteis, com início formalizado por meio de ordem de serviço. Na ordem de serviço devem ser inseridas as histórias do backlog que comporão a sprint, segundo as necessidades definidas pelo TRE-SP, mensuradas por pontos de casos de uso.  Inicialmente, estima-se a necessidade de doze sprints para a primeira versão em produção do sistema e outras doze para evolução e sustentação no primeiro ano de contrato.

 3.3    A elicitação de requisitos e criação do backlog do projeto de desenvolvimento e sustentação do sistema ficarão a cargo da CONTRATADA, sempre em cooperação com a CONTRATANTE.

 3.4    	O pagamento de cada ordem de serviço ocorrerá após certificado emitido pela CONTRATANTE atestando a conformidade dos resultados das sprints com os níveis de serviço esperados.

3.4.1 Para atestar a conformidade das entregas de software de cada sprint a CONTRATANTE:

3.4.1.1 executará os casos de testes automatizados, unitários e de integração elaborados pela CONTRATADA;

3.4.1.1.1  além dos testes das entregas previstas na ordem de serviço a CONTRATANTE poderá, conforme julgar adequado, incluir casos de testes por sua responsabilidade;

3.4.1.2 executará testes funcionais;

3.4.1.3 poderá executar verificação direta do código do software para garantir qualidade, aderência aos padrões previstos no contrato e às melhores práticas e padrões disponíveis para desenvolvimento de sistemas; 
 
3.4.1.4  verificará a correção  e completude dos artefatos gerados.

4 – ANÁLISE DE SOLUÇÕES POSSÍVEIS	
 
4.1   Não existe solução de software disponível para o tratamento de condenações e multas eleitorais com o escopo previsto no atual projeto, na Justiça Eleitoral ou fora dela, daí a necessidade do desenvolvimento de novo sistema. A criação do novo sistema poderia ocorrer por desenvolvimento interno ou por contratação do desenvolvimento. A opção pela contratação do serviço de desenvolvimento deve-se à falta de recursos na Justiça Eleitoral para o trabalho interno de desenvolvimento e sustentação. As soluções apresentadas a seguir referem-se ao modelo de contratação de equipe/formato de trabalho e mensuração de sistemas para contratação do desenvolvimento e sustentação.
 
4.2   O Ministério da Educação, no Estudo Técnico Preliminar para contratação de serviços de desenvolvimento e sustentação de aplicações de software (Cf. https://www.gov.br/mec/pt-br/media/licitacao/estudos_tecnicos_premilinares/PE202021MEC_A_ETPC_DSS_v3_29112021.pdf) apresentou uma coletânea sobre alternativas para execução de contrato de desenvolvimento de sistemas de informação, das quais apresenta-se um resumo a seguir.

4.2.1   Modelo de posto de serviço tradicional, modelo de 

prestação de serviços de desenvolvimento  ocorre com a alocação de postos de trabalho, em que os técnicos, em quantidade determinada, são alocados no órgão e distribuídos entre as áreas conforme suas especialidades e com dedicação exclusiva ao atendimento das demandas do contratante.

           Esse modelo, todavia, possui jurisprudência na Súmula TCU 269 indicando que a remuneração deve estar vinculada a resultados, caracterizando-se o pagamento por hora de trabalho ou posto de trabalho uma condição excepcional.

4.2.2   Modelo de tempo e recurso, que se apresenta como um modelo híbrido, combinando aspectos de custos fixos com serviços sob demanda.  Esse modelo possui as divisões indicadas a seguir.

4.2.2.1   Métrica homem/hora, na qual há subjetividade na avaliação do gasto do trabalho humano para mensurar a realização de uma tarefa. Essa métrica também pode apresentar o paradoxo lucro-incompetência, em que uma maior quantidade de pessoas menos qualificadas implica maior número de horas para execução de uma tarefa e, portanto, aumentar o valor pago pela contratante e aumentar o lucro da empresa contratada.

4.2.2.2    Métrica hora de serviço técnico, que é diferente da métrica Homem-hora, pois ela não se propõe a aferir o tempo presencial na execução das tarefas, mas todo o esforço necessário e riscos envolvidos para sua realização. O próprio Ministério da Educação considera essa opção viável, mas um dos seus fatores de sucesso é o maior nível de detalhamento possível, o que não é exatamente compatível com o desenvolvimento tocado por metodologias ágeis.

4.2.2.3    Métrica capacidade gerenciada, um dos modelos mais comumente utilizados em nível global para contratação de desenvolvimento associado a modelos ágeis. Essa abordagem envolve o desenvolvimento e aproveitamento de recursos variados, tais como recursos financeiros, habilidades humanas, recursos de tecnologia da informação, para citar apenas alguns. O Ministério da Educação ainda informa que

esse modelo é recomendado para cenários com maturidade ágil ainda em níveis iniciais, para contratantes que ainda não possuem experiência ampla o suficiente para dominar todos os aspectos de projetos ágeis – incluindo definição clara de escopo de projeto, controle de mudanças/escopo e corresponsabilidade ampla das áreas de negócio em relação aos projetos.

     Essa foi a métrica adotada pelo Ministério da Educação na licitação discutida. 

4.2.3    Modelo preço fixo, o qual exige que o escopo seja fixo ou que, em sua impossibilidade, o porcentual de mudanças seja conhecido e controlado, o que não é o caso do Sistema de Condenações. Esse modelo pode trazer prejuízos à contratante, que pode pagar mais do que recebe como produto funcional, como para a contratada, que pode precisar gastar mais do que o previsto para executar o contrato.

4.2.4   O Modelo unidade de medida exige algum tipo de métrica para avaliar e quantificar os serviços prestados, como, por exemplo, o volume de usuários ou quantidade de tickets gerenciados num service desk.

4.2.4.1  Métrica ponto de função, utiliza uma medida de tamanho funcional de software, não avaliando por completo usabilidade e complexidade. Embora seja uma métrica bastante utilizada no mercado de tecnologia da informação, o Ministério da Educação aponta alguns riscos relevantes:

um dos pontos críticos de aplicação dessa métrica é a existência e disponibilidade de documentação correta e completa das aplicações a serem mensuradas (diagrama de fluxo de dados, modelos de relacionamento de entidade, modelos de objeto e documento de requisitos, por exemplo). Se essa documentação não estiver disponível a contagem poderá ser ineficiente, difícil e cara. Quando a métrica de Ponto de Função é aplicada como forma de remuneração do desenvolvedor, é necessário que o contratante possua capacidade própria e/ou independente de modo a garantir que as regras de mensuração estejam sendo aplicadas de forma correta – assim, nesse cenário, não são incomuns os conflitos entre contratada e contratante em torno da aplicação dessas regras.

     No caso da contratação do desenvolvimento do Sistema de Condenações Eleitorais, não se possui o escopo completamente fechado ou outros artefatos indicados, como diagrama de fluxo de dados e modelo entidade relacionamento, embora o modelo de requisitos esteja maduro (ainda que não imutável). O TRE-SP também não possui experiência no uso de pontos de função, o que colocaria em risco a correta precificação do serviço, se escolhida essa métrica.	

4.2.4.2    Métrica story points, bastante utilizada em desenvolvimento por metodologias ágeis, utiliza o dimensionamento subjetivo que uma dada equipe aplica às histórias que pretende implementar uma sprint. Essa métrica, embora eficiente para indicar a produtividade de uma equipe e a evolução de sua produtividade, não possui definições padronizadas para produtividade de qualquer equipe, o que torna difícil sua utilização na contratação de desenvolvimento de sistemas.

4.2.4.3    Métrica linha de código é baseada na quantidade de linhas código criadas, mas essa métrica está em desuso em contratos de desenvolvimento de sistemas por ter amplo descrédito.

4.2.4.4    Métrica unidade de serviço técnico tem a seguinte posição do Ministério da Educação: 

a métrica Unidade de Serviço Técnico (UST, ou assemelhadas)  passou a ser adotada de forma genérica nos contratos públicos, no entanto, não há uma definição clara do que seja UST e/ou de quais parâmetros são válidos para definir seu escopo e suas características. Fato é que cada órgão parece aplicar a UST a seu próprio modo, geralmente vinculada a um catálogo ou à lista de atividades com parâmetros personalizados.
O Tribunal de Contas da União já se manifestou acerca dos riscos e das fragilidades advindas da utilização indiscriminada dessa métrica, que tem se tornado cada vez menos aplicada nos contratos de serviços de desenvolvimento e sustentação de software.

4.2.4.5   A contratação e pagamento por preço fixo por sprint executada é uma possibilidade prevista na PORTARIA SGD/MGI Nº 750, DE 20 DE MARÇO DE 2023, em Artigo 5º, com a ressalva de ser vinculado a níveis mínimos de serviço.

4.3     A dependência por parte do TRE-SP da CONTRATADA e possíveis riscos de sua substituição durante o projeto são minimizados pelos seguintes fatores: 

4.3.1  a propriedade intelectual de todos os artefatos produzidos, bem como códigos fontes, serão do TRE-SP (Cf. item 2.14 e 2.15);

4.3.2 existe obrigatoriedade do uso de padrões de desenvolvimento, plataformas e tecnologias definidas pelo TSE (Cf. itens 2.3, 2.4 e 2.5); 

4.3.3   	a abordagem ágil utilizada para o desenvolvimento do sistema define entregas de produtos de software e demais artefatos gerados em períodos curtos, cujo material já ficará em posse do TRE-SP (Cf. item 3.2); 

4.3.4    a elicitação de requisitos e criação do backlog terão acompanhamento de perto por parte do TRE-SP (Cf. item 3.3).Cf. item 3.3).
 
 4.4 – IDENTIFICAÇÃO DAS SOLUÇÕES

	A seguir, são listados os formatos de trabalho e medidas de custo vistos acima para contratação de desenvolvimento e sustentação de sistemas.

Id	Descrição da solução (ou cenário)	
1	Posto de trabalho tradicional	
2	Métrica homem/hora		
3	Métrica hora de serviço técnico	
4	Métrica capacidade gerenciada	
5	Modelo preço fixo	
6	Métrica ponto de função	
7	Métrica story points	
8	Métrica linha de código	
9	Métrica unidade de serviço técnico	
10	Pagamento por sprint	

4.5 – ANÁLISE COMPARATIVA DE SOLUÇÕES

Requisito	Solução	Sim	Não	Não se Aplica	
A Solução encontra-se implantada em outro órgão ou entidade da Administração Pública? 
	Solução 1	X			
	Solução 2	X			
	Solução 3	X			
	Solução 4	X			
	Solução 5	X			
	Solução 6	X			
	Solução 7		X		
	Solução 8			X	
	Solução 9	X			
	Solução 10	X			
A Solução está disponível no Portal do Software Público Brasileiro?
(quando se tratar de software)	Solução 1			X	
	Solução 2			X	
	Solução 3			X	
	Solução 4			X	
	Solução 5			X	
	Solução 6			X	
	Solução 7			X	
	Solução 8			X	
	Solução 9			X	
	Solução 10			X	
A Solução é composta por software livre ou software público?
(quando se tratar de software)	Solução 1			X	
	Solução 2			X	
	Solução 3			X	
	Solução 4			X	
	Solução 5			X	
	Solução 6			X	
	Solução 7			X	
	Solução 8			X	
	Solução 9			X	
	Solução 10			X	
A Solução é aderente às políticas, premissas e especificações técnicas definidas pelos Padrões de governo ePing, eMag, ePWG?	Solução 1			X	
	Solução 2			X	
	Solução 3			X	
	Solução 4			X	
	Solução 5			X	
	Solução 6			X	
	Solução 7			X	
	Solução 8			X	
	Solução 9			X	
	Solução 10			X	
A Solução é aderente às regulamentações da ICP-Brasil?
(quando houver necessidade de certificação digital)	Solução 1			X	
	Solução 2			X	
	Solução 3			X	
	Solução 4			X	
	Solução 5			X	
	Solução 6			X	
	Solução 7			X	
	Solução 8			X	
	Solução 9			X	
	Solução 10			X	
A Solução é aderente às orientações, premissas e especificações técnicas e funcionais do e-ARQ Brasil? (quando o objetivo da solução abranger documentos arquivísticos)	Solução 1			X	
	Solução 2			X	
	Solução 3			X	
	Solução 4			X	
	Solução 5			X	
	Solução 6			X	
	Solução 7			X	
	Solução 8			X	
	Solução 9			X	
	Solução 10			X	

4.6 – PESQUISA DE PREÇOS DE MERCADO

4.6.1  Foram excluídas dessa pesquisa as soluções consideradas inviáveis (Cf. cláusula 5).

Id	Descrição da solução (ou cenário)	
1	Posto de trabalho tradicional - solução inviável.	
2	Métrica homem/hora - solução inviável.		
3	Métrica hora de serviço técnico - solução inviável.	
4	Métrica capacidade gerenciada.	
5	Modelo preço fixo - solução inviável.	
6	Métrica ponto de função - solução inviável.	
7	Métrica story points - solução inviável.	
8	Métrica linha de código - solução inviável.	
9	Métrica unidade de serviço técnico - solução inviável. 	
10	Pagamento por sprint	

4.6.2     Para uso da métrica capacidade gerenciada e do formato de trabalho squad as service, conforme definido na estimativa de demanda (Cf. item 3.1), calcula-se que a CONTRATADA deva oferecer uma equipe de tamanho configurável, conforme o momento do projeto, variando de sete, o mínimo, até até quinze integrantes, o tamanho máximo da squad. Todos os integrantes da equipe são relacionados abaixo.

1.	Scrum master: um, nível sênior, 20 horas, com valor aproximado de R$5.990,34, conforme tabela a seguir (metade do valor de um profissional em tempo integral).

Fonte	Data	Salário mensal (40 horas)	Observações	
https://br.indeed.com/career/scrum-master/salaries/S%C3%A3o-Paulo--SP	20/03/2022	R$ 8.611,00	Média de São Paulo, SP.	
https://www.glassdoor.com.br/Sal%C3%A1rios/brasil-scrum-master-s%C3%AAnior-sal%C3%A1rio-SRCH_IL.0,6_IN36_KO7,26.htm?clickSource=searchBtn	20/03/2022	R$ 11.500,00	Média de São Paulo, SP.	
https://canaltech.com.br/carreira/confira-o-guia-salarial-para-profissionais-de-ti-em-2023-241896/	20/03/2022	R$ 13.560,23	Média entre as cidades de São Paulo, Rio de Janeiro, Belo Horizonte e as regiões Norte, Nordeste, Centro-Oeste e Sul.	
https://www.agazeta.com.br/es/economia/veja-a-lista-das-profissoes-que-estarao-em-alta-em-2023-e-os-salarios-0123	20/03/2022	R$ 14.500,00	Indicado de R$ 12.000,00 a R$ 17.000,00. A estimativa não indica região.	
Valor PORTARIA SGD/MGI Nº 750, DE 20 DE MARÇO DE 2023	20/03/2023	R$ 11.732,20		
		R$ 11.980,69
	Média geral para 40 horas semanais	

2.	Analistas de testes:  um; nível sênior, com valor unitário médio mensal de R$9.328,23,  conforme tabela a seguir.

Fonte	Data	Salário mensal	Observações	
https://br.indeed.com/career/analista-de-teste/salaries/S%C3%A3o-Paulo--SP?from=top_sb	20/03/2022	R$ 5.110,00	Média de São Paulo, SP.	
https://www.glassdoor.com.br/Sal%C3%A1rios/s%C3%A3o-paulo-analista-de-teste-senior-sal%C3%A1rio-SRCH_IL.0,9_IM1009_KO10,34.htm?clickSource=searchBtn	20/03/2022	R$ 8.076,00	Média de São Paulo, SP.	
https://canaltech.com.br/carreira/confira-o-guia-salarial-para-profissionais-de-ti-em-2023-241896/	20/03/2022	R$12.008,75	Média entre as cidades de São Paulo, Rio de Janeiro, Belo Horizonte e as regiões Norte, Nordeste, Centro-Oeste e Sul.	
Valor PORTARIA SGD/MGI Nº 750, DE 20 DE MARÇO DE 2023	20/03/2023	R$ 11.081,16		
Proposta EMBRATEL	23/03/2023	R$ 10.365,24		
		R$9.328,23	Média geral para 40 horas semanais	

1.	Analista de Negócios/Requisitos: um; nível sênior, com valor unitário médio mensal de R$8.580,31, conforme tabela a seguir.

Fonte	Data	Salário mensal	Observações	
https://br.indeed.com/career/analista-de-requisitos/salaries/S%C3%A3o-Paulo--SP?from=top_sb	20/03/2022	R$ 6.388,00	Média de São Paulo, SP.	
https://www.glassdoor.com.br/Sal%C3%A1rios/s%C3%A3o-paulo-analista-de-requisitos-sal%C3%A1rio-SRCH_IL.0,9_IM1009_KO10,32.htm	20/03/2022	R$ 8.125,00	Média de São Paulo, SP.	
Valor PORTARIA SGD/MGI Nº 750, DE 20 DE MARÇO DE 2023	20/03/2023	R$ 11.227,93		

2.	Desenvolvedores full stack:  quatro; nível sênior, com valor unitário médio mensal para sênior de R$ 12.649,30 e total médio mensal de R$ 50.597,20, conforme tabela a seguir.

Fonte	Data 	Salário mensal sênior	Observações	
https://br.indeed.com/career/devops/salaries/S%C3%A3o-Paulo--SP?from=top_sb	20/03/2022	R$ 8.437,00	Média de São Paulo, SP.	
https://www.glassdoor.com.br/Sal%C3%A1rios/s%C3%A3o-paulo-desenvolvedor-full-stack-senior-sal%C3%A1rio-SRCH_IL.0,9_IM1009_KO10,41.htm?clickSource=searchBtn	20/03/2022	R$ 10.128 ,00	Média de São Paulo, SP.	
https://canaltech.com.br/carreira/confira-o-guia-salarial-para-profissionais-de-ti-em-2023-241896/	20/03/2022	R$ 12.411,90	Média entre as cidades de São Paulo, Rio de Janeiro, Belo Horizonte e as regiões Norte, Nordeste, Centro-Oeste e Sul.	
Valor PORTARIA SGD/MGI Nº 750, DE 20 DE MARÇO DE 2023	20/03/2023	R$ 14.016,77		
Proposta EMBRATEL	23/03/2023	R$ 15.731,54		
		R$ 12.649,30	Média geral para 40 horas semanais	

3.	Arquitetos de software:  um, nível sênior, com valor unitário médio mensal de R$ 14.637,18, conforme tabela a seguir.

Fonte	Data	Salário mensal	Observações	
https://br.indeed.com/career/arquiteto-de-software/salaries/S%C3%A3o-Paulo--SP	21/03/2022	R$ 13.407,00	Média de São Paulo, SP.	
https://www.glassdoor.com.br/Sal%C3%A1rios/s%C3%A3o-paulo-arquiteto-de-software-sal%C3%A1rio-SRCH_IL.0,9_IM1009_KO10,31.htm?clickSource=searchBtn	21/03/2022	R$ 14.00000	Média de São Paulo, SP.	
https://canaltech.com.br/carreira/confira-o-guia-salarial-para-profissionais-de-ti-em-2023-241896/	21/03/2022	R$ 12.420,00	Média entre as cidades de São Paulo, Rio de Janeiro, Belo Horizonte e as regiões Norte, Nordeste, Centro-Oeste e Sul.	
Valor PORTARIA SGD/MGI Nº 750, DE 20 DE MARÇO DE 2023	20/03/2023	R$ 18.084,53		
		R$ 14.637,18	Média geral para 40 horas semanais	

4.	Administrador de base de dados: um, nível sênior, valor unitário médio mensal para sênior de R$ 10.383,93, conforme tabela a seguir.

Fonte		Salário mensal	Observações	
https://br.indeed.com/career/administrador-de-banco-de-dados/salaries/S%C3%A3o-Paulo--SP	21/03/2022	R$ 7.384,00	Média de São Paulo, SP.	
https://www.glassdoor.com.br/Sal%C3%A1rios/s%C3%A3o-paulo-dba-sal%C3%A1rio-SRCH_IL.0,9_IM1009_KO10,13.htm?clickSource=searchBtn	21/03/2022	R$ 8.476,00	Média de São Paulo, SP.	
https://canaltech.com.br/carreira/confira-o-guia-salarial-para-profissionais-de-ti-em-2023-241896/	21/03/2022	R$ 13.560,23	Média entre as cidades de São Paulo, Rio de Janeiro, Belo Horizonte e as regiões Norte, Nordeste, Centro-Oeste e Sul.	
Valor PORTARIA SGD/MGI Nº 750, DE 20 DE MARÇO DE 2023	20/03/2023	R$ 12.115,48		
	 	R$ 10.383,93	Média geral para 40 horas semanais	

4.6.2.1    Tabela síntese de média de valores por mês (duas sprints), conforme a capacidade necessária gerenciada.

Cargo	Quantidade	Valor 	
Scrum máster (meio período ou 20 horas semanais)	1	 R$ 5.990,34
	
Analistas de testes	1	R$ 9.328,23	
Analista de Negócio Negócios/Requisitos 	1	R$ 8.580,31	
Desenvolvedores full stack	4	R$ 50.597,20 	
Arquiteto de software	1	R$ 14.637,18	
Administrador de base de dados	1	R$ 10.383,93	
Valores totais por mês (duas sprints)		R$ 99.517,19	
Valores totais por ano (12 meses / 24 sprints)		R$ 1.194.206,28	

4.6.2.2   O uso da métrica capacidade gerenciada proporciona flexibilidade à CONTRATANTE para aumentar ou diminuir a força de trabalho contratada, conforme sua necessidade e conveniência, seja por questões financeiras ou circunstâncias momentâneas do projeto. Nos exemplos acima, embora o valor mínimo estimado seja de R$ 672.652,92 e o máximo de R$ 1.646.168,28, pode ser razoável tocar o projeto com squad que resulte um orçamento anual de R$ 747.716,16, acima do mínimo, mas bem mais baixo do valor máximo estimado.
     
4.3.3 A possibilidade de pagamento fixo por sprint  (Cf. https://www.in.gov.br/en/web/dou/-/portaria-sgd/mgi-n-750-de-20-de-marco-de-2023-471917517) permite ao TRE-SP atuar, em relação à contratação e sustentação do sistema, de forma semelhante ao funcionamento das unidades responsáveis pelo desenvolvimento e sustentação de sistemas, que segue metodologias ágeis, conforme suas possibilidades. Os custos de cada sprint são maiores que os observados acima, para métrica capacidade gerenciada (Cf. 4.6.2), apenas pelo fato de se obter fontes de salários diferentes. De fato, a principal diferença entre a capacidade gerenciada, conforme visto acima, e o pagamento por sprint é que na capacidade gerenciada o tamanho das equipes contratadas pode variar, em função das necessidades e momento dos projetos. No pagamento de sprint por preço fixo, é necessário definir a composição do time ágil e, em função dessa composição, estimar o custo da equipe contratada. O pagamento fechado por sprint não se confunde com postos de trabalho ou por pagamento fixo por hora, pois a remuneração é diretamente ligada aos produtos entregues em cada sprint.

 4.6.3.1 No Anexo I, Portaria do Executivo Federal (idem), Item 4, apresenta-se um modelo de planilha para levantamento de custos por sprint, com possibilidade de adaptação, se necessário. Esse modelo, em linhas gerais, apresenta o custo com base na composição da equipe (quantidade, perfil profissional, experiência e de tempo de dedicação em horas), de forma semelhante ao visto acima, no modelo de capacidade gerenciada (Cf. 4.3.2). Utilizando-se a mesma configuração considerada razoável para o desenvolvimento do sistema de Condenações (Cf. 4.6.2.2) e os valores de salários indicados na PORTARIA SGD/MGI Nº 750, seriam os seguintes valores:

Cargo	Quantidade	Valor estimado	
Scrum master	1
(20 horas semanais)	R$ 5.866,10	
Analistas de testes	1	R$ 11.081,16	
Analista de Negócios/Requisitos: um; nível sênior	1	R$ 11.227,93	
Desenvolvedores full stack	4	R$ 56.067,08	
Arquiteto de software	1	R$ 18.084,53	
Administrador de base de dados	1	R$ 12.115,18	
Valores totais por mês - duas sprints		R$ 114.441,98	
Valores totais por ano (12 meses / 24 sprints)		R$ 1.373.303,76	

4.6.4   As estimativas acima indicam valores para contratação no formato de squad as service ou custo fixo por sprint, mas as empresas concorrentes podem acrescentar outros valores como, por exemplo, os custos administrativos, operacionais e margem desejada de lucro, de modo que essa estimativa de custo, embora seja próxima do valor final da massa salarial da squad prevista, não é definitiva. Por outro lado, não se trata aqui de definir quais salários deveriam ser pagos pelas empresas concorrentes, mas de definir valores mínimos e razoáveis, considerando-se salários de mercado, o que pode ajudar a investigar melhor, antes da contratação, eventuais propostas de empresas com valores muito abaixo dos projetados neste estudo.

5 – REGISTRO DE SOLUÇÕES CONSIDERADAS INVIÁVEIS	

5.1	É inviável a contratação do desenvolvimento e sustentação por posto de serviço (posto de trabalho tradicional), seguindo-se o posicionamento do Tribunal de Contas da União, na súmula TCU 269, na qual informa que pode ocorrer a admissão do pagamento por hora trabalhada ou por posto de serviço somente quando as características do objeto não permitirem o pagamento por resultados, cuja excepcionalidade deve estar justificada. Ora, não é o caso do desenvolvimento do Sistema de Condenações Eleitorais, que pode ser realizado por outros formatos de trabalho.

5.2   A contratação do desenvolvimento pela métrica homem/hora também é considerada inviável para a contratação, pois possui semelhança com o posto de trabalho tradicional, embora esse formato possa ser executado fora das sedes da CONTRATADA e possa ter carga horária diferenciada. Nesse formato de trabalho ainda há o risco do paradoxo lucro-incompetência (Cf. item 4.2.2.1).

5.3    A contratação do desenvolvimento pela métrica hora de serviço técnico seria possível, a princípio, mas as dificuldades para o detalhamento do projeto do sistema nesse momento (e o detalhamento cuidadoso é um dos fatores de sucesso dessa métrica), além do escopo flexível, uma das características do desenvolvimento tocado por metodologias ágeis, tornam inadequada a adoção do formato de trabalho por essa métrica.

5.4    A contratação do desenvolvimento por preço fixo, ainda que se use preço fixo por sprint, exige escopo fixo ou grande conhecimento das possíveis mudanças no projeto, o que permitiria mensurar seus custos e esforços. Ora, não é o caso do escopo do Sistema de Condenações Eleitorais, que pode ser alterado e que possui pontos ainda não rigidamente definidos, cujas possíveis mudanças são de difícil mensuração. Esse modelo, dado o contexto do projeto, pode trazer prejuízos à CONTRATANTE, que pode pagar mais do que recebe como produto funcional, como para a CONTRATADA, que pode precisar gastar mais do que o previsto para executar o contrato.

5.5    Conforme visto acima (Cf. item 4.2.4.1 ), a métrica ponto de função possui como ponto crítico a existência e disponibilidade de documentação correta e completa das aplicações a serem mensuradas, contudo, no caso da contratação do desenvolvimento do Sistema de Condenações Eleitorais, não se possui o escopo completamente fechado ou outros artefatos indicados, como diagrama de fluxo de dados e modelo entidade relacionamento, embora o modelo de requisitos esteja maduro (ainda que não imutável). O TRE-SP também não possui experiência no uso de pontos de função, o que colocaria em risco a correta mensuração do sistema e precificação do serviço, se escolhida essa métrica, portanto, julgou-se prudente não utilizar essa solução. 
	Cabe aqui citar que a contratação de fábrica de software, com demanda mensurada por pontos de função ou não, mostrou-se inadequada por dois motivos. Primeiro, contratações de fábrica de software tradicionalmente exigem escopo fechado dos requisitos, cuja definição deve ocorrer antes da contratação, o que não é o caso do Sistema de Condenações Criminais. De fato, ainda que os requisitos estejam maduros, há espaço para modificação do escopo e requisitos. Uma contratação de fábrica de software nesse contexto imporia um enorme risco de fracasso do projeto, que contaria ainda com possibilidade de prejuízo da CONTRATADA e ou da CONTRATANTE. O segundo motivo é o próprio estado da arte do desenvolvimento de sistemas, que apresenta ampla migração para abordagens ágeis, as quais possuem como um de seus pontos centrais a flexibilidade de especificação dos requisitos e possibilidade de mudança de escopo durante o projeto. A literatura técnica mostra que a taxa de sucesso e de eficiência dos projetos tocados por metodologias ágeis é maior que os projetos tocados por metodologias tradicionais de desenvolvimento de sistemas. 

5.6    A contratação do desenvolvimento mensurado pela métrica story points foi descartado pela subjetividade inerente a essa métrica, o que gera grande dificuldade de se mensurar esforço objetivo do desenvolvimento de software (Cf. 4.2.4.2).  

5.7     A Métrica linha de código é baseada na quantidade de linhas código criadas, mas essa métrica está em desuso em contratos de desenvolvimento de sistemas por ter amplo descrédito, o que a torna indesejável para uso na contratação do desenvolvimento de sistemas.

5.8    A métrica unidade de serviço técnico exige, entre outros pontos, a existência de um catálogo de serviços rigorosamente elaborado, adequado aos serviços que se quer contratar. Nesse momento, o TRE-SP não possui tal catálogo.

6 – ANÁLISE COMPARATIVA DE CUSTOS (TCO)	

6.1 – CÁLCULO DOS CUSTOS TOTAIS DE PROPRIEDADE
Solução Viável 1	
Descrição: pagamento do desenvolvimento por capacidade gerenciada	
A contratação do desenvolvimento de sistemas por meio do formato de capacidade gerenciada (squad as service) permite variar o tamanho da equipe em função das necessidades do projeto ao longo tempo, assim, em determinados momentos o projeto poderia, por exemplo, possuir mais desenvolvedores, mais analistas de testes, nenhum arquiteto de software etc.	
Custo Total de Propriedade – Memória de Cálculo	
Para o TCO são considerados os valores indicados no item 4.3, ressaltando-se que se trata apenas do valor da contratação do desenvolvimento, manutenção evolutiva e sustentação, uma vez que não será necessário adquirir nova infraestrutura de qualquer espécie. Há que se observar as recomendações do item 4.6.4, sobre possíveis outros valores cobrados.
A seguir, valores de TCO.

Desenvolvimento e manutenção evolutiva.
Squad: 8 profissionais (valores de salários mensais)
1 Scrum master:  R$ 5.990,34  (apenas 20 horas semanais)
1 analista de testes: R$ 9.328,23
1 analista de negócios/requisitos: R$8.580,31
4 desenvolvedores full stack: R$ 50.597,20 
1 arquiteto de software: R$ 14.637,18
1 administrador de base de dados: R$ 10.383,93
Total mensal (duas sprints): R$ 99.517,19
Total anual desenvolvimento (18 sprints): R$ 895.654,71
Total anual manutenção evolutiva (8 sprints): R$ 398.068,76

Pagamento fixo mensal para sustentação
1 desenvolvedor full stack: R$ 12.649,30
Total anual: R$ 151.791,60	
Solução Viável 2	
Descrição: pagamento do desenvolvimento (ou manutenção evolutiva) fechado por sprint	
O pagamento do desenvolvimento fechado por sprint é uma possibilidade indicada na PORTARIA SGD/MGI Nº 750, DE 20 DE MARÇO DE 2023. Sua principal diferença em relação à contratação de desenvolvimento e sustentação pelo formato de capacidade gerenciada é a existência de equipes com tamanhos e perfis fixos.
	
Custo Total de Propriedade – Memória de Cálculo	
Para o TCO são considerados os valores indicados no item 4.3, ressaltando-se que se trata apenas do valor da contratação do desenvolvimento e sustentação, uma vez que não será necessário adquirir nova infraestrutura de qualquer espécie. Há que se observar as recomendações do item 4.6.4, sobre possíveis outros valores cobrados. A seguir, a estimativa de custos.

Time scrum (valores de salários mensais)
1 Scrum master:  R$ 5.866,10 (apenas 20 horas semanais)
1 analista de testes: R$ 11.081,16
1 analista de negócios/requisitos: R$ 11.227,93
4 desenvolvedores full stack: R$ 56.067,08 
1 arquiteto de software: R$ 18.084,53
1 administrador de base de dados: R$ 12.115,18
Total mensal (duas sprints): R$ 114.441,98
Total anual desenvolvimento (18 sprints): R$ 1.029.977,82
Total anual manutenção evolutiva (8 sprints): R$ 457.767,82

Pagamento fixo mensal para sustentação
1 desenvolvedor full stack: R$ 14.016,77
Total anual: R$ 168.201,24	

6.2 – MAPA COMPARATIVO DOS CÁLCULOS TOTAIS DE PROPRIEDADE (TCO)

Solução	Estimativa de TCO ao longo dos anos	
Total	
	Ano 1	Ano 2	Ano 3		
1	Squad	R$ 895.654,71	R$ 398.068,76	R$ 398.068,76	R$ 1.691.792,23	
	Sustentação	R$ 37.947,90	R$ 151.791,60	R$ 151.791,60	R$ 341.531,10	
	Total anual / ao longo de 3 anos	R$ 933.602,61	R$ 549.860,36	R$ 549.860,36	R$ 2.033.323,33	
2	Squad	R$ 1.029.977,82	R$ 457.767,82	R$ 457.767,82	R$ 1.945.513,46	
	Sustentação	R$ 42.050,31	R$ 168.201,24	R$ 168.201,24	R$ 378.452,79	
	Total anual / ao longo de 3 anos	R$ 1.072.028,13	R$ 625.969,06	R$ 625.969,06	R$2.323.966,25	

	Observações

O time scrum (solução 2) possui a mesma composição de equipe média da solução viável 1, de modo que, para os mesmos salários, os valores deveriam ser os mesmos, mas nesta memória de cálculo, os valores estão diferentes porque para a solução viável 2 foi considerada apenas a tabela de salários da Portaria SGD/MGI Nº 750, DE 20 DE MARÇO DE 2023. 
	Os valores acima indicam apenas valores de salários estimados para à equipe, não consideram correção monetária, variação de salários ou margem de lucro de empresas. Portanto, são projeções para valores mínimos da contratação.
	No primeiro ano, haverá o desenvolvimento do sistema, previsto para durar 9 meses (18 sprints). A manutenção evolutiva tem previsão de até 4 meses anuais (8 sprints), ocorrendo a partir do segundo ano. A sustentação tem previsão para início após o fim do desenvolvimento do sistema.

7 – DESCRIÇÃO DA SOLUÇÃO DE TIC A SER CONTRATADA	

7.1    Entende-se que a melhor forma de contratação do desenvolvimento e sustentação é a do pagamento fixo por sprint. 

7.2		A execução do serviço por equipes distintas poderia dispersar a responsabilidade pelo alcance dos objetivos. Essa dispersão acarretaria diluição do comprometimento com os processos de trabalho e traria riscos de sobreposição de atividades. Além disso, a comunicação direta e contínua entre as equipes é essencial para a qualidade da prestação do serviço, haja vista que os objetivos são comuns e a fronteira de atuação é muito tênue, dada a forte interconexão das atividades no que concerne aos aspectos técnicos (caráter generalista) e metodológicos (registro, investigação e diagnóstico). Ante o exposto, a adjudicação do serviço a uma única empresa mitigará os riscos em comento e proporcionará melhor gestão e maior qualidade na execução do serviço de sustentação.

ITEM	ESPECIFICAÇÃO	CATSER	UNIDADE	QUANTIDADE
ESTIMADA (ANUAL) 	PREÇO UNITÁRIO MÁXIMO
ACEITÁVEL	PREÇO TOTAL 
MÁXIMO
ACEITÁVEL	
1	Serviço de desenvolvimento do Sistema Nacional de Condenações Eleitorais, conforme especificações e demais condições estabelecidas no Termo de Referência (e APÊNDICES do edital):

- estima-se que serão necessárias 18 sprints;
- sprints com duração de duas semanas (dez dias úteis);
- Pagamento fechado por Sprint;
- Serão utilizados pontos de casos de uso para verificação dos níveis mínimos de serviço.	25917	Sprint

	18
			
2	Treinamento para áreas usuárias do sistema com duração mínima de 20 horas e máxima de 40 horas, para até 50 alunos com transmissão ao vivo e gravação das aulas, conforme item 3.1.7 do Termo de Referência. 	3840	Turma	1
			
3	Serviço de manutenção evolutiva do Sistema Nacional de Condenações Eleitorais, conforme especificações e demais condições estabelecidas no Termo de Referência (e APÊNDICES do edital):

- estima-se que serão necessárias 8 sprints por ano;
- sprints com duração de duas semanas (dez dias úteis);
- Pagamento fechado por Sprint;
- Serão utilizados pontos de casos de uso para verificação dos níveis mínimos de serviço.	25917	Sprint	8			

ITEM	ESPECIFICAÇÃO	CATSER	PREÇO MÁXIMO MENSAL
ACEITÁVEL	PREÇO
MÁXIMO ANUAL
ACEITÁVEL	
4	Serviços de sustentação do Sistema Nacional de Condenações Eleitorais, com remuneração baseada em valor fixo mensal. 	26000

7.3     O time scrum terá a composição definida a seguir: 

Profissional	Quantitativo	
Scrum master	01  (apenas 20 horas semanais)	
Analista de testes	01	
Analista de negócios/requisitos	01	
Desenvolvedor full stack sênior	04	
Arquiteto de software	01	
Administrador de base de dados	01	

8 – ESTIMATIVA DE CUSTO TOTAL DA CONTRATAÇÃO	

	A estimativa do custo total de contratação precisa levar em consideração o tempo de vida do projeto. Para o primeiro ano, deve-se considerar apenas o desenvolvimento e sustentação, o equivalente a um ano, conforme indicado no mapa comparativo dos cálculos totais de propriedade (Cf. item 6.2). Estão indicados no mapa os três primeiros anos do projeto, considerando-se o desenvolvimento, sustentação e evolução. Provavelmente a partir do quarto ou quinto ano do uso do sistema, atingir-se-á estabilidade em manutenções evolutivas e corretivas, possivelmente reduzindo os custos de futuras contratações. Nesse momento futuro, deve-se considerar a contratação de sustentação junto com outros sistemas, o que poderia reduzir os custos de se manter uma equipe dedicada para um sistema estável.

9 – DECLARAÇÃO DE VIABILIDADE DA CONTRATAÇÃO	

	Declaramos que a contratação da solução do desenvolvimento e sustentação por pagamento por preço fixo por sprint é viável, tendo sido escolhida por apresentar modelo de desenvolvimento amplamente utilizado no mercado, incluindo-se o próprio TRE-SP, além de preços semelhantes à outra solução possível, trazendo os seguintes benefícios: redução do risco por apresentar entregas quinzenais de produtos de software funcional e artefatos do projeto; facilidade de fiscalização; redução dos riscos de fracasso do projeto, em função das características próprias das abordagens ágeis de desenvolvimento de sistemas.

10 – APROVAÇÃO E ASSINATURA	
A Equipe de Planejamento da Contratação foi instituída pelo Documento de Oficialização da Demanda (doc. nº 4135388) de 23 de novembro de 2022.

INTEGRANTE TÉCNICO	INTEGRANTE TÉCNICO	INTEGRANTE DEMANDANTE	

_______________________

Taís Rigon Belintani
Matrícula: 13.705-7

São Paulo, 27 de março de 2023.	
_________________________

Cândido Luís Dias Ferreira
Matrícula: 12.862-7

São Paulo, 27 de março de 2023.	
________________________

Robson dos Santos França
Matrícula: 12.525-3

São Paulo, 27 de março de 2023.	

SECRETÁRIO DE TECNOLOGIA DA INFORMAÇÃO, representando o CETIC

________________________
<nome da autoridade>
Matrícula:

<Local>, <dia> de <mês> de <ano>	

ÁREA DEMANDANTE	

______________________________
<nome da autoridade>
Matrícula: xxxxxx

<Local>, <dia> de <mês> de <ano>	

Anexo II - Referências

EDITAL DE LICITAÇÃO PROCESSO Nº 103441/2022
PREGÃO ELETRÔNICO Nº 13/2022 – CEL/PROFISCO II/SEFAZ/MA Disponível em: https://sistemas1.sefaz.ma.gov.br/portalsefaz/files?codigo=21833. Acesso em: 06 mar 2023.

PORTARIA SGD/MGI Nº 750, DE 20 DE MARÇO DE 2023. Disponível em: https://www.in.gov.br/en/web/dou/-/portaria-sgd/mgi-n-750-de-20-de-marco-de-2023-471917517.  Acesso em: 23 mar 2023.