COMISSÃO DE VALORES MOBILIÁRIOS PROCESSO DE COMPRAS Nº RJ-2014-2866 EDITAL DO PREGÃO ELETRÔNICO Nº 9/2014

OBJETO: Contratação de serviços em Tecnologia da Informação (TI) para desenvolvimento e manutenção de sistemas, conforme condições, quantidades e exigências estabelecidas neste Edital e em seus anexos.

SETOR INTERESSADO: Superintendência Administrativo-Financeira (SAD) /

Superintendência de Informática (SSI).

TIPO DE LICITAÇÃO: MENOR PREÇO

DA SESSÃO PÚBLICA: Local: xxxx://xxx.xxxxxxxxxx.xxx.xx

Data de Abertura: 20 de maio de 2014 Horário de Abertura: 10h00min

REGULAMENTAÇÃO BÁSICA: Lei 10.520, de 17/07/02; Lei complementar n.º 123, de

14/12/2006; Decreto n.° 5.450, de 31/05/2005; Decreto n.º 3.555, de 8/8/2000; Decreto n.º 6.204, de 5/9/2007; Decreto n.º 7.174, de 12/5/2010; Instrução Normativa SLTI/MP n.º 02, de 30/4/2008 e suas alterações posteriores; Instrução Normativa SLTI/MP n.º 04, de 12/11/2010; Lei nº 8.666/1993 e suas alterações posteriores (subsidiariamente) e outras normas aplicáveis ao objeto deste certame.

O Pregoeiro e Equipe de Apoio, designados pela Portaria CVM/PTE/nº 120, de 12/8/2013, realizarão, no dia, horário e local acima indicados, o Pregão Eletrônico nº 9/2014, em obediência aos termos dos dispositivos legais e às condições estabelecidas neste edital e seus anexos, dispostos a seguir:

ANEXO I	- Termo de Referência;
ANEXO II	- Modelo para apresentação da proposta;
ANEXO III	- Modelo de Planilha de Custos e Formação de Preços;
ANEXO IV	- Minuta de Termo de Contrato;
ANEXO V	- Declaração de Direito de Preferência.
ANEXO VI	- Modelo de Atestado de Capacidade Técnica

1. DO OBJETO

1.1. O objeto da presente licitação é a escolha da proposta mais vantajosa para a contratação de pessoa jurídica especializada na prestação de serviços em Tecnologia da Informação (TI), pelo prazo de 30 (trinta) meses, para desenvolvimento e manutenção de sistemas, conforme condições, quantidades e exigências estabelecidas neste Edital e em seus anexos:

1.2. A licitação será composta por um único grupo, dividido em cinco itens, conforme quadro abaixo, devendo a licitante oferecer proposta para todos os itens que o compõem.

Grupo	Item	Descrição
1	1	Desenvolvimento e Manutenção de Sistemas em ASP Clássico, PHP e VB6
	2	Desenvolvimento e Manutenção de Sistemas em Delphi
	3	Desenvolvimento e Manutenção de Sistemas em Java
	4	Desenvolvimento e Manutenção de Sistemas em dotNet
	5	Desenvolvimento e Manutenção de Sistemas em OpenCMS

1.2.1. O não parcelamento do objeto encontra-se justificado no item 5.1 do Termo de Referência, Anexo I deste Edital.

2. DA DESTINAÇÃO ORÇAMENTÁRIA

2.1. As despesas para atender a esta licitação estão programadas em dotação orçamentária própria, prevista no orçamento da União para o exercício de 2014 na classificação abaixo:

Fonte: 0174

Programas de Trabalho: 04.123.2039.20WU.0001 Elemento de Despesa: 339039

3. DO CREDENCIAMENTO

3.1. O credenciamento é o nível básico do registro cadastral no Sistema de Cadastramento Unificado de Fornecedores - SICAF, que permite a participação dos interessados na modalidade licitatória Pregão, em sua forma eletrônica (artigo 11, Caput, da IN n.º 02/2010).

3.2. O credenciamento dar-se-á pela atribuição de chave de identificação e de senha, pessoal e intransferível, para acesso ao sistema eletrônico (artigo 3.º, § 1.º, do Decreto n.º 5.450/2005), no sitio xxxx://xxx.xxxxxxxxxx.xxx.xx.

3.3. O credenciamento da licitante dependerá de registro cadastral atualizado no SICAF (artigo 3.º, § 2.º do Decreto n.º 5.450/2005).

3.4. O uso da senha de acesso pela licitante é de sua responsabilidade exclusiva, incluindo qualquer transação efetuada diretamente ou por seu representante, não cabendo ao provedor do sistema ou à Comissão de Valores Mobiliários – CVM, entidade promotora da licitação, responsabilidade por eventuais danos decorrentes do uso indevido da senha, ainda que por terceiros (artigo 3.º, § 5.º, do Decreto n.º 5.450/2005).

3.5. O credenciamento junto ao provedor do sistema implica a responsabilidade legal da licitante ou de seu representante legal e a presunção de sua capacidade técnica para realização das transações inerentes ao pregão eletrônico (artigo 3.º, § 6.º, do Decreto n.º 5.450/2005).

4. DAS CONDIÇÕES DE PARTICIPAÇÃO

4.1. Poderão participar deste Pregão entidades empresariais cujo ramo de atividade seja compatível com o objeto desta licitação, e que estejam com Credenciamento regular no SICAF, conforme disposto no §3.º do artigo 8.º da Instrução Normativa SLTI/MP n.º 2/2010.

4.2. Não poderão participar da presente licitação:

4.2.1. entidades empresariais que estejam sob falência, em recuperação judicial ou extrajudicial, concurso de credores, concordata ou insolvência, em processo de dissolução ou de liquidação (inciso II do artigo 31 da Lei n.º 8.666/1993 c/c artigo 63 da Lei n.º 11.101/2005);

4.2.2. entidades empresariais que tenham sido declaradas inidôneas por qualquer órgão ou entidade das Administrações Públicas Federal, Estadual ou Municipal (inciso IV do artigo 40 da IN SLTI/MP n.º 02/2010);

4.2.3. entidades empresariais que estejam cumprindo a sanção de suspensão do direito de licitar com a CVM, conforme inciso III do artigo 87 da lei nº 8.666/1993;

4.2.4. entidades empresariais que estejam cumprindo sanção de impedimento do direito de licitar e contratar com a União (artigo 7.º da Lei n.º 10.520/2002);

4.2.5. entidades empresariais cujos estatutos ou contratos sociais não sejam compatíveis com o objeto desta licitação;

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

4.2.7. entidades empresariais que não tenham representação legal no Brasil com poderes expressos para receber citação e responder administrativa ou judicialmente (inciso V do artigo 28 da Lei n.º 8.666/1993);

4.2.8. entidades empresariais que estejam reunidas em consórcio, sejam controladoras, coligadas ou subsidiárias entre si;

4.2.9. entidades empresariais da qual seja sócio, cooperado, dirigente ou responsável técnico, servidor da CVM ou quaisquer interessados que se enquadrem nas vedações previstas no artigo 9º da lei nº 8.666/1993;

4.3. Como condição para participação no Pregão, a licitante assinalará “sim” ou “não” em campo próprio do sistema eletrônico, relativo às seguintes declarações:

4.3.1. que cumpre os requisitos estabelecidos no artigo 3.° da Lei Complementar n.º 123/2006, estando apta a usufruir do tratamento favorecido estabelecido em seus artigos 42 a 49;

4.3.1.1. a assinalação do campo “não” apenas produzirá o efeito de o licitante não ter direito ao tratamento favorecido previsto na Lei Complementar n.º 123/2006, mesmo que microempresa ou empresa de pequeno porte.

4.3.2. que está ciente e concorda com as condições contidas no Edital e seus anexos, bem como de que cumpre plenamente os requisitos de habilitação definidos no Edital;

4.3.3. que inexistem fatos impeditivos para sua habilitação no certame, ciente da obrigatoriedade de declarar ocorrências posteriores;

4.3.4. que não emprega menor de 18 anos em trabalho noturno, perigoso ou insalubre e não emprega menor de 16 anos, salvo menor, a partir de 14 anos, na condição de aprendiz, nos termos do artigo 7.°, XXXIII, da Constituição Federal.

4.3.5. que a proposta foi elaborada de forma independente, nos termos da Instrução Normativa SLTI/MP n.º 2/2009;

5. DA VISTORIA (FACULTATIVA)

5.1. As empresas interessadas poderão realizar vistoria nas instalações da CVM, de forma a obter pleno conhecimento dos equipamentos a serem alocados em Datacenter da Contratada, do ambiente operacional, bem como de todas as informações necessárias à formulação da sua proposta de preços.

5.2. A vistoria será agendada por meio do telefone (00) 0000-0000, diretamente com o servidor Xxxx Xxxx xx Xxxxx.

5.3. Caso o licitante opte por realizar a vistoria, esta deverá ser efetuada com acompanhamento de um servidor da CVM, em dias úteis, de segunda a sexta-feira, no horário das 10h00min às 17h00min, até o dia útil anterior à data fixada para abertura da sessão pública.

5.4. A realização da vistoria não se consubstancia em condição para participação na licitação, ficando, contudo, as licitantes cientes de que após a apresentação das propostas não serão admitidas, em hipótese alguma, alegações no sentido da inviabilidade de cumprir com as obrigações, face ao desconhecimento dos serviços e de dificuldades técnicas não previstas.

6. DA IMPUGNAÇÃO DO EDITAL E DO PEDIDO DE ESCLARECIMENTO

6.1. Os pedidos de esclarecimentos referentes a este processo licitatório deverão ser enviados ao Pregoeiro até 3 (três) dias úteis anteriores à data designada para abertura da sessão pública, não incluindo como termo final a data da abertura, exclusivamente por meio eletrônico via internet, no endereço xxxxxxxxx@xxx.xxx.xx (artigo 19 do Decreto n.º 5.450/2005).

6.2. Até 2 (dois) dias úteis anteriores à data fixada para abertura do pregão, não incluindo como termo final a data da abertura, encerrando-se necessariamente no dia anterior, qualquer pessoa poderá impugnar o ato convocatório deste pregão (artigo 18, caput, do Decreto n.º 5.450/2005).

6.3. A impugnação deverá ser encaminhada, via internet, para o endereço xxxxxxxxx@xxx.xxx.xx.

6.4. Caberá ao Pregoeiro, auxiliado pelos setores responsáveis pela elaboração do Edital e seus anexos, decidir sobre a impugnação no prazo de até 24 (vinte e quatro) horas (artigo 18, § 1º c/c artigo 11, inciso II, do Decreto n.º 5.450/2005).

6.5. Acolhida a impugnação, será definida e publicada nova data para a realização do certame (artigo 18, § 2.º do Decreto n.º 5.450/2005).

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

6.7. As respostas às impugnações e aos esclarecimentos solicitados serão disponibilizadas no sistema eletrônico para consulta por qualquer interessado.

6.8. Qualquer modificação no Edital será divulgada no mesmo instrumento de publicação em que se deu o texto original, reabrindo-se o prazo inicialmente estabelecido, exceto quando, inquestionavelmente, a alteração não afetar a formulação das propostas (artigo 20, do Decreto 5.450/2005).

7. DO ENVIO DA PROPOSTA DE PREÇOS

7.1. A licitante deverá encaminhar sua proposta, exclusivamente por meio do sistema eletrônico, no sítio xxx.xxxxxxxxxx.xxx.xx, com a descrição do objeto ofertado, o preço e, se for o caso, o respectivo anexo, até a data e hora marcadas para abertura da sessão, quando então encerrar-se-á automaticamente a fase de recebimento de propostas (artigo 21, do Decreto n.º 5.450/2005).

7.2. O encaminhamento da proposta dar-se-á por meio da digitação da senha privativa da licitante (artigo 21, § 1.º, do Decreto n.º 5.450/2005).

7.3. A proposta inicial de preços deverá ser ofertada pelo VALOR TOTAL DE CADA ITEM DO GRUPO, apurado pela multiplicação do quantitativo total de Pontos de Função estimado para o período de 30 meses para cada linguagem de programação (item) pelos respectivos preços unitários propostos.

7.3.1. Os itens 1 a 5 do objeto deste Edital compõem um único grupo para fins de apresentação das propostas e/ou dos lances durante a sessão pública da licitação, cabendo às licitantes, obrigatoriamente, ofertar suas propostas e/ou lances para todos os itens, como condição de participação.

7.4. Até a abertura da sessão, os licitantes poderão retirar ou substituir a proposta anteriormente apresentada (artigo 21, § 4.º, do Decreto n.º 5.450/2005).

7.5. A licitante será responsável por todas as transações que forem efetuadas em seu nome no sistema eletrônico, assumindo como firmes e verdadeiras sua proposta e lances (artigo 3.º, § 5.º, Decreto n.º 5.450/2005).

7.6. Os preços propostos serão de exclusiva responsabilidade da licitante, não lhe assistindo o direito de pleitear quaisquer alterações dos mesmos, sob alegação de erro, omissão ou de qualquer outro pretexto.

7.7. Não serão consideradas propostas com alternativas. As licitantes devem se limitar às especificações deste Edital.

7.8. Na hipótese de se verificar incoerência entre o preço unitário e o total, prevalecerá o mais vantajoso para a CVM. Entre o valor por extenso e o numérico, prevalecerá o por extenso.

7.9. A simples participação neste certame implica:

7.9.1. a aceitação de todas as condições estabelecidas neste Edital de Pregão Eletrônico;

7.9.2. que nos valores propostos estarão inclusos todos os custos operacionais, encargos previdenciários, trabalhistas, tributários, comerciais e quaisquer outros que incidam direta ou indiretamente no fornecimento do objeto ofertado;

7.9.3. que o prazo de validade da proposta é de 60 (sessenta) dias, contado da data estipulada para sua entrega, o qual, se maior, deverá ser explicitado na proposta.

8. DA ABERTURA DA SESSÃO PÚBLICA

8.1. A abertura da presente licitação dar-se-á em sessão pública, por meio de sistema eletrônico, na data, horário e local indicados neste Edital.

8.2. 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 (artigo 22, §5.º do Decreto n.º 5.450/2005).

8.3. Incumbirá à 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 (artigo 13, Inciso IV do Decreto n.º 5.450/2005).

8.4. Não será admitida a desistência da proposta/lance, após o início ou o encerramento da fase de lances.

8.5. Excepcionalmente, após o encerramento da fase de lances, poderá ser acatado o pedido de desistência da proposta, em razão de motivo justo devidamente comprovado pela licitante, decorrente de fato superveniente, e aceito pelo Pregoeiro.

8.6. Não restando comprovado o atendimento aos requisitos fixados no item acima, a licitante desistente ficará sujeita a aplicação das sanções previstas neste Edital.

9. DA CLASSIFICAÇÃO DAS PROPOSTAS

9.1. O pregoeiro verificará as propostas apresentadas, desclassificando aquelas que não estejam em conformidade com os requisitos estabelecidos no Edital, contenham vícios insanáveis ou não apresentem as especificações técnicas exigidas no Termo de Referência (artigo 22, §2.º, do Decreto nº 5.450/2005).

9.1.1. A desclassificação será sempre fundamentada e registrada no sistema, com acompanhamento em tempo real por todos os participantes (artigo 22, §3.º, do Decreto nº 5.450/2005).

9.1.2. 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.

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

10. DA FORMULAÇÃO DE LANCES

10.1. Iniciada a etapa competitiva, as licitantes deverão encaminhar lances exclusivamente por meio de sistema eletrônico, sendo imediatamente informadas do seu recebimento e do valor consignado no registro (artigo 24, Caput e §1.º do Decreto nº 5.450/2005).

10.2. Os lances deverão ser ofertados pelo VALOR TOTAL DE CADA ITEM DO GRUPO.

10.2.1. Os itens 1 a 5 do objeto deste Edital compõem um único grupo para fins de apresentação das propostas e/ou dos lances durante a sessão pública da licitação, cabendo às licitantes, obrigatoriamente, ofertar suas propostas e/ou lances para todos os itens, como condição de participação.

10.2.2. Considera-se Valor Total de Cada Item do Grupo o resultado obtido a partir da multiplicação do quantitativo total de Pontos de Função estimado para o período de 30 meses para cada linguagem de programação (item) pelos respectivos preços unitários propostos.

10.3. Na fase de lances, embora a classificação final seja pelo valor global do grupo, a disputa será por item. A cada lance ofertado (por item), o sistema eletrônico atualizará automaticamente o valor global do grupo/lote, sagrando-se vencedora a licitante que ofertar o MENOR VALOR GLOBAL DO GRUPO/LOTE.

10.4. Os licitantes poderão oferecer lances sucessivos, observado o horário fixado e as regras estabelecidas neste Edital (artigo 24, § 2.º, do Decreto n.º 5.450/2005).

10.4.1. Em observância às disposições insertas na IN SLTI/MP n.º 03, de 16 de dezembro de 2011, o intervalo entre os lances enviados pela mesma licitante não poderá ser inferior a 20 segundos e o intervalo entre lances não poderá ser inferior a 3 (três) segundos.

10.4.2. Os lances enviados em desacordo com o subitem acima serão excluídos automaticamente pelo sistema eletrônico.

10.5. As licitantes somente poderão oferecer lance inferior ao último por elas ofertado e registrado pelo sistema (artigo 24, § 3.º, do Decreto n.º 5.450/2005).

10.6. Não serão aceitos dois ou mais lances de mesmo valor, prevalecendo aquele que for recebido e registrado em primeiro lugar (artigo 24, § 4.º, do Decreto n.º 5.450/2005).

10.7. Durante o transcurso da sessão pública, as licitantes serão informadas, em tempo real, do valor do menor lance registrado que tenha sido apresentado pelas demais licitantes, vedada a identificação da detentora do lance (artigo 24, § 5.º, do Decreto n.º 5.450/2005).

10.8. No caso de desconexão com o pregoeiro, no decorrer da etapa competitiva do pregão, o sistema eletrônico poderá permanecer acessível às licitantes para a recepção dos lances. O pregoeiro, quando possível, dará continuidade à sua atuação no certame, sem prejuízo dos atos realizados (artigo 24, § 10.º, do Decreto n.º 5.450/2005).

10.8.1. Quando a desconexão persistir por tempo superior a 10 (dez) minutos, a sessão do pregão será suspensa e terá reinicio somente após comunicação aos participantes, no sítio xxx.xxxxxxxxxx.xxx.xx (artigo 24, § 11, do Decreto n.º 5.450/2005).

10.8.2. A etapa de lances da sessão pública será encerrada por decisão do pregoeiro (artigo 24, § 6.º, do Decreto n.º 5.450/2005).

10.8.3. O sistema emitirá aviso de fechamento iminente dos lances, após o que transcorrerá período de tempo de até 30 (trinta) minutos, aleatoriamente determinado, findo o qual será automaticamente encerrada a recepção de lances (artigo 24, § 7.º, do Decreto n.º 5.450/2005).

10.9. Caso o licitante não apresente lances, concorrerá com o valor de sua proposta e, na hipótese de desistência de apresentar outros lances, valerá o último lance por ele ofertado, para efeito de ordenação das propostas.

11. DO BENEFÍCIO ÀS MICROEMPRESAS E EMPRESAS DE PEQUENO PORTE

11.1. Encerrada a etapa de lances, será efetivada a verificação automática, junto à Receita Federal, do porte da entidade empresarial. O sistema identificará em coluna própria as microempresas e empresas de pequeno porte participantes, procedendo à comparação com os valores da primeira colocada, se esta for empresa de maior porte, assim como das demais classificadas, para o fim de aplicar-se o disposto nos artigos 44 e 45 da LC n.º 123/2006, regulamentada pelo Decreto n.º 6.204/2007.

11.2. As propostas de microempresas e empresas de pequeno porte que se encontrarem na faixa de até 5% (cinco por cento) acima da proposta ou lance de menor preço serão consideradas empatadas com a primeira colocada (artigo 5.º, §§1.º e 2.º do Decreto n.º 6.204/2007).

11.3. A melhor classificada nos termos do item anterior terá o direito de encaminhar uma última oferta para desempate, obrigatoriamente em valor inferior ao da primeira colocada, no prazo de 5 (cinco) minutos controlados pelo sistema, contados após a comunicação automática para tanto (artigo 5.º, §4.º, inciso I e §6.º do Decreto n.º 6.204/2007).

11.4. Caso a microempresa ou empresa de pequeno porte melhor classificada desista ou não se manifeste no prazo estabelecido, serão convocadas as demais licitantes microempresa e empresa de pequeno porte que se encontrem naquele intervalo de 5% (cinco por cento), na ordem de classificação, para o exercício do mesmo direito, no prazo estabelecido no subitem anterior (artigo 5.º, §4.º, inciso II do Decreto n.º 6.204/2007).

11.5. Caso não se ofertem lances e sejam identificadas propostas de preços idênticos de microempresa ou empresa de pequeno porte empatadas na faixa de até 5% (cinco por cento) sobre o valor cotado pela primeira colocada, e permanecendo o empate até o encerramento do item, o sistema fará sorteio eletrônico entre tais fornecedores, definindo e convocando automaticamente o vencedor para o encaminhamento da oferta final de desempate (artigo 5.º, §4.º, inciso III do Decreto n.º 6.204/2007).

11.6. Havendo êxito no procedimento de desempate, o sistema disponibilizará a nova classificação de fornecedores para fins de aceitação do valor ofertado. Não sendo aplicável o procedimento, ou não havendo êxito na aplicação deste, prevalecerá a classificação inicial.

11.7. Em eventual empate entre propostas, o critério de desempate será aquele previsto no art. 3.º, §2.º, da Lei n.º 8.666/1993, assegurando-se a preferência, sucessivamente, aos serviços:

11.7.1. prestados por empresas brasileiras;

11.7.2. prestados por empresas que invistam em pesquisa e no desenvolvimento de tecnologia no País.

11.8. Persistindo o empate, o critério de desempate será o sorteio, em ato público para o qual os licitantes serão convocados, vedado qualquer outro processo.

12. DO DIREITO DE PREFERÊNCIA PREVISTO NO DECRETO N.º 7.174/2010

12.1. Após os procedimentos para aplicação das regras de preferência para as microempresas e empresas de pequeno porte, será definida, se for o caso, nova ordem de classificação dos licitantes, a fim de se conceder o direito de preferência previsto no Decreto nº 7.174/2010.

12.2. Diante da impossibilidade de aplicar o direito de preferência previsto no Decreto n.º 7.174/2010, para itens agrupados, pelo Sistema Eletrônico Comprasnet, tal providência será realizada pelo manualmente pelo Pregoeiro.

12.3. Os licitantes cujas propostas finais estejam situadas até 10% (dez por cento) acima da melhor proposta válida serão convocados para encaminhar, sob as penas da lei, a Declaração de Direito de Preferência – Anexo V deste Edital.

12.4. A convocação será realizada via chat, licitante por licitante, para que no prazo de até 15 (quinze) minutos, encaminhe o Anexo V deste edital eletronicamente via e-mail: xxxxxxxxx@xxx.xxx.xx .

12.5. O exercício de direito de preferência será concedido observando-se o disposto no art. 8º do Decreto n.º 7.174/2010, conforme segue abaixo:

1º - Tecnologia no País + Processo Produtivo Básico + Micro e Pequenas empresas. 2º - Tecnologia no País + Processo Produtivo Básico.

3º - Tecnologia no País + Micro e Pequenas empresas. 4º - Tecnologia no País.

5º - Processo Produtivo Básico + Micro e Pequenas empresas. 6º - Processo Produtivo Básico.

12.6. Na ordem de classificação acima, os licitantes serão convocados para oferecerem nova proposta ou novo lance para igualar ou superar a melhor proposta válida, caso em que será declarado vencedor do certame (artigo 8.º, Inciso III, do Decreto n.º 7.174/2010).

12.7. A comprovação do atendimento ao PPB ou aos bens e serviços com tecnologia desenvolvida no País será feita mediante apresentação, juntamente com os demais documentos de habilitação, dos documentos comprobatórios da habilitação à fruição dos incentivos fiscais regulamentado pelo Decreto n.º 5.906, de 26 de setembro de 2006, ou pelo Decreto n.º 6.008, de 29 de dezembro de 2006 (artigo 7.º, Caput, do Decreto n.º 7.174/2010).

12.8. A comprovação/certificação será feita (artigo 7.º, Parágrafo único, do Decreto n.º 7.174/2010):

12.8.1. eletronicamente, por meio de consulta ao sítio eletrônico oficial do Ministério da Ciência e Tecnologia ou da Superintendência da Zona Franca de Manaus - SUFRAMA; ou

12.8.2. por documento expedido para esta finalidade pelo Ministério da Ciência e Tecnologia ou pela SUFRAMA, mediante solicitação da licitante.

12.9. A veracidade acerca das informações constantes dos documentos apresentados pelas licitantes será verificada mediante consulta ao sítio do Ministério da Ciência e Tecnologia.

12.10. Não serão aceitos como meio de comprovação documentos e/ou declarações emitidos pela própria licitante ou pelo fabricante.

12.11. Caso nenhuma empresa classificada venha a exercer o direito de preferência, observar-se- ão as regras usuais de classificação e julgamento previstas na Lei n.º 8.666/1993, e na Lei n.º 10.520/2002. Neste caso, prevalecerá o resultado inicialmente apurado pelo sistema eletrônico (artigo 8.º, Inciso V, do Decreto n.º 7.174/2010).

13. DO JULGAMENTO DAS PROPOSTAS

13.1. Encerrada a etapa de lances e depois da verificação de possível empate, o Pregoeiro examinará a proposta classificada em primeiro lugar para fim de aceitação (artigo 25, caput, Decreto n.º 5.450/2005).

13.2. A Proposta Comercial deverá ser devidamente preenchida em todos os itens nela inseridos, conforme modelos constantes nos Anexos II e III deste Edital.

13.3. Para julgamento e classificação das propostas, será adotado o critério do MENOR PREÇO TOTAL GLOBAL, apurado de acordo com a tabela constante no Anexo III deste Edital, e observados os preços unitários máximos de cada item.

13.4. A proposta de preços deverá conter os seguintes itens/documentos:

13.4.1. nome do proponente, endereço, número de telefone e/ou fax, CEP, aposição do carimbo padronizado do CNPJ da empresa e a inscrição Estadual e/ou Municipal ou do Distrito Federal ou papel timbrado com estas informações;

13.4.2. planilha de custos e formação de preços, devidamente preenchida, contendo os preços unitários e totais para cada item, conforme planilha modelo contida no Anexo III deste Edital;

13.4.3. o valor da proposta, limitado a 2 casas decimais, expresso em moeda corrente nacional, em algarismos e por extenso, incluindo todas as despesas legais ou adicionais, previstas neste Edital e seus Anexos;

13.4.4. o prazo de validade dos preços (mínimo de 60 dias corridos), a contar da data do encaminhamento, via sistema, da proposta (Art. 27, § 4.º do Decreto n.º 5.450/2005);

13.4.5. o nome do banco com o qual a licitante opera, o número e nome da agência e respectiva conta-corrente. A fim de agilizar o pagamento, é conveniente a indicação de uma das agências do Banco do Brasil S.A.;

13.5. As folhas da proposta, contendo os itens citados acima, devem ser rubricadas e numeradas, e a última datada e assinada pelo seu representante legal.

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

13.7. Não será aceito o lance vencedor com valores superiores aos preços máximos fixados por item do grupo ou que apresentar preço manifestamente inexequível (artigo 48, inciso II, da Lei n.º 8.666/1993).

13.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.

13.9. Considerar-se-á inexequível a proposta que não venha a ter demonstrada sua viabilidade por meio de documentação que comprove que os custos são suficientes para a cobertura dos gastos decorrentes da contratação (artigo 29, § 1.º, da IN SLTI/MP n.º 2/2008).

13.10. 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/1993, a exemplo das enumeradas no §3.º, do artigo 29, da IN SLTI/MP n.º 2, de 2008.

13.11. Será desclassificada a proposta que, após as diligências, não corrigir ou justificar eventuais falhas apontadas pelo Pregoeiro.

