PREGÃO ELETRÔNICO Nº 09/2018

PREGÃO ELETRÔNICO Nº 09/2018

CONSELHO DE ARQUITETURA E URBANISMO DO BRASIL – CAU/BR

(Processo Administrativo n.º 211/2018)

O CONSELHO DE ARQUITETURA E URBANISMO DO BRASIL – CAU/BR, por

intermédio de seu pregoeiro e equipe de apoio, designados pela Portaria PRES nº 223, de 29 de junho de 2018, torna público e faz comunicar aos que interessar possa que realizará licitação na modalidade PREGÃO ELETRÔNICO, do tipo MENOR PREÇO GLOBAL. O procedimento licitatório obedecerá à Lei nº 10.520, de 2002; ao Decreto nº 3.555, de 2000; ao Decreto nº 5.450, de 2005 e, subsidiariamente, à Lei nº 8.666, de 1993; assim como à legislação correlata, e demais exigências previstas neste edital e em seus anexos.

Data da sessão: 11 de dezembro de 2018

Horário: 10h00 (Horário de Brasília – DF)

Local: Portal de Compras do Governo Federal – xxx.xxxxxxxxxx.xxx.xx

CAPÍTULO 1. DO OBJETO

1.1. Contratação de empresa para prestação de serviços de Tecnologia da Informação para atender às necessidades do Conselho de Arquitetura e Urbanismo do Brasil – CAU/BR, de acordo com as especificações, padrões técnicos de desempenho e qualidade estabelecidos no Termo de Referência, contemplando as atividades de projeto, sustentação, serviço e documentação de sistemas de informação, na modalidade Fábrica de Software (FSW), baseado nas práticas e princípios das “metodologias ágeis”, mediante ordens de serviço dimensionados pela métrica de ponto de função, bem como transferência de conhecimento e consultoria em TI, dimensionados pela métrica de Unidades de Serviço Técnico – UST.

1.2. O objeto de contratação consiste na prestação de serviços de projeto (desenvolvimento e melhorias), manutenção (manutenção evolutiva, manutenção perfectiva, manutenção adaptativa, manutenção de interface e manutenção corretiva), documentação, serviços de sistema de informação na modalidade Fábrica de Software, transferência de conhecimento e consultoria em TI.

CAPÍTULO 2. DAS INFORMAÇÕES PRELIMINARES

2.1. O inteiro teor deste edital poderá ser obtido gratuitamente no sítio eletrônico do Conselho de Arquitetura e Urbanismo do Brasil (CAU/BR), xxx.xxxxx.xxx.xx, ou solicitado ao pregoeiro ou equipe de apoio na sede do Conselho, com endereço no XXX X. 00, Xxxxx X, Xx. Xxxxx Xxxxxxx, Xxxxx 000 x 000, Xxx Xxx, Xxxxxxxx/XX, no horário de 9h00 às 12h00 e das 14h00 às 17h00, mediante pagamento pelas cópias reprográficas.

2.2. Se por qualquer motivo não houver expediente no CAU/BR no dia agendado para abertura da sessão pública, esta ficará automaticamente transferida para o primeiro dia útil seguinte, no mesmo horário, independente de comunicação.

2.3. Das decisões do pregoeiro dar-se-á publicidade no sítio eletrônico do CAU/BR, salvo em relação àquelas cuja publicação e ciência puderem ser feitas diretamente aos licitantes participantes da sessão pública, principalmente, quanto ao resultado de:

2.3.1. Julgamento da licitação;

2.3.2. Recursos porventura interpostos.

2.4. Os esclarecimentos e decisões quanto à impugnação e recursos serão divulgados no sítio eletrônico do CAU/BR, xxx.xxxxx.xxx.xx, quando houver impossibilidade de fazê-lo no Comprasnet.

2.5. A participação na licitação, sem que tenha sido tempestivamente impugnado o edital importa em total e irrestrito conhecimento e aceitação das condições estatuídas, ou seja, de que os elementos são suficientes, claros e precisos, não cabendo, portanto, posterior reclamação.

2.6. Os licitantes deverão observar o disposto no subitem 2.3, sob pena de arcar com os prejuízos decorrentes da inobservância das publicações oficiais.

2.7. O Termo de Referência é parte integrante deste edital, como se transcrito estivesse.

CAPÍTULO 3. DOS RECURSOS ORÇAMENTÁRIOS

3.1. As despesas para atender a esta licitação estão programadas em dotação orçamentária própria, prevista no orçamento do Conselho de Arquitetura e Urbanismo do Brasil (CAU/BR), a saber:

Centro de Custos: 4.02.08.005 – Gestão da Coordenadoria Técnica do SICCAU – CORTEC

Conta: 6.2.2.1.1.01.04.03.002 – SICCAU;

Conta: 6.2.2.1.1.02.01.03.010 – Serviços de Desenvolvimento de Sistemas.

CAPÍTULO 4. DO CREDENCIAMENTO

4.1. O credenciamento é o nível básico do registro cadastral no SICAF, que permite a participação dos interessados na modalidade licitatória pregão, em sua forma eletrônica.

4.2. O cadastro no SICAF poderá ser iniciado no Portal de Compras do Governo Federal, no sítio xxx.xxxxxxxxxxxxxxxxxxxxx.xxx.xx, com a solicitação de login e senha pelo interessado.

4.3. O credenciamento junto ao provedor do sistema implica a responsabilidade do licitante ou de seu representante legal e a presunção de sua capacidade técnica para realização das transações inerentes a este pregão.

4.4. O uso da senha de acesso pelo licitante é de sua responsabilidade exclusiva, incluindo qualquer transação efetuada diretamente ou por seu representante, não cabendo ao provedor do sistema, ou ao órgão ou entidade responsável por esta licitação, responsabilidade por eventuais danos decorrentes de uso indevido da senha, ainda que por terceiros.

4.5. A perda da senha ou a quebra de sigilo deverão ser comunicadas imediatamente ao provedor do sistema para imediato bloqueio de acesso.

CAPÍTULO 5. DAS CONDIÇÕES DE PARTICIPAÇÃO NO PREGÃO.

5.1. Poderão participar da licitação os interessados que estiverem previamente credenciados no Sistema de Cadastramento Unificado de Fornecedores (SICAF) e perante o sistema eletrônico provido pela Secretaria de Logística e Tecnologia da Informação do Ministério do Planejamento, Orçamento e Gestão (SLTI), por meio do sítio xxx.xxxxxxxxxx.xxx.xx, atendidas as demais exigências do edital.

5.2. Para ter acesso ao sistema eletrônico, os interessados em participar deste pregão deverão dispor de chave de identificação e senha pessoal, obtidas junto à SLTI, onde

também deverão informar-se a respeito do seu funcionamento e regulamento e receber instruções detalhadas para sua correta utilização.

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

5.4. Não poderão participar desta licitação os interessados:

5.4.1. Suspensos de participar de licitação e impedidos de contratar com o CAU/BR, durante o prazo da sanção aplicada;

5.4.2. Declarados inidôneos para licitar ou contratar com a Administração Pública, enquanto perdurarem os motivos determinantes da punição ou até que seja promovida sua reabilitação;

5.4.3. Impedidos de licitar e contratar com a União, durante o prazo da sanção aplicada;

5.4.4. Sociedade estrangeira não autorizada a funcionar no País;

5.4.5. Pessoa Jurídica cujo estatuto ou contrato social não inclua o objeto deste pregão;

5.4.6. Que se encontrem em processo de dissolução, recuperação judicial;

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

5.4.8. Dirigentes, conselheiros e colaboradores do CAU/BR, inclusive familiares, na forma prevista no art. 7º do Decreto nº 7.203, de 2010;

5.4.9. Consórcio de empresa, qualquer que seja sua forma de constituição.

5.5. As demais condições para participação neste certame licitatório estão consignadas no Termo de Referência, Anexo I deste edital.

CAPÍTULO 6. DO ENVIO DA PROPOSTA

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

6.2. Todas as referências de tempo no edital, no aviso e durante a sessão pública observarão o horário de Brasília (DF).

6.3. O licitante será responsável por todas as transações que forem efetuadas em seu nome no sistema eletrônico, assumindo como firmes e verdadeiras suas propostas e lances.

6.4. Incumbirá ao licitante acompanhar as operações no sistema eletrônico durante a sessão pública do pregão, ficando responsável pelo ônus decorrente da perda de negócios, diante da inobservância de quaisquer mensagens emitidas pelo sistema ou de sua desconexão.

6.5. O licitante deverá consignar, na forma expressa no sistema eletrônico, o valor global da proposta, já considerados e inclusos todos custos operacionais, encargos previdenciários, trabalhistas, tributários, comerciais, fretes e quaisquer outros que incidam direta ou indiretamente na aquisição dos produtos e/ou prestação de serviços.

6.5.1. A CONTRATADA deverá arcar com o ônus decorrente de eventual equívoco no dimensionamento dos quantitativos de sua proposta, caso o previsto não seja satisfatório

para o atendimento do objeto da licitação, exceto quando ocorrer algum dos eventos arrolados nos incisos do §1° do artigo 57 da Lei n° 8.666, de 1993.

6.5.2. O licitante deverá declarar em campo próprio do Sistema, a descrição do produto ofertado.

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

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

6.5.5. O licitante enquadrado como microempresa ou empresa de pequeno porte deverá declarar, em campo próprio do Sistema, que atende aos requisitos do art. 3º da Lei Complementar nº 123, de 2006, para fazer jus aos benefícios previstos nesta Lei.

6.5.6. Em se tratando de Microempreendedor Individual – MEI, o licitante deverá incluir, no campo das condições da proposta do sistema eletrônico, o valor correspondente à contribuição prevista no art. 18-B da Lei Complementar n. 123, de 2006.

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

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

6.6.1.Qualquer elemento que possa identificar o licitante importa desclassificação da proposta, sem prejuízo das sanções previstas neste edital.

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

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

6.7.1.Decorrido o prazo de validade das propostas, sem convocação para contratação, ficam os licitantes liberados dos compromissos assumidos. Todas as especificações do objeto contidas na proposta vinculam a CONTRATADA.

CAPÍTULO 7. DA ABERTURA DA SESSÃO PÚBLICA

7.1. A abertura da sessão pública deste pregão, conduzida pelo pregoeiro, ocorrerá na data e na hora indicadas no preâmbulo deste edital, no sítio eletrônico xxx.xxxxxxxxxx.xxx.xx.

7.1.1. Durante a sessão pública, a comunicação entre o pregoeiro e os licitantes ocorrerá exclusivamente mediante troca de mensagens, em campo próprio do sistema eletrônico.

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

CAPÍTULO 8. DA CLASSIFICAÇÃO DAS PROPOSTAS

8.1. O pregoeiro verificará as propostas apresentadas e desclassificará, desde logo e motivadamente, aquelas que não estejam em conformidade com os requisitos estabelecidos neste edital ou contenham vícios insanáveis ou ilegalidades.

8.2. A desclassificação será sempre fundamentada e registrada no sistema, com acompanhamento em tempo real por todos os participantes.

8.3. A não desclassificação da proposta não impede o seu julgamento definitivo em sentido contrário, levado a efeito na fase de aceitação.

8.4. O sistema ordenará automaticamente as propostas classificadas, sendo que somente estas participarão da fase de lances.

CAPÍTULO 9. DA FORMULAÇÃO DE LANCES

9.1. Iniciada a etapa competitiva, os licitantes classificados poderão encaminhar lances sucessivos, exclusivamente por meio do sistema eletrônico, sendo imediatamente informados do horário e valor consignados no registro de cada lance.

9.1.1. O lance ofertado deverá ser referente ao valor global do contrato.

9.2. O licitante somente poderá oferecer lance inferior ao último por ele ofertado e registrado no sistema.

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

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

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

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

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

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

9.9. O encerramento da etapa de lances será decidido pelo pregoeiro, que informará, com antecedência de 1 (um) a 60 (sessenta) minutos, o prazo para início do tempo de iminência.

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

9.11. Após a fase de lances, em atendimento ao disposto no artigo 44 da Lei Complementar nº 123/06, que assegura preferência de contratação como critério de desempate técnico, caso a proposta mais bem classificada não tenha sido ofertada por microempresa ou empresa de pequeno porte e houver proposta apresentada por microempresa ou empresa de pequeno porte igual ou até 5% (cinco por cento) superior à proposta de menor preço, proceder-se-á da seguinte forma:

9.11.1. A microempresa ou a empresa de pequeno porte mais bem classificada poderá, no prazo de 5 (cinco) minutos, que se iniciará após a fase de lances, apresentar uma última oferta, necessariamente inferior àquela apresentada pela primeira colocada, situação em que, atendidas as exigências habilitatórias, será adjudicado em seu favor o objeto deste pregão;

9.11.2. Não ocorrendo a contratação da microempresa ou empresa de pequeno porte, na forma determinada anteriormente, serão convocadas as remanescentes que porventura se enquadrem na hipótese de microempresas e empresas de pequeno porte, na ordem classificatória, para o exercício do mesmo direito;

9.11.3. No caso de equivalência dos valores apresentados pelas microempresas e empresas de pequeno porte, será realizado sorteio entre elas para que se identifique aquela que primeiro poderá apresentar melhor oferta.

9.11.4. Na hipótese da não contratação nos termos do subitem 9.11, o objeto licitado será adjudicado em favor da proposta originalmente vencedora do certame.

CAPÍTULO 10. DA NEGOCIAÇÃO

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

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

CAPÍTULO 11. DA ACEITABILIDADE DA PROPOSTA VENCEDORA

11.1. Encerrada a etapa de lances e depois da verificação de possível empate, o Pregoeiro examinará a proposta classificada em primeiro lugar quanto ao preço, a sua exequibilidade, bem como quanto ao cumprimento das especificações do objeto.

11.2. O licitante classificado provisoriamente em primeiro lugar deverá encaminhar a proposta de preços adequada ao último lance, acompanhada da planilha de preços (conforme modelo apresentado no Encarte H do Termo de Referência), observadas as demais condições relacionadas no Termo de Referência, Anexo I deste edital, no prazo de 3 (três) horas, contado da convocação efetuada pelo pregoeiro por meio da opção “Enviar Anexo” no sistema Comprasnet.

11.2.1. A partir da solicitação do pregoeiro no sistema eletrônico, relativa ao envio de documentos de habilitação complementares, poderá ser usado (caso não seja possível enviá-los pelo sistema Comprasnet), preferencialmente, o endereço eletrônico xxxxxxxxx@xxxxx.xxx.xx, ou outros meios, conforme Instrução Normativa nº 1, de 26 de março de 2014, da Secretária de Logística e Tecnologia da Informação do MPOG.

11.3. Os documentos remetidos por meio da opção “Enviar Anexo” do sistema Comprasnet poderão ser solicitados em original ou por cópia autenticada a qualquer momento, os quais deverão ser entregues no prazo máximo de 5 (cinco) dias, na sede do CAU/BR, conforme subitem 11.3.2.

11.3.1. O prazo para a entrega dos documentos poderá ser prorrogado uma única vez, por igual período, quando solicitado pelo licitante vencedor durante o seu transcurso, desde que ocorra motivo justificado e aceito pelo pregoeiro.

11.3.2. Os originais ou cópias autenticadas, caso sejam solicitados, deverão ser encaminhados ao Setor de Compras do CAU/BR, situado no Setor Comercial Sul, Quadra 2, Bloco C, Entrada 22, Ed. Serra Dourada, Salas 401 a 409, XXX 00.000-000, Brasília (DF).

11.4. O licitante que abandonar o certame, deixando de enviar a documentação indicada nesta seção, será desclassificado e sujeitar-se-á às sanções previstas neste edital e no Termo de Referência.

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

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

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

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

11.9. Não serão aceitas propostas com valores unitários e global superiores aos estimados ou com preços manifestamente inexequíveis.

11.9.1. Se houver indícios de inexequibilidade da proposta de preço, ou em caso da necessidade de esclarecimentos complementares, poderão ser efetuadas diligências, na forma do § 3° do artigo 43 da Lei n° 8.666, de 1993, a exemplo das enumeradas no item

9.4 do Anexo VII-A, da SEGES/MPDG IN. 5, de 2017.

11.9.2. Caso o licitante classificado provisoriamente em primeiro lugar apresente preço inferior a 70% (sessenta por cento) do preço estimado pelo CAU/BR, o licitante deverá apresentar planilha própria de composição de custos detalhada a fim de comprovar a exequibilidade, bem como apresentar demonstrativo analítico de todos os custos e receitas envolvidas na execução contratual, identificando inclusive as remunerações e encargos de pessoal estimados a serem pagos conforme cada perfil profissional, considerando o nível de senioridade e tempo de experiência exigidos no item 11.6 do Termo de Referência.

11.10. O CAU/BR poderá realizar diligências objetivando comprovar a veracidade das informações prestadas pelo licitante. Caso fique caracterizada atitude inidônea do licitante, esse estará sujeito às penalidades previstas em lei.

11.11. Se a proposta ou lance vencedor for desclassificado, o Pregoeiro examinará a proposta ou lance subsequente, e, assim sucessivamente, na ordem de classificação.

11.11.1. Também nas hipóteses em que o Pregoeiro não aceitar a proposta e passar à subsequente, poderá negociar com o licitante para que seja obtido preço melhor.

11.12. Havendo necessidade, o Pregoeiro suspenderá a sessão, informando no “chat” a nova data e horário para a continuidade da mesma.

CAPÍTULO 12. DA HABILITAÇÃO

12.1. As disposições inerentes à habilitação (Qualificação Técnica; Qualificação econômico-financeira; Regularidade fiscal e trabalhista; Declarações e Habilitação Jurídica) constam do Capítulo 11 do Termo de Referência, Anexo I deste edital, e demais disposições aplicáveis.

CAPÍTULO 13. DA REABERTURA DA SESSÃO PÚBLICA

13.1. A sessão pública poderá ser reaberta:

13.1.1. Nas hipóteses de provimento de recurso que leve à anulação de atos anteriores à realização da sessão pública precedente ou em que seja anulada a própria sessão pública, situação em que serão repetidos os atos anulados e os que dele dependam.

13.1.2. Quando houver erro na aceitação do preço melhor classificado ou quando o licitante declarado vencedor não assinar o contrato, não retirar o instrumento equivalente ou não comprovar a regularização fiscal, nos termos do art. 43, §1º da LC nº 123/2006. Nessas hipóteses, serão adotados os procedimentos imediatamente posteriores ao encerramento da etapa de lances.

13.2. Todos os licitantes remanescentes deverão ser convocados para acompanhar a sessão reaberta.

13.2.1. A convocação se dará por meio do sistema eletrônico (“chat”) e do sítio oficial deste Conselho.

CAPÍTULO 14. DOS RECURSOS

14.1. Declarado o vencedor, o pregoeiro abrirá prazo de 30 minutos, durante o qual qualquer licitante poderá, de forma imediata e motivada, em campo próprio do sistema, manifestar sua intenção de recurso.

14.1.1. A falta de manifestação no prazo estabelecido autoriza o pregoeiro a adjudicar o objeto ao licitante vencedor.

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

14.1.2.1. Nesse momento o Pregoeiro não adentrará no mérito recursal, mas apenas verificará a presença dos pressupostos recursais.

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

14.1.4. Para efeito do disposto no art. 109, § 5º da Lei nº 8.666, de 1993, fica a vista do respectivo processo administrativo franqueada aos interessados.

14.2. As intenções de recurso não admitidas e os recursos rejeitados pelo pregoeiro serão apreciados pelo Presidente do CAU/BR.

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

CAPÍTULO 15. DA ADJUDICAÇÃO E HOMOLOGAÇÃO

15.1. O objeto deste pregão será adjudicado ao licitante declarado vencedor, por ato do Pregoeiro, salvo quando houver interposição de recurso, hipótese em que a adjudicação caberá à autoridade competente para homologação, após a regular decisão dos recursos apresentados.

15.2. A homologação do pregão compete ao Presidente do CAU/BR.

15.3. O objeto do pregão será adjudicado globalmente ao licitante vencedor.

CAPÍTULO 16. DA IMPUGNAÇÃO AO EDITAL E DO PEDIDO DE ESCLARECIMENTO

16.1. Até 02 (dois) dias úteis antes da data designada para a abertura da sessão pública, qualquer pessoa física ou jurídica, poderá impugnar o ato convocatório deste pregão mediante petição a ser enviada exclusivamente para o endereço eletrônico xxxxxxxxx@xxxxx.xxx.xx.

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

16.3. Acolhida a impugnação, será definida e publicada nova data para a realização do certame, exceto quando, inquestionavelmente, a alteração não afetar a formulação das propostas.

16.4. Os pedidos de esclarecimentos referentes a este processo licitatório deverão ser enviados ao Pregoeiro, até 03 (três) dias úteis anteriores à data designada para abertura da sessão pública, exclusivamente para o endereço eletrônico xxxxxxxxx@xxxxx.xxx.xx.

16.5. As impugnações e pedidos de esclarecimentos não suspendem os prazos previstos no certame.

16.6. As respostas às impugnações e os esclarecimentos prestados pelo Pregoeiro serão disponibilizados no sistema eletrônico e entranhados nos autos do processo licitatório, permanecendo disponíveis para consulta por qualquer interessado.

CAPÍTULO 17. DO INSTRUMENTO CONTRATUAL

17.1. Após a homologação do resultado do pregão, o licitante vencedor será convocado para assinatura do contrato, dentro do prazo de 5 (cinco) dias úteis, sob pena de decair o direito à contratação, para assinar o contrato, sem prejuízo das sanções previstas neste edital e anexos.

17.1.1. O prazo para assinatura do contrato poderá, em situação excepcionalíssima, ser prorrogado uma única vez, por igual período, quando solicitado pela licitante vencedora em até 48h (quarenta e oito horas), a contar do recebimento da comunicação, desde que ocorra motivo relevante e aceito pelo CAU/BR.

17.2. Previamente à contratação, a Administração realizará consulta “online” ao SICAF, cujo resultado será anexado aos autos do processo.

17.2.1. Na hipótese de irregularidade do registro no SICAF, o contratado deverá regularizar a sua situação perante o cadastro no prazo de até 05 (cinco) dias úteis, sob pena de aplicação das penalidades previstas no edital e anexos.

17.3. Na celebração do contrato serão exigidas as mesmas condições de habilitação.

17.4. Alternativamente à convocação para comparecer perante o órgão ou entidade para a assinatura do contrato, a Administração poderá encaminhá-lo para assinatura, mediante correspondência postal com aviso de recebimento (AR) ou meio eletrônico, para que seja assinado no prazo de 05 (cinco) dias corridos, a contar da data de seu recebimento.

