EDITAL DE CHAMAMENTO PÚBLICO PARA SELEÇÃO DE POSSÍVEL PARCEIRO Nº 002/2020/MTI

EDITAL DE CHAMAMENTO PÚBLICO PARA SELEÇÃO DE POSSÍVEL PARCEIRO Nº 002/2020/MTI

A Empresa Mato-Grossense de Tecnologia da Informação (MTI), empresa pública estadual, com sede na Xxx Xxx. Xxxxxx Xxxxxxx, x/x - Xxxxxx Político Administrativo | CEP: 78049-903 | Cuiabá - MT, inscrito no CNPJ/MF sob o nº 76.535.764/0001-43, torna público para ciência das Interessadas, que iniciará, a partir da publicação deste Chamamento público para seleção de possível parceiro para eventual celebração de parceria estratégica, nos termos da Lei 13.303/2016 e do Regulamento de Licitações e Contratos da MTI, aprovado na Ata da 150º Reunião do Conselho de Administração, conforme Portaria/MTI 049/2019.

SEÇÃO I – DO OBJETO

1.1. O objeto do presente Edital caracteriza-se como chamamento público para seleção de proposta de interesse comercial de possível parceiro de negócio para eventual celebração de parceria com empresa especializada em Soluções de Software, baseado em modelo de Fábrica de Software, para executar serviços de Soluções de Software, em conjunto com a Empresa Mato-Grossense de Tecnologia da Informação (MTI), para a Administração Pública, objetivando prover serviços que disponibilizem condições de otimização da eficiência, economicidade e inteligência digital inerente aos serviços prestados pelos órgãos ao cidadão, nos termos e condições descritas neste Edital.

SEÇÃO II – ESPECIFICAÇÃO TÉCNICA

2.1. Especificação do objeto:

2.2. O objeto contempla o planejamento da solução, mapeamento, desenho e priorização das jornadas e experiência do usuário, dos processos e serviços disponibilizados, definição, desenho e desenvolvimento das soluções de software, planejamento e gestão das mudanças e impactos organizacionais com os stakeholders, bem como o apoio à MTI na adoção de modelos ágeis que suportem o desenvolvimento e implementação das Solução de Software.

2.2.1. Os serviços objetos de eventual parceria,, os quais serão demandados pela MTI, por meio de ORDENS DE SERVIÇO (OS), estão detalhados no “Catálogo de Serviços de Solução de Software” (O detalhamento dos serviços participantes das operacionalizações inerentes à Solução de Software estão referenciados na última versão do “Catálogo de Serviços de Solução de Software”(C3SW) disponibilizado no sítio da MTI – xxxx://xxx.xxx.xx.xxx.xx/x0xx, onde podem ser consultados. A versão do C3SW pode avançar sob estímulo da evolução tecnológica que referência Soluções de Software, tendo como métrica padrão Unidade de Serviço Técnico (UST), onde tal catálogo reporta todos os detalhes, entregáveis e informações relacionadas aos serviços passíveis de serem executados.

2.3.2. Considera-se Solução de Software todos serviços prestados pelo órgão a orquestração, através de software, de processos, pessoas e tecnologias que viabilizem a prestação dos serviços a serem demandados pela Administração Pública, contemplando não apenas os canais de solicitação e acompanhamento dos serviços pelo cidadão, como também os fluxos de trabalho e mecanismos internos do órgão/entidade que permitam com que os serviços sejam processados e executados de forma rápida, simples e eficiente.

2.3.3. As INTERESSADAS deverão considerar, no entendimento, planejamento e desenho da Solução de Software, todos os aspectos inerentes à sua execução fim a fim, de processos existentes no órgão/entidade e na MTI, questões e desafios relacionados à cultura organizacional e mudanças que venham a ser necessárias, custo x benefício das Solução de Software a serem realizadas, bem como quaisquer outros temas que impactam direta ou indiretamente no resultado a ser alcançado com o processo de Solução de Software.

2.3.4. As INTERESSADAS serão responsáveis pelo planejamento e orquestração da Solução de Software, de forma integrada e coordenada com a MTI, que serão as estruturadas responsáveis pelas implementações tecnológicas a serem realizadas. Todas as etapas deverão ser executadas em alinhamento entre a MTI e as INTERESSADAS, uma vez que elas serão responsáveis pela implementação da Solução de Software de acordo com as recomendações realizadas, no que diz respeito às arquiteturas tecnológicas, desenvolvimento da solução, uso ou integração com soluções de software legadas.

2.3.5. Não será permitido a participação de:

a) entidades empresariais reunidas em consórcio;

b) entidades empresariais constituídas na forma de sociedades cooperativas;

c) empresas que possuam entre seus sócios ou dirigentes, servidor vinculado a MTI.

2.4. Detalhamento dos Serviços

O detalhamento dos serviços participantes das operacionalizações inerentes à Solução de Software estão referenciados na última versão do “Catálogo de Serviços de Solução de Software”(C3SW), disponibilizado no sítio da xxxx://xxx.xxx.xx.xxx.xx/x0xx, onde podem ser consultados.

2.5. Modelo de Referência de Práticas de Desenvolvimento Ágil (MR-PDA) Disciplinará práticas de Desenvolvimento, Manutenção e Sustentação de Software no âmbito da parceria a ser futuramente formalizada, que pode ser consultado em sua versão mais atualizada no sítio da MTI xxx.xxx.xx.xxx.xx/xx- pda. A versão do MR-PDA pode evoluir, a qualquer tempo, sob estímulo da evolução tecnológica que referência no Estado da Arte, em termos de Soluções de Software.

SEÇÃO III – DAS CONDIÇÕES PARA PARTICIPAÇÃO

3.1. Poderão participar do presente procedimento as pessoas jurídicas que atenderem a todas as condições e exigências deste Edital, exceto as pessoas jurídicas elencadas no item 3.2.

3.1.1. As INTERESSADAS arcarão com todos os custos decorrentes da elaboração e apresentação de suas propostas e documentação.

3.2. Não serão admitidos à participação:

a) das INTERESSADAS que, por qualquer motivo, estejam com o direito de licitar e contratar com a MTI suspenso ou impedido, que tenham sido declaradas inidôneas para licitar ou contratar com a União, pelo Estado, pelo Distrito Federal ou pela unidade federativa a que está vinculada a empresa pública ou sociedade de economia mista, enquanto perdurarem os efeitos da sanção, previsão contida no Art. 38, incisos II e III e Art. 83, inciso III, ambos da Lei 13.303, de 2016;

b) empresas que se enquadrem em alguma das vedações previstas no Art. 38 da Lei nº 13.303/2016;

c) empresas estrangeiras que não funcionem no País;

d) empresas em processo de falência, recuperação judicial, extrajudicial ou de Insolvência, ou sob outra forma de concurso de credores, em dissolução ou em liquidação;

d.1) as INTERESSADAS em recuperação judicial, desde que amparada em certidão emitida pela instância judicial competente, que certifique que o interessado está apto econômica e financeiramente a participar de procedimento licitatório, nos termos da Lei 13.303, de 2016, serão admitidos neste certame.

e) empresas cujo objeto social não seja pertinente e compatível com o objeto deste Edital.

3.3. O atendimento aos requisitos do presente Edital se dá sem exclusividade, inexistindo qualquer preferência ou direcionamento da MTI, sendo o Chamamento Público disponibilizado a qualquer pessoa jurídica que atenda aos requisitos exigidos.

SEÇÃO IV - DO PRAZO PARA APRESENTAÇÃO DAS PROPOSTAS DE INTERESSE COMERCIAL

4.1. As Propostas de interesse comercial, cujo modelo se encontra no ANEXO II deste Edital, poderão ser apresentadas a partir do dia 24/04/2020 até às 18h00 do dia 05/06/2020, conforme preceituado no Art. 8º, inciso III, do Regulamento de Licitações e Contratos da MTI.

SEÇÃO V – DAS IMPUGNAÇÕES E ESCLARECIMENTOS AO EDITAL

5.1. Até 05 (cinco) dias úteis antes da data fixada para a ocorrência do chamamento público, cidadãos e agentes econômicos podem pedir esclarecimento e impugnar o Edital, mediante requerimento fundamentado à Comissão Especial, que deverá responder motivadamente em até 03 (três) dias úteis.

5.1.1. As petições de impugnação e os pedidos de esclarecimentos deverão ser encaminhadas para o e-mail: xxxxxxxxx@xxx.xx.xxx.xx, no prazo previsto no item 5.1.

5.2. As petições de impugnação e de pedidos de esclarecimento deverão ser encaminhadas devidamente instruídas com as seguintes informações: número do processo e do chamamento público ao qual se refere, qualificação da empresa interessada, endereço de correspondência, endereço de e-mail para os fins de que trata o item 5.1 do Edital, telefone para contato e a assinatura do preposto/procurador.

5.3. Todas as petições e pedidos de esclarecimentos serão respondidos por e- mail para a empresa interessada, bem como, lançado no endereço eletrônico xxxxx://xxx.xxx.xx.xxx.xx - junto ao Edital, para conhecimento da empresa interessada/impugnante e de quaisquer interessadas.

5.4. Se a impugnação ao Edital e/ou pedido de esclarecimento for reconhecida e julgada procedente, serão corrigidos os vícios e uma nova data será designada pela Comissão Especial.

5.5. Decairá o direito de pedir esclarecimentos ou impugnar os termos deste Edital aquele que não o fizer até 05 (cinco) dias úteis antes da data final para apresentação de propostas, apontando de forma clara e objetiva falhas ou irregularidades que entender viciarem o mesmo.

SEÇÃO VI – DA DOCUMENTAÇÃO PARA PARTICIPAÇÃO NO CHAMAMENTO PÚBLICO PARA SELEÇÃO DE POSSÍVEL PARCEIRO

6.1. Apresentar Proposta de interesse comercial constando as seguintes informações:

6.1.1. Estar regularmente constituída, conforme elencado no Art. 26, § 2º, inciso I, do Regulamento de Licitações e Contratos da MTI, diante da apresentação de:

a) cédula de identidade e CPF, no caso de pessoa física;

b) registro na Junta Comercial, no caso de empresa individual;

c) ato constitutivo registrado e ata da assembleia que elegeu seus atuais administradores, no caso de Sociedades Anônimas;

d) ato constitutivo, estatuto ou contrato social em vigor, devidamente registrado, em se tratando de sociedade empresária;

e) inscrição do ato constitutivo, no Registro Mercantil competente, no caso de sociedade simples, acompanhada de prova de diretoria em exercício;

f) Certificado da Condição de Microempreendedor Individual (CCMEI), no caso de MEI, na forma da Resolução CGSIM nº 16, de 2009, cuja aceitação ficará condicionada à verificação da autenticidade no site xxx.xxxxxxxxxxxxxxxxxxxx.xxx.xx, bem como o Cadastro Nacional de Pessoa Física – CPF e Carteira de Identidade – R.G.

6.1.2. Possuir regularidade para a eventual contratação junto a Empresa Mato- Grossense de Tecnologia da Informação (MTI), comprovada pelos itens a seguir:

a) Regularidade perante a Seguridade Social e o Fundo de Garantia por Tempo de Serviço (FGTS), comprovada mediante a apresentação, respectivamente, de Certidão de Débitos Relativos a Créditos Tributários Federais e à Dívida Ativa da União e Certificado de Regularidade do FGTS (CRF);

b) Cumprimento do disposto no inciso XXXIII, do Art. 7º, da Constituição Federal, mediante declaração emitida pelo licitante/futuro contratado;

c) Declaração de que não adota relação trabalhista caracterizando trabalho forçado ou análogo a trabalho escravo, conforme disposto nas Leis n º 9.777, de

30 de dezembro de 1998, nº 10.803, de 11 de dezembro de 2003 e Lei Complementar Federal nº 75, de 20 de maio de 1993;

d) Declaração informando a inexistência de fatos supervenientes impeditivos da habilitação;

e) Declaração da empresa informando que não existem em seu quadro de empregados servidores públicos exercendo funções de gerência, administração ou tomada de decisão;

f) Declaração de que a empresa não se enquadra em uma das hipóteses do Art. 13 deste Regulamento;

6.1.3. Apresentar Proposta de interesse comercial, descrevendo detalhadamente os serviços, metodologias, modelos de execução, experiências na prestação de serviços de características semelhantes, qualificação da equipe técnica a ser alocada na prestação dos serviços e demais informações que sirvam de insumo para análise, pela Comissão Especial, da capacidade de execução e entrega dos serviços.

6.1.4. Apresentar documentação comprobatória acerca da qualificação econômico-financeira, qual seja:

6.1.4.1. Apresentação do balanço patrimonial referente ao último exercício;

6.1.4.2. Apresentação do capital social mínimo, patrimônio líquido mínimo ou garantias que assegurem o adimplemento.

6.1.5. Serão considerados pela Comissão Especial instituída, dentre outros aspectos, obrigatoriamente, os seguintes fatores técnicos,referenciando o MR- PDA,:

(I) Conhecimento técnico em serviços de consultoria em planejamento e desenvolvimento de Solução de Software utilizando Práticas Ágeis, contemplando iniciativas estratégicas, planejamento e implementação de ações voltadas a Processos e Tecnologia da Informação;

(II) Conhecimento técnico em serviços de Solução de Software utilizando Práticas Ágeis que transformaram a experiência de usuários/clientes, contemplando estratégia de engajamento, elucidação de requisitos, análise, modelagem e implementação de soluções centradas em arquitetura de software;

(III) Conhecimento técnico em serviços de apoio à implantação de modelos de excelência que utilizam Práticas Ágeis para desenvolvimento de Soluções de Software;

(IV) Conhecimento técnico em serviços de apoio à implantação de modelos de gestão baseados em Lean que utilizam Práticas Ágeis para disponibilização de Soluções de Software;

(V) Conhecimento técnico em serviços de Solução de Software utilizando Práticas Ágeis para desenho e implementação de modelos de analytics e inteligência de dados, compreendendo a definição de modelos operacionais e organizacionais, processos, papéis, responsabilidades e requisitos de arquitetura de tecnologia.

6.1.6. Apresentar o Termo de Responsabilidade e Sigilo assinado, conforme modelo disponibilizado no sítio da MTI - xxxx://xxx.xxx.xx.xxx.xx/xxx.

6.2. Da possibilidade de realização de vistoria técnica:

6.2.1. As INTERESSADAS poderão realizar vistoria técnica de forma OPCIONAL. A vistoria não será utilizada em caráter eliminatório ou classificatório.

6.2.2. A vistoria será agendada para todas as interessadas, com antecedência mínima de 48 (quarenta e oito) horas, mediante contato com a Diretoria de Tecnologia da Informação e Comunicação, pelo telefone (00) 0000-0000, no horário de 08h às 18h (horário de Mato Grosso), de segunda a sexta-feira, até o 2º (segundo) dia útil anterior à data de abertura do certame;

6.2. Da entrega da documentação:

6.2.1. A interessada encaminhará para o e-mail xxxxxxxxx@xxx.xx.xxx.xx a documentação solicitada em 3.1, até a data final prevista no preâmbulo deste Edital, até o horário de funcionamento da MTI, às 18h00, horário local.

6.2.3. Os documentos deverão ser enviados, EXCLUSIVAMENTE, por via eletrônica, para o e-mail informado.

6.2.3.1. O teor e a integridade dos documentos enviados digitalizados e dos natos digitais serão de responsabilidade da interessada. A MTI poderá exigir, a seu critério, a apresentação da versão impressa que originou o documento digitalizado.

6.3. A Comissão Especial fará a avaliação da documentação apresentada em até 15 (quinze) dias úteis, contados da data final prevista no preâmbulo deste edital.

6.3.1. A Comissão Especial poderá solicitar esclarecimentos quanto à documentação apresentada, conferindo o prazo de 5 (cinco) dias úteis para resposta.

6.4. Após a análise dos documentos e conclusão sobre a manifestação, a Comissão Especial irá providenciar a publicação do resultado no Diário Oficial do Estado e no sítio da MTI.

SEÇÃO VII – OBRIGAÇÕES DA INTERESSADA NO CHAMAMENTO PÚBLICO PARA POSSÍVEL PARCERIA

7.1. Apresentar Proposta de interesse comercial, constando as seguintes informações:

1. Informações sobre a empresa Interessada;

2. Metodologia relativa aos serviços descritos na Especificação Técnica;

3. Constituição da Equipe;

4. Experiências Relevantes da Manifestante em Soluções de Software relacionadas ao setor público, no Brasil e no Mundo, em Atestados Técnicos;

5. Outras Experiências Relevantes em Serviços Governamentais.

7.2. Formular à Comissão Especial solicitações de informações, dados e documentos necessários à execução dos trabalhos, com antecedência compatível com a complexidade do pedido.

7.3. Manter sigilo dos dados, informações e documentos a que venha a ter acesso em função da execução dos serviços a serem contratados, conforme Termo de Confidencialidade.

7.4. A interessada deverá arcar com as despesas com deslocamentos (passagens aéreas, serviços de táxi, diárias, hospedagem, alimentação e outros) dos profissionais alocados na Proposta de interesse comercial.

7.5. Prestar a Comissão Especial quaisquer esclarecimentos técnicos solicitados, de acordo com o objeto deste documento.

7.6. Disponibilizar os recursos computacionais, bem como os softwares e aplicativos necessários às atividades laborais, acessando obrigatoriamente softwares instanciados dentro da nuvem privada da MTI.

7.7. Em havendo divergências entre as especificações técnicas referenciadas neste documento e a apresentada pelas INTERESSADAS, valerá o conteúdo das especificações técnicas deste documento.

7.8. As INTERESSADAS possuem ciência que caso haja necessidade, deverão arcar com os custos relacionados aos processos de registro de propriedade industrial nacional e internacionalmente.

SEÇÃO VIII – OBRIGAÇÕES DA EMPRESA MATO-GROSSENSE DE TECNOLOGIA DA INFORMAÇÃO NO CHAMAMENTO PÚBLICO PARA POSSÍVEL PARCERIA

8.1. Fornecer às INTERESSADAS todos os elementos que se fizerem necessários à compreensão dos serviços a serem executados, informações técnicas e dados complementares que se tornem necessários à boa realização dos serviços, colaborando no seu estudo e interpretação.

8.2. Analisar e responder, em tempo hábil, às solicitações formais das INTERESSADAS, referentes aos esclarecimentos sobre os serviços a serem executados em parceria.

SEÇÃO IX – CRITÉRIOS E PARÂMETROS PARA A SELEÇÃO DAS PROPOSTAS

9.1. Após análise comparativa entre as métricas UST, Posto de Trabalho e FPA, optou-se por utilizar a UST para facilitar a fiscalização por parte dos contratantes.

9.2. Avaliação Técnica:

9.2.1. Será efetuado ranqueamento técnico, referenciando critérios e parâmetros relacionados abaixo, das INTERESSADAS na eventual parceria, que serão convidados a apresentar Proposta de interesse comercial a serem avaliadas pela MTI.

9.2.2. Os valores foram estipulados para equivaler ao tamanho e complexidade administrativa de um órgão governamental médio de um estado como Mato Grosso seja da administração direta ou indireta.A exemplo da própria MTI que tem um orçamento anual médio de aproximadamente 140 milhões.

9.3. Serão considerados pela Comissão Especial instituída, entre outros aspectos, os seguintes fatores empresariais, referenciando o MR-PDA:

(I) Experiência da empresa na prestação de serviços e condução de processos de:

1. Soluções de Software para serviços públicos desenvolvidos utilizando Práticas Ágeis;

2. Desenho e transformação da experiência de usuários através de Soluções de Software;

3. Gestão, Análise, Modelagem e Implementação de Projetos de Soluções de Software utilizando Práticas Ágeis;

4. Implementação de Modelos de Desenvolvimento de Soluções de Software baseado em Práticas Ágeis;

5. Implementação de Modelos de Excelência em Gestão Analítica da Informação baseada em Inteligência de Dados (Analytics);

6. Estratégia e arquitetura de Tecnologia da Informação.

(II) Qualificação de sua equipe técnica;

(III) Casos de sucesso;

(IV) Qualidade das informações e nível de detalhamento das atividades, entregáveis, responsáveis e demais informações constantes da Proposta Técnica.

CRITÉRIOS E PARÂMETROS PARA RANQUEAMENTO TÉCNICO I. Fórmula para Apuração da Pontuação Técnica PT = PFC + PFDP + PFDW + PFS + PFQ
	DESCRIÇÃO			PONTUAÇÃO
1. Pontuação Técnica da Proposta (PT)					Máximo = 100 pontos
PFDP - Pontuação do Fator Desempenho de Programação
PFDW - Pontuação do Fator Desempenho de Framework
PFC - Pontuação do Fator Compatibilidade
PFS - Pontuação do Fator de Serviços
PFQ - Pontuação do Fator Qualidade
Fórmula para Apuração da Pontuação Técnica (PT) PT = PFC + PFDP + PFDW + PFS + PFQ
Pontuação do Fator Desempenho de Programação (PFDP)					Máximo = 30 pontos
1.1 Experiência em execução de Soluções de Software para órgãos do setor público participantes das esferas Municipal, Estadual e Federal, incluindo o Distrito Federal-DF. Serão aceitos atestados de qualificação emitidos por prefeituras de municípios com orçamento anual superior a R$ 200.000.000,00 (duzentos milhões) a fim de equivaler ao faturamento de uma empresa privada conforme previsão no edital, devido ao grau de complexidade da administração dessas prefeituras se equivalerem ao objeto pretendido no chamamento público. Pontos atribuídos ao potencial parceiro em função da quantidade de contratos de Soluções de Software realizados nas seguintes tecnologias abaixo: Tipos de Tecnologias de Programação:			Máximo de 02(dois) atestados por Tipo de Tecnologia de Programação. 05(cinco) pontos por atestado JAVA. 04(quatro) pontos por atestado C#. 03(três) pontos por atestado PYTHON. 02(três) pontos por atestado PHP.

JAVA e/ou PHP e/ou C# e/ou PYTHON e/ou JavaScript (NodeJS; AngularJS; JSON). O atestado técnico deve informar qual(is) da(s) tecnologia(s) de Banco de Dados abaixo foi utilizada para instanciar o Modelo de Dados acessado pela Tecnologia de Programação: ORACLE e/ou SQL Server e/ou PostgreSQL e/ou MySQL. Os atestados devem reportar a versão das tecnologias acima, que devem estar em versão igual ou superior a reportada no artefato “Ambiente Tecnológico de Solução de Software”: A comprovação dar-se-á mediante a apresentação de atestados de capacidade técnica emitidos por órgãos do setor público participantes das esferas Estadual e Federal, incluindo o Distrito Federal-DF.		01(um) ponto por atestado JavaScript.
Pontuação do Fator Desempenho de Framework (PFDW)			Máximo = 18 pontos
1.2 Experiência em execução de Soluções de Software para órgãos do setor público participantes das esferas Municipal, Estadual e Federal, incluindo o Distrito Federal-DF. Serão aceitos atestados de qualificação emitidos por prefeituras de municípios com orçamento anual superior a R$ 200.000.000,00 (duzentos milhões) a fim de equivaler ao faturamento de uma empresa privada conforme previsão no edital, devido ao grau de complexidade da administração dessas prefeituras se equivalerem ao objeto pretendido no chamamento público. Pontos atribuídos ao potencial parceiro em função da quantidade de contratos de Soluções de Software realizados nas seguintes tecnologias por classe abaixo, em versão igual ou superior reportada no artefato “Ambiente Tecnológico de Solução de Software”: Framework Classe Transacional: Genexus. Framework Classe APP: IONIC e/ou React Native. A comprovação dar-se-á mediante a apresentação de atestados de capacidade técnica emitidos por órgãos do setor público participantes das esferas Estadual e Federal, incluindo o Distrito Federal-DF.		03(três) pontos por atestado apresentado, máximo de 02(dois) atestados por classe de framework.
Pontuação do Fator Compatibilidade (PFC)			Máximo = 16 pontos
1.3 Experiência em desenvolvimento e implantação de Soluções de Software mediante comprovação em atestados de capacidade técnica emitidos por empresas brasileiras ou estrangeiras com ativos superiores a R$140.000.000,00 (cento e quarenta milhões de reais) e/ou com faturamento anual superior a R$200.000.000,00 (duzentos milhões de reais) e/ou emitidos por órgãos da administração direta e indireta dos Municípios, Estados, União, Distrito Federal ou por representantes de		04(quatro) pontos por atestado apresentado, máximo de 04(quatro) atestados.