13.12. Erros no preenchimento da planilha não constituem motivo para a desclassificação da proposta. A planilha poderá ser ajustada pelo licitante, no prazo indicado pelo Pregoeiro, desde que não haja majoração do preço proposto (artigo 24 da IN SLTI/MPOG n.º 2/2008).

13.13. Se a proposta ou lance de menor valor não for aceitável, o Pregoeiro examinará a proposta ou lance subsequente, e, assim sucessivamente, na ordem de classificação (artigo 4.º, inciso XVI, da Lei n.º 10.520/2002).

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

13.14.1. O Pregoeiro poderá encaminhar, por meio do sistema eletrônico, contraproposta ao licitante que apresentou o lance mais vantajoso, com o fim de negociar a obtenção de melhor preço, vedada a negociação em condições diversas das previstas neste Edital (artigo 24, § 8.º, do Decreto n.º 5.450/2005).

13.14.2. 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.

13.14.3. A negociação será realizada por meio do sistema, podendo ser acompanhada pelos demais licitantes (artigo 24, § 9.º, do Decreto n.º 5.450/2005).

13.15. Sempre que a proposta não for aceita, e antes de o Pregoeiro passar à subsequente, haverá nova verificação, pelo sistema, da eventual ocorrência do empate ficto, previsto nos artigos 44 e 45 da LC n.º 123/2006, seguindo-se a disciplina antes estabelecida, se for o caso.

14. DA HABILITAÇÃO

14.1. A licitante melhor classificada deverá encaminhar a documentação referente à habilitação, juntamente com a proposta de preços (Anexos II e III), assinada, digitalizada e atualizada em conformidade com o último lance ofertado, por meio da opção “Enviar Anexo”, no prazo de 4 (quatro) horas após a convocação do pregoeiro no sistema eletrônico.

14.1.1. O prazo estabelecido para envio da proposta de preços e dos documentos de habilitação poderá ser prorrogado por solicitação escrita e justificada do licitante, formulada antes de findo o prazo estabelecido, e formalmente aceita pelo Pregoeiro.

14.1.2. A documentação assinada e digitalizada referente à aceitação e habilitação também poderá ser remetida por meio de mensagem para o e-mail xxxxxxxxx@xxx.xxx.xx, preferencialmente, ou por meio do fac-símile (21) 3554- 8475, nos casos de solicitação do Pregoeiro, para fins de agilizar o envio da documentação à área técnica da CVM, sem prejuízo da disponibilização pelo Sistema Eletrônico, ou de comprovada inviabilidade ou dificuldade de envio ou recebimento pelo Sistema Eletrônico, sendo que, nesta última hipótese, será providenciado, em momento posterior, o uso da funcionalidade “Convocar anexo”, de forma que a documentação seja inserida no Sistema Eletrônico e, assim, fique à disposição das demais licitantes.

14.1.3. Dentro do prazo estabelecido neste item poderão ser remetidos, por iniciativa da licitante, tantos quantos forem os documentos complementares ou retificadores afetos à sua proposta ou habilitação. Na hipótese da proposta já ter sido incluída no Sistema Eletrônico, faz-se necessário que a licitante formalize ao Pregoeiro, via mensagem (e-mail), preferencialmente ou fac-símile, o desejo de envio de nova documentação. Nesse caso, Pregoeiro fará novo uso da funcionalidade “Convocar anexo”.

14.1.4. A fim de aplicar o princípio da isonomia entre as licitantes, depois de transcorrido o prazo estabelecido neste item, não serão considerados, para fins de análise, sob qualquer alegação, o envio da documentação de habilitação ou de qualquer outro documento complementar ou retificador ou que deveria/poderia ter sido remetido, sendo realizado, pelo Pregoeiro, o registro da não aceitação ou inabilitação, e a convocação da próxima licitante, salvo quando se tratar de:

14.1.4.1. ajustes na Proposta em função da negociação de preços;

14.1.4.2. ajustes na Proposta em função de impropriedades ou omissões sanáveis, não conflitantes com os termos do Edital e com a lisura da competição; ou

14.1.4.3. documento enviado em virtude de diligência destinada a esclarecer ou a complementar a instrução do processo.

14.2. Adicionalmente, deverá apresentar os documentos de habilitação e proposta de preços originais ou cópias autenticadas, no prazo de até 48 (quarenta e oito) horas após o encerramento da sessão pública, à Comissão de Valores Mobiliários - Gerência de Licitações e Contratos, localizada na Xxx Xxxx xx Xxxxxxxx, 000, 00x xxxxx, Xxxxxx, Xxx xx Xxxxxxx - XX, CEP: 20.050-901, em envelope fechado e rubricado (artigo 25, §§ 2.º e 3.º, do Decreto n.º 5.450/2005).

14.3. A comprovação das habilitações jurídica, fiscal e econômico-financeira poderá ser realizada por meio de consulta on line ao SICAF (artigo 25, § 1.º, do Decreto n.º 5.450/2005 c/c artigo 3.º, caput e artigo 4.º, caput, IN SLTI/MP n.º 02/2010).

14.4. Deverá constar do envelope a seguinte documentação complementar ao SICAF:

14.4.1. Certidão Negativa de Débitos Trabalhistas (CNDT – negativa ou positiva com efeitos de negativa), consoante artigo 29, inciso V, da lei 8.666/1993, de modo a comprovar a inexistência de débitos inadimplidos perante a Justiça do Trabalho.

14.4.2. Proposta de Preços, conforme Anexos II e III do presente Edital.

14.4.3. Comprovação/certificação de que atende às condições legais para a comprovação de qualquer um dos requisitos estabelecidos no item 12 deste Edital (artigos 6.º e 7.º do Decreto n.º 7.174/2010), caso tenha apresentado a declaração, por meio de: consulta ao sítio eletrônico oficial do Ministério da Ciência e Tecnologia ou SUFRAMA ou documento expedido para esta finalidade pelo Ministério da Ciência e Tecnologia ou pela SUFRAMA, mediante solicitação da licitante.

14.5. Comprovação de aptidão para desempenho de atividade pertinente e compatível em características e quantidades com o objeto desta licitação, mediante apresentação de no

mínimo 1 (um) atestado de capacidade técnica, conforme modelo constante no Anexo VI deste Edital, demonstrando que o licitante tenha prestado, para empresas ou organizações públicas ou privadas, de modo satisfatório, serviços de desenvolvimento, manutenção corretiva e evolutiva em sistemas de informação em quantidades compatíveis às estimadas para esta contratação, conforme quadro a seguir:

Tecnologia.	Total de Pontos de Função
Java	5.000
OpenCMS ou outra tecnologia de desenvolvimento de sites com Gestão de Conteúdo	500
Delphi 5.0	1.500

14.5.1. Para a linguagem OpenCMS não serão aceitos atestados parciais, mesmo que a soma total destes atinja o total exigido. Deverá, neste caso, ser apresentado ao menos um atestado de capacidade técnica comprovando que a empresa já executou, em uma mesma empresa ou órgão, de forma satisfatória, o desenvolvimento do total de 500 pontos de função nesta tecnologia ou outra similar de desenvolvimento de Web site com gestão de conteúdo, como, por exemplo, Wordpress e Joomla.

14.5.2. Para as linguagens Java e Delphi, os atestados poderão ser parciais, contanto que atendam às seguintes exigências:

14.5.2.1. o somatório dos pontos de função desenvolvidos para cada linguagem seja igual ou superior ao total exigido, em período não superior a 30 meses;

14.5.2.2. em atestado único, deve haver comprovação de que a licitante executou, de forma satisfatória, o desenvolvimento de no mínimo

2.000 (dois mil) pontos de função para a linguagem Java; e

14.5.2.3. em atestado único, deve haver comprovação de que a licitante executou, de forma satisfatória o desenvolvimento de no mínimo 600 (seiscentos) pontos de função para a linguagem Delphi.

14.5.3. Os atestados deverão comprovar que os serviços prestados foram medidos em pontos de função, sob o regime de fábrica de software, contemplando todas as fases do ciclo de desenvolvimento, conforme modelo constante no Anexo VI deste Edital.

14.5.4. Não serão aceitos atestados de empresa coligada, consorciada ou parceira;

14.5.5. Os atestados de capacidade técnica deverão referir-se a serviços prestados no âmbito de sua atividade econômica principal ou secundária especificadas no contrato social vigente (art. 19, XXV, b da IN SLTI/MPOG n.º 2/2008);

14.5.6. O(s) atestado(s) conterão, preferencialmente, nome (razão social), CNPJ e endereço completo da Contratante e Contratada, as características dos serviços realizados, a data de emissão, nome, cargo, telefone e assinatura do responsável pela emissão do atestado.

14.5.7. O licitante deve disponibilizar todas as informações necessárias à comprovação da legitimidade dos atestados solicitados, apresentando, dentre outros documentos, cópia do contrato que deu suporte à contratação, endereço atual da contratante e local em que foram prestados os serviços (art. 19, §10, da IN SLTI/MPOG n.º 02/2008).

14.5.8. A CVM poderá realizar diligência na empresa vencedora e na empresa ou órgão que fornecer o atestado de capacidade técnica para averiguar a veracidade das informações prestadas, podendo o(s) envolvido(s) responderem administrativa, civil e penalmente pelas informações prestadas.

14.5.9. Os requisitos de qualificação técnica foram estipulados pela CVM para as parcelas de maior relevância e de maior valor significativo do objeto a ser contratado (Súmula 263/2011-TCU), sendo que os quantitativos mínimos estipulados correspondem a 50% da demanda para manutenções evolutivas, corretivas e novos sistemas, com base em dados históricos e medições, os quais representam o mínimo necessário à execução adequada ao porte dos serviços solicitados.

14.5.10. A comprovação da execução em uma mesma empresa ou órgão de 500 pontos de função para a linguagem OpenCMS, 600 (seiscentos) pontos de função para Delphi e 2.000 (dois mil) pontos de função para Java visa a garantir a qualificação técnica da contratada, devido à complexidade e tamanho dos sistemas legados e dos novos desenvolvimentos previstos nestas tecnologias.

14.6. As licitantes que não estiverem cadastradas além do nível de credenciamento ou que não se encontrem com o cadastramento atualizado no SICAF deverão encaminhar, juntamente com a documentação complementar, os documentos relativos à habilitação jurídica, fiscal e qualificação econômico-financeira, detalhados nos itens abaixo.

14.7. Relativamente à HABILITAÇÃO JURÍDICA da licitante:

14.7.1. no caso de empresário individual, inscrição no Registro Público de Empresas Mercantis;

14.7.2. em se tratando de sociedades empresariais ou empresas individuais de responsabilidade limitada, contrato social, estatuto em vigor ou ato constitutivo, devidamente registrado, e, no caso de sociedades por ações, acompanhado de documentos de eleição de seus administradores;

14.7.3. inscrição no Registro Público de Empresas Mercantis onde opera, com averbação no Registro onde tem sede a matriz, no caso de ser o participante sucursal, filial ou agência;

14.7.4. inscrição do ato constitutivo no Registro Civil das Pessoas Jurídicas, no caso de sociedades simples e outras pessoas jurídicas de direito privado, acompanhada de prova de diretoria em exercício;

14.7.5. decreto de autorização, em se tratando de sociedade empresária estrangeira em funcionamento no País.

14.8. Relativamente à REGULARIDADE FISCAL da licitante:

14.8.1. prova de inscrição no Cadastro Nacional de Pessoas Jurídicas;

14.8.2. prova de regularidade com a Fazenda Nacional (certidão conjunta, emitida pela Secretaria da Receita Federal do Brasil e Procuradoria-Geral da Fazenda Nacional, quanto aos demais tributos federais e à Divida Ativa da União, por elas administrados, conforme artigo 1.º, inciso I, do Decreto n.º 6.106/2007);

14.8.3. prova de regularidade com a Seguridade Social (INSS);

14.8.4. prova de regularidade com o Fundo de Garantia do Tempo de Serviço (FGTS);

14.8.5. prova de inscrição no cadastro de contribuintes municipal, relativo ao domicílio ou sede do licitante, pertinente ao seu ramo de atividade e compatível com o objeto contratual;

14.8.6. prova de regularidade com a Fazenda Municipal do domicílio ou sede do licitante, relativa à atividade em cujo exercício contrata ou concorre;

14.8.6.1. Caso o fornecedor seja considerado isento dos tributos municipais relacionados ao objeto licitatório, deverá comprovar tal condição mediante a apresentação de declaração da Fazenda Municipal de seu domicílio ou sede, ou outra equivalente, na forma da lei (artigo 16 da IN SLTI/MP n.º 2/2010);

14.8.7. a licitante detentora do menor preço, sendo microempresa ou empresa de pequeno porte, deverá apresentar toda a documentação exigida para efeito de comprovação de regularidade fiscal, mesmo que esta apresente alguma restrição, sob pena de inabilitação.

14.9. Relativamente à QUALIFICAÇÃO ECONÔMICO-FINANCEIRA da licitante:

14.9.1. certidão negativa de falência ou recuperação judicial expedida pelo distribuidor da sede da pessoa jurídica;

14.9.2. balanço patrimonial e demonstrações contábeis do último exercício social, já exigíveis e apresentados na forma da lei, que comprovem a boa situação financeira da empresa, vedada a sua substituição por balancetes ou balanços provisórios, podendo ser atualizados por índices oficiais quando encerrado há mais de 3 (três) meses da data de apresentação da proposta;

14.9.2.1. no caso de empresa constituída no exercício social vigente, admite- se a apresentação de balanço patrimonial e demonstrações contábeis referentes ao período de existência da sociedade;

14.9.3. comprovação da boa situação financeira da empresa, a ser constatada mediante obtenção de índices de Liquidez Geral (LG), Solvência Geral (SG) e Liquidez Corrente (LC) superiores a 1 (um), resultantes da aplicação das seguintes fórmulas:

14.10. As empresas, cadastradas ou não no SICAF, que apresentarem resultado inferior ou igual a 1(um) em qualquer dos índices de Liquidez Geral (LG), Solvência Geral (SG) e Liquidez Corrente (LC), deverão comprovar que possuem patrimônio líquido igual ou superior a 10% (dez por cento) do valor estimado da contratação. A comprovação será obrigatoriamente feita pelo Ato Constitutivo, Estatuto ou Contrato Social em vigor e devidamente registrado ou pelo balanço patrimonial e demonstrações contábeis do último exercício social, já exigíveis e apresentados na forma da lei, conforme disposto no artigo 31, inciso I, da Lei n.º 8.666/1993, 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.

14.11. As empresas cadastradas ou não no SICAF deverão, ainda, apresentar o seguinte:

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

14.12. Em atendimento à determinação do Tribunal de Contas da União, constante do Acórdão n.º 1.793/2011 - Plenário, também serão realizadas consultas: ao Cadastro Nacional de Empresas Inidôneas e Suspensas (CEIS) do Portal da Transparência; ao Cadastro Nacional de Condenações Cíveis por Ato de Improbidade Administrativa disponível no Portal do CNJ; e à composição societária das empresas no sistema SICAF, a fim de certificar se há entre os sócios servidores da CVM.

14.13. Se a menor proposta ofertada for de microempresa ou empresa de pequeno porte, e uma vez constatada a existência de alguma restrição no que tange à regularidade fiscal, esta será convocada para, no prazo de 2 (dois) dias úteis, após solicitação do Pregoeiro no sistema eletrônico, comprovar a regularização. O prazo poderá ser prorrogado por igual período.

14.13.1. A não regularização fiscal no prazo previsto no subitem anterior acarretará a inabilitação do licitante, sem prejuízo das sanções previstas neste Edital, sendo facultada a convocação dos licitantes remanescentes, na ordem de classificação. Se, na ordem de classificação, seguir-se outra microempresa ou empresa de pequeno porte com alguma restrição na documentação fiscal, será concedido o mesmo prazo para regularização.

14.14. Havendo necessidade de analisar minuciosamente os documentos exigidos, o Pregoeiro suspenderá a sessão, informando no “chat” a nova data e horário para a continuidade da mesma.

14.15. Será inabilitada a licitante que não comprovar sua habilitação, seja por não apresentar quaisquer dos documentos exigidos, ou apresentá-los em desacordo com o estabelecido neste Edital.

14.16. No caso de inabilitação, haverá nova verificação, pelo sistema, da eventual ocorrência do empate ficto, previsto nos artigos 44 e 45 da LC n.º 123/2006, seguindo-se a disciplina antes estabelecida para aceitação da proposta subsequente.

14.17. Quanto aos documentos mencionados nesta seção, não serão aceitos protocolos referentes à solicitação feita às repartições competentes, nem cópias ilegíveis, mesmo que autenticadas.

14.18. A declaração falsa relativa ao cumprimento dos requisitos de habilitação sujeitará a licitante às sanções previstas na legislação pertinente (artigo 21, § 3.º, do Decreto n.º 5.450/2005).

14.19. Constatado o atendimento das exigências fixadas no Edital, a licitante será declarada vencedora, sendo-lhe adjudicado o objeto do certame (artigo 25, § 9.º do Decreto n.º 5.450/2005).

14.20. O Cadastro Nacional da Pessoa Jurídica – CNPJ indicado nos documentos da proposta de preço e de habilitação deverá ser o mesmo da assinatura do contrato e aquele a receber a Nota de Empenho e a emitir a Nota Fiscal/Fatura correspondentes aos serviços, bem como alvo da liquidação da despesa.

14.21. A licitante ficará obrigada a manter válidos todos os documentos relativos à regularidade de cadastramento no SICAF durante todo o procedimento licitatório, bem como durante o período da execução dos compromissos assumidos (artigo 55, inciso XIII da Lei n.º 8.666/1993 c/c artigo 9.º da Lei n.º 10.520/2002).

14.22. Da sessão pública do Pregão divulgar-se-á a Ata no sistema eletrônico.

15. DOS RECURSOS

15.1. Declarado o vencedor e decorrida a fase de regularização fiscal de microempresa ou empresa de pequeno porte, se for o caso, será concedido o prazo de 20 (vinte) minutos, para que qualquer licitante manifeste a intenção de recorrer, de forma motivada, isto é, indicando contra qual(is) decisão(ões) pretende recorrer e por quais motivos, em campo próprio do sistema.

15.2. Havendo quem se manifeste, caberá ao Pregoeiro verificar a tempestividade e a existência de motivação da intenção de recorrer, para decidir se admite ou não o recurso, fundamentadamente.

15.2.1. Nesse momento o Pregoeiro não adentrará no mérito recursal, mas apenas verificará as condições de admissibilidade do recurso.

15.3. A falta de manifestação motivada da licitante quanto à intenção de recorrer importará a decadência desse direito e a consequente adjudicação do objeto pelo Pregoeiro à licitante vencedora (artigo 26, § 1.º, do Decreto n.º 5.450/2005).

15.3.1. Uma vez admitido o recurso, o recorrente terá, a partir de então, o prazo de 3 (três) dias para apresentar as razões, pelo sistema eletrônico, ficando as demais licitantes, desde logo, intimadas para, querendo, apresentarem contrarrazões também pelo sistema eletrônico, em outros três dias, que começarão a contar do término do prazo do recorrente, sendo-lhes assegurada vista imediata dos elementos indispensáveis à defesa de seus interesses (artigo 26, caput, do Decreto n.º 5.450/2005).

15.4. O acolhimento do recurso invalida tão somente os atos insuscetíveis de aproveitamento (artigo 4.º, inciso XIX, da Lei n.º 10.520/2002, c/c artigo 26, § 2.º, do Decreto n.º 5.450/2005).

15.5. As razões recursais deverão ser apresentadas exclusivamente pelo sistema e dirigidas ao Superintendente Administrativo-Financeiro da CVM (artigo 26, caput, do Decreto n.º 5.450/2005).

15.6. Não serão conhecidos os recursos cujas razões/contra-razões recursais sejam enviadas fora do respectivo prazo legal.

15.7. Os autos do processo permanecerão com vista franqueada aos interessados, na Gerência de Licitações e Contratos da CVM, sito à Xxx Xxxx xx Xxxxxxxx, x.x 000, 00.x xxxxx, Xxxxxx, Xxx xx Xxxxxxx – XX, em dias úteis, no horário de 09h às 13h e 14h às 18h (§ 5.º do artigo 109 da Lei n.º 8.666/1993).

16. DA ADJUDICAÇÃO E HOMOLOGAÇÃO

16.1. O objeto da licitação será adjudicado ao licitante declarado vencedor, por ato do Pregoeiro, caso não haja interposição de recurso, ou pela autoridade competente, após a regular decisão dos recursos apresentados.

16.2. Após a fase recursal, constatada a regularidade dos atos praticados, a autoridade competente homologará o procedimento licitatório (artigo 4.º, inciso XXI, da Lei n.º 10.520/2002 c/c artigo 27 do Decreto n.º 5.450/2005).

17. DO TERMO DE CONTRATO

17.1. Após a homologação da licitação, a adjudicada deverá assinar o contrato em até 03 (três) dias úteis, a contar da data do recebimento do respectivo aviso, sob pena de decair o direito à contratação. Este prazo poderá ser prorrogado uma vez, por igual período, quando solicitado pela parte durante o seu transcurso, desde que ocorra motivo justificado e aceito pela CVM (artigo 64, caput e § 1.º, da Lei n.º 8.666/93 c/c artigo 9.º da Lei n.º 10.520/2002).

17.2. O período de vigência do contrato será de 30(trinta) meses, podendo ser prorrogado, quando comprovadamente vantajoso para a CVM, até o limite de 60 (sessenta) meses, conforme disciplinado na minuta de contrato (Anexo IV deste Edital), desde que haja autorização formal da autoridade competente e observados os seguintes requisitos (art.

57, inciso II, da Lei n.º 8.666/1993 c/c art. 30-A, § 1º, da IN SLTI/MP nº 2/2008 e Orientação Normativa AGU n.º 38, de 13/12/2011):

17.2.1. os serviços tenham sido prestados regularmente;

17.2.2. a CVM mantenha interesse na realização do serviço;

17.2.3. o valor do contrato permaneça economicamente vantajoso para a CVM; e

17.2.4. a contratada manifeste expressamente interesse na prorrogação.

17.3. Previamente à contratação e a cada pagamento a fornecedor, a Administração realizará consulta ao SICAF para identificar possível proibição de contratar com o Poder Público e verificar a manutenção das condições de habilitação (artigo 3.º, §1.º, da IN SLTI/MP n.º 2/2010).

17.4. Será exigido o cadastramento quando, anteriormente à assinatura do contrato, o proponente homologado não estiver inscrito no SICAF. Neste caso, o cadastramento deverá ser feito pela Administração, sem ônus para o proponente, com base no reexame da documentação apresentada para habilitação, devidamente atualizada (artigo 3.º,§ 2.º, da IN SLTI/MP n.º 2/2010).

17.5. Se o adjudicatário, no ato da assinatura do Termo de Contrato, não comprovar que mantém as mesmas condições de habilitação, ou quando, injustificadamente, recusar-se à assinatura, poderá ser convocado outro licitante, desde que respeitada a ordem de classificação, para, após a verificação da aceitabilidade da proposta, negociação e comprovados os requisitos de habilitação, celebrar a contratação, sem prejuízo das sanções previstas neste Edital e nas demais cominações legais. (artigo 27, § 3.º do Decreto n.º 5.450/2005).

17.6. A associação da licitante vencedora com outrem, a cessão ou transferência, total ou parcial, bem como a fusão, cisão ou incorporação devem ser comunicadas à CVM para que a autarquia delibere sobre a adjudicação do objeto ou manutenção do contrato, sendo essencial para tanto que a nova empresa comprove atender a todas as exigências de habilitação previstas no Edital.

17.7. É expressamente vedada a subcontratação total ou parcial do objeto deste Edital, sob pena de rescisão contratual.

17.8. Independentemente de transcrição, farão parte do Contrato a ser celebrado:

17.8.1. a proposta da licitante vencedora e seus respectivos anexos;

17.8.2. o presente Edital e seus anexos;

17.8.3. a Nota de Empenho correspondente.

18. DO RECEBIMENTO E ACEITAÇÃO DOS SERVIÇOS E DA FISCALIZAÇÃO

18.1. Os critérios de recebimento e aceitação dos serviços e de fiscalização estão previstos no Termo de Referência, Anexo I deste Edital e na Minuta de Contrato, Anexo IV.

19. DA GARANTIA DE EXECUÇÃO

19.1. A Contratada deverá apresentar garantia de execução conforme estabelecido na Minuta de Contrato (Anexo IV).

20. DA LIQUIDAÇÃO E PAGAMENTO

20.1. As condições para liquidação e pagamento dos serviços prestados pela Contratada são as estabelecidas na Minuta de Contrato (Anexo IV).

21. DAS OBRIGAÇÕES DA CONTRATADA E DA CVM

21.1. As obrigações da Contratada e da CVM são as estabelecidas neste Edital, no Termo de Referência (Anexo I) e na Minuta de Contrato (Anexo IV).

22. DO REAJUSTE

22.1. As condições para reajuste dos preços pactuados são as estabelecidas na Minuta de Contrato (Anexo IV).

23. DAS SANÇÕES ADMINISTRATIVAS

23.1. Comete infração administrativa, nos termos da Lei n.º 10.520/2002, a licitante/adjudicatária que:

23.1.1. não assinar o termo de contrato, quando convocada dentro do prazo de validade da proposta;

23.1.2. apresentar documentação falsa;

23.1.3. deixar de entregar os documentos exigidos no certame;

23.1.4. ensejar o retardamento da execução do objeto;

23.1.5. não mantiver a proposta;

23.1.6. comportar-se de modo inidôneo;

23.1.7. cometer fraude fiscal.

23.2. A licitante/adjudicatária que cometer qualquer das infrações discriminadas no subitem anterior ficará sujeita, sem prejuízo da responsabilidade civil e criminal, às seguintes sanções:

23.2.1. Advertência;

23.2.2. Multa de até 20% (vinte por cento) sobre o valor estimado do(s) item(s) prejudicados(s) pela conduta da licitante;

23.2.3. Multa de 10% (dez por cento), calculada sobre o valor total da proposta ou lance ofertado pela licitante desistente, na hipótese de desistência injustificada do lance, após o encerramento da fase de lances, sem prejuízo da aplicação de outras sanções previstas no artigo 28, do Decreto n.º 5.450/2005 e demais cominações legais;

23.2.4. Multa de 20% (vinte por cento), calculada sobre o valor total da contratação, sem prejuízo da aplicação de outras sanções previstas no artigo 28, do Decreto n.º 5.450/2005, na hipótese de recusa injustificada da licitante vencedora em celebrar o contrato, no prazo máximo de 03 (três) dias úteis, após regularmente convocada, caracterizando inexecução total das obrigações acordadas;

23.2.5. Multa de até 20% (vinte por cento) sobre o valor total da contratação quando for constatado o descumprimento de qualquer obrigação prevista neste Edital e/ou no Termo de Referência, ressalvadas aquelas obrigações para as quais tenham sido fixadas penalidades específicas.

23.2.6. Impedimento de licitar e de contratar com a União e descredenciamento no SICAF, pelo prazo de até 5 (cinco) anos;

23.3. A penalidade de multa pode ser aplicada cumulativamente com as sanções de advertência e de impedimento.

23.4. A multa deverá ser recolhida no prazo máximo de 10 (dez) dias úteis, a contar da data do recebimento da comunicação enviada pela CVM.

23.5. A aplicação de qualquer das sanções previstas realizar-se-á em processo administrativo que assegurará o contraditório e a ampla defesa ao licitante/adjudicatário, observando-se o procedimento previsto na Lei n.º 8.666/1993, e subsidiariamente na Lei n.º 9.784/1999.

23.6. A autoridade competente, na aplicação das sanções, levará em consideração a gravidade da conduta do infrator, o caráter educativo da pena, bem como o dano causado à Administração, observado o princípio da proporcionalidade.

23.7. As penalidades serão obrigatoriamente registradas no SICAF, conforme determina o § 2.º do artigo 36, da Lei n.º 8.666/1993.