17.5. O prazo previsto para assinatura ou aceite poderá ser prorrogado, por igual período, por solicitação justificada do adjudicatário e aceita pela Administração.

17.6. A vigência do contrato será de 12 (doze) meses e terá início na data da sua assinatura, podendo se estender por até 60 (sessenta) meses, nos termos do art. 57, II, da Lei 8.666, de 1993.

17.7. Pela inexecução total ou parcial do contrato poderá ser aplicada à CONTRATADA as sanções de que tratam os arts. 86 a 88 da Lei nº 8.666/1993, garantidos o contraditório e a ampla defesa, bem como as sanções e penalidades previstas neste Termo de Referência.

CAPÍTULO 18. DO ACOMPANHAMENTO E FISCALIZAÇÃO

18.1. Os critérios de acompanhamento e de fiscalização do contrato estão previstos no Capítulo 9 do Termo de Referência, Anexo I deste edital.

CAPÍTULO 19. DAS OBRIGAÇÕES DO CONTRATANTE E DA CONTRATADA

19.1. As obrigações do CONTRATANTE e da CONTRATADA são as estabelecidas nos Capítulos 12 e 13 do Termo de Referência, Anexo I deste edital.

CAPÍTULO 20. DO PAGAMENTO

20.1. O pagamento será efetuado pelo CONTRATANTE segundo as condições estabelecidas no Capítulo 18 do Termo de Referência, Anexo I deste edital.

CAPÍTULO 21. DAS SANÇÕES ADMINISTRATIVAS

21.1. Conforme disposto no art. 28 do Decreto nº 5.450/2005, aquele que, convocado dentro do prazo de validade de sua proposta, não assinar o contrato ou ata de registro de preços, deixar de entregar documentação exigida no edital, apresentar documentação falsa, ensejar o retardamento da execução de seu objeto, não mantiver a proposta, falhar ou fraudar na execução do contrato, comportar-se de modo inidôneo, fizer declaração falsa ou cometer fraude fiscal, garantido o direito à ampla defesa, ficará impedido de licitar e de contratar com a União, e será descredenciado no SICAF, pelo prazo de até 05 (cinco) anos, sem prejuízo das multas previstas neste Edital e das demais cominações legais.

21.2. Além do previsto no item anterior, as sanções por atos praticados no decorrer da contratação estão previstas Termo de Referência, anexo integrante e inseparável do presente Edital.

CAPÍTULO 22. DAS DISPOSIÇÕES GERAIS

22.1. Ao Presidente do CAU/BR compete anular este pregão por ilegalidade, de ofício ou por provocação de qualquer pessoa, e revogar o certame por considerá-lo inoportuno ou inconveniente diante de fato superveniente, mediante ato escrito e fundamentado.

22.2. A anulação do pregão induz à do contrato.

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

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

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

22.5. Caso os prazos definidos neste edital não estejam expressamente indicados na proposta, eles serão considerados como aceitos no julgamento do pregão.

22.6. Os documentos eletrônicos produzidos com a utilização de processo de certificação disponibilizada pela ICP-Brasil, nos termos da Medida Provisória nº 2.200-2, de 24 de agosto de 2001, serão recebidos e presumidos verdadeiros em relação aos signatários, dispensando-se o envio de documentos originais e cópias autenticadas em papel.

22.7. Aplicam-se às cooperativas enquadradas na situação do art. 34 da Lei nº 11.488, de 15 de junho de 2007, todas as disposições relativas às microempresas e empresas de pequeno porte.

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

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

22.10. A homologação do resultado desta licitação não implicará direito à contratação.

22.11. Os licitantes assumem todos os custos de preparação e apresentação de suas propostas e a Administração não será, em nenhum caso, responsável por esses custos, independentemente da condução ou do resultado do processo licitatório.

22.12. 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 no CAU/BR.

22.13. O desatendimento de exigências formais não essenciais não importará o afastamento do licitante, desde que seja possível o aproveitamento do ato, observados os princípios da isonomia e do interesse público.

22.14. Em caso de divergência entre disposições deste edital e de seus anexos ou demais peças que compõem o processo, prevalecerá as deste edital.

22.15. Integram este edital, para todos os fins e efeitos, os seguintes anexos:

22.15.1. ANEXO I – Encarte A (Termo de Referência) ao Encarte L;

22.15.2. XXXXX XX – Modelo de declaração de habilitação (poderá ser substituída pela declaração de mesmo teor, extraída do Sistema Eletrônico);

22.15.3. XXXXX XXX – Modelo de declaração de trabalho do menor (poderá ser substituída pela declaração de mesmo teor, extraída do Sistema Eletrônico);

22.15.4. XXXXX XX – Modelo de declaração de idoneidade;

22.15.5. ANEXO V – Modelo de declaração para ME e EPP – Poderá ser substituída pela declaração de mesmo teor, extraída do Sistema Eletrônico;

22.15.6. XXXXX XX – Minuta de contrato.

22.16. Sempre que o sistema de pregão eletrônico disponibilizar as declarações citadas, o licitante poderá utilizar as opções pelo meio eletrônico.

Brasília, 28 de novembro de 2018.

XXXXXXX XX XXXXXX

Gerente Administrativo do CAU/BR

PREGÃO ELETRÔNICO Nº 09/2018

CONSELHO DE ARQUITETURA E URBANISMO DO BRASIL – CAU/BR

(Processo Administrativo n.º 211/2018)

ANEXO I

ENCARTE A: TERMO DE REFERÊNCIA

CAPÍTULO 1. DO OBJETO

1.3. Contratação de empresa para prestação de serviços de Tecnologia da Informação para atender às necessidades do Conselho de Arquitetura e Urbanismo do Brasil – CAU/BR, de acordo com as especificações, padrões técnicos de desempenho e qualidade estabelecidos neste Termo de Referência, contemplando as atividades de projeto, sustentação, serviço e documentação de sistemas de informação, na modalidade Fábrica de Software (FSW), baseado nas práticas e princípios das “metodologias ágeis”, mediante ordens de serviço dimensionados pela métrica de Ponto de Função, bem como transferência de conhecimento e consultoria em TI, dimensionados pela métrica de Unidades de Serviço Técnico – UST.

1.4. As atividades abrangidas no objeto de contratação consistem na prestação de serviços de projeto (desenvolvimento e melhorias), manutenções (manutenção evolutiva, manutenção perfectiva, manutenção adaptativa, manutenção de interface e manutenção corretiva), documentação, serviços de sistema de informação na modalidade Fábrica de Software, transferência de conhecimento e consultoria em TI.

1.5. Considerando o levantamento dos sistemas de informação em utilização no CAU/BR e a necessidade de novos sistemas de informação, a estimativa de Pontos de Função previstos para a execução do objeto em 12 (doze) meses é de até 2.000 (dois mil) e a estimativa de Unidades de Serviços Técnicos - USTs é de até 500 (quinhentas).

CAPÍTULO 2. DA JUSTIFICATIVA PARA A CONTRATAÇÃO

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

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

2.3. Por dispor de quadro próprio limitado de profissionais especializados em tecnologia da informação (TI), as atividades de desenvolvimento, sustentação, documentação, serviços e metrificação de sistemas de informação precisam ser realizadas com a estrutura de uma Fábrica de Software, com vistas a atender o volume de demandas do CAU, que nos últimos quatro anos teve quantitativo em torno de nove mil pontos de função;

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

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

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

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

2.5. A presente contratação justifica-se ainda pelo encerramento iminente do atual contrato de Fábrica de Software para atendimento ao CAU, que possui vigência até o mês de dezembro de 2018.

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

CAPÍTULO 3. DOS RESULTADOS ESPERADOS

3.1. Apoiar o CAU no cumprimento de sua missão institucional, através do fornecimento de soluções informatizadas às suas áreas de negócio;

3.2. Modernização da gestão e dos sistemas de informação do CAU (SICCAU – Resolução No. 126 de 15 de dezembro de 2016);

3.3. Redução de ocorrência de processos administrativos, em virtude de problemas do sistema de informação;

3.4. Participação do requisitante (unidades demandantes do CAU/BR e dos CAU/UF) no fluxo de gestão de contratos, principalmente referente à aceitação do produto/serviço;

3.5. Atendimento das demandas nos prazos estabelecidos, sob pena de aplicação de sanções;

3.6. Ganho de escala na contratação dos serviços de desenvolvimento e manutenção de sistemas;

3.7. Aderência às diretrizes estabelecidas no Plano Diretor de Tecnologia da Informação – PDTI;

3.8. Atendimento às necessidades de desenvolvimento de software do Centro de Serviços Compartilhados do CAU, especialmente relativas à manutenção e evolução do SICCAU.

CAPÍTULO 4. DA JUSTIFICATIVA DA SOLUÇÃO ESCOLHIDA

4.1. Os objetivos da presente contratação são a melhoria da qualidade dos serviços prestados aos usuários e o apoio tempestivo dos processos de trabalho e atividades finalísticas do CAU, garantindo o pronto atendimento às demandas. Desta forma, torna-se imprescindível manter o pleno funcionamento dos recursos e serviços do ambiente de Tecnologia da Informação do Sistema de Informação e Comunicação do CAU – SICCAU;

4.2. A contratação de uma fábrica de software, com pagamento por demanda entregue, possibilita o aumento ou a diminuição da quantidade de esforço de acordo com a necessidade priorizada pelo CAU, inclusive considerando o orçamento estabelecido pelo Colegiado de Governança do CSC (CG-CSC);

4.3. Dado o cenário da estrutura da Gerência de Serviços Compartilhados (GESC) e a relação das necessidades de soluções de sistemas de informação já levantadas pelas áreas de negócio do CAU/BR e dos CAU/UF, é clara a necessidade de utilização de um modelo de gestão que viabilize a continuidade da sustentação e desenvolvimento dos sistemas geridos no âmbito do CSC, neste caso, por meio do modelo de terceirização dos serviços operacionais de tecnologia da informação, conforme destacado no capítulo 2 deste Termo de Referência.

4.4. No âmbito contratual são necessárias atividades complementares ao próprio desenvolvimento de software, especialmente interligadas à metodologia utilizada e ao escopo das demandas. Por esta razão é essencial que ambos os itens do contrato sejam prestados pelo mesmo fornecedor, a fim de serem mantidas as referências e padrões, bem como o atendimento e cumprimento da Metodologia de Gerenciamento e Desenvolvimento de Software do CAU – MGDS-CAU. Dessa forma há maior garantia da qualidade e agilidade das entregas, permitindo o cumprimento dos objetivos estabelecidos pela gestão do CAU.

CAPÍTULO 5. DA CLASSIFICAÇÃO DOS SERVIÇOS E ESCOLHA DA MODALIDADE LICITATÓRIA

5.1. Considerando que os padrões, os níveis de qualidade, a qualificação técnica, as quantificações e as especificações dos serviços a serem prestados, assim como dos itens a serem entregues, estão adequadamente definidos por meio de especificações usuais no mercado e, de modo objetivo, no presente Termo de Referência, entende-se que a contratação que ora se pretende está enquadrada como serviço comum, tendo a obrigatoriedade de seguir a modalidade Pregão Eletrônico, do tipo Menor Preço, em conformidade com a Lei nº 10.520, de 17 de julho de 2002, publicada no D.O.U., de 18 de julho de 2002 e suas alterações.

5.2. Ainda que o volume efetivo de execução seja estimado, os valores previstos consideram a volumetria histórica para o tipo de serviço contratado, bem como o backlog e mapeamento de demandas já estruturado no âmbito do Conselho.

5.3. Tendo em vista a dependência de ferramentas tecnológicas para a execução das atividades fim da CONTRATANTE, os serviços descritos nesta contratação caracterizam-se como de natureza continuada, pois a sua indisponibilidade paralisa as atividades da CONTRATANTE e traz prejuízos a prestação de serviços essenciais ao cidadão.

5.4. Salienta-se que os serviços a serem contratados enquadram-se nos pressupostos do Decreto n° 2.271, de 1997, constituindo-se em atividades materiais acessórias, instrumentais ou complementares à área de competência legal do órgão licitante, não inerentes às categorias funcionais abrangidas por seu respectivo plano de cargos.

5.5. Desta forma, a prestação dos serviços não gera vínculo empregatício entre os empregados da Contratada e a Administração, vedando-se qualquer relação entre estes que caracterize pessoalidade e subordinação direta. O modelo de contratação proposto tem pagamento realizado por demanda, não exigindo alocação integral de mão-de-obra.

CAPÍTULO 6. DA DESCRIÇÃO DA SOLUÇÃO DE TI

6.1. A solução encontrada foi a contratação de empresa para prestação de serviços de projeto, manutenção, documentação, serviços de sistemas da informação, transferência de conhecimento e consultoria em TI, nos termos das especificações abaixo:

6.2. Item 1 – Fábrica de Software (FSW)

6.2.1. Consiste na prestação dos serviços de projeto (de desenvolvimento e melhorias); manutenção (manutenção evolutiva, manutenção perfectiva, manutenção adaptativa, manutenção de interface e manutenção corretiva); documentação e serviços de sistemas de informação, definidos na Metodologia de Gestão em Desenvolvimento de Software do Conselho de Arquitetura e Urbanismo (MGDS-CAU), presente no ENCARTE B deste Anexo I;

6.2.2. Cada demanda deverá ser construída e homologada individualmente (pela CONTRATADA, atendendo às especificações recebidas, de acordo com o ambiente e os padrões determinados pelo CAU/BR;

6.2.3. A elaboração ou atualização de documentos referentes aos serviços demandados à CONTRATADA é obrigatória no âmbito do escopo aprovado e será realizada sem custo adicional ao CAU, devendo estar em conformidade com o estabelecido pela MGDS-CAU, versão 3.0 ou superior;

6.2.4. Os processos a serem executados pela empresa CONTRATADA deverão seguir as melhores práticas de mercado, tais como: ISO/IEC 15.504, ISO/IEC 12.207, ISO/IEC 9.126, ISO/IEC 17.799, COBIT 4.1, PMBOK, ITIL, CMMI, MPSBR, entre outras similares;

6.2.5. O gerenciamento das demandas do tipo Projeto deverá seguir as melhores práticas de gerenciamento de projeto (baseado no Pmbok 5ª edição ou superior);

6.2.6. A CONTRATADA deverá gerar todos artefatos e produtos previstos na MGDS-CAU

– (Encarte B do presente Anexo I);

6.2.7. Para as demandas do tipo “Serviço”, quando não mensuráveis pela técnica de análise em pontos de função, conforme o “Roteiro de Métrica de Software” do SISP v.2.2 (ou superior) ou no “Function Point Counting Practices Manual (CPM)”, deverá ser considerada a forma de mensuração descrita no item 17.8.6 deste Termo de Referência;

6.2.8. Os demais tipos de demandas serão mensurados pelo “Roteiro de Métrica de Software” do SISP v.2.2 ou superior.

6.3. Item 2 – Transferência de Conhecimento e Consultoria em TI

6.3.1. Os serviços de Transferência de Conhecimento e Consultoria em TI serão realizados e mensurados conforme catálogo de serviços constante no Encarte K deste termo de referência.

6.3.2. As atividades são valoradas em função do seu nível de complexidade. Dada a variação da complexidade há diferentes níveis para enquadramento. Proporcional ao nível de complexidade da atividade está a especialização dos profissionais que as executarão, de forma que a quantidade de USTs garantam a justa remuneração da atividade.

6.3.3. No início de cada demanda de transferência de conhecimento ou consultoria em TI haverá necessidade de se estabelecer o esforço dos serviços em USTs. A CONTRATADA irá propor uma estimativa de esforço que será confirmada ou retificada pelo CONTRATANTE. A primeira referência para cálculo da estimativa de esforço desse tipo de serviço será o Catálogo de Serviços constante no Encarte K deste Termo de Referência.

6.3.4. Caso o catálogo de serviços não ofereça estimativa que possa ser utilizada na medição do esforço requerido por determinada demanda, o CAU/BR e a CONTRATADA buscarão o consenso, utilizando os seguintes critérios, sucessivamente:

6.3.4.1. Analogia com outros itens do catálogo;

6.3.4.2. A critério do CAU/BR será realizada aferição empírica da dimensão do escopo por meio de projeto piloto de reduzida duração, com acompanhamento integral de representante indicado pelo CONTRATANTE, do trabalho realizado pela CONTRATADA.

6.3.5. O resultado advindo do processo acima poderá, a critério do CAU/BR, ser incorporado ao catálogo de serviços para utilização em demandas futuras.

6.3.6. O CAU/BR é o responsável final por definir o tamanho da dimensão em USTs. As justificativas da CONTRATADA deverão ser consideradas e respondidas, ainda que não acatadas.

6.3.7. Após o término da demanda, na fase de encerramento, a CONTRATADA poderá propor a atualização do Catálogo de Serviços. O CAU/BR poderá ainda, a qualquer tempo, revisar os itens do Catálogo, sendo que as novas definições valerão apenas para demandas futuras.

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

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

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

7.3. Requisitos Internos

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

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

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

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

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

7.3.4. A Política de Segurança da Informação do CAU/BR e seu Regulamento Interno de Segurança da Informação deverão ser cumpridos pela empresa CONTRATADA e estão

disponíveis no endereço eletrônico xxx.xxxxx.xxx.xx/xx- content/uploads/2012/07/portarianormativa49.pdf;

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

7.3.6. Nas ações relativas à manutenção e evolução dos sistemas deverão ser considerados pela CONTRATADA critérios de usabilidade, padrões de navegação, facilidade de codificação, facilidade de manutenção, robustez, segurança, facilidade de aprendizado, reusabilidade e portabilidade na escolha das soluções a serem implantadas.

7.4. Requisitos Externos

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

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

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

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

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

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

7.5. Requisitos da Solução

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

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

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

7.5.3.1. Ambiente de desenvolvimento – Disposto na CONTRATADA;

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

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

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

7.6. Arquitetura Técnica Atual

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

7.6.1.1. BD:

a) PostgreSQL

b) PostGIS

c) MySQL.

7.6.1.2. Plataformas de Linguagens:

a) PHP;

b) Java/WEB;

c) PL/PGSQL;

d) Java/Web Service/XML.

7.6.1.3. Sistema Operacional:

a) LINUX;

b) Windows Server.

7.6.1.4. Serviço de Diretório

a) AD (Active Directory) da Microsoft;

b) Samba – LDAP.

7.6.1.5. Serviço de Aplicação

a) Apache 2 (ou superior);

b) Xxxxxx 0 (ou superior);

c) JBoss Seam.

7.6.1.6. Ferramentas:

a) Ferramenta WebIntegrator - WI (ferramenta desenvolvimento Java/Web) – SW Livre;

b) IDE Eclipse (ferramenta de desenvolvimento Java/Web) – SW Livre;

c) IDE PHP Storm (ferramenta de desenvolvimento utilizada pela atual fábrica de software);

d) Prado - framework para desenvolvimento PHP (FOS – Free Open Source);

e) Zend – framework para desenvolvimento PHP (FOS – Free Open Source);

f) IDE Netbeans;

g) Notepad ++ (editor para programação);

h) CMS Drupal (ferramenta para gestão de conteúdo) – SW Livre;

i) Subversion (ferramenta para controle de versão) – SW Livre;

j) DreamWeaver (ferramenta de diagramação e layout) – Licenciada;

k) Bizagi (ferramenta para modelagem de processo);

l) GIT (Sistema de controle de versão distribuído e um sistema de gerenciamento de código fonte) – SW Livre;

m) JENKINS (Sistema de integração contínua de processos de forma manual ou automatizada – SW Livre;

n) LARAVEL (Framework de desenvolvimento rápido para PHP) – SW Livre;

o) Dbeaver (Ferramenta de banco de dados multiplataforma) – SW Livre;

p) PGAdmin (Ferramenta de administração de banco de dados) – SW Livre;

q) Selenium (Ferramenta de testes automatizados) – SW Livre;

r) JIRA (Ferramenta que permite a abertura e acompanhamento das demandas que são solicitadas à CONTRATADA). Atualmente a ferramenta está disposta no ambiente da fábrica de software que possui contrato ainda vigente com o CAU/BR;

s) AXURE PRO V8.0 (Ferramenta de prototipação). Atualmente a ferramenta é licenciada pela fábrica de software que possui contrato ainda vigente com o CAU/BR. O CAU/BR homologa o protótipo em html.

7.7. Ambiente Tecnológico Atual

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

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

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

7.8. Requisitos de Evolução / Manutenção da Solução

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

7.8.2.Transferência de Conhecimento – Técnico

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

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

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

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

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

7.9. Transferência interna de conhecimento técnico da empresa contratada

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

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

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

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

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

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

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

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

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

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

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

7.12. Requisitos Temporais

7.12.1. Os custos de manutenção corretiva, durante o período de garantia do sistema (120 dias após sua disponibilização no ambiente de produção), são de responsabilidade da empresa CONTRATADA.

7.12.2. As correções necessárias aos serviços ainda em garantia (120 dias após sua disponibilização no ambiente de produção) serão executadas no prazo previsto e sem ônus adicional ao CAU/BR;

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

7.13. Requisitos Operacionais

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

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

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

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

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

7.14. Requisitos Legais

7.14.1. O presente Termo de Referência foi elaborado em conformidade com os seguintes regramentos:

a) Lei nº 8.666, de 21 de junho de 1993 – Lei de Licitações e Contratos Administrativos;

b) Lei nº 10.520, de 17 de julho de 2002 – Lei do Pregão;

c) Decreto nº 2.271, de 07 de julho de 1997 – Dispõe sobre contratação de serviços pela Administração Pública Federal;

d) Decreto nº 3.555, de 08 de agosto de 2000 - Regulamento do Pregão para aquisição de bens e serviços comuns;

e) Decreto nº 5.450, de 31 de maio de 2005 – Regulamenta o Pregão, na forma eletrônica;

f) Decreto nº 7.174, de 12 de maio de 2010 – Contratação de bens e serviços de informática e automação pela Administração Pública Federal;

g) Portaria SLTI/MP nº 03, de 07 de maio de 2007 – Modelo de Acessibilidade;

h) Portaria Normativa SLTI/MP nº 05, de 14 de julho de 2005 – Padrões de interoperabilidade;

i) Instrução Normativa SLTI/MP nº 04, de 11 de setembro de 2014 – Dispõe sobre processo de contratação de soluções de TI;

j) Instrução Normativa MPDG nº 05, de 26 de maio de 2017, que revogou a IN nº 02.

7.15. Requisitos de Qualidade

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

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

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

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

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

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

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

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

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

7.16. Teste

7.16.1. Teste do Aplicativo

7.16.1.1. A MGDS do CAU descreve o procedimento da etapa de testes, os artefatos esperados e as responsabilidades da CONTRATADA e do CONTRATANTE;