Governos estrangeiros. Serão aceitos atestados de qualificação emitidos por prefeituras de municípios com orçamento anual superior a 200 milhões a fim de equivaler ao faturamento de uma empresa privada conforme previsão no edital, devido ao grau de complexidade da administração dessas prefeituras se equivalerem ao objeto pretendido no chamamento público. Esses valores foram estipulados para equivaler ao tamanho e complexidade administrativa de um órgão governamental médio de um estado como Mato Grosso seja da administração direta ou indireta.A exemplo da própria MTI que tem um orçamento anual médio de aproximadamente 140 milhões. Pontos atribuídos ao potencial parceiro em função da quantidade de contratos de Soluções de Software realizados nas empresas brasileiras, em órgãos da administração direta e indireta dos Estados e/ou União e/ou Distrito Federal-DF e/ou Governos estrangeiros: No caso de serviços prestados ao exterior, será permitida a autodeclaração do profissional acompanhado da identificação do nome e email do representante do Governo estrangeiro para conferência. Nos demais casos será exigido atestado de capacidade técnica emitido pela empresa brasileira ou órgãos da administração direta ou indireta dos Estados e/ou União e/ou Distrito Federal- DF.
Pontuação do Fator de Serviço (PFS)			Máximo = 16 pontos
1.4 Conhecimento de metodologias ágeis aplicáveis aos serviços referenciados no MR-PDA, mediante comprovação em atestados de capacidade técnica emitidos por empresas brasileiras ou estrangeiras com ativos superiores a R$140.000.000,00 (cento e quarenta milhões de reais) e/ou com faturamento anual superior a R$200.000.000,00 (duzentos milhões de reais) e/ou emitidos por órgãos da administração direta e indireta dos Municípios, Estados, União, Distrito Federal ou por representantes de Governos estrangeiros. Serão aceitos atestados de qualificação emitidos por prefeituras de municípios com orçamento anual superior a 200 milhões a fim de equivaler ao faturamento de uma empresa privada conforme previsão no edital, devido ao grau de complexidade da administração dessas prefeituras se equivalerem ao objeto pretendido no chamamento público. Esses valores foram estipulados para equivaler ao tamanho e complexidade administrativa de um órgão governamental médio de um estado como Mato Grosso seja da administração direta ou indireta.A exemplo da própria MTI que tem um orçamento anual médio de aproximadamente 140 milhões. Pontos atribuídos ao potencial parceiro em função do seu conhecimento em metodologias de gestão e especificação de projetos de Solução de Software para a prestação dos serviços descritos na Especificação Técnica, adquirido no Brasil e no Mundo. No caso de serviços prestados no exterior, será permitida a autodeclaração do profissional acompanhado da identificação do nome e email do representante do Governo estrangeiro para conferência. Nos demais casos, será exigido atestado de		02 (dois) pontos por atestado apresentado, máximo de 08 (oito) atestados.

capacidade técnica emitido pela empresa brasileira ou órgãos da administração direta ou indireta da União.
Pontuação do Fator Qualidade (PFQ)			Máximo = 20 pontos
1.5 Experiência dos profissionais que executarão os serviços A comprovação dar-se-á mediante a apresentação de curriculum acompanhado de atestados de capacidade técnica emitidos em nome da empresa, comprovando em nome dos profissionais que participarão da equipe que prestará os serviços. As especialidades profissionais, com devida especificação no MR- PDA, são as seguintes: (i) Gerente de Solução de Software; (ii) Consultor de Projetos de Solução de Software; (iii) Arquiteto1; (iv) Analista de Negócios; (v) Analista de Qualidade2; (vi) Designer; (vii) Cientista de Dados; (viii) Especialista em Desenvolvimento Ágil3.		01(um) ponto para cada atestado apresentado. É necessário apresentar pelo menos 01(um) atestado para cada uma das habilidades solicitadas, exceto Cientista de Dados. Os profissionais deverão ter vínculo laboral com o parceiro durante o período do procedimento de Chamamento Público para Seleção de Possível Parceiro, seja como empregado, seja como contratado Xxxxxx Xxxxxxxx, ou que tenha participação societária ou a existência de contrato de prestação de serviços regidos pela legislação civil comum. Em todos os casos deve haver comprovação do vínculo.
II. Índice Técnico: A determinação do índice técnico será efetuada mediante a soma algébrica dos pontos obtidos nos quesitos acima. Havendo empate, a definição da ordem de ranqueamento técnico se dará por meio de sorteio.

9.4. Os critérios de ranqueamento técnico objetivam medir o grau de qualificação e maturidade do proponente em relação aos requisitos técnicos mais importantes para MTI, sendo eles:

9.4.1. PFDP - Pontuação do Fator de Desempenho de Programação: esta pontuação objetiva qualificar a experiência dos participantes nas tecnologias que são mais recorrentes no Estado de Mato Grosso, com experiências bem sucedidas em clientes que tenham características similares aos principais clientes potenciais da MTI.

9.4.2. PFDW - Pontuação do Fator Desempenho de Framework: esta pontuação objetiva qualificar a experiência dos participantes nos frameworks de amplo uso no mercado e já em utilização em cases desenvolvidos no Estado de

1 Consultar as especializações deste perfil no MR-PDA. 2 Consultar as especializações deste perfil no MR-PDA. 3 Consultar as especializações deste perfil no MR-PDA.

Mato Grosso, demonstrando a experiência do proponente também na utilização dessas tecnologias, conferindo um grau de ranqueamento maior a quem já possuir expertise na entrega de cases de sucesso utilizando essas tecnologias.

9.4.3. PFC - Pontuação do Fator de Compatibilidade: esta pontuação objetiva comprovar a execução de serviços em entidades, empresas e órgãos públicos, que possuam equivalência em complexidade de gestão, processos e serviços, aos principais clientes da MTI, sendo importante observar que existe uma diferença de complexidade operacional entre entidades/empresas/órgãos públicos (pequeno, médio e grande porte), desta forma, dadas as características dos órgãos públicos estaduais que são potencialmente clientes da MTI, quais possuem porte médio para grande.

9.4.4. PFS - Pontuação do Fator de Serviços: esta pontuação objetiva medir o conhecimento de metodologias ágeis aplicáveis aos serviços referenciados no MR-PDA,

9.4.5. PFQ - Pontuação do Fator de Qualidade: esta pontuação objetiva avaliar a experiência da equipe técnica do proponente em função do seu conhecimento em metodologias de gestão e especificação de projetos de Solução de Software para a prestação dos serviços descritos.

9.5. Avaliação da Proposta de interesse comercial: a Proposta de interesse comercial será avaliada pela Comissão Especial referenciando critérios e parâmetros relacionados abaixo, que evidenciam o Apetite de Investimento na parceria (Previsão de investimento direto do proponente), aporte de mentoriamento e conhecimento na MTI e o retorno financeiro para a empresa pública:

CRITÉRIOS E PARÂMETROS PARA RANQUEAMENTO DE PROPOSTA DE INTERESSE COMERCIAL I. Fórmula para Apuração de Pontuação de Negócio PN = PFVU + PFAN + PFIP + PFPIS + PFLI + PFPE + PFII + PFTL + PFET + PFPP
	DESCRIÇÃO			PONTUAÇÃO
1. Pontuação da Proposta de interesse comercial (PN)					Máximo = 100 pontos
PFVU - Pontuação do Fator do Valor da UST
PFAN - Pontuação do Fator de Aceleração de Negócios
PFIP - Pontuação do Fator de Incentivo Progressivo
PFPIS – Pontuação do Fator Proposta de Investimento Social
PFLI – Pontuação do Fator Laboratório de Inovação
PFPE – Pontuação do Fator Publicidade e Eventos
PFII – Pontuação do Fator Investimento em Infraestrutura da MTI
PFTL – Pontuação do Fator Treinamento In Loco

PFET – Pontuação do Fator Eventos Tecnológicos Fora do Estado de Mato Grosso
PFPP – Pontuação do Fator Propriedade Industrial de Produto
Fórmula para Apuração da Pontuação de Negócio (PN) PN = PFVU + PFAN + PFIP + PFPIS + PFLI + PFPE + PFII + PFTL + PFET + PFPP
Pontuação do Fator do Valor da UST - PFVU			Máximo = 10 pontos
1.1 Este critério o proponente baseado nas informações deste Edital, irá propor um valor nominal de precificação para a UST – Unidade de Serviço Técnico a ser usado como base para a execução dos serviços no modelo operacional proposto para a eventual parceria através deste Edital e seus Anexos, levando em conta que esta UST abrange todas as etapas e serviços executados no Produto Fábrica de Software da MTI incluindo além das atividades da interessada no processo, da própria MTI.		Para atribuição da pontuação final desse quesito, serão apurados o maior e menor valor de UST proposto entre os proponentes, será atribuído 10(Dez) pontos para a proposta com o UST de menor valor, sendo que os demais receberão pontuações proporcionais, conforme a fórmula: PFVU = 10 x Menor Valor Nominal UST / Valor Nominal UST
Pontuação do Fator de Aceleração de Negócios - PFAN				Máximo = 10 pontos
1.2 Valor mínimo anual proposto para aporte de recursos financeiros utilizados para o fomento à inovação e investimentos produtivos em startups ou outro modelo de investimento de empresas ou solução com alto potencial de crescimento.		Para atribuição da pontuação final desse quesito, serão apurados o maior e menor valor proposto entre os proponentes, será atribuído 10(Dez) pontos para a proposta com o maior valor, sendo que os demais receberão pontuações proporcionais, conforme a fórmula: PFAN = 10 * Valor Proposto / Maior Valor Proposto
Pontuação do Fator Incentivo Progressivo - PFIP				Máximo = 10 pontos

1.3 Incentivo progressivo por volume de negócios: percentual	Para atribuição da
financeiro anual retornado a MTI do volume de recebimento do	pontuação final desse
proponente (a cada R$ 300.000,00 – trezentos mil reais) como	quesito, serão
incentivo ao obtenção de meta de recebimento dos serviços	apurados o maior e
entregues ao cliente final.	menor percentual
	proposto entre os
	proponentes, será
	atribuído 10(Dez)
	pontos para a proposta
	com o maior valor,
	sendo que os demais
	receberão pontuações
	proporcionais,
	conforme a fórmula:
	PFIP = 10 * Percentual
	Proposto / Maior
	Percentual Proposto
Pontuação do Fator Proposta de Investimento Social- PFPIS	Máximo = 10 pontos
1.4 A MTI propõe que se possa desenvolver em conjunto no âmbito da parceria projetos de cunho social para benefício de camadas menos favorecidas da sociedade. Com esse cenário, qual seria a disponibilidade do proponente em investir em projetos com esse cunho, como doação. O PFPIS, é a oportunidade da interessada se manifestar em quantas UST poderiam ser disponibilizadas anualmente como doação e investimento da interessada para apoiar o desenvolvimento de soluções tecnológicas em benefício da sociedade. Vamos denominar essa doação de UST Social.	Para atribuição da pontuação final desse quesito, serão apurados o maior e menor valor de percentual para a MTI do valor da UST proposto entre os proponentes. Será calculado ente os valores da UST propostos e o percentual proposto o valor real líquido como participação da MTI na entrega da UST. A partir desse momento será atribuído 10(Dez) pontos para o maior valor líquido para MTI, sendo que os demais receberão pontuações proporcionais, conforme a fórmula:
	PFPIS = 10 * Quantidade de UST Social / Maior quantidade de UST Social Apurada

Pontuação do Fator Laboratório de Inovação - PFLI			Máximo = 10 pontos
1.5 Valor mínimo anual proposto para investimento em laboratório de inovação tecnológica na MTI para exploração de tecnologias e tendências relacionadas ao objeto desta parceria.		Para atribuição da pontuação final desse quesito, serão apurados o maior e menor valor proposto entre os proponentes, será atribuído 10(Dez) pontos para a proposta com maior valor, sendo que os demais receberão pontuações proporcionais, conforme a fórmula: PFLI = 10 x Valor Proposto / Maior Valor Proposto
Pontuação do Fator Publicidade e Eventos - PFPE			Máximo = 10 pontos
1.6 Valor mínimo anual proposto para investimento em campanhas de publicidade, participação ou promoção de eventos, ou qualquer outro mecanismo para disseminação da parceria.		Para atribuição da pontuação final desse quesito, serão apurados o maior e menor valor proposto entre os proponentes, será atribuído 10(Dez) pontos para a proposta com maior valor, sendo que os demais receberão pontuações proporcionais, conforme a fórmula: PFPE = 10 x Valor Proposto / Maior Valor Proposto
Pontuação do Fator Investimento em Infraestrutura da MTI - PFII		Máximo = 10 pontos
1.7 Valor mínimo anual proposto para investimento na infraestrutura(tecnológica ou física) a fim de incentivar o crescimento e modernização da empresa.		Para atribuição da pontuação final desse quesito, serão apurados o maior e menor valor proposto entre os proponentes, será atribuído 10(Dez) pontos para a proposta com maior valor, sendo que os demais receberão pontuações proporcionais, conforme a fórmula:

		PFII = 10 x Valor Proposto / Maior Valor Proposto
Pontuação do Fator Treinamento In Loco - PFTL			Máximo = 10 pontos
1.8 Carga horária anual fornecida pelo proponente para capacitação da equipe técnica da MTI sobre assuntos relacionados ao objeto da parceria na cidade de Cuiabá-MT. Em horas.		Para atribuição da pontuação final desse quesito, serão apurados a maior e menor carga horária proposta entre os proponentes, será atribuído 10(Dez) pontos para a proposta com maior carga horária, sendo que os demais receberão pontuações proporcionais, conforme a fórmula: PFTL = 10 x Carga Horária Proposta / Maior Carga Horária Proposta
Pontuação do Fator Eventos Tecnológicos Fora do Estado de Mato Grosso - PFET		Máximo = 10 pontos
1.9 Quantidade de empregados da MTI que serão capacitados anualmente fora do Estado de Mato Grosso em cursos ou eventos relacionados ao objeto da parceria.		Para atribuição da pontuação final desse quesito, serão apurados o maior e menor número de empregados proposto entre os proponentes, será atribuído 10(Dez) pontos para a proposta com maior número de empregados envolvidos em treinamentos/eventos fora do estado, sendo que os demais receberão pontuações proporcionais, conforme a fórmula: PFET = 10 x Quantidade Proposta / Maior Quantidade Proposta

Pontuação do Fator Propriedade Industrial de Produto - PFPP	Máximo = 10 pontos
1.10 Compromisso da interessada para arcar com os custos relacionados aos processo de registro de propriedade industrial nacional ou internacionalmente, devidamente quando acordado entre as partes.	Sim – Pontuação total Não – Sem pontuação
II. Índice de Negócio A determinação do Índice de Negócio será efetuada mediante a soma algébrica dos pontos obtidos nos quesitos acima. Havendo empate, a definição da ordem de ranqueamento de negócio se dará por meio de sorteio.

9.6. Apuração de Ranqueamento para a possível PARCERIA :

O ranqueamento das interessadas para efeitos de celebração da possível parceria se dará a partir da operacionalização da fórmula abaixo, onde RP significa “Ranqueamento para possível Parceria”, que disponibilizará, após publicação, prerrogativa, ao ranqueado como primeiro colocado, de iniciar as tratativas do modelo de negócio para futura e eventual parceria com a MTI.