24. DOS RECURSOS ADMINISTRATIVOS

24.1. Dos atos praticados pela CVM cabem recursos na forma prevista no artigo 109, da Lei n.º 8.666/1993.

24.2. Os recursos deverão ser entregues, contra recibo, no Protocolo na Gerência de Documentações da CVM (GAD), localizada na Xxx Xxxx xx Xxxxxxxx xx 000, 0x xxxxx, xx Xxxxxx – Xxx xx Xxxxxxx – XX, devendo ser dirigidos à autoridade superior, por intermédio da autoridade que praticou o ato recorrido e, sob pena de preclusão, interpostos no prazo de 05 (cinco) dias úteis contados da intimação do ato (artigo 109, inciso I, alínea “b” da Lei n.º 8.666/1993 c/c artigo 9.º da Lei n.º 10.520/2002).

25. DAS DISPOSIÇÕES FINAIS

25.1. A CVM poderá, a seu critério exclusivo, de acordo com o artigo 65, §1.º, da Lei n.º 8.666/1993, reduzir ou aumentar a quantidade do objeto licitado, desde que não ultrapasse 25% (vinte cinco por cento) do valor inicial atualizado do Contrato.

25.2. O Superintendente Administrativo-Financeiro da CVM poderá revogar a licitação por razões de interesse público decorrente de fato superveniente devidamente comprovado, pertinente e suficiente para justificar tal conduta, mediante parecer por escrito e devidamente fundamentado (artigo 18 do Decreto n.º 3.555/2000 c/c artigo 14 do Decreto n.º 3.697/2000 e artigo 29 do Decreto n.º 5.450/2005).

25.3. Caso constatada ilegalidade no procedimento, o Superintendente Administrativo- Financeiro da CVM deverá anular a licitação, de ofício ou por provocação de terceiros, mediante parecer por escrito e devidamente fundamentado, sem que caiba às licitantes o direito a qualquer reclamação ou indenização, ressalvado o direito do contratado de boa- fé de ser ressarcido pelos encargos que tiver suportado no cumprimento do contrato (artigo 18 do Decreto n.º 3.555/2000, artigo 29, §§ 1.º e 2.º, do Decreto n.º 5.450/2005).

25.4. No caso de desfazimento do processo licitatório, fica assegurado o contraditório e a ampla defesa (artigo 49,§ 3.º da Lei n.º 8.666/1993 c/c artigo 9.º da Lei 10.520/2002).

25.5. O pregoeiro poderá desclassificar proponentes por ato fundamentado, sem direito à indenização ou ressarcimento, sem prejuízo de outras sanções cabíveis, em razão de fatos supervenientes ou só conhecidos após o julgamento e que desabonem a sua idoneidade financeira, capacidade técnica ou administrativa (artigo 43, § 5.º da Lei n.º 8.666/1993 c/c artigo 9.º da Lei n.º 10.520/2002).

25.6. Após o início ou encerramento da fase de lances, não caberá desistência por parte das licitantes, salvo por motivo justo decorrente de fato superveniente e aceito pelo Pregoeiro.

25.7. Após o envio da documentação não serão permitidos quaisquer adendos, acréscimos ou retificações aos documentos e às propostas, salvo quando se tratar:

25.7.1. de simples omissão não conflitante com os termos do Edital e com a lisura da competição;

25.7.2. juntada de documentos decorrente de diligências promovidas pela CVM, conforme disposto no subitem abaixo.

25.8. É facultado ao pregoeiro, em qualquer fase da licitação, promover diligências destinadas a esclarecer ou completar a instrução do processo licitatório, sem que se descaracterize o objeto licitatório (artigo 43,§ 3.º, da Lei n.º 8.666/1993 c/c artigo 9.º da Lei n.º 10.520/2002).

25.9. Na apresentação das propostas, simples omissão ou impropriedades irrelevantes, sanáveis ou desprezíveis, poderão ser relevadas a exclusivo critério do Pregoeiro, desde que não causem prejuízos à Administração.

25.10. A apresentação da proposta implica, tacitamente, inteira submissão às condições estabelecidas na legislação pertinente, aos termos deste Edital, bem como aos regulamentos administrativos e normas gerais e especiais aplicáveis.

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

25.12. Na contagem dos prazos estabelecidos nesta licitação, excluir-se-á o dia do início e incluir-se-á o do vencimento (artigo 110 da Lei n.º 8.666/1993 c/c artigo 9.º da Lei n.º 10.520/2002).

25.13. Havendo indícios de conluio entre as licitantes, a CVM comunicará os fatos apurados à Secretaria Nacional de Direito Econômico do Ministério da Justiça (ou a quem de direito) para a adoção das medidas cabíveis.

25.14. Havendo indícios ou evidências materiais de práticas licitatórias criminosas, a CVM noticiará o Ministério Público Federal.

25.15. Para dirimir as questões decorrentes do ajuste resultante desta licitação, será eleito o Foro Federal da cidade do Rio de Janeiro, com exclusão de qualquer outro, por mais privilegiado que seja (artigo 55, § 2.º da Lei n.º 8.666/1993 c/c artigo 9.º da Lei n.º 10.520/2002).

25.16. Os casos omissos serão resolvidos pelo Pregoeiro, nos termos da legislação pertinente, e em conformidade com as demais normas que regem a matéria.

25.17. 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.

Rio de Janeiro, de de 2014.

XXXXXXX XXX-XXXXX XXXXX

Gerente de Licitações e Contratos

ANEXO I – TERMO DE REFERÊNCIA PROCESSO DE COMPRAS Nº RJ-2014-2866 PREGÃO ELETRÔNICO Nº 9/2014

1. DEFINIÇÃO DO OBJETO

Contratação de serviços em Tecnologia da Informação, complementares às atividades da CVM, para:

1.1. sustentação do ambiente de sistemas de informação, envolvendo manutenção corretiva e evolutiva em seus sistemas corporativos e públicos, bem como alterações e inserções nas páginas de conteúdo estático e/ou dinâmico que integram os sistemas públicos. Compreende os serviços de gerência de projetos, levantamento de requisitos, análise, codificação, testes e documentação de sistemas, de acordo com as condições constantes deste Termo de Referência, das Especificações Técnicas (Anexo II) e Roteiro de Métricas.

1.2. desenvolvimento de novos sistemas de informação, compreendendo os serviços de gerência de projetos, levantamento de requisitos, análise, codificação, testes e documentação de sistemas e serviços, de acordo com as condições constantes deste Termo de Referência, das Especificações Técnicas (Anexo II) e do Roteiro de Métricas (Anexo III).

1.3. transferência de tecnologia e conhecimento aos servidores e colaboradores da CONTRATANTE, bem como a transferência de produtos de software ao Centro de Dados da CVM, com a elaboração do plano de implantação para a correta entrada em produção.

2. FUNDAMENTOS DA CONTRATAÇÃO

2.1. RELAÇÃO DEMANDA X NECESSIDADE

O quadro abaixo é meramente estimativo, com base nos volumes históricos dos últimos três anos.

Id	Demanda Prevista	Quantidade de pontos de função a ser contratada por tecnologia
Id	Demanda Prevista	ASP, VB6, PHP	DELPHI5	.NET	OPENCMS	JAVA
1	Manutenções corretivas	200	300	300	100	100
2	Manutenções evolutivas	800	2700	2700	100	400
3	Desenvolvimento de novos sistemas e reengenharia do legado.	-	-	-	800	9500

2.2. MOTIVAÇÃO

Para realizar suas atividades de fiscalização, existem hoje cerca de 30 sistemas informatizados na CVM, voltados ao público externo e às atividades de controle interno.

Os sistemas da CONTRATANTE estão defasados tecnologicamente e não possuem documentação.

O objetivo desta contratação é garantir as manutenções corretivas e evolutivas dos sistemas legados e a sua atualização tecnológica, bem como o desenvolvimento de novos sistemas.

2.3. RESULTADOS A SEREM ALCANÇADOS

Id	Tipo	Resultado
1	Governança em Desenvolvimento	Sistemas documentados e construídos com base nas melhores práticas
2	Aderência às diretrizes do Governo Federal	Utilização de Software Livre
3	Atendimento às demandas da CONTRATANTE	Garantia da evolução dos sistemas existentes e novas soluções

2.4. JUSTIFICATIVA DA SOLUÇÃO ESCOLHIDA

A maioria dos sistemas da CVM é específica para o atendimento das atividades regulatórias da autarquia, não existindo softwares prontos com as mesmas características, fazendo-se necessária a manutenção dos sistemas legados e o desenvolvimento de novos sistemas.

A contratação de empresa especializada, no modelo de fábrica de software, utilizando pontos de função, atende às recomendações do TCU e às normas da IN 04/2010.

3. DESCRIÇÃO DA SOLUÇÃO DE TI

Empresa especializada no desenvolvimento de sistemas nas plataformas Java, .Net, PHP, Delphi

, portais em OpenCMS, VB 6.0 e ASP Clássico, utilizando banco de dados SQL Server, versões 2000, 2005 e 2008.

4. ESPECIFICAÇÕES TÉCNICAS

Os serviços indicados no item 1 deste Termo de Referência serão detalhados nos Anexos II – Especificações Técnicas e, no que couber, no Anexo III – Roteiro de Métricas.

5. MODELO DE PRESTAÇÃO DE SERVIÇOS / FORNECIMENTO DE BENS

5.1. JUSTIFICATIVA PARA O NÃO PARCELAMENTO DO OBJETO

Para fins de obtenção das propostas durante a fase de lances, optou-se pelo agrupamento das linguagens ASP, PHP e VB6 em um único item, cuja motivação se encontra exposta a seguir:

1. O quantitativo de serviços demandado para estas linguagens representa uma parcela mínima do objeto;

2. O histórico de manutenções para as linguagens ASP e VB6 indica uma variação muito grande de pontos de função utilizados na manutenção de sistemas nestas tecnologias, não sendo possível uma estimativa individualizada do total demandado;

3. A linguagem PHP somente é utilizada no projeto SEI (novo sistema de processos), não havendo dados históricos que garantam uma estimativa de pontos de função que serão utilizados;

4. Os preços do ponto de função para as três linguagens são muito próximos, conforme observado por meio de pesquisa de mercado, na qual as três empresas consultadas ofereceram preços idênticos para as três linguagens.

O não parcelamento das demais linguagens em itens distintos, excluindo a possibilidade de contratação de empresas diferentes para prestação dos serviços de manutenção e desenvolvimento de sistemas, justifica-se pelos seguintes fatos:

1. alguns sistemas legados, especialmente o Sistema de Cadastros e o CVMWeb (incluindo o site institucional), foram escritos utilizando-se conjuntamente as linguagens ASP clássico, VB6 e .net, PHP e Delphi, tornando tecnicamente inviável a prestação dos serviços que envolvam tais linguagens por empresas distintas;

2. os sistemas legados estão defasados tecnologicamente, sem documentação e com modelagem de dados inadequada, e deverão ser migrados para Java. Como existe também uma grande integração entre sistemas da CVM, não será possível a migração de todos os sistemas de uma só vez. Assim, a estratégia para a migração será o desenvolvimento de módulos, substituindo gradualmente as funcionalidades existentes. Em razão destas características, ficaria inviável tecnicamente a separação dos ambientes de desenvolvimento em plataformas distintas. Além disso, as manutenções evolutivas nos sistemas legados agregarão conhecimento para a sua migração para a plataforma Java.

Diante das justificativas técnicas expostas acima, conclui-se que é fundamental que a empresa responsável pelas manutenções do legado seja a mesma responsável pelo desenvolvimento na linguagem Java e na ferramenta de gestão de conteúdo OpenCMS, que é desenvolvida em Java.

Em atendimento à Súmula TCU n.º 247, cabe ainda citar que o não parcelamento do objeto não implicará em restrição à competitividade, haja vista que a diferença entre as linguagens não descaracteriza o cerne do objeto da licitação, qual seja a contratação de empresa especializada para desenvolvimento e manutenção de sistemas de informação. Pode-se afirmar que as empresas que atuam no ramo de prestação de serviços sob a forma de fábrica de software, mesmo as de menor porte, têm condições de oferecer tais serviços, independentemente da linguagem demandada.

Desta forma, entende-se que o não parcelamento do objeto, em conjunto com os critérios para comprovação de capacidade técnica previstos neste Termo de Referência, propiciará a concretização da contratação que melhor atenderá ao interesse público, com o melhor aproveitamento das potencialidades do mercado, sem restrição da competitividade e com a possibilidade de ganho em economia de escala proveniente do aumento da disputa em virtude do elevado montante financeiro estimado para o período de contratação.

5.2. METODOLOGIA DE TRABALHO

A metodologia de trabalho para a realização das manutenções corretivas, evolutivas e novos desenvolvimentos está definida no Anexo II – Especificações Técnicas.

6. ELEMENTOS PARA A GESTÃO DO CONTRATO

6.1. PAPÉIS E RESPONSABILIDADES

Papel

Entidade

Responsabilidade

Acompanhamento desenvolvimento

Gerência de Sistemas (GSI)

Contagem dos Pontos de

Função

Aferição

Serviços

Nível

Qualidade da Solução

Aprovação da

especificação e homologação do produto

Áreas de negócio, demandantes d solução (SIN, SMI, SRE, SOI, SEP, SAD, SPS, SPL, SRI)

Aprovação da

especificação e casos de uso

Homologação da solução

Levantamento requisitos

Analistas da GSI e/ou Analistas de Requisitos da CONTRATADA.

Entendimento das regras de negócio e requisitos do

usuário

Confecção da

documentação necessária à aprovação dos requisitos

Codificação da Solução

CONTRATADA

Desenvolvimento da solução requerida segundo

requisitos do usuário

Implantação da solução

CONTRATADA

Elaborar o plano de implantação

GSI

Coordenação da passagem

para a produção com o Centro de dados

6.2. DEVERES E RESPONSABILIDADES DA CONTRATADA

Caberá à empresa CONTRATADA o cumprimento das seguintes obrigações, além daquelas previstas nas especificações técnicas:

a) reparar, corrigir, remover, reconstruir ou substituir, às suas expensas (sem quaisquer ônus para a CVM), no total ou em parte, o objeto do contrato em que se verificarem vícios, defeitos ou incorreções resultantes da execução ou de materiais empregados (art.69 da Lei nº 8.666/93);

b) guardar sigilo sobre dados e informações obtidos em razão da execução dos serviços contratados ou da relação contratual mantida com a CONTRATANTE;

c) solicitar os esclarecimentos necessários para o regular cumprimento dos termos contratuais à Gerência de Licitações e Contratos da CVM (GAL);

d) manter, em compatibilidade com as obrigações por ela assumidas, todas as condições de habilitação e qualificação exigidas na licitação. Assim, sempre que expirar a validade, e durante a vigência do Contrato, a CONTRATADA ficará obrigada a renovar todos os documentos relativos à regularidade no SICAF - Sistema de Cadastramento Unificado de Fornecedores (art. 55, inciso XIII da Lei nº 8.666/93).

e) realizar os serviços para os quais foi CONTRATADA dentro dos parâmetros e rotinas estabelecidos, em observância às recomendações aceitas pela boa técnica, normas e legislação;

f) providenciar, por conta própria, o transporte e treinamento de seu pessoal;

g) implantar, de forma adequada, a supervisão permanente dos serviços, de forma a obter uma operação correta e eficaz;

h) instruir o seu preposto quanto à necessidade de acatar as orientações da Administração, inclusive quanto ao cumprimento das Normas Internas e de Segurança e Medicina do Trabalho;

i) responder pelos danos causados diretamente à CONTRATANTE ou a terceiros, decorrentes de sua culpa ou dolo na execução dos serviços, não excluindo ou reduzindo essa responsabilidade a Fiscalização ou acompanhamento pela CVM;

j) arcar com as despesas decorrentes de qualquer infração, seja qual for, desde que praticada por seus funcionários durante a execução dos serviços, ainda que no recinto da CVM;

k) assumir, também, a responsabilidade por todas as providências e obrigações estabelecidas na legislação específica de acidentes do trabalho, quando, em ocorrência da espécie, forem vítimas os seus empregados na execução dos serviços ou em conexão com eles, ainda que ocorridos nas dependências da CVM;

l) indicar representante pertencente aos quadros da CONTRATADA para manter contato com a CVM para o esclarecimento de dúvidas, fornecendo nome e telefone de contato;

m) participar, dentro do período compreendido entre a assinatura do contrato e o início da prestação dos serviços, de reuniões de alinhamento de expectativas contratuais com equipe de técnicos e gestores da CONTRATANTE.

n) recrutar, selecionar e contratar os profissionais necessários à realização dos serviços;

o) formalizar a indicação de preposto da empresa e substituto eventual para a coordenação dos serviços e gestão administrativa do contrato;

p) comunicar previamente à CONTRATANTE os nomes, números de identidade e CPF dos empregados que serão alocados na execução dos serviços, indicando as respectivas tarefas a serem desenvolvidas;

q) manter os seus profissionais devidamente identificados por meio de crachá quando em trabalho nas dependências da CONTRATANTE;

r) alocar pessoal tecnicamente qualificado e capacitado na execução dos serviços demandados pela CONTRATANTE, garantindo o cumprimento dos prazos fixados e a qualidade dos serviços fornecidos;

s) prover treinamento e atualização profissional do pessoal alocado no fornecimento dos serviços contratados, considerando as necessidades identificadas, inclusive pela CONTRATANTE;

t) zelar para que todos os privilégios de acesso a sistema, informação e qualquer outro recurso da CONTRATANTE sejam utilizados exclusivamente na execução dos serviços e pelo tempo estritamente essencial à realização dos mesmos;

u) administrar todo e qualquer assunto relativo aos profissionais alocados à execução dos serviços;

v) assumir todas as responsabilidades e tomar as medidas necessárias ao atendimento dos profissionais acidentados ou acometidos de mal súbito;

w) assumir a responsabilidade por todos os encargos previdenciários e obrigações sociais previstos na legislação social e trabalhista em vigor, cumprindo as obrigações decorrentes nas épocas próprias, vez que os seus profissionais não manterão nenhum vínculo empregatício com a CONTRATANTE;

x) assumir a responsabilidade por todas as providências e obrigações estabelecidas responder por todos os danos patrimoniais e de quaisquer natureza causados por ação ou omissão de seus profissionais, relacionada à execução dos serviços;

y) transferir, sob supervisão da CVM, os produtos de software homologados e aprovados pela CVM e sua documentação ao Centro de Dados da CVM visando sua entrada em produção, atuando sob a orientação da empresa gestora do Centro de dados, inclusive no que disser respeito a eventual migração de dados;

z) fornecer à CONTRATANTE, em meio magnético, sempre que solicitado, todas as informações relacionadas à prestação dos serviços;

aa) fornecer à CONTRATANTE, por quaisquer meios, sempre que solicitado, todas as informações relacionadas à tecnologia e à expertise aplicadas nos serviços prestados;

bb) manter ou evoluir todas as condições de habilitação, qualificação e certificação exigidas na licitação;

cc) planejar, desenvolver, implantar, executar e manter os serviços objeto do contrato de acordo com a metodologia praticada pela CONTRATANTE e com os níveis de serviço estabelecidos nas especificações funcionais e técnicas que compõem este Termo de Referência e o Contrato correspondente;

dd) encaminhar à unidade Fiscalizadora todas as faturas dos serviços prestados, bem como os documentos comprobatórios da prestação dos mesmos;

ee) assumir a responsabilidade pelos encargos fiscais e comerciais resultantes da contratação; ff) reportar à CONTRATANTE imediatamente qualquer anormalidade, erro ou irregularidade

que possa comprometer a execução dos serviços e o bom andamento das atividades da CONTRATANTE;

gg) obedecer rigorosamente todas as normas e procedimentos de segurança, bem como de uso de recursos de informática, implementados no ambiente de TI da CONTRATANTE;

hh) disponibilizar documentos, modelos, programas fonte, diagramas e artefatos correlatos em formatos reconhecidos pelos aplicativos disponíveis no ambiente da CONTRATANTE;

ii) atender às solicitações de serviços da CVM, de acordo com as especificações técnicas, procedimentos de controles administrativos, cronogramas físicos e prazos que venham a ser estabelecidos nas “OS – Ordens de Serviço” ou em outros instrumentos adequados.

jj) manter os sistemas de controle atualizados permanentemente.

kk) adotar as providências necessárias que viabilizem a realização dos serviços objeto deste Contrato.

ll) executar os serviços descritos neste Termo de Referência e nas Especificações Técnicas que o complementam seguindo os procedimentos estabelecidos entre as partes, respeitando a priorização definida pela metodologia e a sequencia lógica das funções, atendendo com presteza e qualidade às demandas apresentadas.

mm) atender aos pedidos de informações formalizados pela CONTRATANTE, por pessoas ou entidades por ela credenciadas, relacionados com a execução dos serviços contratados.

nn) manter atualizada a documentação dos serviços constantes deste Termo de Referência e das Especificações Técnicas que o complementam, disponibilizando-a à CONTRATANTE, seguindo os padrões estabelecidos entre as partes, em virtude da especificidade de cada serviço.

oo) elaborar documentação dos sistemas legados conforme previsto no anexo III.

pp) cumprir todas as orientações da CONTRATANTE, para o fiel desempenho das atividades específicas.

qq) prestar todos os esclarecimentos solicitados pela CONTRATANTE, de forma clara, concisa e lógica, cujas reclamações se obriga prontamente a atender.

rr) cumprir o disposto no Inciso XXXIII, do artigo 7º da Constituição Federal/1988.

ss) acatar a arbitragem e as determinações da CONTRATANTE em conflitos de qualquer natureza que venham a surgir entre a CONTRATADA e outros prestadores de serviços que atuem no ambiente da CONTRATANTE, com vistas à preservação da continuidade dos serviços e do interesse público.

6.3. DEVERES E RESPONSABILIDADES DA CONTRATANTE

Caberá à CVM, como CONTRATANTE:

a) proporcionar todas as condições para que a CONTRATADA possa cumprir suas obrigações dentro das normas deste Termo de Referência e do Contrato.

b) efetuar o pagamento devido pela execução dos serviços, desde que cumpridas todas as formalidades e exigências do contrato;

c) permitir acesso dos profissionais da CONTRATADA às suas dependências, equipamentos,

softwares e sistemas de informação para a execução dos serviços;

d) prestar as informações e os esclarecimentos pertinentes que venham a ser solicitados pelos profissionais da CONTRATADA ou por seu preposto;

e) exercer a fiscalização, homologação (aceitação) e/ou rejeição dos serviços prestados, por meio de servidores designados;

f) comunicar oficialmente à CONTRATADA quaisquer falhas verificadas no cumprimento do contrato;

g) avaliar os serviços executados pela CONTRATADA, observando os indicadores e metas de nível de serviço alcançados;

h) avaliar o cumprimento de todas as exigências contidas neste Termo de Referência e no Anexo II - Especificações técnicas, informando e exigindo da CONTRATADA a pronta correção das desconformidades eventualmente encontradas;

i) arbitrar conflitos de qualquer natureza que venham a surgir entre a CONTRATADA e outros prestadores de serviços que atuem em seu ambiente, inclusive com ajuda externa se assim julgar necessário, com vistas à preservação da continuidade dos serviços e do interesse público.

6.4. FORMAS DE ACOMPANHAMENTO DO CONTRATO

Id	Evento	Forma de acompanhamento
1	Cumprimento dos prazos e do SLA	Verificação mensal, através dos relatórios do Sistema de Gestão de Demandas
2	Arquitetura	Avaliação da documentação entregue
3	Códigos Fonte	Utilização de ferramenta de controle de versões

6.5. METODOLOGIA DE AVALIAÇÃO DA QUALIDADE

Id	Etapa/fase/item	Método de avaliação
1	Aprovação da Arquitetura	Analise da documentação apresentada
2	Padrões de tabelas e nome de campos	Ferramenta automatizada
3	Teste de carga	Ferramenta automatizada
4	Teste de estresse	Ferramenta automatizada

6.6. NÍVEIS MÍNIMOS DE SERVIÇOS (apurados mensalmente)

Id	Etapa/fase/item	Indicador	Valor mínimo aceito
1	Prazos de entrega	Percentual de atraso em função do total de pontos de função	85% sem atraso do total entregue
1	Prazos de entrega	Percentual de atraso em função do total de pontos de função	O atraso de cada demanda individualmente não poderá ultrapassar 25% do prazo estimado
2	Erros em produção	Erros em produção	Zero
3	Demanda sem erros em homologação	Percentual de demandas entregues sem erros no ambiente de homologação	85% do total de demandas entregues para testes

6.7. ESTIMATIVA DO VOLUME DE BENS E SERVIÇOS

Para atender à demanda por sistemas da CONTRATANTE, poderão ser demandados até 18.000 pontos de função durante a execução do contrato, conforme valores estimativos abaixo:

Bens e Serviços
Id	Bem/Serviço	Valor Estimado
1	Manutenções Corretivas	R$ 775.478,48
2	Manutenções Evolutivas	R$ 5.182.063,56
3	Novos Sistemas	R$ 8.324.322,38

Os valores foram estimados com base no volume histórico e com a metodologia da NESMA, conforme distribuição da tabela do item 2.1.

Obs: As quantidades acima são meramente estimativas, não estando a CONTRATANTE obrigada a demandar valores mínimos.

6.8. PRAZOS E CONDIÇÕES.

6.8.1. Os prazos para entrega das demandas de manutenções corretivas e evolutivas e novos desenvolvimentos serão calculados em função do tamanho da demanda em pontos de função.

Manutenções corretivas
Pontos de função envolvidos		Prazo máximo (dias)
Até 5		2
De 6 a 15		4
De 15 a 30		6
De 16 a 50		8
Acima de 50 pontos, os prazos serão definidos com base na tabela de Manutenções Evolutivas e Novos Projetos.
Manutenções Evolutivas ou Novos Projetos.
Pontos de função	Prazo máximo (dias)	Recursos estimados
Até 3	3	1
De 4 a 6	6	2
De 6 a 10	10	2
De 11 a 15	15	2
De 16 a 30	25	3
De 31 a 45	35	3
De 46 a 60	45	3
De 61 a 75	55 dias	3
De 76 a 100	60 dias	4
Acima de 100	Prazo Máximo (dias) = (Tamanho em PF / 2) + 10

6.8.1.1. Os projetos serão divididos em módulos entregáveis, a critério da CONTRATANTE;

6.8.1.2. A CONTRATADA fica obrigada a designar profissional especializado para realizar o levantamento de requisitos imediatamente após o recebimento da demanda, que se dará pela abertura da OS no Sistema de Gestão de Demandas;

6.8.1.3. Os prazos acima preveem toda a construção da demanda, desde a fase de requisitos até a efetiva entrada em produção;

6.8.1.4. O prazo para a contratada elucidar os requisitos e apresentar a documentação pertinente para a aprovação dos requisitos pela área demandante está incluído nos prazos acima.

6.8.1.5. A contagem será em dias úteis, ficando suspensa no dia em que houver entrega de artefatos para avaliação da CVM ou indisponibilidade do usuário para as reuniões de requisitos, recomeçando no dia imediatamente após a aprovação dos artefatos ou realização das reuniões;

6.8.1.6. A tabela acima será a única utilizada para o controle de prazos e não se confunde com a tabela 9, do item 6.1.3, Estimativa de Prazo de Projetos de Software, do anexo III – Roteiro de métricas, que é meramente estimativa da produtividade do ponto de função em horas.

6.9. ACEITE, ALTERAÇÃO E CANCELAMENTO.

6.9.1. Condições de aceite

6.9.1.1. Entrega da documentação de requisitos.

6.9.1.2. Aprovação da arquitetura

6.9.1.3. Teste das funcionalidades

6.9.2. Condições de alteração

6.9.2.1. Aumento ou supressão (25%)

6.9.2.2. Reajuste de preços

6.9.3. Condições de cancelamento

6.9.3.1. Descumprimento do Nível Mínimo de Serviço

6.9.3.2. Descumprimento de cláusulas contratuais