7.16.1.2. Entende-se como Teste de Aplicativo a execução controlada do aplicativo, verificando se o seu comportamento ocorre de acordo com o especificado no serviço, buscando assim, evidenciar o alcance dos resultados e dos padrões estabelecidos na especificação funcional;

7.16.1.3. Os casos de testes elaborados pela CONTRATADA devem possuir os cenários de teste abarcando 100% das regras de negócio criadas ou modificadas pela ordem de serviço;

7.16.1.4. A CONTRATADA deve entregar, junto com os artefatos construídos, toda a documentação contendo os cenários de teste, os scripts de testes unitários utilizando o PHPUnit ou similar, os scripts de testes automatizados utilizando o SELENIUM IDE ou similar, a filmagem dos cenários que não puderam ser automatizados e as bases de dados de testes que servirão de subsídio para as atividades de auditoria do trabalho de teste e dos testes de aceitação;

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

7.16.2. Teste Unitário

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

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

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

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

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

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

Exemplo de Relatório de Cobertura de Testes do PHPUnit

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

7.16.3. Teste Integrado

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

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

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

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

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

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

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

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

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

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

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

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

7.16.5. Integração Contínua

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

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

7.16.5.2.1. Criação de uma branch com o nome ‘OS-123’ derivada da branch corrente de produção;

7.16.5.2.2. A branch ‘OS-123’ é colocada pela FSW em um ambiente de testes específico; 7.16.5.2.3. A branch ‘OS-123’ é testada isoladamente nesse ambiente de testes pela equipe da FSW;

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

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

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

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

7.16.5.2.8. A ‘OS-123’ é enviada para Produção;

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

7.16.6. Homologação

7.16.6.1. O processo de homologação (funcional e não-funcional) deverá ocorrer nos ambientes do CAU/BR em 2 (dois) ciclos, conforme detalhado na MGDS do CAU;

7.16.6.2. Quando indicado na ordem de serviço, o processo de homologação será assistido pela empresa CONTRATADA, sem ônus adicional para o CAU/BR;

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

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

CAPÍTULO 8. DO MODELO DE PRESTAÇÃO DE SERVIÇO

8.1. Metodologia de Trabalho

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

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

8.1.3. O processo de demanda deverá ocorrer em conformidade com o art. 33 da IN 04 2014/SLTI-MP.

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

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

8.2.2. Os serviços serão executados nas dependências da empresa CONTRATADA, na cidade de Brasília/DF.

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

8.2.4. A critério do CAU/BR, alguns serviços poderão ser executados fora das dependências do CAU/BR.

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

8.2.6. A critério do CONTRATANTE poderá haver a alocação de times de desenvolvimento de projetos nas dependências do CAU/BR, mantidas as condições previstas no item 8.2.8. e respeitadas as definições dos itens 5.4. e 5.5. deste Termo de Referência, considerada a volumetria e características das demandas em execução pela CONTRATADA;

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

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

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

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

8.2.11. O CAU/BR disponibilizará acesso via VPN (Virtual Private Network) site to site aos ambientes de testes e de homologação para a prestação de serviços pela empresa CONTRATADA;

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

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

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

8.3. Encaminhamento e Controle das Solicitações

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

8.4.14. O sistema deverá calcular de forma automática os índices de desempenho, o atingimento dos níveis mínimos de serviços e as glosas por ordem de serviço.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

8.4.20.11.Registro de impedimento de execução pela FSW; 8.4.20.12.Registro de retirada de impedimento pelo CAU/BR; 8.4.20.13.Registro da conclusão a entrega pela FSW;

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

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

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

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

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

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

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

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

8.4.20.24.Cálculo automático dos níveis de serviço e indicadores de níveis de desempenho (IDP e PD), por tipo de serviço, com as respectivas coletas e análises;

8.4.20.25.Registros de problemas e comentários;

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

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

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

8.4.20.29.Indicação pela FSW da nota fiscal, data de emissão e valor faturado da OS; 8.4.20.30.Armazenamento histórico de todas as informações, assim como uma referência às versões de todos os documentos utilizados;

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

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

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

8.4.20.31.3. Identificação de atividades pendentes;

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

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

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

8.4.20.31.7. Gráfico de acompanhamento de OS por tipo e status; 8.4.20.31.8. Localização de OS através de busca textual e filtros; 8.4.20.31.9. Emissão de relatórios com múltiplos critérios de seleção (filtros).

8.5. Entrega, Avaliação e Recebimento

8.5.1. A entrega do objeto previsto na OS deverá ser realizado pela empresa CONTRATADA dentro do prazo máximo previsto na tabela de Níveis de Serviço – item

17.6 deste Termo de Referência;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

8. Forma de Execução / Fornecimento

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

CAPÍTULO 9. DOS ELEMENTOS PARA GESTÃO DO CONTRATO

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

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

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

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

9.6. Papéis e Responsabilidades

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

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

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

c) Monitorar a execução contratual;

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

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

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

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

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

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

9.6.2. Fiscal Técnico

Entidade: Coordenadoria de TI (CORTI) Responsabilidades:

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

b) Emitir o Termo de Recebimento Definitivo;

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

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

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

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

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

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

9.6.3. Fiscal Requisitante

Entidade: Coordenadoria do SICCAU (CORSICCAU) Responsabilidades:

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

b) Validar o escopo da OS;

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

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

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

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

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

h) Avaliar em conjunto com o dono do produto a qualidade dos serviços entregues, as

conformidades e as justificativas de acordo com os critérios de aceitação;

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

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

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

9.6.4. Dono do Produto (product owner) Entidade: Coordenadoria do SICCAU (CORSICCAU) Responsabilidades:

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

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

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

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

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

f) Retirar os impedimentos registrados pela CONTRATADA;

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

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

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

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

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

b) Aprovar o escopo da OS;

c) Autorizar a abertura da OS;

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

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

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

9.6.6. Fiscal Administrativo Entidade: CAU/BR Responsabilidades:

a) Verificar aderência aos termos contratuais;

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

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

9.6.7. Preposto

Entidade: Empresa CONTRATADA Responsabilidades:

a) Acompanhar a execução do contrato;

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

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

CAPÍTULO 10. DA VISTORIA

10.1. O licitante poderá realizar visita para reconhecimento das dependências do CAU/BR, antes da apresentação das propostas, a fim de tomar conhecimento de toda arquitetura, ambiente operacional e parque tecnológico do CAU/BR.

10.2. Ao final da vistoria, será solicitado o preenchimento do formulário de vistoria, conforme modelo constante no Encarte I deste Termo de Referência.

10.3. Se o licitante não executar a vistoria nas dependências do CAU/BR, não poderá, em nenhuma hipótese, realizar reclamações ou alegações futuras de desconhecimento das condições.

10.4. A vistoria poderá ser realizada em até 2 (dois) dias úteis anteriores à data de abertura da licitação, mediante prévio agendamento de horário junto aos representantes da Comissão Permanente de Licitação do CAU/BR, pelo telefone (00) 0000-0000, no horário das 09h00 às 12h00 e das 14h00 às 17h00.

10.5. Os licitantes não poderão alegar o desconhecimento das condições e grau de dificuldade existentes como justificativa para se eximirem das obrigações assumidas ou em favor de eventuais pretensões de acréscimos de preços em decorrência da execução do objeto deste pregão.

10.6. O representante indicado pela licitante para executar a vistoria, deverá portar documento comprobatório de ser o responsável da licitante e portar documento de identificação com fotografia, juntamente com suas cópias, que serão juntados ao processo administrativo licitatório.

CAPÍTULO 11. DAS CONDIÇÕES PARA PARTICIPAR DA LICITAÇÃO

11.1. Condições gerais

11.1.1. Poderão participar do certame licitatório os interessados que atenderem a todas as exigências estabelecidas e que estiverem previamente credenciados no Sistema de Cadastramento Unificado de Fornecedores (SICAF) e perante o sistema eletrônico provido pela Secretaria de Logística e Tecnologia da Informação do Ministério do Planejamento, Orçamento e Gestão (SLTI), por meio do sítio xxx.xxxxxxxxxx.xxx.xx, não sendo admitida, seja a que título for, a participação de dirigentes, conselheiros e colaboradores do CAU/BR, inclusive familiares, na forma prevista no art. 7º do Decreto nº 7.203, de 2010.

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

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

11.1.2. Não poderão participar deste pregão:

11.1.2.1. Empresário suspenso de participar de licitação e impedido de contratar com o CAU/BR, durante o prazo da sanção aplicada.

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

11.1.2.3. Empresário impedido de licitar e contratar com o CAU/BR, durante o prazo da sanção aplicada.

11.1.2.4. Sociedade estrangeira não autorizada a funcionar no País.

11.1.2.5. Empresário cujo estatuto ou contrato social não inclua o objeto deste pregão.

11.1.2.6. Empresário que se encontre em processo de dissolução ou recuperação judicial.

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

11.1.2.8. Consórcio de empresa, qualquer que seja sua forma de constituição, por se tratar execução de objeto que envolve a prestação de trabalho não eventual por pessoas físicas, com relação de subordinação ou dependência, em face da contratante, conforme redação dada pelo Decreto nº 57.159/2011.

11.1.2.9. Sociedades cooperativas, de acordo com a vedação contida no Termo de Conciliação Judicial firmado entre o Ministério Público do Trabalho e a União e a proibição do art. 4º da IN/SLTI/MPOG nº 2, de 30 de abril de 2008.

11.1.3. A participação na licitação importa em total e irrestrito conhecimento e submissão às condições estatuídas neste edital.

11.1.4. O descumprimento de qualquer condição de participação acarretará a inabilitação do licitante.

11.2. Qualificação econômico-financeira

11.2.1. Balanço patrimonial e demonstrações contábeis referentes ao último exercício social, comprovando índices de Liquidez Geral (LG), Liquidez Corrente (LC), e Solvência Geral (SG) superiores a 1 (um);

11.2.2. Capital Circulante Líquido ou Capital de Giro (Ativo Circulante - Passivo Circulante) de, no mínimo, 8,33% (oito inteiros e trinta e três centésimos por cento) do valor estimado da contratação, tendo por base o balanço patrimonial e as demonstrações contábeis do último exercício social;

11.2.3. Comprovação de patrimônio líquido de 10% (dez por cento) do valor estimado da contratação, por meio da apresentação do balanço patrimonial e demonstrações contábeis do último exercício social, apresentados na forma da lei, vedada a substituição por balancetes ou balanços provisórios, podendo ser atualizados por índices oficiais, quando encerrados há mais de 3 (três) meses da data da apresentação da proposta;

11.2.4. Certidão negativa de efeitos de falência, recuperação judicial ou recuperação extrajudicial, expedida pelo distribuidor da sede do licitante.

11.3. Regularidade Fiscal e Trabalhista

11.3.1. A habilitação das licitantes será verificada por meio do SICAF (habilitação parcial) e da documentação complementar especificada neste edital.

11.3.2. As licitantes que não atenderem às exigências de habilitação parcial no SICAF deverão apresentar documentos que supram tais exigências, quais sejam:

11.3.2.1. Comprovantes de Inscrição no Cadastro Nacional da Pessoa Jurídica do Ministério da Fazenda (CNPJ/MF).

11.3.2.2. Provas de inscrição no cadastro de contribuintes estadual ou municipal, se houver, relativo ao domicílio ou sede do licitante, pertinente ao seu ramo de atividade e compatível com o objeto contratual.

11.3.2.3. Certificados de Regularidade perante o Fundo de Garantia por Tempo de Serviço, emitido pela Caixa Econômica Federal.

11.3.2.4. Certidão Negativa de Débitos perante o Instituto Nacional do Seguro Social.

11.3.2.5. Provas de Regularidade para com as Fazendas Federal, Estadual ou do Distrito Federal e Municipal.

11.3.2.6. Prova de Regularidade trabalhista por meio de apresentação da Certidão Negativa de Débitos Trabalhistas.

11.3.3. Realizada a habilitação parcial no SICAF, serão verificados outros eventuais descumprimentos, mediante consulta ao:

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

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

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

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

11.3.5. Efetuada a verificação referente ao cumprimento das condições de participação no certame, a habilitação das licitantes será realizada mediante a apresentação da seguinte documentação complementar, para fins de comprovação de regularidade trabalhista: prova de inexistência de débitos inadimplidos perante a Justiça do Trabalho, mediante a apresentação de certidão negativa, nos termos do Título VII-A da Consolidação das Leis do Trabalho, aprovada pelo Decreto-Lei nº 5.452, de 1º de maio de 1943, tendo em vista o disposto no art. 3º da Lei nº 12.440, de 7 de julho de 2011.

11.4. Declarações

11.4.1. Os licitantes deverão apresentar:

11.4.1.1. Declaração que cumpre plenamente os requisitos exigidos para habilitação e sujeita-se aos termos e condições da licitação.

11.4.1.2. Declaração de não possuir em seu quadro de pessoal empregado menor de 18 (dezoito) anos em trabalho noturno, perigoso ou insalubre e menor de 16 (dezesseis) anos em qualquer trabalho, salvo na condição de aprendiz a partir de 14 (quatorze) anos.

11.4.2. Declaração do proponente que não está suspenso do direito de licitar e não tenha sido declarado inidôneo por qualquer órgão ou entidade do Governo Federal, Estadual ou do Distrito Federal e Municipal.

11.5. Habilitação jurídica

11.5.1. Os licitantes deverão apresentar:

11.5.1.1. Registro comercial, no caso de empresa individual.

11.5.1.2. Ato constitutivo, estatuto ou contrato social em vigor, devidamente registrado, em se tratando de sociedades comerciais, e, no caso de sociedades por ações, acompanhado

dos documentos de eleição de seus administradores. Havendo alterações ou consolidações, estas deverão acompanhar os demais documentos.

11.5.1.3. Tratando-se de sociedade cooperativa, serão exigidos ainda:

11.5.1.3.1. Ata de fundação.

11.5.1.3.2. Comprovante de registro na Organização das Cooperativas Brasileiras ou na entidade estadual, se houver, conforme art. 107 da Lei nº 5.764/1971.

11.5.1.3.3. O resultado da última auditoria contábil-financeira da cooperativa, conforme dispõe o art. 112 da Lei nº 5.764, de 1971, ou uma declaração, sob as penas da lei de que tal auditoria não foi exigida pelo órgão fiscalizador.

11.5.1.3.4. Relação dos cooperados que atendem aos requisitos técnicos exigidos para a contratação e que executarão o objeto, respeitado o disposto nos artigos. 4º, XI, 21, I e 42,

§§ 2º a 6º da Lei nº 5.764, de 1971.

11.5.1.3.5. Declaração de regularidade de situação do contribuinte individual – DRSCI de cada um dos cooperados relacionados.

11.5.1.4. Decreto de autorização, devidamente publicado, em se tratando de empresa ou sociedade estrangeira em funcionamento no país e ato de registro ou autorização para funcionamento expedido pelo órgão competente, quando a atividade assim o exigir.

11.5.1.5. Inscrição do ato constitutivo, no caso de sociedades civis, acompanhada de prova de investidura ou nomeação da diretoria em exercício.

11.5.1.6. No caso de o licitante ser microempresa ou empresa de pequeno porte, deverá apresentar certidão ou declaração de enquadramento no citado regime.

11.5.1.7. Documento de identificação pessoal do(s) responsável(is) legal(is) pela assinatura do contrato.

11.6. Qualificação técnica

11.6.1. A CONTRATADA deverá apresentar no mínimo 1 (um) atestado de capacidade técnica, fornecido por pessoa jurídica de direito público ou privado, comprovando que a empresa licitante executou serviços compatíveis, em características, quantidades e prazos, com o objeto da licitação, e que contenha as especificações abaixo:

Tipo de Informação	Conteúdo
1.Informações da Empresa Licitante	Nome comercial/ CNPJ/Endereço
2. Identificação do Projeto/Sistema.	Nome do Projeto/Sistema.
3. Tamanho do Projeto/Sistema.	Tamanho em Pontos de Função.
4. Consumo do Projeto/Sistema.	Quantidade de Pontos de Função efetivamente consumidos pelo projeto/sistema.
5.Qualificação dos serviços que retrate o bom atendimento na execução do objeto.	Descrever a qualificação dos serviços prestados, que qualifique o bom atendimento na execução do objeto, detalhando todas as atividades realizadas.
6. Plataforma Tecnológica.	Descrição da linguagem e SGBD utilizados.
7. Período de realização do(s) serviço(s).	Mês/ano de início e fim do(s) serviço(s).

8. Informações sobre o uso do modelo.	Constando a informação sobre o uso do regime de Fábrica de Software.
9. Descrição sucinta do(s) projeto(s).	Constando a identificação dos projetos, com descrições sucintas, contendo as etapas de Ciclo de Desenvolvimento/Manutenção executadas e a utilização de metodologia formal.
10. Dados do responsável pelas informações.	Nome / E-mail / Telefone do responsável pelos contatos técnicos do cliente (pessoa vinculada ao cliente responsável pelos contatos relativos ao projeto).
11. Informações da Empresa/Órgão Público que emitiu o atestado e assinatura.	Nome comercial / CNPJ / Endereço / Telefone e E-mail da empresa privada / Órgão Público e cargo ocupado pelo signatário do atestado.

11.6.2. Os atestado(s) de capacidade técnica deverão comprovar que a licitante tenha executado, ou que esteja executando, serviços de desenvolvimento e manutenção de sistema(s) de informação em instalações próprias de Fábrica de Software, tendo provido toda a infraestrutura voltada à execução dos serviços, que comprovem as seguintes atividades:

a) Experiência na prestação de serviços técnicos de Definição de escopo; levantamento, definição, especificação e gerência de requisitos; análise e projeto; programação; administração de dados; arquitetura; modelagem de dados e banco de dados relacional (conceitual, lógico e físico); reengenharia; implementação, construção; codificação, integração; produção; testes (unitários, funcionais e não-funcionais); homologação; implantação; suporte; segurança; monitoramento; treinamento de usuários; gerência de configuração, mudança, e projeto; e garantia de qualidade;

b) Experiência na prestação de serviços técnicos em desenvolvimento ou sustentação (manutenção) de sistemas de informação, nas plataformas de linguagem Java/Web e PHP com Banco de Dados PostgreSQL, em volume igual ou superior a 2.000 (dois mil) pontos de função efetivamente executados seguindo um método ou metodologia de desenvolvimento de sistemas (MDS) em conformidade com as normas NBR ISO/12.207 (Engenharia de sistemas de software – Processos de ciclo de vida de software) e, no mínimo, com o Nível 3 da NBR/ISO 15.504 (Tecnologia da Informação – Avaliação de processo, também conhecida como SPICE), com pelo menos um dos projetos executados conforme as melhores práticas do mercado (como: ISO/IEC 15.504, ISO/IEC 12.207, ISO/IEC 9.126, ISO 17.799, COBIT 4.1, Pmbok, ITIL, CMMI, MPSBR, entre outras), em período ininterrupto de 12 meses;

c) Experiência em metrificação/mensuração de sistemas de informação em pontos por função, padrão IFPUG (International Function Point Users Group), realizada por profissional certificado CFPS (Certifed Function Point Specialist pelo IFPUG, com certificação válida no período da contagem, com volume mínimo de 2.000 (dois mil) Pontos de Função, em regime de Fábrica de Software, em período ininterrupto de 12 (doze) meses;

d) Experiência na prestação de serviços técnicos de desenvolvimento e sustentação (manutenção) de sistemas de informação, com esforço mínimo de 2.000 (dois mil) Pontos de Função, utilizando metodologias e processos de Gerenciamento de Projetos em conformidade com o Pmbok (3ª edição ou superior), em regime de fábrica de software, em

período ininterrupto de 12 (doze) meses;

e) Experiência na prestação de serviços técnicos em análise, modelagem, projeto técnico utilizando a UML (Unified Modeling Language), com elaboração dos seguintes diagramas: Diagrama de Casos de Uso, Diagrama de Sequência, Diagrama de Transição de Estados, Diagrama de Atividades, Diagrama de Classe, Diagrama de Componentes, Matriz de Rastreabilidade, Documento de Arquitetura de Software, Mapeamento de Risco e Diagrama de Implantação em período ininterrupto de 12 (doze) meses;

f) Experiência em planejamento e execução de testes: unitários, funcionais e não funcionais, usabilidade, acessibilidade, estrutura, integração, sistema, carga, desempenho, estresse, volume, contenção, controle de segurança, regressão, instalação e configuração. Elaboração do Plano de Testes, dos Casos de Teste e da Lista de Bugs Resolvidos, em período ininterrupto de 12 (doze) meses;

g) Experiência na prestação de serviços técnicos de desenvolvimento e manutenção de sistemas de informação, com esforço mínimo de 2000 (dois mil) Pontos de Função, utilizando metodologias ágeis, em regime de fábrica de software, em período ininterrupto de no mínimo 12 (doze) meses, contendo no mínimo 08 (oito) dos seguintes artefatos, práticas ou equivalentes, que devem ter sido produzidos nos projetos:

• Backlog do Produto;

• Gráfico Burndown ou Burnup;

• Planejamento da liberação (release) ou Roadmap;

• Planejamento da iteração (sprint);

• Quadro Informativo (Kanban);

• Diagrama de fluxo cumulativo;

• Documento de requisitos não funcionais;

• Scripts de teste automatizado;

• História de usuário;

• Documento de mensagens;

• Protótipo de tela;

• Parecer de usabilidade e conformidade visual;

• Especificação de componentes;

• Reunião diária;

• Retrospectiva da iteração;

• Apresentação do resultado da liberação.

• Testes de unidade; e

• Teste de aceitação automatizados

h) Experiência na prestação de serviços de apoio ao desenvolvimento e manutenção de sistemas com processos e/ou metodologias ágeis de desenvolvimento, contendo no mínimo 3 (três) dos seguintes artefatos, práticas ou equivalentes, que devem ter sido produzidos no âmbito dos projetos:

• Scripts de banco de dados;

• Documento de análise de volumetria;

• Modelo de dados conceitual;

• Modelo de dados físicos com dicionário de dados;

• Documento de perfil de acesso (privilégios).

i) Experiência na prestação de serviços de desenvolvimento ou manutenção de sistemas, utilizando linguagem PHP, contemplando para qualquer um dos projetos/sistemas apresentados nos atestados referentes às alíneas “d” ou “g”, os itens a seguir:

• O código gerado foi mantido em repositório, sob controle de versões;

• O código gerado foi disponibilizado em ambiente de integração contínua;

• O código gerado foi submetido à análise automatizada de qualidade e ficou aderente aos padrões de qualidade estabelecidos nos processos corporativos.