RP = [(PT * 70) + [(PN * 30)] / 100

Fórmula para Apuração Final de Ranqueamento da Interessada

SEÇÃO X – DOS RECURSOS

10.1. Após a avaliação das propostas pela Comissão Especial e publicadas as propostas no sítio eletrônico oficial da MTI, será conferido o prazo de 5 (cinco) dias úteis para recurso.

10.1.1. Caso as INTERESSADAS desejem, poderão apresentar contrarrazões ao recurso, no prazo de 5 (cinco) dias úteis.

10.2. A interposição de recurso deverá ser realizada, exclusivamente, de forma eletrônica, para o e-mail xxxxxxxxx@xxx.xx.xxx.xx, com a apresentação das razões de recurso, devidamente fundamentada.

10.3. É assegurada às INTERESSADAS, vista imediata dos autos, com a finalidade de subsidiar a preparação dos recursos administrativos, uma vez que o presente processo terá a versão física e os trâmites eletrônicos por questão de celeridade, sendo que o processo físico será instruído com todas as informações que forem recebidas através do e-mail xxxxxxxxx@xxx.xx.xxx.xx.

10.4. A Comissão Especial instituída decidirá os recursos no prazo de 05 (cinco) dias úteis, a contar do término do prazo das interessadas. A decisão da Comissão Especial deverá ser motivada e, quando ela mantiver sua decisão, deverá submetê-la à autoridade competente, que proferirá sua decisão dentro do prazo de 5 (cinco) dias úteis.

10.5. A Comissão Especial poderá solicitar pareceres da área técnica, da Unidade de Assessoria Jurídica/Procuradoria Geral do Estado, para subsidiar na decisão quanto o recurso e contrarrazões.

10.6. A decisão definitiva sobre a avaliação das propostas e seleção da interessada deverá ser publicada no Diário Oficial do Estado, além de ser disponibilizada no site da MTI.

10.7. O acolhimento do recurso administrativo implica tão somente na invalidação dos atos que não sejam passíveis de aproveitamento.

10.8. Não serão conhecidos os recursos administrativos interpostos após os respectivos prazos legais, bem como aqueles que não estiverem devidamente motivados.

10.8.1. Recurso devidamente motivado é aquele que indica, objetivamente, o fato e o direito que a interessada deseja ser revisto pela Comissão/autoridade competente.

SEÇÃO XI – DO SIGILO, PROPRIEDADE DAS INFORMAÇÕES, DIREITO PATRIMONIAL E PROPRIEDADE INTELECTUAL

11.1. Propriedade dos Produtos e Serviços

11.1.1. Todos os produtos gerados na vigência do contrato serão de propriedade da MTI. Isso inclui todos os artefatos e produtos produzidos ao longo do contrato, tais como dados, documentos e elementos de informação pertinentes à tecnologia de concepção, desenvolvimento, implantação de qualquer natureza e aplicação, tais como produtos de software, programas-fonte, classes e componentes, relatórios, diagramas, fluxogramas e modelos, arquivos. A regra está em conformidade com o Art. 80 da Lei nº 13.303, de 2016, com a Lei nº 9.609, de 1998, que dispõe sobre propriedade intelectual de programa de computador e com a Lei nº 9.610, de 1998, que dispõe sobre direito autoral, sendo vedada a comercialização, a qualquer título, destes por parte das INTERESSADAS.

11.1.2. A utilização de soluções ou componentes proprietários da Interessada ou de terceiros na construção dos programas ou quaisquer artefatos relacionados ao presente contrato, que possam afetar a propriedade do produto, deve ser formal e previamente autorizada pela MTI.

11.1.3. A Interessada e os profissionais alocados na execução dos serviços transferem à MTI, de forma incondicional, todos os direitos referentes à propriedade intelectual sobre os documentos produzidos no âmbito do contrato, inclusive para fins de registro no Instituto Nacional de Propriedade Industrial - INPI.

11.2. CONFIDENCIALIDADE

11.2.1. A Interessada deve manter a mais absoluta confidencialidade a respeito de quaisquer informações, dados, processos, fórmulas, códigos, cadastros, fluxogramas, diagramas lógicos, dispositivos, modelos ou outros materiais de propriedade da MTI ou de terceiros, aos quais tiver acesso em decorrência da prestação de serviços objeto do contrato, ficando terminantemente proibida de fazer uso ou revelar estes, sob qualquer justificativa.

11.2.2. A Interessada deverá, através de seu representante legal, firmar acordo de confidencialidade de informação e dar ciência do mesmo a toda a sua equipe de profissionais que participarão da execução do contrato de parceria,

comprometendo-se perante à MTI, por meio da assinatura do Termo de Responsabilidade e Sigilo, a observância das obrigações nele descrito.

11.2.3. É vedada a veiculação de publicidade acerca do contrato, salvo se houver prévia autorização da MTI.

SEÇÃO XII – DA COMISSÃO ESPECIAL DE AVALIAÇÃO E JULGAMENTO

12.1. O Chamamento Público será processado pela Comissão Especial instituída através da Portaria/MTI Nº 012/2020, que terá a incumbência de conduzir todos os atos referentes à seleção das propostas relativas ao presente Edital.

12.2. Além das prerrogativas que decorrem de sua função legal, a Comissão Especial poderá:

12.2.1. Solicitar às interessadas, a qualquer momento, esclarecimentos sobre os documentos por elas apresentadas;

12.2.2. Promover diligência destinada a esclarecer ou complementar instrução do procedimento, nos termos legais;

12.2.3. Prorrogar ou antecipar, respeitados os limites legais, os prazos de que trata o Edital, em caso de interesse público, caso fortuito ou força maior;

12.3. Inabilitar/desclassificar a interessada que recusar em fornecer esclarecimentos e documentos ou em cumprir as exigências solicitadas pela Comissão Especial, nos prazos por ela determinados e de acordo com os termos do edital.

SEÇÃO XIII – DO LOCAL DE EXECUÇÃO

13.1. Os serviços serão executados sob gestão da MTI, podendo ser operacionalizados em modelo físico e digital, em ambiente intranet e extranet, nas dependências da MTI.

13.2. Sob análise e autorização da MTI, também poderão ser executados nas dependências de clientes da MTI, mantendo a obrigatoriedade de gestão da empresa pública.

13.3. As Modalidades digitais de execução, baseadas no conceito intranet, internet e extranet, poderão ser alvos de acordo entre a MTI e a Interessada, sempre justificada na busca da eficiência laboral, minimização de tempo de resposta de entregáveis de Solução de Software e economicidade.

SEÇÃO XIV - DAS DISPOSIÇÕES GERAIS

14.1. Não havendo expediente ou ocorrendo qualquer fato superveniente que impeça o funcionamento da MTI, as datas previstas serão automaticamente transferidas para o primeiro dia útil subsequente, no mesmo horário anteriormente estabelecido, desde que não haja comunicação da MTI em contrário.

14.2. Todos os horários estabelecidos neste Edital observarão o horário de Cuiabá – MT.

14.3. As normas que disciplinam este Edital serão sempre interpretadas de forma a evitar exclusividade de fornecimento, sem preferências ou direcionamento da concessão dos serviços entre as INTERESSADAS,

14.4. O desatendimento de exigências formais não essenciais não importará no afastamento das INTERESSADAS, desde que seja possível a correção durante o processo.

14.5. As INTERESSADAS são responsáveis pela fidelidade e legitimidade das informações e dos documentos apresentados em qualquer fase deste processo.

14.6. Na contagem dos prazos estabelecidos neste Edital e seus Anexos, excluir- se-á o dia do início e incluir-se-á o do vencimento. Só se iniciam e vencem os prazos em dias de expediente na MTI.

14.7. A autoridade competente poderá revogar o presente procedimento de chamamento por razões de interesse público decorrente de fato superveniente devidamente comprovado, pertinente e suficiente para justificar tal conduta, devendo anulá-lo por ilegalidade, de ofício ou por provocação de terceiros, mediante parecer escrito e devidamente fundamentado.

14.8. As empresas interessadas deverão acompanhar, por meio do sítio da MTI e Diário Oficial do Estado, todas as alterações que venham ocorrer neste Edital e seus Anexos.

14.8.1. Qualquer erro no cadastramento dos dados da empresa interessada em participar deste procedimento será de sua responsabilidade.

14.9. Os Anexos deste Edital constituem o rol das obrigações decorrentes do presente procedimento, dele fazendo parte, obrigando as partes ao inteiro teor de suas disposições.

14.10. Os casos não previstos neste Edital serão resolvidos pela Comissão Especial.

14.11. A MTI e a interessada não são obrigadas a firmar contrato de parceria sobre o modelo de negócio desenvolvido por meio deste Chamamento Público.

Cuiabá, 23 de abril de 2020.

Xxxxxx Xxxxxxxxx Xxxxx xxx Xxxxxx Diretor-Presidente Interino

Empresa Mato-Grossense de Tecnologia da Informação

ANEXO I - MODELO DE REFERÊNCIA DE PRÁTICAS DE DESENVOLVIMENTO ÁGIL PARA FÁBRICA DE SOFTWARE COM PARCERIA

1. Motivações para elaboração deste Modelo de Referência

A MTI tem evoluído seus processos tornando mais ágil, adaptável e escalável. Diversas iniciativas foram tomadas para tal evolução e este modelo de trabalho faz parte desse conjunto de ações.

Em razão da falta de pessoal necessário atendimento do volume de demandas, muitas atividades importantes do processo de software deixam de serem executadas, tais como gestão de demandas, suporte a sistemas legados e desenvolvidos, gerenciamento do ciclo de vida de produtos e soluções, estabilização, gestão de indicadores, registro de lições aprendidas e administração de dados. Essa falha pode trazer danos, prejudicando os princípios da economicidade, da eficiência e da continuidade do serviço público.

Nesse sentido, para suprir o crescente volume de demandas por soluções de TI e evitar impactos nos processos de negócio de competência dos órgãos do Poder Executivo do Estado de Mato Grosso para a sociedade, fez-se necessário investir na estruturação dos serviços de desenvolvimento e sustentação para que se possa garantir o correto funcionamento dos sistemas de informação destas entidades, bem como a ampliação de suas soluções informatizadas. Em adição a estes serviços, é importante contar com o apoio técnico para os processos de desenvolvimento de software, viabilizando um contínuo aprimoramento dos processos de trabalho e o suprimento das carências de quadro próprio para a execução desses serviços.

Outra motivação ocorreu em meados de 2018, quando a Lei 13303, de 2016 foi implantada na sua totalidade, trazendo novas possibilidades por meio da forma de contratação e realização de parcerias estratégicas.

Considerando o cenário exposto e as possibilidades prevista na Lei 13303, de 2016 este modelo visa:

● Ser escalável permitindo a ampliação no atendimento com menor impacto;

● Permitir que o quadro efetivo da MTI assimile o conhecimento do negócio viabilizando novas propostas de soluções negociais e de atualizações tecnológicas;

● Aumentar capacidade de entregas com qualidade;

● Possibilitar a redução da atuação do quadro da MTI em atividades operacionais do processo de desenvolvimento de software;

● Garantir entregáveis/artefatos mínimos para continuidade do negócio.

A MTI entende que é de extrema importância a implantação de um modelo mais ágil para o cumprimento de sua missão institucional e melhoria dos serviços prestados. Este Modelo de Referência, sob conceito de fábrica de software, baseia-se na parceria utilizando práticas ágeis, tendo como métrica a unidade de serviço técnico, com parceiro comprovadamente qualificado, observando os princípios da administração pública e garantindo qualidade dos sistemas entregues.

2. Produto Específico fruto da PARCERIA entre a MTI e a INTERESSADA

A próxima ação inerente a evolução citada no item acima, está na construção conjunta, utilizando INTERESSADA da iniciativa privada, de Serviços que façam frente a demanda de Desenvolvimento, Manutenção e Sustentação de Soluções de Software junto aos clientes da MTI. Neste contexto, a MTI conjuntamente com a sua INTERESSADA, entregará e suportará os seguintes macro serviços:

Serviços de Qualidade de Software, Arquitetura Tecnológica e Garantia de Continuidade Tecnológica: este serviço é caracterizado na Equipe Técnica da MTI como “Garantia da Qualidade Técnica e Garantia da Continuidade Tecnológica do Negócio do Cliente”, onde todas as células (Projeto e Sustentação) sofrerão ações de gestão e controle de qualidade (Quality Assurance(QA)), tal como disciplinas focadas em administração de software base, configurações e mudanças centradas na continuidade do negócio do cliente e garantia da continuidade tecnológica.

Sustentação de Soluções de Software: este serviço é caracterizado em “Célula de Manutenção e Sustentação de Solução de Software”.

Projetos de Soluções de Software: este serviço é caracterizado em “Célula de Projeto de Solução de Software” .

As equipes de trabalho serão constituídas de forma colaborativa, composta em parte pela MTI e parte pela INTERESSADA.

Os profissionais da MTI participantes das equipes de trabalho são:

● Analista DBA (Administração de Banco de Dados)

● Analista de Infraestrutura e Facilities de TI

● Arquiteto de Tecnologia da Informação

● Desenvolvedor

● Analista de Administrador de Dados

● Analista de Conformidade

● Analista de Configuração e Mudança

Os profissionais da Interessada participante das equipes de trabalho são:

● Líder da Célula

● Analista de Negócio

● Arquiteto

● Desenvolvedor

● Analista de Qualidade

● Designer

● Cientista de Dados

● Gerente de Sistemas

O profissional do CLIENTE participante da equipe de trabalho é:

● Dono do Produto

A visão gráfica do modelo referenciado acima, está reportado no “Anexo II – Modelo de Operação da Fábrica de Software” do presente Modelo de Referência de Práticas de Desenvolvimento Ágil para Fábrica de Software com Parceria.

Os serviços reportados acima, fruto da possível PARCERIA entre a MTI e a INTERESSADA, caracteriza PRODUTO ESPECÍFICO com característica INÉDITA, focado em Soluções de Software a ser ofertado aos clientes da MTI.

3. Modelo de Referência de Práticas de Desenvolvimento Ágil

Este modelo é baseado em práticas ágeis e é composto por Células de Projetos de Soluções de Software e Células de Manutenção e Sustentação de Sistemas, descritos neste modelo de referência. Para operacionalizar tais práticas, a MTI concebeu um modelo de operação a ser adotado a partir da contratação de Fábrica de Software, conforme apresentado no “Anexo II - Modelo de Operação da Fábrica de Software”.

Figura 1 - Referência para a Operação Fonte: Elaboração própria

Os benefícios encontrados na aplicação de metodologias ágeis e a evidência do crescimento da adoção de métodos ágeis em instituições públicas, conforme registrado no Guia de projetos de software com práticas de métodos ágeis para o SISP4.

Para o entendimento dos processos de trabalho referenciados, faz-se necessário a explicação do modelo de execução de projetos, descrevendo a composição das células e suas respectivas responsabilidades referenciando cada ator participante da equipe, conforme reportado a seguir.

O modelo operacional é formado por times compostos por técnicos da MTI e técnicos da empresa INTERESSADA, o que o caracteriza como escalável de forma a permitir ampliação na força de atendimento das demandas.

O modelo é composto por 02(dois) tipos de células e equipe técnica:

● Célula de Projeto;

● Célula de Manutenção e Sustentação;

● Equipe Técnica da MTI.

As Célula de Projeto e Célula de Manutenção e Sustentação são compostas predominantemente por equipe da INTERESSADA, exceto o “Líder da Célula” que deve estar, obrigatoriamente, sob gestão da MTI e pelo Dono do Produto que representa o cliente da Solução de Software.

4 Guia de projetos de software com práticas de métodos ágeis para o SISP, disponhttp://xxxx.xxx.xx/xxxxxxxx/xxxx/xxxxxxxx/xxxx/Xxxx_xx_Xxxxxxxx_%X0%00xxxx

A Equipe Técnica é composta exclusivamente por equipe da MTI, ou por ela designado.

As equipes das Célula de Projeto e Célula de Manutenção e Sustentação, devem estar alocadas fisicamente nas dependências da MTI ou local por ela designado, conforme acordado previamente com a MTI. Essas células são compostas por equipe mista que executará atividades transversais desde o entendimento da demanda até a entrega da solução. As células serão criadas sob demanda a partir de necessidades específicas.

O perfil “Líder da Célula” deve ser inteiramente dedicado a apenas uma Célula de Projeto ou uma Célula de Manutenção e Sustentação, exceto quando houver mais de uma Célula de Projeto para atendimento de uma Solução de Software. Neste caso um Líder de Xxxxxx pode atuar em mais de uma Célula de Projeto mediante acordo prévio entre a MTI e a INTERESSADA.

a. Célula de Projeto

A orientação e suporte a adoção das práticas ágeis para estabelecimento de planejamento e dinâmica de trabalho da célula é de responsabilidade do Gerente de Sistemas. Dessa forma as práticas podem variar de acordo com as caraterísticas do projeto e da equipe da Célula de Projeto.

Cada Célula de Projeto deve atender às demandas de projeto de desenvolvimento de soluções de software relacionadas à área de negócio demandante. A INTERESSADA deve alocar equipes que consigam atender as demandas de projetos utilizando práticas ágeis de desenvolvimento de Software. Além disso, para melhor atender às demandas da Célula de Projeto, os profissionais da INTERESSADA podem ser requisitados para esclarecer eventuais dúvidas, solucionar pendências e participar de reuniões.

Cada Célula de Projeto deve ser focada no atendimento de uma demanda do cliente, denominada de Solução de Software. Para atender uma Solução de Software demandada pelo cliente, poderá haver a necessidade da existência de mais de uma Célula de Projeto para atuar na construção da solução de software, em função do tamanho do projeto ou da diversidade de tecnologia envolvida.

Caso não tenha sido criada mais de uma Célula de Projeto para atuar na construção da demanda do cliente e com a evolução do projeto a capacidade de atendimento da Célula de Projeto não esteja de acordo com o fluxo de demandas de Projetos, consequentemente não atendendo o nível de serviço estabelecido, esta deverá ser ajustada pela INTERESSADA.

b. Célula de Manutenção e Sustentação

Cada Célula de Manutenção e Sustentação deve atender às demandas de manutenção e de sustentação de sistemas, conforme capacidade acordada. Neste sentido, a INTERESSADA deve alocar equipes que consigam resolver em paralelo tanto as demandas de manutenção, como as demandas de sustentação

dos sistemas alocados à Célula, o andamento das manutenções não pode ser prejudicado a pretexto da resolução das demandas de sustentação. Da mesma forma, as demandas de sustentação não podem ser prejudicadas pelas atividades de manutenção. Além disso, para melhor atender às demandas da célula, os profissionais da INTERESSADA podem ser requisitados para esclarecer eventuais dúvidas, solucionar pendências e participar de reuniões.

Com o objetivo de potencializar recurso da INTERESSADA, o perfil Desenvolvedor da Célula de Manutenção e Sustentação pode tanto atuar no atendimento dos serviços de Manutenção como no de Sustentação de sistema.

Uma Célula de Manutenção e Sustentação pode assumir vários sistemas para:

● Manutenção e sustentação;

● Manutenção de soluções que não estejam sendo sustentados pela INTERESSADA.

A manutenção adaptativa ou evolutiva de um sistema em sustentação pela INTERESSADA também deve ser realizada por essa INTERESSADA.

Especificamente sobre a atividade de manutenção, a Célula de Manutenção e Sustentação deve resolver as manutenções relativas à correção, alteração, exclusão ou inclusão de nova funcionalidade em aplicação existente, ou conjunto de funcionalidades que não seja classificado preliminarmente pela MTI como Projeto.

Em relação a atividade de sustentação, a Célula de Manutenção e Sustentação deve realizar todos os serviços aplicáveis à sustentação, de acordo com o nível de serviço. O detalhamento destes serviços está especificado no “Catálogo de Serviços de Solução de Software” sob a métrica UST.

Deve-se destacar que quando a Manutenção corretiva for realizada em funcionalidade que esteja em período de garantia, esta correção não gera remuneração para a INTERESSADA. Assim, a Manutenção corretiva somente será remunerada quando realizada em funcionalidade após o prazo de garantia ou nos sistemas que não tenham sido mantidos pela INTERESSADA.

Caso a capacidade de atendimento da Célula de Manutenção e Sustentação não esteja de acordo com os fluxos “Anexo I-D – Executar Manutenção de Solução de Software” e “Anexo I-E – Realizar Sustentação de Solução de Software” ambos do presente Modelo de Referência de Práticas de Desenvolvimento Ágil para Fábrica de Software com Parceria, e, não atendendo os níveis de serviços estabelecidos, a Célula de Manutenção e Sustentação deverá ser ajustada pela INTERESSADA. Assim, a INTERESSADA deve gerenciar os seus recursos humanos e materiais de forma a atender todas as demandas da Célula de Manutenção e Sustentação conforme os níveis de serviço estabelecidos. Ou seja, a alocação de profissionais em cada célula é de responsabilidade da INTERESSADA.

A Célula de Manutenção e Sustentação deve receber as demandas por meio da ferramenta de gestão cujo as características estão definidas pela MTI no Anexo III - Características das Ferramentas Técnicas e de Gestão. A INTERESSADA

deve atender às demandas formalizadas abrangendo desde a investigação e entendimento de escopo das demandas até a entrega das soluções de software em ambiente de produção.

c. Composição das Células

Considerando as premissas de práticas de desenvolvimento ágil, os papéis do Desenvolvimento de Software (ex.: análise de requisitos) não são transformados em cargos. Por isso, não há cargos específicos para cada um desses papéis (como, por exemplo, Analista de Requisito ou Designer). Todo time deve ter, de maneira conjunta, a competência necessária para executar todas as camadas participantes do Processo de Desenvolvimento de Software.

Cada Célula de Projeto deve ser composta pelos papéis inerentes ao Profissional da MTI (PM) e Profissional da INTERESSADA (PP):

1. Líder da célula (PM);

2. Dono do Produto (Cliente);

3. Analista de Negócio (PP);

4. Desenvolvedor (PP);

5. Designer (PP);

6. Analista de Qualidade (PP);

7. Arquiteto (PP);

8. Consultor de Projetos (PP);

9. Gerente de Sistemas (PP).

Cada Célula de Manutenção e Sustentação deve ser composta pelos perfis:

1. Líder da célula (PM);

2. Analista de Negócio (PP);

3. Desenvolvedor (PP);

4. Designer (PP);

5. Analista de Qualidade (PP);

6. Arquiteto (PP);

7. Gerente de Sistemas (PP).

As atribuições, responsabilidades e requisitos de qualificação técnica dos papéis está registrado no “Anexo VIII- Perfil Profissional” do presente Modelo de Referência de Práticas de Desenvolvimento Ágil para Fábrica de Software com Parceria.

Os profissionais da INTERESSADA que atuarem nos papéis Desenvolvedor, Analista de Qualidade e Analista de Negócio devem ser dedicados a apenas uma Célula de Projeto. Quando se tratar de Célula de Sustentação e Manutenção, o perfil Desenvolvedor pode atuar na Sustentação e/ou Manutenção de mais de um sistema, desde de que os sistemas estejam vinculados a uma única Célula de Sustentação e Manutenção.

Os profissionais da INTERESSADA que atuam nos papéis Designer e Arquiteto poderão ser alocados em mais de uma Célula, mediante anuência da MTI. Já o profissional Cientista de Dados, será alocado ou apoiará a célula conforme o requisito do projeto demandado. O perfil Consultor de Projetos e não serão alocados em nenhuma Célula, estes irão acompanhar e realizar suporte a todos os projetos associados à INTERESSADA.

O profissional da INTERESSADA que atua no perfil Gerente de Sistemas deve ser inteiramente dedicado a apenas uma Célula de Projeto, exceto quando houver mais de uma Célula para atendimento de uma única Solução de Software.

O desenvolvimento de Soluções de Software contempla sistemas transacionais, integrações, analytics e aplicações Mobile. Os profissionais da INTERESSADA devem dominar as tecnologias para o desenvolvimento, manutenção e sustentação dessas Soluções de Software.

d. Equipe Técnica da MTI

A Equipe Técnica da MTI deve deliberar sobre questões técnicas nas áreas de Configuração e Mudança, Arquitetura de TI, Administração de Dados, Banco de Dados e Infraestrutura de TI, realizando atividades, tais como: mitigar conflitos técnicos, monitorar a adoção das definições técnicas, análise de conformidade e aprovar a adoção de novas tecnologias dentre outras questões técnicas qualitativas.

i.Composição da Equipe Técnica

Cada Equipe Técnica da MTI deve ser composta por profissionais com perfil Analista de Técnico, as atribuições e responsabilidades são descritas no “Anexo VIII- Perfil Profissional”. Este perfil pode ser exercido por funcionários da MTI Analistas de Tecnologia da Informação e/ou Analista Desenvolvedor, ou outro por ela designado.

e. Dinâmica do contrato

A visão geral do processo de trabalho integrado entre a INTERESSADA e a MTI está representada no “Anexo I-A – Visão Geral do Processo de Trabalho”do presente Modelo de Referência de Práticas de Desenvolvimento Ágil para Fábrica de Software com Parceria.

f. Preparação do Ambiente Técnico para Execução do Contrato

No sub processo "Preparar a Execução do Contrato”, apresentado no “Anexo I- A – Visão Geral do Processo de Trabalho” do presente Modelo de Referência de Práticas de Desenvolvimento Ágil para Fábrica de Software com Parceria, deve

ser estabelecido previamente o acordo do trabalho com a INTERESSADA. O estabelecimento do acordo de trabalho deve ser realizado o alinhamento quanto:

● a definição das ferramentas a serem utilizadas no processo de trabalho, atendendo os critérios definidos no “Anexo III - Características das Ferramentas Técnicas e de Gestão”, os artefatos a serem entregues e a forma de entregar as informações;

● modelos de templates a serem utilizados;

● estabelecimento do processo de trabalho, acessos e comunicação com a equipe de infraestrutura de TI da MTI;

● a definição dos requisitos mínimos para aceite e/ou implantação das Soluções de Software em produção;

● prazos para alocação de equipes;

● prazos para validação de entregáveis;

● E outros assuntos relacionados à execução.

g. Emissão e Execução de OS

Para formalizar a solicitação de serviços para a INTERESSADA será utilizado o instrumento Ordem de Serviço (OS). A OS servirá também para o acompanhamento do nível dos serviços prestados.

Este modelo de referência contempla 3 (três) de Ordens de Serviços:

● OS de Construção de Visão do Produto

● OS de Desenvolvimento de Software

● OS de Sustentação

Os serviços, com seus respectivos detalhamentos, passíveis de serem demandados a INTERESSADA estão listados no “Catálogo de Serviços de Solução de Software” , sendo executados mediante abertura de OS.

À critério da MTI, os fluxos de trabalho poderão sofrer melhorias e adaptações. As mudanças deverão ser comunicadas à INTERESSADA com antecedência mínima de 22(vinte e dois) dias úteis do início da adoção do novo fluxo de trabalho.

Para formalizar a Ordem de Serviço para a INTERESSADA, a MTI registrará OS por meio da ferramenta computacional, cuja características estão definidas no “Anexo III - Características das Ferramentas Técnicas e de Gestão” do presente Modelo de Referência de Práticas de Desenvolvimento Ágil para Fábrica de Software com Parceria, ou emissão de OS utilizando modelo padrão da MTI.

Antes do início dos serviços, a INTERESSADA deverá indicar profissional para atuar como Consultor de Projetos para ser o contato da INTERESSADA junto a MTI. Este profissional deve atender aos requisitos descritos no “Anexo VIII- Perfil Profissional” do presente Modelo de Referência de Práticas de Desenvolvimento Ágil para Fábrica de Software com Parceria..

Ao executar os serviços de Desenvolvimento, Manutenção e Sustentação de Solução de Software, a INTERESSADA deve:

● Considerar as tecnologias descritas no “Anexo VII - Ambiente Tecnológico de Solução de Software” do presente Modelo de Referência de Práticas de Desenvolvimento Ágil para Fábrica de Software com Parceria. Novas tecnologias podem ser incorporadas sob definição da MTI considerando a natural evolução tecnológica. Caso a INTERESSADA sugira incorporar novas tecnologias, esta deve submeter à aprovação da Equipe Técnica da MTI. Caso a adoção de uma nova tecnologia seja aprovada, cabe à INTERESSADA realizar o repasse de conhecimento técnico a MTI.

● Prover condições técnica para garantir que todos os artefatos/entregáveis participantes das Soluções de Software operacionalizado entre a MTI e a INTERESSADA, seja este em qualquer ambiente, sejam obrigatoriamente versionados na Nuvem Privada da MTI;

● Conhecer as características e as capacidades da infraestrutura dos ambientes de Homologação e Produção da MTI, possibilitando assim, alinhamento junto a Equipe Técnica da MTI, caso ocorra necessidade de ajustes e refinamentos, com objetivo de atender as necessidades técnicas da Solução de Software a ser desenvolvida ou do sistema a ser mantido;

● Submeter para aprovação da Equipe Técnica da MTI, toda e qualquer inovação tecnológica e ferramentas a serem adotadas pela INTERESSADA, antes do início da execução de uma OS;

● Seguir as definições e acordos estabelecidos na atividade “Preparar a Execução do Contrato”, “Anexo I-A – Visão Geral do Processo de Trabalho”.

● Observar boas práticas e padronizações vigentes relacionadas ao desenvolvimento de software disponíveis no sítio da MTI.

i.Características da OS de “Construção da Visão de Produto”

Somente serviços participantes do “Catálogo de Serviços de Solução de Software” aplicáveis a “OS de Construção da Visão do Produto” podem ser inseridos neste tipo de OS.

O fluxo de trabalho para execução de OS de Construção da Visão do Produto está detalhado no “ANEXO I-B – Construção da Visão do Produto” do presente Modelo de Referência de Práticas de Desenvolvimento Ágil para Fábrica de Software com Parceria.

A OS de Construção de Visão de Produto visa elaborar a visão do produto para subsidiar, inicialmente, o planejamento dos serviços participantes da Solução de Software.

A descrição da visão do produto deve conter as necessidades, expectativas, objetivos específicos de negócio e proposta de solução para o projeto. Conforme o Guia de Projetos Ágeis do SISP5, a Visão do Produto deve ser construída buscando responder às seguintes questões:

▪ Qual problema, oportunidade, benefícios e necessidades que este produto/projeto resolve ou aproveita?

▪ Quais são os objetivos específicos de negócio do produto (Objetivos)?

▪ Quais os clientes e usuários interessados na solução (Atores)?

▪ Como clientes e usuários poderão atingir os objetivos de negócio (Impacto)?

▪ Quais as características-chaves (ou macrofunções) do produto final: quais funcionalidades de negócio, performance, segurança, escalabilidade, precisam ser entregues (Features - Entregáveis)?

▪ Quais os processos de negócio envolvidos nesta solução?

▪ Quais tarefas e atividades do processo de negócio serão automatizadas?

▪ Qual o ciclo de vida das entidades do negócio?

▪ Quais ambientes, padrões, aplicações, terá que suportar?

▪ Escopo e abordagem da Solução?

▪ Quais são os principais riscos e restrições do projeto?

▪ Qual a expectativa de custos e prazos?

▪ Quais premissas devem ser consideradas?

▪ Quais os diferenciais em relação à solução atual ou outra existente?

Para cada OS de Construção de Visão de Produto a INTERESSADA deverá indicar um profissional para atuar como Consultor de Projeto. Esse profissional, com a participação do Líder de Célula e Dono do Produto, será o responsável por realizar reuniões de levantamento e documentação da visão do produto, utilizando técnicas, como as reportadas abaixo, não se restringindo a essas:

▪ Product Vision Box;

▪ Elevator Statement;

▪ Impact Mapping;

▪ Brainstorming;

▪ Mapeamento do Processo de Negócio;

▪ Entrevistas.

A OS de Construção de Visão do Produto será considerada concluída após a aceitação do artefato descrito como entregável no “Catálogo de Serviços de Solução de Software” .

O aceite formal da Visão do Produto deve ser realizado pelo Líder de Célula de Projeto e pelo Dono do Produto.

5 xxxx://xxx.xxxx.xxx.xx/xxxxxxxx/xxxx/xxxxxxxx/xxxx/Xxxx_xx_Xxxxxxxx_%X0%00xxxx

ii.Características da OS do tipo Desenvolvimento de Solução de Software

As OS de Desenvolvimento de Software visam atender demandas de Desenvolvimento de Soluções de Software, Manutenção evolutiva/adaptativas ou corretivas.

A INTERESSADA deve utilizar práticas ágeis referenciando o MD-PDA para execução das OSs de Desenvolvimento de Solução de Software. A INTERESSADA deve realizar o repasse de conhecimento de práticas ágeis ao Líder da Célula e demais participantes da Equipe Técnica da MTI.

Após entendimento do escopo da solução o Consultor de Projetos e Líder de Célula devem classificar se o atendimento da demanda do cliente será realizado por meio de um:

● Projeto – as demandas são classificadas como projeto quando apresentam complexidade, relevância ou prazo justificarem gestão mais complexa e entregas intermediárias. Somente serviços participantes do “Catálogo de Serviços de Solução de Software” classificados como “projeto” podem ser inseridos neste tipo de OS.

● Manutenção – As demandas são classificadas como Manutenção evolutiva/adaptativa quando tratarem de correção, alteração, exclusão ou inclusão de nova funcionalidade em aplicação existente, ou conjunto de funcionalidades que não sejam classificados como projeto pela MTI. Devem ser consideradas/tratadas correções de sistema que não estejam em sustentação por terceiros. Para sistemas em sustentação por terceiros as correções devem ser tratadas com regras específicas do “Catálogo de Serviços de Solução de Software”. Somente serviços participantes do “Catálogo de Serviços de Solução de Software” classificados como “Manutenção” podem ser inseridos neste tipo de OS.

Nas OSs de Desenvolvimento classificada como Projeto e OS de Desenvolvimento classificada como Manutenção, a preparação dos ambientes de Teste, Treinamento e Homologação devem ser realizados pela INTERESSADA na Nuvem Privada da MTI, sendo a ocorrência do contrário somente com autorização expressa da MTI. Caso os ambientes a serem configurados pela INTERESSADA não sejam de domínio da MTI, a INTERESSADA deve realizar o repasse conhecimento técnico e mentoria inerente a preparação destes ambientes para que a MTI prepare o ambiente de produção.

iii.Características da OS do tipo Desenvolvimento de Solução de Software classificada como PROJETO

Somente serviços participantes do “Catálogo de Serviços de Solução de Software” classificados como “Projeto” podem ser inseridos neste tipo de OS.

O fluxo de trabalho para execução de OS do tipo Desenvolvimento de Software classificada como Projeto está detalhado em ANEXO I-C – Executar Projeto de Soluções de Software.

Uma OS do tipo Desenvolvimento de Software classificada como Projeto é aberta a partir da visão do produto. Opcionalmente, a definição da visão do produto, pode ser realizado pela INTERESSADA por meio da abertura de uma OS de Construção de Visão do Produto.

Caso a célula que irá realizar a atividade Planejar Roadmap do Produto, julgue necessário a revisão e a atualização da Visão do Produto decorrente de eventuais mudanças de negócio em função do tempo decorrido entre a construção da Visão do Produto e a abertura da OS do tipo Desenvolvimento de Software, esta atualização deve ser realizada pela INTERESSADA. A atualização da Visão do Produto não será novamente remunerada à INTERESSADA.

O fluxo de trabalho para projeto e que agrega valor ao produto é iterativo. O primeiro planejamento é estabelecimento do Roadmap do produto, a partir da visão do produto. Para cada Release estabelecida no Roadmap do produto é marcado pela elaboração do Backlog do Release e planejamento da Release. Para cada Iteração também é estabelecido o Backlog da Iteração e o seu o planejamento de execução.

A orientação e suporte a adoção das práticas ágeis para estabelecimento de planejamento e dinâmica de trabalho da equipe é de responsabilidade do Gerente de Sistemas, dessa forma as práticas podem variar de acordo com as caraterísticas do projeto e da equipe da Célula de Projeto.

Figura 2 - Modelo de Referência de Projetos de Soluções de Software

O planejamento do Roadmap do Produto, das Releases e das Iterações devem ser entregues ou disponibilizados pela INTERESSADA.

A construção de uma Release é composta por uma ou mais Iterações. A cada Release produzida, executa-se a atividade de Transição, nesta atividade a Release será homologada pelo Dono do Produto e os artefatos técnicos aprovados pela equipe da MTI. Deve ser realizado o aceite formal dos artefatos, conforme previsto no “Catálogo de Serviços de Solução de Software”. O aceite formal dos artefatos que descrevem tecnicamente a Solução de Software deve ser realizado pelo Líder de Célula de Projeto e, o aceito formal do atendimento dos requisitos funcionais da Solução de Software deve ser realizado pelo Dono do Produto.

A OS do tipo Desenvolvimento de Software classificada como Projeto será considerada concluída após a aceitação de todas os entregáveis descritas no “Catálogo de Serviços de Solução de Software” que devem ser disponibilizados pela INTERESSADA.

A remuneração de uma “OS do tipo Desenvolvimento de Software classificada como Projeto” será realizada por Release entregue. A Release entregue representa uma versão homologada pelo cliente mediante acordo contratual.

Ao executar uma “OS do tipo Desenvolvimento de Solução de Software” classificada como “Projeto”, a PARCERIA assume a responsabilidade sobre o

projeto como um todo e suas Releases participantes. Isto significa que todos os artefatos entregues nas Releases anteriores devem ser mantidos, atualizados e versionados em decorrência da evolução do projeto.

A não atualização de determinado artefato afetado pela evolução do projeto em uma Release posterior pode ensejar a não aceitação dos artefatos da Release corrente e, consequentemente, a não autorização de inclusão da Release no faturamento. Por exemplo, se durante o refinamento de requisitos da segunda Release, for identificada nova entidade de negócio, os artefatos versionados e entregues na Release anterior devem ser atualizados para refletir a nova realidade.

Do mesmo modo, a INTERESSADA deve assegurar que o desenvolvimento das Releases posteriores não comprometa o funcionamento das Releases entregues anteriormente. Por exemplo, se a implementação de determinada Release ensejar erro no funcionamento de Release já entregue, a INTERESSADA obriga- se a corrigi-lo antes da conclusão da nova Release.

A INTERESSADA deve acompanhar e realizar suporte ao cliente para a homologação da Solução de Software onde, dentre outras atividades afins, deve esclarecer dúvidas quanto ao uso das funcionalidades desenvolvidas; elaborar scripts para carga de dados de homologação, receber, analisar os erros detectados pelos usuários; reportar o andamento da homologação para a equipe de gestão do contrato da MTI, relacionando problemas encontrados e prazos para correção.

Caso durante a atividade de homologação da Solução de Software o Dono do Produto solicite mudanças de requisitos nas funcionalidades a serem homologadas, estas mudanças devem ser incorporadas no Backlog do Produto e o seu atendimento planejado nas próximas Releases.

O prazo para homologação do software pelo Dono do Produto será acordado previamente no planejamento da Release, onde deve-se também incluir acordo de limite de tempo para o Dono do Produto reportar e registrar o resultado da homologação da Solução de Software a partir da data de sua disponibilização em ambiente de homologação. Após o tempo decorrido a Solução de Software será considerada homologada para efeitos de remuneração.

A responsabilidade de realizar o treinamento dos Gestores da Solução de Software é do Líder da Célula de Projeto. Opcionalmente, a pedido do Líder, este treinamento pode ser realizado pela INTERESSADA. A INTERESSADA tem a responsabilidade de preparar os artefatos que serão usadas no treinamento.

iv.Característica específica da OS do tipo Desenvolvimento de Solução de Software classificada como Manutenção

Somente serviços participantes do “Catálogo de Serviços de Solução de Software” classificados como “Manutenção” podem ser inseridos neste tipo de OS.

As demandas são classificadas como Manutenção evolutiva/adaptativa quando tratarem de correção, alteração, exclusão ou inclusão de nova funcionalidade em aplicação existente, ou conjunto de funcionalidades que não sejam classificados como projeto pela MTI. Devem ser consideradas/tratadas correções de sistema que não estejam em Sustentação por terceiros. Para sistemas em Sustentação por terceiros as correções devem ser tratadas com regras específicas do “Catálogo de Serviços de Solução de Software”.

O fluxo de trabalho para execução de OS do tipo “Desenvolvimento de Solução de Software” classificada como Manutenção está detalhado no “ANEXO I-D – Executar Manutenção de Solução de Software” do presente Modelo de Referência de Práticas de Desenvolvimento Ágil para Fábrica de Software com Parceria.

Para a abertura de OS do tipo Desenvolvimento de Software classificada como Manutenção, o Líder da MTI deve elencar as demandas que serão atendidas na OS. Caso as demandas de Manutenção sejam divididas em mais de uma OS, o Líder da MTI deve distribuir as demandas por OS, agrupando as demandas por funcionalidades afetadas, com o objetivo de todas as alterações serem incorporadas na mesma Release.

Para a OS do tipo “Desenvolvimento de Solução de Software” classificada como Manutenção, o dimensionamento do prazo de atendimento será estabelecido na atividade “Estabelecer Prazo de Entrega”.

Para que a INTERESSADA possa executar uma OS do tipo “Desenvolvimento de Solução de Software” classificada como Manutenção evolutiva/adaptativa para um sistema não desenvolvido por ela própria, é necessário que a MTI promova a realização de repasse técnico de conhecimento para a INTERESSADA. Durante o repasse de conhecimento técnico a MTI deve disponibilizar acesso à INTERESSADA ao código fonte do sistema assim como aos artefatos de referência existentes.

Em se tratando de sistemas desenvolvidos pela própria INTERESSADA, não será necessário realizar repasse de conhecimento técnico e disponibilizar acesso ao código fonte e eventuais artefatos de referência do sistema.

Uma OS de Manutenção evolutiva/adaptativa corresponde, preferencialmente, a uma única Release de entrega, cabendo à INTERESSADA, em conjunto com o Líder da Célula, definir uma Release intermediária em função da prioridade estabelecida, visando o melhor atendimento das necessidades da área de negócio. Porém, mesmo que ocorra a entrega de uma Release intermediária, a OS do tipo “Desenvolvimento de Solução de Software” classificada como Manutenção” somente será paga em parcela única, quando a OS for concluída. A remuneração da OS do tipo “Desenvolvimento de Solução de Software” classificada como Manutenção.

Cabe à INTERESSADA, em conjunto com o Líder da Célula, determinar quando demandas previamente classificadas como Manutenção devem ser tratadas como projeto, e reclassificá-las. Neste caso, a OS do tipo de “Desenvolvimento

de Solução de Software” classificada como Projeto deve seguir o fluxo de trabalho estabelecido “ANEXO I-C – Executar Projeto de Soluções de Software”.

A OS do tipo “Desenvolvimento de Solução de Software” classificada como Manutenção será considerada concluída após a aceitação de todos os entregáveis descritos no “Catálogo de Serviços de Solução de Software” plenamente disponibilizados pela INTERESSADA.

O aceite formal dos artefatos que descrevem tecnicamente a Solução de Software deve ser realizado pelo Líder de Célula de Manutenção e Sustentação e, o aceite formal do atendimento dos requisitos funcionais deve ser realizado pelo Dono do Produto.

A INTERESSADA deve acompanhar e realizar suporte ao cliente para a homologação da Manutenção realizada. Incluem, dentre outras, as ações de esclarecer dúvidas quanto ao uso das funcionalidades desenvolvidas; receber analisar e corrigir os erros detectados pelos usuários; reportar o andamento da homologação para a equipe de gestão do contrato da MTI, relacionando problemas encontrados e cronograma com prazos para correção e disponibilização.

Caso ocorra que durante a atividade de homologação da Release da Solução de Software o Dono do Produto solicite mudanças de requisitos que afete as funcionalidades a serem homologadas, estas mudanças devem ser incorporadas no Backlog do Produto e o seu atendimento planejado nas próximas Releases.

Caso ocorra que durante a atividade de homologação da nova Release entregue pela INTERESSADA o cliente solicite mudanças de requisitos que afete a funcionalidade em homologação, estas mudanças devem ser planejadas para as próximas Releases com a devida incorporação ao Backlog do Produto.

O prazo para homologação da funcionalidade mantida será acordado previamente com o cliente na atividade “Estabelecer Prazo de Entrega”. Será acordado também um limite de tempo para o cliente registrar o resultado da homologação da funcionalidade a partir da data de sua disponibilização em ambiente de homologação, após o tempo decorrido a Manutenção realizada será considerada homologada para efeitos de remuneração.

A responsabilidade de realizar o treinamento dos Gestores da Solução de Software é do Líder da Célula de Manutenção e Sustentação. A pedido do Líder, este treinamento pode ser realizado pela INTERESSADA. Cabe à INTERESSADA preparar os artefatos que serão usados no treinamento.

v.Característica da OS do tipo Sustentação de Solução de Software

O objetivo da OS de Sustentação de sistemas é realizar a Sustentação de determinada solução, visando manter o seu estado normal de operação.

A Sustentação engloba, dentre outras, investigação e tratamento de incidentes relativos à degradação de performance da aplicação ou relativos a erros funcionais.

As características técnicas participantes de uma OS de Sustentação são, não se restringindo a tais:

▪ Investigação de incidentes e diagnóstico de causa-raiz;

▪ Restabelecimento do serviço por meio de solução de contorno;

▪ Manutenção corretiva (tratamento da causa raiz/solução definitiva do problema);

▪ Suporte à operação da aplicação como a preparação de scripts para sanar situações não tratadas pela aplicação, entre outras situações.

Desta forma, a OS de Sustentação compreende o atendimento de demandas tanto classificadas como “Incidente” quanto “Solicitação” conforme serviços estabelecidos no “Catálogo de Serviços de Solução de Software”.

Demandas classificadas como “Incidente” referenciam interrupções não planejadas ou redução da qualidade da Solução de Software sustentada. Já as classificadas como “Solicitações” referem-se as atividades preventivas ou oriundas de levantamento de informações técnicas.

As demandas relacionadas à Sustentação, serão encaminhados para a INTERESSADA através de ferramenta tecnológica com as características definida pela conforme Anexo III - Características das Ferramentas Técnicas e de Gestão, do presente Modelo de Referência de Práticas de Desenvolvimento Ágil para Fábrica de Software com Parceria.

O diagnóstico realizado pela INTERESSADA deverá indicar solução de contorno aplicável, e, quando couber, a medida corretiva necessária. O diagnóstico deverá ser registrado em ferramenta definida pela MTI.

Quando o diagnóstico da demanda apontar necessidade de Manutenção corretiva na aplicação, a INTERESSADA é responsável pela sua execução, observando os níveis de serviço estabelecidos no “Anexo V - Níveis Mínimos de Serviço”, tanto para demandas classificadas como “Incidente” como para demandas classificadas como “Solicitação”.

Por outro lado, quando o diagnóstico da demanda apontar necessidade de intervenção na configuração do ambiente de hardware e software mantido e/ou desenvolvido pela MTI no qual a aplicação se insere, a INTERESSADA deverá indicar que mudanças contextuais provocaram essa necessidade. Neste caso, a área de infraestrutura de TI da MTI analisará os apontamentos da INTERESSADA. Caso esteja de acordo, adotará as medidas cabíveis para corrigir o problema. Caso contrário, o devolverá para outro tratamento por parte da INTERESSADA.

Para os serviços de investigação, sempre que necessário, será utilizado o ferramental de monitoração do ambiente disponível na MTI.

A INTERESSADA poderá sugerir a incorporação de outras ferramentas ao ambiente desde que isto não represente custo adicional para a MTI. Entretanto, a incorporação estará sujeita à aprovação da área de infraestrutura da MTI.

O serviço de investigação engloba a consulta as camadas da arquitetura tecnológica da MTI que suporta as Soluções de Software, onde deve ser disponibilizado LOGs, Relatórios Técnicos dentre outros ativos de subsidiam a investigação. Este processo de investigação e tratamento das demandas deverá ser realizado a partir da Nuvem Privada da MTI.

A MTI disponibilizará mecanismos de acesso controlado a sua Nuvem Privada para possibilitar que os serviços de Sustentação sejam realizados.

Os serviços de Sustentação, quando envolverem necessidade de consulta em bases de dados, esta deverá ser operacionalizada na Nuvem Privada da MTI.

Quando os serviços de Sustentação assim demandarem, em pleno acordo entre a INTERESSADA e a MTI, esta última fornecerá, em periodicidade acordada, visão atualizada de parcela de suas bases de dados após aplicação de inteligência de ocultação e comprometimento inerente termos previamente assinados que acobertam o sigilo.

O acesso restrito e temporário de consulta à base produção para análise, será concedido em situações excepcionais, mediante solicitação devidamente justificada, e somente quando não for possível reproduzir a ocorrência em outras bases de dados. Esse acesso somente poderá ser realizado dentro da Nuvem Privada da MTI, com sua devida supervisão.

Em nenhuma hipótese será concedido acesso de atualização na base de produção a profissionais da INTERESSADA.

Quando for necessária a execução de scripts em ambiente de produção, estes devem ser preparados pela INTERESSADA e encaminhados para avaliação da área técnica especializada da MTI, que, após análise e aprovação, providenciará a execução do mesmo. Os scripts não aprovados serão devolvidos para correção pela INTERESSADA.

Caso materialize as hipóteses previstas que justifiquem a interrupção da Sustentação sob responsabilidade da INTERESSADA, a MTI comunicará com 30 (trinta) dias úteis de antecedência a retirada de determinada Solução de Software do regime de Sustentação pela INTERESSADA. Este mesmo período de antecedência deve ser observado para comunicar à INTERESSADA da entrada de uma Solução de Software sob sua responsabilidade de Sustentação.

A entrada de uma Solução de Software em Sustentação sob responsabilidade da INTERESSADA é formalizada com a emissão de uma OS de Sustentação. A vigência dessa OS estará limitada à vigência da parceria, podendo ser suspensa a critério da MTI a qualquer momento, desde que respeitada à antecedência mínima descrita no item anterior.

Para que a INTERESSADA possa receber uma OS de Sustentação para uma Solução de Software não desenvolvido pela própria INTERESSADA, é

necessário que seja realizado, sob gestão da MTI, repasse de conhecimento técnico.

Em se tratando de Solução de Software desenvolvidos pela própria INTERESSADA, não será necessário o repasse de conhecimento antes do encaminhamento da OS de Sustentação.

A remuneração da Sustentação será realizada mensalmente, calculada com base nos serviços realizados durante o processo de Sustentação, tendo como base suas quantificações em USTs, conforme estabelecido no “Catálogo de Serviços de Solução de Software”.

Mensalmente, a INTERESSADA deverá apresentar à MTI relatório de Sustentação por Solução de Software sustentada, discriminando todas as demandas atendidas e seus respectivos serviços, em ordem cronológica, detalhadas conforme o “Catálogo de Serviços de Solução de Software”.

Adicionalmente, o relatório de Sustentação deverá apresentar o resultado do fator de atendimento do nível de serviço apurado no mês, conforme descrito no “Anexo V - Níveis Mínimos de Serviço” do presente Modelo de Referência de Práticas de Desenvolvimento Ágil para Fábrica de Software com Parceria.

O modelo de Sustentação de Solução de Software apresentado neste documento, além de assegurar a operação em níveis normais de Soluções de Software sustentados, visa, também, estimular a melhoria contínua da qualidade dos mesmos no decorrer da parceria, estabelecendo níveis mínimos de serviço progressivos ao longo do contrato.

O pagamento dos serviços realizados para a Sustentação deve ocorrer somente após o encerramento do atendimento da demanda de Sustentação.

vi.Gerenciamento dos Serviços da OS

A INTERESSADA é responsável pelas entregas conforme as condições acordadas no momento da abertura da OS e no planejamento da Release (escopo, prazo, níveis de serviço, indicadores, dentre outros).

Caso seja uma OS de Desenvolvimento de Soluções de Software classificada como Projeto, a INTERESSADA deve considerar que as atividades gerenciais devem estar aderentes às atividades de gerenciamento projetos da MTI, contemplando gerenciamento de escopo, tempo, comunicação, qualidade, custo e risco.

Para todos os tipos de OS, a INTERESSADA deve fornecer informações a MTI, periodicamente, sobre o andamento das atividades, conforme definições e acordos estabelecidos na atividade “Preparar a Execução do Contrato”, apresentada no “ANEXO I-A – Visão Geral do Processo de Trabalho”do presente Modelo de Referência de Práticas de Desenvolvimento Ágil para Fábrica de Software com Parceria.

vii.Controle de mudanças em OS

Durante a execução dos serviços, poderão ser identificadas necessidades de mudanças nos requisitos da OS, as quais podem afetar o escopo, custo e prazo. Somente o Dono do Produto ou Cliente Demandante poderão solicitar mudanças.

Quaisquer solicitações de mudança relativas a serviços em andamento serão previamente avaliadas quanto à sua pertinência pelo Líder da Célula. Uma vez considerada pertinente pelo Líder da Célula, a solicitação de mudança será encaminhada à INTERESSADA para avaliação do impacto sobre os serviços em execução. Caso as mudanças demandas afetem a Release corrente, esta deve ser inserida no planejamento do Backlog para ser participante da próxima versão da Solução de Software após a versão inerente a Release corrente. Somente em comum acordo entre a INTERESSADA e a MTI, a Release corrente, objeto de impacto direto da mudança solicitada, pode ser abandonada com justificativa registrada na OS, com objetivo único de minimizar perdas de ambos os lados da parceria.

A avaliação de impacto deverá ser registrada em relatório técnico, no qual deve- se destacar as alterações de custo e prazo na OS, acompanhadas das devidas justificativas.

Apenas as mudanças que forem aprovadas pelo Líder da Xxxxxx, após análise do relatório de impacto, devem ser realizadas pela INTERESSADA.

viii.Cancelamento de OS

Somente o Dono do Produto ou o Cliente Demandante podem solicitar cancelamento da execução de OS. As Releases efetivamente finalizadas pela INTERESSADA até o momento do cancelamento serão devidamente entregues para processo de homologação e, após homologadas, remuneradas. A Release corrente da OS será finalizada e remunerada com a justificativa funcional registrada pelo dono do produto.

ix.Método de quantificação dos volumes de serviços

A métrica utilizada é Unidade de Serviço Técnico (UST).

Os serviços, metrificados em UST, disponíveis para serem participantes de uma OS estão reportados na versão atualizada “Catálogo de Serviços de Solução de Software” disponibilizado no sítio da MTI.

Para as OS do tipo “Sustentação ” que possuem demandas classificada como “Incidente” ou “Solicitação”, o atendimento ocorre na demanda. Cada uma das demandas pode ser atendida por uma composição de serviços, observando a classificação prevista no “Catálogo de Serviços de Solução de Software”.

x.Boas práticas relativas à segurança da informação durante o ciclo de desenvolvimento e sustentação

A INTERESSADA, na execução dos serviços contratados, deverá observar boas práticas relativas à segurança da informação, especialmente as indicadas nas normativas da MTI em todas as atividades executadas durante o ciclo laboram das Soluções de Software, considerando práticas referenciadas no Estado da Arte. No subprocesso “Preparar a Execução do Contrato” apresentado no “Anexo I – Processo de Trabalho” do presente Modelo de Referência de Práticas de Desenvolvimento Ágil para Fábrica de Software com Parceria, será apresentado as normativas vigentes.

Quando da validação dos artefatos/entregáveis disponibilizados pela INTERESSADA, a MTI fará verificação quanto aos requisitos de qualidade, incluindo os aspectos de segurança da informação previstos em normativas internas, legislação estadual e federal. A verificação quanto aos aspectos de segurança da informação, pode incluir avaliação técnica especializada da Solução de Software sob prerrogativa decisória da MTI.

4. COMUNICAÇÃO ENTRE MTI E INTERESSADA

A presente contratação prevê a realização de reuniões ordinárias entre a MTI e a INTERESSADA, para acompanhamento dos serviços e planejamento de ações futuras. Essas reuniões serão realizadas em intervalos não inferiores a 15 (quinze) dias, conforme periodicidade a ser definida entre as partes, na abertura da OS. A pauta de cada reunião ordinária será definida por esse profissional e comunicada com antecedência mínima de 24 (vinte e quatro) horas à INTERESSADA.

A parceria prevê ainda a realização de reuniões extraordinárias entre a MTI e a INTERESSADA, as quais, diferente das reuniões ordinárias, poderão ocorrer a qualquer tempo, sem periodicidade preestabelecida, desde que convocadas com antecedência mínima de 24 (vinte e quatro) horas. Poderá ser pauta das reuniões extraordinárias qualquer tema que, por especialização técnica ou pela urgência no tratamento do tema, não possa aguardar ser incluído na pauta das reuniões ordinárias.

Participarão das reuniões ordinárias e extraordinárias o fiscal técnico ou gestor do contrato, o gerente de contrato da INTERESSADA, o preposto e outros atores que a MTI e a INTERESSADA julgarem importantes para tratar devidamente as questões previstas na pauta.

Nas reuniões de acompanhamento os seguintes pontos serão tratados, entre outros:

a. Avaliação dos indicadores de nível de serviço aferidos no período e ações corretivas, caso necessário;

b. Avaliação da efetividade de medidas corretivas definidas em reuniões anteriores;

c. Planejamento estimativo de volume de demandas para os próximos períodos;

d. Acompanhamento do andamento dos projetos em curso com análise de riscos;

e. Comunicação prévia da intenção de inclusão ou e retirada de Soluções de Software da Sustentação.

Compete ao gerente de contrato da INTERESSADA apresentar sugestões de medidas corretivas, sempre que necessário ao estabelecimento ou restabelecimento de níveis de serviço previsto no contrato. As propostas apresentadas serão discutidas e avaliadas pela MTI.

Ao término da reunião, a MTI elaborará ata específica com o registro dos principais assuntos tratados, as decisões tomadas e as notificações realizadas. A ata deve ser assinada pelos presentes e devidamente arquivada.

A MTI pode utilizar-se de outros mecanismos formais de comunicação com a INTERESSADA. Esses também devem ser juntados ao processo de fiscalização, para subsidiar a gestão do contrato.

5. GARANTIA DOS SERVIÇOS

Os serviços de Desenvolvimento e Manutenção de Soluções de Software previstos terão com garantia de 180 (cento e oitenta) dias contados da emissão do respectivo termo de recebimento definitivo.

Caso seja detectado erro em produção, do produto elaborado pela INTERESSADA e ainda em garantia, cabe a esta corrigir nos mesmos prazos definidos para o restabelecimento do serviço de demandas do tipo “incidente” prevista para OS de Sustentação, independentemente da Solução de Software encontrar-se em regime de Sustentação.

No caso de erro detectado nos últimos 60 (sessenta) dias da garantia, essa será prorrogada, de modo que o novo término da garantia do sistema se dê 60 (sessenta) dias após a implantação da correção do erro em produção.

É facultado à MTI, em situações excepcionais ou emergenciais, realizar intervenções em código produzido ou mantido sob gestão da MTI ou de unidade do Setor Público. Nestes casos, somente os arquivos fontes alterados perderão a garantia.

A abertura de OS de Manutenção para que a INTERESSADA realize de forma definitiva as alterações executadas em caráter excepcional pela MTI, restabelece a garantia dos arquivos fontes alterados ou impactados por novos 180(cento e oitenta) dias.

6. NÍVEIS MÍNIMOS DE SERVIÇO

A presente contratação possui mecanismos que possibilitam à MTI remunerar o fornecedor na medida do cumprimento dos níveis de serviço, de forma a assegurar que os pagamentos sejam vinculados aos resultados entregues.

Para cada entrega participante da OS, será calculado o fator de cumprimento do nível de serviço. O “Anexo V - Níveis Mínimos de Serviço” do presente Modelo de Referência de Práticas de Desenvolvimento Ágil para Fábrica de Software com Parceria, apresenta os indicadores mínimos de nível de serviço a serem observados para cada entrega de produto participante da OS. Indicadores acima dos mínimos estabelecidos pode ser pactuado em função de comprovação técnica atestada e apresentada pela INTERESSADA

O alcance do nível mínimo de serviço estabelecido na PARCERIA terá fator de cumprimento estabelecido no “Anexo V - Níveis Mínimos de Serviço”. Caso não seja atingido, serão aplicadas glosas, também definidas no mesmo anexo.

a. Cálculo da remuneração esperada por OS

Cálculo para OS de “Criação de Construção de Visão do Produto” e OS “Desenvolvimento de Software” classificada como “Projeto”: Será calculado somente após a conclusão da OS, e deve ser realizada soma das UST de cada serviço entregues na OS, conforme estabelecido no “Catálogo de Serviços de Solução de Software”.

Cálculo para OS de “Desenvolvimento de Software” classificada como “Projeto”: Será calculado após a entrega de cada release e deve ser realizada soma das UST de cada serviço entregues na release, conforme o “Catálogo de Serviços de Solução de Software”.

Cálculo para OS de “Sustentação”: Será calculado após o fechamento de cada Demanda da solução sustentada e deve ser realizada soma das UST de cada serviço realizado para o atendimento da Demanda, conforme o “Catálogo de Serviços de Solução de Software”.

Para os casos de cancelamento de OS, será considerado a soma das UST(s) dos serviços concluídos, conforme estabelecido no “Catálogo de Serviços de Solução de Software”.

b. Cálculo do valor final da OS, após aplicação do fator de atendimento do nível de serviço

Cada OS ou parcela remunerável de OS concluída, deve ser relacionada no relatório mensal de faturamento, acompanhada dos indicadores relativos ao nível de serviço observado durante a execução dos serviços.

Para cada OS, com base nos indicadores de nível de serviço observados, será calculado o fator de cumprimento do nível de serviço, conforme especificado no “Anexo V - Níveis Mínimos de Serviço” do presente Modelo de Referência de Práticas de Desenvolvimento Ágil para Fábrica de Software com Parceria. O valor final a ser pago pela OS será multiplicado pelo fator de cumprimento do nível de serviço.

c. Fluxo de Pagamento Mensal

O pagamento à INTERESSADA será mensal:

● Para a OS do tipo “Desenvolvimento de Software” e classificada como “Projeto” o pagamento terá por base a OS ou Releases concluídos;

● Para a OS do tipo “Desenvolvimento de Solução de Software” e classificada como “Manutenção” o pagamento terá por base a OS concluída;

● Para a OS do tipo “Sustentação” o pagamento terá por base os serviços realizados, conforme estabelecido no “Catálogo de Serviços de Solução de Software”.

Os pagamentos mensais serão realizados após recebimento definitivo dentro do período de aferição. O período de aferição corresponde ao intervalo entre o 1º e o último dia do mês.

Mensalmente, em no máximo cinco dias úteis a contar do encerramento do período de aferição, a INTERESSADA deverá apresentar o Relatório de Fechamento, relacionando a OS ou parcela remunerável da OS, com termo de recebimento definitivo no período de aferição. Para cada OS ou parcela, deverão ser indicados os níveis de serviço aferidos e os valores de remuneração calculados conforme previsto no contrato.

A MTI tem prazo de 05 (cinco dias) úteis, contados do recebimento, para analisar e aprovar o relatório de fechamento entregue pela INTERESSADA, bem como verificar o nível de serviço alcançado na execução da (s) OS(s).

No caso de divergência nos valores apresentados no relatório, a MTI juntamente com o Cliente discutirá com a INTERESSADA as correções necessárias e solicitará emissão de novo relatório de fechamento. A cada reapresentação do relatório, a MTI terá novo prazo de cinco dias úteis para analisá-lo.

A nota fiscal/fatura deverá ser emitida após aprovação do relatório de fechamento mensal por parte da MTI e deverá conter apenas os serviços efetivamente concluídos e recebidos definitivamente pela mesma. O ateste da nota fiscal/fatura, para efeito de pagamento somente será feito após confrontação dos dados constantes da nota fiscal/fatura com os do referido relatório.

As condições referentes à liquidação e ao pagamento estão descritas em cláusula contratual específica.

7. PERFIS PROFISSIONAIS E QUALIFICAÇÃO MÍNIMA

Para a execução das atividades-chave previstas no contrato, a INTERESSADA deverá designar profissionais de acordo com os perfis e qualificações especificados no documento denominado “Anexo VIII- Perfil Profissional” do

presente Modelo de Referência de Práticas de Desenvolvimento Ágil para Fábrica de Software com Parceria. disponibilizado no sítio da MTI.

A designação destes profissionais deve ocorrer no momento da formação ou ampliação das células, ou ainda na substituição de profissionais.

Por seguir orientação majoritariamente de práticas ágeis, esta modelo de referência não transforma funções do desenvolvimento de solução de software em cargos. Um colaborador pode acumular diversos papéis. Nesse caso, deve apresentar comprovação técnica para os papéis que atuará. Quando o perfil é subdividido em grupos, pode-se adotar um ou outro. O que difere um grupo de outro é a comprovação relacionada ao conhecimento técnico e tempo de experiência laboral.

a. Ferramentas necessárias exigidas da INTERESSADA

As ferramentas necessárias tanto para o apoio ao desenvolvimento como para a gestão do processo, são descritas no “Anexo III - Características das Ferramentas Técnicas e de Gestão” do presente Modelo de Referência de Práticas de Desenvolvimento Ágil para Fábrica de Software com Parceria.

8. TRANSFERÊNCIA DE CONHECIMENTO E TRANSIÇÃO CONTRATUAL

A título de repasse de conhecimentos acerca dos serviços executados, a INTERESSADA deve, ao término de cada OS, repassar todos os documentos produzidos e gerados no contexto da sua execução, incluindo códigos-fonte, documentação de programas, diagramas e especificações, devidamente atualizados de acordo com os serviços executados na OS.

A INTERESSADA também deve, conforme previsto no fluxo de trabalho, discutir previamente com a equipe técnica da MTI, qualquer nova solução arquitetural que venha a ser adotada nos serviços desenvolvidos.

Quando solicitado pela MTI, a INTERESSADA deve fornecer esclarecimentos complementares acerca das soluções desenvolvidas, com a participação dos profissionais envolvidos na definição e desenvolvimento da solução.

A INTERESSADA deve promover transição contratual e repassar para o MTI e/ou para outra empresa por este indicada todos os dados, documentos e elementos de informação utilizados na execução dos serviços.

Com vistas a mitigar riscos de descontinuidade de serviços e de dependência técnica, a INTERESSADA deve habilitar equipe de técnicos da MTI ou outra por ele indicada no uso das soluções desenvolvidas e implantadas no escopo do contrato, repassando todo o conhecimento necessário para tal.

A critério da MTI, poderá ser alocado servidor para acompanhar as atividades de levantamento de requisitos realizadas pela INTERESSADA, tendo em vista a

preservação do conhecimento do negócio relativo à aplicação que está sendo desenvolvida.

9. Instrumentos de Solicitação, Acompanhamento e Avaliação dos Serviços

Será utilizado o instrumento de OS Ordem de serviço, como ferramenta de demanda à INTERESSADA. No “Anexo IV - Modelos de Ordem de Serviço” do presente Modelo de Referência de Práticas de Desenvolvimento Ágil para Fábrica de Software com Parceria são apresentados modelos com as informações mínimas que devem compor esse documento de formalização, podendo ser acordados novos modelos entre a MTI e a INTERESSADA.

Conforme detalhado anteriormente, no presente modelo estão previstos três tipos de OS. Cada tipo de OS possui fluxo de trabalho próprio, detalhados no Anexo I - Processo de Trabalho, do presente Modelo de Referência de Práticas de Desenvolvimento Ágil para Fábrica de Software com Parceria.

Toda entrega realizada pela INTERESSADA no contexto da execução de uma OS será entregue a MTI que o receberá provisoriamente e submeterá a avaliação conforme requisitos de qualidade técnica definidos no início da execução da parceria conforme subprocesso “Preparar a execução do contrato” apresentado no “Anexo I - Processo de Trabalho”. Também deve ser definido os prazos para esta verificação de qualidade.

O resultado da avaliação deve ser disponibilizado para a INTERESSADA por meio de Laudo Técnico. No laudo serão registrados defeitos encontrados, rejeites, aceites com ressalvas e aceites.

A ocorrência de defeitos que comprometam o entendimento de artefato/entregável implicará rejeite do mesmo. Todo rejeite de artefato/entregável será contabilizado para fins de determinação do nível de serviço observado na execução da OS.

A critério da MTI, a ocorrência de defeitos pontuais que não comprometam o entendimento do artefato/entregável pode ensejar o aceite com ressalvas. Nesse caso, a INTERESSADA deverá sanar os defeitos registrados e reapresentar o artefato/entregável à MTI.

Artefatos/entregáveis sem identificação de defeitos serão considerados aceitos, ou seja, artefatos/entregáveis com aceite com ressalvas não corrigidos no prazo acordado ou reapresentados sem que todos os defeitos tenham sido corrigidos, serão considerados rejeitados.

Em caso de rejeite de artefato/entregável, a INTERESSADA deverá fazer as correções cabíveis e reapresentar novamente provisoriamente.

O tempo consumido com correção de artefatos/entregáveis rejeitados deve compor o tempo total de execução dos serviços para fins de aferição do prazo de execução da OS. O tempo consumido nas avaliações das entregas pela MTI não deve ser computado para fins de aferição do nível de serviço.

Aceitos todas as entregas realizadas, e ainda, quando aplicável, após a conclusão da homologação, sem que restem defeitos sem correção, a entrega será considerada de definitiva.

Os instrumentos de solicitação, acompanhamento e avaliação dos serviços previstos nesta seção devem presencialmente serem realizado por meio de ferramenta de gestão, conforme previsto no “Anexo III - Características das Ferramentas Técnicas e de Gestão”.

ANEXO I DO MODELO DE REFERÊNCIA DE PRÁTICAS DE DESENVOLVIMENTO ÁGIL PARA FÁBRICA DE SOFTWARE COM PARCERIA

Processo de Trabalho

ANEXO I-A – Visão Geral do Processo de Trabalho

ANEXO I-B – Construção da Visão do Produto

ANEXO I-C – Executar Projeto de Soluções de Software

ANEXO I-D – Executar Manutenção de Solução de Software

ANEXO I-E – Realizar Sustentação de Solução de Software

ANEXO II - DO MODELO DE REFERÊNCIA DE PRÁTICAS DE DESENVOLVIMENTO ÁGIL PARA FÁBRICA DE SOFTWARE COM PARCERIA

Modelo de Operação da Fábrica de Software

ANEXO III DO MODELO DE REFERÊNCIA DE PRÁTICAS DE DESENVOLVIMENTO ÁGIL PARA FÁBRICA DE SOFTWARE COM PARCERIA

Características das Ferramentas Técnicas e de Gestão

No processo de trabalho com a Fábrica de Software a MTI e a INTERESSADA devem contar com o uso de várias ferramentas de apoio de comunicação entre as partes, suporte ao desenvolvimento, tais como:

● Gestão de projetos e tarefas

● Central de atendimento

● Gestão de OS

No subprocesso "Preparar a Execução do Contrato”, apresentado no “Anexo I-A

– Visão Geral do Processo de Trabalho”, a INTERESSADA deve apresentar as ferramentas necessárias, cabe a Equipe Técnica da MTI avaliar e definir sobre a adoção das ferramentas propostas. As características das ferramentas que previstas no processo de trabalho são especificadas a seguir.

1. Ferramenta de Gestão

A INTERESSADA deverá apresentar ferramenta integrada de gestão que permita o acompanhamento de todo o ciclo de demandas, ordens de serviços, acordos de nível de serviço, abrangendo todo o processo descrito no “Modelo de Referência de Práticas de Desenvolvimento Ágil para Fábrica de Software com Parceria”.

A Equipe Técnica da MTI deve validar a ferramenta apresentada e caso necessário será acordado a melhoria ou definição de nova ferramenta.

2. Ferramenta para Testes Automatizados

A INTERESSADA deverá prover para uso dentro das Célula de Projeto e Célula de Manutenção e Sustentação, ferramenta de automação de testes. A ferramenta disponibilizada pela INTERESSADA será submetida à avaliação da Equipe Técnica da MTI e deverá possuir, no mínimo, as seguintes características:

a. Capacidade de repetir a execução do teste com massa de dados diferente a cada execução;

b. Capacidade de executar o teste em browsers diversos;

c. Capacidade de gerar automaticamente relatórios de execução;

d. Permitir execução automática dos testes através de Ferramentas de Integração Contínua.

3. Ferramentas para as atividades do desenvolvimento

A INTERESSADA deve disponibilizar licenças de ferramentas necessária para os processos de desenvolvimento, manutenção e sustentação das soluções, para atividades tais como prototipação, construção e manutenção da documentação online, codificação e outras atividades inerentes ao processo.

As quantidades de licenças deverão atender às demandas necessárias para as Célula de Projeto e Célula de Manutenção e Sustentação.

Caso a MTI decida adotar a mesma ferramenta utilizada pela INTERESSADA, a INTERESSADA deve fazer o repasse de conhecimento a membros da Equipe Técnica da MTI.

ANEXO IV DO MODELO DE REFERÊNCIA DE PRÁTICAS DE DESENVOLVIMENTO ÁGIL PARA FÁBRICA DE SOFTWARE COM PARCERIA

Ordem de Serviço

ANEXO IV-A – OS Construção de Visão do Produto

Contrato:

Número do Contrato

Número da Ordem de Serviço:

Número da OS

Data de Abertura:

dd/mm/aaaa

OS Construção de Visão do Produto

1. DESCRIÇÃO RESUMIDA DOS SERVIÇOS (anexar especificações necessárias, conforme detalhado no processo de trabalho)

Insira a descrição do serviço a ser realizado.

2. SERVIÇOS DEMANDADOS

I. Insira a descrição do serviço a ser realizado. II.

III. IV.

V.

3. CUSTO ESTIMADO (anexar relatório de contagem indicativa ou estimativa)
(A) Volume Estimado (UST):	0
(B) Preço Unitário (R$):	0,00
(C) Custo Estimado (R$) (AxB):	0,00

4. RESPONSÁVEIS PELA ABERTURA DA OS
Responsável	Matrícula	Assinatura
Representante da MTI: Nome do Representante da MTI	Matrícula

Requisitante do Serviço: Nome do Fiscal Requisitante do Serviço	Matrícula
Responsável Técnico pela Demanda: Nome do Responsável Técnico pela Demanda (Gestor/Dono do Produto)	Matrícula

5. CIENTE DO RESPONSÁVEL PELOS SERVIÇOS
Preposto da Contratada	Data	Assinatura
Nome do Preposto da Contratada	dd/mm/aa aa

6. OBSERVAÇÕES

Descreva as observações, caso existam. Caso contrário, escreva "Não se aplica.".

ANEXO IV – Ordem de Serviço

ANEXO IV-B – OS Desenvolvimento de Software

Contrato:

Número do Contrato

Número da Ordem de Serviço:

Número da OS

Data de Abertura:

dd/mm/aaaa

OS Desenvolvimento de Software

☐ Manutenção

☐ Projeto

1. CLASSIFICAÇÃO DA ORDEM DE SERVIÇO

Insira a descrição do serviço a ser realizado.

2. DESCRIÇÃO RESUMIDA DOS SERVIÇOS (anexar especificações necessárias, conforme detalhado no processo de trabalho)

Insira a descrição do serviço a ser realizado.

I.

II. III. IV.

V.

3. SERVIÇOS DEMANDADOS

4. CUSTO ESTIMADO (anexar relatório de contagem indicativa ou estimativa)

(A) Volume Estimado (UST):	0
(B) Tecnologia:
(C) Preço Unitário (R$):	0,00
(D) Custo Estimado (R$) (AxC):	0,00

5. RESPONSÁVEIS PELA ABERTURA DA OS
Responsável	Matrícula	Assinatura
Representante da MTI: Nome do Representante da MTI	Matrícula
Requisitante do Serviço: Nome do Fiscal Requisitante do Serviço	Matrícula
Responsável Técnico pela Demanda: Nome do Responsável Técnico pela Demanda (Gestor/Usuário)	Matrícula

6. CIENTE DO RESPONSÁVEL PELOS SERVIÇOS
Preposto da Contratada	Data	Assinatura
Nome do Preposto da Contratada	dd/mm/aaaa

7. OBSERVAÇÕES

Descreva as observações, caso existam. Caso contrário, escreva "Não se aplica.".

ANEXO IV DO MODELO DE REFERÊNCIA DE PRÁTICAS DE DESENVOLVIMENTO ÁGIL PARA FÁBRICA DE SOFTWARE COM PARCERIA

Ordem de Serviço

ANEXO IV-C – OS de Sustentação

Contrato:

Número do Contrato

Número da Ordem de Serviço:

Número da OS

Data de Abertura:

dd/mm/aaaa

OS de Sustentação

1. DESCRIÇÃO RESUMIDA DA SOLUÇÃO A SER SUSTENTADA (anexar especificações da solução)

Insira a descrição do serviço a ser realizado.

2. CUSTO ESTIMADO (anexar relatório de contagem indicativa ou estimativa)
(A) Volume Estimado (UST):	0
(B) Tecnologia:
(C) Preço Unitário (R$):	0,00
(D) Custo Estimado (R$) (AxC):	0,00

3. RESPONSÁVEIS PELA ABERTURA DA OS
Responsável	Matrícula	Assinatura
Representante da MTI: Nome do Representante da MTI	Matrícula
Requisitante do Serviço: Nome do Fiscal Requisitante do Serviço	Matrícula
Responsável Técnico pela Demanda: Nome do Responsável Técnico pela Demanda (Gestor/Usuário)	Matrícula

4. CIENTE DO RESPONSÁVEL PELOS SERVIÇOS
Preposto da Contratada	Data	Assinatura
Nome do Preposto da Contratada	dd/mm/aa aa

5. OBSERVAÇÕES

Descreva as observações, caso existam. Caso contrário, escreva "Não se aplica.".

ANEXO V DO MODELO DE REFERÊNCIA DE PRÁTICAS DE DESENVOLVIMENTO ÁGIL PARA FÁBRICA DE SOFTWARE COM PARCERIA

NÍVEIS MÍNIMOS DE SERVIÇO

Indicador

Incide sobre

Xxxxx Xxxxxx de Serviço

Fórmula para determinação do impacto por não cumprimento do NMS

Impacto por não Cumprimento

Nível

Faixa

Impacto

Tempestivida de do Planejament o da OS

Valor da OS

Conforme prazos máximos comprometido no planejamento da(s) release(s) da OS

Dias úteis de atraso na entrega do planejamento das releases da OS

1

NA

0,5% dia atraso

por de

Tempestivida de da entrega da release

Valor Release

da

Conforme cronograma aprovado para OS

a

Dias úteis de atraso em relação ao previsto para a release

1

NA

0,1% dia atraso

por de

Qualidade da release

Valor Release, da OS, entrega única

da ou se

No máximo 1 rejeite por artefato

Número de rejeites da release

1

2 rejeites

0,5%

2

a partir do 3º rejeite

1% para cada rejeite a partir do 3º

Qualidade geral dos serviços da OS

Valor da OS

No máximo 50% da OS se entrega com algum rejeite

Número de funções da OS com algum rejeite

1

NA

2% para cada release com rejeite além de 50%

Qualidade do Produto Final

Valor da OS

No máximo 02(dois) defeitos em homologação a cada Release entregue

𝐼𝑛𝑑 = 𝑁𝑢𝑚 / 𝑁𝑢𝑚releases

1

𝐼𝑛𝑑def > 2

2(inddef∗10) ∗ 0,5%

NÍVEIS MÍNIMOS DE SERVIÇO ESPECÍFICOS PARA OS DO TIPO SUSTENTAÇÃO

Tabela I – Níveis mínimos de serviço para OS de Desenvolvimento e Manutenção de Soluções de Software

Indicador	Incide sobre	Xxxxx Xxxxxx de Serviço	Fórmula para determinação do impacto por não cumprimento do NMS	Impacto por não Cumprimento
				Faixa	%
Tempestiv idade no tratament o de Incidentes	Valor da OS de sustentaç ão classifica da como “incident e” no mês	Incidentes com restabelecimento do serviço no prazo conforme tabela de prioridade do incidente. do 1º ao 6º mês: >= 60% do 6º ao 12º mês: >= 70% do 12º ao 18º mês: >= 80% a partir do 19º mês: >= 90%	Número de demandas classificadas como “incidente” com restabelecimento do nível de serviço fora do prazo, agrupados pela prioridade do incidente.	Baixa	0,5% glosa por atraso
				Média	2% glosa por atraso
				Alta	4% glosa por atraso
				Máxima	6% glosa por atraso
Efetividad e do Tratament o de Incidentes	Valor da OS de sustentaç ão classifica da como “incident e” no mês	Incidente recorrente por falha no restabelecimento do serviço. do 1º ao 6º mês:>= 80% do 6º ao 12º mês: >= 90% a partir do 12º mês: >= 95%	Número de demandas classificadas como “incidente” com reabertura por falha no restabelecimento do serviço, agrupados pela prioridade do incidente.	Baixa	0,5% glosa por atraso
				Média	2% glosa por atraso
				Alta	4% glosa por atraso
				Máxima	6% glosa por atraso
Tempestiv idade na realização de serviços de sustentaç ão	Valor da OS de sustentaç ão classifica da como “solicitaç ão” no mês	Demandas encerradas no prazo conforme tabela de prioridade da solicitação. do 1º ao 6º mês: >= 60% do 6º ao 12º mês: >= 70% do 12º ao 18º mês: >= 80% a partir do 19º mês: >= 90%	Número de demandas classificadas como “solicitações” atendidas fora do prazo, agrupados pela prioridade da solicitação.	Baixa	0,1% glosa por atraso
				Média	0,5% glosa por atraso
				Alta	2% glosa por atraso
				Máxima	4% glosa por atraso

Tabela II – Níveis mínimos de serviço para OS de Sustentação

ANEXO VI DO MODELO DE REFERÊNCIA DE PRÁTICAS DE DESENVOLVIMENTO ÁGIL PARA FÁBRICA DE SOFTWARE COM PARCERIA

REGRAS DE CLASSIFICAÇÃO DE DEMANDAS E SERVIÇOS DE SUSTENTAÇÃO

A sustentação envolve duas classificações: Primeiramente a demanda é classificada por prioridade, que envolve aspectos de impacto e urgência.

A segunda classificação é a complexidade que é aplicada aos serviços utilizados para o atendimento da demanda.

1. Classificação da Prioridade:

A prioridade identifica a importância relativa da demanda e é utilizada para identificar o tempo necessário para que as ações de tratamento sejam realizadas pelas equipes responsáveis. Para determinar a prioridade, deve-se avaliar o impacto que a demanda causa e a sua urgência.

O impacto é uma medida do efeito da demanda no negócio. Ele normalmente baseia-se em como os níveis de serviços serão afetados. Vários fatores podem contribuir para a definição do nível de impacto, tais como número de usuários afetados e serviços envolvidos. Já a urgência é a medida do tempo em que uma demanda gerará impacto significativo no negócio, ou seja, o quão rápido o negócio precisa de uma resolução.

Assim, a prioridade define o nível de resposta que a demanda terá e não a criticidade da situação ou o seu escopo.

a) Prioridades das demandas classificadas como ”Incidente”:

Pontuação	Prioridade	Tempo Máximo6 para Reestabelecimento do Serviço
12 pontos	1 – Máxima	4 horas úteis
10 - 11 pontos	2 - Alta	8 horas úteis
7 - 9 pontos	3 - Média	2 dias úteis
3 - 6 pontos	4 - Baixa	4 dias úteis

Tabela I - Prioridades classificada como “Incidente”

a) Prioridade das demandas classificadas como da “Solicitação”:

Pontuação	Prioridade	Tempo Máximo7 para atendimento
12 pontos	1 – Máxima	8 horas úteis
10 - 11 pontos	2 - Alta	2 dia útil
7 - 9 pontos	3 - Média	4 dias úteis
3 - 6 pontos	4 - Baixa	6 dias úteis

Tabela II - Prioridades classificada como “Solicitação”

b) Procedimento para determinar a prioridade da demanda:

A prioridade da demanda é determinada pela pontuação obtida após avaliação do seu impacto e da sua urgência. Para a análise do impacto, são utilizados dois fatores: usuários afetados e serviços envolvidos.

• O fator de impacto “usuários afetados” avalia o número de usuários afetados ou se é um usuário que possui atendimento especial.

• O fator de impacto “serviços envolvidos” avalia a criticidade do serviço para o negócio.