6.10. CONDIÇÕES PARA PAGAMENTO

6.10.1. O pagamento será feito mediante emissão de ordem bancária creditada em favor da CONTRATADA, no prazo de até trinta dias após a apresentação da nota FISCAL discriminativa dos serviços concluídos, dos correspondentes pontos de função produzidos pela CONTRATADA e validados pela CONTRATANTE, e dos valores dos serviços discriminados, juntamente com as alíquotas e valores de todos os impostos incidentes, conforme previsto pela Instrução Normativa RFB n.º 1234, de 11 de janeiro de 2012. Cada pagamento ficará condicionado à formal confirmação da efetiva e satisfatória realização dos serviços pela CONTRATANTE (entrada efetiva em produção). O prazo fixado para

pagamento não fluirá na pendência de correções da fatura ou esclarecimentos da CONTRATADA sobre serviços faturados;

6.10.2. O fluxo para aceite e pagamento seguirá as etapas e prazos estipulados no cronograma abaixo:

Fase

Atividade

Responsável

Prazo (dias úteis)

Relatório de Ordens de Serviços encerradas no período

CONTRATADA

D (até o quinto dia útil do

mês subsequente à efetiva prestação dos serviços).

Emissão de Termo de Recebimento Provisório

Fiscais Técnicos

D + 3

Reunião para apuração dos Níveis Mínimos de Serviço

CONTRATADA,

Fiscais Técnicos e Gestor do Contrato.

D + 5

Termo de Recebimento Definitivo

Fiscal Requisitante e Gestor do Contrato

D + 8

Autorização para emissão da nota fiscal

Gestor do Contrato

D + 9

Emissão da Nota Fiscal

CONTRATADA

A critério da CONTRATADA, após

concluída a fase 5.

Pagamento

SAD

Conforme contrato

1 – O Relatório conterá as seguintes informações:

• Número e descrição da Ordem de Serviço (gerado pelo Sistema de Gestão de Demandas);

• Total de pontos de função;

• Prazo previsto para a entrega (em função dos pontos de função);

• Prazo total de desenvolvimento (considerando apenas as atividades realizadas pela CONTRATADA, conforme item 6.1.2.1 do Roteiro de Métricas);

2 – O Termo de Recebimento Provisório indicará as demandas (ordens de serviço) homologadas pelas áreas usuárias e desenvolvidas de acordo com os padrões de arquitetura e qualidade estipulados pela CONTRATANTE;

3 – A reunião para aferição dos Níveis Mínimos de Serviço será realizada para verificação do atendimento dos prazos previstos no item 6.8.1 e, se for o caso, será apurado o desconto previsto no item 6.10.4;

4 – Após a reunião prevista no item anterior, o Gestor do Contrato e o Fiscal Requisitante emitirão Termo de Recebimento Definitivo, indicando as demandas efetivamente entregues no ambiente de produção;

5 – O Gestor do Contrato emitirá a autorização para emissão da Nota Fiscal, indicando o total de pontos de função a ser faturado e o total do desconto, se for o caso;

6 – A contratada deverá protocolar a Nota Fiscal no setor responsável da CONTRATANTE, endereçada ao Gestor do Contrato;

7 – Após receber a Nota Fiscal, o Gestor do Contrato a enviará para a área administrativa, com o devido ateste e documentos comprobatórios da prestação dos serviços.

Obs.: Os prazos previstos acima ficarão suspensos enquanto a CONTRATADA não tomar as providências necessárias para o cumprimento das obrigações previstas em cada etapa.

6.10.3. A CONTRATANTE somente pagará à CONTRATADA pelos serviços efetivamente realizados de acordo com os procedimentos de medição estabelecidos neste documento, não sendo devido o pagamento de quaisquer valores a título de franquia ou garantia de execução de valores mínimos;

6.10.4. Mensalmente será apurado o total de pontos de função produzidos, sendo aplicado um desconto à fatura, calculado em função das demandas em atraso, conforme fórmula:

Fator de Desconto = ∑(dai . pf i) , onde:

∑(dei . pf i)

da = atraso da demanda (dias úteis decorridos após o prazo previsto no item 6.8.1) de = prazo de entrega (em dias úteis - item 6.8.1)

pf - Total de pontos de função da demanda

Para o cálculo acima serão consideradas todas as demandas solicitadas no mês anterior à apuração do Nível Mínimo de Serviço cujo prazo de entrega esteja vencido e as demandas entregues no mês da apuração, independente da data da solicitação.

6.10.5. Algumas fases poderão, a critério da CONTRATANTE, ser efetuadas por seus analistas, cabendo à CONTRATADA a conclusão das demais. Em qualquer hipótese, a CONTRATADA receberá apenas pelas fases por ela desenvolvidas, conforme percentuais definidos na tabela 7 do item 6.1.2.1 do Anexo III – Roteiro de Métricas. Nestes casos, para efeitos de cálculo do Nível Mínimo de Serviços, serão considerados os prazos proporcionais às fases de responsabilidade da CONTRATADA. Após 45 dias corridos, não ocorrendo a homologação por parte do usuário requisitante por responsabilidade exclusiva da CONTRATANTE, a OS poderá ser considerada como concluída para efeitos de pagamento, sem prejuízo da garantia prevista no item 6.11.

6.10.6. Havendo divergência entre a CONTRATADA e a CONTRATANTE em relação à contagem de pontos de função ou o valor do desconto apurado, só poderão ser

faturados os valores calculados pela CONTRATANTE, sendo a diferença em favor da CONTRATADA, se for o caso, paga em faturas posteriores.

6.10.7. O pagamento das Ordens de Serviço em desenvolvimento pela contratada ao final do contrato poderá ser realizado proporcionalmente ao esforço das fases efetivamente concluídas e atestadas pela GSI, conforme tabela 7 do item 6.1.2.1 do Anexo III – Roteiro de Métricas.

6.11. GARANTIA

A garantia dos produtos desenvolvidos será devida durante toda a validade do contrato e 90 dias após o término do mesmo, estando a CONTRATADA obrigada a corrigir qualquer problema de mal funcionamento da aplicação ou funcionamento em desacordo com a especificação aprovada.

6.12. PROPRIEDADE. SIGILO E RESTRIÇÕES

Id	Direito de Propriedade
1	Todos os programas fontes, o direito patrimonial e a propriedade intelectual dos produtos produzidos são de propriedade da CONTRATANTE.
2	Os programas fontes serão entregues à CONTRATANTE no controlador de versões indicado por ela.
3	A CONTRATADA se compromete a guardar sigilo sobre dados e informações obtidos em função da execução do contrato.
4	Os programas desenvolvidos são de uso exclusivo da CONTRATANTE, não podendo a CONTRATADA, sem autorização expressa da CONTRATANTE, reutilizá-los, distribuí- los ou divulgá-los.

Id	Condições de Manutenção do Sigilo
1	Termo de comprometimento.
2	Orientação aos funcionários e prepostos.

Id	Restrição Adicional
1	Não divulgação dos dados e informações

6.13. MECANISMOS FORMAIS DE COMUNICAÇÃO

Função de comunicação 1			Abertura da demanda
Documento	Emissor	Destinatário	Meio	Periodicidade
Ordem de serviço	GSI	CONTRATADA	Sistema de Gestão de Demandas	Mensal
Função de comunicação 2			Levantamento de requisitos
Documento	Emissor	Destinatário	Meio	Periodicidade
Especificação	CONTRATADA	Área Demandante	Sistema de	Mensal

Funcional e Casos de Uso			Gestão de Demandas
Análise de Pontos de Função	CONTRATADA	GSI	Sistema de Gestão de Demandas	Mensal
Função de comunicação 3			Arquitetura da Solução
Documento	Emissor	Destinatário	Meio	Periodicidade
Arquitetura	CONTRATADA	GSI	Sistema de Gestão de Demandas	Mensal

7. ESTIMATIVA DE PREÇO

Id	Bens e Serviços	Valor Estimado (R$)
1	Novos sistemas	R$ 8.652.267,90
2	Evolução do Sistema Legado	R$ 5.012.364,64
3	Correção de Erros em produção	R$ 617.231,88

8. ADEQUAÇÃO ORÇAMENTÁRIA

Fonte de Recurso: Ação 20WU – Sistemas de desenvolvimento do mercado de valores mobiliários.

Valor: R$ 14.281.864,42

9. SANÇÕES APLICÁVEIS

9.1. Comete infração administrativa nos termos da Lei nº 8.666, de 1993 e da Lei nº 10.520, de 2002, a CONTRATADA que:

9.1.1. inexecutar total ou parcialmente qualquer das obrigações assumidas em decorrência da contratação;

9.1.2. ensejar o retardamento da execução do objeto;

9.1.3. fraudar na execução do Contrato;

9.1.4. comportar-se de modo inidôneo;

9.1.5. cometer fraude fiscal;

9.1.6. não mantiver a proposta.

9.2. A CONTRATADA, ao cometer qualquer das infrações discriminadas no subitem acima, ficará sujeita, sem prejuízo da responsabilidade civil e criminal, às seguintes sanções:

9.2.1. advertência por faltas leves, assim entendidas aquelas que não acarretem prejuízos significativos para a CVM;

9.2.2. multa compensatória de até 20% (trinta por cento) sobre o valor total do CONTRATO, em caso de inexecução total ou parcial das obrigações assumidas.

9.2.3. mensalmente, serão aferidos os níveis mínimos de serviço, com base nas demandas solicitadas à CONTRATADA, visando a garantia do prazo e qualidade nas entregas, estando a CONTRATADA sujeita às seguintes multas:

9.2.3.1. independente do desconto previsto no item 6.10.4 deste Termo de Referência, será aplicada multa para cada demanda com atraso superior a 25% (vinte e cinco por cento) do prazo estimado. A multa será no valor de 1% (um por cento) ao dia sobre o valor da demanda, limitada a 30 (trinta) dias. Após o 31º (trigésimo primeiro) dia, o contrato poderá ser rescindido.

9.2.3.2. caso o percentual de desconto calculado conforme item 6.10.4 deste Termo de Referência seja superior a 15% (quinze por cento) por três meses, consecutivos ou não, será aplicada a multa de 0,5% (zero vírgula cinco por cento) sobre o valor total do contrato. Se o atraso ocorrer por seis meses, consecutivos ou não, a multa será de 1% (um por cento) sobre o valor do contrato e o contrato poderá ser rescindido.

9.2.4. multa por erros introduzidos em produção de acordo com o seguinte quadro, sem exclusão da responsabilidade de correção do erro pela CONTRATADA, sem custas para a CVM:

Tipo de Xxxx	Xxxxx
Introdução de erros em consultas	10% (dez por cento) sobre o valor da demanda, por ocorrência, após reincidência formalmente advertida pela CVM
Introdução de erros que impeçam a atualização de dados no sistema	15% (quinze por cento) sobre o valor da demanda, por ocorrência, após reincidência formalmente advertida pela CVM
Introdução de erros que configurem inconsistência de dados	20% (vinte por cento) sobre o valor da demanda, por ocorrência, após reincidência formalmente advertida pela CVM

9.2.5. multa de 0,05% (zero vírgula zero cinco por cento) sobre o valor do CONTRATO, caso o percentual de demandas entregues com erro no ambiente de homologação, no período de um mês, seja superior a 15% (quinze por cento):

Cálculo:	∑ Total de PF das demandas com erro
	∑ Total de PF das demandas entregues

9.2.6. a tentativa de fraude, manipulação ou descaracterização em Indicador/Meta de nível de serviço ensejará a aplicação de multa de 5% (cinco por cento) sobre o valor total contratual, sem prejuízo de outras sanções aplicáveis e rescisão contratual.

9.2.7. suspensão de licitar e impedimento de contratar com a CVM, pelo prazo de até 2 (dois) anos;

9.2.8. impedimento de licitar e contratar com a União com o consequente descredenciamento no SICAF pelo prazo de até 5 (cinco) anos;

9.2.9. 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 CVM pelos prejuízos causados;

9.3. A multa deverá ser recolhida no prazo máximo de 10 (dez) dias úteis, a contar da data do recebimento da comunicação enviada pela CVM.

9.4. Também fica sujeita às penalidades do art. 87, III e IV da Lei nº 8.666, de 1993, a CONTRATADA que:

9.4.1. tenha sofrido condenação definitiva por praticar, por meios dolosos, fraude fiscal no recolhimento de quaisquer tributos;

9.4.2. tenha praticado atos ilícitos visando a frustrar os objetivos da licitação;

9.4.3. demonstre não possuir idoneidade para contratar com a Administração em virtude de atos ilícitos praticados.

9.5. durante o prazo de 90 dias após o início do CONTRATO, o Nível Mínimo de Serviços não será aplicado às manutenções evolutivas, mas será apurado normalmente para o desenvolvimento de novos sistemas e manutenções corretivas. Durante este período, a CONTRATADA deverá utilizar todos os recursos necessários para entendimento dos sistemas legados, como engenharia reversa e entrevistas com os analistas da CVM, para o correto cumprimento dos Níveis Mínimos de Serviço.

9.6. A aplicação de qualquer das sanções 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 na Lei n.º 9.784, de 1999.

9.7. A aplicação das sanções previstas neste instrumento, que ocorrerá após regular processo administrativo, não impede que a CVM rescinda unilateralmente o CONTRATO e aplique outras sanções regulamentares (artigo 86, §1.º da Lei nº 8.666/1993).

9.8. Será facultada à 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, suspensão e impedimento e de 10 (dez) dias para a penalidade declaração de inidoneidade.

9.9. Em caso de inadimplência quanto ao pagamento das multas que lhe forem aplicadas pela CVM, a CONTRATADA fica desde já ciente que estará sujeita à sua inclusão no Cadastro Informativo dos créditos não quitados do setor público federal (CADIN), consoante legislação específica sobre a matéria, sendo executada segundo a Lei nº 6.830/1980.

9.10. A autoridade competente, na aplicação das sanções, levará em consideração a gravidade da conduta do infrator, o caráter educativo da pena, bem como o dano causado à Administração, observado o princípio da proporcionalidade.

9.11. Não serão aplicadas simultaneamente, para a mesma ação ou omissão, sanções e glosas.

9.12. As penalidades serão obrigatoriamente registradas no SICAF.

10. CRITÉRIOS DE SELEÇÃO DO FORNECEDOR

10.1. Proposta técnica - Menor preço global – Pregão eletrônico;

10.2. Qualificação técnica

A comprovação das exigências presentes neste item se dará através de atestado (s) de capacidade técnica, fornecido (s) por pessoa (s) jurídica (s) de direito público ou privado:

10.2.1. Os atestados deverão comprovar a prestação de serviços de desenvolvimento, manutenção corretiva e evolutiva em sistemas de informação em quantidades compatíveis às estimadas para esta contratação, conforme a seguinte tabela:

Tecnologia.	Total de Pontos de Função
Java	5.000
OpenCMS ou outra tecnologia de desenvolvimento de sites com Gestão de Conteúdo	500
Delphi 5.0	1.500

10.2.2. Para a linguagem OpenCMS não serão aceitos atestados parciais, mesmo que a soma total destes atinja o total exigido. Deverá, neste caso, ser apresentado ao menos um atestado de capacidade técnica comprovando que a empresa já executou, em uma mesma empresa ou órgão, de forma satisfatória, o desenvolvimento do total de 500 pontos de função nesta tecnologia ou outra similar de desenvolvimento de Web site com gestão de conteúdo, como, por exemplo, Wordpress e Joomla.

10.2.3. Para as linguagens Java e Delphi, os atestados poderão ser parciais, contanto que atendam às seguintes exigências:

10.2.3.1. o somatório dos pontos de função desenvolvidos para cada linguagem seja igual ou superior ao total exigido, em período não superior a 30 meses;

10.2.3.2. em atestado único, deve haver comprovação de que a licitante executou, de forma satisfatória, o desenvolvimento de no mínimo

2.000 (dois mil) pontos de função para a linguagem Java; e

10.2.3.3. em atestado único, deve haver comprovação de que a licitante executou, de forma satisfatória o desenvolvimento de no mínimo 600 (seiscentos) pontos de função para a linguagem Delphi.

10.2.4. Os atestados deverão comprovar que os serviços prestados foram medidos em pontos de função, sob o regime de fábrica de software, contemplando todas as fases do ciclo de desenvolvimento, conforme modelo constante no Anexo IV deste Termo de Referência.

10.2.5. Não serão aceitos atestados de empresa coligada, consorciada ou parceira;

10.2.6. Os atestados de capacidade técnica deverão referir-se a serviços prestados no âmbito de sua atividade econômica principal ou secundária especificadas no contrato social vigente (art. 19, XXV, b da IN SLTI/MPOG n.º 2/2008);

10.2.7. O(s) atestado(s) conterão, preferencialmente, nome (razão social), CNPJ e endereço completo da Contratante e Contratada, as características dos serviços realizados, a data de emissão, nome, cargo, telefone e assinatura do responsável pela emissão do atestado.

10.2.8. A CVM poderá fazer diligência na empresa vencedora e na empresa ou órgão que forneceu o atestado de capacidade técnica para averiguar a veracidade das informações prestadas, podendo o(s) envolvido(s) responder(em) administrativa, civil e penalmente pelas informações prestadas. Na diligência poderão ser solicitados documentos, tais como contratos, ordens de serviços, notas fiscais e outros que comprovem a quantidade de pontos de função praticada e, ainda, as respectivas tecnologias declaradas no atestado fornecido

10.2.9. Os requisitos de qualificação técnica foram estipulados pela CVM para as parcelas de maior relevância e de maior valor significativo do objeto a ser contratado (Súmula 263/2011-TCU), sendo que os quantitativos mínimos estipulados correspondem a 50% da demanda para manutenções evolutivas, corretivas e novos sistemas, com base em dados históricos e medições, os quais representam o mínimo necessário à execução adequada ao porte dos serviços solicitados.

10.2.10. A comprovação da execução em uma mesma empresa ou órgão de 500 pontos de função para a linguagem OpenCMS, 600 (seiscentos) pontos de função para Delphi e 2.000 (dois mil) pontos de função para Java visa a garantir a qualificação técnica da contratada, devido à complexidade e tamanho dos sistemas legados e dos novos desenvolvimentos previstos nestas tecnologias.

10.2.11. As exigências acima não são excessivas nem restringem a competitividade da licitação, uma vez que estas são práticas comuns de mercado e existem várias empresas que atende a estes requisitos.

10.3. Critérios de seleção Modalidade: Pregão. Tipo: Eletrônico.

Justificativa: Por se tratar de bens e serviços comuns, a licitação se dará por pregão eletrônico, conforme DECRETO Nº 5.450 - DE 31 DE MAIO DE 2005, conforme Recomendação da IN04 2010.

Critério Técnico de Habilitação (obrigatório) Atestados de capacidade técnica

Justificativa: Qualidade da prestação do serviço (Art. 30, §3, lei 8.666)

Equipe de Planejamento da Contratação

Integrante Requisitante

Xxxx Xxxx xx Xxxxx - Matrícula: 7.001.313

Integrantes Técnicos

Xxxxxx Xxxxxx Xxxxxx Xxxxxxx – Matrícula: 7.001.389

Xxxxxxxxx Xxxxxxx Xxxxxxxxx Xxxxx– Matrícula: 7.001.559

Xxxxxx xx Xxxxx Xxxxxx – Matrícula: 7.001.607

Xxxxxxx Xxxxx Xxxxxx Xxxxxx – Matrícula: 7.001.599

Integrante Administrativo

Xxxxxxx Xxx-Xxxxx Xxxxx – Matrícula: 7.000.719

ORIGINAL ASSINADO

ANEXO II DO TERMO DE REFERÊNCIA ESPECIFICAÇÕES TÉCNICAS

1. CONSIDERAÇÕES GERAIS

O serviço a ser contratado pode envolver todas as fases dos processos de desenvolvimento e manutenção de sistemas, desde o levantamento de requisitos até sua disponibilização em ambiente de produção. Visa dar sustentação aos processos de negócio da Xxxxxxxxx, mantendo os aplicativos em uso atualizados e em consonância com a legislação vigente e com o mercado brasileiro de valores mobiliários.

A CONTRATADA está obrigada a auxiliar na elaboração de diagnósticos em produção, visando a correção de problemas de funcionamento do software, como performance e falhas intermitentes.

Se a falha encontrada for comprovadamente decorrente de atuação da CONTRATADA, os custos destes diagnósticos serão exclusivos da CONTRATADA.

Se forem constatados problemas de infraestrutura, a contratada será remunerada conforme a contagem de itens não mensuráveis previstas no Roteiro de Métricas (Anexo III) e roteiro SISP.

1.1. Escopo dos serviços

A presente contratação de serviços de desenvolvimento e manutenção de sistemas de informação compreenderá, entre outras, a execução das seguintes atividades:

a) Desenvolvimento de sistemas informatizados em ambiente corporativo, na Internet, Intranet e Extranet, a critério da CONTRATANTE, podendo envolver ou não páginas de conteúdo estático ou dinâmico;

b) Desenvolvimento de aplicativos e portais mobile;

c) Manutenção corretiva e evolutiva de sistemas informatizados, inclusive de sistemas legados, portais corporativos e sites Internet, Intranet e Extranet;

d) Teste, validação, documentação, apoio à homologação e orientação à implantação, bem como treinamento no uso de sistemas;

e) Acompanhamento e avaliação do desempenho de sistemas;

f) Controle de qualidade com o uso de ferramentas específicas de teste de software;

g) Levantamento de requisitos e regras de negócio e requisitos;

h) Modelagem de dados e objetos;

i) Gerenciamento de mudanças e versões de sistemas informatizados com uso de ferramentas automatizadas;

j) Gerência de componentes de sistemas de informação;

k) Planejamento da migração e implantação de sistemas informatizados e orientação e passagem de documentos e produtos de software às equipes de operação do Centro de Dados da CVM;

l) Construção e/ou supervisão da codificação de programas;

m) Integração de sistemas informatizados em plataformas heterogêneas utilizando as tecnologias de web services, XML e SOA;

n) Análise, orientação e proposição de soluções para realização de manutenções corretivas e evolutivas de sistemas;

o) Dimensionamento e medição de sistemas informatizados por meio de análise de pontos de função;

p) Migração de dados e de sistemas informatizados para novas plataformas sempre que uma manutenção assim determinar;

q) Demais atividades relacionadas à sustentação de ambiente de sistemas de informação.

Os equipamentos, instalações físicas, ramais telefônicos e mobiliários necessários à execução dos serviços serão providos pela CONTRATANTE, quando da prestação dos serviços em suas dependências, e devem ser utilizados na execução dos serviços.

2. REQUISITOS INTERNOS

2.1. FUNCIONAIS

2.1.1. Qualidade – A CONTRATADA deverá seguir os padrões de arquitetura definidos pela CONTRATANTE.

2.1.2. Requisitos funcionais – Serão definidos por demanda.

2.1.3. Evolução e manutenção – A CONTRATADA será responsável por correções de erros introduzidos pela sua atuação durante toda a vigência do contrato e por 90 dias após o fim do mesmo.

2.1.4. Xxxxx Xxxxxx de Serviço.

Id	Etapa/fase/item	Indicador	Valor mínimo aceito
1	Prazos de entrega	Percentual de atraso em função do total de pontos de função	85% sem atraso do total entregue
1	Prazos de entrega	Percentual de atraso em função do total de pontos de função	O atraso de cada demanda individualmente não poderá ultrapassar 25% do prazo estimado
2	Erros em produção	Erros em produção	Zero
3	Demanda sem erros em homologação	Percentual de demandas entregues sem erros no ambiente de homologação	85% do total de demandas entregues para testes

2.2. NÃO-FUNCIONAIS

2.2.1. Unidade de medida

A unidade de medida utilizada é “ponto de função” não ajustado, conforme definido na versão

4.3 do Manual de Práticas de Contagem fornecido pelo IFPUG (xxx.xxxxx.xxx).

A CONTRATADA deverá apresentar a contagem estimada para cada demanda, que será revista pelo analista da GSI.

Não havendo acordo entre a CONTRATANTE e a CONTRATATA sobre a contagem, poderá ser contratado profissional certificado, escolhido em comum acordo entre as partes.

Os custos referentes à contratação deste profissional serão pagos pela CONTRATATA, e caso a contagem apresentada por ela seja igual a aferida por este profissional, os custos serão repassados à CONTRATANTE, na fatura da ordem de serviço correspondente.

2.2.2. Estimativas e medições

À critério da CONTRATANTE, em função das características do projeto solicitado, as estimativas de esforço para desenvolvimento de novos sistemas poderão utilizar como referência as práticas do Manual do IFPUG mencionado acima, o método de Contagem Indicativa da NESMA (Netherlands Software Metrics Users Association), o método de Estimativa Percentual do ISBSG (International Software Benchmarking Standards Group), Método de Estimativa Percentual de Capers Jones, divulgado pela consultoria internacional SPR (Software Productivity Research), ou por um valor médio obtido envolvendo todos os métodos acima, ou um subconjunto deles.

As medições de serviços de desenvolvimento de sistemas serão realizadas conforme o anexo III

– Roteiro de Métricas, respeitando as práticas do Manual do IFPUG mencionado no subitem 2.1.1.

2.2.3. Disponibilidade do serviço

Para todas as tarefas relativas à prestação dos serviços, serão considerados pela CONTRATANTE os dias úteis, das 9 às 18 horas.

A CONTRATANTE poderá solicitar a execução dos serviços de manutenção corretiva em dias e horários distintos dos estabelecidos acima, sendo a necessidade comunicada previamente à CONTRATADA e aplicando-se neste caso o fator previsto no item 6.2.5 do Roteiro de Métricas.

2.2.4. Quantificação do serviço

Para atender à demanda para o serviço de sustentação de ambiente de sistemas de informação estimou-se a necessidade de execução de 18000 pontos de função para manutenções corretivas e evolutivas dos sistemas legados e novos desenvolvimentos, distribuídos nas tecnologias previstas neste edital:

a) sistemas corporativos, majoritariamente na tecnologia/linguagem de programação Delphi, versão 5, VB 5.0 e 6.0, com uso de SGBD relacional;

b) sistemas web, majoritariamente na tecnologia/linguagem de programação .Net (ASPX - VB/C#), ASP clássico e DLL VB 6.0, com uso de XML e SGBD relacional;

c) alterações e inserções em páginas de conteúdo estático, majoritariamente nas tecnologias/linguagens de programação HTML, JavaScript, e MacroMedia Flash.

d) portais WEB com gestão de conteúdo baseado em OpenCMS

e) desenvolvimento de novos sistemas ou migração de sistemas legados na plataforma Java.

f) Sistema de Gerenciamento Eletrônico de Documentos em PHP.

Cabe ressaltar que as quantidades aqui apresentadas são meramente estimativas, não caracterizando qualquer obrigatoriedade de demandar quantidades mínimas.

3. REQUISITOS EXTERNOS

A CONTRATADA deverá iniciar a execução dos serviços no primeiro dia útil após a assinatura do contrato.

A licitante vencedora deverá apresentar para aprovação da CONTRATANTE, às suas expensas, no prazo máximo de cinco dias após a assinatura do contrato, projeto para implantação dos serviços contendo cronograma detalhado de atividades a serem executadas pela CONTRATADA e pela CONTRATANTE, quando couber. O projeto deverá contemplar, dentre outras atividades, a montagem do ambiente de desenvolvimento, o entendimento da metodologia e das ferramentas utilizadas pela CONTRATANTE e análise da arquitetura dos sistemas legados.

O ambiente de desenvolvimento deverá estar concluído em no máximo 15 dias até a assinatura do contrato.

3.1. Situação atual

Os serviços de desenvolvimento e manutenção de sistemas de informação são, atualmente, executados por empresa CONTRATADA para tal fim e destinam-se a fornecer à CONTRATANTE uma gama de serviços de gerenciamento de projeto, levantamento de requisitos, análise, codificação, teste, homologação, documentação e implantação dos aplicativos desenvolvidos e mantidos. Para fiscalizar o serviço, a CONTRATANTE conta, atualmente, com 15 profissionais, sendo um gerente, 12 analistas e dois agentes executivos.