j) Experiência na implantação do(s) sistema(s) nas instalações do CONTRATANTE com treinamento dos usuários, elaboração do manual do usuário e do help online.

11.6.3. O licitante deve disponibilizar todas as informações necessárias à comprovação da legitimidade dos atestados, apresentando, cópia do contrato, fatura, nota fiscal, empenho, ou qualquer outro documento que corrobore com as informações.

11.6.4. Somente serão aceitos atestados expedidos após a conclusão do contrato ou se decorrido, pelo menos, um ano do início de sua execução, exceto se firmado para ser executado em prazo inferior.

11.6.5. Poderá ser admitida, para fins de comprovação de quantitativo mínimo do serviço, a apresentação de diferentes atestados de serviços executados de forma concomitante, pois essa situação se equivale, para fins de comprovação de capacidade técnico- operacional, a uma única contratação.

11.6.6. No caso de apresentação de atestado de empresas privadas, não serão considerados aqueles apresentados por empresas participantes do mesmo grupo empresarial da CONTRATADA. Serão consideradas como de mesmo grupo, empresas controladas pela CONTRATADA, ou que tenham pelo menos uma pessoa física ou jurídica que seja sócia da empresa emitente e da CONTRATADA;

11.6.7. Os atestados deverão estar em nome da licitante, de forma que, se filial, em nome da filial, se matriz, em nome da matriz, sendo que não serão aceitos atestados emitidos a favor de pessoa jurídica diversa daquela credenciada para o pregão.

11.6.8. A aceitação da qualificação técnica deste item poderá ficar condicionada à verificação da compatibilidade dos serviços nas instalações dos expedidores dos atestados, por meio de visita técnica a ser realizada no local, podendo ainda ser realizada visita técnica nas dependências da empresa licitante, a critério do CAU/BR, momento em que será(ão) solicitado(s) ao emitente dos atestados documentos que descrevam e comprovem a execução das etapas e desenvolvimento dos artefatos abaixo relacionados:

11.6.8.1. Elucidação de Requisitos:

a) Documento de Visão

b) Especificação de Requisitos/Regras de Negócio;

11.6.8.2. Levantamento de Requisitos:

a) Matriz de Rastreabilidade;

b) Documento de Arquitetura de Software;

c) Mapeamento de Risco.

11.6.8.3. Projeto Técnico/Arquitetura de Sistema:

a) Script de DDL dos objetos de BD;

b) Script de Migração de dados.

11.6.8.4. Construção de software:

a) Código-fonte;

b) Help online (Quando solicitado);

c) Documento de Arquitetura do Sistema;

11.6.8.5. Teste/Homologação:

a) Plano de Teste;

b) Casos de Teste/Script de Teste (preferencialmente testes automatizados);

11.6.8.6. Implantação

a) Plano de Implantação de Sistema ou documentos de suporte à atividade de implantação (entrada em produção);

b) Manual do Sistema.

11.7. Requisitos de Capacitação e Experiência dos Profissionais

11.7.1. O licitante vencedor deverá comprovar que os profissionais a serem alocados para os serviços de preposto, gerência de projetos, análise de requisitos, projeto técnico e metrificação possuem os seguintes requisitos obrigatórios relacionados abaixo:

a) Preposto: Curso superior completo na área de informática ou qualquer curso superior com especialização na área de Informática;

b) Gerente de Projeto: Certificação PMP (Project Management Professional) válida concedida pelo PMI (Project Management Institute) e com Certificação CSM (Certified Scrum Master) ou PSM-1 (Professional Scrum Master 1) e Certificação CSPO (Certified Scrum Product Owner) ou PSM-2 (Professional Scrum Master 2);

c) Analista de Requisitos: 1) certificação UML (Unified Modeling Language); 2) certificação CSM (Certified Scrum Master) ou PSM-1 (Professional Scrum Master 1); 3) levantamento de requisitos e regras de negócio; 4) metrificação de sistemas de informação utilizando como unidade de medida o ponto de função;

d) Projetista/Arquiteto de Software: possuir ao menos uma das certificações JAVA: SCEA (Sun Certified Enterprise Architect), SCJD - Sun Certified Java Developer, SCWCD - Sun Certified Web Component Developer, SCBCD - Sun Certified Business Component Developer, SCDJWS - Sun Certified Developer for Java Web Services, Zend Certified PHP Engineer.

11.7.2. Para comprovação do vínculo profissional do responsável técnico com a empresa licitante, serão admitidos os seguintes documentos:

a) cópia da carteira de trabalho (CTPS) do responsável técnico;

b) contrato social da licitante, do qual conste o responsável técnico como integrante da sociedade;

c) contrato de prestação de serviço; e

d) declaração de contratação futura do responsável técnico detentor do atestado apresentado, desde que acompanhada da anuência deste.

11.7.3. A empresa vencedora obriga-se a apresentar, como condição para a assinatura do contrato o Certificado de Maturidade de Processos Capabilty Maturity Model (CMM) nível 3, Capability Maturity Model Integrator (CMMI) nível 3, certificado do Programa de

Melhoria de Processo do Software Brasileiro (MPS-BR) nível “C” ou similar vigente e expedido por instituição qualificada e autorizada para este fim.

11.7.4. Não será aceita documentação que indique encontrar-se a licitante em vias de obtenção da certificação, ou que se encontre em processo de auditoria para tanto, ou com prazo de validade expirado, ou que de qualquer outra maneira não comprove encontrar-se com certificação definitiva e em vigência. Nos casos em que a certificação possui prazo de validade e este não estiver explicitado no documento, deverá ser juntada prova documental de que a certificação está vigente.

11.7.5. Para assegurar o fornecimento adequado dos serviços e a qualidade dos trabalhos, além dos requisitos obrigatórios, é necessário que a equipe técnica tenha os conhecimentos técnicos abaixo relacionados, ficando sob a responsabilidade da empresa CONTRATADA a obrigação de fazer cumprir o exigido. O CAU/BR poderá a qualquer momento requisitar a comprovação ao atendimento dos conhecimentos elencados abaixo:

11.7.5.1. Requisitos do Preposto:

a) Experiência com gestão de contratos ou de projetos;

b) Habilidades de organização, liderança, iniciativa e independência, capacidade analítica e de julgamento, capacidade para trabalhar em equipes multidisciplinares, além de facilidade para lidar com pessoas.

c) Experiência profissional em gerenciamento de projetos de desenvolvimento de software baseados em metodologia baseadas em Processo Unificado (UP) e metodologias ágeis (SCRUM ou similar);

11.7.5.2. Requisitos do Líder Técnico e do Gerente de Projetos:

a) Curso superior completo na área de informática ou qualquer curso superior com especialização na área de informática;

b) Experiência profissional em gerenciamento de projetos de desenvolvimento de software baseados em metodologia baseadas em Processo Unificado (UP) e metodologias ágeis (SCRUM ou similar);

c) Experiência em Contagem de Ponto de Função (PF);

d) Habilidades de organização, liderança, iniciativa e independência, capacidade analítica e de julgamento, capacidade para trabalhar em equipes multidisciplinares, além de facilidade para lidar com pessoas.

11.7.5.3. Requisitos do Analista de Requisitos:

a) Curso superior completo na área de informática ou qualquer curso superior com especialização na área de informática;

a) É indicado que pelo menos um analista de requisitos tenha formação superior em Arquitetura e Urbanismo, sendo para esse profissional, desejável a formação ou especialização na área de informática.

b) Experiência em modelagem BPMN (Business Process Modeling Notation);

c) Habilidades de organização, iniciativa e independência, capacidade analítica e de julgamento, capacidade para trabalhar em equipes multidisciplinares, além de facilidade para lidar com pessoas.

11.7.5.4. Requisitos do Projetista/Arquiteto de Software:

a) Curso superior completo na área de informática;

b) Conhecimento em análise e modelagem de dados utilizando linguagem própria para modelagem;

c) Experiência em desenvolvimento na linguagem Java Struts 2.x (ou superior) e na utilização de frameworks;

d) Experiência em modelagem com o uso da UML;

b) Experiência em desenvolvimento na linguagem PHP 4.x (ou superior) e na utilização de frameworks;

c) Experiência em construção de aplicações web que utilize Framework de desenvolvimento PHP, principalmente: Zend Framework, CodeIgniter, SymPhony, CakePHP e Prado;

d) Experiência em modelagem em Bando de Dados Relacional;

e) Experiência em desenvolvimento de aplicações utilizando as tecnologias XML e XML Schema;

f) Possuir experiência em configuração de serviços de servidor de aplicação: Apache e Tomcat;

g) Experiência em desenvolvimento de aplicações com arquitetura de Web Services e SOA.

11.7.5.5. Requisitos do Analista Desenvolvedor/Programador:

a) Curso superior completo na área de informática ou qualquer curso superior com especialização na área de informática;

b) Conhecer as IDE´s de desenolvimento: Eclipse ou Netbeans;

c) Conhecer a ferramenta Subversion;

d) Experiência em desenvolvimento de sistemas na plataforma WEB;

e) Experiência em desenvolvimento utilizando a linguagem SQL para SGBD-R;

f) Experiência em leitura de modelos UML, que utilizem a metodologia Processo Unificado (UP) ou similar;

g) Experiência em desenvolvimento na linguagem PHP 4.x (ou superior) e na utilização de frameworks;

h) Experiência em construção de aplicações web que utilize Framework de desenvolvimento PHP, principalmente: Zend Framework, CodeIgniter, SymPhony, CakePHP e Prado;

i) Experiência em desenvolvimento de aplicações utilizando as tecnologias XML e XML Schema, XSL e arquitetura de Web Services e SOA.

11.7.5.6. Requisitos do Projetista de interface / Webdesigner:

a) Curso superior completo na área de informática ou qualquer curso superior com especialização na área de artes gráficas;

b) Experiência na construção de sítios Web que utilizem as linguagens XHTML, CSS, Javascript, JSP e PHP;

c) Experiência na utilização de ferramentas para construção de páginas Web (Dreamweaver, Photoshop, Illustrator e Flash);

d) Experiência na utilização, customização e desenvolvimento de módulos para CMS (sistema de gestão de conteúdo);

e) Experiência na elaboração de protótipos, com a utilização de wireframes e/ou mookups;

f) Experiência na leitura de modelos UML.

11.7.5.7. Requisitos do Analista de Testes:

a) Curso superior completo na área de informática ou qualquer curso superior com especialização na área de informática;

b) Experiência como analista de testes;

c) Experiência como analista de requisitos;

d) Experiência nas metodologias e técnicas de teste (testes de caixa-preta, de caixa branca, de unidade, de integração, de componente, de sistema etc.).

11.7.5.8. Requisitos do Administrador de Dados (DA):

a) Curso superior completo na área de informática ou qualquer curso superior com especialização na área de informática;

b) Experiência na área de administração de dados;

c) Experiência em PostgreSQL 9.1 (ou superior), linguagem PL/PGSQL e ferramentas de Administração: PgAdmin e Stack Builder 2.1.0;

d) Experiência em ferramenta de modelagem de dados relacional e modelagem orientada a objetos;

e) Experiência na criação, execução, verificação e validação de script de banco de dados para rotinas DTS e processos ETL;

f) Experiência em levantamento e exploração de dados de sistemas legados, mapeamento de entidades e atributos, criação de dicionário de dados;

g) Experiência na criação de Jobs para manutenção de serviços integração de dados e do servidor SGBD-R.

11.7.6. A alocação dos profissionais nos times de desenvolvimento deverá respeitar a seguinte proporcionalidade:

11.7.6.1. Para cada dois profissionais de nível sênior, um profissional de nível Pleno;

11.7.6.2. Para cada dois profissionais de nível pleno, um profissional de nível Júnior;

11.7.7. Para cumprimento do item 11.7.6, consideram-se os seguintes requisitos:

a) Profissional de nível Sênior – Pelo menos 6 anos de experiência na atividade/perfil desempenhado.

b) Profissional de nível Pleno – Pelo menos 4 anos de experiência na atividade/perfil desempenhado.

c) Profissional de nível Júnior – Pelo menos 2 anos de experiência na atividade/perfil desempenhado.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

13.1.31. Disponibilizar a formalização dos procedimentos de instalação do serviço executado nos ambientes do CAU/BR (por intermédio das instruções para publicação da OS nos ambientes de homologação e produção, utilizando a integração contínua), contemplando todas as atividades técnicas necessárias, em todas as plataformas tecnológicas envolvidas, para que a solução desenvolvida esteja plenamente operacional no referido ambiente;

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

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

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

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

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

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

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

13.1.39. Assumir a responsabilidade por todas as providências e obrigações estabelecidas na legislação específica de acidentes de trabalho, quando, em ocorrência da espécie, forem vítimas os seus empregados quando da prestação dos serviços ou em conexão com

ela, ainda que acontecido em dependência do CAU/BR, inclusive por danos causados a terceiros;

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

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

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

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

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

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

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

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

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

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

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

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

13.1.52. Entregar ao CAU/BR, durante o período de transição inicial, relação nominal de todos os profissionais que atuarão na execução deste contrato, fornecendo os dados pessoais necessários e o seu papel de trabalho. Essa relação deverá ser mantida atualizada durante toda a vigência do contrato;

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

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

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

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

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

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

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

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

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

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

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

CAPÍTULO 14. DA ESTIMATIVA DE PREÇOS

14.1. O valor estimativo da contratação, por ponto de função, é de R$ 2.043.486,67 (dois milhões quarenta e três mil quatrocentos e oitenta e seis reais e sessenta e sete centavos), e o valor estimado por unidade de serviço técnico é de R$ 98.708,33 (noventa e oito mil setecentos e oito reais e trinta e três centavos), sendo o valor total máximo estimativo de até R$ 2.142.195,00 (dois milhões cento e quarenta e dois mil cento e noventa e cinco reais), para o período de 12 meses.

CAPÍTULO 15. DA DOTAÇÃO ORÇAMENTÁRIA

15.1. Os recursos necessários ao atendimento das despesas, que correrão à conta dos recursos orçamentários deste Conselho, Orçamento 2018, estão assim previstos:

Centro de Custos: 4.02.08.005 – Gestão da Coordenadoria Técnica do SICCAU – CORTEC;

Conta: 6.2.2.1.1.01.04.03.002 – SICCAU;

Conta: 6.2.2.1.1.02.01.03.010 – Serviços de Desenvolvimento de Sistemas;

CAPÍTULO 16. DA GARANTIA CONTRATUAL

16.1. Será exigida da CONTRATADA, no prazo máximo de 10 (dez) dias, a partir da assinatura do contrato, prestação de garantia contratual em favor do CAU/BR, correspondente a 5% (cinco por cento) do valor total do contrato, numa das seguintes modalidades:

16.1.1. Caução em dinheiro ou títulos da dívida pública federal.

16.1.2. Seguro-garantia.

16.1.3. Fiança bancária.

16.2. Caso a CONTRATADA opte por apresentar títulos da dívida pública, deverão ter valor de mercado compatível com aquele a ser garantido, preferencialmente em

consonância com as espécies recomendadas pelo Governo Federal, como os previstos no art. 2º da Lei nº 10.179/2001.

16.3. Caso o licitante opte pela caução em dinheiro, deve providenciar o depósito perante instituição financeira indicada pelo CAU/BR, em conta remunerada, para os fins específicos a que se destina, sendo o recibo de depósito o único meio hábil para comprovar essa exigência.

16.4. Se o valor da garantia for utilizado, total ou parcialmente, em pagamento de qualquer obrigação, a CONTRATADA deverá proceder à respectiva reposição no prazo de até 3 (três) dias úteis, contados da data em que for notificado pelo CAU/BR, sob pena de rescisão contratual, multa e responsabilização da CONTRATADA pelos danos eventuais causados ao CAU/BR.

16.5. A garantia somente será liberada ante a comprovação de que a adjudicatária pagou todas as verbas rescisórias trabalhistas decorrentes da contratação, e que, caso esse pagamento não ocorra até o fim do segundo mês após o encerramento da vigência contratual, a garantia será utilizada para o pagamento dessas verbas trabalhistas diretamente pelo CAU/BR.

16.6. A garantia será restituída à CONTRATADA após total cumprimento das obrigações pactuadas no contrato, nos termos da legislação vigente.

CAPÍTULO 17. DA METODOLOGIA DE AVALIAÇÃO DA QUALIDADE

17.1. Aderência à MGDS-CAU

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

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

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

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

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

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

17.1.2. Índice de Pontos com Defeito (PD)

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

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

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

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

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

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

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

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

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

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

17.2. Fábrica de Software (FSW)

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

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

17.3. Termo de Recebimento Provisório (TRP)

17.3.1. A emissão do Termo de Recebimento Provisório (TRP) contemplará entregas que contenham todos os artefatos previstos, no caso dos códigos-fontes, disponibilizados no

ambiente do CAU/BR (desenvolvimento e/ou homologação), de forma que seja possível o início do processo de homologação técnica e/ou funcional da solução.

17.4. Termo de Recebimento Definitivo (TRD)

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

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

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

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

17.5. Inspeções e Diligências

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

17.6. Níveis de Serviço

17.6.1. A execução das demandas do tipo projeto, sustentação, serviços e/ou metrificação de sistemas de informação terá sua qualidade medida por meio de Nível de Serviço;

17.6.2. O CAU/BR poderá submeter os programas produzidos pela empresa CONTRATADA a testes em ferramentas especializadas para avaliação da qualidade dos serviços, auxiliando a emissão do Termo de Recebimento Provisório (TRP) e Termo de Recebimento Definitivo (TRD);

17.6.3. Os ajustes propostos em função da utilização destas ferramentas serão efetuados pela empresa CONTRATADA sem custo adicional para o CAU/BR, respeitando os requisitos não funcionais elaborados anteriormente e os padrões previamente estabelecidos, mesmo que a execução do procedimento de avaliação tenha ocorrido após emissão de TRP e TRD;

17.6.4. O estabelecimento do índice aceitável de defeitos (IP) não exime a empresa CONTRATADA da obrigação de correção dos erros identificados, independentemente da quantidade, sem ônus para o CAU/BR;

17.6.5. Caso não sejam observados os prazos para atendimento previstos no item 17.7, serão aplicados os fatores de redução (FRA) e caso a quantidade de erros identificados por ponto de função ultrapasse o previsto na tabela abaixo, serão aplicados os fatores de redução (FRE). Em ambos os casos, serão aplicadas as multas previstas, calculadas sobre o valor da(s) respectiva(s) demanda(s), conforme o disposto no Capítulo 23 deste Termo de Referência.

ID	Etapa/Fase/Item	Indicador	Valor Máximo Aceitável
			Valor máximo aceitável do indicador IDP:
	Fábrica de		<= 115% (cento e quinze por cento)
	Software: Entrega
1	para homologação do usuário (prazos precisam prever todas as etapas anteriores à etapa de	Índice de Entrega dentro do Prazo (IDP) – por OS
			Valor do indicador IDP deve ser: <= 100% (cem por cento)
				homologação		Fórmula IDP = Quantidade de dias úteis
	usuário)		apurados na execução da OS / Quantidade de
			dias úteis máximos previstos da OS x 100
	Fábrica de Software: Defeitos identificados por	Defeitos (erros) por Pontos de Função (PD)	Valor máximo aceitável deste índice PD: <= 0,25 (vinte e cinco décimos)
	ponto de função -
			2	Índice de Pontos de	Valor do indicador PD deve ser:
	Defeito (PD) e		= 0 (zero)
	poderá ser apurado na entrega parcial ou integral da OS
			Fórmula PD = Quantidade de erros registrados na OS / Quantidade de Pontos de Função da OS
				Valor máximo aceitável do indicador IDP:
			<= 110% (cento e dez por cento)
3	Transferência de Conhecimento e Consultoria: Entrega Final	Índice de Entrega dentro do Prazo (IDP) – por OS
			Valor do indicador IDP deve ser: <= 100% (cem por cento)
			Fórmula IDP = Quantidade de dias úteis
			apurados na execução da OS / Quantidade de
			dias úteis máximos previstos da OS x 100

17.7. Prazo de Atendimento

17.7.1. Os serviços deverão ser iniciados de acordo com os prazos estabelecidos a seguir:

Projeto, Sustentação (exceto manutenção corretiva) e Serviço
Tamanho do serviço em Pontos de Função	Prazo máximo para início do serviço (em dias úteis)
1 a 49	2 dias
50 a 149	5 dias
150 a 500	7 dias
Acima de 500	15 dias

Sustentação (Manutenção Corretiva)
Criticidade	Característica	Início de Atendimento
Nível 1	Incidente com paralisação do sistema ou comprometimento grave de dados, processo ou ambiente.	Em até 06 (seis) horas corridas após informado o incidente / paralisação à CONTRATADA.
Nível 2	Incidente sem paralisação do sistema, porém, com comprometimento mediano de dados, processo ou ambiente.	Em até 24 (vinte e quatro) horas corridas após informado o incidente/paralisação à CONTRATADA.
Nível 3	Incidente sem paralisação do sistema e pequeno ou nenhum comprometimento de dados, processo ou ambiente.	Em até 72 (setenta e duas) horas corridas após informado o incidente/paralisação à CONTRATADA.

17.7.2. Prazos de Atendimento Projeto e Sustentação;

17.7.2.1. Para demanda maior ou igual a 100 PF; Cálculo do Prazo (mês) = V^t*21 (dias úteis);

Onde:

V: tamanho do projeto em Pontos de Função. t: 0,32

17.7.2.2. Para demanda menor que 100 PF

Tamanho do Projeto	Prazo máximo (em dias úteis)
Até 4 PF	5 dias
4 a 8 PF	10 dias
8 a 10 PF	13 dias
11 a 20 PF	25 dias
21 a 30 PF	37 dias
31 a 40 PF	50 dias
41 a 50 PF	62 dias

51 a 60 PF	75 dias
61 a 70 PF	82 dias
71 a 85 PF	87 dias
86 a 99 PF	91 dias

17.7.2.3. A empresa CONTRATADA poderá solicitar, ainda, um prazo adicional, quando justificada e comprovada a necessidade, em função de complexidade do serviço a ser executado, ficando a critério do CAU/BR, aceitar ou não as justificativas e o novo prazo apresentado pela empresa CONTRATADA.

17.7.2.4. O prazo adicional deverá ser solicitado em até, no máximo, 1 (um) dia útil após o recebimento da OS e, no caso de aceito pelo CAU/BR, será adicionado ao prazo total do serviço ou projeto contratado;

17.7.2.5. Caso a justificativa não atenda ao CAU/BR, prevalecerá o prazo inicialmente estipulado;