Para determinar a prioridade da demanda, deve-se realizar os passos a seguir.

1. Avaliar o fator de impacto usuários afetados (tabela III) e obter uma pontuação.

2.Avaliar o fator de impacto serviços envolvidos (tabela IV) e obter uma pontuação.

3. Avaliar a urgência (tabela V) e obter uma pontuação. 4.Somar as três pontuações.

5.A pontuação total determina a prioridade da demanda definida na tabela I.

	4 pontos	3 pontos	2 pontos	1 ponto
Impacto	- Governador - Secretário - Presidente	- Duas ou mais unidades de negocio	- Mais de um usuário até uma	- Único usuário

	- Todos os usuários do sistema -Cidadão		unidade de negocio
Fator “Usuários afetados”

Tabela III – Analise do Impacto - Fator Usuários Afetados

	4 pontos	3 pontos	2 pontos	1 ponto
Impacto	-Serviços relacionados ao atendimento do cidadão (balcão ou online)	-Serviços de áreas finalísticos	-Serviços de áreas administrativas	-Sistemas em obsolescência
Fator
“Serviços envolvidos”	-Serviços de arrecadação

Tabela IV – Analise do Impacto - Fator “ Serviços Envolvidos”

4 pontos 3 pontos 2 pontos 1 ponto

	Demanda classificada como “Incidente”:	Demanda classificada como “Incidente”:	Demanda classificada como “Incidente”:	Demanda classificada como “Incidente”:
Urgência	A atividade impactada por esse incidente não pode ser interrompida e é preciso uma ação imediata para resolver o problema.	A atividade impactada por esse incidente precisa ser realizada em breve.	A atividade impactada por esse incidente precisa ser realizada no futuro ou pode ser reprogramada.	A atividade impactada por esse incidente pode continuar sem perdas significativas.
	Demanda Classificada como “Solicitação”:	Demanda Classificada como “Solicitação”:	Demanda Classificada como “Solicitação”:	Demanda Classificada como “Solicitação”:
	- Solicitações relacionadas à segurança da informação;	- Consultas em banco de dados	Solicitações relacionadas à atividades preventivas.	Atividade de rotina.

Tabela V – Urgência

2. Classificação da Complexidade:

Os serviços utilizados para atendimento das demandas são classificados por complexidade Baixa, Média e Alta.

Os serviços de “Apoio à Gestão” e “Apoio ao desenvolvimento” não possuem diferenciação de complexidade, sendo considerada sempre média.

Os serviços de “Desenvolvimento”, que são executados por funcionalidade, devem ter a sua complexidade classificada utilizando a métrica “Análise de pontos de função” por meio do “Manual de Práticas de Contagem de Pontos de Função do IFPUG”.

Para isso serão consideradas as funções de “transação”: Entrada Externa(EE), Consulta Externa(CE) e Saída Externa(SE).

Somente será utilizado para efeito de classificação de complexidade da função.

ANEXO VII DO MODELO DE REFERÊNCIA DE PRÁTICAS DE DESENVOLVIMENTO ÁGIL PARA FÁBRICA DE SOFTWARE COM PARCERIA

ANEXO VII - AMBIENTE TECNOLÓGICO de SOLUÇÃO de SOFTWARE

LINGUAGEM e FRAMEWORK de DESENVOLVIMENTO e MANUTENÇÃO de SOLUÇÃO de SOFTWARE

NOME	VERSÃO
JAVA
PHP
C/C++
PYTHON
XXXXX
AngularJS
NodeJS
JavaScript JSON
React Native
Ionic
.Net C#
.Net VB
GeneXus (JAVA)
Liferay (JAVA)

SISTEMA GERENCIADOR de BANCO de DADOS

NOME	VERSÃO
ORACLE
MS SQL Server
PostgreSQL
MySQL

SERVIDOR de APLICAÇÃO (WEB e Application Servers)

NOME	VERSÃO
JBoss
Oracle Web Logic
Oracle OC4J
Wildfly
IIS
Apache Camel
Apache Tom Cat

IDE (Integrated Development Environment)

NOME	VERSÃO
Eclipse
JDeveloper
Netbeans
ScriptCase
Nuclide (React Native)
Atom with React Native
PhpMyadmin
PhpPgadmin
Komodo-Edit (python)
Spyder 2 (python)
Weave (xxxxx)
Juno (xxxxx)

PADRÕES de ARQUITETURA de SOFTWARE e PADRÕES de PROJETO

NOME

J2EE e/ou JEE e/ou Jakarta EE

MVC

SOA

REFLECTION (arquitetura de sistemas multi-agentes)

MICROKERNEL

PAC (Apresentação-Abstração-Controle)

MICROSERVICES

CONTAINERS

KUBERNETES

DOCKER

CORBA (perspectiva IoT)

DCOM (perspectiva de IoT)

WCF (Windows Communication Foundation)

SOAP & REST Web Services

SISTEMA OPERACIONAL

NOME	VERSÃO
Red Hat Enterpise Linux
Linux Suse
Oracle Linux
Windows Server

PLATAFORMA de INTEGRAÇÃO SEGURA

NOME VERSÃO

X-ROAD

WSO2

PLATAFORMA de TESTE de SOFTWARE

NOME	VERSÃO
SonarQube
Selenium
Telerik Test Studio
Robotium
Watir
HPE Unified Functional Testing
Cucumber
Visual Studio Test Professional
TestingWhiz

ANEXO VIII DO MODELO DE REFERÊNCIA DE PRÁTICAS DE DESENVOLVIMENTO ÁGIL PARA FÁBRICA DE SOFTWARE COM PARCERIA

PERFIL PROFISSIONAL

Este documento apresenta os papéis atuantes no modelo apresentado no Anexo II - Modelo de Operação da Fábrica de Software do presente Modelo de Referência de Práticas de Desenvolvimento Ágil para Fábrica de Software com Parceria, detalhando as respectivas responsabilidades, responsabilidades e requisitos de qualificação.

Por seguir orientação majoritariamente ágil, o modelo de operação da fábrica de software não transforma funções do desenvolvimento de software em cargos, sendo que um colaborador pode acumular diversos papéis.

Quando o papel é subdividido em grupos, significa que pode adotar um ou outro. O que difere um grupo de outro é a certificação ou não, relacionado ao tempo de experiência exigido

1. PAPÉIS DA MTI

1.1. Líder da Célula

O Líder da Xxxxxx, representante da MTI ou por ela designado, conduz a célula, fazendo a ponte entre unidades externas, demandantes e equipe técnica. Ele executa atividades onde há necessidade de uma representação formal na condução das ações.

O Líder da Xxxxxx também é responsável pela gestão das demandas recebidas pela célula, sejam de sustentação, manutenções ou as demandas tratadas como projetos. Além disso, é responsável pela comunicação formal com as diversas áreas da MTI que sejam parte da solução das demandas (Banco de Dados, Infraestrutura, Arquitetura, Qualidade, Central de Serviços, Escritório de Projetos, etc).

Para os casos de OS do tipo Desenvolvimento classificada como “manutenção”, o Líder da Xxxxxx também é responsável por agrupar e relacionar a(s) demanda(s) que compõem o escopo da OS.

O Líder da Xxxxxx deve reportar o desempenho dos trabalhos da Xxxxxx aos dirigentes da MTI quando necessário, com vistas a alertar sobre potenciais riscos ou fatos que prejudiquem o andamento dos trabalhos, além de manter o gestor da parceria informado sobre o cumprimento dos requisitos operacionais por parte da INTERESSADA.

O Líder da Célula formaliza assuntos da(s) OS(s), monitora e controla as obrigações técnicas da MTI e da INTERESSADA.

1.2. Analista Técnico

O Analista técnico compõe a equipe técnica e atua visando a qualidade e continuidade do produto. Este papel promove o desenvolvimento DevOps, pois facilita o desenvolvimento e entrega de software na instituição. Viabiliza a construção do software por meio de um sistema de produção integrado de pessoas, informação, ativos de hardware, serviços, ferramentas e aplicativos que, por sua vez, apoiam as atividades de gestão de projetos, produção e gerência de requisitos de software, construção de software, testes automatizados, inspeção automatizada da qualidade dos produtos, integração contínua dos componentes de software, disponibilização automática de releases, gestão informatizada dos ambientes de TI, gestão de configuração dos artefatos de engenharia e gestão de mudanças. Todas estas atividades de engenharia de software são desenvolvidas por meio de processos, métodos e ferramentas,

promovendo, assim, o princípio da impessoalidade e a diminuição do esforço da execução pela automação de processos operacionais.

As principais atividades deste papel são:

Apoiar o desenvolvimento de projetos, manutenções e sustentação de soluções de TI;

● Propor estratégias para a definição, desenvolvimento e implantação de tecnologias, aplicáveis à MTI e aos projetos de clientes;

● Estabelecer e manter o modelo e a infraestrutura tecnológica, compatíveis com as necessidades de uso para os projetos desenvolvidos ou integrados pela MTI;

● Realizar o controle dos acessos lógicos que deve ser garantido com o propósito de manter a integridade, a privacidade e a confidencialidade das informações;

● Propor e orientar ações relacionadas à infraestrutura de TI;

● Definir e/ou aprovar modelos de artefatos que visam a referência futura dos produtos;

● Definir e/ou aprovar ferramentas para a gestão e apoio ao desenvolvimento de software;

● Definir e/ou aprovar modelos arquiteturais para as soluções de desenvolvidas ou evoluídas;

● Definir estratégias, procedimentos e práticas para o processo de gerência dos recursos de dados, incluindo padronização, organização, proteção e utilização;

● Prover mecanismos que visam garantir a continuidade das soluções de TI;

● Estabelecer medições de modo a acompanhar e comparar assuntos técnicos;

● Prover visões analíticas relacionadas aos ambientes, tecnologias e atividades;

● Realizar diagnósticos técnicos;

● Realizar controle da disponibilização de versões de produção, das soluções desenvolvidas, mantidas ou evoluídas;

● Deliberar sobre conflitos técnicos;

● Propor e acompanhar a mitigação de riscos técnicos;

● Realizar auditoria para análise de conformidade;

● Realizar avaliação técnica de ferramentas de apoio ao processo de Software;

● Definir ferramentas que apoiem a configuração e mudança do produto;

● Realizar atividades que visam a garantia da qualidade, conformidade, Administração de dados e banco de dados e arquitetura de software.

2. PAPÉIS DO CLIENTE DA MTI

2.1. Dono do Produto

Na célula de projeto, o cliente da MTI tem papel de Dono do Produto, ou seja, o responsável pela solicitação formal de demandas, pela homologação e aceite dos resultados. Ele participa da célula, define a visão do produto e subsidia a criação de uma lista priorizada de itens necessários ao desenvolvimento do sistema, além de definir o planejamento cronológico das entregas em conjunto com a equipe da célula.

O Dono do Produto é o servidor que averigua a qualidade dos produtos entregues e o atendimento aos requisitos do ponto de vista funcional. Ele é responsável pelo aceite formal das entregas.

O Dono do Produto deve prover a visão do produto onde são descritas as necessidades, expectativas e objetivos específicos de negócio. Ele também deve apoiar a elaboração do Roadmap, do produto. Além disso, ele deve subsidiar a definição do Backlog do Produto, que é a lista priorizada dos itens necessários para o desenvolvimento e entrega do produto de software.

2.2. Cliente Demandante

Na célula de manutenção e sustentação, cliente da MTI tem papel de Cliente Xxxxxxxxxx, sendo responsável pela solicitação formal de demandas e pela priorização das manutenções, homologação e aceite dos resultados.

O Cliente Demandante é o servidor que averigua o atendimento aos requisitos e a qualidade dos produtos entregues do ponto de vista funcional. Ele é responsável pelo aceite formal das entregas.

3. PAPÉIS DA EMPRESA INTERESSADA DA MTI

3.1. Gerente de Sistemas

O Gerente de Sistemas, é responsável pelo atendimento de todas as demandas encaminhadas à Célula que gerencia, tanto referente a projetos quanto às referentes a manutenções e sustentação.

O Gerente de Sistemas deve conduzir a equipe da INTERESSADA na execução das demandas e é responsável pela gestão operacional destes profissionais. O controle das atividades da INTERESSADA será realizado mediante acompanhamento das tarefas realizadas e pela entrega dos serviços.

O Gerente de Sistemas também deve prover ao Líder da Célula todas as informações necessárias ao efetivo exercício das suas atividades, comunicando sobre as demandas recebidas e reportando o desempenho dos trabalhos, com vistas a alertar sobre potenciais riscos ou fatos que prejudiquem o andamento das atividades.

O foco do Gerente de Sistemas está na gestão das atividades operacionais, sendo o responsável pelo cumprimento dos indicadores de desempenho da INTERESSADA no que se refere à sua Célula.

O Gerente de Sistemas também assumirá algumas atribuições de Scrum Master, sendo responsável por garantir que as práticas ágeis adotadas na célula sejam entendidas e aplicadas, pela dinâmica diária de trabalho da equipe, pela remoção de impedimentos, pela interação com o Dono do Produto e clientes, e pelo apoio na organização das equipes para atendimento das demandas recebidas na Célula.

A qualificação técnica esperada para o papel Gerente de sistemas:

● Graduação em curso de nível superior na área de Tecnologia da Informação, ou conclusão de qualquer curso de nível superior acompanhado de certificado de curso de pós-graduação, em nível Lato Senso e/ou Strictu Sensu, na área de Tecnologia da Informação de, no mínimo, 360 horas;

● Certificação SCRUM Master;

● Experiência comprovada de 3 (três) anos, no gerenciamento de equipe de atendimento a demandas em contratos de serviços de tecnologia da informação baseados em ordens de serviço, chamados, demandas ou equivalentes;

● Conhecimentos em Concepção Ágil de Produtos, Gestão Ágil de Projetos e Kanban.

3.2. Analista de Negócio

O Analista de Xxxxxxx, profissional da INTERESSADA, responsável pelo entendimento negocial relacionado aos sistemas. Deverá realizar interações constantes com a área negocial e apoiar o desenvolvimento durante o projeto, manutenção ou sustentação dos sistemas.

O Analista de Negócio deve elicitar as regras, escrever documentos de requisitos para o processo de software, dirimir dúvidas negociais. Ele é responsável também por escrever e manter a documentação da solução que visa a referência futura.

O Analista de negócio deve documentar orientações de uso da solução para o usuário final.

A qualificação técnica esperada para o papel Analista de Xxxxxxx:

● Graduação em curso de nível superior na área de Tecnologia da Informação, ou conclusão de qualquer curso de nível superior acompanhado de certificado de curso de pós-graduação, em nível Lato Senso e/ou Strictu Sensu, na área de Tecnologia da Informação de, no mínimo, 360 horas;

● Experiência comprovada de 3 (três) anos em Análise de Negócio e/ou Requisitos de software;

● Conhecimentos em projetos ágeis, elaboração documentação de software e construção do produto de produto, elicitação de regras de negócio e utilização de ferramentas de modelagem de processo e prototipação.

3.3. Desenvolvedor

O Desenvolvedor, profissional da INTERESSADA, é responsável por executar os serviços necessários a codificação de aplicações, sistemas, componentes e/ou serviços (back-end), abrangendo analise dos requisitos, manipulação de banco de dados, elaboração de documentação para referência futura, além de atividades relacionadas à criação/adaptação de interface do usuário (front-end). Dessa forma o profissional deve ter um conhecimento multidisciplinar nas várias áreas exigidas. Tal perfil é comumente denominado “full-stack” e visa valorizar as habilidades e os conhecimentos de computação do desenvolvedor e da equipe.

A qualificação técnica esperada para o papel Desenvolvedor: Para todos os grupos:

● Graduação em curso de nível superior na área de Tecnologia da Informação, ou conclusão de qualquer curso de nível superior acompanhado de certificado de curso de pós-graduação, em nível Lato Senso e/ou Strictu Sensu, na área de Tecnologia da Informação de, no mínimo, 360 horas;

● O profissional deve ser full-stack, ou seja, ter um conhecimento multidisciplinar nas várias áreas do desenvolvimento de soluções de TI;

● Conhecimento em metodologias ágeis, preferencialmente Scrum e Kanban, documentação de software e prototipação, gitflow, versionamento (git e svn);

● Conhecimento em Angular.js, React.js ou Vue.js;

● Conhecimento em SGBD Oracle e SGBD PostgreSql. Grupo 1 (profissional nível Pleno):

● Experiência comprovada de 3 (três) anos com desenvolvimento de sistemas, aplicações e web services em PHP;

● Certificação Zend Certified PHP Engineer;

● Conhecimento em Zend Framework 2, Slim Framework, Laravel ou Symfony.

Grupo 2 (profissional nível Pleno):

● Experiência comprovada de 5 (cinco) anos com desenvolvimento de sistemas, aplicações e web services em PHP;

● Conhecimento em Zend Framework 2, Slim Framework, Laravel ou Symfony.

Grupo 3 (profissional nível Pleno):

● Experiência comprovada de 2 (dois) anos com desenvolvimento de sistemas, aplicações, web services em Java;

● Certificação OCE Web Services Developer; Certificação OCP Programmer;

● Conhecimento em Java EE 7+ ou Spring Framework 4+. Grupo 4 (profissional nível Pleno):

● Experiência comprovada de 3 (três) anos com desenvolvimento de sistemas, aplicações e web services em Java;

● Certificação OCP Programmer;

● Conhecimento em Java EE 7+ ou Spring Framework 4+. Grupo 5 (profissional nível Pleno):

● Experiência comprovada de 5 (cinco) anos com desenvolvimento de sistemas, aplicações e web services em Java;

● Conhecimento em Java EE 7+ ou Spring Framework 4+. Grupo 6 (profissional nível Pleno):

● Certificação GeneXus Analyst;

● Experiência comprovada de 3 (três) anos com desenvolvimento de sistemas, aplicações e web services em Genexus;

● Conhecimento em SmartDevicesPlus Framework, WorkWithPlus Framework.

Grupo 7 (profissional nível Pleno):

● Experiência comprovada de 5 (cinco) anos com desenvolvimento de sistemas, aplicações e web services em Genexus;

● Conhecimento em SmartDevicesPlus Framework, WorkWithPlus Framework.

Grupo 8 (profissional nível Pleno):