Os sistemas legados encontram-se defasados tecnologicamente e sem documentação. Uma necessidade evidente é a migração dos sistemas legados para a plataforma Java, pois além de seguir diretriz do governo federal quanto à utilização de software livre, permitirá a modernização destes sistemas, facilitando sua evolução.

O Plano Diretor de Tecnologia da Informação, definido para o período de 2013 a 2017, elencou uma série de sistemas de informação que deverão ser desenvolvidos e evoluídos.

Considerando o cenário supracitado, estima-se que sejam necessários, para o período de 30 meses:

• 7.700 pontos de função para dar vazão às demandas existentes e absorver as novas demandas que surgem constantemente, para manutenção corretiva e evolutiva do legado.

• 9.500 Pontos de função para o desenvolvimento de novos sistemas e migração dos principais sistemas legados para a plataforma Java.

• 800 Pontos de Função para a migração da Intranet para plataforma de gestão de conteúdo.

3.2. Metodologia

Os serviços devem ser executados de acordo com normas, procedimentos e técnicas adotadas pela CONTRATANTE, especialmente no que tange à sua metodologia de desenvolvimento de sistemas, e de acordo com as melhores práticas contidas nos modelos CMMI (Capability Maturity Model Integrated). Ao assinar o contrato, fica entendido que a licitante vencedora adere à metodologia, aos modelos de documentos, e qualquer outra padronização adotada pela CONTRATANTE.

3.3. Fluxo de desenvolvimento

3.3.1. A demanda é iniciada com a abertura da Ordem de Serviço (OS);

3.3.2. Ao receber a OS, a CONTRATADA deverá indicar profissional para realizar o levantamento de requisitos;

3.3.3. Após o levantamento de requisitos, a contratada deverá produzir os documentos necessários, referentes a esta fase e atualizar o Sistema de Gestão de Demandas, mudando a fase do projeto para o status de aprovação de requisitos;

3.3.4. Após a análise da documentação, a área demandante aprovará os requisitos, alterando o status da demanda para requisitos aprovados ou, em caso de rejeição, retornará a demanda para a fase de levantamento de requisitos, indicando os motivos da rejeição;

3.3.5. Após a aprovação dos requisitos, a CONTRATADA apresentará a Análise de Pontos de Função (APF) e a proposta de arquitetura, atualizando o status da demanda para em aprovação da arquitetura;

3.3.6. A Gerência de Sistemas aprovará a arquitetura e revisará a APF. Caso a arquitetura seja aprovada, o status da demanda será alterado para desenvolvimento, e a contratada deverá iniciar a construção de imediato, ainda que haja divergência entre as contagens apuradas pela CONTRATADA e CONTRATANTE. Em caso de rejeição da arquitetura, o status da demanda retornara para em aprovação da arquitetura;

3.3.7. Após a aprovação da arquitetura, a CONTRATADA desenvolverá a solução com base na arquitetura apresentada e, ao término desta atividade, entregará os artefatos produzidos, principalmente os códigos fontes, para testes, alterando o status para homologação;

3.3.8. Se a demanda for rejeitada, o status será retornado para desenvolvimento. Se for aprovada, caberá à CONTRATADA, sob a supervisão da CONTRATANTE, encaminhar a colocação dos serviços em produção, disponibilizando o produto de software e sua correspondente documentação para o Centro de Dados. A CONTRATANTE só autorizará a conclusão dos serviços e o seu após constatar sua entrada em produção sem vícios, entendidos como tais o funcionamento diferente do observado durante a homologação e o surgimento de problemas inexistentes antes de sua entrada em produção, cuja origem esteja comprovadamente no escopo dos produtos decorrentes destes serviços;

3.3.9. Os serviços prestados serão avaliados quando da entrega dos produtos e/ou resultados demandados. Será avaliada a conformidade com os requisitos definidos na Ordem de Serviço e, quando aplicável, com a fase concluída, sendo o aceite de cada fase e a homologação total da demanda efetuados no sistema de gestão de demandas, mediante a apresentação dos documentos previstos no item 6.1.2.2. Artefatos entregues por fase de projeto, do Anexo III - Roteiro de Métricas;

4. DESCRIÇÃO DO AMBIENTE COMPUTACIONAL

4.1. Plataforma de software

i. Sistemas operacionais

Servidores: Windows 2000 e 2003 Server, Sun (BOVESPA) e HP-UX (Novo Sistema de Acompanhamento do Mercado)

Linux ( Centos/Red Hat)

Estações clientes: Windows XP Professional e Window 7

ii. Clientes Web

Mozilla Firefox 3.5 ou superior e Internet Explorer 6.0 ou superior.

iii. Clientes de SGBD’s (Sistemas gerenciadores de banco de dados)

SQL Server 2000, 2005 e 2008, e Oracle 10g.

iv. Serviços de mensageria e colaboração

Exchange 2003; Protocolo SMTP e IMAP;

Servidores de aplicação: IIS, Apache e JBoss.

v. Ferramentas de automação de escritório

MS Office 2000 e 2003, em descontinuação, e 2007 Professional, em implantação; MS Project 2007;

vi. Ferramentas de backup

TSM, da IBM

vii. Solução de Antivírus:

McAfee VirusScan Enterprise.

viii. Outros softwares ou serviços

Business Objects (Enterprise 11, release 2) Compactador de arquivos WinZip

Fusion 3.7 (GED/Workflow) Máquina Virtual JAVA

Adobe Acrobat Viewer 6.0 ou superior Adobe Acrobat Writer 7.0 ou superior Adobe Pagemaker

Adobe PhotoShop 5.5

Adobe Creative Suite 2 for Windows Adobe Contribute 4

Adobe DreamWeaver 3.0 e 8.0

Adobe FireWorks 8 Adobe Flash 8 Pro

Aplicações Internet/Intranet/Extranet desenvolvidas usando HTML, ActiveX, JavaScript, VBScript, ASP, Macromedia Flash, XXX.Xxx 2003, C# .Net 2003, VB .Net 2003

Portal do Investidor, com recursos de acessibilidade, desenvolvido usando OpenCMS Borland Delphi 5.0, Client-Server version

MacroMedia Studio 8

Microsoft Visual Studio .Net 2003 e 2005

NextPage Folio Electronic Publishing software 4.0 e Site Director 4.2 Software CASE AllFusion-ERWin versões 4.1.4 e 7.2

Software CASE Visio Professional 2003 e Standard 2003 Visual Basic 5.0, 6.0 e .Net 2003

Informatica PowerCenter ETL 8.1.1 Cognos 8.0

4.2. Plataforma de hardware

O ambiente computacional da CVM, a partir de 2013, será administrado sobre a forma de Hosting, com os principais serviços descritos a seguir:

i. Arquitetura cliente

Servidores virtualizados, baseados em arquitetura x86-64 e plataforma de virtualização VMware

Servidores da plataforma Itanium, utilizados pelo sistema de mercado de capitais

ii. Rede

Conectividade Gibabit Ethernet (1000BaseT) em ambiente de Datacenter, localizado em São Paulo;

Links de acesso das unidades da CVM nas velocidades de 100Mb (RJ), 20Mb (SP) e 4Mb (DF)

Switches para balanceamento de carga destinados às aplicações Web; Protocolo TCP/IP;

iii. Servidores de rede:

Hosts de virtualização fornecidos pelo prestador de serviço de Datacenter da CVM suportando aproximadamente 60 servidores virtuais Windows ou Linux CentOS;

3 Servidores HP-UX que suportam o sistema de mercado de capitais

iv. Dispositivos de armazenamento e backup:

Unidade de armazenamento de dados fornecida pelo prestador de serviço de Datacenter, provento cerca de 40TB de espaço alocável;

Appliance de compartilhamento de arquivos NAS (Network Attached Storage), suportando os protocolos CIFS/SMB e NFS;

Backup do ambiente executado em Tape Library Adic Scalar i6000 utilizando fitas LTO-5.

4.3. Detalhamento do ambiente

i. Instalações prediais

Sede: Um prédio, situado na xxx Xxxx xx Xxxxxxxx, 000, 00x Xxxxx, Xxxxxx, Xxx xx Xxxxxxx/XX – 15 andares ocupados pela CONTRATANTE, de um total de 34;

Superintendência Regional de Brasília: Um módulo do Ed. Corporate Financial Center, no SCN Quadra 02 Bloco A 4° Andar - Módulo 404, Brasília/DF; e

Superintendência Regional de São Paulo: Xxx Xxxxxxxxx Xxxxx, 000 - 0x, 0x e 4º andares - Edifício Delta Plaza, Centro, São Paulo/SP.

ii. Estrutura de rede para comunicação de dados

Infra-estrutura implantada em cabeamento de par trançado categorias 5 e 6 e cabeamento óptico;

Instalações (06) de videoconferência, sendo três situadas na Sede da CONTRATANTE, duas na Superintendência Regional de São Paulo e uma na Superintendência Regional de Brasília.

iii. Ambiente de desenvolvimento

Banco de Dados de Produção: SQLServer 2000,2005 e 2008 e Oracle 10g ; OpenCMS (portais);

Linguagens de Programação: Delphi 5.0, XXX.Xxx, XX.Xxx e C#, HTML, XML, PHP, VBScript e JavaScript;

Ferramentas: Visual Studio .Net 2003 e 2005, Visio 2003, ER-Win 7.2 ; Containers Web: Internet Information Server 5.0 e 6.0, COM+; Frameworks de desenvolvimento utilizados: MS .Net 2003 e 2005; Programação orientada a eventos;

Programação orientada a objetos;

Análise e projeto orientados a objeto com UML;

Metodologia: Subconjunto customizado para a CVM pelo SERPRO, baseado no Processo SERPRO de Desenvolvimento de Soluções (PSDS), adaptado do RUP (Rational Unified Process) e alinhado com a Certificação CMMI de Nível 2.

iv. Sistemas de informação

Os sistemas de informação são divididos por suas características técnicas e funcionais, podendo ser cliente/servidor ou web, estando disponível apenas para uso dos colaboradores da Instituição quando presentes nas dependências do Órgão (client/Server e Intranet), para orientação de serviços terceirizados de call-center (Extranet) ou para uso do Mercado de Valores Mobiliários e demais cidadãos (através da Internet – Web).

A tabela a seguir relaciona serviços, softwares e sistemas atualmente em uso na CVM.

Ambiente	Solução	Plataforma
1. Intranet	12 itens
	Páginas Institucionais	HTML, ASP
	Busca de Documentos CVM	Folio, Delphi
	CAP – Sistema de Controle de Audiências a Particulares	ASP
	BI – Business Intelligence	BO
	Formação Acadêmica	Delphi
	Liberação Oferta Lançamento Dados Finais	Delphi
	SAD – Sistema de Atos Declaratórios	ASP, VB6
	SCDP – Diárias & Passagens	SERPRO
	SRH – Módulos de Freqüência e Férias	Delphi
	SSO – Sistema de Solicitação Serviços de Informática	.Net
	SSS – Sistema de Solicitação de Serviços Administrativos	ASP, Access
	DMCA – Sistema de Acompanhamento de Cias. Abertas	Informática, Cognos
2. Internet	66 itens
2.1 CVMWEB	12 itens
2.1.1 Sistemas autônomos (8 itens)
	CVMWeb - Serviços de Interface e Autenticação (SWB)	.Net,ASP, VB6
	CVMWeb - Serviços de Sincronização de Dados com o Repositório Corporativo	T-SQL
	CVMWeb - Denúncia Sobre Suspeita de Lavagem de Dinheiro (SDLD)	.Net
	CVMWeb - Consultas BACEN	.Net
	CVMWeb - Web Services de Download de Informes de Fundos	.Net, XML
	CVMWeb - Serviços Administrativos para Usuários da CVM (ADM)	.Net
	CVMWeb - Atualização Cadastral de Ativos (Títulos Públicos e Bolsas)	.Net
	CVMWeb - Serviço de Atendimento ao Investidor (SAI)	.Net
2.1.2 Complemento de sistemas corporativos (4 itens)
	CVMWeb - Atualização Cadastral de Participantes (SIC)	.Net
	CVMWeb - Registro (SRE)	.Net
	CVMWeb - Serviços de Taxas de Fiscalização (SCTAX)	.Net
	CVMWeb - Recepção de Informes de Fundos, Investidores Não Residentes e Administradores de Carteira (SRD)	.Net, Delphi
2.2 INTERNET pp. Dita (9 itens)
	Páginas Institucionais	HTML,

Ambiente	Solução	Plataforma
		ASP
	SIC - Módulo de Agentes Autônomos	.Net
	SIC - Módulo de Analista de Valores	.Net
	SIC - Módulo de Auditores	.Net
	SIC - Módulo de Instituições Financeiras	.Net
	SIC - Módulo de Prestadores de Serviços	.Net
	CAP - Sistema de Controle de Audiências a Particulares - Módulo de Solicitações	.Net
	Mailing "Legislação e Regulamentação"	ASP
	SAF/XXX - Xxxxxx RAD/IPE	BOVESPA
2.3 Extranet	2 itens
	Serviço 0800 – Consultas diversas no Cadastro de Participantes, Fundo 157 e Sistema de Taxas	ASP
	Serviço de Consultas aos Manuais de Inspeção	.Net
2.4 Portal do Investidor (43 itens, inteiramente provido com recursos de acessibilidade)
2.4.1. Página do Investidor (7 itens)
	Orientações ao investidor	.Net
	Por que investir?	.Net
	Como investir	.Net
	Direitos	.Net
	Como acompanhar investimentos	.Net
	Participantes do Mercado	.Net
	Cadernos e guias da CVM	.Net
2.4.2 Página do Acadêmico (6 itens)
	e-Learning	.Net
	Histórias em quadrinhos	.Net
	Histórias interativas	.Net
	Desafios	.Net
	Cursos	.Net
	Palestras	.Net
2.4.3. Página do Jurídico (4 itens)
	Legislação e regulamentação	.Net
	Pareceres	.Net
	Decisões do colegiado	.Net
	Entrevistas e artigos	.Net
2.4.4. Investidor Estrangeiro (18 itens (6 itens x 3 idiomas))
	O Mercado de Valores Mobiliários brasileiro	.Net
	Como investir	.Net
	Impostos e taxas	.Net

Ambiente	Solução	Plataforma
	Leis de proteção ao investidor	.Net
	Economia brasileira	.Net
	Dados estatísticos e econômicos do Brasil	.Net
2.4.5. Recursos Comuns (8 itens)
	Painel do investidor	.Net
	Pesquisa de fundos de investimento	.Net
	Desafios	.Net
	Vídeos	.Net
	Alertas	.Net
	Comunicados	.Net
	Ferramenta de busca	.Net
	Cadastro de Usuários	.Net
3. Sistemas Corporativos (33 itens)
	INQ - Sistema de Processos Administrativos Sancionadores - Inquéritos	Delphi
	LOG – Funcionalidades de atualização de trilhas de auditoria	T-SQL
	PJU_ACOMP - Sistema de Acompanhamento de Processos Jurídicos	Visual Basic 5
	PJU_DIVDAT - Sistema de Dívida Ativa de Taxa	Delphi
	DAM – Sistema de Dívida Ativa de Multas	Delphi
	REC - Sistema de Emissão/Recepção de Correspondência	Delphi
	REC/PFE - Sistema de Ementas de Documentos para a PFE	Delphi
	SAF/IAN - Módulo de Consultas	BOVESPA
	SAF/XXX - Xxxxxx CVMWin	BOVESPA
	SAA - Módulo Gerenciador & Carga do SAF/XXX	XXXXXXX
	SAF - Sistema de Análises Financeiras (Módulo auxiliar do SAF/IAN)	Delphi
	SysBibli - Sistema de Biblioteca	Contempory
	SAP - Sistema de Acompanhamento de Processos	Delphi
	SCA - Sistema de Acompanhamento de Processos de Companhias Abertas	Delphi
	SCMUL - Sistema de Controle de Multas Cominatórias	Delphi
	SCRD ou SRI - Sistema de Controle de Recepção de Documentos	Delphi
	SCTAX - Sistema de Taxa de Fiscalização	Delphi
	SDPA - Sistema de Desvios e Performance de Auditor	Delphi
	SEM - Sistema de Séries Históricas e Estatísticas	Delphi
	SFI - Sistema de Controle de Solicitações de Inspeção	Delphi
	SGA - Sistema de Gastos	Delphi
	SIC - Sistema de Cadastro de Participantes	Delphi

Ambiente	Solução	Plataforma
	SIE - Sistema de Investidores Estrangeiros	Delphi
	SMA - Sistema de Mailing	Delphi
	SRA - Sistema de Restrição de Acesso	Delphi
	SRD - Sistema de Recebimento de Documentos	Delphi
	SRE - Sistema de Registro de Valores Mobiliários	Delphi
	CRI - Sistema de Registros de Certificados de Recebíveis Imobiliários	Delphi
	CRI Emissor - Certificado de Recebíveis Imobiliários	Delphi
	EP - Sistema de Emissões Particulares	Delphi
	Link - Controle de Almoxarifado	Link
	Link - Controle de Patrimônio	Link
	SRH - Sistema de Recursos Humanos (RHN)	Delphi
4. Soluções de Business Intelligence (2 itens)
	WFD- Datamart de Fundos de Investimento	BO
	WIN - Datamart de Inquéritos	BO
5. Soluções de Automação de Escritório (2 itens)
	Sistema de Recepção e Controle de Documentos	Access
	Sistema de Documentos da Procuradoria Federal Especializada	Access
Total:	115 Soluções

Observações:

a. As plataformas BOVESPA, Informática, Cognos e SERPRO não são de responsabilidade da CONTRATADA, mas deverão ser levadas em consideração por força de integração de aplicativos.

b. As plataformas Link e Contempory não são de responsabilidade da CONTRATADA.

v. Metodologia de Desenvolvimento de Sistemas

A metodologia de desenvolvimento de sistemas utilizada pela CONTRATANTE, de utilização compulsória, será definida no período de adaptação da CONTRATADA.

4.4. Local de execução dos serviços

Os serviços de desenvolvimento deverão ser executados nas dependências da CONTRATADA, sobre o regime de fábrica de software.

A CONTRATADA poderá manter profissional nas dependências da CONTRATANTE, conforme especificidades, características e emergência das atividades a serem realizadas, notadamente atividades de manutenção corretiva e emergencial e levantamento de requisitos.

Para as atividades realizadas nas dependências da CONTRATADA, esta deverá manter, sob suas expensas, conexão com o Centro de Dados da CVM, em conformidade com os padrões estabelecidos pela CONTRATANTE e seu provedor.

O endereço das dependências da CONTRATANTE para execução dos serviços relacionados no item 1 do Termo de Referência (Anexo I) e neste documento de especificações técnicas (Anexo II) é:

Xxx Xxxx xx Xxxxxxxx, 000, 00x xxxxx, Xxxxxx, Xxx xx Xxxxxxx/XX

5. SISTEMA DE GESTÃO DE DEMANDAS

Para acompanhamento da execução das demandas e do SLA, a CONTRATADA DEVERÁ migrar o atual sistema da CONTRATANTE, conformo os requisitos definidos pela Gerência de Sistemas (GSI).

A construção do sistema será remunerada em pontos de função, seguindo os critérios definidos para o desenvolvimento de sistemas.

Este sistema deverá possuir interface WEB e será compulsoriamente utilizado pela CONTRATADA, através de representantes indicados por ela, para incluir as informações relacionadas à execução da demanda sob sua responsabilidade;

Abaixo, a descrição do ciclo da demanda:

• Abertura da demanda pela GSI;

• Apresentação da documentação dos requisitos pela CONTRATADA;

• Aprovação dos requisitos pela área de negócios demandante;

• Apresentação da Arquitetura da Solução para a GSI;

• Aprovação da Arquitetura da Solução pela GSI;

• Entrega dos Fontes, Scripts, plano de implantação e outros artefatos para a implantação da solução pela CONTRATADA;

• Testes da Solução pela GSI;

• Homologação da Solução pela área de negócios demandante;

Este fluxo acima poderá ser revisto pela CONTRATANTE, visando adequações a alterações da metodologia de desenvolvimento.

Até que o Sistema de Gestão de Demandas esteja operacional, a CONTRATADA dever manter e disponibilizar à CVM informações atualizadas sobre as ordens de serviço, constando o estágio de desenvolvimento e sua previsão de atendimento.

6. UNIDADE RESPONSÁVEL PELO TERMO DE REFERÊNCIA

Gerência de Sistemas (GSI).

7. UNIDADE FISCALIZADORA DO CONTRATO

Gerência de Sistemas (GSI).

Rio de Janeiro/RJ, 05 de dezembro de 2013.

Xxxx Xxxx xx Xxxxx

Gerente de Sistemas – CVM

ANEXO III DO TERMO DE REFERÊNCIA ROTEIRO DE MÉTRICAS

1. Introdução

Diversas instituições públicas e privadas têm utilizado a métrica Ponto de Função (PF) nas estimativas e dimensionamento de tamanho funcional de projetos de software devido aos diversos benefícios de utilização da métrica, destacando: regras de contagem objetivas, independência da solução tecnológica utilizada e facilidade de estimativa nas fases iniciais do ciclo de vida do software.

A Instrução Normativa IN04 SLTI/MPOG 2010 recomenda o uso de métricas em contratos de projetos de software, restringindo o uso da métrica de esforço homem-hora. Além disso, a Portaria SLTI/MP Nº 31, de 29 de novembro de 2010 recomenda o uso da métrica Análise de Ponto de Função para os órgãos integrantes do Sistema de Administração dos Recursos de Tecnologia da Informação (SISP), organizado pelo Decreto nº 7.579, de 11 de outubro de 2011, bem como a adoção do Roteiro de Métricas de Software do SISP, ou documento similar, na contratação de serviços de desenvolvimento e manutenção de soluções de software. Os Acórdãos do Tribunal de Contas da União (TCU) recomendam a utilização da métrica Pontos de Função Não Ajustados em contratos de prestação de serviços de desenvolvimento e manutenção de sistemas.

O Manual de Práticas de Contagem de Pontos de Função (CPM 4.3) [IFPUG, 2010], publicado pelo International Function Point Users Group (IFPUG), define as regras de contagem de Pontos de Função. É importante ressaltar que a métrica Ponto de Função foi concebida como uma medida de tamanho funcional para projetos de desenvolvimento e de melhoria (manutenção evolutiva) de software. No entanto, os projetos de software não estão limitados a projetos de desenvolvimento e de melhoria. Desta forma, torna-se essencial a definição de métricas para dimensionar o tamanho de outros tipos de projetos de manutenção, os quais são itens não mensuráveis pelo CPM.

Além disso, a contagem de Pontos de Função é baseada no projeto lógico da aplicação (logical design). Nas fases iniciais do ciclo de vida do software, o insumo para a definição das estimativas do projeto é um documento inicial de requisitos, por exemplo: Documento de Visão ou algum outro tipo de especificação elaborada pelo analista de negócios. Assim, torna-se importante o estabelecimento de métodos para estimar o tamanho dos projetos de software nas fases iniciais do ciclo de vida. Outro ponto a ser destacado é a importância da definição de métodos para geração de estimativas de prazo e custo dos projetos de software a partir do tamanho funcional estimado do projeto.

É importante frisar que o Manual de Práticas de Contagem é um documento que se destina a mensurar o tamanho funcional de projetos de software, não tendo por objetivo principal suportar contratos de fábrica de software. Assim, torna-se necessário criar roteiros complementares, contemplando questões não abordadas pelo manual do IFPUG, mas vivenciadas pelos órgãos e entidades do SISP.

2. Objetivo

Este documento descreve o roteiro de métricas de contagem de pontos de função a ser utilizado na Comissão de Valores Mobiliários (CVM) com base no Manual de Práticas de Contagem (CPM 4.3) e nos Roteiros de Métricas de Software do SISP, para todos os projetos de desenvolvimento e manutenção de sistemas.

Além da contagem de Pontos de Função, este roteiro apresenta um processo de estimativas com base na métrica Ponto de Função, aderente ao modelo CMMI, visando apoiar as estimativas de tamanho, custo, prazo e esforço de projetos.

Este roteiro não utilizará o Fator de Ajuste que se baseia nas quatorze características gerais do sistema nas contagens de pontos de função. Será considerado, para qualquer finalidade, o ponto de função não ajustado, conforme orientação do TCU (Acórdão nº 1.910/2007).

Por abranger várias atividades de desenvolvimento e manutenção de sistemas, este roteiro é parte integrante do Contrato e do Termo de Referência, sendo que alguns itens podem não ser aplicáveis à execução do objeto licitado.

3. Contagem de Pontos de Função

A métrica PF mede o tamanho funcional de um projeto de software, observando as funcionalidades implementadas, considerando a visão do usuário. Tamanho funcional é definido como “tamanho do software derivado pela quantificação dos requisitos funcionais do usuário” [Dekkers, 2003]. A métrica PF é independente da metodologia e tecnologia utilizadas. A Análise de Pontos de Função (APF) é um método padrão para a medição de projetos de desenvolvimento e de manutenção de sistemas, visando estabelecer uma medida de tamanho do software em pontos de função, com base na quantificação da funcionalidade solicitada e entregue, sob o ponto de vista do usuário. Assim, a APF tem como objetivo medir o que o software faz, por meio de uma avaliação padronizada dos requisitos de negócio do sistema.

O Manual de Práticas de Contagem (CPM) [IFPUG, 2010] apresenta as regras de contagem de Pontos de Função de Projetos de Desenvolvimento, Projetos de Melhoria e Aplicações Implantadas. A Figura 1 ilustra o procedimento de contagem de pontos de função, descrito nas seções seguintes.

Figura 1: Procedimento de Contagem de Pontos de Função

3.1. Determinar Propósito, Tipo, Escopo e Fronteira de Contagem

A Contagem de Pontos de Função se inicia com a análise da documentação disponível do projeto em questão, visando à identificação dos requisitos funcionais. O próximo passo é o estabelecimento do propósito da contagem, o qual fornece uma resposta para uma questão de negócio a ser resolvida. Com base no propósito da contagem são definidos o escopo da contagem, que identifica quais funcionalidades serão incluídas na contagem de pontos de função, e o tipo de contagem, que pode ser projeto de desenvolvimento, projeto de melhoria ou aplicação instalada. A fronteira da aplicação, que é a interface conceitual que indica o limite lógico entre o sistema sendo medido e os usuários (também entre outras aplicações), deve ser definida com base na visão do usuário, desconsiderando questões de implementação. Deve-se ressaltar que toda contagem de Pontos de Função é realizada dentro de uma fronteira estabelecida.

3.2. Identificar Funções de Dados e Funções Transacionais

Uma vez estabelecida a fronteira da contagem, o próximo passo é o mapeamento dos requisitos de dados e de funções transacionais para os tipos funcionais da APF, a saber:

• Arquivo Lógico Interno (ALI): é um grupo de dados, logicamente relacionados, reconhecido pelo usuário, mantido por meio de um processo elementar da aplicação que está sendo contada.

• Arquivo de Interface Externa (AIE): é um grupo de dados, logicamente relacionados, reconhecido pelo usuário, mantido por meio de um processo elementar de outra aplicação e referenciado pela aplicação que está sendo contada. O AIE é obrigatoriamente um ALI de outra aplicação.

• Entrada Externa (EE): é um processo elementar que processa dados ou informação de controle que entram pela fronteira da aplicação. Seu objetivo principal é manter um ou mais ALI ou alterar o comportamento do sistema.

• Consulta Externa (CE): é um processo elementar que envia dados ou informação de controle para fora da fronteira da aplicação. Seu objetivo principal é apresentar informação para o usuário através da recuperação de dados ou informação de controle de ALI ou AIE.

• Saída Externa (SE): é um processo elementar que envia dados ou informação de controle para fora da fronteira da aplicação. Seu objetivo principal é apresentar informação para um usuário ou outra aplicação através de um processamento lógico adicional à recuperação de dados ou informação de controle. O processamento lógico deve conter cálculo, ou criar dados derivados, ou manter ALI ou alterar o comportamento do sistema.