17.7.2.6. A solicitação de prazo adicional para atendimento não justifica a suspensão do atendimento pela empresa CONTRATADA e, durante o julgamento da solicitação pelo CAU/BR, ficam mantidas as condições estipuladas para o serviço;

17.7.2.7. Caso o prazo de execução proposto pela empresa CONTRATADA não atenda às necessidades do CAU/BR novos prazos poderão ser apresentados.

17.8. Estimativa de volume de bens/serviços

17.8.1. Após avaliação baseada em levantamento dos sistemas de informação em utilização no CAU/BR e a necessidade de novos sistemas de informação, bem como a definição determinada pelo Colegiado de Governança do CSC, a estimativa de Pontos de Função previstos para a execução em 12 (doze) meses é de 2.000 (dois mil);

Equivalência de esforço por Ponto de Função (unidade) PROJETO e SUSTENÇÃO
Etapa de Desenvolvimento	Percentual de esforço
Engenharia de Requisitos	25 %
Análise / Projeto Técnico	10 %
Implementação	40 %
Testes	15 %
Homologação	5 %
Implantação	5 %

17.8.2. Toda a documentação está prevista nas etapas acima descritas, sem ônus adicional ao CAU/BR.

17.8.3. A remuneração dos serviços demandados considerará os percentuais (%) de esforços executados.

17.8.4. Para cada ponto de função das demandas do tipo “Serviço”, quando não mensuráveis pela técnica de Análise em Pontos de Função pelo “Roteiro de Métrica de Software” do SISP v.2.2 (ou superior) (xxxx://xxx.xxxxxxxxxxxxxxxxx.xxx.xx) e o “Function Point Counting Practices Manual (CPM)”, versão 4.3.1 (ou superior), deverá ser

considerada e equivalência do ponto de função com o esforço de desenvolvimento conforme abaixo:

Equivalência do Ponto de Função para o esforço de desenvolvimento das demandas do tipo “Serviço”
Demandas do tipo “Serviço”	Equivalência de Esforço (produtividade)
01 (um) Ponto de Função de Serviço	10 dez) horas

17.8.5. Toda a documentação para a demanda do tipo “Serviço” deverá estar previsto no esforço (produtividade) indicado para sua execução.

17.8.6. Para cada Ponto de Função (PF) sua equivalência de esforço (produtividade) em horas é de 10 (dez) horas, o cálculo das frações obedecerá ao que segue.

17.8.6.1. Para cálculo do pagamento das demandas do tipo “Serviço”:

a) Caso o Serviço esteja contemplado no Roteiro de Métricas do SISP v 2.2 (ou superior), considerar a fórmula existente neste Roteiro;

b) Para os casos não tratados no Roteiro de Métricas do SISP v 2.2 (ou superior), considerar a seguinte fórmula:

Equivalência em PF = (Esforço da Atividade (H)/10) * Valor do PF de Serviço

17.9. Prazos e Condições

17.9.1. O prazo máximo para entrega dos serviços será o previsto no item 17.7 deste Termo de Referência;

17.9.2. O objeto do contrato deverá ser disponibilizado no ambiente do CAU/BR, com todos os artefatos previstos, no prazo pactuado e será recebido da seguinte forma:

a) Provisoriamente: até 15 (quinze) dias após o ato de entrega, para efeito de posterior verificação da conformidade da demanda com o requisitado na Ordem de Serviço;

b) Definitivamente: 5 (cinco) dias úteis para as demandas com prazo de entrega previsto em até 20 dias (úteis) e nas demais em até 25% do prazo de entrega (contados em dia útil) a partir do recebimento provisório (TRP) e após a verificação da qualidade e quantidade do material e sua consequente aceitação, mediante a emissão do Termo de Recebimento Definitivo assinado pelas partes.

17.9.3. Os problemas identificados nas demandas serão formalmente informados ao preposto, considerando todas as exigências deste Termo de Referência (técnicas e recebimento). A empresa CONTRATADA será notificada a proceder à devida regularização ou correção das demandas não aceitas pelo CAU/BR, e deverá iniciar as correções em prazo não superior a 5 (cinco) dias corridos, contados da notificação da rejeição.

17.9.4. Somente após a verificação da compatibilidade entre o objeto contratado e o executado, bem como a qualidade e a integridade dos serviços prestados, o CAU/BR emitirá o Termo de Recebimento Definitivo (TRD).

17.9.5. Para o recebimento definitivo das demandas, além da verificação da conformidade com a MGDS-CAU, serão consideradas as metas alcançadas dos níveis de serviço IDP e IP;

17.9.6. O recebimento provisório ou definitivo não exclui a responsabilidade civil pela solidez e segurança do serviço, nem a ético-profissional pela perfeita execução do

contrato, dentro dos limites estabelecidos pela lei.

CAPÍTULO 18. DO PAGAMENTO

18.1. Os pagamentos serão realizados após a apresentação do documento fiscal exigível em conformidade com a legislação de regência e com eles as informações sobre o banco, agência e número da conta corrente da CONTRATADA.

18.2. A CONTRATADA deverá encaminhar o documento fiscal exigível, discriminando todas as importâncias devidas, correspondentes aos serviços efetivamente prestados.

18.3. O documento fiscal deverá destacar as retenções previstas na Instrução Normativa RFB nº 1.234, de 11 de janeiro de 2012, também sendo realizada nos moldes da Lei Complementar nº 116/2003 e outras legislações pertinentes.

18.4. Na hipótese de a CONTRATADA ser optante do Simples, a fim de fazer incidir a não retenção de tributos, conforme art. 4º, XI, da Instrução Normativa RFB nº 1.234/2012, deverá anexar à fatura declaração devidamente assinada por seu representante legal, sob as penas da lei.

18.5. Recebido o documento fiscal exigível, o CAU/BR providenciará sua aferição e aceitação, realizando o pagamento no prazo de 10 (dez) dias úteis, contados do atesto da respectiva nota fiscal/fatura.

18.6. O atraso no pagamento do documento fiscal emitido, desde que a CONTRATADA não tenha concorrido de alguma forma para tanto, sujeitará o CAU/BR ao pagamento de juros moratórios de 0,5% (cinco décimos por cento) ao mês, até o efetivo pagamento, além da devida atualização monetária.

18.7. O CAU/BR reserva-se no direito de não efetuar o pagamento se, no ato da atestação, a prestação dos serviços não atender as situações descritas neste Termo de Referência, inclusive no caso de a CONTRATADA deixar de apresentar a documentação de regularidade fiscal para com o Fundo de Garantia do Tempo de Serviço, Instituto Nacional do Seguro Social, as Fazendas Públicas Federal, Estadual ou do Distrito Federal e Municipal, e regularidade trabalhista.

18.8. O CAU/BR não pagará qualquer valor não constante ou fora dos critérios estabelecidos neste Termo de Referência.

18.9. Nenhum pagamento será efetuado à CONTRATADA enquanto pendente de liquidação qualquer obrigação financeira em virtude de penalidade ou inadimplência contratual, sem que isso gere direito à alteração dos preços, ou de compensação financeira por atraso de pagamento.

18.10. O CAU/BR poderá deduzir do montante a pagar os valores correspondentes a multas ou indenizações devidas pela CONTRATADA, conforme este Termo de Referência.

18.11. Havendo erro na emissão do documento de cobrança ou circunstância que impeça a liquidação da despesa, como rasuras, entrelinhas, ou falta de algum dos documentos descritos no subitem 18.4, a nota fiscal/fatura será devolvida à CONTRATADA e o pagamento ficará pendente até que sejam sanados os problemas.

18.12. Nesta hipótese, o prazo para pagamento será reiniciado após a regularização da situação ou reapresentação dos documentos, não acarretando quaisquer ônus para o CAU/BR.

18.13. A simples existência da relação contratual sem a contraprestação do serviço não enseja nenhum pagamento à CONTRATADA.

18.14. O CAU/BR não se responsabilizará pelo pagamento de quaisquer serviços realizados sem a solicitação e autorização do fiscal do contrato.

18.15. O CAU/BR poderá reter pagamentos equivalentes a quantias suficientes à garantia de eventuais indenizações trabalhistas, até o trânsito em julgado das respectivas sentenças, sendo que a licitante ressarcirá o CAU/BR de qualquer despesa que este vier a ser condenado a pagar.

18.16. A CONTRATADA deverá aceitar, nas mesmas condições contratuais, os acréscimos ou supressões que se fizerem necessários até o limite de 25% (vinte e cinco por cento) do valor global do contrato, conforme previsto no Art. 65, §1º, da Lei 8.666/1993.

CAPÍTULO 19. DA PROPRIEDADE, SIGILO E RESTRIÇÕES

19.1. Direito de Propriedade

19.1.1. A empresa CONTRATADA deverá manter sigilo, sob pena de responsabilidade civil, penal e administrativa, sobre todo e qualquer assunto de interesse do CAU/BR ou de terceiros de que tomar conhecimento em razão da execução do contrato, respeitando todos os critérios estabelecidos, aplicáveis aos dados, informações, regras de negócios, documentos, entre outros pertinentes;

19.1.2. A empresa CONTRATADA deverá manter sigilo absoluto sobre quaisquer dados, informações, códigos-fonte, artefatos, contidos em quaisquer documentos e em quaisquer mídias, incluindo os coletores de dados e seus meios de armazenamento, de que venha a ter conhecimento durante a execução dos trabalhos de levantamento de requisitos, construção, implantação e execução dos serviços, não podendo, sob qualquer pretexto divulgar, reproduzir ou utilizar, sob pena de lei, independentemente da classificação de sigilo conferida pelo CAU/BR a tais documentos;

19.1.3. O CAU/BR, para todos os efeitos da aplicação da Lei n.º 9.609/98, que dispõe sobre a proteção da propriedade intelectual de programa de computador, e regulamentos correlatos, é o único proprietário dos produtos entregues pela prestadora de serviços;

19.1.4. O CAU/BR terá o direito de propriedade intelectual do software e respectivos componentes, bem como de todos os artefatos gerados nas etapas de fabricação de forma permanente, sendo permitido, a qualquer tempo, distribuir, alterar e utilizar o software sem limitações de quaisquer licenças restritivas;

19.1.5. Todo produto resultante de análise, código-fonte, documentação, objetos, bibliotecas, classes, rotinas e outros, serão de propriedade intelectual e exclusiva do CAU/BR, não podendo ser reproduzidos ou utilizados para quaisquer outras finalidades;

19.1.6. A empresa CONTRATADA deverá ceder ao CAU/BR o direito patrimonial e a propriedade intelectual de toda e qualquer documentação e produtos gerados antes do recebimento definitivo dos serviços prestados;

19.1.7. A empresa CONTRATADA deverá manter sigilo dos dados e das informações confidenciais a que tiver acesso;

19.1.8. A empresa CONTRATADA deverá manter o sigilo e a confidencialidade dos dados que serão utilizados pelo software;

19.1.9. Acerca dos sistemas e bases de dados existentes na instituição que compõem o escopo do objeto de que trata este TR, o CAU/BR irá permitir à empresa CONTRATADA livre acesso aos códigos-fonte e dados mediante assinatura de Termo de Confidencialidade (Encarte F);

19.1.10. Os artefatos do sistema serão de uso proprietário do CAU/BR, inclusive seus códigos-fonte e documentação;

19.1.11. As soluções desenvolvidas estarão sob licença de uso restrito ao CAU/BR, protegidos por direitos autorais e de propriedade. A cópia, redistribuição, engenharia reversa e modificação do software proprietário são proibidas por parte da empresa CONTRATADA sem anuência do CAU/BR;

19.1.12. Os dados, artefatos, softwares e informações da organização não poderão ser distribuídos, divulgados e comercializados pela empresa CONTRATADA.

19.2. Condição de Manutenção de Sigilo

19.2.1. A empresa CONTRATADA deve cumprir normas estabelecidas no Regulamento Interno de Segurança da Informação do CAU/BR para o acesso, manuseio, tratamento, controle e proteção das informações e dados (disponível em xxxx://xxxxxxxxxxxxx.xxxxx.xxx.xx);

19.2.2. A empresa CONTRATADA deve adotar critérios para sigilo, uso e proteção das informações, além da adoção de mecanismos físicos de proteção aos equipamentos e dispositivos utilizados na execução do contrato;

19.2.3. É de responsabilidade exclusiva da empresa CONTRATADA aferir e adotar critérios para avaliação da vida pregressa dos seus funcionários, certificando-se que estes tenham comportamento irrepreensível e idoneidade moral inatacável, com o propósito de evitar a incorporação no contrato de pessoas com características e/ou antecedentes que possam comprometer a segurança ou credibilidade do CAU/BR;

19.2.4. A empresa CONTRATADA e seus empregados devem manter sigilo absoluto sobre informações, dados e documentos que venham a ter conhecimento quando da realização dos serviços, para isso será formalizado Termo de Compromisso (Encarte F) e Termo de Ciência (Encarte G).

19.3. Mecanismos Formais de Comunicação

19.3.1. Solicitações formais por escrito para fornecimento, emissão de Nota Fiscal, pedidos de esclarecimentos e demais solicitações relacionadas com o objeto serão feitas pelo Gestor ou pelo Fiscal do contrato à empresa CONTRATADA;

19.3.2. A empresa CONTRATADA deverá propor um plano de comunicação, que contenha os procedimentos e responsáveis aos quais devem ser dirigidas as comunicações formais no âmbito da execução contratual. O plano deverá ser aprovado e aceito pelo CAU/BR;

19.3.3. A empresa CONTRATADA se obriga a disponibilizar, em até 30 (trinta) dias a contar da assinatura do contrato, sem custo adicional para o CAU/BR, os seguintes canais de atendimento a partir da entrega do primeiro Termo de Compromisso, do contrato:

a) Telefone;

b) Email;

c) Ferramenta de Gestão de Demandas de TI (OS);

d) Ferramenta de Gestão de Defeitos (Ticket);

e) Central para acionamento das ocorrências de pronto atendimento (equipe de Sustentação).

19.3.4. Os canais e-mail e/ou ferramenta de Gestão de Demandas de TI (OS) deverão prever recepção e tratamento diferenciado das demandas, por tipo de serviço e por

criticidade e a possibilidade de acompanhamento pelo CAU/BR de todo o processo de atendimento;

19.3.5. A ferramenta de Gestão de Demandas de TI (OS) deverá prover ao CAU/BR informação detalhada da execução dos serviços, em tempo real, com conexão segura, bem como permitir ao CAU/BR acompanhar a execução e verificar os índices de desempenho dos serviços contratados;

19.3.6. A comunicação entre as partes envolvidas no processo de atendimento das demandas deve ser, preferencialmente, por Ordem de Serviço registrada pela ferramenta de Gestão de Demanda, sendo prevista comunicação por e-mail, reuniões presenciais e suas respectivas atas;

19.3.7. A empresa CONTRATADA fica responsável pela manutenção da(s) ferramenta(s) de comunicação em funcionamento, sem erros, durante toda a vigência do contrato;

19.3.8. No período máximo de 15 dias, deverão ser realizadas reuniões de acompanhamento, onde deverão estar presentes o Preposto indicado pela empresa CONTRATADA, o Gestor do contrato, os fiscais do contrato e demais envolvidos ou interessados.

CAPÍTULO 20. DA RESPONSABILIDADE CIVIL

20.1. A CONTRATADA responderá por quaisquer prejuízos ou danos, por culpa ou dolo, causados por seus empregados ou prepostos ao CAU/BR e/ou a terceiros, em decorrência da prestação dos serviços, seja a que título for;

20.2. O CAU/BR estipulará prazo para a devida reparação, a depender da gravidade e extensão dos danos.

CAPÍTULO 21. DO CONTRATO

21.1. Após a adjudicação e homologação do procedimento licitatório, convocar-se-á o licitante vencedor para assinatura do instrumento contratual, que deverá ocorrer, impreterivelmente, no prazo de até 5 (cinco) dias úteis, a contar da comunicação, sob pena de decair do direito à contratação e sem prejuízo das sanções previstas neste Termo de Referência e no art. 81 da Lei nº 8.666, de 1993.

21.2. O prazo para assinatura do contrato poderá, em situação excepcionalíssima, ser prorrogado uma única vez, por igual período, quando solicitado pelo licitante vencedor em até 48h (quarenta e oito horas), a contar do recebimento da comunicação constante do item 21.1, desde que ocorra motivo relevante e aceito pelo CAU/BR.

21.3. Na celebração do contrato e caso haja renovações, serão exigidas as mesmas condições de habilitação.

21.4. O contrato a ser assinado com o licitante vencedor terá vigência de 12 (doze) meses, contados da data da assinatura, podendo, atendidos a oportunidade e conveniência do CAU/BR, e sob condições vantajosas, ser prorrogado mediante termo aditivo, por iguais e sucessivos períodos, nos termos do art. 57, II, da Lei nº 8.666, de 1993.

21.5. Pela inexecução total ou parcial do contrato poderá, garantidos o contraditório e a ampla defesa, ser aplicada à CONTRATADA as sanções de que tratam os arts. 86 a 88 da Lei nº 8.666, de 1993, bem como as sanções e penalidades previstas neste Termo de Referência.

CAPÍTULO 22. DA PROVA DE CONCEITO

22.1. A empresa licitante provisoriamente classificada em primeiro lugar será informada via chat a data e a hora da prova de conceito que deverá realizar como parte do processo licitatório;

22.2. A empresa licitante terá o prazo máximo de 9 (nove) dias úteis, em horário comercial, a contar da data marcada para a prova de conceito, descrita no item anterior, para concluir a prova de conceito estipulada pelo CAU/BR;

22.3. A empresa licitante é responsável em prover todos os recursos computacionais necessários para realização da prova de conceito, incluindo hardwares e softwares com respectivas licenças a serem utilizados para execução da prova de conceito;

22.4. O CAU/BR, não disponibilizará recursos computacionais de apoio à empresa licitante, como acesso à Internet, periféricos, softwares, entre outros;

22.5. Não caberá ao CONTRATANTE, sob qualquer hipótese, o pagamento de qualquer valor ou indenização em virtude da realização da demonstração, seja ela rejeitada ou não. Portanto, todos os custos decorrentes da participação na Prova de Conceito ficarão a cargo da LICITANTE;

22.6. A Prova de Conceito consiste em executar 1 (uma) OS - Ordem de Serviço, contendo demandas fictícias totalizando no máximo 10 (dez) pontos de função, a título de prova de conceito a qual se destinará à verificação da conformidade e qualidade dos artefatos produzidos e do desempenho técnico do licitante;

22.7. A solução de software será avaliada em máquina virtual configurada pela empresa licitante contendo solução de software desenvolvida, conforme requisitos especificados pelo CAU/BR na prova de conceito;

22.8. Caso o CAU/BR emita o aceite da OS, será confirmada a classificação;

22.9. Caso o CAU/BR emita a recusa da OS em função do resultado de sua validação, a empresa licitante participante da Prova de Conceito terá sua proposta desclassificada, e será chamada a próxima empresa licitante habilitada, para executar o proposto na Prova de Conceito e, assim sucessivamente seguindo a ordem da prévia classificação e habilitação no processo licitatório;

22.10. Este ciclo será repetido até que o CAU/BR adjudique um licitante no certame;

22.11. Caso nenhum licitante seja aprovado na prova de conceito o CAU/BR fará novo processo licitatório;

22.12. Os documentos constantes da prova de conceito serão entregues para a empresa licitante na data marcada para realização da prova de conceito;

22.13. É de responsabilidade da empresa licitante a obtenção de todas as informações do ambiente especificado pelo CAU/BR necessárias para execução da prova de conceito;

22.14. O “Checklist da Avaliação e Resultado” da prova de conceito, constante no Encarte L deste Termo de Referência, contém todos os critérios que serão usados para pontuar e indicar se a empresa licitante foi ou não aprovada;

22.15. Os requisitos que deverão ser implementados, que declaram as restrições e especificam a qualidade mínima da solução de software serão descritos no documento “Requisitos Funcionais e Não Funcionais”;

22.16. A “Planilha de Contagem de Pontos de Função” conterá todas as funcionalidades da solução de software que deverão ser desenvolvidas no qual a empresa licitante registrará a quantidade de pontos de função por funcionalidade;

22.17. Serão disponibilizados à empresa licitante, durante o período da Prova de Conceito, artefatos para proporcionar maior esclarecimento ao processo, sendo estes:

a) Checklist da Avaliação e Resultado da Prova de Conceito;

b) Documento de Visão;

c) Especificação de Requisitos Funcionais e não-funcionais;

d) Regras de Negócio;

e) Diagrama de Caso de Uso;

f) Planilha de Contagem de Pontos de Função;

g) Templates da MGDS-CAUBR.

22.18. A solução de software desenvolvida e demais artefatos constantes da prova de conceito a serem entregues pela empresa licitante serão avaliados conforme consta no item referente ao Checklist da Avaliação;

22.19. Os artefatos requisitados pela Prova de Conceito e que serão avaliados pelo Checklist da Avaliação são os que seguem:

a) Planilha de Contagem de Pontos de Função (Preenchida);

b) Casos de Uso Detalhado;

c) Casos de Testes

d) Documento de Mensagem;

e) Documento de Arquitetura;

f) Testes Unitários;

g) Termo de Entrega do Produto;

h) Código Fonte;

i) Mídia Digital – CD (Contendo todos os artefatos das alíneas anteriores).

22.20. Os artefatos produzidos pela empresa licitante serão avaliados com base nos templates fornecidos pelo CAU/BR;

22.21. A empresa licitante será automaticamente reprovada na prova de conceito caso entregue algum artefato que não tenha sido gerado a partir dos templates fornecido pelo CAU/BR;

22.22. Após a entrega dos artefatos e da solução de software para avaliação, não serão permitidas quaisquer alterações neles;

22.23. A empresa licitante deverá fornecer, antes da avaliação dos artefatos e produto de software, uma cópia, em mídia digital para arquivamento, contendo todos os artefatos produzidos durante a prova de conceito;

22.24. A cópia ficará em posse do CAU/BR e fará parte dos autos do certame, juntamente com os demais documentos do processo;

22.25. A validação dos itens do checklist será realizada por grupo técnico de servidores do CAU/BR, sendo a empresa licitante responsável em comprovar o atendimento dos itens;

22.26. As justificativas e observações relativas aos itens a serem avaliados no checklist serão preenchidos pelos servidores do CAU/BR;

22.27. Será permitido o acompanhamento da avaliação a quaisquer interessados, desde que não haja quaisquer interferências na condução do processo e em número de pessoas condizente com as instalações do local onde será realizada a sessão.

22.28. A máquina física onde estiver sendo executada a solução de software desenvolvida deverá, no momento da avaliação, estar desconectada da rede local e da internet, totalmente isolada de qualquer comunicação externa;