● Certificação MCSD Certification Toolkit (Programming in C#);

● Experiência comprovada de 3 (três) anos com desenvolvimento de sistemas, aplicações e web services em C#, VB#;

● Conhecimento em .NET Framework. Grupo 9 (profissional nível Pleno):

● Experiência comprovada de 5 (cinco) anos com desenvolvimento de sistemas, aplicações e web services em C#, VB#;

● Conhecimento em .NET Framework. Grupo 10 (profissional nível Pleno):

● Certificação Certified Professional in Python Programming (PCPP-32-1);

● Experiência comprovada de 3 (três) anos com desenvolvimento de sistemas, aplicações e web services em Python;

● Conhecimento em .Django, Flasky, Web2py. Grupo 11 (profissional nível Pleno):

● Experiência comprovada de 5 (cinco) anos com desenvolvimento de sistemas, aplicações e web services em NodeJS;

● Conhecimento em .ExpressJS, NextJS, TypeORM. Grupo 12 (profissional nível Sênior):

● Experiência comprovada de 5 (cinco) anos com desenvolvimento de sistemas, aplicações e web services em PHP;

● Certificação Zend Certified PHP Engineer;

● Conhecimento em Zend Framework 2, Slim Framework, Laravel ou Symfony.

Grupo 13 (profissional nível Sênior):

● Experiência comprovada de 8 (oito) anos com desenvolvimento de sistemas, aplicações e web services em PHP;

● Conhecimento em Zend Framework 2, Slim Framework, Laravel ou Symfony.

Grupo 14 (profissional nível Sênior):

● Experiência comprovada de 5 (cinco) anos com desenvolvimento de sistemas, aplicações e web services em Java;

● Certificação OCP Programmer;

● Conhecimento em Java EE 7+ ou Spring Framework 4+. Grupo 15 (profissional nível Sênior):

● Experiência comprovada de 8 (oito) anos com desenvolvimento de sistemas, aplicações e web services em Java Conhecimento em Java EE 7+ ou Spring Framework 4+.

Grupo 16 (profissional nível Sênior):

● Certificação GeneXus Analyst;

● Experiência comprovada de 5 (cinco) anos com desenvolvimento de sistemas, aplicações e web services em Genexus;

● Conhecimento em SmartDevicesPlus Framework, WorkWithPlus Framework.

Grupo 17 (profissional nível Sênior):

● Experiência comprovada de 8 (oito) anos com desenvolvimento de sistemas, aplicações e web services em Genexus;

● Conhecimento em SmartDevicesPlus Framework, WorkWithPlus Framework.

Grupo 18 (profissional nível Sênior):

● Certificação MCSD Certification Toolkit (Programming in C#);

● Experiência comprovada de 5 (cinco) anos com desenvolvimento de sistemas, aplicações e web services em C#, VB#;

● Conhecimento em .NET Framework. Grupo 19 (profissional nível Sênior):

● Experiência comprovada de 8 (oito) anos com desenvolvimento de sistemas, aplicações e web services em C#, VB#;

● Conhecimento em .NET Framework. Grupo 20 (profissional nível Sênior):

● Certificação Certified Professional in Python Programming (PCPP-32-1); Experiência comprovada de 5 (cinco) anos com desenvolvimento de sistemas, aplicações e web services em Python;

● Conhecimento em .Django, Flasky, Web2py. Grupo 21 (profissional nível Sênior):

● Experiência comprovada de 8 (cinco) anos com desenvolvimento de sistemas, aplicações e web services em NodeJS;

● Conhecimento em .ExpressJS, NextJS, TypeORM.

3.4. Designer

O Designer, profissional da INTERESSADA, é responsável pela programação visual dos sistemas e aplicações criando layouts e templates reutilizáveis, observando os princípios de acessibilidade, usabilidade, responsividade e a identidade visual estabelecida pela MTI.

Por ser um papel de cunho substancialmente artístico o Designer deve ser versado nas atividades de edição/manipulação de imagens, concepção de logomarcas, diagramação de conteúdo e elaboração de identidade visual.

O Designer deve ser capaz de elaborar estudos de acessibilidade e usabilidade em sistemas legados e propor evoluções visuais, criar/adaptar layouts e templates (html/css) e criar/adaptar componentes visuais (JavaScript).

A qualificação técnica esperada para o papel Designer:

Para todos os grupos:

● Graduação em curso de nível superior na área de Design ou Tecnologia da Informação, ou conclusão de qualquer curso de nível superior acompanhado de certificado de curso de pós-graduação, em nível Lato Senso e/ou Strictu Sensu, na área de Design ou Tecnologia da Informação de, no mínimo, 360 horas;

● Conhecimentos nos padrões de acessibilidade eMag e WCAG. Grupo 1:

● Certificação Adobe Certified Expert;

● Experiência comprovada de 2 (dois) anos com design gráfico, web design, usabilidade, responsividade, desenvolvimento de interfaces e front-end.

Grupo 2:

● Experiência comprovada de 5 (cinco) anos com design gráfico, web design, usabilidade, responsividade, desenvolvimento de interfaces e front-end.

3.5. Analista de Qualidade

O Analista de Qualidade, profissional da INTERESSADA, é responsável por apoiar as etapas de concepção dos produtos e projetos contribuindo com todas as questões relacionadas à qualidade, dar apoio ao Desenvolvedor, no levantamento de requisitos, na elaboração de documentação de referência futura e manuais de usuários, como também por garantir que os indicadores de qualidade definidos pela MTI sejam atingidos a cada entrega. Indicadores como complexidade ciclomática, acoplamento, cobertura de testes unitários e testes de integração, duplicidade de linhas, violações críticas e outros, serão continuamente revistos, adicionados ou removidos, e ajustados conforme necessidade da MTI.

O Analista de Qualidade também deverá ter amplo conhecimento em automatização de testes funcionais e não funcionais. Ele é o profissional responsável pelo processo, realizando desde a criação dos testes automatizados, sua execução, verificação de erros e correções, quando houver.

Espera-se multidisciplinaridade deste perfil que é comumente conhecido como “full stack quality analyst”, que similarmente ao “desenvolvedor full stack”, o Analista de Qualidade full stack deve trabalhar em todos os aspectos da qualidade usando diferentes métodos para testar a aplicação. Ele deve pensar nos diferentes aspectos de qualidade, tais como funcionalidade, acessibilidade, usabilidade, performance e segurança, sempre levando em consideração a perspectiva da visão do usuário.

A qualificação técnica esperada para o papel Analista de Qualidade: Para todos os grupos:

● Graduação em curso de nível superior na área de Tecnologia da Informação, ou conclusão de qualquer curso de nível superior acompanhado de certificado de curso de pós-graduação, em nível Lato Senso e/ou Strictu Sensu, na área de Tecnologia da Informação de, no mínimo, 360 horas;

● Conhecimento em ferramentas de testes;

● Conhecimento sobre práticas de desenvolvimento orientado a testes (TDD) e desenvolvimento orientado a comportamento (BDD);

● Conhecimento em testes exploratórios, testes de comportamento, teste e2e (end to end) e testes em aplicações web multicamada;

● Conhecimentos em linguagem SQL. Grupo 1:

● Certificação BSTQB CTAL Test Analyst ou BSTQB CTAL Technical Test Analyst;

● Experiência comprovada de 1 (um) ano com testes. Grupo 2:

● Certificação BSTQB CTFL-AT (CTFL Agile Tester);

● Experiência comprovada de 2 (dois) anos com testes. Grupo 3:

● Certificação BSTQB CTFL;

● Experiência comprovada de 3 (três) anos com testes. Grupo 4:

● Experiência comprovada de 4 (cinco) anos com testes.

3.6. Arquiteto

O Arquiteto, profissional da INTERESSADA, é responsável por direcionar tecnicamente e/ou executar os serviços necessários à codificação de aplicações, sistemas, componentes e/ou serviços (back-end), abrangendo o levantamento de requisitos, manipulação de banco de dados, elaboração de documentação técnica, além de atividades relacionadas à criação/ adaptação de interface do usuário (front-end), code review do código desenvolvido pelo time de desenvolvimento, elaborar arquitetura de sistemas / componentes / serviços e prospectar tecnologias.

Dessa forma o profissional deve ter um conhecimento multidisciplinar nas várias áreas exigidas. Tal perfil é comumente denominado “full-stack” e visa valorizar as habilidades e os conhecimentos de computação do arquiteto e da equipe, em linha com o que pregam as orientações “ágil”.

O Arquiteto também deve disponibilizar capacidade técnica para desenhar Arquitetura de Solução de Software, que utilize Práticas Ágeis, que possibilite transformar a experiência de usuários/clientes, contemplando estratégia de engajamento, elucidação de requisitos, análise, modelagem e implementação de soluções centradas em arquitetura de software.

A qualificação técnica esperada para o papel Arquiteto:

Para todos os grupos:

● Graduação em curso de nível superior na área de Tecnologia da Informação, ou conclusão de qualquer curso de nível superior acompanhado de certificado de curso de pós-graduação, em nível Lato Senso e/ou Strictu Sensu, na área de Tecnologia da Informação de, no mínimo, 360 horas;

● Conhecimento em Angular.js, React.js ou Vue.js;

● Conhecimento em SGBD Oracle;

● Conhecimento em metodologias ágeis.

Grupo 1:

● Certificação OCM Java EE Enterprise Architect;

● Experiência comprovada de 1 (um) ano com Arquitetura de Software;

● Experiência comprovada de 3 (três) anos com desenvolvimento de sistemas, aplicações e web services em Java;

● Conhecimento em Java EE 7+ ou Spring Framework 4+. Grupo 2:

● Certificação OCP Programmer e Certificação OCE Web Services Developer;

● Experiência comprovada de 2 (dois) anos com Arquitetura de Software;

● Experiência comprovada de 4 (quatro) anos com desenvolvimento de sistemas, aplicações e web services em Java;

● Conhecimento em Java EE 7+ ou Spring Framework 4+. Grupo 3:

● Experiência comprovada de 4 (quatro) anos com Arquitetura de Software; Experiência comprovada de 7 (sete) anos com desenvolvimento de sistemas, aplicações e web services em Java;

● Conhecimento em Java EE 7+ ou Spring Framework 4+. Grupo 4:

● Certificação Zend Certified PHP Engineer;

● Experiência comprovada de 3 (três) anos com Arquitetura de Software;

● Experiência comprovada de 5 (cinco) anos com desenvolvimento de sistemas, aplicações e web services em PHP;

● Conhecimento em Zend Framework 2, Slim Framework, Laravel ou Symfony.

Grupo 5:

● Certificação GeneXus Senior Analyst;

● Experiência comprovada de 3 (três) anos com Arquitetura de Software;

● Experiência comprovada de 5 (cinco) anos com desenvolvimento de sistemas, aplicações e web services em Genexus;

● Conhecimento em SmartDevicesPlus Framework, WorkWithPlus Framework.

Grupo 6:

● Certificação International Association of Software Architects (IASA);

● Experiência comprovada de 3 (três) anos com Arquitetura de Software;

● Experiência comprovada de 5 (cinco) anos com desenvolvimento de sistemas, aplicações e web services em C#, VB#;

● Conhecimento em .NET Framework. Grupo 7:

● Certificação Certified Professional in Python Programming (PCPP-32-2);

● Experiência comprovada de 3 (três) anos com Arquitetura de Software;

● Experiência comprovada de 5 (cinco) anos com desenvolvimento de sistemas, aplicações e web services em Python;

● Conhecimento em .Django, Flasky, Web2py. Grupo 8:

● Certificação OpenJS Node.js Services Developer (JSNSD) Program

● Certificação OpenJS Node.js Application Developer (JSNAD) Program

● Experiência comprovada de 3 (três) anos com Arquitetura de Software;

● Experiência comprovada de 5 (cinco) anos com desenvolvimento de sistemas, aplicações e web services em NodeJS;

● Conhecimento em .ExpressJS, NextJS, TypeORM.

3.7. Cientista de dados

O Cientista de dados é um profissional da INTERESSADA que atua em área voltada para o estudo e análise de dados, estruturados ou não, objetivando extração de conhecimento ou insights para possíveis tomadas de decisão, de maneira similar à mineração de dados, porém com aplicabilidade de inteligência de dados. Ciência de dados integra conceitos de Big Data e Machine Learning, além de técnicas de outras áreas interdisciplinares como estatística, economia, engenharia e outros subcampos da computação como: Banco de Dados e Análise de Agrupamentos (Cluster Analysis). Dentre as variadas utilidades da Ciência de Dados, destaca-se que esta tem potencial para transformar uma grande quantidade de dados brutos em insights de negócios e, com isso, auxiliar, com inteligência de dados, especialmente em caráter preditivo, as organizações em tomadas de decisões em seu ciclo de melhoria contínua, especialmente em termos de eficiência, escalabilidade e economicidade.

O Cientista de Dados também deve disponibilizar capacidade técnica para especificar e implantar Solução de Software. utilizando Práticas Ágeis. que operacionalize desenho, implementação e implantação de modelos de analytics e inteligência de dados.

O Cientista de Dados também deve disponibilizar capacidade técnica para mentoriar design de Processo de Solução de Software. utilizando Práticas Ágeis. que possibilite disciplinar especificação, implementação e implantação de modelos de analytics e inteligência de dados, compreendendo a definição e elicitação de modelos operacionais e organizacionais, processos, papéis, responsabilidades e requisitos de arquitetura de tecnologia.

Em termos de Certificações, abaixo reporta-se a qualificação técnica esperada para este perfil:

● Certified Analytics Professional (CAP);

● Certificação Associado Cloudera (CCA) - Analista de Dados;

● Certificação Profissional Cloudera - Engenheiro de Dados CCP;

● Data Science Council of America (DASCA);

● HDP Data Science;

● Certificação Profissional de Análises Avançadas do SAS (SAS Academy for Data Science);

● Certificação de Cientista de Dados do SAS.

Em termos de Tecnologia de Escrita de Código, abaixo reporta-se a qualificação técnica esperada para este perfil:

● Python;

● R;

● SQL;

● SAS.

3.8. Consultor de Projetos

O Consultor de Projetos, profissional da INTERESSADA, presta apoio ao Escritório de Projetos da MTI, fazendo a ponte com as equipes das células e compilando dados para o Portfólio de Projetos e Gestão das demandas. Também deve compilar estes dados como apoio nas atividades de monitoramento do Portfólio de Projetos executada pelo Escritório de Projetos.

O Consultor de Projetos presta apoio metodológico às equipes das células, e também verifica a aderência das atividades e artefatos às metodologias de projeto adotadas pela MTI.

O Consultor de Projetos atua como facilitador, é o responsável pela preparação, organização do workshop de concepção do produto, sua realização, condução e consolidação da visão e resultados.

O Consultor de Projetos atuará como Coaching, sendo acionado sob demanda pelo Escritório de Projetos da MTI, sempre que for necessário realizar o alinhamento de conceitos e processos para o Líder da Célula e para o Dono do Produto.

O Consultor deve disponibilizar capacidade técnica para operacionalizar consultoria em planejamento e desenvolvimento de Solução de Software utilizando práticas ágeis.

O Consultor também deve disponibilizar capacidade técnica para operacionalizar consultoria em implantação de modelos de excelência que utilizam Práticas Ágeis para desenvolvimento de Soluções de Software e implantação de modelos de gestão baseados em Lean.

A qualificação técnica esperada para o papel Consultor de Projetos:

● Graduação em curso de nível superior na área de Tecnologia da Informação, ou conclusão de qualquer curso de nível superior acompanhado de certificado de curso de pós-graduação, em nível Lato

Senso e/ou Strictu Sensu, na área de Tecnologia da Informação de, no mínimo, 360 horas;

● Certificação SCRUM Master;

● Certificação PMP (Project Management Professional) ou PMI-ACP (Agile Certified Practitioner);

● Experiência comprovada de 5 (cinco) anos em projetos de Tecnologia da Informação;

● Conhecimentos em Concepção Ágil de Produtos, Gestão Ágil de Projetos e conceitos de Design Thinking e PMO Ágil.

3.9. Preposto

O preposto será o representante da INTERESSADA, responsável por acompanhar a execução do contrato e atuar como interlocutor principal junto ao futuro CLIENTE, incumbido de receber, diligenciar, encaminhar e responder as principais questões técnicas, legais e administrativas referentes ao andamento contratual.

O gerente de contrato será responsável pela interlocução técnica com ao futuro CLIENTE acerca da qualidade e andamento dos serviços. São responsabilidades do preposto:

a. Zelar pela qualidade geral dos serviços prestados;

b. Supervisionar, a atuação dos gerentes de sistemas;

c. Participar das reuniões regulares de acompanhamento do contrato, em periodicidade a ser definida pela MTI;

d. Avaliar, em conjunto com a MTI, os níveis de serviço alcançados;

e. Participar, sempre que convocado pela MTI, de reuniões de abertura, acompanhamento ou encerramento de projetos;

f. Apresentar e negociar com a MTI medidas corretivas para OS com problema em sua execução, ou com vistas a atingir ou restabelecer níveis de serviço previstos nesta especificação técnica;

g. Assegurar que as medidas corretivas negociadas sejam devidamente observadas pela equipe.

A qualificação técnica esperada para o papel Preposto:

● Graduação em curso de nível superior de, no mínimo, 360 horas;

● Experiência profissional de 2 (dois) anos em gestão de contratos, comprovada através de Atestado, nominal ao profissional, contendo a descrição das principais atividades desenvolvidas pelo profissional, fornecido por órgão da Administração Pública ou empresa privada;

● Conhecimento em gerenciamento de projetos comprovado através de Atestado de Capacidade Técnica, nominal ao profissional, contendo a descrição do projeto e as atividades desenvolvidas pelo profissional, fornecido por órgão da Administração Pública ou empresa privada abordando métodos ágeis, liderança de equipe e avaliação de resultados.

Release será homologada pelo Dono do Produto e os artefatos técnicos aprovados pela equipe da MTI. Deve ser realizado o aceite formal dos artefatos, conforme previsto no “Catálogo de Serviços de Solução de Software”. O aceite formal dos artefatos que descrevem tecnicamente a Solução de Software deve ser realizado pelo Líder de Célula de Projeto e, o aceite formal do atendimento dos requisitos funcionais da Solução de Software deve ser realizado pelo Dono do Produto.

A OS do tipo Desenvolvimento de Software classificada como Projeto será considerada concluída após a aceitação de todas os entregáveis descritas no “Catálogo de Serviços de Solução de Software” que devem ser disponibilizados pela INTERESSADA.

A remuneração de uma “OS do tipo Desenvolvimento de Software classificada como Projeto” será realizada por Release entregue. A Release entregue representa uma versão homologada pelo cliente mediante acordo contratual.

Ao executar uma “OS do tipo Desenvolvimento de Solução de Software” classificada como “Projeto”, a PARCERIA assume a responsabilidade sobre o projeto como um todo e suas Releases participantes. Isto significa que todos os artefatos entregues nas Releases anteriores devem ser mantidos, atualizados e versionados em decorrência da evolução do projeto.

A não atualização de determinado artefato afetado pela evolução do projeto em uma Release posterior pode ensejar a não aceitação dos artefatos da Release corrente e, consequentemente, a não autorização de inclusão da Release no faturamento. Por exemplo, se durante o refinamento de requisitos da segunda Release, for identificada nova entidade de negócio, os artefatos versionados e entregues na Release anterior devem ser atualizados para refletir a nova realidade.

Do mesmo modo, a INTERESSADA deve assegurar que o desenvolvimento das Releases posteriores não comprometa o funcionamento das Releases entregues anteriormente. Por exemplo, se a implementação de determinada Release ensejar erro no funcionamento de Release já entregue, a INTERESSADA obriga- se a corrigi-lo antes da conclusão da nova Release.

A INTERESSADA deve acompanhar e realizar suporte ao cliente para a homologação da Solução de Software onde, dentre outras atividades afins, deve esclarecer dúvidas quanto ao uso das funcionalidades desenvolvidas; elaborar scripts para carga de dados de homologação, receber, analisar os erros detectados pelos usuários; reportar o andamento da homologação para a equipe de gestão do contrato da MTI, relacionando problemas encontrados e prazos para correção.

Caso durante a atividade de homologação da Solução de Software o Dono do Produto solicite mudanças de requisitos nas funcionalidades a serem homologadas, estas mudanças devem ser incorporadas no Backlog do Produto e o seu atendimento planejado nas próximas Releases.

O prazo para homologação do software pelo Dono do Produto será acordado previamente no planejamento da Release, onde deve-se também incluir acordo de limite de tempo para o Dono do Produto reportar e registrar o resultado da homologação da Solução de Software a partir da data de sua disponibilização em ambiente de homologação. Após o tempo decorrido a Solução de Software será considerada homologada para efeitos de remuneração.

A responsabilidade de realizar o treinamento dos Gestores da Solução de Software é do Líder da Célula de Projeto. Opcionalmente, a pedido do Líder, este treinamento pode ser realizado pela INTERESSADA. A INTERESSADA tem a responsabilidade de preparar os artefatos que serão usadas no treinamento.

i.Característica específica da OS do tipo Desenvolvimento de Solução de Software classificada como Manutenção

Somente serviços participantes do “Catálogo de Serviços de Solução de Software” classificados como “Manutenção” podem ser inseridos neste tipo de OS.

As demandas são classificadas como Manutenção evolutiva/adaptativa quando tratarem de correção, alteração, exclusão ou inclusão de nova funcionalidade em aplicação existente, ou conjunto de funcionalidades que não sejam classificados como projeto pela MTI. Devem ser consideradas/tratadas correções de sistema que não estejam em Sustentação por terceiros. Para sistemas em Sustentação por terceiros as correções devem ser tratadas com regras específicas do “Catálogo de Serviços de Solução de Software”.

O fluxo de trabalho para execução de OS do tipo “Desenvolvimento de Solução de Software” classificada como Manutenção está detalhado no “ANEXO I-D – Executar Manutenção de Solução de Software”do presente Modelo de Referência de Práticas de Desenvolvimento Ágil para Fábrica de Software com Parceria.

Para a abertura de OS do tipo Desenvolvimento de Software classificada como Manutenção, o Líder da MTI deve elencar as demandas que serão atendidas na OS. Caso as demandas de Manutenção sejam divididas em mais de uma OS, o Líder da MTI deve distribuir as demandas por OS, agrupando as demandas por funcionalidades afetadas, com o objetivo de todas as alterações serem incorporadas na mesma Release.

Para a OS do tipo “Desenvolvimento de Solução de Software” classificada como Manutenção, o dimensionamento do prazo de atendimento será estabelecido na atividade “Estabelecer Prazo de Entrega”.

Para que a INTERESSADA possa executar uma OS do tipo “Desenvolvimento de Solução de Software” classificada como Manutenção evolutiva/adaptativa para um sistema não desenvolvido por ela própria, é necessário que a MTI promova a realização de repasse técnico de conhecimento para a INTERESSADA. Durante o repasse de conhecimento técnico a MTI deve

disponibilizar acesso à INTERESSADA ao código fonte do sistema assim como aos artefatos de referência existentes.

Em se tratando de sistemas desenvolvidos pela própria INTERESSADA, não será necessário realizar repasse de conhecimento técnico e disponibilizar acesso ao código fonte e eventuais artefatos de referência do sistema.

Uma OS de Manutenção evolutiva/adaptativa corresponde, preferencialmente, a uma única Release de entrega, cabendo à INTERESSADA, em conjunto com o Líder da Célula, definir uma Release intermediária em função da prioridade estabelecida, visando o melhor atendimento das necessidades da área de negócio. Porém, mesmo que ocorra a entrega de uma Release intermediária, a OS do tipo “Desenvolvimento de Solução de Software” classificada como Manutenção” somente será paga em parcela única, quando a OS for concluída. A remuneração da OS do tipo “Desenvolvimento de Solução de Software” classificada como Manutenção.

Cabe à INTERESSADA, em conjunto com o Líder da Célula, determinar quando demandas previamente classificadas como Manutenção devem ser tratadas como projeto, e reclassificá-las. Neste caso, a OS do tipo de “Desenvolvimento de Solução de Software” classificada como Projeto deve seguir o fluxo de trabalho estabelecido “ANEXO I-C – Executar Projeto de Soluções de Software”.

A OS do tipo “Desenvolvimento de Solução de Software” classificada como Manutenção será considerada concluída após a aceitação de todos os entregáveis descritos no “Catálogo de Serviços de Solução de Software” plenamente disponibilizados pela INTERESSADA.

O aceite formal dos artefatos que descrevem tecnicamente a Solução de Software deve ser realizado pelo Líder de Célula de Manutenção e Sustentação e, o aceite formal do atendimento dos requisitos funcionais deve ser realizado pelo Dono do Produto.

A INTERESSADA deve acompanhar e realizar suporte ao cliente para a homologação da Manutenção realizada. Incluem, dentre outras, as ações de esclarecer dúvidas quanto ao uso das funcionalidades desenvolvidas; receber analisar e corrigir os erros detectados pelos usuários; reportar o andamento da homologação para a equipe de gestão do contrato da MTI, relacionando problemas encontrados e cronograma com prazos para correção e disponibilização.

Caso ocorra que durante a atividade de homologação da Release da Solução de Software o Dono do Produto solicite mudanças de requisitos que afete as funcionalidades a serem homologadas, estas mudanças devem ser incorporadas no Backlog do Produto e o seu atendimento planejado nas próximas Releases.

Caso ocorra que durante a atividade de homologação da nova Release entregue pela INTERESSADA o cliente solicite mudanças de requisitos que afete a funcionalidade em homologação, estas mudanças devem ser planejadas para as próximas Releases com a devida incorporação ao Backlog do Produto.

O prazo para homologação da funcionalidade mantida será acordado previamente com o cliente na atividade “Estabelecer Prazo de Entrega”. Será acordado também um limite de tempo para o cliente registrar o resultado da homologação da funcionalidade a partir da data de sua disponibilização em ambiente de homologação, após o tempo decorrido a Manutenção realizada será considerada homologada para efeitos de remuneração.

A responsabilidade de realizar o treinamento dos Gestores da Solução de Software é do Líder da Célula de Manutenção e Sustentação. A pedido do Líder, este treinamento pode ser realizado pela INTERESSADA. Cabe a INTERESSADA preparar os artefatos que serão usados no treinamento.

ii.Característica da OS do tipo Sustentação de Solução de Software

O objetivo da OS de Sustentação de sistemas é realizar a Sustentação de determinada solução, visando manter o seu estado normal de operação.

A Sustentação engloba, dentre outras, investigação e tratamento de incidentes relativos à degradação de performance da aplicação ou relativos a erros funcionais.

As características técnicas participantes de uma OS de Sustentação são, não se restringindo a tais:

▪ Investigação de incidentes e diagnóstico de causa-raiz;

▪ Restabelecimento do serviço por meio de solução de contorno;

▪ Manutenção corretiva (tratamento da causa raiz/solução definitiva do problema);

▪ Suporte à operação da aplicação como a preparação de scripts para sanar situações não tratadas pela aplicação, entre outras situações.

Desta forma, a OS de Sustentação compreende o atendimento de demandas tanto classificadas como “Incidente” quanto “Solicitação” conforme serviços estabelecidos no “Catálogo de Serviços de Solução de Software”.

Demandas classificadas como “Incidente” referenciam interrupções não planejadas ou redução da qualidade da Solução de Software sustentada. Já as classificadas como “Solicitações” referenciam atividades preventivas ou oriundas de levantamento de informações técnicas.

As demandas relacionadas à Sustentação, serão encaminhados para a INTERESSADA através de ferramenta tecnológica com as características definida pela conforme Anexo III - Características das Ferramentas Técnicas e de Gestão do presente Modelo de Referência de Práticas de Desenvolvimento Ágil para Fábrica de Software com Parceria.

O diagnóstico realizado pela INTERESSADA deverá indicar solução de contorno aplicável, e, quando couber, a medida corretiva necessária. O diagnóstico deverá ser registrado em ferramenta definida pela MTI.

Quando o diagnóstico da demanda apontar necessidade de Manutenção corretiva na aplicação, a INTERESSADA é responsável pela sua execução, observando os níveis de serviço estabelecidos no “Anexo V - Níveis Mínimos de Serviço”, tanto para demandas classificadas como “Incidente” como para demandas classificadas como “Solicitação”.

Por outro lado, quando o diagnóstico da demanda apontar necessidade de intervenção na configuração do ambiente de hardware e software mantido e/ou desenvolvido pela MTI no qual a aplicação se insere, a INTERESSADA deverá indicar que mudanças contextuais provocaram essa necessidade. Neste caso, a área de infraestrutura de TI da MTI analisará os apontamentos da INTERESSADA. Caso esteja de acordo, adotará as medidas cabíveis para corrigir o problema. Caso contrário, o devolverá para outro tratamento por parte da INTERESSADA.

Para os serviços de investigação, sempre que necessário, será utilizado o ferramental de monitoração do ambiente disponível na MTI.

A INTERESSADA poderá sugerir a incorporação de outras ferramentas ao ambiente desde que isto não represente custo adicional para a MTI. Entretanto, a incorporação estará sujeita à aprovação da área de infraestrutura da MTI.

O serviço de investigação engloba a consulta as camadas da arquitetura tecnológica da MTI que suporta as Soluções de Software, onde deve ser disponibilizado LOGs, Relatórios Técnicos dentre outros ativos de subsidiam a investigação. Este processo de investigação e tratamento das demandas deverá ser realizado a partir da Nuvem Privada da MTI.

A MTI disponibilizará mecanismos de acesso controlado a sua Nuvem Privada para possibilitar que os serviços de Sustentação sejam realizados.

Os serviços de Sustentação, quando envolverem necessidade de consulta em bases de dados, esta deverá ser operacionalizada na Nuvem Privada da MTI.

Quando os serviços de Sustentação assim demandarem, em pleno acordo entre a INTERESSADA e a MTI, esta última fornecerá, em periodicidade acordada, visão atualizada de parcela de suas bases de dados após aplicação de inteligência de ocultação e comprometimento inerente termos previamente assinados que acobertam o sigilo.

O acesso restrito e temporário de consulta à base produção para análise, será concedido em situações excepcionais, mediante solicitação devidamente justificada, e somente quando não for possível reproduzir a ocorrência em outras bases de dados. Esse acesso somente poderá ser realizado dentro da Nuvem Privada da MTI, com sua devida supervisão.

Em nenhuma hipótese será concedido acesso de atualização na base de produção a profissionais da INTERESSADA.

Quando for necessária a execução de scripts em ambiente de produção, estes devem ser preparados pela INTERESSADA e encaminhados para avaliação da área técnica especializada da MTI, que, após análise e aprovação, providenciará

a execução do mesmo. Os scripts não aprovados serão devolvidos para correção pela INTERESSADA.

Caso materialize as hipóteses previstas que justifiquem a interrupção da Sustentação sob responsabilidade da INTERESSADA, a MTI comunicará com 30(trinta) dias úteis de antecedência a retirada de determinada Solução de Software do regime de Sustentação pela INTERESSADA. Este mesmo período de antecedência deve ser observado para comunicar à INTERESSADA da entrada de uma Solução de Software sob sua responsabilidade de Sustentação.

A entrada de uma Solução de Software em Sustentação sob responsabilidade da INTERESSADA é formalizada com a emissão de uma OS de Sustentação. A vigência dessa OS estará limitada à vigência da parceria, podendo ser suspensa a critério da MTI a qualquer momento, desde que respeitada a antecedência mínima descrita no item anterior.

Para que a INTERESSADA possa receber uma OS de Sustentação para uma Solução de Software não desenvolvido pela própria INTERESSADA, é necessário que seja realizado, sob gestão da MTI, repasse de conhecimento técnico.

Em se tratando de Solução de Software desenvolvidos pela própria INTERESSADA, não será necessário o repasse de conhecimento antes do encaminhamento da OS de Sustentação.

A remuneração da Sustentação será realizada mensalmente, calculada com base nos serviços realizados durante o processo de Sustentação, tendo como base suas quantificações em USTs, conforme estabelecido no “Catálogo de Serviços de Solução de Software”.

Mensalmente, a INTERESSADA deverá apresentar à MTI relatório de Sustentação por Solução de Software sustentada, discriminando todas as demandas atendidas e seus respectivos serviços, em ordem cronológica, detalhadas conforme o “Catálogo de Serviços de Solução de Software”.

Adicionalmente, o relatório de Sustentação deverá apresentar o resultado do fator de atendimento do nível de serviço apurado no mês, conforme descrito no “Anexo V - Níveis Mínimos de Serviço” do presente Modelo de Referência de Práticas de Desenvolvimento Ágil para Fábrica de Software com Parceria.

O modelo de Sustentação de Solução de Software apresentado neste documento, além de assegurar a operação em níveis normais de Soluções de Software sustentados, visa, também, estimular a melhoria contínua da qualidade dos mesmos no decorrer da parceria, estabelecendo níveis mínimos de serviço progressivos ao longo do contrato.

O pagamento dos serviços realizados para a Sustentação deve ocorrer somente após o encerramento do atendimento da demanda de Sustentação.

iii.Gerenciamento dos Serviços da OS

A INTERESSADA é responsável pelas entregas conforme as condições acordadas no momento da abertura da OS e no planejamento da Release (escopo, prazo, níveis de serviço, indicadores, dentre outros).

Caso seja uma OS de Desenvolvimento de Soluções de Software classificada como Projeto, a INTERESSADA deve considerar que as atividades gerenciais devem estar aderentes às atividades de gerenciamento projetos da MTI, contemplando gerenciamento de escopo, tempo, comunicação, qualidade, custo e risco.

Para todos os tipos de OS, a INTERESSADA deve fornecer informações a MTI, periodicamente, sobre o andamento das atividades, conforme definições e acordos estabelecidos na atividade “Preparar a Execução do Contrato”, apresentada no “ANEXO I-A – Visão Geral do Processo de Trabalho”.

iv.Controle de mudanças em OS

Durante a execução dos serviços, poderão ser identificadas necessidades de mudanças nos requisitos da OS, as quais podem afetar o escopo, custo e prazo. Somente o Dono do Produto ou Cliente Demandante poderão solicitar mudanças.

Quaisquer solicitações de mudança relativas a serviços em andamento serão previamente avaliadas quanto à sua pertinência pelo Líder da Célula. Uma vez considerada pertinente pelo Líder da Célula, a solicitação de mudança será encaminhada à INTERESSADA para avaliação do impacto sobre os serviços em execução. Caso as mudanças demandas afetem a Release corrente, esta deve ser inserida no planejamento do Backlog para ser participante da próxima versão da Solução de Software após a versão inerente a Release corrente. Somente em comum acordo entre a INTERESSADA e a MTI, a Release corrente, objeto de impacto direto da mudança solicitada, pode ser abandonada com justificativa registrada na OS, com objetivo único de minimizar perdas de ambos os lados da parceria.

A avaliação de impacto deverá ser registrada em relatório técnico, no qual deve- se destacar as alterações de custo e prazo na OS, acompanhadas das devidas justificativas.

Apenas as mudanças que forem aprovadas pelo Líder da Xxxxxx, após análise do relatório de impacto, devem ser realizadas pela INTERESSADA.

v.Cancelamento de OS

Somente o Dono do Produto ou o Cliente Demandante podem solicitar cancelamento da execução de OS. As Releases efetivamente finalizadas pela INTERESSADA até o momento do cancelamento serão devidamente entregues para processo de homologação e, após homologadas, remuneradas. A Release

corrente da OS será finalizada e remunerada com a justificativa funcional registrada pelo dono do produto.

vi.Método de quantificação dos volumes de serviços

A métrica utilizada é Unidade de Serviço Técnico (UST).

Os serviços, metrificados em UST, disponíveis para serem participantes de uma OS estão reportados na versão atualizada “Catálogo de Serviços de Solução de Software” disponibilizado no sítio da MTI.

Para as OS do tipo “Sustentação ” que possuem demandas classificada como “Incidente” ou “Solicitação”, o atendimento ocorre na demanda. Cada uma das demandas pode ser atendida por uma composição de serviços, observando a classificação prevista no “Catálogo de Serviços de Solução de Software”.

vii.Boas práticas relativas à segurança da informação durante o ciclo de desenvolvimento e sustentação

A INTERESSADA, na execução dos serviços contratados, deverá observar boas práticas relativas à segurança da informação, especialmente as indicadas nas normativas da MTI em todas as atividades executadas durante o ciclo laboram das Soluções de Software, considerando práticas referenciadas no Estado da Arte. No subprocesso “Preparar a Execução do Contrato” apresentado no “Anexo I – Processo de Trabalho”do presente Modelo de Referência de Práticas de Desenvolvimento Ágil para Fábrica de Software com Parceria, será apresentado as normativas vigentes.

Quando da validação dos artefatos/entregáveis disponibilizados pela INTERESSADA, a MTI fará verificação quanto aos requisitos de qualidade, incluindo os aspectos de segurança da informação previstos em normativas internas, legislação estadual e federal. A verificação quanto aos aspectos de segurança da informação, pode incluir avaliação técnica especializada da Solução de Software sob prerrogativa decisória da MTI.

2. COMUNICAÇÃO ENTRE MTI E INTERESSADA

A presente contratação prevê a realização de reuniões ordinárias entre a MTI e a INTERESSADA, para acompanhamento dos serviços e planejamento de ações futuras. Essas reuniões serão realizadas em intervalos não inferiores a 15 (quinze) dias, conforme periodicidade a ser definida entre as partes, na abertura da OS. A pauta de cada reunião ordinária será definida por esse profissional e comunicada com antecedência mínima de 24 (vinte e quatro) horas à INTERESSADA.

A parceria prevê ainda a realização de reuniões extraordinárias entre a MTI e a INTERESSADA, as quais, diferente das reuniões ordinárias, poderão ocorrer a qualquer tempo, sem periodicidade preestabelecida, desde que convocadas com antecedência mínima de 24 (vinte e quatro) horas. Poderá ser pauta das

reuniões extraordinárias qualquer tema que, por especialização técnica ou pela urgência no tratamento do tema, não possa aguardar ser incluído na pauta das reuniões ordinárias.

Participarão das reuniões ordinárias e extraordinárias o fiscal técnico ou gestor do contrato, o gerente de contrato da INTERESSADA, o preposto e outros atores que a MTI e a INTERESSADA julgarem importantes para tratar devidamente as questões previstas na pauta.

Nas reuniões de acompanhamento os seguintes pontos serão tratados, entre outros:

a. Avaliação dos indicadores de nível de serviço aferidos no período e ações corretivas, caso necessário;

b. Avaliação da efetividade de medidas corretivas definidas em reuniões anteriores;

c. Planejamento estimativo de volume de demandas para os próximos períodos;

d. Acompanhamento do andamento dos projetos em curso com análise de riscos;

e. Comunicação prévia da intenção de inclusão ou e retirada de Soluções de Software da Sustentação.

Compete ao gerente de contrato da INTERESSADA apresentar sugestões de medidas corretivas, sempre que necessário ao estabelecimento ou restabelecimento de níveis de serviço previsto no contrato. As propostas apresentadas serão discutidas e avaliadas pela MTI.

Ao término da reunião, a MTI elaborará ata específica com o registro dos principais assuntos tratados, as decisões tomadas e as notificações realizadas. A ata deve ser assinada pelos presentes e devidamente arquivada.

A MTI pode utilizar-se de outros mecanismos formais de comunicação com a INTERESSADA. Esses também devem ser juntados ao processo de fiscalização, para subsidiar a gestão do contrato.

3. GARANTIA DOS SERVIÇOS

Os serviços de Desenvolvimento e Manutenção de Soluções de Software previstos terão com garantia de 180(cento e oitenta) dias contados da emissão do respectivo termo de recebimento definitivo.

Caso seja detectado erro em produção, do produto elaborado pela INTERESSADA e ainda em garantia, cabe a esta corrigir nos mesmos prazos definidos para o restabelecimento do serviço de demandas do tipo “incidente” prevista para OS de Sustentação, independentemente da Solução de Software encontrar-se em regime de Sustentação.

No caso de erro detectado nos últimos 60 (sessenta) dias da garantia, essa será prorrogada, de modo que o novo término da garantia do sistema se dê 60 (sessenta) dias após a implantação da correção do erro em produção.

É facultado à MTI, em situações excepcionais ou emergenciais, realizar intervenções em código produzido ou mantido sob gestão da MTI ou de unidade do Setor Público. Nestes casos, somente os arquivos fontes alterados perderão a garantia.

A abertura de OS de Manutenção para que a INTERESSADA realize de forma definitiva as alterações executadas em caráter excepcional pela MTI, restabelece a garantia dos arquivos fontes alterados ou impactados por novos 180(cento e oitenta) dias.

4. NÍVEIS MÍNIMOS DE SERVIÇO

A presente contratação possui mecanismos que possibilitam à MTI remunerar o fornecedor na medida do cumprimento dos níveis de serviço, de forma a assegurar que os pagamentos sejam vinculados aos resultados entregues.

Para cada entrega participante da OS, será calculado o fator de cumprimento do nível de serviço. O “Anexo V - Níveis Mínimos de Serviço” do presente Modelo de Referência de Práticas de Desenvolvimento Ágil para Fábrica de Software com Parceria apresenta os indicadores mínimos de nível de serviço a serem observados para cada entrega de produto participante da OS. Indicadores acima dos mínimos estabelecidos pode ser pactuado em função de comprovação técnica atestada e apresentada pela INTERESSADA

O alcance do nível mínimo de serviço estabelecido na PARCERIA terá fator de cumprimento estabelecido no “Anexo V - Níveis Mínimos de Serviço”do presente Modelo de Referência de Práticas de Desenvolvimento Ágil para Fábrica de Software com Parceria. Caso não seja atingido, serão aplicadas glosas, também definidas no mesmo anexo.

a. Cálculo da remuneração esperada por OS

Cálculo para OS de “Criação de Construção de Visão do Produto” e OS “Desenvolvimento de Software” classificada como “Projeto”: Será calculado somente após a conclusão da OS, e deve ser realizada soma das UST de cada serviço entregues na OS, conforme estabelecido no “Catálogo de Serviços de Solução de Software”.

Cálculo para OS de “Desenvolvimento de Software” classificada como “Projeto”: Será calculado após a entrega de cada release e deve ser realizada soma das UST de cada serviço entregues na release, conforme o “Catálogo de Serviços de Solução de Software”.

Cálculo para OS de “Sustentação”: Será calculado após o fechamento de cada Demanda da solução sustentada e deve ser realizada soma das UST de cada serviço realizado para o atendimento da Demanda, conforme o “Catálogo de Serviços de Solução de Software”.

Para os casos de cancelamento de OS, será considerado a soma das UST(s) dos serviços concluídos, conforme estabelecido no “Catálogo de Serviços de Solução de Software”.

b. Cálculo do valor final da OS, após aplicação do fator de atendimento do nível de serviço

Cada OS ou parcela remunerável de OS concluída, deve ser relacionada no relatório mensal de faturamento, acompanhada dos indicadores relativos ao nível de serviço observado durante a execução dos serviços.

Para cada OS, com base nos indicadores de nível de serviço observados, será calculado o fator de cumprimento do nível de serviço, conforme especificado no “Anexo V - Níveis Mínimos de Serviço”do presente Modelo de Referência de Práticas de Desenvolvimento Ágil para Fábrica de Software com Parceria. O valor final a ser pago pela OS será multiplicado pelo fator de cumprimento do nível de serviço.

c. Fluxo de Pagamento Mensal

O pagamento à INTERESSADA será mensal:

● Para a OS do tipo “Desenvolvimento de Software” e classificada como “Projeto” o pagamento terá por base a OS ou Releases concluídos;

● Para a OS do tipo “Desenvolvimento de Solução de Software” e classificada como “Manutenção” o pagamento terá por base a OS concluída;

● Para a OS do tipo “Sustentação” o pagamento terá por base os serviços realizados, conforme estabelecido no “Catálogo de Serviços de Solução de Software”.

Os pagamentos mensais serão realizados após recebimento definitivo dentro do período de aferição. O período de aferição corresponde ao intervalo entre o 1º e o último dia do mês.

Mensalmente, em no máximo cinco dias úteis a contar do encerramento do período de aferição, a INTERESSADA deverá apresentar o Relatório de Fechamento, relacionando a OS ou parcela remunerável da OS, com termo de recebimento definitivo no período de aferição. Para cada OS ou parcela, deverão ser indicados os níveis de serviço aferidos e os valores de remuneração calculados conforme previsto no contrato.

A MTI tem prazo de 05 (cinco dias) úteis, contados do recebimento, para analisar e aprovar o relatório de fechamento entregue pela INTERESSADA, bem como verificar o nível de serviço alcançado na execução da (s) OS(s).

No caso de divergência nos valores apresentados no relatório, a MTI juntamente com o Cliente discutirá com a INTERESSADA as correções necessárias e

solicitará emissão de novo relatório de fechamento. A cada reapresentação do relatório, a MTI terá novo prazo de cinco dias úteis para analisá-lo.

A nota fiscal/fatura deverá ser emitida após aprovação do relatório de fechamento mensal por parte da MTI e deverá conter apenas os serviços efetivamente concluídos e recebidos definitivamente pela mesma. O ateste da nota fiscal/fatura, para efeito de pagamento somente será feito após confrontação dos dados constantes da nota fiscal/fatura com os do referido relatório.

As condições referentes à liquidação e ao pagamento estão descritas em cláusula contratual específica.

5. PERFIS PROFISSIONAIS E QUALIFICAÇÃO MÍNIMA

Para a execução das atividades-chave previstas no contrato, a INTERESSADA deverá designar profissionais de acordo com os perfis e qualificações especificados no documento denominado “Anexo VIII- Perfil Profissional”do presente Modelo de Referência de Práticas de Desenvolvimento Ágil para Fábrica de Software com Parceria disponibilizado no sítio da MTI.

A designação destes profissionais deve ocorrer no momento da formação ou ampliação das células, ou ainda na substituição de profissionais.

Por seguir orientação majoritariamente de práticas ágeis, esta modelo de referência não transforma funções do desenvolvimento de solução de software em cargos. Um colaborador pode acumular diversos papéis. Nesse caso, deve apresentar comprovação técnica para os papéis que atuará. Quando o perfil é subdividido em grupos, pode-se adotar um ou outro. O que difere um grupo de outro é a comprovação relacionada ao conhecimento técnico e tempo de experiência laboral.

a. Ferramentas necessárias exigidas da INTERESSADA

As ferramentas necessárias tanto para o apoio ao desenvolvimento como para a gestão do processo, são descritas no “Anexo III - Características das Ferramentas Técnicas e de Gestão”.

6. TRANSFERÊNCIA DE CONHECIMENTO E TRANSIÇÃO CONTRATUAL

A título de repasse de conhecimentos acerca dos serviços executados, a INTERESSADA deve, ao término de cada OS, repassar todos os documentos produzidos e gerados no contexto da sua execução, incluindo códigos-fonte, documentação de programas, diagramas e especificações, devidamente atualizados de acordo com os serviços executados na OS.

A INTERESSADA também deve, conforme previsto no fluxo de trabalho, discutir previamente com a equipe técnica da MTI, qualquer nova solução arquitetural que venha a ser adotada nos serviços desenvolvidos.

Quando solicitado pela MTI, a INTERESSADA deve fornecer esclarecimentos complementares acerca das soluções desenvolvidas, com a participação dos profissionais envolvidos na definição e desenvolvimento da solução.

A INTERESSADA deve promover transição contratual e repassar para o MTI e/ou para outra empresa por este indicada todos os dados, documentos e elementos de informação utilizados na execução dos serviços.

Com vistas a mitigar riscos de descontinuidade de serviços e de dependência técnica, a INTERESSADA deve habilitar equipe de técnicos da MTI ou outra por ele indicada no uso das soluções desenvolvidas e implantadas no escopo do contrato, repassando todo o conhecimento necessário para tal.

A critério da MTI, poderá ser alocado servidor para acompanhar as atividades de levantamento de requisitos realizadas pela INTERESSADA, tendo em vista a preservação do conhecimento do negócio relativo à aplicação que está sendo desenvolvida.

7. Instrumentos de Solicitação, Acompanhamento e Avaliação dos Serviços

Será utilizado o instrumento de OS Ordem de serviço, como ferramenta de demanda à INTERESSADA. No “Anexo IV - Modelos de Ordem de Serviço” do presente Modelo de Referência de Práticas de Desenvolvimento Ágil para Fábrica de Software com Parceria são apresentados modelos com as informações mínimas que devem compor esse documento de formalização, podendo ser acordados novos modelos entre a MTI e a INTERESSADA.

Conforme detalhado anteriormente, no presente modelo estão previstos três tipos de OS. Cada tipo de OS possui fluxo de trabalho próprio, detalhados no Anexo I - Processo de Trabalho do presente Modelo de Referência de Práticas de Desenvolvimento Ágil para Fábrica de Software com Parceria.

Toda entrega realizada pela INTERESSADA no contexto da execução de uma OS será entregue a MTI que o receberá provisoriamente e submeterá a avaliação conforme requisitos de qualidade técnica definidos no início da execução da parceria conforme subprocesso “Preparar a execução do contrato” apresentado no “Anexo I - Processo de Trabalho”. Também deve ser definido os prazos para esta verificação de qualidade.

O resultado da avaliação deve ser disponibilizado para a INTERESSADA por meio de Laudo Técnico. No laudo serão registrados defeitos encontrados, rejeites, aceites com ressalvas e aceites.

A ocorrência de defeitos que comprometam o entendimento de artefato/entregável implicará rejeite do mesmo. Todo rejeite de artefato/entregável será contabilizado para fins de determinação do nível de serviço observado na execução da OS.

A critério da MTI, a ocorrência de defeitos pontuais que não comprometam o entendimento do artefato/entregável pode ensejar o aceite com ressalvas. Nesse caso, a INTERESSADA deverá sanar os defeitos registrados e reapresentar o artefato/entregável à MTI.

Artefatos/entregáveis sem identificação de defeitos serão considerados aceitos, ou seja, artefatos/entregáveis com aceite com ressalvas não corrigidos no prazo acordado ou reapresentados sem que todos os defeitos tenham sido corrigidos, serão considerados rejeitados.

Em caso de rejeite de artefato/entregável, a INTERESSADA deverá fazer as correções cabíveis e reapresentar novamente provisoriamente.

O tempo consumido com correção de artefatos/entregáveis rejeitados deve compor o tempo total de execução dos serviços para fins de aferição do prazo de execução da OS. O tempo consumido nas avaliações das entregas pela MTI não deve ser computado para fins de aferição do nível de serviço.

Aceitos todas as entregas realizadas, e ainda, quando aplicável, após a conclusão da homologação, sem que restem defeitos sem correção, a entrega será considerada de definitiva.

Os instrumentos de solicitação, acompanhamento e avaliação dos serviços previstos nesta seção devem presencialmente serem realizado por meio de ferramenta de gestão, conforme previsto no “Anexo III - Características das Ferramentas Técnicas e de Gestão” do presente Modelo de Referência de Práticas de Desenvolvimento Ágil para Fábrica de Software com Parceria.