Após a identificação dos tipos funcionais para cada requisito funcional definido no documento de requisitos do sistema, deve-se avaliar a complexidade (Baixa, Média, Alta) e a contribuição funcional do mesmo para a contagem de pontos de função, observando-se as regras de contagem de pontos de função descritas no CPM. A Tabela 1 apresenta a contribuição dos tipos funcionais na contagem de pontos de função.

	Complexidade
Tipo Funcional	Baixa	Média	Alta
Arquivo Lógico Interno (ALI)	7 PF	10 PF	15 PF
Arquivo de Interface Externa (AIE)	5 PF	7 PF	10 PF
Entrada Externa (EE)	3 PF	4 PF	6 PF
Saída Externa (SE)	4 PF	5 PF	7 PF
Consulta Externa (CE)	3 PF	4 PF	6 PF

Tabela 1: Contribuição Funcional dos Tipos Funcionais (Fonte: CPM 4.3)

3.3. Calcular Tamanho Funcional

O Manual de Práticas de Contagem do IFPUG define dois tipos de projetos de software, a

saber:

• Projeto de Desenvolvimento: 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.

• Projeto de Melhoria: Projeto de manutenção evolutiva ou melhoria funcional. 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.

Seguem abaixo as definições dos termos técnicos da Análise de Pontos de Função utilizados nas fórmulas de dimensionamento de projetos de software propostas neste Roteiro:

• PF_INCLUÍDO = Pontos de Função associados às novas funcionalidades que farão parte da aplicação após um projeto de desenvolvimento ou de manutenção.

• PF_ALTERADO = Pontos de Função associados às funcionalidades existentes na aplicação que serão alteradas no projeto de manutenção.

• PF_EXCLUÍDO = Pontos de Função associados às funcionalidades existentes na aplicação que serão excluídas no projeto de manutenção.

• PF_CONVERSÃO = Pontos de Função associados às funcionalidades de conversão de dados dos projetos de desenvolvimento ou de manutenção. Exemplos de funções de conversão incluem: migração ou carga inicial de dados para popular as novas tabelas criadas (Entradas Externas) e relatórios associados à migração de dados, caso requisitado pelo usuário (Saídas Externas ou Consultas Externas). Observe que os dados carregados em um processo de migração não devem ser contados como Arquivos de Interface Externa.

Este Roteiro recomenda a supressão do PF_CONVERSÃO das fórmulas de contagem de pontos de função de Projetos de Desenvolvimento e de Melhoria nos casos específicos onde for caracterizado um esforço relativamente maior dessa atividade. Como exemplo, citamos os projetos que envolvam a migração de dados de banco de dados hierárquico para banco de dados relacionais e o tratamento das funções complexas de migração de dados. Nesses casos, recomendamos tratar esse serviço como projetos separados de migração de dados.

3.4. Requisitos Não Funcionais

A métrica Ponto de Função é uma métrica de tamanho funcional, ou seja, dimensiona projetos de software com base nos requisitos funcionais da aplicação, não contemplando diretamente os requisitos não funcionais do projeto.

Nesse sentido, em contratos de software baseados na métrica Ponto de Função é fundamental definir claramente no edital os requisitos não funcionais do projeto a serem atendidos pela empresa contratada. Os requisitos não funcionais impactam no esforço e, consequentemente, no custo do projeto.

Os requisitos não funcionais estão associados aos aspectos qualitativos de um software, considerando aspectos relacionados ao uso do software. Seguem abaixo alguns tipos de requisitos não funcionais, com exemplos, que podem ser mencionados nos editais:

- Usabilidade: a solução deve atender aos requisitos dos Padrões Web em Governo Eletrônico (e-PWG) - Cartilha de Usabilidade; a aplicação deve ter help on-line de sistema, tela e campo (sensível a contexto); a aplicação deve ser disponibilizada nos idiomas Português, Espanhol e Inglês.

- Técnicos: a aplicação deve funcionar adequadamente nos navegadores: Internet Explorer 7.0 ou superior e Mozilla Firefox 3.0 ou superior; a solução deve ser desenvolvida em linguagem Java com banco de dados PostgreSQL; para o desenvolvimento da solução, deve ser utilizado preferencialmente um dos seguintes frameworks Java: Demoiselle, Jaguar e MDArt; a solução deve atender aos requisitos do e-PWG; deve utilizar as ferramentas AWSTATS e Google Analytics para gerar estatísticas de acesso.

- Segurança: a aplicação deve realizar controle de segurança dos dados de acordo com política de backup definida em conformidade com a norma ISO/IEC 27002.

- Acessibilidade: a solução deve ser aderente ao Modelo de Acessibilidade de Governo Eletrônico (e-MAG).

- Performance: o tempo de resposta da aplicação não deve exceder 10 segundos; a solução deve suportar até 1.000 acessos simultâneos.

- Interoperabilidade: a solução deve ser aderente aos Padrões de Interoperabilidade de Governo Eletrônico (e-PING).

4. Cálculo de Pontos de Função

Este capítulo tem como propósito descrever os tipos de projetos de software e definir métricas baseadas nas regras de contagem de pontos de função do CPM e do SISP para seu dimensionamento.

Quanto à documentação de projetos de manutenção menores que 100 PF, deve-se registrar a solicitação e documentar os requisitos do projeto de manutenção e da aplicação impactada pela demanda, de forma detalhada, visando apoiar a contagem de pontos de função da demanda. É importante também documentar as estimativas e a contagem de pontos de função.

Cabe ressaltar que não haverá necessidade de contratar todas as fases do ciclo de vida do software. Dessa forma, a contratada será remunerada pela contagem de pontos de função considerando-se apenas os percentuais das fases contratadas. Exemplo: para um novo projeto de

desenvolvimento de um sistema de treinamentos não se deseja contratar as fases de requisitos e de testes, desta forma, a contratada será remunerada pela contagem de pontos de função considerando-se apenas os percentuais das outras fases contratadas.

4.1. Projeto de Desenvolvimento

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. Segue a fórmula de cálculo utilizada no dimensionamento de projetos de desenvolvimento de software:

PF_DESENVOLVIMENTO = PF_INCLUIDO + PF_CONVERSÃO

Este roteiro recomenda a supressão do PF_CONVERSÃO das fórmulas de contagem de pontos de função de projetos de desenvolvimento quando for caracterizado um esforço relativamente maior dessa atividade.

4.2. Projeto de Melhoria (Manutenção Evolutiva)

O Projeto de Melhoria (enhancement), também denominado de projeto de melhoria funcional ou manutenção evolutiva, está associado às mudanças em requisitos funcionais da aplicação, ou seja, à inclusão de novas funcionalidades, alteração ou exclusão de funcionalidades em aplicações implantadas.

Segundo o padrão IEEE Std 1219 [IEEE, 1998], esta manutenção seria um tipo de manutenção adaptativa, definida como: modificação de um produto de software existente para mantê-lo funcionando adequadamente em um ambiente com mudanças. O projeto de melhoria é considerado um tipo de projeto de manutenção adaptativa com mudanças em requisitos funcionais da aplicação, ou seja, com funcionalidades incluídas, alteradas ou excluídas na aplicação, segundo o CPM 4.3.

Este documento separa o projeto de melhoria (quando as mudanças são associadas aos requisitos funcionais) do projeto de manutenção adaptativa (quando as mudanças estão associadas aos requisitos não funcionais da aplicação).

Um projeto de melhoria consiste em demandas de criação de novas funcionalidades (grupos de dados ou processos elementares), demandas de exclusão de funcionalidades (grupos de dados ou processos elementares) e demandas de alteração de funcionalidades (grupos de dados ou processos elementares) em aplicações implantadas em produção.

Segue a fórmula de cálculo utilizada no dimensionamento de projetos de melhoria de software:

PF_MELHORIA = PF_INCLUIDO + (0,5 x PF_ALTERADO) + (0,1 x PF_EXCLUIDO) + PF_CONVERSAO

Os cálculos acima correspondem à contratação de todas as fases do processo de desenvolvimento de software. Caso alguma fase não seja contratada, deve-se aplicar às fórmulas um redutor que corresponde ao percentual da fase não contratada, conforme percentuais sugeridos na Tabela 7.

Este roteiro recomenda a supressão do PF_CONVERSÃO das fórmulas de contagem de pontos de função de projetos de melhoria quando for caracterizado um esforço relativamente maior dessa atividade.

Seguem algumas considerações importantes para serem analisadas em projetos de melhoria.

OBS 1: Documentação

O projeto de melhoria prevê a documentação do requisito da manutenção e atualização do requisito da funcionalidade em questão, caso exista documentação de requisito. A documentação da demanda de manutenção não é redocumentação (ver seções 4.5 e 4.6 deste roteiro)

OBS 2: Função alterada

Uma função de dados (Arquivo Lógico Interno ou Arquivo de Interface Externa) é considerada alterada quando houver inclusão ou exclusão de Tipos de Dados (TD). De acordo com o Glossário do CPM 4.3, um Tipo de Dados (DET - Data Element Type) é um atributo único, reconhecido pelo usuário e não repetido. Também é considerada alterada se algum tipo de dado sofrer mudança de tamanho (número de posições) ou tipo de campo (por exemplo: mudança de numérico ou alfanumérico), caso a mudança decorra de alteração de regra de negócio.

Uma função transacional (Entrada Externa, Consulta Externa e Saída Externa) é considerada alterada, quando a alteração contemplar:

Mudança de tipos de dados; Mudança de arquivos referenciados;

Mudança de lógica de processamento.

O CPM 4.3 define lógica de processamento como requisitos especificamente solicitados pelo usuário para completar um processo elementar. Esses requisitos podem incluir as seguintes ações:

• Validações são executadas;

• Fórmulas matemáticas e cálculos são executados;

• Valores equivalentes são convertidos;

• Dados são filtrados e selecionados através da utilização de critérios;

• Condições são analisadas para verificar quais são aplicáveis;

• Um ou mais ALIs são atualizados;

• Um ou mais ALIs e AIEs são referenciados;

• Dados ou informações de controle são recuperados;

• Dados derivados são criados através da transformação de dados existentes, para criar dados adicionais;

• O comportamento do sistema é alterado;

• Preparar e apresentar informações para fora da fronteira;

• Receber dados ou informações de controle que entram pela fronteira da aplicação;

• Dados são reordenados.

OBS 3: Outros tipos de funções alteradas

Este roteiro considera como função alterada qualquer mudança em funcionalidades da aplicação devido às mudanças de regras de negócio. Por exemplo, uma funcionalidade de cadastro implicava na inclusão de um telefone do gerente. Devido a mudanças no processo de negócio, a funcionalidade deve sofrer uma manutenção para cadastrar dois telefones do gerente. Desta forma, o Roteiro considera esta função como uma Entrada Externa alterada, PF_ALTERADO em um Projeto de Melhoria, mesmo que não exista mudança de lógica, mudança de Tipos de Dados e mudança de arquivos referenciados.

OBS 4:Manutenção adaptativa

Serão tratadas como manutenções adaptativas apenas as manutenções que implicarem exclusivamente em mudanças em requisitos não funcionais. Se uma mesma funcionalidade tiver mudanças em requisitos funcionais e não funcionais, esta deve ser contada apenas uma vez, como função alterada em um Projeto de Melhoria. Em projetos com mais de uma funcionalidade envolvendo os dois tipos acima, a contagem será realizada considerando cada funcionalidade em separado e não o aspecto predominante da demanda ou pedido.

4.3. Manutenção Corretiva

Mesmo com a execução de atividades de garantia da qualidade, podem-se identificar defeitos na aplicação entregue. A manutenção corretiva altera o software para correção de defeitos. Encontram-se nesta categoria, as demandas de correção de erros (bugs) em funcionalidades em sistemas em produção.

É importante destacar que as demandas de manutenção corretiva frequentemente precisam ser atendidas com urgência. Assim, o grau de criticidade do projeto poderá trazer impacto nas estimativas de custo e esforço. O padrão IEEE Std 1219 [IEEE,1998] define um tipo

de manutenção corretiva, denominado de Manutenção Emergencial como “manutenção corretiva não programada executada para manter o sistema em estado operacional”.

Quando o sistema em produção tiver sido desenvolvido pela contratada, a manutenção corretiva será do tipo Garantia, conforme prazos e demais cláusulas do contrato em questão. Caso não exista cláusula contratual de Garantia, deve ser considerada a garantia de seis meses, preconizada por lei (Código do Consumidor).

Quando o sistema estiver fora da Garantia ou não tiver sido desenvolvido pela contratada, deverá ser estimado e calculado o tamanho do projeto de manutenção corretiva.

As demandas de manutenção corretiva não contemplam atualização de documentação da funcionalidade corrigida, pois este roteiro considera que, normalmente, manutenção corretiva não se refere a erros de requisitos. Caso seja erro em requisitos, essa demanda deve ser tratada como projeto de melhoria (alteração de funcionalidade).

A aferição do tamanho em pontos de função da funcionalidade ou das funcionalidades corrigidas seguirá a fórmula descrita abaixo.

PF_CORRETIVA = PF_ALTERADO x 0,5

4.4. Manutenção Adaptativa sem Alteração de Requisitos Funcionais

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.

Nestes casos, a aferição do tamanho em Pontos de Função da funcionalidade ou das funcionalidades que sofreram impactos será calculada de acordo com a fórmula abaixo. Caso exista uma documentação da funcionalidade, esta deverá ser atualizada.

PF_ADAPTATIVA = PF_ALTERADO x 0,5

4.5. Redocumentação em Projetos de Manutenção

Este roteiro propõe um fator de redocumentação (Caso de Uso, Regra de negócio, etc.) menor para projetos de manutenção (melhoria, corretiva e adaptativa) do que o fator proposto em projetos específicos de redocumentação (seção 4.6 deste roteiro). Isso porque, em projetos de manutenção de uma funcionalidade sem documentação, é necessário realizar o entendimento da funcionalidade para poder modificá-la e testá-la, ou seja, é necessário realizar a engenharia reversa da funcionalidade para executar os testes corretamente. Assim sendo, a redocumentação requisitada em projetos de melhoria requer um esforço menor do que em projetos de redocumentação, descritos na seção 4.6, onde é necessário remunerar todo o esforço de engenharia reversa e a atividade de documentação. Em projetos de manutenção, o fator de 15% está remunerando apenas a atividade de documentação.

PF_DOCUMENTAÇÃO = PF_NÃO_AJUSTADO x 0,15

4.6. Projetos Específicos de Redocumentação de Sistemas

Nesta seção são tratadas demandas de documentação ou atualização de documentação (Caso de Uso, Regra de negócio, etc.) de sistemas legados não abrangendo projetos de manutenção. Observe que o desenvolvedor deve realizar uma engenharia reversa da aplicação para gerar a documentação. Para este tipo de projeto foi definido o fator de impacto de 25% dos pontos de função da aplicação em questão, considerando a fase de requisitos e a geração de artefatos associados a requisitos, conforme a fórmula abaixo.

PF_DOCUMENTAÇÃO = PF_NÃO_AJUSTADO x 0,25

Caso a demanda seja a geração de artefatos de documentação de outras fases do processo de desenvolvimento, deve-se considerar outro fator de impacto, considerando as fases do ciclo de vida e os demais artefatos a serem gerados. As premissas utilizadas devem ser definidas nas cláusulas contratuais e documentadas no documento de estimativas do projeto.

4.7. Projetos de Migração de Dados

Conforme mencionado na seção 3.3, este Roteiro recomenda a supressão do PF_CONVERSÃO das fórmulas de contagem de pontos de função de Projetos de Desenvolvimento e de Melhoria nos casos específicos onde for caracterizado um esforço relativamente maior dessa atividade, tais como, nos casos de migração de dados de banco de dados hierárquico para banco de dados relacionais, e no tratamento de funções complexas de migração de dados. Nesses casos, recomendamos tratar esse serviço como projetos separados de migração de dados.

Os projetos de migração de dados devem ser contados como um novo projeto de desenvolvimento de um sistema, seguindo a fórmula abaixo:

PF_CONVERSÃO = PF_INCLUIDO

Um projeto de migração deve contemplar minimamente: os ALIs mantidos pela migração, Entradas Externas - considerando as cargas de dados nos ALIs e caso seja solicitado pelo usuário relatórios gerenciais das cargas, estes serão contados como Saídas Externas. Todas as contagens de PF devem ser realizadas com base nas funcionalidades requisitadas e recebidas pelo usuário.

4.8. Manutenção em Interface

A manutenção em Interface, denominada na literatura manutenção cosmética, é associada às demandas de alterações de interface, por exemplo, fonte de letra, cores de telas, logotipos, mudança de botões na tela, mudança de posição de campos ou texto na tela. Também se enquadram nessa categoria as mudanças de texto em mensagens de erro, validação, aviso, alerta ou conclusão de processamento.

Nestes casos, a aferição do tamanho em Pontos de Função das funcionalidades ou processos elementares alterados será realizada de acordo com a fórmula abaixo:

PF_INTERFACE = 0,05 x QUANTIDADE DE PROCESSOS ELEMENTARES ALTERADOS

Está contemplada a atualização da documentação das funcionalidades da aplicação impactadas pela manutenção nas demandas desta categoria. Ou seja, a documentação, por exemplo, documento de requisitos, documento de interface, protótipo, das funcionalidades alteradas deve ser atualizada. Caso não exista documentação para as funcionalidades alteradas, não será contemplada a redocumentação das funcionalidades da aplicação impactadas pela manutenção nas demandas desta categoria.

OBS 1 - Help: As demandas de projetos de desenvolvimento de sistemas ou de manutenção de funcionalidades contemplam o desenvolvimento ou atualização do help da

funcionalidade em questão, sendo tratadas como uma atividade de documentação no processo de software. No caso de demandas específicas de apenas desenvolvimento ou atualização de Help de funcionalidades, estas podem ser enquadradas neste tópico e usarão a mesma fórmula acima. Em caso de requisitos de usuário para o desenvolvimento de funcionalidades de manutenção de help, deve-se contar a função de dados de help e as funcionalidades de manutenção de help (por exemplo: incluir help de tela, consultar help de campo) de acordo com o CPM 4.3.

4.9. Desenvolvimento, Manutenção e Publicação de Páginas Estáticas de Intranet, Internet ou Portal

Nesta seção são tratadas manutenções específicas em páginas estáticas de Portais,

Intranets ou Websites. A demanda consiste na publicação de páginas com conteúdo estático. Por exemplo:

• criação/alteração de página de estilo;

• criação/alteração de página HTML/ASP/JSP;

• criação/atualização de menu estático;

• criação/atualização de texto;

• criação/alteração de imagem ou vídeo em páginas existentes;

• inclusão/alteração/exclusão de links

• inclusão/alteração de links para visualização de documentos Word/Excel/PDF, etc.

Caso o desenvolvimento de páginas estáticas esteja contido em um projeto de desenvolvimento, então elas serão contabilizadas no projeto de desenvolvimento e não devem ser mensuradas em separado. Ou seja, esta seção se aplica quando ocorrer demanda exclusivamente para o desenvolvimento ou manutenção de páginas estáticas.

Os Pontos de Função destas manutenções são calculados levando-se em conta a quantidade de páginas desenvolvidas ou mantidas, independentemente do número de alterações, inclusões ou exclusões realizadas por página, de acordo com as fórmulas abaixo:

• DESENVOLVIMENTO (criação) de Páginas de Conteúdo Estático:

PF_DESENVOLVIMENTO = 0,10 x (quantidade de páginas desenvolvidas)

Obs: A inclusão ou alteração de links para visualização de documentos Word/Excel/PDF e assemelhados serão contados separadamente levando-se em conta o esforço despendido para colocar o arquivo em um local específico da pasta de rede. Caso haja apenas referência ao arquivo já existente na pasta de rede, este não será contado, apenas a alteração do conteúdo estático da página com referência ao arquivo será contada. Exemplo: criação de uma página estática com dois links para arquivos Word -> PF = 0,10 (desenvolvimento de página estática) + 0,10 (1º arquivo) + 0,10 (2º arquivo) = 0,30

• MANUTENÇÃO de Páginas de Conteúdo Estático. As manutenções de inclusão, exclusão e alteração de conteúdo são tratadas como uma única manutenção por página:

PF_MANUTENÇÃO = 0,02 x (quantidade de páginas mantidas)

• CRIAÇÃO E MANUTENÇÃO de Páginas com gerenciador de conteúdo (OpenCMS, WordPress, Joomla e outros). A criação e a manutenção (inclusão, exclusão e alteração) de conteúdo são tratadas pela fórmula abaixo:

PF_GERENCIADOR_CONTEÚDO = 0,01 x (itens publicados)

São considerados itens de publicação: links, documentos, páginas. As imagens, vídeos, sons e similares são tratados conforme o item abaixo.

• TRATAMENTO de Arte (imagens, sons, vídeos ou similares). As demandas de criação ou alteração de arte são tratadas segundo a fórmula abaixo:

PF_TRATAMENTO_ARTE = 0,10 x (quantidade de páginas envolvidas)

O tratamento de mais de uma imagem, som, vídeo ou similar é considerado como uma única manutenção por página. Ex: criação/alteração de animações em flash, criação/alteração de imagens JPEG/GIF/PNG, criação/alteração de vídeos nos formatos AVI/MPEG.

Obs: O tratamento de arquivos de imagens, vídeos, sons e similares se refere somente ao esforço de criação ou alteração do arquivo em questão, sendo assim, as cópias ou referências a estes arquivos sem o trabalho de criação ou alteração dos mesmos não são considerados na contagem de pontos de função para o item de tratamento de arte.

4.10. Componente Interno Reusável

Em alguns casos são demandadas manutenções em componentes específicos de uma aplicação e estes são reusados por várias funcionalidades da aplicação. Por exemplo, uma mudança em uma rotina de validação de um CPF usada em várias funcionalidades de cadastro. Se considerarmos o método de contagem de projetos de melhoria do CPM, seriam contadas todas as funcionalidades impactadas por essa mudança.

No entanto, este roteiro propõe que o componente, o qual deverá ser testado, seja considerado como um processo elementar independente e contado como uma funcionalidade. Além disso, as funcionalidades da aplicação que necessitem de teste devem ser requisitadas pela contratante e dimensionadas por meio da métrica Pontos de Função de Teste.

PF_COMPONENTE = PF_NÃO_AJUSTADO

Seguem alguns exemplos de manutenção de componentes:

• Alteração de valores de elementos internos de configuração que afetem o comportamento ou a apresentação do sistema de forma geral, tais como páginas de estilos (arquivos CSS de sistemas Web), arquivos com mensagens de erro, arquivos de configuração de sistema, arquivos de internacionalização;

• Mudança em tópico de um menu de um sistema em PHP que aparece em todas as telas da aplicação. A contagem pode ser realizada considerando o componente “Apresentar Menu”.

4.11. Mudança de Plataforma

São considerados nesta categoria, projetos que precisam ser migrados para outra plataforma. Por exemplo, um sistema legado em COBOL precisa ser redesenvolvido em JAVA; o banco de dados de um Sistema Legado precisa ser migrado para o DB2.

Recomenda-se enfaticamente a realização da análise de impacto das mudanças propostas, para efeito de determinação do percentual adequado para aplicação sobre o total de pontos de função do projeto. Por exemplo, em uma análise de impacto pode ser identificado que não haverá mudanças em código, sendo necessário apenas testar o sistema, então deve-se utilizar um percentual contemplando apenas a fase de testes. E em caso de erros identificados no teste, pode ser identificada uma nova demanda de manutenção corretiva.

As subseções seguintes apresentam os tipos de Projetos de Mudança de Plataforma. Os projetos de mudança de plataforma que se enquadram em mais de uma subseção, devem ser contados apenas uma vez, considerando o tipo de projeto com maior contagem de Pontos de Função.

4.11.1. Mudança de Plataforma - Linguagem de Programação

Nesta categoria encontram-se as demandas de redesenvolvimento de sistemas em outra linguagem de programação. Como estes projetos legados, frequentemente, encontram-se sem documentação, então serão considerados como novos projetos de desenvolvimento. Assim, será utilizada a fórmula de Projetos de Desenvolvimento do CPM 4.3. Observe que caso não exista mudança nas funções de dados, ou seja, o Banco de Dados da aplicação seja mantido, então as funções de dados não devem ser contadas. Outro ponto a ser observado são as fases contratadas, caso o projeto já possua documentação de requisitos, então a fase de requisitos não será contratada. Devem-se considerar apenas os percentuais das fases contratadas.

PF_REDESENVOLVIMENTO_LINGUAGEM = PF_INCLUÍDO + PF_CONVERSÃO

Este Roteiro recomenda a supressão do PF_CONVERSÃO da fórmula de contagem de Pontos de Função de Projetos de Redesenvolvimento quando for caracterizado um esforço relativamente maior dessa atividade, conforme descrito na seção 3.3.

4.11.2. Mudança de Plataforma - Banco de Dados

Nesta categoria encontram-se as demandas de redesenvolvimento de sistemas para utilizar outro sistema gerenciador de banco de dados.

Observe que caso não exista mudança nas funções de dados, ou seja, o banco de dados da aplicação seja mantido, então as funções de dados não devem ser contadas. No entanto, nesse caso, deve ser realizada a contagem das funções de dados a fim de compor a documentação da contagem final do projeto.

Em casos de mudança de banco hierárquico para relacional, em sistemas sem documentação, devido às mudanças envolvidas, deve-se considerar como um novo projeto de desenvolvimento, ou seja, as funções de dados e funções transacionais devem ser contadas. Assim, será utilizada a fórmula de projeto de desenvolvimento do CPM 4.3, conforme fórmula abaixo:

PF_REDESENVOLVIMENTO_BD_HIERÁRQUICO = PF_INCLUÍDO + PF_CONVERSÃO

Nos Projetos de Redesenvolvimento de Banco de Dados Hierárquico para Relacional, recomenda-se a supressão do PF_CONVERSÃO da fórmula acima, conforme descrito na Seção 3.3.

Caso o projeto já possua documentação de requisitos, então a fase de requisitos não deve ser contratada. É importante destacar que isso se aplica a qualquer fase que não se deseja contratar. Devem-se considerar apenas os percentuais das fases contratadas.

Caso a demanda de redesenvolvimento seja de um Sistema Gerenciador de Banco de Dados Relacional para outro Relacional, então deve ser utilizada a seguinte fórmula:

PF_REDESENVOLVIMENTO_BD_RELACIONAL = (PF_ALTERADO X 0,30) + PF_CONVERSÃO

O PF_ALTERADO deve considerar apenas as funcionalidades impactadas. As funcionalidades que possuem apenas demandas de testes devem ser contadas como Ponto de Função de Testes (Seção 4.13).

Nos Projetos de Redesenvolvimento de Banco de Dados Relacional para outro Relacional, recomenda-se tratar o PF_CONVERSÃO dentro do mesmo projeto.

Na mudança de banco relacional para relacional, geralmente a estrutura de dados não é alterada, desta forma não contamos as funções de dados.

4.12. Atualização de Versão

São consideradas nesta categoria, demandas para uma aplicação existente - ou parte de uma aplicação existente - executar em versões diferentes de browsers (ex: Internet Explorer, Firefox, Chrome, etc) ou de linguagens de programação (ex: versão mais atual do JAVA). Também são consideradas nesta categoria atualização de versão de banco de dados.

Nesta categoria foram observadas demandas de diferentes tipos de projetos, descritos nas próximas subseções.

Outro ponto a ser observado é a classificação, em alguns casos, dessas demandas como componente interno reusável (seção 4.15).

Recomenda-se enfaticamente a realização da análise de impacto das mudanças propostas para efeito de determinação do percentual adequado para aplicação sobre o total de pontos de função das funcionalidades impactadas. Por exemplo, em uma análise de impacto, pode ser identificado que não haverá mudanças no código-fonte ou em função transacional, sendo necessário somente testar o sistema, então deve-se utilizar um percentual contemplando apenas a fase de testes. No caso do teste apontar a necessidade de atualizar alguma função transacional, não deve ser contado o esforço do teste, mas sim o esforço abordado nesta seção, conforme as fórmulas apresentadas nas subseções seguintes.