22.29. A avaliação do software que venha fazer uso da internet durante sua a execução não isenta a responsabilidade e possíveis penalidades da empresa licitante pelo mal funcionamento do software avaliado;

22.30. Será desclassificada a LICITANTE:

22.30.1. Que não realizar a demonstração solicitada, na data estabelecida.

22.30.2. Que não atender algum dos itens obrigatórios do Checklist “Itens Eliminatórios”;

22.30.3. Que não atingir o valor, igual ou maior, de 80% (oitenta por cento) do valor do Índice de conformidade da prova de conceito de acordo com a fórmula abaixo:

Índice de Conformidade = (Qtd. Pontos Obtidos / Qtd. Total de Pontos Possíveis) x 100 Onde:

Qtd. Pontos Obtidos: Quantidade de itens do checklist pontuados pelo licitante, de acordo com os requisitos descritos pelo CONTRATANTE;

Qtd. Total de Ponto Possíveis: Quantidade total pontos possíveis de obter dentro do checklist entregue pelo CONTRATANTE.

22.31. A Pontuação obtida nos “Itens Pontuadores” poderá ser “Integral” (100% da pontuação do item em questão), “Parcial” (50% da pontuação do item em questão) ou “Nenhuma” (0% da pontuação do item em questão). Sendo que:

22.31.1. A pontuação “Integral” será obtida caso o CAUBR julgue que a solução da licitante está em total conformidade com o que foi solicitado no item avaliado;

22.31.2. A pontuação “Parcial” será obtida caso o CAUBR julgue que a solução da licitante apresenta desconformidade PONTUAL e que não prejudica e nem compromete a essência do que foi solicitado no item avaliado;

22.31.3. A pontuação “Nenhuma” será obtida caso o CAUBR julgue que a solução da licitante apresente algo totalmente diferente do solicitado e/ou que apresente erros relevantes na solução apresentada.

22.32. A LICITANTE que, devidamente convocada para a Prova de Conceito, não comparecer e nem apresentar justificativa para essa falta, além de ser desclassificada no certame, ficará sujeita às sanções previstas no art. 7º da Lei nº 10.520, de 2002, respeitado o rito para a aplicação de penalidades.

22.33. O Pregoeiro do CAU/BR considerará como vencedora a proposta que apresentar o menor preço global, após ser considerada classificada na Prova de Conceito e cumpridos os requisitos da habilitação.

CAPÍTULO 23. DAS SANÇÕES ADMINISTRATIVAS

23.1. Incorre em infração administrativa, nos termos da Lei nº 8.666, de 1993 e da Lei nº 10.520, de 2002, a CONTRATADA que:

23.1.1. Inexecutar total ou parcialmente qualquer das obrigações assumidas em decorrência da contratação;

23.1.2. Ensejar o retardamento da execução do objeto;

23.1.3. Fraudar a execução do contrato;

23.1.4. Comportar-se de modo inidôneo;

23.1.5. Cometer fraude fiscal;

23.1.6. Não manter a proposta apresentada.

23.2. A CONTRATADA que cometer qualquer das infrações discriminadas no subitem acima ficará sujeita, sem prejuízo da responsabilidade civil e criminal, às seguintes sanções:

23.2.1. Advertência por faltas leves, assim entendidas aquelas que não acarretem prejuízos significativos para o CONTRATANTE;

23.2.2. Multa moratória de 0,5% (meio por cento) por dia de atraso injustificado sobre o valor da parcela inadimplida, até o limite de 30 (trinta) dias;

23.2.3. Multa compensatória de 10% (dez por cento) sobre o valor total do contrato, no caso de inexecução total do objeto;

23.2.3.1. Em caso de inexecução parcial, a multa compensatória, no mesmo percentual do subitem acima, será aplicada de forma proporcional à obrigação inadimplida.

23.2.4. Suspensão do direito de licitar e impedimento de contratar com o CAU/BR, pelo prazo de até dois anos;

23.2.5. Impedimento de licitar e contratar com a União, e consequente descredenciamento no SICAF pelo prazo de até cinco anos;

23.2.6. Declaração de inidoneidade para licitar ou contratar com a administração pública, enquanto perdurarem os motivos determinantes da punição ou até que seja promovida a reabilitação perante a própria autoridade que aplicou a penalidade, que será concedida sempre que a CONTRATADA ressarcir a CONTRATANTE pelos prejuízos causados;

23.3. Também ficam sujeitas às penalidades do art. 87, III e IV da Lei nº 8.666, de 1993, a CONTRATADA que:

23.3.1. Tenha sofrido condenação definitiva por praticar, por meio dolosos, fraude fiscal no recolhimento de quaisquer tributos;

23.3.2. Tenha praticado atos ilícitos visando a frustrar os objetivos da licitação;

23.3.3. Demonstre não possuir idoneidade para contratar com a administração em virtude de atos ilícitos praticados.

23.4. A aplicação de qualquer das penalidades previstas realizar-se-á em processo administrativo que assegurará o contraditório e a ampla defesa à CONTRATADA, observando-se o procedimento previsto na Lei nº 8.666, de 1993, e subsidiariamente a Lei nº 9.784, de 1999;

23.5. A autoridade competente, na aplicação das sanções, levará em consideração a gravidade da conduta do infrator, o caráter educativo da pena, bem como o dano causado ao CONTRATANTE, observado o princípio da proporcionalidade;

23.6. As penalidades serão obrigatoriamente registradas no SICAF.

23.7. As hipóteses de rescisão contratual serão regidas pelos artigos 77 a 80 da Lei nº 8.666, de 1993.

23.8. A aplicação da multa não impede que o CAU/BR rescinda unilateralmente o contrato e aplique as demais sanções previstas neste item;

23.9. Será facultado à empresa CONTRATADA a apresentação de defesa prévia no prazo de 05 (cinco) dias, após a notificação, para as penalidades: advertência, multa e suspensão e de 10 (dez) dias para a penalidade de declaração de inidoneidade;

23.10. Decorridos 20 (vinte) dias sem que a empresa CONTRATADA tenha, sem justificativa plausível, iniciado a prestação da obrigação assumida, estará caracterizada a inexecução contratual, ensejando a sua rescisão;

CAPÍTULO 24. DA VIGÊNCIA

24.1. O prazo de vigência do contrato será de 12 (doze) meses, contado da data da assinatura, podendo, por interesse da administração, ser prorrogado por sucessivos períodos, nos termos do inciso II do art. 57 da Lei nº 8.666, de 1993 e alterações

posteriores. A partir da primeira renovação, será incluída cláusula que possibilitará rescindir o contrato antecipadamente, mediante justificado interesse da administração, sendo realizada comunicação com antecedência mínima de 30 (trinta) dias, sem que tal ato gere direito a quaisquer indenizações.

CAPÍTULO 25. DO REAJUSTE DE PREÇOS

25.1. Decorrido o prazo de 12 (doze) meses da data da apresentação da proposta, poderá a CONTRATADA fazer jus ao reajuste do valor contratual que deverá retratar a variação efetiva do custo de produção ou dos insumos utilizados na consecução do objeto contratual, limitado pelo Índice Nacional de Preços ao Consumidor (INPC), na forma do que dispõem o art. 40, XI, da Lei nº 8.666, de 1993 e os art. 2º e 3º da Lei nº 10.192, de 2001.

25.2. Os reajustes deverão ser precedidos de solicitação da CONTRATADA.

25.3. A CONTRATADA poderá exercer, perante o CONTRATANTE, seu direito ao reajuste dos preços do contrato até a data da prorrogação contratual subsequente.

25.3.1. Caso a CONTRATADA não solicite tempestivamente o reajuste e prorrogue o contrato sem pleiteá-lo, ocorrerá a preclusão do direito de reajustar.

25.4. O CONTRATANTE deverá assegurar-se de que os preços contratados são compatíveis com aqueles praticados no mercado, de forma a garantir a continuidade da contratação mais vantajosa.

CAPÍTULO 26. DAS DISPOSIÇÕES FINAIS

26.1. Esclarecimentos relativos ao Termo de Referência serão prestados pela Gerência Administrativa, no horário de 9h00 às 12h00 e 14h00 às 18h00, no endereço SCS Quadra 02, Bloco “C”, Enxxxxx 00, Xxxx 000 x 409, Edifício Serra Dourada, CEP: 00000-000, no telefone: (00) 0000-0000 ou, ainda, por e-mail, no endereço eletrônico xxxxxxxxx@xxxxx.xxx.xx.

À consideração superior,

Brasília-DF, 23 de outubro de 2018.

XXXXXX XXXXXXX

Gerente do CSC

De acordo. Aprovo o Termo de Referência nos moldes delineados, à vista de todo o detalhamento descrito e encaminho à Comissão de Licitação para as providências devidas quanto a elaboração do edital de licitação e demais procedimentos.

XXXXXX XXXXXXXX

Gerente Executivo do CAU/BR

ENCARTE B: MGDS-CAU

METODOLOGIA DE GESTÃO EM DESENVOLVIMENTO DE SOFTWARE DO CONSELHO DE ARQUITETURA E URBANISMO (VERSÃO 3.0)

1. Introdução

A Gerência de Serviços Compartilhados (GESC) vem desenvolvendo ações voltadas à implementação dos direcionamentos estratégicos definidos pelos órgãos orientadores, normativos e fiscalizadores do Governo Federal para a Administração Pública.

Neste sentido, a GESC, de forma planejada, vem trabalhando na padronização, simplificação e divulgação da estratégia de melhoria contínua dos processos organizacionais que visam o uso racional da tecnologia da informação.

A Metodologia de Gestão em Desenvolvimento de Software (MGDS) do CAU está inserida em um contexto organizacional de gestão dos serviços de projeto, sustentação, serviços, inclusive documentação e metrificação de sistemas de informação para este Conselho.

Esta metodologia tem o objetivo de estabelecer procedimentos para a gestão dos processos e serviços previstos dentro do escopo de Fábrica de Software (FSW), responsável por executar os serviços de desenvolvimento e manutenção de sistemas utilizando práticas de métodos ágeis e Fábrica de Métrica (FM), responsável por realizar a contagem de pontos de função das ordens de serviço para a FSW.

De acordo com as diretrizes do PDTI do CAU/BR, visando permitir o aumento ou diminuição de investimentos com sistemas informatizados de acordo com a necessidade dos entes do Centro de Serviços Compartilhados – CSC-CAU, os serviços de desenvolvimento de software serão realizados de forma terceirizada, com a contratação de uma fábrica de software. Já para realizar a medição do serviço executado pela fábrica de software será CONTRATADA uma fábrica de métricas. Conforme descrito no Roteiro de Métricas de Software do SISP, versão 2.2, uma das principais dificuldades e desafios na adoção de métodos ágeis em contratação de desenvolvimento de software é definir um modelo de remuneração que seja equilibrado, remunerando de forma justa o esforço da CONTRATADA para atender o volume de refinamentos e mudanças em funcionalidades e, ao mesmo tempo, não onerando de forma excessiva o CAU/BR, contratante do serviço. Ou seja, o valor pago deve corresponder aos serviços recebidos e o ciclo do processo ágil de desenvolvimento de software não deve influenciar negativamente o ciclo de faturamento do projeto.

É importante observar que, conforme a Súmula TCU 269, a remuneração nas contratações de serviços de Tecnologia da Informação deve estar vinculada à entrega de resultados e ao atendimento de níveis de serviço. Portanto, é relevante que o modelo de remuneração do contrato firmado defina os níveis de serviço e os critérios de qualidade para a aceitação dos resultados entregues ao final das sprints do processo ágil.

Portanto, todo o processo de medição citado neste MGDS deve ser complementado com as práticas definidas no capítulo 7, denominado de “Contagem de Pontos de Função no Desenvolvimento de Software utilizando Métodos Ágeis” do Roteiro de Métricas já citado.

2. Conceitos

Para alinhar o entendimento no cenário de desenvolvimento de software com métodos ágeis utilizando a remuneração de FSW por produto entregue medido em pontos de função, é importante alinhar os seguintes conceitos:

• Release: É um ciclo que perpassa pelas fases do processo de desenvolvimento de software com o objetivo de entregar, ao final do ciclo, um produto pronto a ser colocado em produção para uso. A duração de cada release será definida pelo Fiscal Técnico, coordenador do CSC que atenderá à demanda, na fase de planejamento do projeto/manutenção, conforme seu backlog priorizado, de forma a garantir uma entrega de valor antecipada aos usuários. O conjunto de releases forma o roadmap do produto.

• Sprint: É uma unidade de período de tempo fixo (time box) dentro do release, com datas de início e fim pré-definidas, dentro da qual é executado um conjunto de atividades de desenvolvimento previamente estabelecidas, gerando ao final um incremento do produto aceito, testado, homologado e potencialmente implantável, ou seja passível de publicação em ambiente de produção e disponibilização para os usuários. A sprint não deve ser menor que 2 (duas) semanas e maior que 4 (quatro) semanas e, à guisa do release, será definida pelo requisitante em conjunto com o Product Owner (PO) responsável pela demanda, na fase de planejamento do projeto/manutenção.

• Ciclo de Pagamento: período definido para fins de pagamento e apuração dos resultados entregues, podendo consistir de uma iteração (sprint), de um conjunto de iterações, de um release ou ainda de uma demanda. Considerando os critérios adotados para o projeto, como o tamanho da iteração (sprint), o tamanho do release, a produtividade da equipe do projeto e a expectativa de fluxo de caixa da CONTRATADA, para manter seu equilíbrio econômico-financeiro no atendimento do contrato, deve se realizar o faturamento por iteração (sprint), por grupo de iterações, por release ou por demanda, desde que sempre devidamente associado aos produtos entregues e aceitos de uma ordem de serviço. Esta MGDS permite o pagamento parcial por etapa entregue após a emissão do Termo de Recebimento Provisório - TRP.

• Produto Pronto: Visando a remuneração da CONTRATADA a partir da medição de resultados gerados em um “ciclo de pagamento”, entende-se que um produto está “pronto” se foi entregue e aceito. Cabe observar que o desenvolvimento de uma funcionalidade pode perpassar mais de uma sprint e conter várias funcionalidades prontas e validadas em sprints diferentes. Nesse caso, a funcionalidade só será considerada para fins de pagamento ao final do ciclo de pagamento em que estiver com todas as suas funcionalidades componentes prontas, testadas, homologadas e aceitas.

• Refinamentos: são quaisquer mudanças ocorridas sobre uma função transacional ou de dados já previamente trabalhada(s) na release corrente (seja por meio de uma inclusão, alteração ou exclusão), provocadas pelo aprofundamento, detalhamento e complementação de requisitos durante o processo de desenvolvimento.

• TAG: Forma de organizar arquivos de diferentes sprints ou releases para a publicação em ambientes de teste, homologação ou produção.

3. Processo de Software

O CAU, no contexto de sua metodologia (MGDS), se valerá de processos de apoio para sua execução de forma a garantir sua qualidade. Conceitos utilizados nesse documento:

• Funcionalidade: Capacidade do produto de software de prover funções que atendam às necessidades explícitas e implícitas, quando o software estiver sendo utilizado sob condições especificadas;

• Confiabilidade: Capacidade do produto de software de manter um nível de desempenho especificado, quando usado em condições especificadas;

• Usabilidade: Capacidade do produto de software de ser compreendido, aprendido, operado e atraente ao usuário, quando usado sob condições especificadas;

• Eficiência: Capacidade do produto de software de apresentar desempenho apropriado, relativo à quantidade de recursos usados, sob condições especificadas;

• Manutenibilidade: Capacidade do produto de software de ser modificado. As modificações podem incluir correções, melhorias ou adaptações do software devido a mudanças no ambiente e nos seus requisitos ou especificações funcionais;

• Portabilidade: Capacidade do produto de software de ser transferido de um ambiente para outro;

• Gerência de configuração: possui o propósito de estabelecer e manter a integridade de todos os produtos de trabalho (artefato) de um processo do projeto;

• Garantia da qualidade: possui o propósito de prover garantia de que os produtos e processos estão em conformidade com os requisitos especificados e satisfazem aos planos e regras estabelecidas;

• Verificação: possui o propósito de confirmar que os produtos e/ou serviços refletem os requisitos especificados;

• Validação: possui o propósito de confirmar que os requisitos para o uso específico de um produto e/ou serviço são atendidos;

• Erro: é a diferença entre o valor obtido e o valor esperado, ou seja, qualquer estado intermediário incorreto ou resultado inesperado na execução do programa constitui um erro;

• Revisão conjunta: possui o propósito de manter o entendimento (gerencial comum com os stakeholders);

• Auditoria: possui o propósito de determinar independentemente a conformidade dos produtos e processos contra os requisitos definidos;

• Resolução de problema: possui o propósito de assegurar que todos os problemas levantados sejam analisados e resolvidos;

• Contrato: todo e qualquer ajuste entre órgãos ou entidades da Administração Pública e particulares, em que haja um acordo de vontades para a formação de vínculo e a estipulação de obrigações recíprocas.

• GAD: O GAD é a ferramenta utilizada pela GESC para receber demandas dos entes do CSC.

• Área de Negócio:

• Dono do Produto (product owner): colaborador do CSC indicado para ser o responsável pela demanda.

• Matriz GUT: ferramenta de avaliação de criticidade que consiste em aplicar uma nota de

1 a 5 para gravidade, urgência e tendência. A prioridade da demanda é calculada multiplicando as notas.

• Documento de Escopo: possui a visão do produto e o roadmap com os releases da demanda, que serão incluídas nas versões do produto.

O processo de desenvolvimento ágil do CAU/BR se baseia no processo descrito no “Guia de Projetos de Software com Práticas Ágeis do SISP (Sistema de Administração dos Recursos de Tecnologia da Informação)” e utiliza o modelo de referência da figura abaixo:

Figura: Modelo de referência de projetos de software com práticas ágeis do SISP

Recomenda-se frequentemente a consulta ao modelo de referência citado para aprofundamento nos conceitos, ferramentas e técnicas, de modo a complementar a aplicação desta MGDS.

4. Tipos de demandas

I) Projeto

Pode ser classificado como (conforme o guia do SISP 2.2):

a. Projeto de desenvolvimento: Consiste no projeto para desenvolver e entregar a primeira versão de uma aplicação de software. Seu tamanho funcional é a medida das funcionalidades entregues ao usuário no final do projeto. Também se considera as funcionalidades de conversão de dados, caso seja requisitado no projeto a migração ou carga inicial de dados para a nova aplicação.

b. Projeto de melhoria: Consiste no esforço necessário para o atendimento de uma demanda de evolução ou melhoria funcional com tamanho significativo (igual ou superior a 100 pontos de função) e/ou alta criticidade para o processo de negócio do CAU/BR. Seu tamanho funcional é a medida das funcionalidades incluídas, alteradas e excluídas ao final do projeto. Também se considera as funcionalidades de conversão de dados, caso seja requisitado a migração ou carga inicial de dados no projeto de melhoria.

II) Manutenção

Consiste em demandas de sustentação e manutenção dos sistemas existentes abaixo de 100 pontos de função. Tem o objetivo de evoluir e manter, o maior tempo possível, sem falhas os sistemas/aplicações em produção. Pode ser classificado como:

a. Manutenção evolutiva: evoluções (melhorias) de sistemas de informação, visando implementar novas funcionalidades, alterar ou excluir funcionalidades existentes, promover a melhoria de performance, a manutenibilidade e usabilidade do sistema, melhorando sua aplicabilidade, eficiência e usabilidade dentro da organização;

b. Manutenção adaptativa: São consideradas nesta categoria as demandas de manutenção adaptativa associadas a solicitações que envolvem aspectos não funcionais, sem alteração em requisitos funcionais. Seguem alguns exemplos:

• Aumentar a quantidade de linhas por página em um relatório;

• Colocar paginação em um relatório;

• Limitar a quantidade de linhas por página em uma consulta existente;

• Permitir exclusões múltiplas em uma funcionalidade que antes só possibilitava a exclusão de um item;

• Adaptação de uma funcionalidade para possibilitar a chamada por um webservice ou para outro tipo de integração com outros sistemas;

• Replicação de funcionalidade: chamar uma consulta existente em outra tela da aplicação;

• Alteração na aplicação para adaptação às alterações realizadas na interface com rotinas de integração com outros softwares, por exemplo, alteração em sub-rotinas chamadas por este software;

• Modificar o servidor a ser acessado em uma funcionalidade de download de arquivo;

• Adequar mensagem do sistema que em algumas telas apresenta “Usuário Não está Habilitado a ver esta Página”, para que passe a enviar uma mensagem mais adequada ao fato do usuário não possuir mais uma sessão ativa e ainda estar navegando no sistema. A demanda deve ser contada como manutenção adaptativa considerando as funcionalidades impactadas. Observe que trata-se de mudança em validação com regra de negócio não funcional.

c. Manutenção de interface: mudança de interface (layout), por exemplo: fonte de letra, cores de telas, logotipos, mudanças de botões na tela, mudança de posição de campo ou texto na tela. Também se enquadram nessa categoria as seguintes manutenções:

• Mudanças de texto em mensagens de erro, validação, aviso, alerta, confirmação de cadastro ou conclusão de processamento;

• Mudança em texto estático de e-mail enviado para o usuário em uma funcionalidade de cadastro. A demanda deve ser contada como manutenção em interface na funcionalidade de cadastro;

• Alteração de título de um relatório;

• Alteração de labels de uma tela de consulta.

d. Manutenção corretiva: implementação de ajustes no código de sistemas de informação com o intuito de corrigir defeitos e/ou deficiências que foram encontrados durante sua utilização, ou seja, nos sistemas em produção. Para isso, a empresa CONTRATADA deverá adotar ações de contorno que minimizem o impacto de falhas e/ou paradas no processo de negócio do Conselho e, principalmente, ações definitivas que garantam a continuidade do negócio, aumentando a confiança nos sistemas e reduzindo a necessidade de novos investimentos. Para esse tipo de demanda não será elaborado um escopo e realizada contagem estimada de pontos de função, devendo a CONTRATANTE abrir um ticket/ordem de serviço com as evidências de erros e/ou problemas e a CONTRATADA iniciar o atendimento conforme os prazos definidos nos níveis de serviço.

e. Verificação de erro: As verificações de erro ou análise e solução de problemas são as demandas referentes a todo comportamento anormal ou indevido apontado pelo cliente nos sistemas aplicativos. Neste caso, a equipe de desenvolvimento da CONTRATADA se mobilizará para encontrar as causas do problema ocorrido. Se for constatado algum erro de sistema, a demanda será atendida como manutenção corretiva ou defeito, conforme vigência da garantia.

f. Garantia: Quando o sistema em produção tiver sido desenvolvido pela CONTRATADA, a manutenção corretiva será assim classificada se estiver no período de cobertura e em conformidade com as demais condições de garantia previstas em contrato e nesta MGDS.

III) Serviço

Os serviços de sistemas de informação serão demandas pontuais solicitadas pelo CAU, que não envolvam tarefas e/ou atividades já previstas nas demandas do tipo: projeto ou sustentação, mas que dependam de conhecimento técnico sobre o(s) sistema(s);

São exemplos de serviço de sistemas de informação:

• Desenvolvimento e/ou manutenção de documentação dos Sistemas Legados;

• Configuração de ambiente;

• Publicação de conteúdo estático intranet e/ou internet;

• Desenvolvimento de script de banco de dados;

• Consultoria destinado à análise de regras de negócio a serem implementadas em soluções de TI ou para elaboração do documento de escopo, visão e roadmap do produto, dentre outros;

• Demais serviços considerados atividades sem contagem de pontos de função especificados no Roteiro de Métricas de Software do SISP.

5. Viabilidade da demanda

A aprovação da demanda estabelecerá um acordo formal entre a GESC e os usuários requisitantes para o escopo do produto a ser desenvolvido. A demanda deve considerar as premissas e diretrizes do PDTIC - Plano Diretor de Tecnologia da Informação e Comunicação e estar coerente com o mapa estratégico do CAU.

Com o objetivo de mitigar riscos, é importante a participação da GESC desde a concepção das ações dos projetos institucionais que envolvam soluções de tecnologia da informação, estabelecendo uma arquitetura de software estável que poderá ser desenvolvida ou mantida em termos tecnológicos, considerando os requisitos, limitações e restrições

identificadas.

6. Macro Processo: Gestão em Desenvolvimento de Software

DIAGRAMA 1: MACROPROCESSO

Descrição dos procedimentos existentes no processo, exceto para demandas do tipo manutenção corretiva e serviços

ANÁLISE PRÉVIA

SEQ	AÇÕES (descrição)	COORDENAÇÃO/ FUNÇÃO	SAÍDA OU PRODUTO
1	1.1. As áreas requisitantes devem descrever, de forma detalhada, sua necessidade e objetivos de negócio. Deverá especificar na demanda o ganho e o impacto corporativo, bem como as expectativas de prazo e custo, caso existam. A demanda deverá ser encaminhada para a unidade responsável na Gerência do CSC (GESC), indicando o representante da área de negócio que será o responsável designado para atuar em conjunto com o dono do produto (product owner) durante o ciclo de desenvolvimento da demanda de desenvolvimento de software.	Responsável da Área Requisitante	Protocolo ou demanda do GAD (gerenciador avançado de demandas).

2	2.1. O responsável na GESC avalia se a demanda possui as informações necessárias e se pode ser implementada. 2.2. Se a demanda não for viável, o chamado é fechado ou o protocolo é respondido indicando a inviabilidade e seus motivos. Neste caso o processo é encerrado. 2.3. Se a demanda for viável, o coordenador indica um colaborador para ser o dono do produto (product owner).	Coordenador do CSC ou responsável que avaliará a demanda.	Indicação de viabilidade da demanda. Dono do produto designado.
3	3.1. O dono do produto realiza a avaliação de criticidade da demanda usando a técnica GUT. 3.2. A demanda com a criticidade calculada é incluída na lista de backlog.	Dono do Produto	Demanda priorizada. Lista de backlog do produto atualizada.
4	4.1. A área Requisitante é comunicada da criticidade calculada e informada quanto ao prazo estimado para que a demanda seja iniciada. 4.2. A demanda fica aguardando a sua inclusão no Roadmap de execução do produto, considerando a priorização atribuída.	Coordenador do CSC ou responsável que avaliará a demanda.	Registro da priorização no protocolo ou GAD. Inclusão na demanda no Roadmap do produto.
5	5.1. O dono do produto entrevista o responsável da área requisitante e elabora o documento de escopo. Esse processo é cíclico e repetido até que todas as funcionalidades estejam mapeadas. Por essa razão o dono do produto e a área requisitante devem identificar as funcionalidades e características que geram valor e priorizá- las para inclusão nos releases do produto. 5.2. Sempre que necessário, a coordenadoria de TI será consultada para identificar os impactos das novas funcionalidades no produto, realizando planejamento das adequações quanto aos ativos de TI.	Dono do Produto Responsável da Área Requisitante Coordenadoria de TI	Documento de escopo. Roadmap do produto atualizado. Documento de adequações quanto aos ativos de TI.

6	6.1 O coordenador abre a ordem de serviço para a Fábrica de Métricas realizar a contagem estimada de pontos de função por release. 6.2 O coordenador apresenta ao Responsável da Área Requisitante o escopo, a contagem de pontos de função total e/ou por release, o custo e o prazo para execução. 6.3 Caso os custos e/ou prazos para execução da demanda não sejam aprovados pela área requisitante, a demanda é encerrada sem êxito. 6.4 O escopo aprovado deverá ser assinado pelo Dono do Produto e pelo Responsável da Área Requisitante.	Coordenador do CSC ou responsável pela demanda. Responsável da Área Requisitante;	Ordem de serviço para Fábrica de Métricas. Contagem estimada de pontos de função. Registro da informação no protocolo ou GAD. Documento de escopo atualizado e assinado. Roadmap do produto atualizado.
7	7.1. Aprovado o escopo, é criada a ordem de serviço na FSW para a construção do Projeto ou da Evolução. 7.1.1. A OS preferencialmente conterá todas as sprints de um release, e quando não for possível, deve contemplar, preferencialmente, ao menos duas sprints (colocar junto aos conceitos aplicáveis ao contrato – OS por release e OS por Sprint – SISP 7.1 e 7.2); 7.2 Autorizam a OS: o Fiscal Técnico e o Gerente de Projeto da Fábrica de Software; 7.3 Os documentos gerados nas etapas anteriores e relevantes para a execução da demanda devem ser encaminhados à FSW na OS.	Fiscal Técnico Gerente de Projeto da Fábrica de Software (FSW)	Ordem de Serviço para Fábrica de Software (FSW); Roadmap do produto atualizado;

PLANEJAMENTO E ENGENHARIA DE REQUISITOS

SEQ.	AÇÕES (descrição)	COORDENAÇÃO/ FUNÇÃO	SAÍDA OU PRODUTO
8	8.1. O representante da FSW recebe a OS e inicia sua execução. Devem ser observados: os níveis de serviço do contrato, a documentação solicitada na OS e a lista de artefatos e produtos especificado nesta MGDS para o tipo de demanda da OS. 8.1.1 A FSW indica os profissionais do time de desenvolvimento e agenda com o dono do produto preferencialmente para o primeiro dia de início de execução da OS a primeira reunião de entendimento e detalhamento da demanda. 8.2 A FSW planeja a execução da ordem de serviço, identificando as atividades necessárias de acordo com os produtos que devem ser entregues e elabora o(s) sprint(s) backlog(s). 8.3. O gerente do projeto ou líder do time de desenvolvimento deve apresentar o cronograma inicial para execução do sprint backlog para a aprovação dos envolvidos na demanda. Em caso de divergência serão realizadas reuniões de consenso. 8.3.1 O gerente de projeto pode apresentar uma contagem de pontos de função estimados e caso haja divergência, solicitar o replanejamento. Se comprovado e aceitos os argumentos, a OS pode ser alterada e replanejada, mediante autorização do Dono do Produto.	Fábrica de Software (FSW) Dono do Produto	Artefatos / Produtos de acordo com o tipo da demanda Backlog do produto atualizado.
9	9.1.1 O gerente do projeto e o time de desenvolvimento da FSW devem iniciar o entendimento do escopo do projeto, detalhando a visão do produto, os objetivos de negócio, as características chaves do produto, o backlog do produto e o roadmap do produto. 9.1.2 O gerente do projeto deverá iniciar o planejamento do projeto considerando o	Fábrica de Software (FSW) Dono do Produto	Artefatos / Produtos da demanda de projeto. Sprint backlog

	roadmap apresentado na OS e detalhar o plano cronológico de liberação de releases. Esse é o momento para fazer os ajustes iniciais no roadmap do produto e no backlog do produto, caso o dono do produto concorde. 9.1.3 O dono do produto deverá garantir que foram documentados os critérios de aceitação do produto, que estão fortemente relacionados aos requisitos não funcionais e funcionais especificados. 9.1.3.1 O mapeamento de riscos deverá ser aprovado pelo Dono do Produto e pelo Fiscal Técnico. 9.1.3.1. O documento de arquitetura de software, quando aplicável, deve ser aprovado pelo Coordenadoria de TI do CSC. 9.2 Considerando que em demandas de manutenção abaixo de 100 PF as incertezas são menores, o processo de entendimento do time de desenvolvimento da FSW deve ser executado com maior celeridade.	(Product Owner)	elaborado Backlog do produto atualizado
10	10.1 Se demanda de manutenção (exceto corretiva): 10.1.1 Considerando que em demandas de manutenção abaixo de 100 PF as incertezas são menores, o processo de entendimento do time de desenvolvimento da FSW pode ser executado com maior celeridade. É esperado que em uma reunião com duração de 4 (quatro) horas seja possível entender escopo da manutenção e definir as atividades e apresentar o sprint backlog.	Fábrica de Software (FSW) Dono do Produto (product owner)	Artefatos / Produtos da demanda de manutenção. Sprint backlog elaborado Backlog do produto atualizado

ANÁLISE - PROJETO TÉCNICO - TESTE

SEQ.	AÇÕES (descrição)	COORDENAÇÃO / FUNÇÃO	SAÍDA OU PRODUTO
11	11.1. O time de desenvolvimento executa as atividades planejadas, interage com o dono do produto quando necessário. Durante a sprint o time de desenvolvimento e o Scrum Master (ambos da FSW) realizam as reuniões diárias, registram as evoluções no kanban, e sinaliza quando os produtos ou artefatos devem ser homologados. O produto deve ser apresentado na reunião de demonstração da iteração. 11.2. A FSW, a critério do CAU, deve publicar o produto em um dos ambientes de testes e o time de teste da FSW deve: 11.2.1. Executar a publicação dos scripts unitários; 11.2.2. Elaborar a massa de testes; 11.2.3. Elaborar o script de automação de testes; 11.2.4. Realizar a filmagem com as evidências de testes que não puderam ser automatizados na opção acima. 11.3. O time de desenvolvimento deve garantir que o processo de teste verificou todos os critérios de aceitação, que estão relacionados aos requisitos não funcionais e funcionais especificados por meio das regras de negócio e de apresentação, bem como que o produto está atendendo às necessidades dos usuários. 11.4.Caso o produto passe no processo de testes da FSW, o produto e os artefatos de testes são disponibilizadas para o dono do produto.	Fábrica de Software (FSW) Dono do Produto (product owner)	Artefatos / Produtos de acordo com o tipo da demanda; Kanban atualizado; Sprint backlog atualizado; Backlog do produto atualizado; Roadmap atualizado;
12	12.1. O dono do produto aceita ou rejeita a entrega. O dono do produto deve validar se o produto atende às necessidades dos usuários e verificar se os artefatos construídos estão de acordo com as especificações. 12.2. Em caso de rejeição pelo dono do	Fábrica de Software (FSW) Dono do Produto (product owner)	Produtos da etapa de testes de acordo com o tipo de demanda. Tempo de execução da

produto, o mesmo deve indicar individualmente os refinamentos necessários, ou seja, reportar as correções para que o produto atenda às necessidades dos usuários, e os erros encontrados em relação ao que foi especificado. Esse apontamento será usado para calcular os índices de qualidade. 12.2.1. Em caso de divergência entre a FSW e o dono do produto, será realizada reunião de consenso. 12.2.2. Os erros obrigatoriamente precisam ser corrigidos para a emissão do termo de recebimento provisório. Os refinamentos podem ser executados na sprint atual ou nas próximas sprints, releases ou ordens de serviço. OS registrado; Erros identificados apontados.

HOMOLOGAÇÃO

SEQ.	AÇÕES (descrição)	COORDENAÇÃO/ FUNÇÃO	SAÍDA OU PRODUTO
13	13.1. Na homologação, o dono do produto elabora o Termo de Recebimento Provisório – TRP e sinaliza para validação do Fiscal Técnico. 13.2. O Fiscal Técnico aceita o TRP – Termo de Recebimento Provisório autorizando o faturamento da OS de acordo com o percentual de esforço da etapa aceita. 13.3. Na homologação de artefatos específicos da disciplina de engenharia de software, o dono do produto pode solicitar o apoio da Coordenadoria de TI (CORTI) do CSC. São exemplos destes artefatos: Documento de arquitetura de software, Modelo de dados e Dicionários de dados. 13.4 Na homologação de regras e do produto, o dono do produto pode solicitar o apoio do responsável da área requisitante.	Fiscal Técnico Dono do Produto Responsável da Área Requisitante	Artefatos / Produtos de acordo com o tipo da demanda; Kanban atualizado; Tempo de execução da OS registrado; TRP

15	15.1 O dono do produto deve realizar a homologação validando o atingimento dos critérios de aprovação. 15.2. No 1º ciclo de homologação o dono do produto utilizará o mesmo ambiente de testes. O dono do produto pode complementar os testes com outros cenários com o objetivo de responder às seguintes perguntas: “Estamos construindo o produto certo?” “Estamos construindo certo o produto?” 15.3 Caso não seja homologado, o dono do produto deve seguir o fluxo do diagrama nº 4.	Dono do produto	Artefatos / Produtos de acordo com o tipo da demanda; Kanban atualizado; Sprint backlog atualizado; Backlog do produto atualizado; Roadmap atualizado; Tempo de execução da OS registrado; Erros identificados apontados.
16	16.1. Caso seja homologado, o dono do produto deve: 16.1.1. Decidir em conjunto com o Fiscal Técnico e com o Responsável da Área Requisitante se haverá a publicação da demanda, sendo esta realizada inicialmente no ambiente de homologação. 16.1.1.1. A homologação deve demonstrar o incremento do software para a Área Requisitante. 16.1.2. A publicação do produto pode ser postergada para ocorrer juntamente com outras sprints de um mesmo release.	Dono do produto Fiscal Técnico Responsável da Área Requisitante	Artefatos / Produtos de acordo com o tipo da demanda; Kanban atualizado; Sprint backlog atualizado; Backlog do produto atualizado; Roadmap atualizado;
17	00.0.Xx caso de publicação do produto: 17.1.2. O Fiscal Técnico deve planejar a publicação da TAG no ambiente de homologação e17.2. solicitar a TAG para a FSW; 17.2.1.O dono do produto deve solicitar a elaboração do boletim ou aviso da RIA (rede integrada de atendimento) divulgando a publicação do produto; 17.2.2.1 A CORTI deve publicar a TAG e demais artefatos ou produtos no ambiente de homologação, incluindo os scripts de	Fiscal Técnico Dono do produto Responsável da Área Requisitante FSW CORTI RIA	Artefatos / Produtos de acordo com o tipo da demanda; Kanban atualizado; Sprint backlog atualizado; Backlog do produto atualizado;

	teste; 17.2.2.2. O dono do produto deve realizar o 2º ciclo de homologação no ambiente de homologação. O objetivo é fazer o último ciclo de testes de aceitação, usando os scripts automatizados com dados similares ao ambiente de produção. Estes scripts devem ajudar a reduzir o tempo dos testes. Sempre que possível é recomendado utilizar outros scripts automatizados para permitir a validação do impacto em outras partes do sistema. 17.2.2.3 O Responsável da Área Requisitante poderá participar do 2º ciclo de homologação. 17.3. Se o produto não for homologado: 17.3.1. Caso não seja homologado, o dono do produto deve seguir o fluxo diagrama 4.		Roadmap atualizado; TAG do produto; Boletim ou aviso da RIA Tempo de execução da OS registrado; Erros identificados apontados;
19	19.1 A FSW ao final de cada sprint deve realizar a reunião de retrospectiva com o objetivo de identificar os pontos fortes e fracos, as oportunidades e os impedimentos detectados durante a execução da sprint. O resultado da retrospectiva deve ser apresentado ao CAU.	FSW Fiscal Técnico Fiscal Administrativo Dono do Produto Gestor do contrato	Sugestões de melhoria e ajustes no processo

IMPLANTAÇÃO

SEQ.	AÇÕES (descrição)	COORDENAÇÃO/ FUNÇÃO	SAÍDA OU PRODUTO
20	20.1. Caso o produto seja homologado no 2º ciclo: 20.1.1. O Fiscal Técnico deve planejar a publicação da TAG no ambiente de produção; 20.1.2. A CORTI publica a TAG em ambiente de produção; 20.1.3 O dono do produto e o Fiscal Técnico registram o atendimento da demanda nas ferramentas de gestão (exemplos: sistema de controle de OS da FSW, GAD, protocolo, etc.) e comunicam os envolvidos; 20.1.4. Erros encontrados no ambiente de produção serão corrigidos por meio de OS de defeito, caso em garantia, ou por OS de manutenção corretiva.	Fiscal Técnico; Dono do produto; CORTI	Contagem detalhada de PF; Documento de Manutenção;
21	21.1. Após a publicação em produção da última sprint do release: 21.1.1. O Fiscal Técnico abre a ordem de serviço para a Fábrica de Métricas (FM) realizar a contagem detalhada de pontos de função da OS; 21.1.1.1. Caso exista divergência entre a contagem detalhada da FSW e da FM, pode ser solicitada uma reunião de consenso. A quantidade de PF apurada no consenso é utilizada para o faturamento da OS. 21.1.2. O Fiscal Técnico calcula os índices de qualidade do contrato e emite o TRD – Termo de Recebimento Definitivo indicando os resultados apurados e a glosa caso exista. 21.1.3. O Fiscal Administrativo valida e aceita o TRD – Termo de recebimento definitivo, verificando se há necessidade de aplicação de penalidade e cumprindo as demais formalidades previstas no contrato. 21.1.4. Concluídos os procedimentos do item anterior, o Fiscal Administrativo	Fiscal Técnico; Fiscal Administrativo; Gestor do contrato; FSW; FM;	Contagem Detalhada; TRD;

autoriza o faturamento final da OS e o

processo é encerrado.

Descrição dos procedimentos existentes no processo, para demandas do tipo manutenção corretiva e serviços

SEQ.	AÇÕES (descrição)	COORDENAÇÃ O/ FUNÇÃO	SAÍDA OU PRODUTO
1	1.1. As áreas requisitantes devem descrever, de forma detalhada, sua necessidade e objetivos de negócio. Deverá especificar na demanda o ganho e o impacto corporativo, bem como as expectativas de prazo e custo, caso existam. A demanda deverá ser encaminhada para a unidade responsável na Gerência do CSC (GESC), indicando o representante da área de negócio que será o responsável designado para atuar em conjunto com o dono do produto (product owner) durante o ciclo de desenvolvimento da demanda de desenvolvimento de software.	Responsável da Área Requisitante	Protocolo ou demanda do GAD (gerenciador avançado de demandas).
2	2.1. O responsável na GESC avalia se a demanda possui as informações necessárias e se pode ser implementada. 2.2. Se a demanda não for viável, o chamado é fechado ou o protocolo é respondido indicando a inviabilidade e seus motivos. Neste caso o processo é encerrado. 2.3. Se a demanda for viável, o coordenador indica um colaborador para ser o dono do produto (product owner).	Coordenador do CSC ou responsável que avaliará a demanda.	Indicação de viabilidade da demanda. Dono do produto designado.
3	3.1. O dono do produto realiza a avaliação de criticidade da demanda usando a técnica GUT. 3.2. A demanda com a criticidade calculada é incluída na lista de backlog.	Dono do Produto	Demanda priorizada. Lista de backlog do produto atualizada.
4	4.1. A área Requisitante é comunicada da criticidade calculada e informada quanto ao prazo estimado para que a demanda seja iniciada. 4.2. A demanda fica aguardando a sua inclusão no Roadmap de execução do produto, considerando a priorização	Coordenador do CSC ou responsável que avaliará a demanda.	Registro da priorização no protocolo ou GAD. Inclusão na demanda no Roadmap do

	atribuída.		produto.
5	5.1. Efetuado o escopo simplificado, é criada a ordem de serviço na FSW para a construção da Sustentação ou do serviço. 5.1.1. A OS preferencialmente conterá todas as sprints de um release, e quando não for possível, deve contemplar, preferencialmente, ao menos duas sprints (colocar junto aos conceitos aplicáveis ao contrato – OS por release e OS por Sprint – SISP 7.1 e 7.2); 5.2 Autorizam a OS: o Fiscal Técnico e o Gerente de Projeto da Fábrica de Software; 5.3 Os documentos gerados nas etapas anteriores e relevantes para a execução da demanda devem ser encaminhados à FSW na OS.	Fiscal Técnico Gerente de Projeto da Fábrica de Software (FSW)	Ordem de Serviço para Fábrica de Software (FSW); Roadmap do produto atualizado;
6	6.1. O representante da FSW recebe a OS e inicia sua execução. Devem ser observados: os níveis de serviço do contrato, a documentação solicitada na OS e a lista de artefatos e produtos especificado nesta MGDS para o tipo de demanda da OS. 6.1.1 A FSW indica os profissionais do time de desenvolvimento e agenda com o dono do produto preferencialmente para o primeiro dia de início de execução da OS a primeira reunião de entendimento e detalhamento da demanda. 6.2 A FSW planeja a execução da ordem de serviço, identificando as atividades necessárias de acordo com os produtos que devem ser entregues e elabora o(s) sprint(s) backlog(s). 6.3 O gerente de projeto pode apresentar uma contagem de pontos de função estimados, e efetuar o planejamento.	Fábrica de Software (FSW) Dono do Produto	Artefatos / Produtos de acordo com o tipo da demanda Backlog do produto atualizado.
7	7.1. O gerente do projeto e o time de desenvolvimento da FSW devem iniciar o entendimento do escopo, detalhando a visão do produto, os objetivos de negócio, as características chaves do produto, o backlog do produto e o roadmap do		Artefatos / Produtos da

	produto. 7.1.2 O dono do produto deverá garantir que foram documentados os critérios de aceitação do produto, que estão fortemente relacionados aos requisitos não funcionais e funcionais especificados. 7.2 Considerando que em demandas de manutenção abaixo de 100 PF as incertezas são menores, o processo de entendimento do time de desenvolvimento da FSW deve ser executado com maior celeridade.	Fábrica de Software (FSW) Dono do Produto (Product Owner)	demanda de projeto. Sprint backlog elaborado Backlog do produto atualizado