4.12.1. Atualização de Versão – Linguagem de Programação

Nesta categoria encontram-se as demandas de atualização de versão de linguagem de programação de sistemas. As funções de dados não devem ser contadas. Estas demandas devem ser dimensionadas de acordo com a fórmula abaixo:

PF_ATUALIZAÇÃO_VERSÃO_LINGUAGEM = PF_ALTERADO X 0,30

O PF_ALTERADO deve considerar apenas as funcionalidades impactadas. As funcionalidades que possuem apenas demandas de testes, devem ser contadas usando o percentual da fase de testes (ver Tabela 7).

4.12.2. Atualização de Versão – Browser

Nesta categoria encontram-se as demandas de atualização de aplicações Web para executar em novas versões de um mesmo browser e para suportar a execução em mais de um browser. É importante destacar que este tipo de procedimento usualmente é realizado quando é necessário resolver algum problema de incompatibilidade. As funções de dados não devem ser contadas. Estas demandas devem ser dimensionadas de acordo com a fórmula abaixo.

PF_ATUALIZAÇÃO_VERSÃO_BROWSER = PF_ALTERADO x 0,30

O PF_ALTERADO deve considerar apenas as funcionalidades impactadas. As funcionalidades que possuem apenas demandas de testes devem ser contadas usando o percentual da fase de testes (ver Tabela 7).

Essas atualizações podem implicar em manutenções em componentes específicos da plataforma utilizada. Nesse caso, a demanda deve ser contada como componente interno reusável, descrita na seção 4.15 deste roteiro.

Recomenda-se enfaticamente a realização da análise de impacto das mudanças propostas para efeito de determinação do percentual adequado. Por exemplo, para sistemas que já atendem ao padrão W3C (World Wide Web Consortium) o esforço é menor, podendo usar, neste caso, um percentual diferente do citado acima. É importante ressaltar que os sistemas Web devem seguir o padrão W3C, como recomendado na e-Ping. Caso seja necessário fazer a adequação do sistema para atendimento ao padrão W3C, pode-se usar a fórmula acima.

4.12.3. Atualização de Versão – Banco de Dados

Nesta categoria encontram-se as demandas de atualização de versão do Sistema Gerenciador de Banco de Dados. As funções de dados não devem ser contadas. Estas demandas devem ser dimensionadas de acordo com a fórmula abaixo.

PF_ ATUALIZAÇÃO_VERSÃO_BD = PF_ALTERADO x 0,30

O PF_ALTERADO deve considerar apenas as funcionalidades impactadas. As funcionalidades que possuem apenas demandas de testes devem ser contadas usando o percentual da fase de testes (ver Tabela 7).

4.13. Apuração Especial

São funcionalidades executadas apenas uma vez para: corrigir problemas de dados incorretos na base de dados das aplicações; gerar relatórios específicos ou arquivos para usuários por meio de recuperação de informações nas bases da aplicação.

Caso a apuração seja de correção de dados, devido a erros de funcionalidades de aplicações desenvolvidas pela contratada, observar as cláusulas contratuais com relação a garantias e prazos de correção.

Recomenda-se fortemente ao Órgão contratante sempre solicitar formalmente para a empresa contratada o armazenamento do script para permitir posterior reexecução.

4.13.1. Apuração Especial – Base de Dados

Este tipo de apuração especial é um projeto que inclui a geração de procedimentos para atualização da base de dados. Deve-se destacar que estas funções são executadas apenas uma vez, não fazendo parte da aplicação, visando à correção de dados incorretos na base de dados da aplicação ou atualização em função de modificação da estrutura de dados, por exemplo, inclusão do indicador de matriz - sim ou não para um CNPJ. Nestes casos, considera-se a contagem de Pontos de Função das funcionalidades desenvolvidas. Geralmente, estas funcionalidades são classificadas como Entradas Externas. Nesse caso, como artefato de homologação da demanda, deve ser gerado um relatório para validação do usuário.

É importante ressaltar que as funções de dados associadas aos dados atualizados não

devem ser contadas, considerando que não há mudanças nas estruturas dos Arquivos Lógicos.

O tamanho em Pontos de Função da Apuração Especial em Base de Dados será calculado de acordo com a fórmula abaixo:

PF_APURAÇÃO_BD = PF_ALTERADO x 0,2

4.13.2. Apuração Especial – Geração de Relatórios

Este tipo de apuração especial é um projeto que inclui a geração de relatórios em uma ou mais mídias para o usuário. Em alguns casos, são solicitadas extrações de dados e envio dos dados para outros sistemas. Caso, neste envio de dados, sejam requisitadas atualizações no sistema de origem, então estas funções são Saídas Externas, devido à atualização do Arquivo Lógico Interno.

Deve-se destacar que estas funções são executadas apenas uma vez, não fazendo parte da aplicação. Nestes casos, considera-se contagem de Pontos de Função das funcionalidades desenvolvidas. Frequentemente, estas funcionalidades são classificadas como Saídas Externas. Também podem ser classificadas como Consultas Externas, caso não possuam cálculos ou criação de dados derivados.

É importante ressaltar que as funções de dados associadas aos dados atualizados não

devem ser contadas, considerando que não há mudanças nas estruturas dos Arquivos Lógicos.

PF_APURAÇÃO_RELATÓRIOS = PF_INCLUÍDO x 0,2

4.13.3. Apuração Especial – Reexecução

Em alguns casos, a empresa contratante pode ter interesse em executar uma apuração especial mais de uma vez. Nestes casos, ela deve solicitar formalmente à contratada o armazenamento do script executado. Desta forma, se for solicitada a reexecução de uma

apuração especial, esta deve ser dimensionada com a aplicação de um fator redutor de 10% na contagem de pontos de função da apuração especial em questão, da seguinte maneira:

PF_REEXECUÇÃO_APURAÇÃO = PF_NÃO_AJUSTADO x 0,10

4.14. Atualização de Dados

Em alguns casos, as demandas de correção de problemas em base de dados estão associadas a atualizações manuais (de forma interativa), diretamente no banco de dados em um único registro, e que não envolvem cálculos ou procedimentos complexos. São exemplos desse tipo de demanda, a atualização do valor de um campo de uma tabela cadastrado erroneamente ou a exclusão de um registro de uma tabela.

Nestes casos, a aferição do tamanho em Pontos de Função deve considerar 10% do PF de uma Entrada Externa e os Tipos de Dados da Entrada Externa são todos os TD considerados na funcionalidade - campos atualizados e campos utilizados para a seleção do registro.

PF_ATUALIZAÇÃO_BD = PF_INCLUÍDO x 0,10

Deve-se ressaltar que neste tipo de demanda não há gestão de configuração (armazenamento de script, versionamento, etc) das atualizações. Caso a contratante identifique a necessidade de realização de gestão de configuração das atualizações no banco de dados, então a demanda será classificada como Apuração Especial - Base de Dados.

4.15. Verificação de Erros

São consideradas verificações de erro ou análise e solução de problemas, 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 erro de sistema, a demanda será atendida como manutenção corretiva.

Entretanto, uma vez não constatado o problema apontado pelo cliente ou o mesmo for decorrente de regras de negócio implementadas ou utilização incorreta das funcionalidades, será realizada a aferição do tamanho em Pontos de Função das funcionalidades verificadas que o cliente reportou erro de acordo com as fórmulas abaixo:

Caso não exista documentação de testes disponível dessas funcionalidades verificadas, será considerado 20% do tamanho funcional dessas funcionalidades com solicitação de análise pelo órgão contratante, segundo a fórmula abaixo:

PF_VERIFICAÇÃO = PF_Funcionalidade_Reportada_Com_Erro x 0,20

Caso exista documentação de testes das funcionalidades verificadas, então serão considerados 15% (mesmo percentual da fase de Testes, conforme Tabela 7) do tamanho funcional das funcionalidades analisadas, segundo a fórmula abaixo:

PF_VERIFICAÇÃO = PF_Funcionalidade_Reportada_Com_Erro x 0,15

É importante ressaltar que a demanda de verificação de erros deve ser associada a uma funcionalidade específica. Os casos de sistema fora do ar por conta de problemas em rede ou banco de dados devem ser tratados como serviços de suporte e não de Fábrica de Software. Esses serviços de suporte não fazem parte do escopo desse Roteiro de métricas, não se aplicando Verificação de Erros nestes casos.

4.16. Pontos de Função de Teste

Muitas vezes, em projetos de manutenção, o conjunto de funções transacionais a serem testadas é maior do que a quantidade de funções a serem implementadas, isto é, além das funcionalidades que são afetadas diretamente pelo projeto de manutenção, outras precisam ser testadas [NESMA, 2009]. O tamanho das funções a serem apenas testadas deve ser aferido em Pontos de Função de Teste (PFT). Não considerar as funcionalidades incluídas, alteradas ou excluídas do projeto de manutenção na contagem de Pontos de Função de Teste.

A contagem de PFT será o somatório dos tamanhos em Pontos de Função das funções transacionais envolvidas no teste:

PFT = Somatório dos Tamanhos das Funções Transacionais Testadas

A conversão do PFT em Ponto de Função deve ser feita de acordo com a fórmula abaixo:

PF_TESTES = PFT x 0,15

É importante ressaltar que no caso de uma função ser testada várias vezes, com cenários diferentes, a função só pode ser contada uma vez. Outra observação é que as funções testadas, consideradas no PFT, devem ser documentadas pela contratada considerando-se a documentação de testes definida no processo de desenvolvimento da contratante. Observe que estas funções farão parte do escopo do projeto de manutenção.

5. Orientações Complementares para Contagem

Este capítulo tem como propósito apresentar as diretrizes de contagem de pontos de função em relação ao tema Múltiplas Xxxxxx, cuja abordagem é reconhecida pelo IFPUG. As definições apresentadas têm como base o artigo “Considerations for Counting with Multiple Media” Release 1.1 publicado pelo IFPUG [IFPUG, 2010a].

5.1. Contagem de Pontos de Função com Múltiplas Mídias

A contagem de PF de funcionalidades entregues em mais de uma mídia, na aplicação das regras de contagem de pontos de função definidas no CPM, tem levado a duas abordagens alternativas, a saber: single instance e multiple instance.

É importante enfatizar que o IFPUG reconhece ambas abordagens, single instance e multiple instance, para a aplicação das regras definidas no CPM. A determinação da contagem de PF seguindo a abordagem multiple instance ou single instance depende da avaliação do Escritório de Métricas da instituição.

As estimativas e contagens de PF abordadas neste documento são baseadas em multiple instance, com exceção dos casos de consultas em .pdf, .doc, .xls e consultas idênticas em tela e papel, que serão consideradas uma única funcionalidade.

A seguir são descritos os termos comuns definidos pelo IFPUG [IFPUG, 2010a]:

• Canal: também se refere à mídia. Múltiplos canais é sinônimo de múltiplas mídias.

• Mídia: descreve a maneira como os dados ou informações se movimentam para dentro e para fora de uma fronteira de aplicação, por exemplo, apresentação de dados em tela, impressora, arquivo, voz. Este termo é utilizado para incluir, dentre outros, diferentes plataformas técnicas e formatos de arquivos como diferentes mídias.

• Múltiplas Mídias: quando a mesma funcionalidade é entregue em mais de uma mídia. Frequentemente, apenas uma mídia é requisitada para um usuário específico em um determinado momento, por exemplo, consulta de extrato bancário via Internet como oposto a consulta de extrato bancário via terminal do banco.

• Multi-Mídia: quando mais de uma mídia é necessária para entregar a funcionalidade, por exemplo, uma nova notícia publicada na Internet que é apresentada em vídeo e texto. Observe que a notícia completa só é apresentada para o usuário se ele ler o texto e assistir o vídeo.

• Abordagem Single Instance: esta abordagem não reconhece que a mídia utilizada na entrega da função transacional é uma característica de diferenciação na identificação da unicidade da função transacional. Se duas funções entregam a mesma funcionalidade usando mídias diferentes, elas são consideradas a mesma funcionalidade em uma contagem de pontos de função.

• Abordagem Multiple Instance: esta abordagem especifica que o tamanho funcional é obtido no contexto do objetivo da contagem, permitindo uma função de negócio ser reconhecida no contexto das mídias que são requisitadas para que a funcionalidade seja entregue. A abordagem multiple instance reconhece que a mídia para entrega constitui uma característica de diferenciação na identificação da unicidade da função transacional.

Os cenários descritos nas seções seguintes não representam uma lista completa de situações de múltiplas mídias. O entendimento dos exemplos a seguir facilitará o entendimento de outros cenários envolvendo múltiplas mídias.

Este roteiro deve ser atualizado considerando a publicação de novas diretrizes do IFPUG e novos cenários que emergirão nas contagens de PF de projetos dos órgãos e entidades do SISP.

5.1.1. Cenário 1: Mesmos dados apresentados em tela e impressos

Neste cenário, uma aplicação apresenta uma informação em uma consulta em tela. A mesma informação pode ser impressa, caso requisitado pelo usuário, na tela em questão.

Nesses casos, sugere-se a abordagem single instance, considerando que dados idênticos sendo apresentados em tela e em relatório impresso devem ser contados como uma única função. Caso as lógicas de processamento da consulta em tela e do relatório em papel sejam distintas, o processo elementar não é único e, portanto, a funcionalidade será contada duas vezes (multiple instance). Neste caso, duas funções são contadas: apresentação de dados em tela e apresentação de dados impressos.

5.1.2. Cenário 2: Mesmos dados de saída como dados em arquivo e relatório impresso

Uma aplicação grava dados em um arquivo de saída e imprime um relatório com informações idênticas às gravadas no arquivo.

Nesses casos, sugere-se a utilização da abordagem single instance considerando que os dados impressos e os dados apresentados no arquivo de saída sejam idênticos e que a ferramenta de desenvolvimento apoie a geração dessas múltiplas saídas. Assim, apenas uma funcionalidade será incluída na contagem de pontos de função. Caso as lógicas de processamento da geração do arquivo de saída e do relatório em papel sejam distintas, o processo elementar não é único e, portanto, a funcionalidade será contada duas vezes. Além disso, se a geração das múltiplas saídas não seguir o padrão da ferramenta de desenvolvimento e tiverem que ser customizadas para o cliente, então será utilizada a abordagem multiple instance.

5.1.3. Cenário 3: Mesmos dados de entrada batch e on-line

Uma informação pode ser carregada na aplicação por meio de dois métodos arquivo batch e entrada on-line. O processamento do arquivo batch executa validações durante o processamento, da mesma forma que o processamento da entrada on-line também executa validações das informações. Neste caso, sugere-se a utilização da abordagem multiple instance, que conta duas funcionalidades: a entrada de dados batch e a entrada de dados on-line. Geralmente, a lógica de processamento utilizada nas validações em modo batch é diferente da lógica de processamento das validações nas entradas de dados on-line.

5.1.4. Cenário 4: Múltiplos canais de entrega da mesma funcionalidade

Uma funcionalidade deve ser disponibilizada em múltiplos canais, por exemplo: consulta de dados em página Web e consulta de dados no telefone celular. Neste caso, sugere-se a abordagem multiple instance, que conta duas funcionalidades: consulta de dados na Web e consulta de dados via celular.

Considera-se que a funcionalidade é desenvolvida duas vezes, uma para cada canal de saída. Algumas vezes, são até projetos de desenvolvimento distintos, um projeto relativo ao sistema Web e outro para o sistema via celular. Lembrando que caso o projeto seja claro o suficiente para dizer que o desenvolvimento é o mesmo, poderá ser utilizada a abordagem single instance.

5.1.5. Cenário 5: Relatórios em Múltiplos Formatos

Um relatório deve ser entregue em diferentes formatos, por exemplo: um arquivo html e um arquivo com valores separados por vírgula (.csv).

Nestes casos, conforme sugerido na abordagem multiple instance, considera-se a ferramenta utilizada na geração dos relatórios. Se a equipe de desenvolvimento precisar desenvolver o relatório nos dois formatos na ferramenta em questão, serão contadas duas funcionalidades. No entanto, se a ferramenta de desenvolvimento suportar um gerador de relatórios que o usuário visualize o relatório em tela e o gerador permita ao usuário imprimir o relatório, salvar em html ou salvar no formato de valores separados por vírgula, então se contará apenas uma vez, observando que a funcionalidade será da ferramenta e não da aplicação.

6. Considerações Especiais para Planejamento e Acompanhamento de Projetos

Este capítulo tem como propósito apresentar diretrizes para o planejamento e acompanhamento de projetos com o auxílio da métrica Ponto de Função e de técnicas relacionadas. Com base nesta finalidade é descrito um processo de estimativas de projetos de software aderente à área de processo de Planejamento de Projeto do CMMI (Capability Maturity Model Integration). Nesse contexto, são apresentados: o método Contagem Estimativa de Pontos de Função (CEPF) para estimar o tamanho dos projetos de software em PF, o modelo simplificado de estimativas para estimar o esforço dos projetos em homem-hora (HH) e a fórmula de Capers Jones para estimar os prazos dos projetos. Também são apresentadas recomendações para o gerenciamento de: mudanças de requisitos, projetos cancelados e progresso de projetos, e considerações sobre redução de cronograma e fator de criticidade de solicitação de serviços.

6.1. Diretrizes para Planejamento: Estimativas de Projetos de Software

Esta seção define métodos para Estimativas de Projetos de Software. A Figura 2 ilustra um processo de Estimativas de Projetos de Software, descrito nos parágrafos seguintes.

Figura 2: Processo de Estimativas de Projetos de Software [Hazan, 2008]

O principal insumo (artefato de entrada) para um processo de estimativas é o documento de requisitos. Como as estimativas devem ser realizadas no início do processo de desenvolvimento de software, então, o artefato utilizado é um documento inicial de requisitos, por exemplo: Documento de Visão ou Formalização Simples de Requisitos. O estimador deve analisar os requisitos para garantir a qualidade e então estimar o tamanho do projeto de software. O próximo passo é a derivação das estimativas de esforço, prazo (cronograma), custo (orçamento) com base na estimativa de tamanho e nos dados históricos de projetos concluídos da organização, assim como o estabelecimento da estimativa de recursos computacionais críticos e dos recursos da equipe a ser alocada ao projeto. Neste ponto, as principais estimativas foram geradas e precisam ser documentadas. As premissas e suposições utilizadas na geração das estimativas, dentre outras: complexidade do projeto, plataforma de desenvolvimento, tipo do projeto, percentual de evolução de requisitos, também devem ser documentadas [Hazan, 2008].

A realização das estimativas por um analista de métricas que não atue na equipe do projeto constitui uma prática recomendada. O analista de métricas deve analisar também a consistência da documentação utilizada na estimativa. No decorrer do processo de desenvolvimento, as estimativas devem ser acompanhadas conforme o refinamento dos requisitos. O projeto deve ser reestimado após a fase de requisitos, quando for gerada a especificação de casos de uso, e sempre que ocorrerem mudanças significativas nos requisitos funcionais ou não funcionais. Quando o projeto é concluído, deve-se aferir e documentar o tamanho, prazo, custo, esforço e recursos realizados, assim como outros atributos relevantes do projeto, visando à coleta de dados para a melhoria do processo de estimativas. As lições aprendidas também devem ser documentadas [Hazan, 2008].

Portanto, para os contratos de projetos de software, baseados na métrica Pontos de Função, as estimativas devem ser realizadas em três marcos do processo de desenvolvimento de software, a saber:

• Estimativa inicial: realizada após o fechamento do escopo do projeto. Geralmente é baseada em um documento inicial de requisitos, por exemplo, Documento de Visão. Constitui uma boa prática a previsão de evolução de requisitos, especialmente em projetos de desenvolvimento de médio ou grande porte.

• Contagem de Pontos de Função de Referência: realizada após o aceite dos requisitos. Geralmente, leva em consideração a Especificação dos Casos de Uso e Regras de Negócio da aplicação.

• Contagem de Pontos de Função Final: realizada após a homologação da aplicação. Esta contagem leva em consideração as funcionalidades efetivamente entregues para o usuário pela aplicação.

Para fins de faturamento, que é realizado durante o desenvolvimento, deve-se considerar a Contagem de Referência e posteriormente considerar os ajustes no faturamento após a Contagem Final. É importante ressaltar que as mudanças de requisitos também serão consideradas no tamanho do projeto a ser faturado. Além disso, se estas mudanças forem significativas, maiores que a evolução de requisitos (scope creep) prevista na estimativa inicial, o prazo do projeto deve ser reestimado. Toda mudança de requisito deve passar por uma análise de impacto entre contratante e contratada.

As subseções seguintes apresentam os métodos de estimativas de tamanho, prazo, custo e esforço a serem utilizados nos projetos de software em contratos.

6.1.1. Contagem Estimativa de Pontos de Função (CEPF)

Antes de definir o método de estimativas – Contagem Estimativa de Pontos de Função (CEPF) - é importante destacar que “estimar significa utilizar o mínimo de tempo e esforço para se obter um valor aproximado dos Pontos de Função do projeto de software investigado” [Meli, 1999]. Assim, é recomendável sempre fazer uma distinção entre os termos e conceitos: Contagem de Pontos de Função e Estimativa de Pontos de Função.

• Contagem de Pontos de Função: significa medir o tamanho do software por meio do uso das regras de contagem do IFPUG [IFPUG, 2010];

• Estimativa de Pontos de Função: significa fornecer uma avaliação aproximada do tamanho de um software utilizando métodos diferentes da Contagem de Pontos de Função do IFPUG.

O método CEPF visa aferir o tamanho em PF de maneira simplificada, com base no conhecimento dos requisitos iniciais do projeto. Inicialmente, os requisitos funcionais iniciais documentados nas propostas comerciais, nos documentos de visão, formalização simples de requisitos ou em qualquer especificação inicial do sistema do usuário são mapeados nos tipos funcionais da Análise de Pontos de Função: Arquivo Lógico Interno (ALI), Arquivo de Interface Externa (AIE), Entrada Externa (EE), Consulta Externa (CE) e Saída Externa (SE) (Figura 1). Posteriormente, os Pontos de Função são associados a cada função identificada, baseando-se nas tabelas de complexidade e de contribuição funcional do CPM (Tabela 1).

O estimador deve realizar uma leitura no documento inicial de requisitos, buscando informações relevantes para a identificação de processos elementares. O processo elementar é definido como a menor unidade de atividade significativa para o usuário. O processo elementar deve ser completo em si mesmo, independente e deixar a aplicação em um estado consistente [IFPUG, 2010]. Em outras palavras, os processos elementares são funções transacionais independentes, isto é, funções sequenciais pertencem a um mesmo processo elementar e funções independentes constituem processos elementares diferentes.

Figura 3: Modelo Lógico da Análise de Pontos de Função

Uma vez identificado o processo elementar, o estimador deve buscar o entendimento deste para classificá-lo em Entrada Externa, Consulta Externa ou Saída Externa. Adicionalmente, o estimador deve descobrir os dados associados ao processo elementar, visando à determinação da complexidade funcional da função identificada. Caso não seja possível a identificação da complexidade da funcionalidade em questão, recomenda-se a utilização da complexidade Média. Na análise do processo elementar também são identificados os grupos de dados lógicos da aplicação, que são classificados como Arquivos Lógicos Internos ou Arquivos de Interface Externa. Caso não seja possível a identificação da complexidade da função de dados em questão, recomenda-se a utilização da complexidade Baixa. É importante ressaltar que se o estimador identificar mais de um Registro Lógico no Arquivo Lógico Interno recomenda-se utilizar a complexidade Média.

A seguir são apresentadas dicas para ajudar no mapeamento dos requisitos funcionais da aplicação nos tipos funcionais da APF. As necessidades e funcionalidades especificadas para o projeto, contidas no documento inicial de requisitos, devem ser enquadradas em uma das seguintes tabelas:

Tabela 2 - Contagem dos Arquivos Lógicos Internos (ALIs): Banco de Dados Lógico da Aplicação (tabelas e arquivos mantidos pela aplicação).

Considerações: Identifique os grupos de dados lógicos de aplicação nos modelos de dados ou diagrama de classes ou a partir dos requisitos funcionais, descritos nos documentos de requisitos (Documento de Visão, Relação de Casos de Uso, etc.). Não considere arquivos físicos, arquivos de índices, arquivos de trabalho e tabelas de relacionamento sem atributos próprios (tabelas que existem para quebrar o relacionamento m x n e apenas transportam as chaves estrangeiras). As entidades fracas também não são consideradas um ALI. Se possível, tente descobrir os atributos lógicos, campos reconhecidos pelo usuário, e subgrupos de dados existentes para obter a complexidade funcional, segundo as regras de contagem do CPM. Caso não seja possível, a experiência tem mostrado que a maioria dos ALIs dos sistemas são de complexidade Baixa.

N° ALIs Baixa:	X 7 PF
N° ALIs Média:	X 10 PF
N° ALIs Alta:	X 15 PF
Total PF:

Tabela 2: Identificação dos Arquivos Lógicos Internos da Aplicação

Tabela 3 - Contagem de Arquivos de Interface Externa (AIEs): Banco de Dados de outras Aplicações, apenas referenciados pela aplicação que está sendo estimada (tabelas e arquivos mantidos por outra aplicação).

Considerações: Identifique os grupos de dados lógicos de outras aplicações referenciados pela aplicação que está sendo estimada. Frequentemente, o referenciamento de dados ocorre para a validação de informações em cadastros ou consultas. Algumas vezes, relatórios ou consultas referenciam dados externos de outras aplicações, também considerados AIEs. Não são considerados arquivos físicos, arquivos de índice, arquivos de trabalho, tabelas de relacionamento sem atributos próprios e entidades fracas. Geralmente, os AIEs dos sistemas possuem a classificação de complexidade Baixa, porque são considerados para a determinação da complexidade funcional do AIE apenas os atributos referenciados pela aplicação que está sendo contada.

N° AIEs Baixa:	X 5 PF
N° AIEs Média:	X 7 PF
N° AIEs Alta:	X 10 PF
Total PF:

Tabela 3: Identificação dos Arquivos de Interface Externa da Aplicação

Tabela 4 - Contagem de Entradas Externas (EEs): Funcionalidades que mantêm os Arquivos Lógicos Internos (ALIs) ou alteram o comportamento da aplicação.

Considerações: Identifique as funcionalidades de manutenção de dados. Conte separadamente a inclusão, alteração e exclusão de dados, isto é, cada função independente de inclusão ou alteração ou exclusão deve ser contada separadamente. A aplicação possui funções de entrada de dados que alteram o comportamento dela, por exemplo: processamentos batch, ou processamento de informações de controle? Caso positivo, estas funções também devem ser identificadas como Entradas Externas.

Se você não possui conhecimento sobre o processo elementar (funcionalidade analisada), considere as Entradas Externas identificadas com complexidade Média.

N° EEs Baixa:	X 3 PF
N° EEs Média:	X 4 PF
N° EEs Alta:	X 6 PF
Total PF:

Tabela 4: Identificação das Entradas Externas da Aplicação

Tabela 5 - Contagem de Consultas Externas (CEs): funcionalidades que apresentam informações para o usuário sem a utilização de cálculos ou algoritmos. São os processos elementares do tipo “lê - imprime”, “lê - apresenta dados”, incluindo consultas, relatórios, geração de arquivos pdf, xls, downloads, entre outros.

Considerações: Você está desenvolvendo uma função para apresentar informações para o usuário: uma consulta, relatório, listbox, download, geração de um arquivo, geração de arquivo pdf, xls? Esta função não possui cálculos ou algoritmos para derivação dos dados referenciados nem altera um Arquivo Lógico Interno, nem muda o comportamento do sistema? Caso positivo, estas funções devem ser identificadas como Consultas Externas. Se você não possui conhecimento sobre o processo elementar (funcionalidade analisada), considere as Consultas Externas com complexidade Média.