8	8.1. O time de desenvolvimento executa as atividades planejadas, interage com o dono do produto quando necessário. Durante a sprint o time de desenvolvimento e o Scrum Master (ambos da FSW) realizam as reuniões diárias, registram as evoluções no kanban, e sinaliza quando os produtos ou artefatos devem ser homologados. O produto deve ser apresentado na reunião de demonstração da iteração. 8.2. A FSW, a critério do CAU, deve publicar o produto em um dos ambientes de testes e o time de teste da FSW deve: 8.2.1. Executar a publicação dos scripts unitários; 8.2.2. Elaborar a massa de testes; 8.2.3. Elaborar o script de automação de testes; 8.2.4. Realizar a filmagem com as evidências de testes que não puderam ser automatizados na opção acima. 8.3. O time de desenvolvimento deve garantir que o processo de teste verificou todos os critérios de aceitação, que estão relacionados aos requisitos não funcionais e funcionais especificados por meio das regras de negócio e de apresentação, bem como que o produto está atendendo às necessidades dos usuários. 8.4.Caso o produto passe no processo de testes da FSW, o produto e os artefatos de testes são disponibilizadas para o dono do produto.	Fábrica de Software (FSW) Dono do Produto (product owner)	Artefatos / Produtos de acordo com o tipo da demanda; Kanban atualizado; Sprint backlog atualizado; Backlog do produto atualizado; Roadmap atualizado;

9	9.1. O dono do produto aceita ou rejeita a entrega. O dono do produto deve validar se o produto atende às necessidades dos usuários e verificar se os artefatos construídos estão de acordo com as especificações. 9.2. Em caso de rejeição pelo dono do produto, o mesmo deve indicar individualmente os refinamentos necessários, ou seja, reportar as correções para que o produto atenda às necessidades dos usuários, e os erros encontrados em relação ao que foi especificado. Esse apontamento será usado para calcular os índices de qualidade. 9.2.1. Em caso de divergência entre a FSW e o dono do produto, será realizada reunião de consenso. 9.2.2. Os erros obrigatoriamente precisam ser corrigidos para a emissão do termo de recebimento provisório. Os refinamentos podem ser executados na sprint atual ou nas próximas sprints, releases ou ordens de serviço.	Fábrica de Software (FSW) Dono do Produto (product owner)	Produtos da etapa de testes de acordo com o tipo de demanda. Tempo de execução da OS registrado; Erros identificados apontados.
10	10.1. Na homologação, o dono do produto elabora o Termo de Recebimento Provisório – TRP e sinaliza para validação do Fiscal Técnico. 10.2. O Fiscal Técnico aceita o TRP – Termo de Recebimento Provisório autorizando o faturamento da OS de acordo com o percentual de esforço da etapa aceita. 10.3. Na homologação de artefatos específicos da disciplina de engenharia de software, o dono do produto pode solicitar o apoio da Coordenadoria de TI (CORTI) do CSC. São exemplos destes artefatos: Documento de arquitetura de software, Modelo de dados e Dicionários de dados. 10.4 Na homologação de regras e do produto, o dono do produto pode solicitar o apoio do responsável da área requisitante.	Fiscal Técnico Dono do Produto Responsável da Área Requisitante	Artefatos / Produtos de acordo com o tipo da demanda; Kanban atualizado; Tempo de execução da OS registrado; TRP

11	11.1 O dono do produto deve realizar a homologação validando o atingimento dos critérios de aprovação. 11.2. No 1º ciclo de homologação o dono do produto utilizará o mesmo ambiente de testes. O dono do produto pode complementar os testes com outros cenários com o objetivo de responder às seguintes perguntas: “Estamos construindo o produto certo?” “Estamos construindo certo o produto?” 15.3 Caso não seja homologado, o dono do produto deve seguir o fluxo diagrama nº 4	Dono do produto	Artefatos / Produtos de acordo com o tipo da demanda; Kanban atualizado; Sprint backlog atualizado; Backlog do produto atualizado; Roadmap atualizado; Tempo de execução da OS registrado; Erros identificados apontados.
12	12.1. Caso seja homologado, o dono do produto deve: 12.1.1. Decidir em conjunto com o Fiscal Técnico e com o Responsável da Área Requisitante se haverá a publicação da demanda, sendo esta realizada inicialmente no ambiente de homologação. 12.1.1.1. A homologação deve demonstrar o incremento do software para a Área Requisitante.	Dono do produto Fiscal Técnico Responsável da Área Requisitante	Artefatos / Produtos de acordo com o tipo da demanda; Kanban atualizado; Sprint backlog atualizado; Backlog do produto atualizado; Roadmap atualizado;
13	13.1 No caso de publicação do produto: 13.1.2. O Fiscal Técnico deve planejar a publicação da TAG no ambiente de homologação e 13.2. solicitar a TAG para a FSW; 13.2.1 O dono do produto deve solicitar a elaboração do boletim ou aviso da RIA (rede integrada de atendimento) divulgando a publicação do produto, caso necessário. 13.2.2 A CORTI deve publicar a TAG e demais artefatos ou produtos no ambiente de homologação, incluindo os scripts de teste; 13.2.2.1. O dono do produto deve realizar o	Fiscal Técnico Dono do produto Responsável da Área Requisitante FSW CORTI RIA	Artefatos / Produtos de acordo com o tipo da demanda; Kanban atualizado; Sprint backlog atualizado; Backlog do produto atualizado; Roadmap atualizado; TAG do produto;

	2º ciclo de homologação no ambiente de homologação. 13.3. Se o produto não for homologado: 13.3.1. Caso não seja homologado, o dono do produto deve seguir o fluxo do diagrama 4.		Boletim ou aviso da RIA Tempo de execução da OS registrado; Xxxxx identificados apontados;
14	14.1. Caso o produto seja homologado no 2º ciclo: 14.1.1. O Fiscal Técnico deve planejar a publicação da TAG no ambiente de produção; 14.1.2. A CORTI publica a TAG em ambiente de produção; 14.1.3 O dono do produto e o Fiscal Técnico registram o atendimento da demanda nas ferramentas de gestão (exemplos: sistema de controle de OS da FSW, GAD, protocolo, etc.) e comunicam os envolvidos; 14.1.4. Erros encontrados no ambiente de produção serão corrigidos por meio de OS de defeito, caso em garantia, ou por OS de manutenção corretiva.	Fiscal Técnico; Dono do produto; CORTI	Contagem detalhada de PF; Documento de Manutenção;
15	15.1. Após a publicação em produção: 15.1.1. O Fiscal Técnico abre a ordem de serviço para a Fábrica de Métricas (FM) realizar a contagem detalhada de pontos de função da OS; 15.1.1.1. Caso exista divergência entre a contagem detalhada da FSW e da FM, pode ser solicitada uma reunião de consenso. A quantidade de PF apurada no consenso é utilizada para o faturamento da OS. 16.1.2. O Fiscal Técnico calcula os índices de qualidade do contrato e emite o TRD – Termo de Recebimento Definitivo indicando os resultados apurados e a glosa caso exista. 17.1.3. O Fiscal Administrativo valida e aceita o TRD – Termo de recebimento definitivo, verificando se há necessidade de aplicação de penalidade e cumprindo as	Fiscal Técnico; Fiscal Administrativo; Gestor do contrato; FSW; FM;	Contagem Detalhada; TRD;

demais formalidades previstas no contrato.

17.1.4. Concluídos os procedimentos do item anterior, o Fiscal Administrativo autoriza o faturamento final da OS e o processo é encerrado.

Descrição dos procedimentos existentes no processo, para demandas do tipo Garantia

SEQ.	AÇÕES (descrição)	COORDENAÇÃ O/ FUNÇÃO	SAÍDA OU PRODUTO
1	1.1. As áreas requisitantes devem descrever, de forma detalhada o erro. A demanda deverá ser encaminhada para a unidade responsável na Gerência do CSC (GESC).	Responsável da Área Requisitante	Protocolo ou demanda do GAD (gerenciador avançado de demandas).
2	2.1. O responsável na GESC avalia se a demanda possui as informações necessárias e se está na garantia e indica o dono do produto. 2.2. Se a demanda não for erro, o chamado é fechado ou o protocolo é respondido indicando seus motivos. Neste caso o processo é encerrado.	Coordenador do CSC ou responsável que avaliará a demanda.	Dono do produto designado.
3	3.1. O dono do produto realiza a avaliação de criticidade da demanda usando a técnica GUT. 3.2. A demanda com a criticidade calculada é incluída na lista de backlog do produto.	Dono do Produto	Demanda priorizada. Lista de backlog do produto atualizada.
4	4.1. A área Requisitante é comunicada da criticidade calculada e informada quanto ao prazo estimado para que a demanda seja iniciada. 4.2. A demanda fica aguardando a sua inclusão no Roadmap de execução do produto, considerando a priorização atribuída.	Coordenador do CSC ou responsável que avaliará a demanda.	Registro da priorização no protocolo ou GAD. Inclusão na demanda no Roadmap do produto.
5	5.1. Efetuado o escopo simplificado, é criada a ordem de serviço na FSW para a correção do erro. 5.2 Autorizam a OS: o Fiscal Técnico e o Gerente de Projeto da Fábrica de Software; 5.3 Os documentos gerados nas etapas anteriores e relevantes para a execução da	Fiscal Técnico Gerente de Projeto da Fábrica de Software (FSW)	Ordem de Serviço para Fábrica de Software (FSW); Roadmap do produto atualizado;

	demanda devem ser encaminhados à FSW na OS.
6	6.1. O representante da FSW recebe a OS e inicia sua execução. Devem ser observados: os níveis de serviço do contrato, a documentação solicitada na OS e a lista de artefatos e produtos especificado nesta MGDS para o tipo de demanda da OS. 6.1.1 A FSW indica os profissionais do time de desenvolvimento e agenda com o dono do produto atendendo a criticidade do erro. 6.2 A FSW planeja a execução da ordem de serviço, identificando as atividades necessárias de acordo com os produtos que devem ser entregues e elabora o(s) sprint(s) backlog(s).	Fábrica de Software (FSW) Dono do Produto	Artefatos / Produtos de acordo com o tipo da demanda Backlog do produto atualizado.
7	7.1. O gerente do projeto e o time de desenvolvimento da FSW devem iniciar o entendimento do escopo.	Fábrica de Software (FSW) Dono do Produto (Product Owner)	Artefatos / Produtos da demanda de projeto. Sprint backlog elaborado Backlog do produto atualizado
8	8.1. O time de desenvolvimento executa as atividades planejadas, interage com o dono do produto quando necessário. 8.2. A FSW, a critério do CAU, deve publicar o produto em um dos ambientes de testes e o time de teste da FSW deve: 8.2.1. Executar a publicação dos scripts unitários; 8.2.2. Elaborar a massa de testes; 8.2.3. Elaborar o script de automação de testes; 8.2.4. Realizar a filmagem com as evidências de testes que não puderam ser automatizados na opção acima. 8.3. O time de desenvolvimento deve garantir que o processo de teste verificou todos os critérios de aceitação, que estão	Fábrica de Software (FSW) Dono do Produto (product owner)	Artefatos / Produtos de acordo com o tipo da demanda; Kanban atualizado; Sprint backlog atualizado; Backlog do produto atualizado; Roadmap atualizado;

	relacionados aos requisitos não funcionais e funcionais especificados por meio das regras de negócio e de apresentação, bem como que o produto está atendendo às necessidades dos usuários. 8.4.Caso o produto passe no processo de testes da FSW, o produto e os artefatos de testes são disponibilizadas para o dono do produto.
9	9.1. O dono do produto aceita ou rejeita a entrega. O dono do produto deve validar se o produto foi corrigido. 9.2. Em caso de rejeição pelo dono do produto, o mesmo deve indicar individualmente os refinamentos necessários.	Fábrica de Software (FSW) Dono do Produto (product owner)	Produtos da etapa de testes de acordo com o tipo de demanda. Erros identificados apontados.
10	10.1. Na homologação, o dono do produto elabora o Termo de Recebimento Provisório – TRP e sinaliza para validação do Fiscal Técnico. 10.2. O Fiscal Técnico aceita o TRP – Termo de Recebimento Provisório.	Fiscal Técnico Dono do Produto Responsável da Área Requisitante	Kanban atualizado; TRP
11	11.1 O dono do produto deve realizar a homologação validando o atingimento dos critérios de aprovação. 11.2. No 1º ciclo de homologação o dono do produto utilizará o mesmo ambiente de testes. 11.3 Caso não seja homologado, o dono do produto deve seguir o fluxo do diagrama nº 4.	Dono do produto	Artefatos / Produtos de acordo com o tipo da demanda; Kanban atualizado; Backlog do produto atualizado; Erros identificados apontados.
12	13.1 No caso de homologado em 1º ciclo: 13.1.2. O Fiscal Técnico deve planejar a publicação da TAG no ambiente de homologação e 13.2. solicitar a TAG para a FSW; 13.2.2 A CORTI deve publicar a TAG e demais artefatos ou produtos no ambiente de homologação. 13.2.2.1. O dono do produto deve realizar o 2º ciclo de homologação no ambiente de	Fiscal Técnico Dono do produto Responsável da Área Requisitante FSW CORTI	Kanban atualizado; Backlog do produto atualizado; TAG do produto; Erros identificados apontados;

	homologação. 13.3. Se o produto não for homologado: 13.3.1. Caso não seja homologado, o dono do produto deve seguir o do diagrama 4.
14	14.1. Caso o produto seja homologado no 2º ciclo: 14.1.1. O Fiscal Técnico deve planejar a publicação da TAG no ambiente de produção; 14.1.2. A CORTI publica a TAG em ambiente de produção; 14.1.3 O dono do produto e o Fiscal Técnico registram o atendimento da demanda nas ferramentas de gestão (exemplos: sistema de controle de OS da FSW, GAD, protocolo, etc.) e comunicam os envolvidos; 14.1.4. Erros encontrados no ambiente de produção serão corrigidos por meio de OS de defeito, caso em garantia.	Fiscal Técnico; Dono do produto; CORTI	Contagem detalhada de PF; Documento de Manutenção;

9. Artefatos ou Produtos

As tabelas abaixo definem os artefatos ou produtos para cada tipo de demandas de projeto, sustentação, serviços e metrificação do Conselho, os obrigatórios sempre deverão ser entregues e os demais solicitados a qualquer tempo, a critério do CAU.

A responsabilidade pela elaboração de cada artefato está descrita no macroprocesso desta MGDS-CAU. Os artefatos listados são exigência mínima, podendo em alguns casos serem solicitados de acordo com a necessidade específica de cada demanda.

Projeto
Desenvolvimento de um novo sistema ou demandas superiores a 100 Pontos de Função
Etapa de desenvolvimento	Percentual de esforço	Documentos/Produtos	Entrega
Análise Prévia da Demanda		Documento de escopo de projeto	Obrigatório
		Planejamento do Roadmap com o plano cronológico de liberação de release	Obrigatório
		Matriz funcional	A critério do CAU
		Contagem estimada de	Obrigatório

		PF
		Ordem de serviço/Ticket	Obrigatório
Planejamento do projeto Engenharia de Requisitos	25%	Protótipo navegável com especificação de regras de apresentação, requisitos não funcionais e referência às regras de negócio	Obrigatório
		Regras de Negócio	Obrigatório
		Matriz de rastreabilidade	Obrigatório
		Casos de testes com os cenários de teste abarcando 100% das regras de negócio e dos critérios de aceitação	Obrigatório
		Mapeamento de risco	Obrigatório
		Documento de arquitetura de software	Obrigatório quando aplicável
Análise / Projeto Técnico	10%	Modelo de Dados	Obrigatório
		Dicionário de Dados	Obrigatório
		Script de DDL dos objetos de BD	Obrigatório quando aplicável
		Script de Migração de Dados	Obrigatório quando aplicável
Implementação	40%	Código Fonte	Obrigatório
Testes	15%	Script de teste Unitário e integração com ferramenta de gestão de Builds	Obrigatório quando aplicável
		Script de automação de testes	Obrigatório para todos os casos e cenários que puderem ser automatizados.
		Filmagem das evidências de Testes	Obrigatório para os casos e cenários de testes que não for possível automatizar.
		Instruções para publicação da OS nos ambientes de	Obrigatório quando aplicável.

		homologação e produção, utilizando a integração contínua
Homologação 1° Ciclo (Dono do Produto)		TAG aprovada no 1°ciclo.	Obrigatório
		Script	Obrigatório quando aplicável.
Homologação 2° Ciclo (Dono do Produto)		TAG aprovada no 2º ciclo.	Obrigatório
		Script	Obrigatório quando aplicável.
		Boletim ou aviso da evolução do produto.	Obrigatório
Implantação	10%	Documento de manutenção	Obrigatório
		Contagem detalhada de PF	Obrigatório

Manutenção Evolutiva (ME), Adaptativa (MA) e de Interface (MI)
Desenvolvimento de um novo sistema ou demandas inferiores a 100 Pontos de Função
Etapa de desenvolvimento	Percentual de esforço	Documentos/Produtos	Entrega
Análise Prévia da Demanda		Documento de escopo de projeto	Obrigatório
		Planejamento do Roadmap com o plano cronológico de liberação de release	Obrigatório
		Matriz funcional	A critério do CAU
		Contagem estimada de PF	A critério do CAU
		Ordem de serviço/Ticket	Obrigatório
Planejamento do projeto Engenharia de Requisitos	25%	Protótipo navegável com especificação de regras de apresentação, requisitos não funcionais e referência às regras de negócio, ou documentação de requisitos definidos a critério do CAU	Obrigatório
		Regras de Negócio	Obrigatório quando aplicável

		Matriz de rastreabilidade	Obrigatório quando aplicável
		Casos de testes com os cenários de teste abarcando 100% das regras de negócio e dos critérios de aceitação	Obrigatório quando aplicável
		Mapeamento de risco	A critério do CAU
		Documento de arquitetura de software	Obrigatório quando aplicável
Análise / Projeto Técnico	10%	Modelo de Dados	Obrigatório quando aplicável
		Dicionário de Dados	Obrigatório quando aplicável
		Script de DDL dos objetos de BD	Obrigatório quando aplicável
		Script de Migração de Dados	Obrigatório quando aplicável
Implementação	40%	Código Fonte	Obrigatório
Testes	15%	Script de teste Unitário e integração com ferramenta de gestão de Builds	Obrigatório quando aplicável
		Script de automação de testes	Obrigatório para todos os casos e cenários que puderem ser automatizados.
		Filmagem das evidências de Testes	Obrigatório para os casos e cenários de testes que não for possível automatizar, a critério do CAU.
		Instruções para publicação da OS nos ambientes de homologação e produção, utilizando a integração contínua	Obrigatório quando aplicável.
Homologação 1° Ciclo (Dono do Produto)		TAG aprovada no 1°ciclo.	Obrigatório
		Script	Obrigatório quando aplicável.
Homologação 2° Ciclo		TAG aprovada no 2º ciclo.	Obrigatório

(Dono do Produto)
		Script	Obrigatório quando aplicável.
		Boletim ou aviso da evolução do produto.	Obrigatório
Implantação	10%	Documento de manutenção	Obrigatório
		Contagem detalhada de PF	Obrigatório

Manutenção Corretiva (MC), Garantia e Serviço
Etapa de desenvolvimento	Percentual de esforço	Documentos/Produtos	Entrega
Análise Prévia da Demanda		Documento de escopo de projeto	Obrigatório
		Matriz funcional	A critério do CAU
		Ordem de serviço/Ticket	Obrigatório
Planejamento do projeto Engenharia de Requisitos	25%	Atualização dos casos de testes com os cenários de teste abarcando 100% das regras de negócio e dos critérios de aceitação	Obrigatório quando aplicável
Análise / Projeto Técnico	10%	Atualização do modelo de Dados	Obrigatório quando aplicável
		Atualização do dicionário de Dados	Obrigatório quando aplicável
		Script de DDL dos objetos de BD	Obrigatório quando aplicável
		Script de Migração de Dados	Obrigatório quando aplicável
Implementação	40%	Código Fonte	Obrigatório
Testes	15%	Atualização do script de teste Unitário e integração com ferramenta de gestão de Builds	Obrigatório quando aplicável
		Atualização do script de automação de testes	Obrigatório para todos os casos e cenários que puderem ser automatizados.
		Filmagem das evidências de Testes	Obrigatório para os casos e cenários de testes que não for possível automatizar, a critério do CAU.
		Instruções para publicação da	Obrigatório quando

		OS nos ambientes de homologação e produção, utilizando a integração contínua	aplicável.
Homologação 1° Ciclo (Dono do Produto)		TAG aprovada no 1°ciclo.	Obrigatório
		Script	Obrigatório quando aplicável.
Homologação 2° Ciclo (Dono do Produto)		TAG aprovada no 2º ciclo.	Obrigatório
		Script	Obrigatório quando aplicável.
		Boletim ou aviso da evolução do produto.	A critério do CAU
Implantação	10%	Documento de manutenção	Obrigatório
		Contagem detalhada de PF	Obrigatório

10. Garantia

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

11. Revisão da MGDS-CAUBR

Esta MGDS-CAUBR poderá ser revisada a qualquer tempo para melhor adequação aos processos do CAU. Sua revisão deverá ocorrer, pelo menos, a cada 12 (doze) meses.

12. Aprovação e Divulgação da MGDS-CAUBR

Esta MGDS-CAU foi elaborada pela Gerência do CSC e aprovada pela Gerência Executiva.

ENCARTE C: MODELO – ORDEM DE SERVIÇO

Solicitação de Serviço – Fábrica de Software
Número OS:	Contrato:	Data de Emissão: / /
Área Requisitante (sigla):		Nome Requisitante:
Tipo de Demanda:		Criticidade (se corretiva): OS em garantia (se defeito):
Necessidade de Homologação assistida:
Descrição:
Documentos Entregues pelo CONTRATANTE
( ) –		( ) –
( ) –		( ) –
Artefatos ou Produtos que deverão ser Entregues pela CONTRATADA
( ) –		( ) –
( ) –		( ) –
( ) –		( ) –
( ) –		( ) –
( ) –		( )
Valores Estimados
Quantidade de PF estimados:      Quantidade de Horas estimadas:		Valor estimado da OS: R$
Datas e Prazos Estimados
Data Prevista para Início dos Produtos / Serviços de       de 20		Data Prevista para Entrega dos Produtos / Serviços de       de 20	Prazo Total do Contrato (com a Garantia) de de 20

CIÊNCIA
CONTRATANTE
Área Requisitante da Solução	Fiscal Requisitante	Fiscal Técnico	Gestor do Contrato
Nome Cargo	Nome Cargo	Nome Cargo	Nome Cargo
CONTRATADA
Preposto
Nome Cargo