N° CEs Baixa:	X 3 PF
N° CEs Média:	X 4 PF
N° CEs Alta:	X 6 PF
Total PF:

Tabela 5: Identificação das Consultas Externas da Aplicação

Tabela 6 - Contagem de Saídas Externas (SEs): Funcionalidades que apresentam informações para o usuário com utilização de cálculos ou algoritmos para derivação de dados ou atualização de Arquivos Lógicos Internos ou mudança de comportamento da aplicação. São as consultas ou relatórios com totalização de dados, relatórios estatísticos, gráficos, geração de arquivos com atualização log, downloads com cálculo de percentual, entre outros.

Considerações: Você está desenvolvendo uma funcionalidade para apresentar informações para o usuário: uma consulta ou relatório com totalização de dados, etiquetas de código de barras, gráficos, relatórios estatísticos, download com percentual calculado, geração de arquivo com atualização de log? Caso positivo, estas funções devem ser identificadas como Saídas Externas. Observe que esta função deve ter cálculos ou algoritmos para processar os dados referenciados nos arquivos lógicos ou atualizar campos (normalmente indicadores) nos arquivos ou mudar o comportamento da aplicação. Caso não haja conhecimento da aplicação de APF ou sobre o processo elementar (funcionalidade analisada), considere as Saídas Externas com complexidade Média.

N° SEs Baixa:	X 4 PF
N° SEs Média:	X 5 PF
N° SEs Alta:	X 7 PF
Total PF:

Tabela 6: Identificação das Saídas Externas da Aplicação

A Estimativa de tamanho do projeto em PF deve ser gerada totalizando-se os PF obtidos nas Tabelas 2, 3, 4, 5 e 6.

A fórmula de contagem ou de estimativa de Pontos de Função para Projetos de Desenvolvimento é a seguinte:

PF_DESENVOLVIMENTO = PF_INCLUIDO + PF_CONVERSÃO

Este Roteiro recomenda a supressão do PF_CONVERSÃO das fórmulas de contagem de Pontos de Função de Projetos de Desenvolvimento, conforme descrito na Seção 3.3.

6.1.2. Estimativa de Esforço de Projetos de Software

Uma vez que o tamanho do projeto está estimado em Pontos de Função, o próximo passo é estimar o esforço de desenvolvimento do projeto, bem como sua distribuição pelas fases do ciclo de vida do desenvolvimento do software. A Engenharia de Software possui vários modelos para estimar esforço de projetos de software, baseados em Pontos de Função, sendo o Modelo Simplificado de Estimativas [Vazquez, 2010] e o Modelo COCOMO II [Xxxxx, 2009] os mais utilizados. Neste Roteiro é adotado o modelo Simplificado de Estimativas.

O Modelo Simplificado de Estimativas consiste em obter um índice de produtividade em horas/PF para o projeto específico em questão, e então multiplicar o tamanho em PF do Projeto pelo índice de produtividade, conforme a fórmula [Xxxxxxx, 2010]:

Esforço (horas) = Tamanho (PF) x Índice de Produtividade (HH/PF)

O índice de produtividade depende de diversos atributos dos projetos, dentre outros: plataforma tecnológica, complexidade do domínio, segurança, desempenho, usabilidade, tamanho do projeto, tipo de manutenção, desenvolvimento de componentes.

6.1.2.1. Distribuição de Esforço por Fase de Projeto

O próximo passo é a definição da distribuição de esforço pelas macro atividades do projeto, visando definir o valor agregado ao projeto após cada fase do ciclo de vida (Tabela 7).

Fases do Processo de Desenvolvimento de Software	Percentual de Esforço (%)
ENGENHARIA DE REQUISITOS	25%
DESIGN, ARQUITETURA	10%
IMPLEMENTAÇÃO	40%
TESTES	15%
HOMOLOGAÇÃO	5%
IMPLANTAÇÃO	5%

Tabela 7: Distribuição de Esforço por Macro Atividades do Projeto

6.1.2.2. Artefatos entregues por fase de projeto

Estão listados abaixo os artefatos a serem entregues (criados ou atualizados conforme o caso) em cada fase de projeto relativos a funcionalidades novas ou existentes. Os artefatos poderão ou não ser solicitados pela contratante de acordo com o tipo e/ou complexidade da demanda. Em casos excepcionais poderão ser pedidos artefatos não presentes na lista abaixo.

ENGENHARIA DE REQUISITOS

- Análise de Viabilidade

- Estimativa Inicial de Tamanho em PF

- Documento de Visão

- Especificação de Requisitos

- Documento de Regras de Negócio

- Casos de Uso

- Protótipo de Interface

DESIGN e ARQUITETURA

- Especificação de Arquitetura e Design

- Modelo de Dados / Entidade-Relacionamento

- Dicionário de Dados

- Diagramas UML (ênfase nos diagramas de classe e de sequência)

- Lista, para autorização da CVM, com versões de software e componentes de terceiros a serem utilizados no desenvolvimento.

IMPLEMENTAÇÃO

- Componentes/Módulos implementados

- Casos de Testes Unitários

- Documentação das classes/módulos do sistema (padrão Javadoc)

- Documentação de Build

TESTES

- Plano de Testes

- Casos de Testes

- Scripts de Testes

- Registro de Testes (resultados e evidências)

HOMOLOGAÇÃO

- Atualização do ambiente de Homologação com a solução

desenvolvida

IMPLANTAÇÃO

- Manual do Usuário

- Manual do Sistema

- Plano de Implantação

6.1.3. Alocação de Equipe ao Projeto

Na alocação de equipe, deve ser considerada a estimativa de prazo e a de esforço. Sugere- se utilizar a fórmula seguinte:

Equipe = Esforço (HH) / (21 x prod. diária x Prazo)

Onde:

Prazo = Td em meses

Prod. Diária = 6h/dia ou 7h/dia (recomenda-se considerar 6 horas/dia)

21 = dias úteis contidos em 1 mês

O tamanho da equipe é obtido em quantidade de recursos para o desenvolvimento do projeto e deve-se considerar percentuais de alocação. Por exemplo, suponha uma Equipe de 2,2 recursos. Esta equipe pode conter 5 pessoas, sendo que 4 pessoas com 50% de alocação e um líder de projeto com 20% de alocação ao projeto.

6.1.4. Método para Estimativa de Custo

A estimativa de custo do projeto deve levar em consideração o custo de um ponto de função. A contratada já deverá considerar o custo da hora de todos os profissionais envolvidos no desenvolvimento da solução de software. O cálculo do custo do projeto (CP) será então da seguinte forma:

CP = QPF x CPF

Onde:

QPF = Tamanho do Projeto em PF

CPF = Custo para implementar um Ponto de Função na plataforma em questão

6.1.5. Estimativa de Recursos Computacionais

A Estimativa de Recursos Computacionais também deve ser considerada, esta constitui um componente importante para as estimativas de custos dos projetos. Um recurso computacional é um hardware que se precisa adquirir; ou que se possui, mas precisa-se configurar. Exemplos de recursos computacionais incluem, dentre outros: espaço em disco para o sistema entrar em produção, um servidor específico para teste ou homologação do sistema. Devem ser registradas as seguintes informações associadas aos recursos computacionais críticos:

• Nome do Recurso Computacional: [considere exclusivamente hardware: micro, periférico, expansão de memória, área em disco, banda de rede, etc.]

• Descrição:

• Responsável pela Disponibilização:

• Data Limite:

• Parâmetros: [características do recurso: quantidade, perfil, configuração, etc.]

• Tipo do Recurso: [D: recurso para ambiente de Desenvolvimento; P: recurso para ambiente de Produção; H: recurso para ambiente de Homologação]

• Custo (Opcional): [Custo do recurso computacional. Não considerar custos de processamento ou custos operacionais de produção]

Caso o projeto a ser desenvolvido não possua nenhum recurso computacional crítico, deve ser registrado no documento de estimativas que o projeto não possui nenhum recurso computacional crítico.

6.2. Diretrizes para Acompanhamento de Projetos

Esta seção apresenta considerações especiais sobre o gerenciamento de mudança de requisitos, projetos cancelados, progresso de projetos, assim como o tratamento de redução de cronograma e fator criticidade.

6.2.1. Considerações sobre Mudança de Requisitos

Em projetos de desenvolvimento e de manutenção de software é bastante observada a mudança de requisitos anterior à implantação do projeto, conforme o usuário e o desenvolvedor adquirem mais conhecimento sobre as necessidades e funcionalidades de negócio [Sommerville, 2007]. O CPM denomina este fenômeno de Scope Creep.

Nas estimativas iniciais de tamanho de projetos de desenvolvimento, após a fase de especificação, considerando-se o documento de visão inicial do projeto, recomenda-se utilizar um percentual de 30% a 40% para evolução de requisitos. Este percentual é sugerido, ficando a critério da instituição estabelecê-lo contratualmente. Por exemplo suponha que após a análise do

documento de visão de um projeto, aplicando-se a CEPF foi obtido o tamanho de 200 PF, então o tamanho estimado desse projeto é de 270 PF

(200 + 35%), utilizando-se a premissa de evolução de requisitos em 35%. Esta premissa do projeto deve ser documentada. Nas estimativas, após a fase de requisitos, utilizando se como insumo as especificações de casos de uso, deve-se considerar um percentual de 20% a 30% para evolução de requisitos.

Por exemplo, suponha que após a análise do Documento de Visão de um Projeto, aplicando-se a CEPF, foi obtido o tamanho de 200 PF, então o tamanho estimado do projeto considerado é de 270 PF (200 + 35%), utilizando-se a premissa de evolução de requisitos em 35%. Esta premissa deve ser documentada.

Uma mudança de requisito gera retrabalho da equipe de desenvolvimento, aumentando assim o esforço e o custo do projeto. Por exemplo, suponha um relatório de clientes em que no final da fase de implementação foi solicitada a exibição de uma nova informação. A equipe de desenvolvimento terá um retrabalho de várias fases do ciclo de vida. Para tratar o dimensionamento das mudanças de requisitos torna-se importante definir a distribuição de esforço pelas macroatividades do projeto, visando definir o valor agregado ao projeto após cada fase do ciclo de vida.

A Tabela 7 estabelece os percentuais por atividade de forma a permitir a contagem de mudança conforme o estágio do projeto. Esta distribuição percentual de esforço deve ser definida no contrato de software.

As mudanças de requisitos serão contadas observando-se o tipo da mudança na funcionalidade formalmente aprovada do projeto, a saber:

• Incluída: o usuário identificou um novo requisito funcional para o projeto em questão. Estas funcionalidades não geram retrabalho, devem ser contadas como as demais funcionalidades do projeto em questão.

PF_Inclusão_Requisito = PF_INCLUIDO

• Alterada: o usuário identificou mudanças em um requisito funcional formalmente aprovado do projeto. Esta mudança gera retrabalho para a equipe de desenvolvimento. A contagem de Pontos de Função do requisito original deve ser realizada considerando as fases do ciclo de vida do projeto que já foram realizadas. A contagem de Pontos de Função do requisito alterado deve ser realizada considerando um Fator de Impacto de 50%.

PF_Alteração_Requisito = PF_Req_Original x (∑%Fases Realizadas) + (PF_Req_Alterado x 0.5)

• Cancelada: o usuário solicitou cancelamento da construção de um requisito funcional formalmente aprovado. A contagem de Pontos de Função do requisito original deve ser realizada considerando as fases do ciclo de vida do projeto que já foram realizadas.

PF_Cancelamento_Requisito = PF_Req_Original x (∑%Fases Realizadas)

• Excluída: o usuário solicitou exclusão de um requisito funcional formalmente aprovado do projeto. A exclusão gera retrabalho para a exclusão do requisito em desenvolvimento no projeto. A contagem de Pontos de Função do requisito excluído deve ser realizada considerando as fases do ciclo de vida do projeto que já foram realizadas e ainda deve ser contada atividade de retirada do requisito do projeto, considerando-se um fator de impacto de 10% da contagem de Pontos de Função do requisito excluído levando-se em conta as fases que já foram realizadas.

PF_Exclusão_Requisito = PF_Realizado + (PF_Retirado x 0.10) Onde,

PF_Realizado = PF_Original x (∑%Fases)

PF_Retirado = PF_Original x (∑%Fases)

Apresentamos alguns exemplos para ilustrar a contagem de casos de mudança de requisitos:

Exemplo 1: Requisito Alterado

Suponha um relatório de clientes em que no final da fase de implementação foi solicitada a exibição de uma nova informação. Assim, o tamanho dessa mudança deve ser calculado da seguinte maneira:

-Tamanho do relatório de clientes (original) – SE – M – 5 PF

-Tamanho do relatório de clientes (alterado) – SE – M – 5 PF

Para o requisito original será considerado o seguinte:

• Engenharia de Requisitos: 20%

• Design, Arquitetura: 10%

• Implementação: 35%

Assim, o tamanho do requisito original é de 3,25 PF (5 PF x 65%). Para o requisito alterado será considerado o Fator de Impacto de 50%, assim, o tamanho do requisito alterado é de 2,5 PF (5 PF x 50%). Então, a remuneração da contratada será de 5,75 PF (3,25 PF requisito original + 2,5 PF requisito alterado).

Exemplo 2: Requisito Cancelado

Suponha uma consulta de cursos em que no final da fase de implementação foi solicitado o cancelamento do requisito. Assim, o tamanho dessa mudança deve ser calculado da seguinte maneira:

-Tamanho da consulta de cursos (original): CE – M – 4 PF

Para o requisito original será considerado o seguinte:

• Engenharia de Requisitos: 20%

• Design, Arquitetura: 10%

• Implementação: 35%

Assim, o tamanho do requisito cancelado é de 2,6 PF (4 PF x 65%).

Exemplo 3: Requisito Excluído

Suponha um gráfico de percentual de cursos realizados por tema em que no final da fase de implementação foi solicitada a exclusão do requisito. Assim, o tamanho dessa mudança deve ser calculado da seguinte maneira:

-Tamanho do gráfico de cursos (original): SE – B – 4 PF Para o requisito original será considerado o seguinte:

• Engenharia de Requisitos: 20%

• Design, Arquitetura: 10%

• Implementação: 35%

Assim, o tamanho do requisito já realizado é de 2,6 PF (4 PF x 65%). E, o tamanho da retirada do requisito da baseline do projeto é de 0,26 PF (4 PF x 65% x 10%). Portanto, a remuneração da contratada deverá ser de 2,86 PF (2,6 PF + 0,26 PF).

Caso o Órgão contratante deseje apenas suspender a construção do requisito, este deve ser tratado como requisito cancelado e não excluído. Nesse caso, se o requisito fosse cancelado, a remuneração da contratada seria de 2,6 PF. Recomenda-se uma análise cuidadosa do requisito em questão antes da solicitação de exclusão.

6.2.2. Considerações sobre Projetos Cancelados

Em alguns casos, devido a mudanças no ambiente da contratante, uma demanda ou parte de um projeto de desenvolvimento ou manutenção pode ser cancelado a critério da contratante. Nestes casos, o tamanho funcional das funcionalidades canceladas será aferido por meio da contagem de Pontos de Função das funcionalidades canceladas e um Fator de Impacto.

O Fator de Impacto é definido com base no percentual de esforço alocado à construção da funcionalidade em questão, observando a Tabela 7 de distribuição de esforço ou alguma diretriz específica de distribuição de esforço do contrato em questão. O Fator de Impacto deve ser aplicado na contagem de Pontos de Função das funcionalidades em questão. É importante ressaltar que em um processo de desenvolvimento incremental uma funcionalidade pode, por exemplo, estar em fase de requisitos e de testes, porque o plano de testes é construído na fase de requisitos. O progresso das atividades executadas em cada funcionalidade do projeto deve ser obtido por meio do acompanhamento do plano do projeto.

6.2.3. Gerenciamento de Progresso de Projetos

O acompanhamento do projeto deve identificar o progresso de cada requisito do projeto, ou seja, o percentual de conclusão de cada fase do processo de software para o requisito em questão.

A apuração do percentual concluído em cada fase deve ser definida em comum acordo entre o Órgão contratante e a empresa contratada de acordo com os artefatos entregues em cada fase. O cálculo de PF do requisito original deve considerar o tamanho funcional do requisito.

Segue um exemplo de acompanhamento do progresso do Desenvolvimento do Sistema de Gestão de Projetos:

Requisito

Tamanho

Engenharia

de Requisitos

Design, Arquitetura

Implementação

Testes

Homologação

Implantação

Caso de Uso 1

- Incluir Ativ.

- Alterar Ativ

- Excluir Ativ

- Consultar Ativ

19 PF

50%

20%

10%

Caso de Uso 2

- Relatório de Projetos

5 PF

100 %

100%

50%

20%

No exemplo, supondo a mudança de Requisitos no Caso de Uso 2, inclusão de uma nova informação para ser apresentada no Relatório, a contagem de PF do requisito original é a seguinte:

Caso de Uso 2 – Relatório de Projetos – 5 PF

Macro Atividades	Esforço da Fase	Tamanho	Esforço realizado	Tamanho realizado
Engenharia de Requisitos	20%	1 PF	100%	1 PF
Design, Arquitetura	10%	0,5 PF	100%	0,5 PF
Implementação	35%	1,75 PF	50%	0,875 PF
Testes	15%	0,75 PF	20%	0,15 PF
Homologação	10%	0,5 PF	0%	0 PF
Implantação	10%	0,5 PF	0%	0 PF
Total:				2,525 PFs

O requisito alterado será considerado 100% do PF, supondo que este será entregue ao cliente sem passar por novas alterações. O tamanho da mudança de requisitos do requisito original é de 2,525 PF. Portanto, o tamanho total deste requisito considerando a mudança é de 7,525 PFs (5 PF requisito original + 2,525 PF requisito alterado).

6.2.4. Considerações sobre Redução de Cronograma

As estimativas de prazo não são lineares com o tamanho do projeto, assim pretende-se pesquisar mais sobre o melhor tempo de desenvolvimento (onde há uma melhor relação custo x benefício de alocação de recursos e menor prazo de desenvolvimento), dado o tamanho de um projeto específico. Xxxxx [Xxxxx, 2007] propõe uma fórmula para o cálculo do melhor tempo de desenvolvimento, descrita na seção 6.1.3.

Alguns projetos devido à legislação e a outros fatores externos já se iniciam com um prazo imposto. Se este prazo for igual ou superior ao prazo calculado pela Fórmula de Capers Jones (expoente t) ou em caso de projetos pequenos (menores que 100 PF) a um prazo calculado considerando o trabalho da equipe de 7 horas/dia nos dias úteis, então este é tratado como um projeto normal.

No entanto, se o projeto tiver um prazo imposto inferior ao prazo calculado, então pode- se considerar a seguinte proposta como uma sugestão de valores:

• Redução de prazo de 10%: aumento de esforço de 20% (projetos urgentes)

• Redução de prazo de 20%: aumento de esforço de 50% (projetos críticos)

• Redução de prazo de 25%: aumento de esforço de 70% (projetos de alta criticidade)

Os valores acima devem ser avaliados e definidos a critério do órgão, caso esse cenário possa ocorrer durante o contrato.

Deve-se ressaltar que não é possível uma redução de prazo maior que 25%, devido aos cálculos de Região Impossível e ainda, conforme nos aproximamos da Região Impossível, o esforço e o custo do projeto aumentam de maneira exponencial.

Como os riscos da redução de cronograma também são altos, não é recomendada a redução de cronograma. Deve-se tentar priorizar funcionalidades trabalhando com o processo incremental.

Caso o contrato seja baseado em preço por Pontos de Função, este aumento de esforço será refletido na contagem de PF. Assim, um aumento de esforço de 20% implica em aumento de 20% no custo de PF; aumento de esforço de 50% implica em aumento de 50% no custo de PF; o aumento de esforço de 70% implica em aumento de 70% no custo de PF.

Não é recomendado o uso de redução de cronograma, podem-se utilizar processos incrementais de desenvolvimento e trabalhar com definição de prioridades. É importante ressaltar que estas questões devem ser definidas em cláusulas contratuais e devem ser consideradas no orçamento do contratante.

6.2.5. Fator de Criticidade de Solicitação de Serviço

Em função da criticidade e da necessidade de alocação de recursos extras para atendimento da demanda no prazo estipulado pelo cliente, será adotado um Fator de Criticidade de 1,35 (um vírgula trinta e cinco), que deverá ser multiplicado pelo tamanho funcional da demanda considerada crítica, de modo a remunerar adequadamente o aumento do esforço de atendimento. Este fator é considerado para demandas que devem ser atendidas em finais de semana, feriados e fora do horário comercial. Entende-se como horário comercial o horário de 08:00 às 18:00 h, horário de Brasília.

É importante ressaltar que estas questões devem ser definidas em cláusulas contratuais e devem ser consideradas no orçamento do contratante.

7. Atividades Sem Contagem de Pontos de Função

A) Deve-se ressaltar que o processo de desenvolvimento de soluções possui várias atividades que devem ser consideradas como um projeto separado, levando-se em conta as horas realizadas e que devem estar associadas a produtos contratados e entregáveis. São atividades nessa condição:

• Treinamentos em Tecnologia, Metodologias, Métricas, etc.: Encontram-se nesta categoria as demandas de treinamentos em linguagens de programação, ferramentas de gestão, processos, modelos da qualidade, métricas, etc. Estes serviços são executados por consultores da contratada, especialistas no assunto em questão. Assim, devem ser consideradas as horas de consultoria para preparação e execução do curso e o custo do deslocamento do instrutor, se for o caso.

• Desenvolvimento de Cursos para EaD: Encontram-se nesta categoria as demandas de desenvolvimento de um curso na modalidade de Ensino a Distância (EaD). Estas demandas devem ser remuneradas em horas.

• Mapeamento de Processos de Negócio: Encontram-se nesta categoria as demandas de elaboração de documentação contendo o mapeamento de processos de negócio de uma organização ou de parte de uma organização. Estes serviços são executados por consultores da contratada, especialistas em BPM (Business Process Modeling).

• Elaboração de Plano Diretor de Tecnologia da Informação (PDTI): Encontram-se nesta categoria demandas para elaboração de PDTIs para clientes. Estes serviços são executados por consultores da contratada, especialistas nas atividades associadas à elaboração de um PDTI.

• Definição de Processo de Desenvolvimento de Soluções: Encontram-se nesta categoria demandas para definição de Processos de Software, aderentes às melhores práticas do CMMI e IN04. Estes serviços são executados por consultores da contratada, especialistas nas atividades de processos de software e na customização da ferramenta para criação do site do processo.

B) Outros serviços prestados que também não possuem Pontos de Função associados são os seguintes:

• Administração de Dados: Este serviço requer uma equipe de administradores de dados (ADs) com um número de profissionais definido junto a contratante, dedicada para atender as demandas associadas à definição e manutenção do modelo de dados de negócio do cliente. Esta equipe fica disponível em horário comercial para atendimento das demandas. Assim, estes serviços não possuem contagem de PF associada. É importante ressaltar que as atividades de banco de dados associadas ao projeto de desenvolvimento ou de manutenção, por exemplo, preparação de ambiente (testes, homologação, implantação), desempenhadas pelos DBAs da equipe de desenvolvimento, já estão consideradas dentro do projeto de software, não cabendo cobrança adicional.

• Consultoria: Serviço de apoio destinado à análise de regras de negócio a serem implementadas em soluções de TI realizado por consultores especialistas da contratada. As demais modalidades de consultoria também podem ser enquadradas neste item, por exemplo, Consultoria em Métricas. Estas demandas não possuem contagem de PF associada.

C) Outras atividades contidas em um processo de software devem ser gerenciadas dentro do projeto de desenvolvimento ou de manutenção, no entanto o esforço deve ser considerado separadamente da estimativa de esforço derivado da contagem de Pontos de Função. Estas atividades também devem ser precificadas a parte. São elas:

• Treinamento para Implantação: São demandas de treinamentos sobre utilização do sistema a ser implantado para os gestores de solução do cliente e usuários. O esforço deste serviço deve ser considerado separadamente da estimativa de esforço derivada da contagem de PF. O preço deste serviço deve ser calculado, levando-se em conta o preço da hora dos consultores da contratada que estarão realizando atividades de preparação de treinamento e

de instrutoria. Em alguns casos, pode ocorrer também o deslocamento do instrutor, que também deve ser cobrado do contratante. Deve-se ressaltar que este treinamento para implantação pode ser definido na modalidade de EaD, sendo tratado como um projeto de treinamento a parte. O esforço deste é considerado dentro do projeto de EaD que não faz parte do projeto de desenvolvimento ou manutenção em questão.

ANEXO II - MODELO PARA APRESENTAÇÃO DA PROPOSTA PROCESSO DE COMPRAS Nº RJ-2014-2866

PREGÃO ELETRÔNICO Nº 9/2014

_______, ______ de de 20__

À Comissão de Valores Mobiliários – CVM

Prezados Senhores,

Apresentamos nossa Proposta de Preços n.º ___/___, referente ao Pregão Eletrônico n.º 9/2014, cujo objeto é a contratação de pessoa jurídica especializada na prestação de serviços em Tecnologia da Informação (TI), pelo prazo de 30 (trinta) meses, para desenvolvimento e manutenção de sistemas, conforme descrito, caracterizado e especificado no Edital do certame licitatório e em seus anexos.

EMPRESA:
ENDEREÇO:
NOME PARA CONTATO:	FONE:	FAX:
NOME DO BANCO:	Nº DO BANCO:
NOME DA AGÊNCIA:	Nº DA AGÊNCIA:	C.C Nº:
INSCRIÇÃO ESTADUAL:	CNPJ:

Declaramos que examinamos, conhecemos e nos submetemos a todas as condições contidas no Edital do Pregão Eletrônico n.º 9/2014, bem como verificamos todas as especificações nele contidas, não havendo qualquer discrepância nas informações e/ou documentos que dele fazem parte. Declaramos, ainda, que estamos cientes de todas as condições que possam de qualquer forma influir nos custos, assumindo total responsabilidade por erros ou omissões existentes nesta proposta, bem como qualquer despesa relativa à realização integral de seu objeto.

CARIMBO PADRONIZADO DO CNPJ

Assinatura

NOME: CARGO: RG:

CPF

ANEXO III - MODELO DE PLANILHA DE CUSTOS E FORMAÇÃO DE PREÇOS PROCESSO DE COMPRAS Nº RJ-2014-2866

PREGÃO ELETRÔNICO Nº 9/2014

Proposta de Preços n.º /

Item	Linguagem	Demanda Prevista (PF)	Preço Unitário (R$/PF)	Preço Total (R$)
Item	Linguagem	(A)	(B)	(C)=(A)*(B)
1	ASP Clássico, PHP e VB6	1.000
2	Delphi	3.000
3	Java	10.000
4	dotNet	3.000
5	OpenCMS	1.000
Preço Total Global

Valor Global por extenso:

Prazo de validade: (não inferior a 60 (sessenta) dias corridos, a contar da data de sua apresentação);

Composição dos preços: Nos preços propostos acima estão incluídos todas as despesas, tributos e demais encargos de qualquer natureza incidentes sobre o objeto deste Pregão.

Esta empresa declara estar ciente de que a apresentação da presente proposta implica na plena aceitação das condições estabelecidas no Edital e seus Anexos.

(Local e data)

(Assinatura do Representante Legal, com NOME COMPLETO)

OBSERVAÇÕES E FORMAS DE CÁLCULO:

1) A coluna de valor total de cada item refere-se ao somatório dos subitens a ele relacionados e representará o valor máximo mensal pago à Contratada, conforme demanda, para a prestação de serviços.

2) O Valor Global da Proposta deverá ser o somatório dos valores totais dos itens de 1 a 5.

3) Os quantitativos indicados na Planilha de Custos correspondem a uma estimativa de mensal de demanda pelos serviços, não se constituindo em qualquer compromisso futuro para a CVM.

Document Metadata

Table of Contents

COMISSÃO DE VALORES MOBILIÁRIOS PROCESSO DE COMPRAS Nº RJ-2014-2866 EDITAL DO PREGÃO ELETRÔNICO Nº 9/2014

Document Metadata