consulta pÚblica para metodologia de … · relatório final da consulta pública para a...

CONSULTA PÚBLICA PARA

METODOLOGIA DE AVALIAÇÃO DA CERTICS PARA SOFTWARE

RELATÓRIO FINAL

21/8/2012 A 12/12/2012

Relatório Final da Consulta Pública para a Metodologia de Avaliação da CERTICS para Software 2

Conteúdo

APRESENTAÇÃO ................................................................................................................................... 4

1. RESUMO EXECUTIVO ............................................................................................................... 5

2. PANORAMA DA CONSULTA PÚBLICA ....................................................................................... 7

2.1. OBJETIVOS E BREVE HISTÓRICO ..................................................................................................... 7

2.2. CARACTERIZAÇÃO DA PARTICIPAÇÃO ............................................................................................ 8

3. COMENTÁRIOS REFERENTES AOS PRINCÍPIOS DA METODOLOGIA CERTICS ......................... 10

3.1. CERTICS, COMPETITIVIDADE E DESENVOLVIMENTO NACIONAL ................................................. 10

3.2. CERTICS E P&D GLOBAL ............................................................................................................... 12

3.3. CERTICS E ADEQUAÇÃO ÀS MICRO E PEQUENAS EMPRESAS ...................................................... 13

3.4. CERTICS, SOFTWARE PÚBLICO E SOFTWARE LIVRE ..................................................................... 14

4. COMENTÁRIOS REFERENTES À METODOLOGIA CERTICS ...................................................... 16

4.1. PROPOSTAS ACEITAS DE MUDANÇA NA METODOLOGIA CERTICS ............................................... 16

4.2. PROPOSTAS NÃO ACEITAS DE MUDANÇA NA METODOLOGIA CERTICS ....................................... 21

5. OUTROS COMENTÁRIOS ........................................................................................................ 25

ANEXO I - AVISO DA AUDIÊNCIA PÚBLICA ......................................................................................... 26

ANEXO II – LISTAS DE PRESENÇA DAS AUDIÊNCIAS PÚBLICAS .......................................................... 28

ANEXO III - PRINCIPAIS ASSUNTOS TRATADOS NAS AUDIÊNCIAS PÚBLICAS ..................................... 29

ANEXO IV - LISTA DOS PARTICIPANTES DA CONSULTA PÚBLICA ....................................................... 31

ANEXO V – RESPOSTA À FRENTE NACIONAL DE TECNOLOGIA DA INFORMAÇÃO - FNTI .................. 33

ANEXO VI - RESPOSTA À ASSOCIAÇÃO BRASILEIRA DAS EMPRESAS DE TECNOLOGIA DA INFORMAÇÃO E

COMUNICAÇÃO – BRASSCOM ........................................................................................................... 43

ANEXO VII- PESQUISA COM PEQUENAS E MICRO EMPRESAS PARA ADEQUAÇÃO DA METODOLOGIA50

ANEXO VIII - CONTRIBUIÇÕES E QUESTIONAMENTOS NA ÍNTEGRA (MEMÓRIA) ............................. 58

a. MENSAGENS ENCAMINHADAS PARA O CANAL "CONSULTA PÚBLICA" ........................................... 58

ANEXO US Chamber ................................................................................................................................. 65

ANEXO BSA ............................................................................................................................................... 69

ANEXO ERICSSON ..................................................................................................................................... 75

ANEXO IBM .............................................................................................................................................. 79

ANEXO HP ................................................................................................................................................ 88

ANEXO CISCO ........................................................................................................................................... 92


ANEXO BRASSCOM................................................................................................................................. 100

ANEXO FNTI ............................................................................................................................................ 109

ANEXO VANZOLINI ................................................................................................................................. 154

ANEXO QUALCOMM .............................................................................................................................. 158

ANEXO CTI .............................................................................................................................................. 165

ANEXO JEITA........................................................................................................................................... 167

ANEXO DIGITAL EUROPE ........................................................................................................................ 172

ANEXO FÓTON ....................................................................................................................................... 198

Tabelas

Tabela 1 - Número de comentários de cada canal por tema e subtema ........................................................... 8

Tabela 2 - Participantes da Consulta Pública por tipo de organização .............................................................. 9

Tabela 3 - Distribuição geográfica dos participantes da Consulta Pública ........................................................ 9


APRESENTAÇÃO

O presente relatório tem por objetivo apresentar as contribuições recebidas nos 114 dias em que a Metodologia CERTICS da CERTICS para Software1 esteve sob Consulta Pública, assim como os respectivos encaminhamentos dados a elas. Este documento foi redigido pelo Grupo de Trabalho que elaborou a Metodologia CERTICS2. Para tanto, o documento é composto, primeiramente, por um Resumo Executivo, no qual é apresentada uma síntese dos principais resultados e das conclusões deste relatório.

No item 2 é apresentado um Panorama da Consulta Pública, composto por um breve histórico da realização dessa Consulta e por uma caracterização dos comentários recebidos, com informações a respeito do número de participantes, perfil institucional da participação e tipo de contribuição dada.

A partir daí, as contribuições recebidas pela Consulta Pública e seus respectivos encaminhamentos estão distribuídos em três partes.

No item 3 são apresentadas respostas aos questionamentos relacionados aos princípios da Metodologia CERTICS, tais como sua contribuição para o País, adequação da Metodologia ao modelo de desenvolvimento global, adequação da Metodologia para micro e pequenas empresas (MPEs) e para o Software Público e Software Livre.

No item 4 estão apresentadas as principais deliberações resultantes da Consulta Pública: os encaminhamentos dados para as contribuições que se referiam especificamente à Metodologia CERTICS. Apresenta ainda a deliberação dada pelo Grupo de Trabalho que elaborou a CERTICS para cada uma das sugestões de mudança, tanto na redação da Metodologia quanto em sua estrutura e conteúdo.

No item 5 é apresentado o encaminhamento dado a outros tipos de manifestações recebidas e que não se referem ao objeto da Consulta Pública (Metodologia CERTICS), tais como dúvidas gerais sobre o processo de Consulta Pública, procedimentos para certificação, custo de certificação, certificação de família de produtos, interesse em certificação imediata, elogios, entre outras.

São também apresentados documentos anexos que contêm: I) Aviso da Audiência Pública publicado no Diário Oficial da União (D.O.U.); II) Listas de presença das Audiências Públicas; III) Resumo dos principais pontos tratados nas Audiências; IV) Lista dos participantes da Consulta Pública; V) Resposta a contribuições e questionamentos da Frente Nacional de Tecnologia da Informação (FNTI); VI) Resposta a contribuições e questionamentos da Associação Brasileira das Empresas de Tecnologia da Informação e Comunicação Brasscom)3; VII) Pesquisa para verificação da aderência da Metodologia às micro e pequenas empresas4; VIII) Mensagens recebidas na Consulta Pública5.

1 Para fins desse documento, nos referiremos à Metodologia CERTICS da CERTICS para Software como Metodologia CERTICS ou

simplesmente CERTICS. 2 A Metodologia CERTICS foi desenvolvida durante 18 meses por uma equipe multidisciplinar sediada no Centro de Tecnologia da

Informação Renato Archer (CTI). Parte dessa equipe é formada por servidores do CTI Renato Archer e parte formada por profissionais da Fundação de Apoio à Capacitação em Tecnologia da Informação (Facti). 3 Foram elaboradas respostas específicas para as duas entidades – FNTI e Brasscom – que têm participado ativamente das

discussões em torno da Metodologia CERTICS. 4 Em virtude de alguns comentários recebidos durante a Consulta Pública, que se referiam à inadequação da Metodologia a micro e

pequenas empresas, foi realizada em dezembro de 2012 uma pesquisa com 49 microempresas localizadas nas cidades de Porto Alegre, Campinas, Ribeirão Preto, Florianópolis, Brasília, Rio de Janeiro e Campina Grande para verificação da aderência da Metodologia a elas. O resultado está no Anexo III e assegura que a Metodologia é aderente a micro e pequenas empresas e traz indicativos para adequações da Metodologia a fim de aumentar essa aderência. 5 No site http://www.certics.cti.gov.br foram disponibilizados dois canais de contato com o público. Um deles era exclusivo para

envio de contribuições para a Consulta Pública ([email protected]). O outro era destinado a dúvidas de atendimento em geral ([email protected]). Alguns participantes mandaram considerações que se referiam à Consulta

http://www.certics.cti.gov.br/

mailto:[email protected]

mailto:[email protected]?Subject=CERTICS%20-%20Contato


1. RESUMO EXECUTIVO

A Metodologia CERTICS para Software foi desenvolvida nos anos de 2011 e 2012, com o propósito de verificar se um software é resultante de desenvolvimento e inovação tecnológica realizados no País, por meio de requisitos e critérios. A princípio será utilizada para viabilizar margem de preferência em compras públicas, mas prevê-se também sua utilização como referência para mecanismos de fomento ou de estímulo ao setor de software no Brasil.

A construção da Metodologia CERTICS atende a um ordenamento jurídico, que principia na Política Nacional de Informática, relacionando tecnologia nacional, autonomia tecnológica e desenvolvimento nacional. O ambiente normativo é complementado em outubro de 1991 com a Lei nº 8.248/91, que dispôs sobre a capacitação e competitividade do setor de informática e automação, na qualidade de instrumento para a realização da Política Nacional de Informática, e estabeleceu preferência de compras para tecnologia desenvolvida no País. Essa preferência só foi reconhecida na Lei Geral de Compras Públicas, em 1993, atingindo sua forma atual em 2010, quando o último quadrante da estrutura da preferência em compras públicas foi estabelecido, por meio da Medida Provisória nº 495, depois Lei nº 12.349. Como resultado desta MP, foram incluídas margens de preferência geral (até 10%) e adicional (até 25%) para a consecução da obrigação do Estado de garantir o desenvolvimento nacional conforme disposto no Art. 3º, inciso II, da Constituição Federal.

A Metodologia CERTICS foi colocada em Consulta Pública no período de 20 de agosto a 12 de dezembro de 2012. Nesse período houve 4.686 visitas ao site da CERTICS (www.certics.cti.gov.br) e a página da CERTICS foi visualizada 18.922 vezes. Durante o período de Consulta Pública foram realizadas duas Audiências Públicas: uma em Brasília/DF, no dia 15 de setembro de 2012, e outra em Campinas/SP, no dia 22 de setembro de 2012.

No canal da Consulta Pública ([email protected]) foram recebidos 333 comentários (122 participantes e 91 instituições), posteriormente agrupados em 6 temas e 20 subtemas, que tratam dos seguintes assuntos:

1. Consulta Pública (prazo, próximos passos, etc.); 2. Certificação CERTICS (custo, documentos a submeter, etc.); 3. Avaliação (perfil dos avaliadores, etc.); 4. Uso da Certificação (uso nas compras públicas, etc.); 5. Metodologia CERTICS (propostas de melhorias, exclusões, etc.); 6. Comentários Gerais (elogios, desejo de certificar, etc.).

Alguns comentários não se relacionaram diretamente a pontos específicos da Metodologia CERTICS, mas foram questionamentos em relação aos princípios que embasam a Metodologia. Esses comentários foram tratados em quatro grandes temas, relacionados com a CERTICS: Competitividade e Desenvolvimento Nacional, P&D Global, Adequação às Micro e Pequenas Empresas (MPEs), Software Público e Software Livre. Nesses temas são esclarecidos pontos e comentários que colocavam dúvidas acerca do uso da CERTICS. Em resumo, conclui-se que:

A CERTICS atende a um ordenamento jurídico que busca o aumento da competitividade do setor de software no Brasil e a ampliação de sua inserção no mercado global por meio da ampliação da autonomia e da capacitação tecnológica, em conjunto com o fortalecimento econômico-financeiro e a potencialização da capacidade inovativa das empresas. A certificação CERTICS pretende

Pública para o canal de Atendimento. Esses comentários foram lidos e contabilizados contudo aqueles que se referiam a propostas de mudança na Metodologia (apenas 4 de 120) não foram considerados por não terem sido encaminhados pelo canal correto. As contribuições recebidas pelo Canal Atendimento não foram publicadas, assim como o nome dos remetentes, uma vez que o conteúdo do contato via Canal Atendimento não deveria ser público tal como o realizado pelo Canal Consulta Pública.




estimular e reforçar a geração de competências no Brasil, necessárias para absorver ou criar tecnologias inovadoras, promovendo assim a ampliação da base tecnológica do País e o fortalecimento das cadeias produtivas, em conformidade com os objetivos mais amplos do desenvolvimento nacional sustentável.

A aplicação da Metodologia CERTICS não é restritiva a empresas de capital transnacional, desde que estas contribuam com o País, formando aqui competências tais como as desenhadas na Metodologia.

A Metodologia CERTICS pressupõe que um dos elementos-chave para o desenvolvimento de competências, a partir de um centro de P&D, é que este tenha autonomia para avaliar e decidir quais direcionamentos técnicos um projeto de desenvolvimento de software deve ter, pois é esta capacidade de decisão e assunção de responsabilidades que promove a construção de capacidades de gerenciamento e entendimento mais aprofundado da tecnologia.

A expectativa de que as micro e pequenas empresas não teriam dificuldade em atender aos requisitos da Metodologia CERTICS foi verificada em pesquisa realizada nos meses de novembro e dezembro de 2012 com 35 micro e 14 pequenas empresas distribuídas pelas cinco regiões do Brasil. Foram feitas perguntas às empresas para verificar a capacidade de atendimento aos requisitos da Metodologia. As empresas participantes responderam que em média atendem a 75% dos requisitos exigidos pela Metodologia CERTICS. Como decorrência do resultado da pesquisa realizada, foram feitas modificações na Metodologia para ampliar este grau de atendimento dos requisitos.

Em princípio, não há a necessidade de um software público ou livre ser certificado CERTICS para ter direito à preferência na aquisição pública; essa preferência já é garantida pela Instrução Normativa nº 04, de 12 de novembro de 2010. Contudo, havendo ainda a expectativa de que algum software livre possa ser certificado, destaca-se que a Metodologia CERTICS contempla igualmente todos os tipos de licenciamento de software, desde que haja uma organização que detenha as competências exigidas para a certificação.

Uma parte importante dos comentários (35% do total) foi direcionada a propostas de melhoria e contribuições para a Metodologia CERTICS, principal objetivo da Consulta Pública. Essas propostas e o resultado da pesquisa com MPEs de software levaram a mudanças na Metodologia. Dentre as mudanças, destacam-se:

Eliminação de uma das áreas de competências: Gestão de Parcerias e Alianças, por se entender que esta não pode ser exigida no conjunto mínimo de áreas de competências, pois há dificuldades para o atendimento de seus resultados esperados, por pequenas e microempresas;

Redução do número de resultados esperados de 24 para 16, em parte pela eliminação da área de competências acima mencionada, em parte em função de aglutinação de resultados de modo a facilitar o entendimento da Metodologia, bem como sua aplicação;

Mudança na redação da descrição dos resultados esperados da Metodologia CERTICS para facilitar seu entendimento.

A versão atual da Metodologia está disponível em www.certics.cti.gov.br.


2. PANORAMA DA CONSULTA PÚBLICA

Este item apresenta um breve histórico da realização da Consulta Pública e uma caracterização dos comentários recebidos com informações a respeito do número de participantes, perfil institucional da participação e tipo de contribuição dado.

2.1. OBJETIVOS E BREVE HISTÓRICO

A Metodologia CERTICS para Software foi desenvolvida nos anos de 2011 e 2012, com o propósito de verificar se um software é resultante de desenvolvimento e inovação tecnológica realizados no País, por meio de requisitos e critérios. A princípio será utilizada para viabilizar margem de preferência em compras públicas, mas prevê-se também sua utilização como referência para mecanismos de fomento ou de estímulo ao setor de software no Brasil.

A Metodologia CERTICS para Software foi apresentada à sociedade para apreciação em uma Consulta Pública. O objetivo dessa Consulta foi colher contribuições e validar seus conceitos, estrutura lógica e corpo de conhecimentos, além de também dar ciência da construção dessa Metodologia à sociedade brasileira.

A Consulta foi iniciada no dia 20 de agosto de 2012 e anunciada publicamente durante o lançamento do "Programa Estratégico de Software e Serviços de TI" – TI Maior. A partir dessa data, a Metodologia foi disponibilizada em http://www.certics.cti.gov.br e passou a receber comentários e sugestões pelos endereços eletrônicos "[email protected]" e "[email protected]".

A Portaria n° 01, de 11 de setembro de 2012, do Ministério da Ciência, Tecnologia e Inovação (MCTI), formalizou o lançamento da Consulta Pública (incluindo duas Audiências Públicas). A portaria foi publicada no Diário Oficial da União no dia 14 de setembro de 2012 e está disponível em http://www.in.gov.br/visualiza/index.jsp?jornal=1&pagina=10&data=14/09/2012.

O encerramento da Consulta Pública estava previsto para o dia 29 de outubro de 2012 porém, para viabilizar um maior prazo para a participação, foi prorrogado para o dia 12 de dezembro de 2012. Dessa forma, as contribuições e sugestões acerca da Metodologia proposta puderam ser enviadas no prazo de 90 (noventa) dias a contar da data de publicação da Portaria de Convocação da Consulta Pública, para o seguinte e-mail: [email protected]. Nesse período houve 4.686 visitas e a página da CERTICS foi visualizada 18.922 vezes. No item 2.2. do presente documento é apresentada a caracterização dessa participação.

Durante o período de Consulta Pública foram realizadas duas Audiências Públicas: uma em Brasília/DF, no dia 15 de setembro de 2012, e outra em Campinas/SP, no dia 22 de setembro de 2012. A publicação do Aviso da Audiência pode ser visualizada no Anexo I. No Anexo II estão as listas de presença de ambas as audiências. No Anexo III estão listados os principais assuntos tratados em cada uma das audiências e que foram considerados nas reflexões para melhoria da Metodologia.


http://www.in.gov.br/visualiza/index.jsp?jornal=1&pagina=10&data=14/09/2012



2.2. CARACTERIZAÇÃO DA PARTICIPAÇÃO

As mensagens recebidas6 foram agrupadas por threads7, cada uma delas composta por um diferente número de comentários. Ao todo foram tratadas 77 threads no canal Consulta Pública e 78 threads no canal Atendimento, somando 333 comentários que foram agrupados em seis temas (Consulta Pública, Certificação, Avaliação, Uso da Certificação, Metodologia, Comentários Gerais) e 20 subtemas.

Tabela 1 - Número de comentários de cada canal por tema e subtema

TEMA SUBTEMA CANAL

TOTAL DE COMENTÁRIOS CONSULTA

PÚBLICA ATENDIMENTO

CONSULTA PÚBLICA

Dúvidas gerais (onde e como contribuir, prazo final, próximos passos, prorrogação, data e detalhamento das audiências, etc.)

33 28 61

CERTIFICAÇÃO

Processo de certificação (quando e como posso certificar um produto?)

20 31 51

Documentos a submeter (o que preciso ter?) 0 4 4

Custo (quanto custa certificar?) 3 10 13

Softwares/serviços certificáveis (o que posso certificar?) 8 3 11

Diferença entre CERTICS e outras certificações (MPS-Br, por exemplo)

4 3 7

Famílias de produtos (posso certificar família de produtos? como? qual o custo? quanto demora?)

3 8 11

Duração (quanto tempo dura a certificação?) 0 1 1

Evidências (tal documento é uma evidência?) 0 4 4

MPE e MEI (como uma microempresa pode atender às exigências da certificação?)

4 1 5

AVALIAÇÃO Perfil dos avaliadores/instituições avaliadoras 2 5 7

Processo de seleção de avaliadores/instituições avaliadoras 3 7 10

USO DA CERTIFICAÇÃO

Objetivo, importância e benefícios da certificação (por que devo certificar o produto?)

2 3 5

Exigência legal (é obrigatório certificar?) 1 1 2

Compras públicas (os compradores vão adotar a certificação? vai estar nos editais?)

0 1 1

METODOLOGIA Comentários a respeito da redação da Metodologia CERTICS 4 0 4

Comentários a respeito da Metodologia CERTICS 113 4 117

COMENTÁRIOS GERAIS

Intenção de certificação imediata 0 3 3

Elogios 10 5 15

Empresas se oferecendo para testar a certificação 0 1 1

TOTAL 210 123 333

Alguns comentários não se relacionam diretamente a pontos específicos da Metodologia CERTICS, mas são questionamentos em relação aos princípios utilizados que embasam a Metodologia. Tais apontamentos estão sendo respondidos no item 3 do presente documento – Comentários referentes aos princípios da Metodologia CERTICS.

6 Para fins de mensuração da participação no processo como um todo, foram contabilizadas todas as mensagens recebidas, tanto

no canal Consulta Pública quanto no canal Atendimento. 7 Uma thread é o agrupamento da sequência de mensagens de um mesmo destinatário e todas as respostas relacionadas a elas.

Quando o mesmo destinatário enviou mensagens em momentos diferentes, não relacionadas a uma sequência de mensagens já iniciada, considerou-se duas threads diferentes, porém um só participante.


Uma parte importante dos comentários (35% do total) está direcionada a propostas de melhoria e contribuições para a Metodologia CERTICS, principal objetivo da Consulta Pública. Todos esses comentários foram avaliados e são tratados detalhadamente no item 4 do presente documento – Comentários referentes à Metodologia CERTICS.

Houve ainda comentários que não se relacionam diretamente à Metodologia mas, sim, a dúvidas gerais sobre a Consulta Pública, procedimentos para certificação, elogios, etc. Esses comentários são tratados no item 5 – Outros comentários.

No Anexo IV estão listados os 72 participantes da Consulta Pública (remetentes) das 91 organizações que enviaram mensagens8 à Consulta Pública. Abaixo (Tabela 2) é apresentada a distribuição dos participantes por tipo de organização.

Tabela 2 - Participantes da Consulta Pública por tipo de organização

TIPO DE ORGANIZAÇÃO CONSULTA PÚBLICA ATENDIMENTO

Associações e outras entidades 12 1

Empresa de consultoria (jurídica, contábil, administrativa) 3 0

Empresa de consultoria (qualidade, processos, etc.) 2 0

Empresa de tecnologia (origem de capital nacional) 9 0

Empresa de tecnologia (origem de capital estrangeiro) 23 34

ICT 5 0

Órgão público 5 3

Pessoa física 10 16

TOTAL 69 54

Os participantes estão distribuídos geograficamente conforme tabela abaixo. Observa-se que, apesar de a maioria dos participantes estarem localizados na Região Sudeste, com destaque para o Estado de São Paulo, que foi responsável por 40% da participação, há representação das regiões Sul e Centro-Oeste na Consulta Pública (ambas com 16% da participação).

Além disso, as seguintes organizações internacionais participaram da Consulta: INTI Argentina, Digital Europe, Japan Electronics and Information Technology Industries Association (Jeita – Washington, DC Office) e Brazil-U.S. Business Council.

Tabela 3 - Distribuição geográfica dos participantes da Consulta Pública

REGIÃO PART. %

Sudeste 55%

Sul 16%

Centro-Oeste 16%

Nordeste 8%

Exterior (Argentina, Bélgica, EUA, Japão) 6%

Não identificada9 17%

8 Alguns participantes enviaram mais de uma mensagem e algumas pessoas físicas participaram sem indicar vínculo com alguma

organização. Esta listagem apresenta os participantes que enviaram mensagens apenas para o canal Consulta Pública. Já o número de organizações participantes de refere ao número total, incluindo tanto o Canal Consulta Pública quanto o Canal Atendimento. 9 As pessoas físicas não tiveram sua localização geográfica identificada.


Cabe destacar que em 15 casos as contribuições foram recebidas no formato de documentos anexos às mensagens dos remetentes10. As organizações que encaminharam suas manifestações neste formato foram: Brasscom, BSA, Cebeu, Cisco, CTI, Digital Europe, Ericsson, FNTI, Fóton, HP, IBM, ISPM11, Jeita, Qualcomm, Fundanção Vanzolini. Tais contribuições foram igualmente contabilizadas e distribuídas de acordo com o tema a que se referiam. Esses documentos podem ser encontrados no Anexo VIII, junto com todas as mensagens recebidas.

Os questionamentos da FNTI e da Brasscom, por tratar-se de um conjunto específico de propostas de melhorias, fruto de reflexões de associações de empresas brasileiras de software, foram tratados com destaque nos anexos V e VI. As respostas para as demais organizações, por apresentarem argumentos semelhantes e mais atinentes aos princípios da construção da Metodologia, encontram-se principalmente nos itens 3 e 4 deste documento.

3. COMENTÁRIOS REFERENTES AOS PRINCÍPIOS DA METODOLOGIA CERTICS

Neste item são apresentadas respostas aos questionamentos relacionados aos princípios que embasam a Metodologia CERTICS, tais como sua adequação ao modelo de desenvolvimento global da indústria de software, sua adequação a micro e pequenas empresas, tipos de software certificáveis (software público, software livre, etc.), entre outros.

3.1. CERTICS, COMPETITIVIDADE E DESENVOLVIMENTO NACIONAL

Alguns comentários recebidos na Consulta Pública apresentaram argumentos acerca de o uso da CERTICS levar a uma diminuição da competitividade do setor de software brasileiro. Argumenta-se que o desenvolvimento de tecnologia nacional levará a um atraso tecnológico do País e à redução da participação deste no mercado global de software, seja pela diminuição da presença, no Brasil, de elos produtivos da cadeia global de produção de software, seja pela redução do acesso às tecnologias de software mais inovadoras.

A construção da Metodologia CERTICS atende a um ordenamento jurídico, que principia na Política Nacional de Informática. O ambiente normativo que orienta a CERTICS teve início em 1984, quando foi editada a Lei nº 7.232/84, que estabeleceu a Política Nacional de Informática, no geral orientada a prover “capacitação nacional nas atividades de informática, em proveito do desenvolvimento social, cultural, político, tecnológico e econômico da sociedade brasileira”. Entre outras diretrizes a Política definiu o princípio do “direcionamento de todo o esforço nacional no setor, visando ao atendimento dos programas prioritários do desenvolvimento econômico e social e ao fortalecimento do Poder Nacional, em seus diversos campos de expressão”, assim como “fomento e proteção governamentais dirigidos ao desenvolvimento de tecnologia nacional e ao fortalecimento econômico-financeiro e comercial da empresa nacional, bem como estímulo à redução de custos dos produtos e serviços, assegurando-lhes maior competitividade internacional”.

Tais diretrizes da Política Nacional de Informática seguem vigentes e estão em consonância com o Art. 218 da Constituição Federal de 1988, que determina que o Estado “promoverá e incentivará o desenvolvimento

10

As tabelas apresentadas anteriormente já contabilizam os comentários feitos neste formato.

11 O Anexo da ISPM foi recebido pelo Canal Atendimento. Desta forma, suas contribuições foram avaliadas mas seu

conteúdo não foi tornado público.


científico, a pesquisa e a capacitação tecnológicas” e que a “lei apoiará e estimulará as empresas que invistam em pesquisa, criação de tecnologia adequada ao País”. O artigo seguinte (Art.219) determina que “o mercado interno integra o patrimônio nacional e será incentivado de modo a viabilizar o desenvolvimento cultural e socioeconômico, o bem-estar da população e a autonomia tecnológica do País, nos termos de Lei Federal” (grifo nosso).

O ambiente normativo é complementado com a Lei nº 8.248/91, de outubro de 1991, que dispôs sobre a capacitação e competitividade do setor de informática e automação, na qualidade de instrumento para a realização da Política Nacional de Informática. Em sua primeira redação esta Lei estabelecia a todas as esferas da Administração Pública, nas aquisições de bens e serviços de informática e automação, dar-se preferência a empresas brasileiras. Esta redação que foi aperfeiçoada em 2001 por meio da Lei nº 10.176, quando a preferência de compras foi disposta como critério de desempate em favor da origem nacional de bens e serviços, produzidos no País, por empresa brasileira e por empresas que invistam em pesquisa e desenvolvimento.

Essa preferência só foi reconhecida na Lei Geral de Compras Públicas (Lei nº 8666/93) em 2010, quando o último quadrante da estrutura da preferência em compras públicas foi estabelecido, por meio da Medida Provisória nº 495, depois Lei nº 12.349. Como resultado dessa MP, foram incluídas margens de preferência geral (até 10%) e adicional (até 25%) para as compras governamentais, para produtos e serviços resultantes de desenvolvimento e inovação tecnológica realizados no País, vinculando a aplicação dessas margens à promoção do desenvolvimento nacional sustentável.

Desse modo, o entorno normativo do “desenvolvimento nacional sustentável” incluído pela Lei nº 12.349/10, como acima apontado, estabelece não só o amparo legal para a presente Metodologia (CERTICS), mas também circunscreve o seu âmbito, na medida em que esta deve buscar dispor, como requisitos e critérios para a verificação do que sejam produtos e serviços resultantes de desenvolvimento e inovação realizados no País, aqueles que se demonstrem como efetivos contribuintes do desenvolvimento nacional sustentável.

Portanto, o Estado Brasileiro, como expresso no ordenamento jurídico anteriormente mencionado, busca o aumento da competitividade do setor de software no Brasil e a ampliação de sua inserção no mercado global por meio do aumento da autonomia e da capacitação tecnológica, em conjunto com o fortalecimento econômico-financeiro e a potencialização da capacidade inovativa das empresas.

A certificação CERTICS pretende estimular e reforçar a geração de competências no Brasil, necessárias para absorver ou criar tecnologias inovadoras, promovendo assim a ampliação da base tecnológica do País e o fortalecimento das cadeias produtivas, em conformidade com os objetivos mais amplos do desenvolvimento nacional sustentável. E o papel das compras governamentais, bem como outros estímulos governamentais que venham a ser estabelecidos, baseados na CERTICS, são fundamentais.

De fato, os países desenvolvidos e as respectivas empresas que hoje lideram o mercado global de software construíram esta posição como decorrência de um intenso investimento governamental, na forma de compras governamentais, nas décadas do pós-guerra. Esse investimento gerou ativos nesses países, que constituem barreiras de entrada aos novos empreendedores neste setor. A literatura especializada demonstra que, quando orientada na direção de soluções e produtos inovativos, a demanda pública tem um grande potencial de melhorar as políticas públicas e os serviços, e de gerar melhorias nas dinâmicas inovativas e nos benefícios associados a transbordamentos12.

12

Alguns autores defendem que a importância das compras públicas para as dinâmicas de inovação não se dá somente em função da garantia de demanda, mas também pela interação entre demanda e oferta, dada a possibilidade de organização do diálogo entre usuários, consumidores e outros afetados pela inovação para articular e comunicar as preferências e a demanda para o mercado (HIPPEL, 1976; MOWERY & ROSENBERG, 1979).


Outro argumento apresentado remete a um risco de isolamento da indústria brasileira de software, causado por um possível protecionismo que a CERTICS criaria. Deve-se aqui reforçar que a aplicação da Metodologia CERTICS não é restritiva ao capital transnacional, desde que este contribua com o País, formando aqui competências tais como as desenhadas na Metodologia.

Em outras palavras, empresas transnacionais que desenvolvem software também podem obter a certificação CERTICS, desde que comprovem a criação e manutenção de competências no País, conforme estabelecido na Metodologia.

3.2. CERTICS E P&D GLOBAL

Em complemento aos comentários do item anterior também foram feitas observações de que a CERTICS poderia inibir a instalação de centros de P&D globais no País, alegando que estes não teriam autonomia tecnológica perante o centro de decisão mundial da companhia, que há concorrência entre centros de P&D para atração de investimentos e que a CERTICS não contribuiria para reforçar a posição de empresas multinacionais aqui instaladas para a atração desses investimentos.

Há diversos instrumentos de políticas públicas brasileiras que têm por objetivo a atração de investimentos estrangeiros, particularmente atividades de P&D, entre os quais se destacam a Lei de Informática e a Lei do Bem, que podem ser usufruídos por transnacionais, como de fato acontece no Brasil.

O objetivo maior da CERTICS, como definido no item anterior, é estimular a geração de competências no País que contribuam para o desenvolvimento nacional. Num primeiro momento isso se dará por meio de margem de preferência em compras públicas. A CERTICS não considera a origem do capital um critério de exclusão, mas o quanto o desenvolvimento de determinado software contribui com o País, por meio da criação e retenção de competências em território nacional.

É senso comum que a indústria de software, dado o seu caráter de intangibilidade e pervasividade, é uma das mais globalizadas do mundo e que insumos básicos como sistemas operacionais, bancos de dados e outros compõem o conjunto de tecnologias básicas, hoje de propriedade de um conjunto pequeno de organizações multinacionais ou disponíveis com licenciamento livre. Portanto, o acesso a tecnologias estratégicas passa pela interação com grupos transfronteiriços. A CERTICS não restringe esta colaboração, mas espera-se que a tal colaboração contribua para o estabelecimento de bases de conhecimento nacionais. Em outras palavras, que sejam trazidas ou construídas no País capacidades de conhecimento na forma de competências. E a Metodologia CERTICS pressupõe que um dos elementos-chave é que a estrutura aqui construída, por exemplo um centro de P&D, tenha autonomia para avaliar e decidir quais direcionamentos técnicos um projeto de desenvolvimento de software deve ter, pois é esta capacidade de decisão e assunção de responsabilidades que promove a construção de capacidades de gerenciamento, entendimento mais aprofundado da Metodologia, etc. Sabe-se que um centro de P&D multinacional tem, neste sentido, autonomia restrita, mas é também comum nessas estruturas autonomia técnica para evolução do projeto de P&D. A literatura internacional dá conta de uma tendência de que, em função do aumento das competências e das capacidades tecnológicas das unidades de P&D descentralizadas, as empresas que antes exerciam um controle maior sobre seus centros de P&D passam a conceder a estes maior autonomia e autoridade, e desse modo, à medida que é designado a tais centros um papel mais


estratégico na rede de P&D, sua flexibilidade é aprimorada e desenvolve-se, ainda, maior capacidade criativa13.

Quanto ao software avaliado pela CERTICS ser concebido no País, a redação dos resultados esperados para maior alinhamento com os princípios da CERTICS foi revista a partir das contribuições obtidas na Consulta Pública. Ou seja, a Metodologia pressupõe que o software avaliado possa ter partes desenvolvidas fora do Brasil, entretanto as tecnologias mais relevantes do software devem ser conhecidas e dominadas pelos técnicos e especialistas aqui residentes. Por tecnologias relevantes entendem-se aquelas tecnologias presentes no software e que cumprem os seguintes critérios: 1) a tecnologia é parte significativa do valor de mercado do software; 2) a tecnologia promove um diferencial tecnológico ou de negócios para o software ante os concorrentes; 3) são técnicas que contribuem significativamente para a produção das funcionalidades que caracterizam o valor da utilidade do software.

Dominar tecnologias relevantes está diretamente associado a construir um conjunto de competências tecnológicas nessas tecnologias, ou seja, construir na organização um conjunto de conhecimentos e habilidades para criar ou modificar uma tecnologia em seus princípios ou funcionalidades. Na maioria das vezes, essa competência é demonstrada com a criação ou modificação dessas tecnologias na própria organização instalada no País.

3.3. CERTICS E ADEQUAÇÃO ÀS MICRO E PEQUENAS EMPRESAS

Durante a Consulta Pública foram recebidas algumas manifestações demonstrando preocupação com a dificuldade de micro e pequenas empresas (MPEs) em atenderem aos requisitos da Metodologia CERTICS para um determinado software desenvolvido por essas empresas. O argumento centrava-se na ideia de que a Metodologia exige evidências em um conjunto de resultados, que dificilmente poderá ser demonstrado pelas MPEs, em função do esforço e investimento percebidos como necessários para a obtenção desses resultados.

Entretanto, a capacidade de inovação de uma empresa tem maior relação com a cultura empresarial, com a qualificação de recursos humanos e com o modelo de negócio vinculado a atividades de P&D do que com volume e capacidade de investimento. O dinamismo tecnológico do setor de software se dá, majoritariamente, pela geração de inovações em MPEs. O perfil de empresa tecnologicamente inovadora pressupõe capacidades que foram exaustivamente estudadas na fase de desenho da Metodologia CERTICS.

A expectativa de que as MPEs não teriam dificuldade em atender aos requisitos da Metodologia CERTICS foi verificada em pesquisa realizada nos meses de novembro e dezembro de 2012 com 35 micro e 14 pequenas empresas distribuídas pelas cinco regiões do Brasil, em que foram feitas perguntas às empresas para verificar a capacidade de atendimento aos requisitos da Metodologia (Anexo VII).

13

Crescentemente as unidades de P&D estrangeiras têm sido consideradas fontes críticas de competências tecnológicas; a elas têm sido designadas novas tarefas, vitais para as estratégias e para o sucesso global das suas empresas, e esta ampliação de escopo tem demandado modelos mais eficientes de arranjos de gestão das redes globais de P&D. A eficiência é ampliada na medida em que a autonomia das unidades estrangeiras de P&D é suficiente para atender aos requisitos de processamento de informações necessários para desempenhar de forma efetiva as tarefas de P&D que lhes cabem. Isso requer que o grau de autonomia seja especificado de modo a cooperar com as características de tais tarefas e do ambiente organizacional em questão, levando em conta a interdependência de tarefas em relação à P&D global.


A pesquisa foi conduzida por consultores de mercado, com atuação junto a empresas de TI na região pesquisada, que não participaram das discussões da montagem da Metodologia. Os resultados obtidos estão resumidos a seguir:

- As empresas participantes responderam que em média atendem a 75% dos requisitos exigidos pela Metodologia CERTICS;

- Mais de 75% das empresas avaliaram que a linguagem e/ou terminologia utilizada na Metodologia CERTICS é adequada para definição/entendimento;

- Cerca de 65% das empresas julgaram que o grau de dificuldade para apresentar evidências aos requisitos exigidos pela Metodologia CERTICS é baixo ou médio.

Os requisitos mais difíceis de serem atendidos referem-se à Área de Competência Parcerias e Alianças, item que foi revisto na Metodologia CERTICS. O segundo item mencionado como maior grau em dificuldade de atendimento diz respeito a documentação do conhecimento e dados técnicos, carência esta que é uma realidade das empresas pequenas, mas importante de ser tratada na cultura das empresas.

O resultado da pesquisa também está disponível em www.certics.cti.org.br e demonstra a aplicabilidade da Metodologia CERTICS para MPEs.

3.4. CERTICS, SOFTWARE PÚBLICO E SOFTWARE LIVRE

Outro tema objeto de comentários encaminhados à Consulta Pública refere-se à aplicação da CERTICS em softwares públicos e softwares livres. É relevante destacar que a Instrução Normativa nº 04, de 12 de novembro de 2010, da Secretaria de Logística e Tecnologia da Informação (SLTI) do Ministério do Planejamento, Orçamento e Gestão (MPOG), estabelece que as demandas públicas por soluções de Tecnologia da Informação (TI) devem ser precedidas por busca a: i) soluções similares de outro órgão ou entidade da Administração Pública; ii) soluções do Portal do Software Público Brasileiro; e iii) alternativas do mercado, inclusive software livre.

Assim, antes de ser iniciado o procedimento licitatório para a realização da compra de um software, os Integrantes Técnicos e Requisitantes da solução devem verificar se há algum software público ou livre disponível que possa atender a demanda. Após essa etapa, não havendo tais soluções disponíveis, é iniciado o processo de licitação no qual o software certificado pela CERTICS poderá utilizar a margem de preferência na compra.

Dessa forma, em princípio, não há a necessidade de um software público ou livre ser certificado para ter direito à preferência na aquisição pública, uma vez que o reconhecimento de sua importância para o desenvolvimento e a inovação tecnológica já está legitimado pelo Ministério do Planejamento, Orçamento e Gestão (MPOG).

Contudo, havendo ainda a expectativa de que algum software livre deva ser certificado, destaca-se que a Metodologia CERTICS contempla igualmente todos os tipos de licenciamento de software, desde que haja uma organização que detenha as competências exigidas para a certificação.

Das quatro camadas hierárquicas que estruturam a Metodologia, as três primeiras – Conceito, Áreas de Competência e Resultados Esperados – são aplicáveis a qualquer software resultante de desenvolvimento e inovação tecnológica realizados no País. A quarta camada da Metodologia – Conjuntos de Orientações e Indicadores –, que orienta a interpretação dos Resultados Esperados e a identificação e análise de evidências para comprovar o atendimento desses resultados, necessitará de inclusões para melhor adequá-

http://www.certics.cti.org.br/


la ao modelo de software livre. Um avaliador utiliza essas orientações levando em consideração o modelo e a estratégia da empresa para o software em avaliação, como por exemplo relacionadas a software livre. Para facilitar a avaliação de software livre serão documentadas e inseridas orientações específicas na quarta camada da Metodologia.


4. COMENTÁRIOS REFERENTES À METODOLOGIA CERTICS

A seguir são apresentadas as propostas de mudança na Metodologia CERTICS e as deliberações tomadas pelo Grupo de Trabalho que elaborou a Metodologia CERTICS. As propostas e deliberações, com a justificativa para cada deliberação, estão agrupadas em dois itens. No item 4.1 estão apresentadas as propostas que foram aceitas. No item 4.2 estão apresentadas as propostas que não foram aceitas.

As propostas (tanto as aceitas quanto as não aceitas) estão agrupadas por assunto, sendo que o primeiro deles, Definições e Pressupostos, trata de sugestões da inclusão de definições de termos e do aperfeiçoamento na redação de alguns dos já descritos. Os demais assuntos estão distribuídos de acordo com a respectiva Área de Competência/Resultado Esperado a que se referem. Destaca-se que quando uma proposta foi "aceita" isso significou uma concordância com a sugestão ou o questionamento, que em alguns casos foi apenas parcial.

Algumas propostas apontavam conceitos que já eram considerados na Metodologia porém indicavam que o entendimento na leitura do texto da Metodologia não foi o esperado para determinado conceito. Nesses casos, em geral, foi entendido que o texto deveria ser revisto para melhorar a comunicação. Essas propostas foram consideradas aceitas e a deliberação menciona que a redação foi melhorada para comunicar melhor.

É importante ressaltar que a Metodologia prevê que os exemplos de tipos de evidências indicados na Metodologia servem como uma referência para ilustrar o que é desejável para o atendimento aos Resultados Esperados. Em outras palavras, a lista de evidências não é uma lista exaustiva de todas as possibilidades de atingimento dos Resultados Esperados.

Destaca-se também que, após a análise das contribuições recebidas na Consulta Pública, a Metodologia foi aprimorada em sua redação, tendo ocorrido mudanças também no número de Áreas de Competência14 e de Resultados Esperados e na inclusão/exclusão de evidências. As alterações de redação mais importantes são mencionadas no presente documento embora outras mais pontuais (ortográficas) também tenham ocorrido.

4.1. PROPOSTAS ACEITAS DE MUDANÇA NA METODOLOGIA CERTICS

Definições e Pressupostos

1. Questionamento sobre o conceito de autonomia tecnológica ser contrário à atração de centros de P&D internacionais e não permitir casos em que o software tenha sido desenvolvido em projetos internacionais. Deliberação: aceito; a redação foi revisada para comunicar melhor que a Metodologia prevê casos em que o software tenha sido desenvolvido em projetos globais, desde que a Unidade Organizacional demonstre autonomia tecnológica sobre as tecnologias relevantes presentes no software. Para mais detalhes ver item 3.2. deste Relatório.

2. Questionamento a respeito da necessidade de a empresa ter autonomia tecnológica sobre todo o software (inclusive ferramentas de desenvolvimento), sob argumento de que o desenvolvimento de parte do software também gera competências. Deliberação: aceito; a redação da definição do conceito de autonomia tecnológica foi revisada para destacar que a capacidade técnica e decisória exigida é sobre as tecnologias relevantes do software.

14

A Área de Competência Gestão de Parcerias e Alianças (GPA) foi excluída e alguns Resultados Esperados também.


3. Questionamento sobre exigência de que a Unidade Organizacional tenha um modelo de operação específico ou uma prática ideal de documentação. Deliberação: aceito; a redação dos princípios da Metodologia foi revisada para destacar que nenhuma forma específica de estruturação, operação e documentação da organização produtora do software é exigida. Os exemplos de tipos de evidências indicados na Metodologia servem como uma referência para ilustrar o que é desejável para o atendimento aos Resultados Esperados. Em outras palavras, a lista de evidências não é uma lista exaustiva de todas as possibilidades de atingimento dos Resultados Esperados.

4. Questionamento sobre o conceito de Unidade Organizacional, sob argumento de que o conceito não deixaria claro que o ambiente de desenvolvimento do software poderia ser multiprojetos, multiequipe e em múltiplas localidades. Deliberação: aceito; a redação do conceito de Unidade Organizacional foi revisada para comunicar melhor a possibilidade de desenvolvimento em ambiente multiprojetos, multiequipe e em múltiplas localidades, desde que as Competências geradas sejam verificadas na própria Unidade Organizacional por meio do atendimento aos Resultados Esperados exigidos pela Metodologia CERTICS.

5. Sugestão de explicitar o termo "software básico" entre as categorias de softwares certificáveis. Deliberação: aceita; a redação da Metodologia foi revisada para enfatizar a possibilidade de certificar esse tipo de software também.

6. Questionamento a respeito de qual tratamento será dado aos serviços na Metodologia (inclusive serviços de desenvolvimento). Deliberação: aceito; a redação da Metodologia foi revisada para evidenciar que o objeto da certificação é o software, não os serviços de desenvolvimento do software. Os serviços decorrentes do software certificado (por exemplo, aqueles comercializados como SaaS e serviços de manutenção corretiva) poderão se beneficiar da certificação, se forem fornecidos pela Unidade Organizacional detentora do software certificado.

7. Sugestão de que haja garantia de sigilo das informações exigidas na avaliação. Deliberação: aceita; essa garantia já estava prevista por meio de Termos de Confidencialidade assinados por todos os envolvidos no processo de certificação. A redação foi revisada para comunicar melhor essa garantia.

Área de Competência Desenvolvimento (Atual Área de Competência Desenvolvimento Tecnológico)

1. Questionamento sobre o que é considerado ciclo de vida. Deliberação: aceito; a redação da

definição da Área de Competência foi revisada. Nessa Área de Competência é tratada tanto a fase de desenvolvimento até a liberação para uso quanto à fase pós-entrega.

Área de Competência Desenvolvimento – Resultado Esperado DES.1 (Atual Área de Competência Desenvolvimento Tecnológico – Resultado Esperado DES.2)

1. Questionamento sobre a redação que trata da exigência de a concepção do software ter sua origem no País para garantir domínio do conhecimento necessário ao desenvolvimento do produto. Deliberação: aceito; a redação do Resultado Esperado DES.1 foi revisada enfatizando que o domínio do conhecimento nos requisitos deve estar no País, e não sua concepção.

2. Sugestão de trocar o termo "produto" por "software". Deliberação: aceita; foi realizada a troca do termo.

3. Sugestão de explicar melhor o que significa "os recursos humanos devem estar fixados no País". Deliberação: aceita; a redação do trecho em questão foi revisada para comunicar melhor que a Competência Tecnológica tem de estar no País, significando que há profissionais da Organização Solicitante, residentes no Brasil, capazes de desenvolver e atualizar os requisitos pertencentes às tecnologias relevantes do software e ter autonomia para tomar decisões sobre essas atualizações.


4. Sugestão de revisar a redação do exemplo de tipo de evidência "documentação de Conceitos Operacionais do Sistema, especificando as responsabilidades alocadas ao software". Deliberação: aceita; o exemplo de tipo de evidência em questão foi excluído.

5. Questionamento sobre a necessidade de uma análise de impacto para o exame do software como um artefato em si, em casos de mudança (manutenção ou evolução) do software. Deliberação: aceito; o trecho em questão deixou de ser uma exigência e passou a ser um exemplo de tipo de evidência.


1. Questionamento sobre o significado da expressão "fase de elaboração" e se o significado da palavra

"onde" se refere ao País ou à Unidade Organizacional (item "Orientações"). Deliberação: aceito; a expressão "fase de elaboração" foi substituída por "fase inicial" e a palavra "onde" foi excluída.


1. Sugestão de esclarecer melhor a expressão "não necessariamente", relacionada à geração de

competências por atividades de codificação e teste. Deliberação: aceita; a redação foi revisada para esclarecer que, nos casos em que a codificação e os testes geraram competência tecnológica, a empresa deve apresentar evidências das competências geradas. Um exemplo disso pode ser a introdução de uma inovação na forma da execução de teste do software que demandou atividades de P&D, como decorrência da criticidade da ausência de erros. Neste caso podem ser apresentados como evidência os desafios tecnológicos e os esforços e resultados de P&D para solucionar tais desafios.


1. Sugestão de incluir outros exemplos para o caso de o software não precisar da implantação, tais como open source e software baixado via web. Deliberação: aceita.

2. Sugestão de incluir a definição do termo "defeito". Deliberação: aceita; a definição do termo "defeito" foi incluída na metodologia.

3. Sugestão de substituir a expressão "incidências no software" por "defeitos no software". Deliberação: aceita; a redação do trecho em questão foi revisada.

Área de Competência Gestão da Tecnologia – Resultado Esperado TEC.1

1. Sugestão de incluir, no item "Orientações", o termo "um especialista" após "área responsável". Deliberação: aceita.

2. Sugestão de incluir a definição dos termos "Competência Tecnológica" e "Apropriação dos Resultados de Pesquisa e Desenvolvimento". Deliberação: aceita.

3. Sugestão de inclusão de indicadores sobre capacitação tecnológica nacional. Deliberação: aceita; os indicadores "investimento em P&D" (TEC.1) e "volume de renda gerada pela empresa através do uso de parceiros de negócio e canais de venda" (GNE.5) foram inseridos na Metodologia como exemplos de tipos de evidência.


Área de Competência Gestão da Tecnologia – Resultado Esperado TEC.3 (Atual Resultado Esperado TEC.2)

1. Sugestão de incluir explicação sobre o termo "monitoradas". Deliberação: aceita; o termo foi excluído.

2. Sugestão de revisão dos Resultados Esperados TEC.3 e TEC.5. para um melhor encadeamento de ações de identificação, apropriação e monitoramento das tecnologias relevantes e estratégicas para o software. Deliberação: aceita; os Resultados Esperados em questão foram revisados para atender ao melhor encadeamento.

3. Sugestão de incluir dois exemplos de tipos de evidência de que ocorrem ações voltadas para a apropriação do conhecimento tecnológico: existência de colaboradores certificados nas tecnologias-chave e participação da organização em fóruns nacionais e internacionais que visam à padronização das tecnologias relevantes. Deliberação: aceita; a redação do trecho em questão foi revisada para inclusão desses dois exemplos de tipos de evidência.

4. Sugestão de incluir a aderência a padrões internacionais (ITIL, FCAPS, etc.) como elemento de comprovação de competitividade global. Deliberação: aceita; a comprovação de aderência a padrões internacionais foi listada como um exemplo de evidência, mas não como um requisito.


1. Sugestão de inserir exemplos de evidências que contemplem a interação com desenvolvedores (fornecedores nacionais) especializados em módulos baseados em padrões abertos oriundos de tecnologia nacional ou estrangeira. Deliberação: aceita; entende-se que, quanto maior a disseminação de uma determinada tecnologia em padrões abertos, maior pode ser a contribuição para a ampliação do desenvolvimento tecnológico e da inovação do País. Neste sentido, se determinada Unidade Organizacional interage qualificadamente, ou seja, agregando valor, em comunidades virtuais ou junto a fornecedores, no sentido de disseminar e/ou absorver tecnologia e inovações tecnológicas, isso pode ser considerado uma evidência. Entretanto, essa evidência será verificada na própria Unidade Organizacional por meio de verificação de recursos humanos qualificados, sistematização do conhecimento e outros aspectos que tenham contribuído para a geração de uma inovação no software avaliado e será incluída na lista de exemplos de tipos de evidência.


1. Questionamento sobre as expressões "patente de software" e "atestado de propriedade". Deliberação: aceito; as expressões em questão foram excluídas da Metodologia.

2. Questionamento sobre a exigência de autonomia tecnológica a respeito das tecnologias relevantes e estratégicas presentes no software no caso do software livre. Deliberação: aceito; a redação foi revisada para melhor comunicar que a exigência de autonomia tecnológica requer a demonstração de que a organização que solicitou a certificação detenha duas capacidades fundamentais. A primeira diz respeito à habilidade técnica em promover alterações no software, a segunda diz respeito à liberdade jurídica de implementar tais alterações. Os programas de computador disponíveis sob as modalidades de licenças de uso de software livre não estão sujeitos a restrições


de alterações em características fundamentais de sua operação, já que o que caracteriza o regime do software livre é o respeito às quatro liberdades que alcançam o código fonte de tais aplicativos: a livre execução, a livre aprendizagem e uso para qualquer propósito, a livre re-distribuição e a livre modificação do software. Portanto, quando for aplicado a programa de computador disponível sob uma licença de software livre, a General Public License (GLP), a Metodologia CERTICS requererá a demonstração da criação e ampliação de competências na organização, que apontam que o software é resultante de desenvolvimento e inovação tecnológicos realizados no País. Para mais detalhes, ver item 3.3. deste Relatório.

3. Sugestão de que seja preservada a condição de autonomia tecnológica sobre as tecnologias relevantes que fizeram parte do desenvolvimento do software, mas que tenham sido substituídas por meio de aquisição de componente nacional ou importado. Deliberação: aceita; desde que a tecnologia não responda majoritariamente pelo diferencial competitivo e não esteja vinculada a maiores investimentos relacionados ao software. Caso contrário, só será possível preservar a condição de autonomia se a Unidade Organizacional demonstrar ter capacidade técnica e decisória para criar ou modificar a tecnologia adquirida em seus princípios ou funcionalidades. Deve-se ressaltar que isso será fruto de uma análise da equipe de avaliação. A redação foi revisada para comunicar melhor essa orientação.

Área de Competência Gestão de Negócios – Resultado Esperado GNE.4 (Atual Resultado Esperado GNE.3)

1. Questionamento sobre a diferença entre "instrumentos" e "ferramentas". Sugestão de incluir exemplos de instrumentos, além dos que já estão no texto. Deliberação: aceito; a redação do Resutado Esperado foi revisada. O termo "instrumentos" foi substituído pelo termo "ações" e essas ações, para serem realizadas, se utilizam de ferramentas.

Área de Competência Gestão de Pessoas, Processos e Conhecimento – Resultado Esperado PPC.1 (Atual Área de Competência Melhora Contínua – Resultado Esperado MEC.1)

1. Sugestão de inclusão de "aplicação de provas/testes para seleção dos colaboradores" como exemplo, na lista de exemplos de tipos de evidência. Deliberação: aceita; o exemplo foi incluído.


1. Sugestão de rever a redação deste Resultado Esperado para diminuir a subjetividade dos termos "eficiente" e "eficaz". Deliberação: aceita; a redação do Resultado Esperado em questão foi revisada e os termos foram excluídos.

2. Sugestão de inclusão da definição de "lexi loci executinis". Deliberação: o termo foi excluído do texto.


1. Questionamento sobre a necessidade de treinamento para o colaborador que já tem um perfil adequado. Deliberação: aceito; a redação foi revisada para comunicar melhor que não há


necessidade de todos os profissionais envolvidos no software receberem treinamento. A Unidade Organizacional deve avaliar a necessidade de treinamento desses profissionais.


1. Questionamento sobre o uso da expressão "atividades tecnológicas e correlatas" nesse Resultado Esperado, uma vez que nos demais Resultados Esperados a expressão não aparece. Deliberação: não aceito; a redação foi alterada para "atividades tecnológicas e de negócios".

2. Sugestão de inserir exemplos nas orientações do Resultado Esperado para explicar melhor a expressão "ações de modo informal". Deliberação: aceita; o texto foi revisado e foram inseridas orientações e exemplos para comunicar que as ações podem ser tanto formais quanto informais.

3. Sugestão para inclusão da expressão "Lições Aprendidas" na lista de exemplos de tipos de evidência. Deliberação: aceita; foi inserida como exemplo de tipo de evidência a expressão "Lições Aprendidas".

Área de Competência Gestão de Parcerias e Alianças – GPA (Área de Competência excluída)

A partir da análise da pesquisa com micro e pequenas empresas (Anexo VII) e de alguns questionamentos e sugestões de mudança recebidos na Consulta Pública, decidiu-se pela exclusão desta Área de Competência. Conclui-se que tal Área, no atual estágio de maturidade do setor de software no Brasil, não pode ser exigida no conjunto mínimo de Áreas de Competência, pois há dificuldades para o atendimento de seus Resultados Esperados, por pequenas e microempresas. Alguns dos Resultados Esperados dessa Área de Competência foram realocados como exemplos de evidências em outros Resultados Esperados, quando se julgou apropriado.

Abaixo seguem alguns dos questionamentos e das sugestões recebidos na Consulta Pública:

1. Sugestão de rever critérios para aplicação da Área de Competência Gestão de Parcerias e Alianças. 2. Questionamento sobre as expressões "resultados obtidos pelo software" e "resultados obtidos

pelos projetos em parcerias, para a geração do software", do item "Orientações". 3. Sugestão de que a empresa possua parcerias e alianças com fornecedores de tecnologias alinhadas

aos padrões de mercado. 4. Sugestão de que processos de negócios da empresa possuam metodologias baseadas na norma

ISO/IEC 15504. 5. Questionamento sobre os termos "em outro contexto" "acompanhar" e "monitorar", do item

"Orientações", do Resultado Esperado GPA.3.

4.2. PROPOSTAS NÃO ACEITAS DE MUDANÇA NA METODOLOGIA CERTICS

Definições e Pressupostos

1. Questionamento sobre dificuldades para consecução de um processo de certificação objetivo para reconhecer: a) se houve desenvolvimento no País; b) se houve a formação, sustentável ao longo do tempo, de capacitação no País. Deliberação: não aceito; o questionamento não explicita os trechos da Metodologia que embasaram a crítica; o objetivo da Metodologia, conforme descrito, é verificar


se o software é resultante de desenvolvimento e inovação tecnológica realizados no País. Este objetivo é atingido pela Metodologia. Para confirmar o atendimento desse objetivo está previsto um monitoramento contínuo dos resultados e impactos da certificação.

2. Sugestão de considerar que "Padrões Abertos" contribuem para o desenvolvimento nacional sustentável. Deliberação: não aceita; independentemente do tipo de padrão, a Metodologia vai avaliar se o desenvolvimento de um software cria e/ou amplia competências tecnológicas e correlatas no País, contribuindo para o desenvolvimento nacional sustentável.

3. Sugestão de utilizar média aritmética ou ponderada para cálculo da nota final da avaliação. Deliberação: não aceita; a nota binária (sim/não) do resultado da avaliação garante o atendimento mínimo do que se considera necessário para qualificar o software como resultante de desenvolvimento e inovação tecnológica realizados no País.

4. Sugestão de incluir na Metodologia CERTICS os atributos de usabilidade e acessibilidade. Deliberação: não aceita; a Metodologia CERTICS visa à identificação de software resultante de desenvolvimento e inovação tecnológica realizados no País e esses atributos sugeridos não contribuem para indicar a localização das competências no País.

5. Sugestão de que a certificação de software seja arquivada e que nova proposta seja formulada. Deliberação: não aceita; a Metodologia CERTICS foi construída em um processo participativo, tendo sido revisada e validada junto a stakeholders, inclusive via Consulta Pública, antes do início de sua operação.

6. Questionamento sobre a certificação de produto que se utilize de um software embarcado certificado. Deliberação: não aceito; atualmente a Metodologia CERTICS não contempla software embarcado.

7. Sugestão de mudança dos critérios para a avaliação, seguindo os elementos referenciados na Lei nº 12.349/10:

I. geração de emprego e renda; II. efeito na arrecadação de tributos federais, estaduais e municipais; III. desenvolvimento e inovação tecnológica realizados no País; IV. custo adicional dos produtos e serviços; V. em suas revisões, análise retrospectiva de resultados.

Deliberação: Não aceita; estes itens dizem respeito a impactos esperados pela aplicação de margem de preferência. Portanto caracterizam-se como algo a ser obtido ao longo do tempo e não um requisito ou critério de comprovação de software resultante de desenvolvimento e inovação tecnológica realizados no País. O monitoramento dos resultados da aplicação da margem de preferência e de outros usos da CERTICS indicarão se esses impactos estão sendo atingidos. Por esta razão, apenas o item III desta sugestão seria aceito, mas já é tratado na Metodologia.

8. Sugestão de utilizar parâmetros de origem da produção e teor da inovação para estabelecer as margens de preferência, conforme Decretos nº 7.709, 7.713 e 7.767. Deliberação: não aceita; a Metodologia não visa avaliar a origem da produção do software mas, sim, identificar se o software é resultante de desenvolvimento e inovação tecnológica realizados no País, por meio da verificação das competências tecnológicas e correlatas geradas. Além disso, não entra no mérito do teor da inovação mas, sim, se é resultante de inovação.

9. Questionamento sobre aplicação da CERTICS para casos em que o software ainda não tenha sido desenvolvido. Deliberação: não aceito; a CERTICS certificará software pronto para uso e não em estágio de desenvolvimento.

10. Sugestão de que se utilize na execução da Avaliação CERTICS a sistemática do Sistema Brasileiro de Avaliação da Conformidade do Instituto Nacional de Metrologia, Normalização e Qualidade Industrial (Inmetro). Deliberação: não aceita; razão: o Sistema de Avaliação da Conformindade (Lei nº 5.966/73) tem sua finalidade disposta pela Lei nº 9.933/99, que trata da verificação do cumprimento, por produto ou serviço posto no mercado brasileiro, de normas técnicas que exijam, para aquele produto ou serviço, os requisitos de segurança e parâmetros de usabilidade, todavia não existem normas técnicas brasileiras que designem as características de usabilidade de


softwares. Existem normas de melhoria de processo; estas orientam a melhoria das atividades (tomadas como processos) executadas para a elaboração de programas de computador, mas não designam as características de usabilidade de cada tipo de software disponível no mercado. A Metodologia CERTICS, em contrapartida, tem a finalidade de verificar se um programa de computador é resultado de desenvolvimento e inovação tecnológica realizados no Brasil, e tal objetivo não se encontra como resultado direto da aplicação de normas de melhoria de processo, decorrendo daí a necessidade de estipular um método que verifique, rápida e eficientemente, as condições de desenvolvimento de certo software, as resultantes e a sua contribuição de tal desenvolvimento para o País.

11. Sugestão de inclusão de metas tangíveis que identifiquem o grau de absorção de tecnologia por uma dada empresa. Deliberação: não aceita; a absorção da tecnologia observada por meio da aplicação da Metodologia é definida por uma pontuação dada ao atingimento dos Resultados Esperados, que, por sua vez, indicam a criação ou ampliação de competências no País. Em outras palavras, o grau de absorção se verifica pela geração ou ampliação de competências no País e, portanto, já está previsto na Metodologia.

12. Questionamento a respeito da subjetividade da Avaliação CERTICS. Deliberação: não aceito; a Metodologia CERTICS é baseada na norma ABNT NBR ISO/IEC 15.504, que estabelece requisitos, sistema de pontuação e orientações para modelos e métodos de avaliação de processo capazes de gerar resultados objetivos e reprodutíveis. O modelo foi desenvolvido de uma forma hierárquica estruturada, que decompõe um objetivo em Áreas de Competência, e estas em Resultados Esperados. Dessa forma, cada Resultado Esperado está definido de forma clara e bem circunscrito. Há também uma descrição de orientações e indicadores para cada Resultado Esperado, de forma a orientar tanto as empresas quanto os avaliadores sobre como interpretar cada resultado. Também haverá treinamentos dos avaliadores e um acompanhamento constante (validação dos resultados, supervisão de avaliadores, etc.) para garantir este entendimento. Todas essas etapas asseguram a objetividade da avaliação. Além disso, haverá um processo de monitoramento de resultados e impactos da certificação que estabelecerá um mecanismo de retroalimentação para ajustes e melhoria contínua.

13. Questionamento sobre a necessidade de a empresa ter a propriedade intelectual do software para se certificar. Deliberação: não aceito; a Metodologia não exige que a empresa detenha algum instrumento de proteção à propriedade intelectual do software a ser certificado.

Área de Competência Desenvolvimento – Resultado Esperado DES.1 (Atual Área de Competência

Desenvolvimento Tecnológico – Resultado Esperado DES.2)

1. Sugestão de que o histórico de desenvolvimento e entrega de projetos seja considerado comprovação suficiente de desenvolvimento tecnológico no País. Deliberação: não aceito; o histórico de desenvolvimento e entrega de projetos, desde que se refira ao software candidato à certificação, pode ser uma das evidências analisadas pela Metodologia, mas não é suficiente para verificar se um software é resultante de desenvolvimento e inovação tecnológica realizados no País.


1. Questionamento sobre a necessidade de realização de mudança significativa na tecnologia

relevante adquirida por Unidade Organizacional para comprovação da autonomia tecnológica. Deliberação: não aceito; a realização de mudança significativa é um elemento essencial para verificação de Competência Tecnológica. Em outras palavras, ter Competência Tecnológica significa


ter conhecimentos e habilidades de criar ou modificar uma tecnologia em seus princípios e funcionalidades.


1. Sugestão de considerar a proporção de desenvolvedores no País envolvidos no desenvolvimento do

software em relação ao número global de desenvolvedores envolvidos com o software. Deliberação: não aceita; essa proporção, isoladamente, não contribui para avaliação, somente quando associada a outras variáveis, tais como, por exemplo, os papéis desempenhados pelos profissionais e suas qualificações.


1. Questionamento a respeito de a metodologia não exigir padrões abertos de documentação sob argumento de que o ciclo de desenvolvimento de competências nacionais seria prejudicado. Deliberação: não aceito; por uma questão de direito à propriedade intelectual, não é possível exigir que a Unidade Organizacional disponibilize publicamente a documentação de um software.

Área de Competência Gestão da Tecnologia – Resultado Esperado TEC.2 (Resultado Esperado excluído)

1. Sugestão de incluir a disponibilização do software no Portal do Software Público como instrumento de potencialização de pesquisa e desenvolvimento. Esclarecimento: embora o Resultado tenha sido excluído, é importante destacar que o software disponibilizado no Portal do Software Público Brasileiro é um bem público e não necessita de certificação CERTICS. Para mais detalhes, ver item 3.4.


1. Sugestão de incluir a exigência de que o software em questão seja disponibilizado no Portal do

Software Público. Deliberação: não aceita; por uma questão de direito à propriedade intelectual, não é possível exigir que a Unidade Organizacional disponibilize o código do software no Portal do Software Público.


1. Sugestão de aceitar que a decisão de efetuar modificações possa ser em conjunto com a organização estrangeira que desenvolveu o software. Deliberação: não aceita; a Metodologia considera modelos de redes globais de P&D, porém prevê que a Unidade Organizacional tenha capacidade técnica e decisória para implementar mudanças nas tecnologias relevantes presentes no software, contribuindo assim para a ampliação da autonomia tecnológica e da capacidade


inovativa do País, além de uma maior garantia ao comprador da realização de suporte e evolução do software.

5. OUTROS COMENTÁRIOS

Além das respostas formuladas para atender os comentários relacionados aos princípios da CERTICS (item 3) e à Metodologia em si (item 4), foi também respondida, pelos próprios canais de Consulta Pública e Atendimento, uma série de comentários e dúvidas gerais relacionados à Consulta Pública (onde e como contribuir, prazo final, próximos passos, prorrogação, data e detalhamento das audiências, etc.), a processo de certificação (quando e como certificar um produto, documentos a submeter, custo da certificação), perfil dos avaliadores, processo de seleção de avaliadores/instituições avaliadoras, elogios, etc.

Todas as mensagens recebidas foram lidas e consideradas. As respostas e explicações a essas mensagens que independiam de uma consulta ou análise do Grupo de Trabalho que elaborou a CERTICS, por não se referir à Metodologia propriamente dita, foram encaminhadas aos remetentes e contabilizadas no presente Relatório para fins de acompanhamento da participação.


ANEXO I - AVISO DA AUDIÊNCIA PÚBLICA

Ministério da Ciência, Tecnologia e Inovação

Secretaria de Política de Informática

AVISO DE AUDIÊNCIA PÚBLICA

O SECRETÁRIO DE POLÍTICA DE INFORMÁTICA DO MINISTÉRIO DA CIÊNCIA, TECNOLOGIA

E INOVAÇÃO, no uso de suas atribuições, tendo em vista o disposto no art. 3º da Lei Nº 8.248, de 23 de

outubro de 1991, e no art. 3º da Lei Nº 8.666, de 21 de julho de 1993, e considerando o que consta do

Processo MCTI nº 1200.003222/2012-32, de 21 de agosto de 2012, comunica:

1. Objetivo

Realização da Audiência Pública Presencial, em duas reuniões, para a recepção de contribuições e sugestões

para a Metodologia CERTICS para Software, que tem por objetivo estabelecer os critérios para a

comprovação junto ao Ministério da Ciência, Tecnologia e Inovação de resultado do efetivo

desenvolvimento de uma tecnologia de software realizada no País.

O acesso à Metodologia de que trata a audiência encontra-se disponível no endereço eletrônico do Centro de

Tecnologia da Informação Renato Archer - CTI, Unidade de Pesquisa do Ministério da Ciência, Tecnologia

e Inovação: http://www.certics.cti.gov.br

2. Locais e horários

A primeira reunião fica marcada para o dia 15 de outubro de 2012, no horário de 14:00 às 17:00 horas no

auditório térreo do Ministério da Ciência, Tecnologia e Inovação, localizado na Esplanada dos Ministérios,

Bloco E, Brasília - DF.

A segunda reunião fica marcada para o dia 22 de outubro de 2012, no horário de 14:00 às 17:00 horas no

auditório do Centro de Tecnologia da Informação Renato Archer – CTI, localizado na Rod. D. Pedro I (SP-

65), km 143,6 – Campinas - SP.

3. Do registro e divulgação dos resultados da audiência

Com o objetivo de preservar a integridade de seus conteúdos e o seu máximo aproveitamento como subsídios

ao aprimoramento do objeto da audiência, todas as manifestações verbais referentes às Reuniões desta


Audiência Presencial serão registradas por meio de áudio e a respectiva gravação ficará disponível para

Consulta no endereço eletrônico do Centro de Tecnologia da Informação Renato Archer - CTI, Unidade de

Pesquisa do Ministério da Ciência, Tecnologia e Inovação: http://www.certics.cti.gov.br

4. Da agenda das Reuniões da Audiência

14:00 – 14:10 - Abertura da reunião

14:10 – 15:00 – Exposição do objeto da reunião

14:00 – 15: 00– Inscrição para manifestações

15:00 – 16:50 – Manifestações

16:50 – 17:00 - Encerramento



ANEXO II – LISTAS DE PRESENÇA DAS AUDIÊNCIAS PÚBLICAS

Data: 15/10/2012 - 14h/17h Local: Auditório do Ministério de Ciência, Tecnologia e Inovação

Nome Instituição/Empresa

Alexandre Candido de Paula CTI Renato Archer

Anna Carolline F. Magri Microsoft

Davi Carvalho Jr. FACTI

Francisco G. Soares Qualcomm

Giselle Garcia Intel

Isadora Ribeiro Correia da Silva Advogados

Lúcia Berbert Tele-Síntese

Marcelo Malagutti Fóton Informática

Pedro Menezes SEPIN/MCTI

Raimundo Costa Microsoft

Ricardo Castanheira Microsoft

Data: 22/10/2012 - 14h/17h Local: Auditório do CTI Renato Archer

Nome Instituição/Empresa

Adalberto Nobiato Crespo CTI

Alan Roberto Raldi FACTI

Amyr Girondi TECGRAF

Ana Lúcia Sampaio CTI

Antonio C. Bordeaux CPqD

Antonio Montes CTI

C. Cunha CPqD

Camila Azevedo Sevilha IMA

Carlos Eduardo Moher Positivo Informática

Claudia Cunha CESAR

Claudio Schlesinger IBM

Edmundo M. Oliveira BRASSCOM

Edvaldo Santos Ericsson

Fabio Benatti G&P

Helena Araújo Particular

José Carlos Roccon Filho Universidade Positivo

M. Ruth de P. L. Rega Noh. CPqD

Márcia Martinez CTI

Maria José M. A. Silva IMA

Mariana de Felice BRASSCOM

Michaelle Santos IBM

Nelson Hirano NC Games & Entertainment

Rafael Henrique R. Moreira MCTI

Raimundo Costa Microsoft

Renata Felisberto Reuss SIC

Renato S. Salvadori ISPM

Ricardo M. Matinatta IBM

Rodolfo Fucher Microsoft

Sueli A. Varani Eleutério CTI


ANEXO III - PRINCIPAIS ASSUNTOS TRATADOS NAS AUDIÊNCIAS PÚBLICAS

Como parte do processo de Consulta Pública definido para a Metodologia CERTICS pela SEPIN, foram realizadas duas audiências públicas nos dias 15 de outubro de 2012 no Auditório do Ministério de Ciência, Tecnologia e Inovação – MCTI, em Brasília e 22 de outubro de 2012 no Auditório do Centro de Tecnologia Renato Archer – CTI em Campinas.

A reunião de Brasília teve início aproximadamente às 14:30h com as boas vindas e fala do Coordenador de TI da Secretária de Política de Informática – SEPIN, Rafael Moreira, apresentando os motivadores da criação desta Metodologia de certificação, quais sejam, o atendimento às Leis de Informática (8248 em seu artigo 3º), o decreto 7174 e também a Lei 12.349, bem como a intenção de criar um instrumento inclusivo para todas as empresas da cadeia produtiva do segmento de software. Citou que foram feitas mais de 40 aplicações – piloto na indústria, considerando a heterogeneidade dos modelos de negócio das várias empresas do mercado (grandes e pequenas). Explicou que a CERTICS é uma certificação que identifica, credencia e diferencia software e seus serviços associados, gerando valor local e competitividade global.Além de voluntária, a adesão ao CERTICS serve de instrumento às empresas que buscam qualificação para preferência em compras públicas obtenção de recursos do BNDES e da Finep, além de diferenciação no mercado.

Estiveram presentes 11 pessoas mais a equipe da SEPIN, sendo que os representantes da Fóton Informática, Marcelo Malaguttie da Qualcomm, Francisco Soares, se pronunciaram.

A preocupação de Marcelo Malagutti, da Fóton Informática, é que a avaliação por um técnico pode conter subjetividades que prejudicarão a empresa. Além disso, a complexidade da implantação do processo pode acabar com o interesse das desenvolvedoras de software, custando caro e trazendo benefícios reduzidos aos detentores da licença.Ele reclamou que ainda não foram divulgados os valores para obtenção da CERTICS e nem o prazo para receber a certificação.

Já o diretor da Qualcomm, Francisco Soares, também reclamou da complexidade da proposta e disse que medidas como redução dos impostos cobrados na cadeia produtiva do software poderia ter um impacto positivo maior no setor que a certificação. Mas reconheceu a validade do governo em buscar incentivos para crescimento dessa indústria no Brasil.

O coordenador-geral do MCTI, Rafael Moreira, argumentou que a proposta de certificação do software foi concebida durante 15 meses, com a participação de acadêmicos, consultores e especialistas contratados e a Metodologia foi amplamente testada. “O modelo foi amplamente testado e vamos garantir que haja uma uniformização dos entendimentos pelos avaliadores para mitigar problemas de subjetividade”. Com relação a custos e prazos, disse que eles serão divulgados após a calibragem da proposta, que será realizada ao final da Consulta Pública. Mas adiantou que os custos serão suficientes apenas para cobrir o processo de avaliação e será diferente a depender do tamanho da empresa.

Rafael Moreira admitiu um refinamento da proposta, especialmente para simplificar a implantação da certificação em micro e pequenas empresas. Ele sustenta que essas empresas representam 94% do setor. A previsão é de que a proposta seja concluída no final de março de 2013.

No dia 22 de outubro de 2012 foi realizada no Centro de Tecnologia Renato Archer – CTI em Campinas, a segunda audiência pública com a presença de 28 pessoas, além da equipe do projeto.

Após palavras de abertura do Diretor do CTI Victor Mamanna e do Coordenador de TI da Secretária de Política de Informática – SEPIN, Rafael Moreira, foram abertas as inscrições para manifestações. Os participantes que pediram a palavra e os tópicos abordados durante a audiência foram os seguintes:


Edmundo Oliveira, Diretor da Brasscom, argumentou que a formulação do CERTICS teve participação pontual das empresas e das entidades e que a Metodologia proposta terá baixo impacto nas compras públicas.Com relação especificamente à Metodologia CERTICS, fez as seguintes considerações:

O desenvolvimento de software é um processo que muitas vezes acontece informalmente, sem um registro formal da evolução. A Metodologia proposta demanda uma formalização do processo de registro do desenvolvimento

O modelo dá pouca ênfase na comprovação do que é realizado localmente Há pouca clareza nos quesitos de parcerias e alianças A Lei 12.349 referencia a construção de uma norma técnica e CERTICS não é uma norma técnica Aparente excesso de quesitos além do desenvolvimento local (competências correlatas) Dúvidas em como tratar família de produtos - proposta de certificar competências em

determinados mercados-alvo Ambiguidade na definição de software constante na página 16. Questiona o que acontece quando a

empresa detém domínio de apenas uma parte da solução Necessidade de a Metodologia considerar times globais de P&D. Propõe prever ambientes multe

projetos e multeequipes na área de competência Gestão de Parcerias e Alianças Incluir certificação de serviços na Metodologia, em especial serviços sob encomenda Recomenda que o resultado não seja binário, aprovado ou não, mas tenha uma graduação de

maturidade Sugere que a área de Competência Gestão da Tecnologia considere outros modelos Propõe que a área de Competência em Gestão de Negócios considere a capacidade financeira e

autonomia

Nelson Hiranoda da NC Games&Entertainment apresenta o perfil da empresa a que pertence, empresa de jogos eletrônicos, e pergunta se as competências a serem verificadas são as mesmas para os 3 tipos de software (Encomenda, semi-pronto e pacote). Menciona a necessidade de definição mais clara do que é o software. Edvaldo Santos da Ericsson Telecomunicações apresenta preocupação com a ênfase em autonomia tecnológica. Relata que o modus operandi atualmente são centros globais de P&D e que Metodologia não permite certificar este tipo de desenvolvimento. Menciona preocupação com o fato da solução/ produto ter que ter sido concebido no País. Em geral, software utilizado no País não foi concebido aqui. Afirma que Metodologia não tem indicadores que priorizem exportações e competitividade. Pergunta se empresa tem que atender aos 24 resultados, totalmente e se ficar um de fora, é reprovada. Claudio Schlesinger da IBM do Brasil reforçou a necessidade de fortalecer as parcerias intramultinacionais que são uma decorrência do mundo globalizado. Metodologia devia fortalecer estas parcerias. Menciona necessidade de melhoria na comunicação (escrita) da Metodologia e que a Leitura que se faz friamente transparece pouca flexibilidade da Metodologia. Considera que a Metodologia depende muito da qualidade da avaliação (perfil do avaliador) e que o Governo poderia comprar mais soluções de software e isto estimularia investimentos no Brasil.


ANEXO IV - LISTA DOS PARTICIPANTES DA CONSULTA PÚBLICA

n Remetente Organização

1 Adelcio Cabral Pessoa física

2 Alberto Bastos Modulo Security

3 Alessandro Quattrini Ericsson do Brasil Telecomunicações S.A.

4 Almir Firmino Decisão Sistemas

5 Americo Borghi Moreira Jacinto MPOG - Ministério do Planejamento, Orçamento e Gestão

6 Anderson Oliveira Conecte Soluções (CSPE)

7 Antonio C. Bordeaux Rego CPqD

8 Antonio Gil BRASSCOM

9 Célio Fabiano de Souza Desk Manager Software

10 Claudio Norio Minei Consist

11 Claudio Norio Minei Pessoa física

12 Cleber Nardelli IPM Software

13 CLeida A. Queiroz Cunha. CPqD

14 Daniane Bergamini Progic Tecnologia Eletrônica Ltda

15 Deivi Kuhn Comitê de Implementação de Software Livre

16 Deyson Thome Pessoa física

17 Diva Gabriela TWConnectCare

18 Edmilson Púlice de Castro 4win Tecnologia da Informação Ltda.

19 Edson Nery HP

20 Eduardo Garcia EPG Consultores Associados

21 Eduardo Santos LightBase

22 Fabio Rodolfo Marques Benatti GP NET

23 Felipe Herzog Correia da Silva

24 Felipe Herzog Pessoa física

25 Fernando Botelho Ashoka

26 Fernando Gebara Filho Microsoft

27 Fernando Santo Andre Pessoa física

28 Francisco Carlos Soares Qualcomm

29 Frank Caramuru BSA - The Software Alliance

30 Gabriela Fonseca Silva de Oliveira CETEC - Coordenação Estratégica de Tecnologia / SERPRO - Serviço Federal de Processamento de Dados

31 Geraldo Couto Via Apia Informática

32 Guilherme Tirado Leite Leite & Marvalhas

33 Gustavo Barbosa AbilityCom

34 Igor Gavazzi Vazzoler Progic Tecnologia Eletrônica Ltda

35 Izoulet Lima Moreira Cortes Filho CITS - Centro Internacional de Tecnologia de Software

36 Jacson Renzo Querubin Itaipu Binacional

37 Joana Almeida e Souza Cisco do Brasil Ltda (via Bialer & Falsetti Advogados)

38 Joao Farias Energy Telecom

39 João Paulo Rimes Flextronics

40 João Paulo Rimes Pessoa física

41 Jonas Sousa Prefeitura Municipal de Limoeiro do Norte

42 José Maria Villac Pinheiro NEXUS GeoEngenharia

43 Julia Jasinska DIGITALEUROPE

44 Kazuhiko Oi Japan Electronics and Information Technology Industries Association (JEITA - Washington DC Office)

45 Luiz Wolf Reglare Business Center Rules

46 Marcelo A . O. Malagutti Fóton Informática S.A .

47 Marcelo Marques 4Linux

48 Marcelo Massao Pessoa física


49 Marcelo Pessoa Fundação Vanzolini

50 Márcia Martinez CTI

51 Marcos Gomes SOFTEX Recife

52 Maria Jose Ferreira de Lima Shimakawa ÁBACO Tecnologia de Informação Ltda

53 Maria Medrano Information Technology Industry Council (ITI)

54 Matheus A . Rodrigues Motorola R&D Solutions

55 Michaelle Santos IBM do Brasil

56 Monique Fridell Seção Americana do Conselho Empresarial Brasil-Estados Unidos (CEBEU)

57 Nelson Mitsuo Hirano NC Games

58 Oscar Ribeiro OASyS Informática

59 Pedro Antônio de Oliveira Gonçalves Correia da Silva

60 Renato Lundberg MAPS Soluções e Serviços

61 Renato Salvadori ISPM - Soluções para Gestão de Nível de Serviço

62 Ricardo Jurczyk Pinheiro Pessoa física

63 Roberto Bittar PPV Informática

64 Roberto C. Mayer FNTI - Frente Nacional das Entidades de TI

65 Robson Cardoso da Silva Via Lógica Consultoria e Sistemas Ltda

66 Rogério Mendonça Pessoa física

67 Ronaldo Cardozo Lages Chefia da Coordenadoria de Informática do Gabinete do Governador do Estado do Rio Grande do Sul

68 Rosilda Prates Associação Nacional das Indústria com Tecnologia Desenvolvida no País

69 Ruben Delgado SOFTEX

70 Silvio Viegas Pessoa física

71 Sueli A . Varani CTI

72 Vítor Baptista Pessoa física


ANEXO V – RESPOSTA À FRENTE NACIONAL DE TECNOLOGIA DA INFORMAÇÃO - FNTI

Em 11 de dezembro de 2012 foi recebida, por meio do canal da "Consulta Pública", proposta de metodologia substitutiva à Metodologia CERTICS preparada pela Frente Nacional de Tecnologia da Informação, como se denominou a iniciativa da Associação Brasileira das Empresas de Software - ABES, Associação das Empresas Brasileiras de Tecnologia da Informação - Assespro-Nacional, Associação de Usuários de Informática e Telecomunicações - Sucesu, Associação para Promoção da Excelência do Software Brasileiro - SOFTEX, e Federação Nacional da Informática – Fenainfo.

Importa destacar que seu conteúdo não constitui um conjunto de sugestões para modificações de melhoria para a Metodologia CERTICS (M.C.) como deu-se com as demais contribuições recebidas, constitui, de fato, proposta substitutiva organizada em atenção à premissas e objetivos distintos daqueles que nortearam a preparação da metodologia submetida à consulta pública, e por conter propósito e conceitos próprios, é relatada em separado.

A proposta encaminhada, neste particular, concebe a existência de uma dicotomia de avaliações, como se resultasse da legislação relacionada com preferências de compras uma avaliação relativa ao desenvolvimento local, que serviria para atender aos preceitos da Lei 8248/1991 e baseada na regra de demonstração de efetivo desenvolvimento local disposto no Decreto 7174/2010 que permitisse a aplicação de margem de preferência normal, e outra, relativa à inovação, que atenderia a margem de preferência adicional como prevista na Lei 12.349/2010 e regulada, no geral, pelo Decreto 7546/2011. Ao fazer tal dicotomia, a proposta não leva em consideração o posicionamento das duas legislações frente ao todo do Ordenamento Jurídico Brasileiro15, onde a Lei Geral de Compras (8666/1993 tal como modificada pela 12.349/2010), se sobrepõe e redefine o campo de operação da Lei de Compras de Informática.

Por sua vez, a M.C. foi orientada para atender a dois campos normativos contínuos, tanto em consonância ao objetivo que norteou a formulação da Lei 12.349/2010, o de “agregar à finalidade das licitações públicas o desenvolvimento nacional”, quando ao de identificar software com tecnologia desenvolvida no País conforme a lei 8.248/91. Importa à M.C. prover nos dois campos normativos do perfil da demanda pública por bens e serviços de tecnologia da informação e telecomunicações chancela de avaliação que permita aos responsáveis pelos processos licitatórios da Administração Federal melhor executarem os instrumentos da margem de preferência e do direito de preferência estipulados pelas leis 8.666/1993 e 8.248/1991.

Assim, a M.C. foi configurada para agregar às licitações para compras de TICs nítida oportunidade para que estas contribuam para o “desenvolvimento nacional” isto porque o conceito, desenvolvimento nacional, agora alçado pela Lei 12.349/2010 como princípio geral determinante de qualquer licitação, submete, como dito, até mesmo o campo normativo da lei 8248/1991 e o direito de preferência ali estabelecido. Para dar conta da tarefa, a M.C. foi estabelecida sobre preceitos, chamados na proposta da FNTI de “pressupostos básicos”, que levam em conta mais do que os contornos estatísticos do setor no País mapeados por pesquisas.

15 Pelo efeito de a Lei 8666/1993 ser aquela que contém as definições para a realização de quaisquer licitações para compras

públicas, todas as licitações feitas para contratar bens e serviços de TICs deverão seguir as regras incluídas pela Lei 12.349/2010,

especialmente as compras orientadas pela Lei 8248/1991, que, quanto ao procedimento licitatório, deverão realizar-se ao encontro

do preceito de que qualquer processo licitatório deverá contribuir para o desenvolvimento nacional sustentado. Neste sentido,

uma portaria que estabelecesse as regras para atender ao disposto no Art. 6º do Decreto 7174/2010, quanto à aplicação de

preferência no âmbito da negociação (apresentação de nova proposta com valor mais baixo que o melhor colocado), está também

submetida à determinação da promoção do desenvolvimento nacional sustentável, tanto quanto deve estar sob o mesmo critério o

procedimento de compras que aplique a margem de preferência adicional.


Nesta razão, e amparada pelos objetivos expressos pela Exposição de Motivos16 da Medida Provisória que foi convertida pelo Congresso Nacional na Lei 12.349/2010, a metodologia submetida à consulta estipulou verificar a fixação no País dos aspectos necessários ao desempenho de negócios intensivos em conhecimento, elegendo a evidenciação da produção local deste conhecimento, da sua gestão autônoma nas relações de fornecimento, de sua distribuição na unidade organizacional que o fornece ao mercado como programa de computador e serviços essenciais à sua plena operação, e ainda verificando sua relação, na qualidade de fornecedor de certo conhecimento, como o mercado que dele depende, posto serem estes, consensualmente, os âmbitos da atividade produtiva empresarial no setor de TICs mais profícuos na geração de inovação.

Por seu turno, o documento intitulado “Contribuição da FNTI à Chamada Pública sobre a CERTICS” é composto por um capítulo primeiro, intitulado “Panorama da Indústria Brasileira de Software e Serviços de TI (IBSS)” que contém dados estatísticos reunidos em pesquisas realizadas pela SOFTEX (Software e Serviços de TI: A Indústria Brasileira em Perspectiva, de 2012) e pela ABES (Mercado Brasileiro de Software: panorama e tendências, de 2011) e da ASSESPRO (Censo ASSESPRO do Setor de TI 2012), que são levantamentos estatísticos também considerados para a formulação dos cenários empregados na elaboração da Metodologia CERTICS pela equipe dela encarregada.

O segundo capítulo, intitulado “Proposta da FNTI diante da CERTICS”, apresenta proposta de método de identificação de fornecedores agraciados com a aplicação da margem de preferência e do direito de preferência em compras públicas que operaria como mera regra de origem que entende, tal como está organizada, que a margem de preferência normal seria concedida para empresas que demonstrem o efetivo desenvolvimento local segundo o escopo do art. 6º do Decreto 7174/2010, enquanto que um segundo conjunto de critérios que apontariam para a inovação, identificada nas empresas por elementos já presentes nestas empresas como conquistas de prêmios, obtenção de certificados de metodologias de processo, entre outros diversos indicadores, autorizaria conceder margem de preferência conforme a Lei 12.349/2010.

Em suma, o conjunto de critérios eleitos pela proposta da FNTI é encabeçado pela quantidade de certificados em modelos de melhoria de processos (CMMi, MPS-BR, ISO 29110) a que certa empresa já tenha se submetido, bem como um conjunto discreto de indicadores relacionados com sua gestão de negócios, (neste caso, somente a participação em feiras seria considerada), demonstração da realização de parcerias e alianças, (tal como a contratação de uma parceria para fornecimento regional), o uso de benefícios da lei do bem, a elaboração de trabalhos acadêmicos por colaboradores da empresa sobre o software avaliado, projetos apresentados e projetos fomentados por órgãos oficiais e no exterior, entre outros poucos itens, que , demonstrados presentes na empresa avaliada seriam pontuados. E, ao considerar duas avaliações distintas, como dito, uma relacionada ao desenvolvimento local de código e outra relacionada com a inovação, alguns dos itens verificados seriam pontuados distintamente nas duas relações estabelecidas, uma pontuação para efeitos do direito de preferência e outra como demonstração de resultado inovação realizada no País para a aplicação da margem de preferência adicional.

A despeito de a proposta de substitutivo mencionar que aquele tenha sido elaborado para atender a Lei 12.349/2010, a identificação de fornecedores preferenciais obtida pelo método proposto, que é fortemente baseado em declaração de origem, não é capaz de vincular o resultado das compras públicas de TICs ao desenvolvimento nacional, tampouco alcança tal objetivo a segunda disposição do substitutivo, em que a certificação seria concedida diante de declarações do interessado que servem à pontuação de uma escala de indicadores fixa. De fato, a proposta requer que a empresa interessada declare que seu software

16

Exposição de Motivos da Medida Provisória 459, item 6. “ A modificação do caput do artigo 3º visa agregar às finalidades das licitações públicas o

desenvolvimento econômico nacional. (...) É importante notar que a proposição fundamenta-se nos seguintes dispositivos da Constituição Federal de 1988: (i) inciso II do artigo 3º, que inclui o desenvolvimento nacional como um dos objetivos fundamentais da República Federativa do Brasil; (ii) os incisos I e VIII do artigo 170, (...); (iii) artigo 174, (...) e (iv) artigo 219, que trata de incentivos ao mercado interno, de forma a viabilizar o desenvolvimento cultural e sócio-econômico, o bem estar da população e a autonomia tecnológica do país.” Sem grifos no original em http://www.planalto.gov.br/ccivil_03/_Ato2007-2010/2010/Exm/EMI-104-MP-MF-MEC-MCT-MPV-495-10.htm


atende ao preceito legal de ser resultado de desenvolvimento e inovação tecnológica realizada no País sem bem determinar no que consiste tal desenvolvimento e inovação, isto é, sem definir o campo semântico válido para tal preceito, o que resultaria, do ponto de vista legal, em uma declaração de boa-fé quanto ao declarante, todavia desprovida de efetividade quanto ao declarado.

Segue adiante breve relato dos pontos mais relevantes da proposta da FNTI, iniciando-se pela observação dos preceitos que a orientam, presentes na página 23 do documento encaminhado, em que se enumeram os “pressupostos básicos” que nortearam a elaboração da proposta de substituto para a Metodologia CERTICS, transcritos abaixo:

a) A simplificação do processo de certificação tornando-o mais acessível a empresas de todos os tamanhos, especialmente em atenção ao objetivo de fomentar as micro e pequenas empresas nacionais a realizarem inovação tecnológica em seus produtos;

Nesta razão, a simplificação do processo de avaliação, de algum modo não explicitado, fomentaria micro e pequenas empresas nacionais à realizarem inovação tecnológica em seus produtos, Por seu turno, a M.C. pretende que as empresas avaliadas demonstrem, por evidências quaisquer, que suas práticas empresarias já implementadas às aproximem do campo de inovação mais ativo, que é consenso, se realiza quando empresas monitoram o seu mercado, seus concorrentes, gerenciam a tecnologia que detém e implementam a disseminação do conhecimento necessário para a sua operação e controle funcional dentro de suas próprias organizações.

Todavia, importa esclarecer que a metodologia submetida à consulta pública não é um método de melhoria de processos cuja aplicação fomente certo resultado na organização verificada, se não marginalmente. A verificação disposta pela metodologia CERTICS procura avaliar unidades organizacionais que empreendam negócios intensivos em conhecimento nas quais, seja em forma já bem estruturada em empresas de maior porte seja de forma ainda incipiente em empresas pequenas, suas práticas evidenciem fornecedores capazes de produzir bens e serviços de TICs.

b) “A participação das entidades representativas de classe, gerando uma capilaridade essencial no atendimento às empresas, especialmente em um primeiro momento, quando poderá surgir uma demanda maior”;

No sentido do objetivo último de uma metodologia, a preocupação com a capacidade de atendimento e a formação de uma demanda represada é largamente justificada, todavia, a solução de uma potencial demanda inicial não deve ser determinante na seleção do método de avaliação, já que tal demanda pode ser bem resolvida pela formação de uma rede de instituições que apliquem, ao menos em parte, os procedimentos de avaliação propostos pelo método escolhido. Esta rede de instituições deve ser moldada pela aplicação, em uma licitação, de critérios de eficiência, identificando fornecedores de cunho técnico, de caráter eminentemente neutro quanto aos interessados na realização de avaliações, selecionadas segundo sua capacidade de implementação da metodologia proposta. Daí que a participação de entidades representativas de classe na aplicação de um instrumento de política pública setorial, quando afastados os potenciais conflitos de interesse, seria antes função da capacidade daquelas entidades demonstrarem a sua capacidade de aplicarem eficientemente certa metodologia através de propostas em atendimento aos termos de um edital de seleção de fornecedores, do que às suas características de entidade representativa de empresas que submeter-se-ão aquela avaliação. De todo modo, entende-se que o contorno das possíveis dificuldades de demanda para a implementação de certa metodologia não deve ser elevada a condição de definir o próprio método.

c) “O aproveitamento das certificações de processos e documentação que as empresas já possuírem”;


Este pressuposto, bem analisado, é antinômico à preocupação com empresas que, em função do pequeno tamanho, seriam prejudicadas na obtenção de avaliações positivas, pois exigiria que as micro e pequenas empresas ou tenham anteriormente realizado implementação de modelos de rastreabilidade de código produzido (essencialmente muito mais caros e morosos que a proposta CERTICS e, portanto, menos presentes nesta classe de empresas) ou que estas, por serem pequena empresas, sejam dispensadas da demonstração do que demonstraria a detenção deste tipo de certificação quando da aplicação da avaliação. Importa observar em complemento, que as certificações de processos disponíveis no mercado brasileiro medem coisa distinta do que o que deverá ser evidenciado em uma avaliação segundo a M.C. Tais avaliações de processo não avaliam a presença, em certa empresa, de um conjunto de competências que a tornaria fornecedor melhor imbricado na consecução do desenvolvimento nacional (sustentado) como objetivado pela legislação, antes disto, tais avaliações medem a eficiência dos processos adotados pelas empresas com relação a produzir, melhor, melhores códigos de software.

Finalmente, como quarto pressuposto básico apresentado pela proposta da FNTI, se trás um sistema de pontuação, que se na CERTICS é espelhado pelo proposto pela Norma ISO 15.504 - norma esta que opera como uma matriz para a produção de metodologias de avaliação – aqui é assim formulado:

d) A criação de um sistema de pontuação que torne mais transparentes os critérios que identificam as empresas de TI participantes do processo de compras governamentais.”

Importa apontar que a M.C, segue, para o estabelecimento de sistema de pontuação, o determinado pela norma ISO 15.504. Esta estabelece sistema de pontuação que a comunidade internacional reputa capaz de gerar resultados objetivos e reproduzíveis, medindo quando um determinado conjunto de evidências permite apontar o atingimento de determinado nível de certeza para certo resultado esperado; opera indicando em que medida dado conjunto de evidências cobre o campo de requisitos, segregando aqueles que servem para demonstrá-lo em parte, aqueles que convivem com outras evidências que lhe contradigam a capacidade de prover certeza em maior ou menor grau, ou ainda, que evidenciem a certeza do não atingimento do resultado esperado.

Só têm melhor efeito objetivo as métricas escalares de pontuação cumulativa quando aplicadas a um universo discreto e completo de evidências a ser mensurado, atribuindo-se a cada item de mensuração certa quantidade de pontos em uma escala crescente. Assim, todo o conteúdo de avaliação está referenciado ao longo de uma escala, de modo que a escala seja composta dos pontos que representem a totalidade do universo medido. Assim, uma escala de pontuação deste tipo deverá conter, por exemplo, se forem dez os indicadores de resultado, dez itens de mensuração, distribuindo-se, entre estes dez itens, segundo a importância relativa de cada um, a ponderação daquele item frente à escala total.

Entretanto, para a aplicação de uma Metodologia que avalie empresa contribuinte do desenvolvimento nacional, o seu efeito de tal escala discreta é, antes, a redução do universo das evidências que possam ser aceitas para demonstrar a fixação de competências técnicas e de negócio em uma organização, pois que só valeriam as evidencias que estejam presentes na escala proposta, o que faria as pequenas empresas, principalmente, ou as criadas a pouco tempo, não terem itens pontuáveis (por exemplo, na proposta da FNTI, um prêmio de qualidade já obtido, ou um trabalho acadêmico realizado por colaborador da empresa sobre o software daquela empresa). Uma escala de pontuação, por definição de seu funcionamento, conterá itens admissíveis em menor número do que os itens admitidos para demonstrar o atendimento de resultados esperados admitidos pelo modelo de avaliação adotado pela Metodologia CERCITS espelhando a norma ISO 15.504. De modo distinto, a proposta substitutiva relatada, estipula um rol de quesitos que deverão ser atendidos pelas empresas candidatas à avaliação, de modo que a cada resposta positiva se atribui certo número de pontos em favor da avaliada. O modelo é mais simples, e aparenta maior “objetividade” esta entendida como, estar presente ou não estar presente o item requerido pelo quesito incluído na escala de pontuação, entretanto, tais quesitos não se orientam pela consecução do desenvolvimento nacional.


II

Passamos a seguir a enumerar os quesitos apresentados pela proposta de substitutivo à M.C. no documento da FNTI, primeiro, enumerando e comentando os que foram ali alinhados para evidenciar atendimento a regra de origem decorrente da aplicação do conceito de efetivo desenvolvimento local:

1. Declaração de cumprimento das regras de origem do representante legal de empresa constituída em território nacional, que comprovam que o programa de computador em questão atende aos requisitos do artigo 3 parágrafo V da Lei 8.666/93. Esta declaração não vale pontos, mas será obrigatória para todas as empresas, independente do cumprimento dos demais quesitos mencionados na tabela, e deverá ser preenchida e enviada a uma das entidades representativas.

Para obter-se uma declaração consistente, pressupõe-se que seu declarante fosse capaz de aquilatar sozinho e no momento da declaração, sem qualquer métrica ou conceito (a proposta da FNTI não os definem) quais seriam os requisitos para atendimento do art. 3º, § 5º da atual redação da Lei 8666/1993 que se declara atender. Ademais, ao afirmar que a sua empresa os cumpriria os requisitos sem identificar quais sejam estes, a proposta da FNTI como que substitui toda a M.C, em uma declaração sem objeto. Cabe ressaltar ainda, que se a intenção tenha sido vincular a declaração com o atendimento de normas técnicas brasileiras, sendo tais normas de qualidade, que não existem, para software, normas técnicas de conformidade de produção. Na verdade, o IMETRO publicou normas técnicas para homologação de software exclusivamente quanto estes serve à instrumentos de mensuração, como software para balanças, radares e congêneres. Não existem normas técnicas brasileiras relativas à software, não devendo ser confundido com aquelas as que atendem ao consagrado formato de normas de melhoria de processo de desenvolvimento, que, por definição, não apontam para as características de uso e segurança de um bem ou serviço de TIC, mas sim para a rastreabilidade de sua elaboração como processo de elaboração de um serviço.

2. Certificação ISO 9000 - A utilização do certificado ISO 9000 comprova atendimento das normas técnicas brasileiras, conforme exigência do § 5º do artigo 3º da Lei 8.666/93. Vale 1,0 ponto.

As normas técnicas de qualidade são referidas pelo parágrafo quinto do artigo terceiro da Lei 8666/1993 tal como modificado pela Lei 12.349/2010, e referem-se a quaisquer classes de produtos e serviços, estipulando regras de padronização daqueles para que sejam admitidos no mercado nacional, estipulando, sempre como condição para o acesso a tal mercado, as garantias de atendimento de níveis de desempenho e segurança do uso de certo produto e serviço. Entretanto, como já se pontuou, não existem normas técnicas brasileiras de conformidade aplicáveis a software, i.e., não há regra que defina as características que devem oferecer, ao usuário, certo programa de computador, como um E.R.P.; há sim regras para apoiar a aplicação da confiabilidade de código desenvolvido que requerem a implantação de modelos de gestão de processo de desenvolvimento baseados em rastreabilidade. Tais regras, tomando em conta seus objetivos, primeiramente voltados para o controle do desenvolvimento de serviços, não aferem se houve, em dado desenvolvimento de código, contribuição para o desenvolvimento nacional.

3. Carta declaratória de cliente indicando que adquiriu ou avaliou o produto de software. Esta carta deverá ser escrita por clientes da empresa interessada como forma de recomendação do produto adquirido. Serão aceitas no máximo três cartas, com validade de 0,5 pontos cada uma.

A forma proposta é a usada pelas licitações públicas para obter indicação de que certo fornecedor já realizou serviço ou entrega semelhante ao que, então, é objeto da licitação. O seu objetivo é o de oferecer barreira de entrada para fornecedores sem experiência, mas como forma livre de expressão de satisfação com resultado, as cartas apresentadas na forma de atestados técnicos, (como a elas se refere a legislação) apontam para produtos e serviços já entregues, deixando de servir para a contratação de serviços inovadores, ou para a identificação de características inovadoras, por exemplo.


4. Documentação técnica em português (Requisitos, arquitetura e/ou modelagem de base de dados). Documentação gerada no processo de desenvolvimento, implementação e avaliação do produto, visando assegurar que o mesmo tenha sido produzido para o cliente nacional. Vale 1,0 ponto. Caso conste aprovação formal do cliente, essa documentação valerá 1,5 pontos.

Os documentos requisitados pelo quarto critério estão presentes na quase totalidade das empresas de maior porte, todavia não se encontram disponíveis com a mesma freqüência em pequenas empresas. Com a presença no mercado internacional de empresas especializadas na “localização” de softwares desenvolvidos originalmente para outras culturas que aquelas para a qual a localização se destina, diminui a confiabilidade de que tais documentos assegurem a produção para certo cliente de certo país. Ainda, é relevante que o desenvolvimento de adaptações de programas não nacionais por empresas nacionais podem incluir grau considerável de fixação de competências no País, ultrapassando o que se costuma chamar de tropicalização, para realizar disponibilização de tecnologia inovadora no mercado nacional, mesmo assim, a exibição de documentação técnica em português não demonstra tal apropriação de tecnologia no País.

5. Código fonte depositado junto a terceiros, comprovado por meio de cláusula contratual ou documento de registro emitido pelo cliente, valerá 1,0 ponto

Os depósitos de código fonte são transações mais comuns em empresas transnacionais que em brasileiras, e têm sido suportadas por contratos chamados de escrow, originalmente vinculados aos contratos de distribuição de software estrangeiro por parceiros locais, servem para controlar a internação de código fonte em depósito no território brasileiro. Todavia, a existência destes contratos em uma relação entre distribuidor e distribuído ou entre fornecedor e usuário, não representa forma de acesso às tecnologias que neles estão contidas no código fonte depositado.

6. Produto cadastrado para venda por meio do Cartão BNDES. O processo de cadastro de produtos para serem adquiridos com cartão BNDES impõe regras de origem bem definidas que podem comprovar com eficácia o desenvolvimento dentro do território nacional. Vale 1,0 ponto.

Importa apenas apontar para o fato de que o BNDES tem interesse em usar os resultados do processo de certificação realizado pela M.C. para proceder ao cadastramento de software no programa Cartão BNDES.

7. Declaração RAIS detalhando as ocupações em desenvolvimento de software. O preenchimento da declaração RAIS - Relação Anual de Informações Sociais possibilita a disponibilização de informações que envolvem os trabalhadores ocupados na empresa, logo, é fonte de dados que comprovam o estabelecimento de equipes de desenvolvedores no país. Vale 1,0 ponto.

A Relação Anual de Informações Sociais contendo as informações sobre os empregados da declarante reúne as informações sobre os trabalhadores e seus respectivos papéis em uma empresa candidata à certificação, mas não dá conta da relação que estes empregados, individualmente, têm com certos softwares para os quais se busca certificação, tampouco seria eficiente em relacionar os perfis de capacidade dos elencados com os perfis de capacidade exigidos pela aplicação de certo programa de computador submetido à avaliação. O uso da RAIS é limitado, como diz o enunciado, a demonstrar a existência de equipe de trabalhadores empregados pela empresa, mas não demonstra a competência técnica daqueles e, portanto, tampouco da empresa.


8. URL de currículo publicado no sistema Lattes, indicando vínculo com a empresa e conhecimento/experiência relacionados a TI. Este item é focado na equipe desenvolvedora que, por meio de sua experiência profissional, pode atestar participação no desenvolvimento de produtos e serviços para a empresa. Serão aceitas no máximo três URL's, com validade de 0,5 pontos cada.

A indicação de currículos é uma forma eficiente para a imbricação de competências técnicas da equipe responsável pelo desenvolvimento de certo software que não pode ser alcançada pela declaração RAIS, todavia, observe-se que tal mecanismo tem sua eficiência integralmente prejudicada pela aplicação de medida de escala de pontuação, ao admitir, na proposta comentada, apenas três currículos. Passa que, primeiro, ao não reunir todos os participantes de certo esforço de desenvolvimento, não serviria para demonstrar a plena fixação do conhecimento técnico na empresa; segundo, como é conhecido, empresas maiores com maior número de currículos obteriam pontuação enquanto empresas recém constituídas ou de tamanho menor tenderiam a não ter ainda banco de curricula. Em suma, o item é um dos que, se includos na lista de requisitos para certificação, seriam atendidos pelas maiores empresas em detrimento das menores, que é uma das razões pelas quais a M.C. preferiu o modelo de avaliação da ISO 15.504.

9. Certificados de Treinamento Técnico da Equipe Técnica Local. Este item também é focado na equipe desenvolvedora, e demonstra o comprometimento da empresa com a qualificação de seus colaboradores no âmbito nacional. Vale 1,0 ponto.

A indicação de certificados técnicos não necessariamente demonstra o comprometimento da empresa com qualificação de seus empregados por si só; demonstra, antes, as oportunidades de contratação de pessoal bem aproveitadas pela empresa. Todavia, como se trata de uma medida escalar, a proposta como meio para recolher evidências é prejudicada pelo mesmo limite estabelecido pela pontuação escalar, não vinculando, ao menos o proposto não o prevê, vinculação entre o certificado de treinamento e o conhecimento técnico necessário para a elaboração dos softwares submetidos à avaliação.

10. Prêmio concedido ao produto. A empresa deve apresentar certificados, títulos ou declarações de premiação nacional ou referente à produção nacional. Vale 1,0 ponto.

O requisito e antes a pontuação de uma excepcionalidade que um indicador padrão. Não poderia, por definição, ser cumprido por todas as empresas já que somente as premiadas em certos concursos deteriam as evidências que seriam pontuadas. Por outro lado, o fato de uma empresa participar de um concurso e não ser agraciada com prêmio não é indicativo de que aquela não houvesse submetido ao julgamento software nacional ou que detenha as competências técnicas necessárias a sua elaboração.

11. Disponibilização de Logs de Alterações e/ou Logs de defeitos do software e suas correções. Neste caso, a empresa precisa apresentar documentação que comprove a evolução do produto ao longo de pelo menos 90 dias, identificando o autor das alterações, ou registro dos defeitos por colaborador da empresa que se comprove trabalhar no país. Vale 1,0 ponto.

A despeito de incluir revelação de informações confidenciais altamente sensíveis da empresa que se submetesse a tal avaliação, a exibição de registros de alterações em programa de computador em uso em clientes é certamente eficiente para demonstrar a preocupação de certa avaliada com os serviços complementares pós-licenciamento que produz. Todavia, já que mesmo atividades de suporte de primeiro nível, por exemplo, que prescinde do controle integral sobre o código fonte pelo seu implementador, poderiam gerar sensível número de registros desta natureza, sem a vinculação destes registros com o nível de interação com as principais tecnologias e conhecimentos que tornam possível o desenvolvimento daquele software por uma organização, a métrica não teria eficiência para a finalidade que se persegue. A importância destes registros também é prejudicada quando ao seu aquilatamento, pelo modelo de medida escalar, de um ponto apenas.


12. Disponibilização de Base de Dados de Alocação de Horas-homem ou tarefas. A empresa deve apresentar relatórios de controle e alocação dos recursos humanos atestando o trabalho da equipe em determinado local do território nacional. Vale 1,0 ponto.

Trata-se de evidência que pode ser eficiente para a aferição do desenvolvimento local de um programa de computador quando acompanhada da demonstração das tecnologias relevantes das quais dependem as funcionalidades providas pelo software avaliado. A exibição desta base de dados, isoladamente, não é suficiente para demonstrar o controle das principais tecnologias e conhecimentos que tornam possível o desenvolvimento daquele software por uma organização, entendo-se que a demonstração de tal controle seja o que melhor evidencie a fixação do conhecimento técnico no País.

13. Manual de Usuário em Português, com identificação do(s) autor(es) local(is). Este quesito demonstra que a empresa elaborou sua documentação a partir de equipe dentro do país. Vale 1,5 pontos.

A produção de um manual em português para o uso de certo programa costuma ser providência necessária à exploração econômica de certo software no mercado nacional, e neste sentido é provido como primeira medida quando da internalização de código de software desenvolvido em outro local, isto é, a tradução ou mesmo a re-elaboração de um manual de usuário em português não é índice seguro para demonstrar que o programa que deu ensejo a produção do manual tenha sido realizado no País.

14. Resultados de Pesquisa de Satisfação dos Clientes contratado junto a terceiros. A pesquisa de satisfação demonstra o interesse da empresa em avaliar a qualidade de seu produto e/ou serviços junto aos seus clientes, contribuindo para o desenvolvimento do país. Vale 1,0 ponto.

Pesquisas de satisfação preparadas sob encomenda por terceiros são instrumentos usados por empresas que tenham seu processo de desenvolvimento e acompanhamento da usabilidade de seus softwares em nível gerenciado, para se usar um termo das metodologias de processo, entretanto é ferramenta que raramente estará disponível para as pequenas e micro empresas, o que não recomendaria o seu uso como índice para a construção de uma medida para efeitos de legislação de compras, pois alijaria, exatamente como tem sido a preocupação das associações que formam a FNTI, as empresas que não tem recursos para realizar a contratação de terceiros.

15. Registro de Propriedade Intelectual do Software no INPI. Nesse documento consta a declaração de origem de desenvolvimento do produto. Vale 3,0 pontos

O Instituto Nacional de Propriedade Intelectual tem procedimento para registrar declarações de pessoas, inclusive jurídicas, que, salvo a exigência do depósito de exemplos de partes do código sobre o qual se faz a declaração, não contém nenhum procedimento de verificação da confiabilidade de tal declaração – não são inexistentes registros concedidos à quem não tenha sido efetivo desenvolvedor do software, mas sim sócio ou dirigente de uma empresa. De fato, o procedimento do INPI em registro de software não atribui grau de certeza da autoria ou do direito de exploração comercial de certo software registrado maior que o próprio ato de declaração do interessado no seu registro. Assim, por exemplo, uma empresa qualquer poderia firmar com o titular dos direitos sobre programa de computador de origem estrangeira, usando um contrato de sublicenciamento, que a autorizasse a fazer registro do software vertido para o português no INPI em seu nome, sem que tal documento restringisse o poder do primeiro titular sobre o programa assim registrado. É dizer, que o Registro de Software concedido pelo INPI deve ser avaliado caso a caso, observado as características próprias de cada um como aderentes a finalidade que se busca com a metodologia

16. Apresentação de Interface de Usuário em Português Brasileiro. Os produtos devem ter sido produzidos visando facilitar a sua utilização para o usuário brasileiro, portanto sua interface deve estar em língua nativa. Vale 1,0 ponto.

Na mesma medida de um manual de usuário traduzido para o português, a conversão de da interface de usuário para a língua nativa dos seus usuários é procedimento comum para a maioria dos aplicativos de uso


pessoal disponíveis no mercado brasileiro. É dizer, que a interface de usuário estará em português usado no Brasil tanto em programa desenvolvido no País por brasileiros tanto como aqueles softwares desenvolvidos em qualquer local tendo suas interfaces localizadas para uso por brasileiros

III

Há ainda uma parte final na proposta de substitutivo à M.C. apresentada pela FNTI sob o título “Quesitos para identificar indícios de inovação”. Sob este está a proposta de itens que devem ser pontuados, também em uma escala crescente, por pontuação máxima de 14 pontos para a identificação de desenvolvimento local de tecnologia. Em suma, a relação implica em percorrer os mesmos resultados limitados apontados ate aqui, típicos da estratégia de vincular um resultado a uma lista limitada de indicadores de presença, neste caso, presença de “indícios de inovação” .

A lista preparada com para a identificação de “indícios” de inovação, contém, afinal, as mesmas limitações apontadas acima quando da elaboração da lista para compor regra de origem, sendo o mais negativo o fato de que micro e pequenas empresas de software bem como as empresas nascentes e as em estado de baixo gerenciamento de processos não serem capazes de atender aos quesitos, posto que estes se caracterizam por ser típicos de empresas de médio e grande porte (como é exemplo ser empresa que detenha centro de pesquisa credenciado pelo CATI/MCTI). Assim, para fins de expor os motivos da não aceitação da proposta da FNTI para a substituição da Metodologia CERTICS posta em consulta pública, importa repisar o argumento de que uma lista a que se atribuem pontos para admitir que a partir de certo número de pontos obtidos se confira a certa empresa conceito positivo para fins da Lei 12.349/2010, ou mesmo para fins do decreto 7174/2010, os elementos desta lista deve conter não menos que todos os itens que servem para a demonstração do atingimento daquele conceito positivo.

Diferentemente disto, o que temos como indícios de inovação é uma lista limitada, que repete a maioria dos itens usados para demonstrar a origem antes comentados, em que se atribui, em suma, um máximo de meio ponto (0,5 ponto) para o que é chamado de realização de negócios; um máximo de 2,5 pontos para a demonstração de parcerias e alianças; um valor não limitado de pontos relacionados à apresentação de trabalhos acadêmicos preparados pelos empregados e colaboradores da empresa avaliada sempre com respeito aos softwares submetidos à avaliação; um ponto para o caso de solicitante da avaliação deter centro de pesquisa credenciado pelo CATI; um e meio ponto para a apresentação da declaração RAIS; um ponto para a apresentação de projeto a instituição de fomento fora do País e um ponto pela aprovação de tal projeto; meio ponto, num máximo de três, para curricula Lates apresentados pelos colaboradores da empresa que submetesse software à avaliação. Assim fazendo, a lista que se apresenta não contém o suficiente para ser admitida como capaz de atender aos requisitos de aplicabilidade que se exigem para se conferir margem de preferência para softwares resultados de desenvolvimento e inovação tecnológica realizada no País como requer o decreto 7.546/2011.

Para finalizar este breve relato, importa indicar que o documento da FNTI apresenta, então, algumas conclusões que justificam a escolha dos elementos que integram sua proposta, como a afirmação (a despeito de não ser este o objetivo da CERTICS como acima já registrado) de que a oportunidade de aplicar-se uma metodologia, como a CERTICS, para orientar as compras públicas de TICs não é suficiente para aumentar a capacidade das micro e pequenas empresas ampliarem suas iniciativas de inovação.

Afirma-se que a Metodologia CERTICS é um processo muito burocrático e dispendioso, criando dificuldades para as micro e pequenas empresas, que são as empresas que majoritariamente formam o mercado, em apresentarem evidencias de demonstração dos resultados esperados requeridos pela metodologia – a afirmação é feita a despeito de que,como já registrado acima, a maior parte dos indicadores de avaliação propostos e indicados pela proposta substitutiva não são disponíveis para as micro e pequenas empresas, a não ser após os investimentos necessários para obtê-las, com são exemplo as requeridas certificações de processo (v.g. MPS-BR e CMMI), a apresentação de projetos a organismos não nacionais, a manutenção de laboratórios certificados pelo CATI, entre outras.


Afirma-se que as compras públicas estão centralizadas em poucos fornecedores, mormente na forma de empresas de grande porte e empresas públicas, e que tal viés permitiria o entendimento de que o Governo Federal não compra produtos inovadores, e que portanto seriam poucas, segundo os dados do Censo Assespro 2012, as empresas que os fornecem à Administração – a afirmação é feita a despeito de ser consenso que a finalidade de uma metodologia como a proposta pela M.C. não se relacionar com as decisões de compra da Administração, mas sim com a forma como tais compras se realizarão após haverem sido, por critérios da própria Administração, especificadas suas características.

Afirma-se que a proposta da Metodologia CERTICS, “estabelece regra única para um negócio feito de duas partes - margem de preferência normal e adicional. Não obstante, estamos diante de duas exigências diferentes, já que pela norma jurídica a preferência normal não exige inovação” – a afirmação é feita sem atenção ao fato de que a hierarquia das normas no Brasil, em razão de sua finalidade, estabelece a submissão dos termos de uma norma ordinária à outra, também ordinária, em razão das matérias tratadas por cada uma delas, de modo que a lei de capacitação do setor de informática e automação, que contém mecanismo de direito de preferência para a sua implantação, deve se submeter à norma geral de licitações, contida na Lei Geral de Compras Públicas, na medida em que o mecanismo de preferência contido na primeira lei seja regido pelos critérios de aplicação da segunda norma, ou seja, devam alcançar, também, e antes de mais qualquer critério ser invocado, a contribuição para o desenvolvimento nacional.

Finalmente, o documento sugere duas minutas, (i) uma de Decreto que não tem como ser aproveitado porque não considera o texto e os efeitos já produzidos pelo Decreto 7.546/2011, em que se trata da regra geral para a aplicação das margens de preferência em cada setor econômico e no qual se estabeleceu a regra da margem de preferência normal, e ao qual, por seu turno, o decreto complementar que vier a ser publicado segundo o que exige o art.3º, §5º do Decreto 7546/2011 para tratar da margem de preferência adicional, operará para aquele como complemento normativo; (ii) a segunda, de uma Portaria a ser publicada pelo Ministério da Ciência Tecnologia a Inovação, para estabelecer regime de origem de programas de computador para efeitos da lei 8.666/1993, que pelas mesmas razões, tem seu aproveitamento prejudicado.

Sendo o exposto, o que nos cabia relatar.


ANEXO VI - RESPOSTA À ASSOCIAÇÃO BRASILEIRA DAS EMPRESAS DE TECNOLOGIA DA INFORMAÇÃO E COMUNICAÇÃO – BRASSCOM

Recebeu-se em 12 de dezembro de 2012, através do canal "Consulta Pública", a contribuição da Brasscom à Consulta Pública, que é enviada com o propósito de, citamos, “contribuir positivamente para o objetivo do programa TI Maior de tornar o Brasil mais inovador e competitivo globalmente no setor de software e serviços de tecnologia da informação”.

O documento faz suas contribuições separando-as por áreas, sendo a primeira chamada de Contribuições Técnicas. A primeira contibuição desta área se intitula “Sobre a definição de Software”, assim transcrita.

“Em primeiro lugar, entendemos que o esforço da metodologia em buscar uma definição de software acaba por gerar incertezas e ambigüidades, dada a natureza da composição do software.

Na página 16, temos o seguinte trecho:

(...) O software resultante de desenvolvimento tecnológico e inovação realizados no País pode, então, apresentar-se tanto na forma de software de infraestrutura, software básico (linguagem de programação, bancos de dados), embarcado, como na forma de plataformas ou aplicativos intensivos em conhecimento."

Não existe clareza na definição acima citada para casos nos quais a Unidade Organizacional detenha controle completo apenas de uma porção, componente ou tecnologia de software. Em muitos casos, desenvolver partes do software e da tecnologia gera valor e capacitação tecnológica no país tanto quanto deter o controle de todo o software.”

Resposta:

Não se entende haver ambiguidade ou incerteza na definição de software já que a Metodologia, tal como proposta, usa a definição de software estabelecida pelo art. 1º da Lei 9.609/1998 como sendo “a expressão de um conjunto organizado de instruções em linguagem natural ou codificada, contida em suporte físico de qualquer natureza, de emprego necessário em máquinas automáticas de tratamento da informação, dispositivos, instrumentos ou equipamentos periféricos, baseados em técnica digital ou análoga, para fazê-los funcionar de modo e para fins determinados”. Por outro lado, a citação do texto da página 16, refere-se a uma classificação comum no mercado sobre a tipicidade de certo programa de computador em relação a sua aplicação, opondo o tipo de software cuja operação realiza resultados de infra-estrutura computacional como se dá com o efeito do processamento de um Sistema Operacional, ao software cuja operação realiza resultados de interesse direto dos usuários como se dá com o efeito do processamento de uma suíte de programas que realize automaticamente o envio de informações de controle exigidas de uma instituição financeira instalada no Brasil pelo Banco Central.

Quanto a inexistência de uma definição para software quando a Unidade Organizacional detenha apenas uma parte, porção ou componente da competência necessária para a elaboração do software, entende-se que tal definição não é requerida pelos contornos da aplicação da metodologia porque a Unidade Organizacional poderá requerer e efetivamente obter a certificação da parte do software ou do componente desenvolvido no Pais, assim uma unidade organizacional contaria com margem de preferência sempre que o processo de licitação que venha ser realizado busque contratar apenas o componente ou porção da tecnologia detida integralmente pela Unidade Organizacional.

A segunda se intitula “Sobre a cadeia de produção de software”, e é assim transcrita

“Em segundo lugar, é importante ressaltar que a indústria de software tem uma característica marcante e diferencial das demais. Desde o princípio de sua formulação, seja em plataformas


abertas ou fechadas, os softwares mais competitivos e dinâmicos são aqueles que buscam reunir contribuições de todas as partes e centros de inteligência do mundo. Mesmo um projeto de software desenvolvido para um mercado específico, para ser competitivo, não desprezará os sistemas operacionais, bancos de dados, bibliotecas de software e linguagens previamente existentes, originários de terceiros. Parece-nos, portanto, um equívoco tentar definir algo em termos de “tecnologia nacional de software”, como composto na própria sigla CTENIC, inapropriada a nosso ver.

Os requisitos propostos pelo texto em consulta pública incluem a maneira como a Unidade Organizacional deve operar e onde as atividades devem acontecer, transmitindo a impressão que somente neste modelo existe a geração de valor e tecnologia no País.

Esta restrição acaba por deixar de fora uma categoria significativa de laboratórios globalmente integrados, que produzem componentes completos em cadeias complexas de produtos e soluções. Tal é o caso de unidades de empresas multinacionais, nos quais tanto as atividades como a geração de valor estão distribuídas globalmente. Contudo, com a intensa troca de experiências, todos acabam por adquirir competências e capacidade de produzir tecnologia. Assim, quaisquer que sejam, as definições pretendidas para o software devem considerar a existência desses times globais.”

Resposta:

A Metodologia CERTICS, tal como proposta, é perfeitamente aderente a afirmação feita pela Brasscom quando à reunião de contribuições, e importa à sua formulação estar aderente aos dispositivos da lei 8666/1993 e do Decreto 7546/2011 aos quais atende; sua formulação, neste sentido, não está posta para identificar o que seja um tecnologia nacional, mas sim interessa identificar quando certo programa de computador foi desenvolvido no País por estar na Organização Solicitante presentes as competências técnicas e correlatas tais que permita usar insumos de qualquer origem, como sistemas operacionais, banco de dados, bibliotecas de software e linguagens previamente existentes, para com estas desenvolver programa de computador no País.

Por outro lado a metodologia tal como proposta levou em consideração a existência dos times globais organizados em laboratórios distribuídos mundialmente como estratégia de organização de empresas de tecnologia de reduzirem seus custos e manter o controle sobre a propriedade intelectual impedindo que destes centros resulte indireta capacitação para concorrentes locais, por exemplo. Todavia, a orientação da formulação da metodologia deve atender exclusivamente ao disposto na norma de regência. Assim, os centros que congregam tais times que não sejam localizados no Brasil, ainda que possam contribuir com a disseminação dos resultados que produzam, estão fora do escopo da metodologia porque, por definição de sua lógica de operação, não fixarão no País todas as competências necessárias para a elaboração de certo software. Como o interesse público expresso pelo texto objetivo da lei 12.349/2010 e o decreto que a especifica, é o de conceder margem de preferência para resultado de desenvolvimento e inovação tecnológica realizada no País, não cabe nesta definição a parcela de contribuição ofertada por uma unidade da cadeia global de produção fixada em território estrangeiro.

A terceira se intitula “Sobre o foco dos requisitos no software”, e é assim transcrita

“Os requisitos da metodologia proposta focam excessivamente na equipe envolvida no desenvolvimento do software a ser certificado, principalmente no que diz respeito às alianças estratégicas e parcerias de pesquisa. Na prática, muitos desses acordos são construídos num contexto mais amplo de ambiente multiprojetos e multiequipes. Seria mais razoável que as avaliações tivessem foco no ambiente em que a equipe do software está inserida, ou seja, a empresa.”


Resposta:

A metodologia tal como proposta foi elaborada para avaliar software, fazendo-o pelas evidências da fixação de competências na unidade organizacional que elaborou tal software no País. Importa à Metodologia proposta identificar também as pessoas que sejam envolvidas na definição de requisitos porque o objetivo da legislação, que se procura atender, requer que se avalie software de modo a demonstrá-lo tanto como resultado de desenvolvimento local quanto como resultado de inovação tecnologia, ambas as atividaes sempre realizadas no País. Como se trata de diretriz da norma válida e integrada no Ordenamento Jurídico Brasileiro, esta resulta em exclusão dos resultado de desenvolvimento e inovação tecnológica realizada por equipes fora do País, sendo indiferente aquela lei se as empresas transnacionais se organizaram historicamente de um modo diferente para obterem, por sua organização, as vantagens que dela recolhem. Na verdade, neste aspecto, parece integrar as razões para que aquela legislação tenha sido aprovada com tais contornos, o de servir de incentivo para que as empresas transnacionais transfiram para o Brasil seus centros mobilizados como multiprojetos e multiequipes se lhes interessa obter o uso da margem de preferência estipulada pela lei.

A quarta se intitula “Sobre a pontuação”, e é assim transcrita

“Da forma e com os pressupostos com que foi concebida, a CERTICS gera entre as empresas associadas da BRASSCOM um sentimento de insegurança quanto à suposta objetividade das pontuações e uma certeza de que ela imporá custos desnecessários ao setor de software, além de potencialmente criar arestas e um campo de conflito de interpretações. Em vez de consonância, a percepção dominante é que se pode acabar criando dissonância, pelas seguintes razões:

a. O processo de classificação da Metodologia que o avaliador executará é binário e vai resultar na avaliação de um software numa escala de pontuação ordinal N (não atendido), P (parcialmente atendido), L (largamente atendido) e F (completamente atendido). Embora a descrição da avaliação no texto da CERTICS suponha um processo objetivo, há um claro sentimento de que isso redundará em subjetividade do avaliador, dado que toda a Metodologia pressupõe uma prática ideal de documentação que não ocorre no mundo real das empresas. Se grandes companhias terão dificuldade para cumprir esses requisitos, imagine-se empresas de base tecnológica iniciantes em que, muitas vezes, o fator decisivo é o envolvimento integral dos engenheiros e desenvolvedores de software na execução da atividade fim da companhia;”

b. A classificação binária é excludente, em vez de ser inclusiva, como poderia ser uma eventual classificação por gradação;

c. Embora se projete um processo de certificação objetivo e de curta duração, o sentimento predominante é que tenderá a se formar filas e delongas em todo o processo, encarecendo-o e complicando-o de forma crescente;

d. A formação de contenciosos será uma decorrência de um processo em que, por sua própria natureza, haverá a interposição de recursos e disputas por causa de diferenças de avaliações;

e. A CERTICS implica ainda um nível indesejável de invasão em territórios que pouco têm a ver com a pretendida formação de competência no País, dado que buscará, entre outras, informações sobre estratégias e alianças das Unidades Organizacionais de uma dada companhia e que muito comumente fazem parte de estratégias, segredos comerciais e política de proteção intelectual das firmas.

Resposta:

Os métodos de avaliação de processo que compartilham desta mesma origem são comumente aceitos e empregados por empresas de software e seus clientes, inclusive governos, ao redor do mundo, e


certamente devem ser usadas pelas empresas associadas a Brasscom, justamente metodologias de certificação de processos tal como a CMMI, que é aplicada usando-se modelo de classificação binário tal como o transcrito. Mais que isso, como proposta, a metodologia segue a norma ISO 15.504, que postula ser o regramento para a construção de metodologias de avaliação de processo, cujos métodos de avaliação dependem de decisão do avaliador que, treinado na interpretação da metodologia, tem a tarefa de dizer se determinada evidência apresentada é ou não capaz de evidenciar o atendimento àquele resultado esperado ao que é relacionada. Em suma, a contribuição apresentada pela Brasscom neste sentido mais se alinha com a subjetiva expectativa negativa sobre a capacidade dos avaliadores interpretarem corretamente a metodologia, a despeito de manifestá-la como se fosse apontado um defeito de formulação da metodologia.

Como em qualquer metodologia de processo aplicada pelas associadas da Brasscom para seus propósitos individuais, mais do que uma operação binária, na metodologia proposta, a tarefa do avaliador é convalidar evidências segundo a metodologia, quaisquer que sejam; as evidências que podem ser apresentadas são, por definição, de qualquer natureza, documental ou não, que uma empresa proponha como meio suficiente de demonstrar o atendimento de certo resultado esperado. A operação não é, de fato, em nenhuma destas metodologias de processo, binária – se trata de uma operação de avaliação, a luz da orientação da metodologia e do prévio conhecimento do avaliador nas disciplinas do desenvolvimento de programas de computador, sobre se certa evidência pode ser convalidada como suficiente para demonstrar o atendimento de um resultado esperado requerido.

Diferentemente do afirmado pela contribuição da Brasscom, é consenso que a classificação por graduação como atingimento de um índice cumulativo só consegue ser eficiente na medida em que as escalas desta graduação compuserem o universo completo dos critérios a serem avaliados. Este modelo escalar tem sido entendido como menos eficiente que o que admite quaisquer evidências como admissíveis independentemente de sua prévia inclusão em qualquer conjunto fixo. Afinal, a convalidação de uma evidência para demonstrar o atendimento de um resultado esperado é mais flexível e favorável à empresa do que seria uma lista pré-fornecida de evidências admissíveis, esta sim seria razão de preocupação de poder não ser alcançada por empresas iniciantes. A avaliação por convalidação de evidências permite, por outro lado, que empresas iniciantes que não tenham seus processos mapeados ou geridos possam se certificar, como já se demonstrou em aplicação de campo da metodologia em pequenas e micro empresas, como relatado neste relatório de consulta pública.

O processo de avaliação tal como o proposto foi desenhado para ser completado em espaço de três a quatro semanas depois de iniciado, o que o inclui entre os procedimentos ágeis. O volume de pedidos de certificação será atendido pela constituição de uma rede nacional de entidades avaliadoras autorizadas a realizarem visitas de avaliação, a capacidade de atendimento projetada para o modelo permite que a expectativa seja pelo rápido desaparecimento das pressões de demanda reprimida.

A estrutura responsável pela aplicação da metodologia de avaliação tal como proposta prevê a existência de um conselho recursal de caráter estritamente técnico que permitirá o imediato esclarecimento de desacordos quanto a validade de certa evidência para o atendimento de resultados esperados bem como o esgotamento de diferenças quanto à aplicação das avaliações. Em última análise, tal conselho observará a aplicação da metodologia e a serventia de certas evidências para demonstrar o atingimento de resultados esperados e suas decisões serão subsídio para o incremento de notas definidoras de cada evidência apresentada.

É consenso que a inovação é mais comumente evidenciada desde fora do âmbito da administração de processos projetos de software, e é por esta razão que a metodologia proposta foca na convalidação de evidências de atividades que denotem a busca por composições com terceiros, seja de natureza comercial e técnica, desde que tenham servido para implementar a fixação de competências tecnológicas e correlatas. Todavia, não se pode dizer que a metodologia requer a revelação de segredos das empresas avaliadas, porque a decisão de demonstrar certa e qualquer evidência é sempre da empresa avaliada,


cabendo exclusivamente a ela decidir se é conveniente revelar e em qual grau de integridade, revelar certa informação sensível de sua propriedade como evidência do atendimento a certo resultado esperado. De todo modo, todas as informações que forem apresentadas a um avaliador durante um processo de avaliação estarão sob condição de contrato de confidencialidade diretamente firmado com o avaliador.

No item 2 o mesmo documento de contribuição da Brasscom afirma que crê seja meritória a busca por bases objetivas para a comprovação do desenvolvimento de tecnologia no País como parte do processo de compras públicas, e que “a preferência de compras do governo para esses bens e serviços desenvolvidos no País pode ser um instrumento de fomento ao investimento das empresas nacionais e multinacionais de software instaladas no Brasil”, para em seguida dizer que o modo como a metodologia requer se evidencie ser certo software resultado de desenvolvimento e inovação tecnológica realizada no País não é adequado ao objetivo da legislação, porque a metodologia buscaria evidências de que o desenvolvimento de certo software tenha fixado competências tecnológicas no País, para o que, deveria haver procedimento que requeresse a análise de impacto e a visualização da sua rastreabilidade a partir de um dado requisito funcional até o código fonte dele derivado, e vice-versa, bem como dos artefatos elaborados no processo de desenvolvimento do código. O documento de contribuição da Brasscom, entende, ainda que sem fundamentar como se criariam as dificuldades mencionadas, que “as quatro camadas do Modelo de Avaliação trabalham num nível de ambigüidade que cria dificuldades para a consecução da declarada (boa) intenção de se chegar a um processo de certificação objetivo, ao final do qual se reconheceria duas coisas principais: a) se o software foi desenvolvido no Brasil; b) se houve a formação, sustentável ao longo do tempo, de capacitação no País”. Para a seguir afirmar que existem outras possibilidades e caminhos para se atingir o mesmo objetivo, fazendo as contribuições assim transcritas como “a.” e “b.” e em seguida respondidas :

a. A definição de tecnologia nacional de software implica um conceito que não encontra correspondência no benchmark de produção nacional que já vem sendo estabelecido nos Decretos Nº 7.709, para retroescavadeiras e motoniveladoras; Nº 7.713, para fármacos e medicamentos e Nº 7.767, para produtos médicos. Nesses casos, não está em questão a origem da tecnologia, se nacional ou estrangeira, mas sim a origem da produção e o seu teor de inovação. É com esses dois parâmetros que são estabelecidas as margens de preferência. De forma equivalente, acreditamos que o registro documental de softwares e serviços desenvolvidos no Brasil corresponderá melhor ao benchmark acima descrito do que uma certificação de “tecnologia nacional de software”;

Resposta: No transcrito item a, há antes a inconsistência do entendimento dos conceitos que ali parecem fundamentar a observação. A definição de desenvolvimento e inovação realizada no País não é e não poderia ser aderente ao correspondente de certo bechmark da produção de bens manufaturados nacionais de que tratam os decretos já publicados (retroescavadeiras e motoniveladoras, fármacos e medicamentos, e produtos médicos) já que o próprio conceito de benchmark é incompatível com a comparação de produtos manufaturados em plantas industriais de que tratam os Decretos 7.709, 7.713 e 7.767 com o desenvolvimento de programas de computador, mais adequadamente alinhados, na legislação brasileira, ao conceito de serviços. Consistente com a lógica de sua formulação normativa, a aplicação da CERTICS deverá obedecer exclusivamente as disposições do Decreto 7549/2011 para prover a identificação prévia a um processo licitatório da Administração Federal, aquele serviço nacional ao seja autorizado receber, na forma da lei, aplicação de certa margem de preferência. A singularidade do software como serviço nacional foi reconhecida pela Lei 12.349/2010 e pelo Decreto mencionado, ao tratarem que a definição do que seja resultado de desenvolvimento e inovação tecnológica realizada no País obedeça a requisitos e critérios determinados em portaria interministerial.


b. Existe, por fim, na documentação em consulta uma interpretação, a nosso ver, restritiva do conceito constitucional de “autonomia tecnológica”, expresso no Art. 219 do Capítulo IV (“Da Ciência e Tecnologia”) da Constituição Federal. Para evitar-se a subjetividade em eventual processo de certificação, conviria esclarecer que não há automatismo entre o que propugna a Constituição Federal e a gestão empresarial imediata. Assim, por exemplo, um centro de P&D de uma empresa multinacional de TI que esteja estabelecido no Brasil muito provavelmente não terá autonomia tecnológica frente ao centro de decisão mundial da companhia. Ainda assim, esse centro de P&D poderá desenvolver tecnologias que contribuam para a autonomia tecnológica do País

Resposta:

O conceito de fixação da competência tecnológica requerida pela metodologia tal como proposta não decorre de uma interpretação de conceito constitucional, antes reflete o objetivo primeiro da legislação a que a metodologia procura atender, isto é, obter a identificação para fins de concessão de margem de preferência, ao resultado de desenvolvimento e inovação tecnológica realizada no País, este resultado que não é referido pela norma não como “resultado parcial”, “resultado composto”, “resultado integrado ao longo da cadeia global de contribuições” ou outra forma assemelhada. A metodologia proposta, portanto, foi formulada para que o resultado a ser evidenciado pela Unidade Organizacional deve ser de tal ordem que permita estimar a disponibilidade integral da competência no País, independente da conveniência da organização empresarial que o explore comercialmente. Assim, o conceito de autonomia sobre o software presente na unidade organizacional diz respeito à capacidade que aquela unidade detém em modificar o software, inclusive quanto as suas funcionalidades básicas, posto que de outra forma, a amplitude do conceito de inovação estaria prejudicado no viés que dele se requer quanto a incentivar a fixação no País de centros de pesquisa e desenvolvimento altamente inovadores.

A seguir, em seu último ponto (3) nomeado Proposições, a contribuição apresentada pela Brasscom propõe ( “Reconhecendo a grande dificuldade de se conseguir um modelo de certificação comumente aceito para bens e serviços de TI, pois estes resultam essencialmente de formulação abstrata”) a adoção, ao invés da metodologia proposta, de outros indicadores, a saber (i) declaração acompanhada de documentação relativa aos projetos, com indicadores de investimentos em P&D, (ii) Indicador de emprego direto ou indireto de mestres, doutores e desenvolvedores, (iii) Convênios com universidades e centros de pesquisa, (iv) Indicador de renda gerada pela empresa por meio do uso de parceiros de negócios e canais de venda de forma a dar fomento a um parque empresarial de empresas de TI no País.

Neste passo, importa apontar que todos estes indicadores propostos, são, do ponto de vista da metodologia proposta, potenciais evidências reconhecíveis para o atendimento dos resultados esperados, todavia, a apresentação deste conjunto de evidências por si só, sem o atendimento do conjunto de resultados esperados apontados como essenciais pela metodologia proposta, não será suficiente para identificar software como serviço nacional. Este conceito exige a sua demonstração como resultado do desenvolvimento e inovação tecnológica realizada no País, portanto, por uma empresa, qualquer, que detenha as competências técnicas e correlatas imediatamente disponíveis no Pais para realizá-lo. Por razão desta insuficiência para o propósito legal, as soluções que limitavam-se a requerer a apresentação de declaração acompanhada de indicadores de investimento, emprego, renda gerada e associativismo promovido, assim por diante, que estejam dissociados da demonstração da imediata disponibilidade no País das competências técnicas e correlatas para o desenvolvimento do software avaliado, não foram entendidas como suficientes para atingir o objetivo que deu forma ao uso da margem de preferência em compras públicas.


ANEXO VII- PESQUISA COM PEQUENAS E MICRO EMPRESAS PARA ADEQUAÇÃO DA METODOLOGIA

Este documento apresenta os resultados da pesquisa realizada em Micro e Pequenas Empresas (MPEs) em sete Estados do País com o objetivo de avaliar o Modelo de Referência CERTICS. Esta pesquisa foi conduzida por sete consultores que aplicaram, em 49 empresas de 18 cidades, um questionário elaborado especialmente para avaliar cada Resultado Esperado das cinco Áreas de Competência do Modelo de Referência.

O questionário para apoiar esta pesquisa continha três perguntas. O questionário foi encaminhado por e-mail e as orientações e esclarecimentos das dúvidas sobre o Modelo assim como do preenchimento do questionário foram resolvidas via Skype, e-mail e telefone pelos consultores. As perguntas aplicadas para avaliar o Modelo de Referência CERTICS, com seus respectivos objetivos, foram:

1. “Em geral, uma MPE atende a esse Resultado Esperado para um software e seus serviços associados? (Sim, não, não sei)”

Objetivo: verificar se a MPE atende a cada Resultado Esperado do Modelo no seu software e seus serviços associados.

2. “Qual o grau de dificuldade para uma MPE apresentar evidência para esse Resultado Esperado (alto, médio, baixo)”

Objetivo: verificar em que grau de dificuldade a MPE apresenta evidência para cada Resultado Esperado do Modelo.

3. “Adequação da linguagem e/ou terminologia empregada na Metodologia CERTICS para esse Resultado Esperado (adequada, pouco adequada, inadequada)”

Objetivo: verificar a adequação da linguagem e/ou terminologia empregada na Metodologia CERTICS para cada Resultado Esperado.

Alguns pontos importantes a serem observados:

A orientação dada as empresas só foi feita pelos consultores, sem envolvimento da equipe CERTICS;

A maioria dos consultores não tinha o domínio do Modelo de Referência CERTICS;

As empresas tiveram que ler o Modelo de Referência CERTICS antes de responder o questionário;

Não houve qualquer remuneração às empresas para que respondessem o questionário;

As empresas responderam o questionário tendo como referência a própria Organização.

Fizeram parte da pesquisa 49 MPE´s, distribuídas em 7 Estados, conforme Tabela 1:

Região/Estado Responsável pela Pesquisa

Total de Empresas

São Paulo (Santos, Franca, São Bernardo dos Campos, São José dos Campos, Pitangueiras e Ribeirão Preto)

Edvar 14

Rio Grande do Sul (Passo Fundo, Bento Gonçalves, Caxias do Sul, Nova Hamburgo, São Leopoldo e Porto Alegre)

Sandro 10

Paraíba (João Pessoa e Campina Grande) Francilene 07

Florianópolis Luciane 05

Rio de Janeiro Antônio Botelho 05

Brasília Luciane 04

Pará Clênio 01


Total: 49 empresas entrevistadas

Tabela 1. Distribuição das MPEs entrevistadas por Estado

A consolidação dos dados será apresentada em duas partes, sendo que a primeira mostra o resultado das 49 MPEs por pergunta e, a segunda apresenta o resultado por Estado.

Parte I

O Gráfico 1 apresenta o resultado da consolidação das 49 MPEs entrevistadas em relação à pergunta “Em geral, uma MPE atende a cada Resultado Esperado para um software e seus serviços associado?”

Gráfico 1 – Atendimento aos Resultados Esperados (Pergunta 1)

Para cada Resultado Esperado (RE) apresenta-se o percentual de empresas que responderam a pergunta. Por ex.: Para o RE GPA3, 37% responderam “sim” e 63% responderam “não“ ou “Não sei”.

Será utilizado, como sugestão, um percentual de 60% que definirá o limite de aceitação de uma resposta para o atendimento de um Resultado Esperado. Isso significa que para um Resultado Esperado, se a taxa de resposta “Sim” for 60% ou maior, então o Resultado Esperado será considerado adequado no contexto da Metodologia CERTICS.

Critério de Corte: 60%

Pode ser verificado, pela área em verde do gráfico, que a maioria dos Resultados Esperados (79%) do Modelo de Referência CERTICS é atendida pelas MPEs entrevistadas. Os seguintes Resultados Esperados devem ser revistos:

DES5 (59%): “Dados técnicos relevantes da tecnologia do software estão documentados”

GNE4 (57%): “Instrumentos para direcionar a evolução do negócio relacionado ao software são definidos e realizados”

GPA2 (57%): “Parcerias e alianças relacionadas ao software são formalizadas para pesquisa e desenvolvimento de tecnologia ou para atuação no mercado”

PPC4 (47%): “O conhecimento gerado nas atividades tecnológicas e de negócio relacionado ao software é documentado, disseminado e atualizado”


GPA3 (37% das Empresas): “A coordenação do conjunto de parcerias e alianças é realizada, incluindo a gestão da execução, monitoramento de resultados e revisões”

O Gráfico 2 apresenta o resultado da consolidação das 49 MPEs entrevistadas em relação a pergunta “Adequação da linguagem e/ou terminologia empregada na Metodologia CERTICS para cada Resultado Esperado”

Gráfico 2 – Adequação da Terminologia Empregada (Pergunta 3)

Critério para corte: 60%

Considerando o critério de corte como 60%, pode ser verificado que todas as empresas entrevistadas consideram a terminologia empregada na Metodologia CERTICS adequada. Os dados indicam que quase 70% das empresas entrevistadas consideram a Metodologia CERTICS adequada.

O Gráfico 3 apresenta o resultado da consolidação das 49 MPEs entrevistadas em relação à pergunta “Qual o grau de dificuldade para uma MPE apresentar evidência para cada Resultado Esperado”


Gráfico 3 – Grau de Dificuldade para Apresentar Evidências (Pergunta 3)

Neste caso observa-se que o grau de dificuldade para apresentar evidências para os Resultados Esperados distribui-se igualmente entre as empresas entrevistadas, ou seja, 32% consideram que a apresentação das evidências solicitadas pelo modelo é de baixo grau de dificuldade, 32% consideram que o grau de dificuldade é médio e 36% alto.

Deve-se ressaltar que o objetivo desta questão é identificar o grau de dificuldade ou de trabalho para uma Organização produzir uma evidência para um determinado resultado esperado. Resultados indicados como sendo de alto ou médio grau de dificuldade não significam que a organização não tem capacidade técnica para produzi-lo.

Parte II

Os gráficos a seguir apresentam os resultados da consolidação das MPEs por Estado, em relação à pergunta “Em geral, uma MPE atende a cada Resultado Esperado para um software e seus serviços associado?”. Em seguida, a Tabela 2 apresenta a relação das empresas que participaram da pesquisa. Algumas empresas solicitaram sigilo quanto à divulgação de seu nome ou marca.


Gráfico 4 – Atendimento aos Resultados Esperados na Região de São Paulo

Gráfico 5 - Atendimento aos Resultados Esperados na Região de Florianópolis

Gráfico 6- Atendimento aos Resultados Esperados na Região da Paraíba e Natal


Gráfico 7- Atendimento aos Resultados Esperados na Região da Grande Porto Alegre

Gráfico 8 - Atendimento aos Resultados Esperados na Região do Distrito Federal


Gráfico 9 - Atendimento aos Resultados Esperados na Região do Rio de Janeiro

Gráfico 10 - Atendimento aos Resultados Esperados na Região de Belém

Tabela 2 - Empresas que participaram das entrevistas

Empresa Cidade UF

Ad Infinitum Soluções Brasília DF

Aker Brasília DF

Calc1 Passo Fundo RS

Cigam Novo Hamburgo RS

CLAVIS Rio de Janeiro RJ

Computar Informática Ltda ME Ribeirão Preto SP

Conexão Local Informática e Comércio Ltda. São Bernardo do Campo SP

CSOFTWARE INFORMATICA LTDA Ribeirão Preto SP

CSP Florianópolis SC

Custom Software Ribeirão Preto SP

DM4Brasil Digital Marketing Ltda. São José dos Campos SP

Empresa PB-1 Campina Grande PB

Empresa PB-2 João Pessoa PB




Empresa Cidade UF





Empresa RN-1 Natal RN

Empresa RN-2 Natal RN

Empresa Y Belém PA

Eservice Brasília DF

FIDELIZE Rio de Janeiro RJ

Hadrion Sistemas Integrados Ltda. Pitangueiras SP

INCCA TI Sistemas Ltda ME Franca SP

Kersys Desenvolvimento de Sistemas Ltda São José dos Campos SP

Livera Passo Fundo RS

Lydians São Leopoldo RS

Maven Porto Alegre RS

MBM SYSTEMS LTDA Santos SP

Metadados Caxias do Sul RS

Nkey Software Ltda Florianópolis SC

NST e-Business Sistemas de Informação Ltda. Ribeirão Preto SP

O2 Passo Fundo RS

PHD SOFT Rio de Janeiro RJ

PNP Soluções em Bioengenharia LTDA (InPulse) Florianópolis SC

Power Opticks Tecnologia Ltda Florianópolis SC

Reinvent Tecnologia São José dos Campos SP

Ríberus Solutions Ltda.-ME Ribeirão Preto SP

RIOPRO Rio de Janeiro RJ

Saipher ATC Ltda. São José dos Campos SP

SB Sistemas Marau RS

Softpc Gestão em TI Florianópolis SC

SPECTA TI Rio de Janeiro RJ

Systemhaus Novo Hamburgo RS

Tecnew Informática Brasília DF

Tecnosistemas Bento Gonçalves RS

Vórtice Sistemas Ltda. Ribeirão Preto SP

Gráfico 11 – Porte das empresas que participaram das entrevistas


ANEXO VIII - CONTRIBUIÇÕES E QUESTIONAMENTOS NA ÍNTEGRA (MEMÓRIA)17

a. MENSAGENS ENCAMINHADAS PARA O CANAL "CONSULTA PÚBLICA"

Thu Jan 3 12:12:45 2013

===<thread>===[sequencial:1]===========================================

[email protected]

Re: CERT ICS – Consulta

De : Consulta Publica <[email protected]>

Qui, 13 de Dez de 2012 09:51

Assunto : Re: CERTICS – Consulta

Para : Vitor Baptista

Prezado,

Obrigada pela contribuição.

Todas as contribuições da Consulta Pública serão analisadas e serão publicadas no site da

CERTICS.

Atenciosamente,

Angela

----- Original Message -----

From: "Vitor Baptista"

To: "Consulta publica" <[email protected]>

Sent: Thursday, December 13, 2012 7:43:52 A M

Subject: CERTICS – Consulta

Prezados,

Tendo em vista a Consulta Pública para o CERTICS gostaria de encaminhar minhas sugestões,

todas referentes ao item 4 – Modelo de Referência para Avaliação CERTICS. Em meu

entendimento o modelo proposto não atende às necessidades das empresas nacionais que

desenvolvem software livre, além de ignorar quase que totalmente o maior repositório de

software nacional: o Portal do Software Público BrasiLeiro.

Minhas considerações abaixo, segundo os itens indicados:

4.1 – Software resultante de desenvolvimento tecnológico e inovação realizados no País

<mtmet> Dentre os vários itens destacados como resultante de desenvolvimento e inovação

realizados no País, em nenhum momento é citada a maior fonte de software nacional: o

Portal do Software públ ico. Sugiro que a liberação do software no Portal do Software

Público seja considerada um critério para desenvolvimento tecnológico e inovação

realizados no País, segundo o seguinte texto:

“Serão considerados resultantes de desenvolvimento tecnológico e inovação todos os

softwares cadastrados no Portal do Software Público segundo os termos da IN 04/2011

SLTI/MPOG.” </mtmet>

<mtmet> 4.2 – Área de competência de Desenvolvimento (DES)

DES.1. – O software teve seus requisitos concebidos no País.

Essa área não se aplica ao desenvolvimento do tipo de software mai s estratégico na

indústria: o software básico. Requisitos de software básico são universais e não se

aplicam somente ao Brasil. A manutenção desse item no processo de certificação vai

favorecer claramente a indústria de aplicativos, que promovem um desenvolvimento

estratégico significativamente menor. Quem paga pelo desenvolvimento de um Sistema

Operacional? E de um Banco de Dados?

17 As informações fornecidas por e-mail nos canais de Consulta Pública e Atendimento levaram em conta a metodologia vigente na

ocasião das respostas. Após a finalização da Consulta Pública, a metodologia sofreu algumas alterações, que possivelmente não

foram contempladas nas respostas fornecidas durante o período da Consulta Pública. Deve-se, portanto, considerar a versão atual da

Metodologia.


Se a subvenção do governo não for fornecida a esse tipo de software, existe uma clara

tendência de que a a indústria de software

básico morra, como já aconteceu na década de 90. Os principais concorrentes na área

(Oracle, Microsoft, Red Hat) recebm fortes

subvenções econômicas de seus governos através de contratos com os principais órgãos (ver

livro DTA – Desenvolvimento de

Tecnologias A bertas no DoD americano, traduzido pelo ITI). O Brasil deveria fazer o

mesmo.

Sugiro a remoção desse item ou adição do seguinte texto.

“Para o caso do software em questão estar encaixado na definição de software básico, os

mesmos serão considerados nacionais se

forem desenvolvidos nos Brasil, independente dos requisitos específicos do País.”

</mtmet>

<mtmet> DES.2. – A arquitetura do software e a solução técnica (design) estão definidas,

com indicação do que foi desenvolvido na

Unidade Organizacional.

Nesse item, a alínea a) diz:

“A tecnologia licenciada (adquirida) é parte significativa do valor de mercado do

software.”

Essa linha praticamente exclui os software livres e públicos, onde não há aquisição de

licença, e contraria a in 01/2011 da

SLTI/MPOG, onde consta que deve ser dada preferência à contratação de software livres e

públicos.

Sugiro que essa alínea seja retirada do texto. </mtmet>

<mtmet> DES.4. – Os papéis e pessoas que desenvolveram o software estão identificados,

são compatíveis com o desenvolvimento e geraram competência tecnológica na Unidade

Organizacional.

Esse item possui a seguinte definição:

“As equipes de trabalho envolvidas no desenvolvimento do software são identificadas,

possuem formação, habilidades e conhecimentos adequados às necessidades das atividades

que realizaram.”

No caso de desenvolvimento de software livre nem sempre é possível identificar todos os

que participaram do desenvolvimento do Projeto, uma vez que as equipes são

descentralizadas e de conhecimento difuso. A inclusão desse item só beneficia as empresas

que realizam o desenvolvimento de software da maneira tradicional, excluindo quase que

totalmente o desenvolvimento colaborativo.

Sugiro a retirada desse item ou a inclusão do seguinte texto:

“No caso do software desenvolvido ter seu licenciamento livre o código-fonte deve poussir

uma cópia no Portal do Software Público”

Lá é possível identificar todos os colaboradores através de cadastro público. </mtmet>

<mtmet> 4.3 – Área de competência Gestão de Tecnologia (TEC)

TEC.2. O desenvolvimento do software potencializa pesquisa e desenvolvimento no País.

Nessa área em nenhum momento é citado que a abertura do código do software favorece a

inovação. Se o código for fechado a alteração e/ou evolução do mesmo dependem de

aprovação dos parceiros da empresa desenvolvedora, enquanto o modelo de desenvolvimento

aberto permite a colaboração por todas as empresas, instituições de ensino, enfim, todos

os interessados. Sendo que, em caso de software básico, na maior parte dos casos o

desenvolvimento de novas funcionalidades implica o pagamento de royaties a empresas

estrangeiras.

Sugiro que seja incluído no texto:

“Será considerado um instrumento de potencialização da pesquisa e desenvolvimento a

disponibilização do software no Portal do Software Público.” </mtmet>

<mtmet> TEC.3. As tecnologias relevantes e estratégicas para o software são

identificadas, apropriadas e monitoradas pela organização.

Nesse item existe o seguinte texto:

“A organização deve definir e manter ações de vigilância e prospecção para identificar as

tecnologias que sejam ou que possam ser relevantes para o seu negócio. Estas ações devem

ser aplicadas na busca e identificação das tecnologias que fazem ou farão parte do

software.”

Esse item praticamente exclui o desenvolvimento livre, pois necessita de uma organização

que mantenha “mão de ferro” sobre o desenvolvimento do software. No modelo de

desenvolvimento livre a integração com outros módulos e a criação de “forks” são partes

do processo e não podem ser consideradas menos importantes. Faz parte de sua essência ser


tecnologicamente difuso, e se torna praticamente impossível a qualquer um dos envolvidos

conhecer todos os detalhes do software. Principalmente em se tratando de software básico.

Sugiro a retirada do item ou a inclusão do seguinte texto:

“No caso do software em questão possuir licenciamento livre, o mesmo deve ser

disponibilizado nos termos na IN 01/2011 do SLTI/MPOG, a IN do Software Público,

cumprindo todos os requisitos para ser disponibilizados no Portal.”

Na IN em questão já está contemplada a necessidade de possuir uma instituição mantenedora

do software. </mtmet>

<mtmet> TEC.4. Ações para introduzir inovações no software são estimuladas e realizadas.

O texto não contempla o caso do software desenvolvido ser livre e ser mantido de maneira

descentralizada. O Portal do Software Público é uma grande fonte de estímulo à inovação,

e deveria ser incluído na análise.

Sugiro que seja incluído o seguinte texto:

“A organização deve disponibilizar o software no Portal do Software Público”

O próprio portal serve como ponto focal para agregação das colaborações. </mtmet>

<mtmet> TEC.5. A organização tem autonomia sobre as tecnologias relevantes e estratégicas

que estão presentes no software.

O item novamente ignora o caráter difuso do software livre. No modelo colaborativo cada

um é livre para melhorar o software como bem entender, desde que as melhorias voltem ao

desenvolvedor original.

Sugiro que o item seja removido no caso do software possuir licenciamento livre ou o

seguinte texto seja adicionado:

“No caso do licenciamento do software ser livre o item não se aplica. Para o caso de o

software ser livre mas possuir componentes proprietários, aos componentes aplicam-se as

mesmas regras”

Sugiro ainda que seja incluído o seguinte critério:

“Disponibilização do software no Portal do Software Público conforme previsto na IN

01/2011. Na IN referida os processos de gestão de desenvolvimento do software já estão

contemplados </mtmet>

<mtmet> 4.4 – Área de competência Gestão de Negócios (GNE)

GNE.2. A análise de produtos concorrentes ao software é planejada e realizada.

Como o software livre é por definição um bem anti-rival, o conceito de concorrência no

Mercado de Software não se aplica a seu desenvolvimento. Contudo, é importante monitorar

as tendências para evoluir ou integrá-las ao software em questão.

Sugiro a inclusão do seguinte texto:

“No caso do software em questão possuir licenciamento livre, a análise de novas

tendências deve considerar a possibilidade de inclusão de novas funcionalidades ao núcleo

do sistema, ou até mesmo a fusão de uma ou mais tecnologias livres” </mtmet>

<mtmet> GNE.3. Ações de antecipação e atendimento de necessidades de clientes, que

impactam negócios baseados em conhecimento relacionados ao software são planejadas e

realizadas.

No caso do modelo de desenvolvimento livre, o principal instrumento de monitoramento do

software é a comunidade. Assim, é importante considerar como evidência que a empressa em

questão conhece a comunidade e participa dela ativamente. Sugiro a inclusão do seguinte

item:

“No caso do software em questão possuir licenciamento livre, é importante saber se a

empresa conhece a comunidade e acompanha suas necessidades. O acompanhamento se dá

através da participação ativa em fóruns e/ou listas de discussões, além de outras

ferramentas de desenvolvimento colaborativo onde seja possível monitorar as demandas em

cima do software” </mtmet>

<mtmet> GNE.4. Instrumentos para direcionar a evolução do negócio relacionado ao software

são definidos e realizados.

No caso do modelo de desenvolvimento livre a evolução do software deve passar

necessariamente pela avaliação das necessidades da comunidade e da sociedade, em uma

análise mais profunda. Sugiro a inclusão do seguinte item:






<mtmet>4.6 Área de competência Gestão de Pessoas, Processos e Conhecimento (PPC)


PPC.4. O conhecimento gerado nas atividades tecnológicas e de negócio relacionado ao

software é documentado, disseminado e atualizado.

Em se tratando de projetos de desenvolvimento de software livre, é importante ressaltar a

figura da comunidade como membro central de documentação, disseminação e atualização. Um

sistema virtual de acompanhamento integrado é de extrema importância, além de um ambiente

colaborativo de desenvolvimento de software.

Sugiro a adição do seguinte item:

“No caso do software em questão possuir licenciamento livre é fundamental à organização

criar e manter comunidade aberta para comunicação com os usuários do software, além de

ambiente de desenvolvimento colaborativo. Sugere-se que o software seja disponibilizado

no Portal do Software Público conforme os termos da IN 01/2011, onde a empresa se

compromete a manter a comunidade funcionando.” </mtmet>

Atenciosamente,

Vítor Baptista.

===</thread>===[sequencial: 1]=========================================

===<thread>===[sequencial: 2]==========================================

Re: Contribuição a Consulta Pública pela Coordenação do Comitê de Implementação de

Software Livre

De : Consulta Publica <[email protected]> Qui, 13 de Dez de 2012 09:51

Assunto : Re: Contribuição a Consulta Pública pela Coordenação do Comitê de Implementação

de Software Livre

Para : Deivi Lopes Kuhn

Prezado,



CERTICS.

Atenciosamente,

Angela Maria Alves


From: "Deivi Lopes Kuhn"


Cc: "Machado", "Gabriela Fonseca da Silva", "Mariana Salomao Alexandre de Oliveira"

"Antonio Carlos Tiboni", "Sylas Rodrigues Mendes"

Sent: Wednesday, December 12, 2012 11:44:02 PM

Subject: Contribuição a Consulta Pública pela Coordenação do Comitê de Implementação de

Software Livre

Caros avaliadores,

O Comitê de Implementação de Software Livre, parte do programa de Governo Eletrônico

Brasília, e coordenado pelo SERPRO infelizmente não teve tempo hábil para promover um

debate suficiente sobre o tema em questão. Porém a sua coordenação, exercida pela

Coordenação de Assuntos Governamentais, apresenta esta contribuição ao debate.

<cpger> É importante ressaltar que a nossa posição é que foi impossível realizar uma

avaliação concreta e definitiva de um texto parcialmente publicado. A Metodologia afirma

que haverá um manual de aplicação para software livre, que ainda não foi confeccionado. A

Consulta Pública deveria ocorrer apenas após a publicação deste documento. </cpger>

Solicitamos desta maneira, de forma especial, que após de TODOS os documentos

relacionados à certificação haja um novo debate público sobre o tema.

Segue nossa contribuição:

i) Avaliamos que a METODOLOGIA possibilita a interpretação que SOFTWARES CANDIDATOS que

tenham sido desenvolvidos utilizando SOFTWARE LIVRE em seus componentes arquiteturais

tenham mais dificuldade ou mesmo impedimentos a uma avaliação positiva.

ii) O SERPRO desenvolve software livre, é também usuário de softwares e componentes

livres usados para desenvolvimento de software para nossos clientes e, ainda, atualmente

coordena as atividades do CISL (Comitê Técnico de Implementação do Software Livre no

Governo Federal) do Comitê Executivo de Governo Eletrônico. Além disso, internaliza

tecnologias que são baseadas em software livre (seja por estender um software livre ou

por usar em sua arquitetura componentes distribuídos sob licença livre). Essa

internalização, formalmente definida nos processos de ciclo de vida de tecnologia da

empresa ocorre tanto por relações comerciais quanto por iniciativa própria de aquisição e


operação de softwares livres ou daqueles listados no portal do Software Publico

BrasiLeiro.

Assim, caso a METODOLOGIA implique na impossibilidade, ainda que eventual, de algum

SOFTWARE LIVRE ter avaliação positiva como software nacional, isso pode ter impacto

bastante negativo na política tecnológica da empresa.

É inegável que o texto do TI Maior demonstra que houve uma disposição a incluir elementos

do software livre na composição do texto do Programa e, na METODOLOGIA, particularmente

em sua seção 3 (Visão Geral), porém, não conseguimos identificar em outras seções do

texto da METODOLOGIA critérios para avaliação e/ou exemplos de evidência dos casos

específicos de SOFTWARES CANDIDATOS que utilizam SOFTWARE LIVRE.

iii) Assim como o SERPRO, outros grandes compradores de tecnologia no governo seguem a

política de software livre e de governo eletrônico já amadurecidas ao longo de 10 anos

contando 3 administrações federais consecutivas sem que por isso pequenos, médios ou

grandes fornecedores nacionais tenham sido preteridos. Por vezes, foram até mesmo

beneficiados por serem capazes de utilizar,estender, modificar e operar SOFTWA RE LIVRE.

iv) Além de contribuições pontuais enviadas para a Consulta Pública, gostaríamos de

listar aqui nossos pontos de maior preocupação, ora explicitando uma seção do texto

quando pertinente, ora omitindo um ponto específico por se tratar de lacunas ou de

características presentes em várias partes do documento da METODOLOGIA .

a) Texto incompleto: guia de uso para “aplicação da Metodologia CERTICS em software livre

e de código aberto ” previsto apenas para um momento futuro.

b) Questões relacionadas a autonomia na decisão de mudança nos componentes

c) Criticas a Patentes de Software (TEC5)

d) Metodologia e Modelo sustentáveis a partir de “padrões abertos”

<mtred> e) Carência de definição de fronteira arquitetural entre componentes e o software

sendo desenvolvido.</mtred>

<ctmic> f) Esforço para MPEs conseguirem certificar CERTICS </ctmic>

<ctsws> g) Como está contemplado o serviço de desenvolvimento de software? </ctsws>

<mtred> a) acreditamos que é necessário que o desenvolvimento do SOFTWARE CANDIDATO

utilizando SOFTWARE LIVRE esteja explícito desde a primeira versão publicada da

METODOLOGIA. </mtdred>

Assim, ficará mais evidente que a METODOLOGIA está alinhada com as políticas de

informática para o desenvolvimento do setor no País e também para o Governo Eletrônico.

De modo a tranquilizar as empresas que utilizam tecnologias com licenças livres e que

desejam candidatar produtos delas a certificação.

<mtmet> b) Em alguns resultados esperados e exemplos de evidências nas seções 4.2 Área de

competência Desenvolvimento (DES) e 4.3 Área de competência Gestão de Tecnologia (TEC),

há referências a autonomia da equipe de desenvolvimento quanto a modificação de

componentes adquiridos e tecnologias usadas no SOFTWARE CANDIDATO. É preciso notar que,

em casos de tecnologias de software livre, desenvolvidas de forma comunitária, comumente

a autonomia e o poder de decisão são também distribuídos entre vários colaboradores do

projeto. Esses colaboradores podem não incluir os desenvolvedores envolvidos no

desenvolvimento do SOFTWARE CANDIDATO e podem ainda não acatar alguma sugestão por eles

feita. </mtmet>

<mtmet> c) Embora a descrição da TEC5 traga elementos interessantes sob a premissa de que

a equipe de desenvolvimento possa modificar o software de tecnologias presentes no

SOFTWARE CANDIDATO, dentre os exemplos de evidência lista-se “Registro de patente ou de

propriedade intelectual, realizada no Brasil. ”. Entendemos que a adoção do conceito de

Patentes de Software(hoje inexistente) na legislação de propriedade industrial brasiLeira

seria maléfica ao nosso mercado interno e um fator complicador do desenvolvimento de

competências tecnológicas e de tecnologia e inovação do País. </mtmet>

<mtmet> c.1) Por oportuno, gostaríamos de sugerir aceite de evidencias do processo de

publicação de um SPB como evidencias para a Metodologia CERTICS não somente como

evidência do papel dos desenvolvedores do SOFTWA RE CANDIDATO na decisão de mudança do

mesmo , como nos exemplos de evidência de outros resultados esperados nas 5 áreas da

METODOLOGIA. </mtmet>

<mtmet> d) Sentimos falta de exemplos de evidência que contemplem a criação de

desenvolvedores (fornecedores nacionais) especializados em módulos baseados em padrões

abertos oriundos de tecnologia nacional ou estrangeira. De forma que tais fornecedores


possam ofertar para diversos compradores e não apenas para demandadores originais. Isso

potencializará o desenvolvimento de Inovação Secundária tanto aos fornecedores nacionais

quanto para os compradores dos serviços que poderão recombinar módulos e partes

ajustadas, de diferentes origens, resultando em produtos inéditos igualmente nacionais e

inovadores. </mtmet>

d1) Segundo a METODOLOGIA(pag.5) atividade definida é aquela “atividade que está

minimamente documentada e é praticada na Unidade Organizacional.”

<mtmet> d2) Algumas passagens explicitam a necessidade da definição e documentação estar

disponível e ser recuperável apenas “pelos envolvidos nas atividades de desenvolvimento”.

Dessa forma, o não- uso de padrões abertos de documentação pode significar a quebra do

ciclo de desenvolvimento de competências nacionais, particularmente nos casos de

transferência de tecnologia e DESENVOLVIMENTO COLABORATIVO. </mtmet>

e) Sentimos Carência de definição de fronteira arquitetural entre componentes e SOFTWARE

CANDIDATO.

<mtmet> e1) em DES1 a concepção de requisitos pode incluir requisitos que apontam ou

modificam componentes externos utilizados no desenvolvimento do SOFTWARE CANDIDATO.

</mtmet>

<mtred> e2) em DES2 quanto trata-se da Arquitetura e solução técnica do software

desenvolvido na unidade organizacional, sentimos falta de alguma definição ou critérios

de definição do que é “alteração significativa[METODOLOGIA DES2]” </mtred>

assim como da definição ou de critérios para definição da fronteira arquitetural conforme

(e1)

<ctmic> f) Avaliamos que a Metodologia apresenta uma carga de trabalho adicional caro a

micro, pequenas e medias empresas. </ctmic>

Essas, muito frequentemente tem alto grau de especialização em expertises indispensáveis

a determinados projetos de tecnologia contratados pelo governo.

<mtmet> f1) Além disso, A Metodologia é muito abrangente utilizando critério único para

todos os tipos de Unidades Organizacionais. Aparentemente sem levar em conta questões

como porte (Micro, Pequena, Média, Grande) , Caracterização Social (com ou sem fins

lucrativos, pesquisa, cooperativa)</mtmet>

<mtmet> g) No caso, O desenvolvimento do software é o objeto de contrato. O software

ainda não foi desenvolvido, logo não há evidências dos requisitos definidos,

desenvolvimentos para rastrear, atividades de gestão relatadas, identificação prévia de

todos os desenvolvedores envolvidos e outros aspectos que não se pode evidenciar antes de

ter o software desenvolvido. </mtmet>

GLOSSARIO

METODOLOGIA : Metodologia CERTICS para Software, Versão para Consulta Pública

(20/08/2012).

http://www.certics.cti.gov.br/downloads/MetodologiaCERTICS_20ago2012_v1.pdf

SOFTWARE CANDIDATO: Software hipotético e seus serviços associados que no futuro venha a

aplicara para a certificação CERTICS

SOFTWARE LIVRE: software distribuído sob licença livre reconhecida pela FSF ou OSI e que

siga as 4 liberdades definidas pela FSF. LINK

CISL: Comitê Técnico de Implementação de Software Livre do Governo Federal

DESENVOLVIMENTO COLABORATIVO: Modelo de desenvolvimento realizado de forma distribuída,

ou não, por entidades e indivíduos ligados a uma mesma ou muitas organizações

-

"Esta mensagem do SERVIÇO FEDERA L DE PROCESSAMENTO DE DA DOS (SERPRO), empresa pública

federal regida pelo disposto na Lei Federal nº 5.615, é enviada exclusivamente a seu

destinatário e pode conter informações confidenciais, protegidas por sigilo profissional.

Sua utilização desautorizada é ilegal e sujeita o infrator às penas da Lei. Se você a

recebeu indevidamente, queira, por gentileza, reenviá-la ao emitente, esclarecendo o

equívoco."

"This message from SERVIÇO FEDERAL DE PROCESSA MENTO DE DADOS (SERPRO) -- a government

company established under Brazilian law (5.615/70) -- is directed exclusively to its

addressee and may contain confidential data, protected under professional secrecy rules.


Its unauthorized use is illegal and may subject the transgressor to the law's penalties.

If you're not the addressee, please send it back, elucidating the failure."



Re: Consulta Pública - CERTICS - Comentários da Seção Americana do CEBEU


Qui, 13 de Dez de 2012 09:52

Assunto : Re: Consulta Pública - CERTICS - Comentários da Seção A mericana do CEBEU

Para : Monique Fridell

Prezado,



CERTICS.

Atenciosamente,

Angela Maria Alves


From: "Monique Fridell" To:"[email protected]"

<[email protected]>


Subject: Consulta Pública - CERTICS - Comentários da Seção Americana do CEBEU

A/C: Secretário Virgílio Augusto Fernandes Almeida

Prezado Senhor Secretário,

Em nome da Seção Americana do Conselho Empresarial Brasil-Estados Unidos (CEBEU), envio,

anexo, documento com comentários sobre a Metodologia CERTICS para Software.

Permaneço à disposição do senhor e de sua equipe para esclarecimentos adicionais.

Respeitosamente,

Monique Fridell

Diretora Executiva

Conselho Empresarial Brasil-Estados Unidos -- Seção Americana


ANEXO US Chamber




Re: Dúvidas e contribuições



Qui, 13 de Dez de 2012 09:53

Assunto : Re: Dúvidas e contribuições

Para : Gabriela Fonseca Silva de Oliveira

Prezado,



CERTICS.

Atenciosamente,

Angela Maria Alves


From: "Gabriela Fonseca Silva de Oliveira"



Subject: Dúvidas e contribuições

<mtmet> Boa noite, no final da página 31, item 4.3 TEC 5 existe uma imprecisão

conceitual. Entre os exemplos de evidência sobre a autonomia técnica e decisória da

empresa em realizar o acesso e modificações nas tecnologias utilizadas sugere-se como

evidência o registro de patente e o atestado de propriedade.

No Brasil, assim como na grande maioria dos Países do mundo não é aceito patentes para

software. O mecanismo legal para garantir a propriedade é o registro, baseado na Lei de

direito autoral, no Instituto Nacional de Propriedade Intelectual.

Além disto há, no texto proposto, a previsão de um atestado de propriedade. O INPI, órgão

responsável por garantir a autoria de software, não emite este tipo de certificado e não

existe um outro órgão ou associação que possa fazer isto com base legal.

Neste mesmo item deveria ser considerado a utilização de tecnologias de Software Livre,

visto que o licenciamento livre é a forma mais eficiente de garantir a autonomia e

liberdade dos usuários dos softwares para a realização de alterações.

Também é importante ressaltar que a autonomia está relacionada com a capacidade de

realizar as alterações para cada necessidade, mas que nem sempre a comunidade responsável

pelo software livre irá implementar a contribuição recebida, ela possui autonomia,

normalmente baseada em princípios como meritocracia. Porém esta característica em nada

afeta o acesso da empresa a tecnologia utilizada e mantém a sua independência de

organizações estrangeiras. </mtmet>

Atenciosamente,

Gabriela Fonseca Silva de Oliveira

Analista

CETEC - Coordenação Estratégica de Tecnologia

SERPRO - Serviço Federal de Processamento de Dados

A mente que se abre a uma nova ideia jamais voltará ao seu tamanho original.

Albert Einstein

-

"Esta mensagem do SERVIÇO FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO), empresa pública

federal regida pelo disposto na Lei Federal nº 5.615, é enviada exclusivamente a seu

destinatário e pode conter informações confidenciais, protegidas por sigilo profissional.

Sua utilização desautorizada é ilegal e sujeita o infrator às penas da Lei. Se você a

recebeu indevidamente, queira, por gentileza, reenviá-la ao emitente, esclarecendo o

equívoco."

"This message from SERVIÇO FEDERAL DE PROCESSA MENTO DE DADOS (SERPRO) -- a government

company established under Brazilian law (5.615/70) -- is directed exclusively to its

addressee and may contain confidential data, protected under professional secrecy rules.

Its unauthorized use is illegal and may subject the transgressor to the law's penalties.

If you're not the addressee, please send it back, elucidating the failure."



Re: Consulta Pública sobre o programa estratégico de software e serviços de TI


Qui, 13 de Dez de 2012 09:54

Assunto : Re: Consulta Pública sobre o programa estratégico de software e serviços de TI

Para : Frank Caramuru

Prezado,




CERTICS.

Atenciosamente,

Angela Maria Alves


From: "Frank Caramuru" To: "Consulta publica" <[email protected]>


Subject: FW: Consulta Pública sobre o programa estratégico de software e serviços de TI

From: Frank Caramuru

Sent: quarta-feira, 12 de dezembro de 2012 17:59

To: '[email protected]'

Subject: Consulta p[ublica sobre o programa estratégico de software e serviços de TI

Prezados Senhores,

Vimos pela presente apresentar nossos comentários em resposta à Consulta Pública em

referência.

Atenciosamente,

http://bsa-web.sharepoint.com/SiteImages/bsa_new_logo.pngFrank

Caramuru

Brazil Country Manager

BSA | The Software Alliance

De : Frank Caramuru

Qua, 12 de Dez de 2012 18:18

Assunto : FW: Consulta Pública sobre o programa estratégico de software e serviços de TI

1 anexo


ANEXO BSA




Re: Consulta publica sobre o programa estratégico de software e serviços de T I


Qui, 13 de Dez de 2012 09:54

Assunto : Re: Consulta publica sobre o programa estratégico de software e serviços de TI

Para : Frank Caramuru

Prezado, Obrigada pela contribuição. Todas as contribuições da Consulta Pública serão

analisadas e serão publicadas no site da CERTICS.

Atenciosamente,

Angela Maria Alves


From: "Frank Caramuru"



Subject: Consulta p[ublica sobre o programa estratégico de software e serviços de TI

Prezados Senhores,

Vimos pela presente apresentar nossos comentários em resposta à C onsulta Pública em

referência.

Atenciosamente,

http://bsa-web.sharepoint.com/SiteImages/bsa_new_logo.pngFrank

Caramuru

Brazil Country Manager



Re: Consulta Pública


Qui, 13 de Dez de 2012 09:54

Assunto : Re: Consulta Pública

Para : José Maria Villac Pinheiro

Prezado,



CERTICS.

Atenciosamente,

Angela Maria Alves


From: "José Maria Villac Pinheiro"



Subject: Consulta Pública

Senhores(as):

Em nosso entendimento software livre é aquele desenvolvido no País sem a utilização de

bibliotecas/componentes proprietárias que requeiram pagamento de royalties na

distribuição.

Também em nosso entendimento o software é livre quando utilizada por exemplo a componente

Java, hoje da Oracle, ou qualquer tipo de compilador, pago ou não, desde que a utilização

do compilador não implique em pagamento de royalties na utilização das componentes do

mesmo, quando distribuído o software.

Para nós compiladores que exigem o pagamento de licença para a instalação do software

gerado no cliente ou servidor, não é considerado software livre.

Entendemos que compiladores que possuam custo de aquisição para o desenvolvedor, o qual

gera artefatos de software que podem ser distribuídos livremente, sem necessidade de

pagamento de royalties pela distribuição, são considerados software desenvolvidos

completamente no Brasil e livres.


Att,

Eng. José Maria Villac Pinheiro

NEXUS GeoEngenharia



Re: Resposta da Ericsson à Consulta Pública do MCT I sobre SW nacional


Qui, 13 de Dez de 2012 09:55

Assunto : Re: Resposta da Ericsson à Consulta Pública do MCTI sobre SW nacional

Para : ALESSANDRO QUATTRINI

Prezado,



CERTICS.

Atenciosamente,

Angela Maria Alves


From: "ALESSANDRO QUATTRINI"


Cc: "RICARDO TAVARES"

Sent: Wednesday, December 12, 2012 9:51:21 A M

Subject: Resposta da Ericsson à Consulta Pública do MCTI sobre SW nacional

Prezados Srs.,

A Ericsson Telecomunicações S.A. vem por meio desta mensagem apresentar no documento

anexo resposta com nossos comentários à Metodologia CERTICS para Software de 20 de agosto

de 2012.

Permanecemos desde já à disposição de V. Sas. para qualquer informação adicional.

Atenciosamente,

ALESSANDRO QUATTRINI

Government & Industry Relations Manager

Ericsson do Brasil Telecomunicações S.A.

De : ALESSANDRO QUA TTRINI

Qua, 12 de Dez de 2012 17:03

Assunto : Re: Resposta da Ericsson à Consulta Pública do MCTI sobre SW nacional

Para : Consulta Publica <[email protected]>

Cc : RICARDO TA VARES

Cara Angela,

Muito obrigado por seu e-mail. Temos uma dúvida: as contribuições a serem publicadas no

site da CERTICS serão identificadas?

Obrigado novamente,

Alessandro Quattrini

Ericsson Telecounicações S.A.

Enviado via iPad

Em 12/12/2012, às 16:27, "Consulta Publica"

ANEXO ERICSSON

Resposta da Ericsson à Consulta Pública

sobre Software Nacional do MCTI

Ao Ministério da Ciência, Tecnologia e Inovação(MCTI)

Referência: Consulta Pública para Metodologia de Definição de Software Nacional de 20 de

agosto de 2012 (“CERTICS”)

Sumário Executivo


A Ericsson propõe que a proposta atual de certificação de software como nacional seja

arquivada e que uma nova proposta, mais realista e inclusiva, venha a ser formulada e

posta em discussão.

Nossa contribuição está focada na análise do conceito de “autonomia tecnológica”, cujas

implicações poderiam ser colocadas de maneira transparente; na preocupação com a

capacitação e competitividade internacional do software brasileiro, inexistentes no texto

da presente consulta; e na simplificação de critérios de avaliação dentro de um contexto

de uma empresa real, inserida no mercado altamente dinâmico do setor de software.

Introdução

A Ericsson Telecomunicações S.A., fazendo negócios no Brasil desde o século XIX e

incorporada no País há 88 anos, com investimentos em pesquisa & desenvolvimento no Brasil

de mais de R$1 bilhão na última década e meia, com grande ênfase em software, vem

apresentar comentários à proposta de definição de software nacional apresentada por este

Ministério (“Metodologia CERTICS para Software”, colocada em Consulta Pública em 20 de

agosto de 2012).

Com três centros de P&D no Brasil em Indaiatuba (SP), São Paulo (SP) e Salvador (BA),

focados principalmente no desenvolvimento de software e com mais de 400 desenvolvedores,

a Ericsson possui experiência relevante tanto mundial quanto de País que esperamos possa

contribuir para esta discussão. A Ericsson, como empresa mundializada, adota modelo de

Pesquisa & Desenvolvimento (“P&D”) de produtos — aí incluídos software e hardware —

compartilhado em diferentes partes do mundo e com base em inovação aberta (envolvendo

centros de pesquisa e universidades brasileiras, com partes da pesquisa e desenvolvimento

internalizadas e outras externalizadas). Dos mais de 180 Países onde a Ericsson está

presente, somente 17 Países conduzem P&D em seus respectivos Centros. Vale lembrar que,

na América Latina, o Brasil é o único País no qual realizamos atividades de P&D.

Comentários

1. “Autonomia tecnológica” nacional ou atração de Centros Internacionais de P&D?

Uma das preocupações centrais que temos, neste sentido, é sobre o conceito de “autonomia

tecnológica” nacional conforme sugerido no documento sobre software nacional do MCTI: “O

aumento da autonomia tecnológica no País são contribuições para ampliação da base

tecnológica nacional e para capacidade de uso desta base para tomada de decisões de forma

independente e para controlar conjuntamente processos que se produzem dentro e além das

fronteiras nacionais”. É importante que a política de apoio ao desenvolvimento de

software no Brasil deixe claro se este texto procura atrair centros de desenvolvimento

internacionais.

Se o objetivo da política é incrementar a capacidade de desenvolvimento de software no

Brasil, tanto por empresas brasileiras de capital internacional quanto por empresas

brasileiras de capital nacional, o modelo de desenvolvimento de software da Ericsson

encontra-se contemplado. No entanto, se o objetivo é definir “autonomia tecnológica” como

todas as decisões relevantes sobre o desenvolvimento de produtos sendo feitas

exclusivamente no Brasil, a Ericsson seria excluída e desencorajada de ampliar os seus

investimentos em desenvolvimento de software no País.

Todas as duas estratégias são legítimas em termos de políticas públicas, apresentando

seus respectivos custos e benefícios. Mas é preciso haver clareza e transparência, para

evitar eventuais contradições com a política governamental de trazer competitividade à

área de P&D do Brasil para atrair grandes centros internacionais, juntamente com o

crescimento dos investimentos de empresas brasileiras de capital nacional em P&D, como

definido pelo programa da Presidenta da República, Dilma Rousseff, o Brasil Maior.

Ao estabelecer que a tomada de decisões sobre software seja feita de forma totalmente

independente no Brasil, o texto atual vislumbra cenários em que:

O processo de tomada de decisões de uma empresa mundializada, com matriz no

exterior e forte presença no Brasil, seja totalmente transferido e centralizado

unicamente no Brasil; ou

Que seja criado um corpo diretivo no Brasil, independente e alheio aos demais

Centros de P&D existentes no mundo, para tomada de decisões de desenvolvimento de

software a ser endereçado única e exclusivamente ao mercado brasileiro.


Os dois cenários indicados acima são incompatíveis com o modelo de desenvolvimento

compartilhado entre diferentes Países, utilizado pela Ericsson e por outras empresas

brasileiras de capital internacional.

<mtmet> Empresas como a Ericsson, ao serem alijadas de obter a certificação de software

nacional, tenderiam a reduzir os seus investimentos em desenvolvimento de software no

Brasil, dada a impossibilidade, no mundo globalizado atual, de se desenvolver software

(assim como hardware) de maneira confinada em um único País, para geração de produtos

voltados a um único mercado deste mesmo País. O que torna estas empresas competitivas é

tanto o desenvolvimento mundializado entre vários Países quanto o foco no mercado global,

que dá escala aos produtos.

Ao estabelecer que para a certificação seja necessário encontrar informações que mostrem

que “a ideia que originou o software foi concebida no País...”, o documento elimina por

completo a possibilidade de um Centro de P&D instalado no Brasil ser designado, por

exemplo, pela matriz de uma multinacional para receber investimentos e capacitações a fim

de desenvolver um software no Brasil com base numa ideia originada no exterior. Não se

trata de que “pedaços” de uma solução desenvolvida no Brasil obtenham o status de

software nacional, mas sim que uma solução completa, desenvolvida no Brasil, possa obter

a certificação, independentemente de onde tenha sido idealizada.

Ideias de produtos são, muito frequentemente, geradas por demandas de clientes em

diversos Países. Ou mesmo elaborações definidas a partir do diálogo com o setor

industrial, de padrões e normas consensuais (União Internacional de Telecomunicações,

3GPP e outros organismos de internacionais) sobre tecnologias que garantam o

funcionamento, a interoperabilidade e a integração dos sistemas no mundo. E seu

desenvolvimento é alocado para centros onde exista capacidade e competitividade para

oferecer a solução de desenvolvimento.

A realidade de uma empresa mundializada é caracterizada por uma intensa disputa entre

Centros de P&D de diferentes partes do planeta, para atrair projetos de desenvolvimento

que possam ter sido idealizados em qualquer outra parte do mundo, ou mesmo baseados em

plataformas globais pré-existentes. Tal disputa se dá pela atração de investimentos

estrangeiros que capacitam profissionais brasileiros e geram conhecimento, tecnologia,

empregos e renda no Brasil. Enfim, estes investimentos promovem, em última análise, o

desenvolvimento nacional. Portanto, o documento do MCTI, se deixado como está,

enfraqueceria sobremaneira a posição da Ericsson Telecomunicações para atrair estes

investimentos dentro da cadeia de inovação da Ericsson e teria um efeito negativo no

desenvolvimento da indústria de software do Brasil. </mtmet>

2. O Brasil como único mercado ou a competitividade internacional?

<mtmet> O texto não menciona, no transcorrer de suas 78 páginas, exportações e inserção

competitiva de software desenvolvido no Brasil em mercados internacionais. Corremos o

risco de reduzir a oferta de soluções ao governo brasileiro a um grupo muito pequeno de

empresas certificadas, ao mesmo tempo em que estas empresas não teriam nenhum incentivo

de procurar escala mundial para os seus produtos.

A totalidade do software desenvolvido no Brasil pela Ericsson é utilizada aqui e é também

exportada para unidades da Ericsson de outros Países. Isto é altamente benéfico ao

Brasil, ao capacitar pesquisadores brasileiros a desenvolver, em nosso País, software

competitivo e em escala global.

O documento não dá ênfase na possibilidade de software desenvolvido no Brasil endereçar

mercados internacionais. Entendemos que vincular exportação de software desenvolvido no

Brasil — independentemente de onde tenha sido originada a decisão de se desenvolver

software no Brasil — à certificação de software nacional seria uma política altamente

benéfica ao Brasil, pois resultaria em aumento significativo de investimentos em

capacitação de pesquisadores brasileiros. </mtmet>

3. Certificação da “superempresa”nacional ou dinâmica inovadora do mercado?

<mtmet> O documento define os critérios de análise, estabelecendo a avaliação de cinco

áreas distintas de competências: Desenvolvimento, Gestão de Tecnologia, Gestão de

Negócios, Gestão de Parcerias e Alianças e Gestão de Pessoas, Processos e Conhecimento.

Apesar do esforço de prover objetividade, existe um grande componente de subjetividade

resultante da necessidade de se atribuir notas F (Completamente atendido > 85% a 100% de

alcance) ou L (Largamente atendido >50% a 85% de alcance) a todos os “Resultados


Esperados” de cada área para que um Software seja certificado como desenvolvido no

Brasil. </mtmet>

A avaliação consiste de 25 itens:

- sete Resultados Esperados para Desenvolvimento,

- cinco Resultados Esperados para Gestão de Tecnologia,

- cinco Resultados Esperados Gestão de Negócios,

- três Resultados Esperados para Gestão de Parcerias e Alianças, e de

- cinco Resultados Esperados para Gestão de Pessoas, Processos e Conhecimento.

<mtmet> Uma única pontuação P (Parcialmente atendido) ou N (Não atendido) de até 49% de

alcance para qualquer um dos 25 Resultados Esperados já seria suficiente para

desqualificar o software avaliado. </mtmet>

<mtmet> O ponto principal a considerarmos aqui, no entanto, é que, na dinâmica do

mercado, a liderança de uma empresa nunca está focada em tantos critérios gerenciais ao

mesmo tempo, pois responde a mudanças constantes do mercado em um setor

extraordinariamente dinâmico. Nesta dinâmica de mercado, a liderança empresarial foca em

momentos diferentes em aspectos diferentes do desafio de desenvolvimento. Os critérios,

em seu conjunto, definem menos o que é “nacional” e mais o conceito de uma “superempresa”

teórica, que só poderia existir com fortes subsídios governamentais, “independente” da

dinâmica do mercado real de uma das indústrias mais desafiadoras e mutantes do mundo

atual, a de tecnologias da informação e comunicação. </mtmet>

Por tudo isto, a Ericsson sugere, muito respeitosamente, que a atual proposta seja

arquivada e que as contribuições dos vários respondentes a esta consulta sejam utilizadas

para definir uma nova proposta de apoio e certificação ao software nacional, com

critérios mais realistas e inclusivos que visem a fortalecer o desenvolvimento da

indústria de software no Brasil.



Re: Consulta Pública Certics

Prezado,



CERTICS.

Atenciosamente,

Angela

----- Mensagem original -----

De:

Para: "Consulta publica" <[email protected]>, "Consulta publica"

<[email protected]>

Cc: Enviadas: Quarta-feira, 12 de Dezembro de 2012 16:00:28

Assunto: Consulta Pública Certics

Prezados senhores,

Enviamos para análise nossos comentários a respeito da Metodologia CERTICS.

Colocamo-nos à disposição para qualquer esclarecimento.

Atenciosamente,

Michaelle.


ANEXO IBM




Re: CERTICS - Consulta Pública com Participação Cidadã


Qua, 12 de Dez de 2012 16:24

Assunto : Re: CERTICS - Consulta Pública com Participação Cidadã

Para : Ronaldo Cardozo Lages

Prezado,



CERTICS.

Atenciosamente,

Angela


De: "Ronaldo Cardozo Lages"

Para: "CERTICS Consulta Pública" <[email protected]>

Enviadas: Quarta-feira, 12 de Dezembro de 2012 15:47:09

Assunto: CERTICS - Consulta Pública com Participação Cidadã

Prezados,


todas referentes ao item 4 - Modelo de Referência para Avaliação CERTICS. Em meu





























mesmo.





</mtmet>







software.”




públicos.




Organizacional.




que realizaram.”


















estrangeiras.










software.”






























mesmas regras”
















realizadas.




item:
















<mtmet>4.6 Área de competência Gestão de Pessoas, Processos e Conhecimento (PPC)













Cordiais saudações...

Paz, Vida Longa e Próspera.

Logomarca do Governo Tarso Genro|

| Ronaldo Cardozo Lages

GG/RS - Gabinete do Governador - Governo do Estado do Rio Grande do Sul


O conteúdo desta mensagem é de uso restrito e confidencial, sendo o seu sigilo protegido

por Lei. Estas informações não podem ser divulgadas sem prévia autorização escrita. Se tu

não és o real destinatário dessa mensagem, ou o responsável pela sua entrega, apague-a

imediatamente e avise ao remetente, respondendo a esta mensagem. O Gabinete do Governador

do Estado do Rio Grande do Sul não se responsabiliza por conclusões, opiniões ou outras

informações nesta mensagem que não se relacionem com suas ações. Agrademos tua

colaboração preservando a ética no uso de e-mails.



Re: Contribuições para a Metodologia CERTICS


Qua, 12 de Dez de 2012 16:24

Assunto : Re: Contribuições para a Metodologia CERTICS

Para : Edson Nery

Prezado,



CERTICS.

Atenciosamente,

Angela


De: "Edson Nery"

Para: "Consulta publica" <[email protected]>


Assunto: Contribuições para a Metodologia CERTICS

Prezados,

Segue material que preparamos, contendo algumas observações, questionamentos e sugestões

sobre alguns pontos que, pelo nosso entendimento, poderiam reforçar o espírito que

norteia a Metodologia de certificação a ser implantada.

Me coloco à disposição para tratar de qualquer ponto que necessite algum esclarecimento.

Atenciosamente

Edson Nery

Brazil R&D

Hewlett-Packard Company

Esta mensagem e os arquivos nela contidos são confidenciais e legal mente protegidos,

somente podendo ser usada pelo indivíduo ou entidade a quem foi endereçada. Caso você a

tenha recebido por engano, você deverá devolvê-la ao remetente e, posteriormente, apagá-

la, pois, a disseminação, encaminhamento, uso, impressão ou cópia do conteúdo desta

mensagem são expressamente proibidos.

ANEXO HP

Metodologia CERTICS para Software

Uma apresentação

A HP Brasil, através de seu ecossistema de P&D, que tem como base a sua área de Pesquisa

e Desenvolvimento, vem, ao longo dos anos, demonstrando como é possível agregar

competências e desenvolver talentos. Atualmente ela conta, no País, com mais de mil

colaboradores atuando em mais de 60 Programas de P&D. Esses Programas, que vão da

microeletrônica ao desenvolvimento de novos negócios baseados no conhecimento, têm

contribuído para o aumento da autonomia tecnológica do País, a geração de novos negócios

e como aumento do volume de inovações.

Boa parte dos mais de mil colaboradores é formada por estudantes e estagiários que atuam

diretamente nos programas de P&D ou estão sendo capacitados através dos Programas

educacionais. Isso faz com que o conhecimento seja cada vez mais disseminado na sociedade

como um todo, aumentando a geração de competências tecnológicas locais.


Da forma com está estruturado, esse ecossistema garante o aprimoramento da tecnologia,

pois desenvolve seu próprio corpo de competências internas, naqueles Programas que rodam

apenas dentro da empresa, e desenvolve competências adicionais naqueles Programas que

rodam no modelo colaborativo ou nos Programas Educacionais.

Como estamos focados em Programas de alto impacto na estratégia mundial da HP, estamos

promovendo a disseminação de competências em tecnologias de ponta e criando capacitação

local com grande potencial de gerar inovação e de gerar novos modelos de negócios.

Dado o ecossistema descrito resumidamente acima, entendemos que estamos desenvolvendo SW

em sintonia com o que a Metodologia defende, ou seja: aquele cujo desenvolvimento cria ou

amplia competências tecnológicas e correlatas no País, contribuindo para a criação de

negócios baseados em conhecimento e aumento de autonomia tecnológica.

Comentários e questionamentos

<cgelo> São grandiosos e importantes os pontos ressaltados na Metodologia. A avaliação,

da forma que está proposta, sem sombras de dúvida, será capaz de identificar as

evidências de que um determinado software foi realmente desenvolvido no País. Ressalta-se

que quanto maior for a valorização daquilo que está sendo desenvolvido em Centros de

Desenvolvimento locais e gerando inteligência local, e quanto maior for o cuidado para

evitar a valorização de ações esporádicas ou oportunistas, maior será o sucesso da

aplicação do que está sendo proposto. </cgelo>

<mtmet> Outro comentário que consideramos importante é com relação a como avaliar e

separar aquilo que se considera simplesmente ‘building’ ou seja, a simples coletânea de

um conjunto de códigos e/ou bibliotecas para montagem de uma solução, daquilo que é

realmente o desenvolvimento de uma solução. Dada a avaliação proposta, acreditamos que o

simples ‘building’ pode ser considerado um desenvolvimento local e isso não estaria

totalmente alinhado com a proposta maior da Metodologia, como é dito na primeira camada,

onde se define: “Software resultante do desenvolvimento tecnológico e inovação realizados

no País como aquele cujo desenvolvimento cria ou amplia competências tecnológicas e

correlatas no País, contribuindo para a criação de negócios baseados em conhecimento e

aumento de autonomia tecnológica.” </mtmet>

<mtmet> Importante ressaltar outra questão quando se quer considerar softwares na forma

de aplicativos ou de infraestrutura intensivos em conhecimento e resultantes do

desenvolvimento tecnológico e inovação realizados no País: dependendo da aplicabilidade

ou das plataformas de uso, muitos softwares que empregaram alto grau de conhecimento e

inovação para seu desenvolvimento podem estar presentes somente em conjunto com outros

softwares ou, então, como parte de um pacote vendido em determinados equipamentos.

Entendemos que é válida a tentativa de buscar uma certificação para um SW desse tipo,

entretanto, não encontramos uma ligação do SW em si com o pacote ou o produto em questão

(o mesmo raciocínio vale para SW embarcado, discutido mais abaixo, neste mesmo

documento). Sendo assim, faz-se necessário esclarecer este aspecto sob risco de o País

perder grandes oportunidades de atrair investimento em desenvolvimento de novos conjuntos

de aplicações/produtos. </mtmet>

Além do exposto acima, identificamos alguns pontos de indagação e temos algumas sugestões

a fazer, conforme segue:

<mtmet Software Embarcado

Questão. Supondo que um determinado SW embarcado, após ser avaliado conforme a

Metodologia proposta, seja certificado e sabendo que tal tipo de SW não tem aplicação se

não atrelado a um produto, pergunta-se:

Como será tratado o produto ao qual o SW se aplica?

Poderá, o referido produto, ao utilizar-se de um SW embarcado certificado, também

ser considerado um “produto desenvolvido no Brasil”?

Quais regras se aplicariam em um caso desses?

Sugestão.

Reforçando a importância da Metodologia, nos parece justo sugerir um ajuste no § 5º do

Artigo 3º da Lei 8.666 para que ela passe a mencionar os produtos que possuam SW

embarcado certificado, conforme abaixo:


§ 5o Nos processos de licitação previstos no caput, poderá ser estabelecida margem de

preferência para produtos manufaturados, produtos que contenham software embarcado

certificado pela Metodologia CERTICS e para serviços nacionais que atendam a normas

técnicas brasileiras.

Como mesmo objetivo, também ajustar o § 7º do Artigo 3º da Lei 8.666 para que passe a

mencionar os produtos que possuam SW embarcado certificado. Algo como segue:

§ 7o Para os produtos manufaturados, produtos que contenham software embarcado

certificado pela Metodologia CERTICS e serviços nacionais resultantes de desenvolvimento

e inovação tecnológica realizados no País, poderá ser estabelecido margem de preferência

adicional àquela prevista no § 5o. </mtmet>

<mtmet>Área de competência Desenvolvimento (DES)

Questão. Algumas vezes, como resultado de uma implementação bem-sucedida da área de

competência Desenvolvimento, um SW que teve seus requisitos desenvolvidos e suas

primeiras versões também desenvolvidas no País passa a ter sua evolução, através de novas

versões, desenvolvidas fora do País. Em um caso destes, considerando que as primeiras

versões sejam certificadas, seria possível pleitear a certificação das novas versões como

produto desenvolvido no País?

Este aspecto é importante, pois a arquitetura do software bem como a especificação de

requisitos e, muitas vezes, do próprio modelo de negócio, tem maior valor agregado do que

o desenvolvimento do código pura e simplesmente. Sendo assim, deve-se procurar proteger o

modelo de negócio e a importância dos requisitos por um tempo maior e, em nossa opinião,

de forma a cobrir e proteger, como se nacional fossem, as eventuais novas versões do

código que seriam desenvolvidas fora do País.

Questão: como considerar o desenvolvimento local de componentes que vão compor uma

solução de software integrada, sendo esta solução o produto que estará sendo de fato

colocada no mercado?

Sugestão: visto que há uma participação importante de equipes de desenvolvedores atuando

em território nacional, seria justo estabelecer uma pontuação proporcional no CERTICS,

pois isto seria um estímulo para que empresas globais instalassem cada vez mais centros

de competência em software no território nacional. </mtmet>

Porto Alegre, 11 de dezembro de 2012

P&D Hewlett-Packard Brasil Ltda.



Re: Consulta Pública - Metodologia CERTICS - CERTICS


Qua, 12 de Dez de 2012 16:25

Assunto : Re: Consulta Pública - Metodologia CERTICS - CERTICS

Para : Joana Almeida e Sousa

Prezado,



CERTICS.

Atenciosamente,

Angela


De: "Joana Almeida e Sousa"


Cc: "Ana Paula Bialer"


Assunto: Consulta Pública - Metodologia de A valiação - CERTICS

Prezados Senhores,


Apresentamos em anexo a este e-mail os comentários da Cisco do Brasil Ltda., à Consulta

Pública de 20 de Agosto de 2012, lançada pelo Ministério da Ciência, Tecnologia e

Inovação acerca da Metodologia CERTICS - CERTICS para Software.

Ficamos à inteira disposição do Ministério da Ciência, Tecnologia e Inovação para prestar

quaisquer esclarecimentos adicionais que porventura sejam necessários.

Atenciosamente,

Joana Almeida e Sousa


ANEXO CISCO




Re: Contribuição Brasscom à CERTICS


Qua, 12 de Dez de 2012 16:25

Assunto : Re: Contribuição Brasscom à CERTICS

Para : Antonio Gil, Edmundo

Prezado,



CERTICS.

Atenciosamente,

Angela


De: "Antonio Gil"



Assunto: Contribuição Brasscom à CERTICS

Ao CTI

Encaminhamos em anexo o posicionamento da BRASSCOM – Associação BrasiLeira das Empresas

de Tecnologia da Informação e Comunicação acerca da CERTICS.

Att,

Antonio Gil

ANEXO BRASSCOM

Ao Centro de Tecnologia de Informática Renato Archer

Resposta da BRASSCOM - Associação Brasileira das Empresas de Tecnologia da Informação e Comunicação à Consulta

Pública sobre Certificação de Tecnologia Nacional de Software e Serviços (CERTICs)

A BRASSCOM vem analisando com muito empenho, nos últimos 90 dias, o documento “Metodologia CERTICS para

Software”, elaborado pelo CTI Renato Archer para o MCTI e que é objeto da presente Consulta Pública. Apresentamos a seguir

as seguintes considerações e proposições, na certeza de contribuir positivamente para o objetivo do programa TI Maior de tornar

o Brasil mais inovador e competitivo globalmente no setor de software e serviços de Tecnologia da Informação.

1. Considerações técnicas:

<mtmet> 1.1. Sobre a definição de software:

Em primeiro lugar, entendemos que o esforço da Metodologia em buscar uma definição de software acaba por gerar

incertezas e ambiguidades, dada a natureza da composição do software.

Na página 16, temos o seguinte trecho:

"(...) O software resultante de desenvolvimento tecnológico e inovação realizados no País pode, então, apresentar-se tanto

na forma de software de infraestrutura, software básico (linguagem de programação, bancos de dados), embarcado, como

na forma de plataformas ou aplicativos intensivos em conhecimento."

Não existe clareza na definição acima citada para casos nos quais a Unidade Organizacional detenha controle completo

apenas de uma porção, componente ou tecnologia de software. Em muitos casos, desenvolver partes do software e da

tecnologia gera valor e capacitação tecnológica no País tanto quanto deter o controle de todo o software. </mtmet>

<mtmet> 1.2. Sobre a cadeia de produção de software:

Em segundo lugar, é importante ressaltar que a indústria de software tem uma característica marcante e diferencial das

demais. Desde o princípio de sua formulação, seja em plataformas abertas ou fechadas, os softwares mais competitivos e

dinâmicos são aqueles que buscam reunir contribuições de todas as partes e centros de inteligência do mundo. Mesmo um


projeto de software desenvolvido para um mercado específico, para ser competitivo, não desprezará os sistemas

operacionais, bancos de dados, bibliotecas de software e linguagens previamente existentes, originários de terceiros.

Parece-nos, portanto, um equívoco tentar definir algo em termos de “tecnologia nacional de software”, como composto na

própria sigla CTENIC, inapropriada a nosso ver.

Os requisitos propostos pelo texto em Consulta Pública incluem a maneira como a Unidade Organizacional deve operar e

onde as atividades devem acontecer,

transmitindo a impressão que somente neste modelo existe a geração de valor e tecnologia no País.

Esta restrição acaba por deixar de fora uma categoria significativa de laboratórios globalmente integrados, que produzem

componentes completos em cadeias complexas de produtos e soluções. Tal é o caso de unidades de empresas

multinacionais, nos quais tanto as atividades como a geração de valor estão distribuídas globalmente. Contudo, com a

intensa troca de experiências, todos acabam por adquirir competências e capacidade de produzir tecnologia. Assim,

quaisquer que sejam, as definições pretendidas para o software devem considerar a existência desses times globais.

</mtmet>

<mtmet> 1.3. Sobre o foco dos requisitos no software:

Os requisitos da Metodologia proposta focam excessivamente na equipe envolvida no desenvolvimento do software a ser

certificado, principalmente no que diz respeito às alianças estratégicas e parcerias de pesquisa. Na prática, muitos desses

acordos são construídos num contexto mais amplo de ambiente multiprojetos e multiequipes. Seria mais razoável que as

avaliações tivessem foco no ambiente em que a equipe do software está inserida, ou seja, a empresa. </mtmet>

<mtmet> 1.4. Sobre a pontuação:

Da forma e com os pressupostos com que foi concebida, a CERTICS gera entre as empresas associadas da BRASSCOM

um sentimento de insegurança quanto à suposta objetividade das pontuações e uma certeza de que ela imporá custos

desnecessários ao setor de software, além de potencialmente criar arestas e um campo de conflito de interpretações. Em vez

de consonância, a percepção dominante é que se pode acabar criando dissonância, pelas seguintes razões:

a. O processo de classificação da Metodologia que o avaliador executará é binário e vai resultar na avaliação de um

software numa escala de pontuação ordinal N (não atendido), P (parcialmente atendido), L (largamente atendido)

e F (completamente atendido).

Embora a descrição da avaliação no texto da CERTICS suponha um processo objetivo, há um claro sentimento

de que isso redundará em subjetividade do avaliador, dado que toda a Metodologia pressupõe uma prática ideal

de documentação que não ocorre no mundo real das empresas. Se grandes companhias terão dificuldade para

cumprir esses requisitos, imagine-se empresas de base tecnológica iniciantes em que, muitas vezes, o fator

decisivo é o envolvimento integral dos engenheiros e desenvolvedores de software na execução da atividade fim

da companhia;

b. A classificação binária é excludente, em vez de ser inclusiva, como poderia ser uma eventual classificação por

gradação;

c. Embora se projete um processo de certificação objetivo e de curta duração, o sentimento predominante é que

tenderá a se formar filas e delongas em todo o processo, encarecendo-o e complicando-o de forma crescente;

d. A formação de contenciosos será uma decorrência de um processo em que, por sua própria natureza, haverá a

interposição de recursos e disputas por causa de diferenças de avaliações;

e. A CERTICS implica ainda um nível indesejável de invasão em territórios que pouco têm a ver com a pretendida

formação de competência no País, dado que buscará, entre outras, informações sobre estratégias e alianças das

Unidades Organizacionais de uma dada companhia e que muito comumente fazem parte de estratégias, segredos

comerciais e política de proteção intelectual das firmas.

Por esses motivos, entendemos que se deve pensar num sistema mais inclusivo e, portanto, incentivador da multiplicação

da criação de valor no País. </mtmet>

2. Considerações de forma e conteúdo

<cgelo> A BRASSCOM reconhece como meritória a busca do MCTI para conferir bases objetivas à comprovação do

desenvolvimento de tecnologia no País, como parte do processo de compras públicas de software e serviços associados de

TI. A BRASSCOM reconhece também como sendo algo de seu interesse, e do interesse nacional, que esse processo

contribua para o aumento da capacitação e autonomia tecnológica do País, tornando a indústria de software e serviços de TI

mais competitiva globalmente.


Como afirmado no texto ora em consulta – “Metodologia CERTICS para Software” –, o objetivo a ser alcançado deve ser

uma “resultante do desenvolvimento tecnológico e inovação realizados no País”, criando ou ampliando “competências

tecnológicas e correlatas no País, contribuindo para a criação de negócios baseados em conhecimento e aumento de

autonomia tecnológica”.

A BRASSCOM acredita que, aplicada de forma consensualmente construída com as empresas, a preferência de compras do

governo para esses bens e serviços desenvolvidos no País pode ser um instrumento de fomento ao investimento das

empresas nacionais e multinacionais de software instaladas no Brasil. Pode, especialmente, estimular o aumento de

investimentos que redundem em inovação tecnológica, até mais do que a simples produção nacional de bens e serviços.

</cgelo>

Entretanto, entre o objetivo a ser atingido e a aplicação do processo de certificação proposto pela CERTICS, pode-se abrir

uma contradição que termine por produzir resultados opostos aos pretendidos.

<mtmet> Ainda que tecnicamente ancorada no sistema de normas ISO/IEC 15504, a Metodologia da CERTICS não é o

bastante para garantir a consecução do objetivo. Em se tratando, especialmente, da indústria de software, reputada como

uma das mais globalizadas do mundo moderno, é inadequado medir a contribuição à “criação ou ampliação de

competências tecnológicas e correlatas no País” pela definição da origem do software. Em outras palavras, como define o

texto em consulta: “A concepção do software deve ter sua origem no País, gerando competências tecnológicas e correlatas

associadas ao domínio de conhecimento necessário ao desenvolvimento do produto e seus serviços associados.” (Pág. 18)

</mtmet>

<mtmet> O texto da CERTICS admite, indiretamente, que há uma dificuldade no reconhecimento da origem do software e

aceita o fato de que “um software pode incluir componentes importados”. Nesses casos, o que a Metodologia procura

avaliar é “em que medida o corpo principal de conhecimentos, o diferencial de determinado software, foi desenvolvido e

apropriado pelo País.” (Pág. 14). Na mesma linha de raciocínio, em outra passagem do texto é afirmado que a Metodologia

não busca fazer a certificação pelo exame do artefato de software em si, mas pelo entorno que cerca a sua elaboração e

evolução.

Entretanto, o texto da CERTICS define procedimentos para o certificador que levarão a resultados contrários aos

declarados. Incorre-se no exame em si do artefato, indo até o seu código fonte, pois, conforme diz o texto: “No caso de

necessidade de mudança (manutenção ou evolução) do software, uma análise de impacto deve ser executada para garantir

que é possível a realização da mudança, bem como a identificação dos componentes afetados, tais como documentação de

requisitos e solução técnica (design). A análise de impacto deve utilizar a visualização da rastreabilidade a partir de um

requisito até o código fonte e vice-versa, passando pelos diferentes artefatos produzidos ao longo do processo de

desenvolvimento.” (pág. 18)

Esta e outras passagens do texto que fundamentam as quatro camadas do Modelo de Avaliação trabalham num nível de

ambiguidade que cria dificuldades para a consecução da declarada (boa) intenção de se chegar a um processo de

certificação objetivo, ao final do qual se reconheceria duas coisas principais: a) se o software foi desenvolvido no Brasil; b)

se houve a formação, sustentável ao longo do tempo, de capacitação no País. </mtmet>

A BRASSCOM tem grande interesse em que se desenvolvam softwares no Brasil, que a competência aumente e que as

empresas invistam crescentemente em pesquisa e desenvolvimento, mas não acredita que processos de certificação como o

proposto pela CERTICS, ainda que para orientar a compra pública, sejam suficientes ou indispensáveis para atingir aqueles

fins. Existem outras possibilidades e caminhos para se atingir o mesmo objetivo.

<mtmet> Vale observar ainda que existem no texto da CERTICs duas interpretações restritivas, que, a nosso ver, vão

condicionar os critérios de avaliação:

a. A definição de tecnologia nacional de software implica um conceito que não encontra correspondência no

benchmark de produção nacional que já vem sendo estabelecido nos Decretos Nº 7.709, para retroescavadeiras e

motoniveladoras; Nº 7.713, para fármacos e medicamentos e Nº 7.767, para produtos médicos. Nesses casos, não

está em questão a origem da tecnologia, se nacional ou estrangeira, mas sim a origem da produção e o seu teor de

inovação. É com esses dois parâmetros que são estabelecidas as margens de preferência. De forma equivalente,

acreditamos que o registro documental de softwares e serviços desenvolvidos no Brasil corresponderá melhor ao

benchmark acima descrito do que uma certificação de “tecnologia nacional de software”;

b. Existe, por fim, na documentação em consulta uma interpretação, a nosso ver, restritiva do conceito constitucional

de “autonomia tecnológica”, expresso no Art. 219 do Capítulo IV (“Da Ciência e Tecnologia”) da Constituição

Federal. Para evitar-se a subjetividade em eventual processo de certificação, conviria esclarecer que não há

automatismo entre o que propugna a Constituição Federal e a gestão empresarial imediata. Assim, por exemplo, um

centro de P&D de uma empresa multinacional de TI que esteja estabelecido no Brasil muito provavelmente não terá

autonomia tecnológica frente ao centro de decisão mundial da companhia. Ainda assim, esse centro de P&D poderá

desenvolver tecnologias que contribuam para a autonomia tecnológica do País. </mtmet>


3. Proposições

<mtmet> Reconhecendo a grande dificuldade de se conseguir um modelo de certificação comumente aceito para bens e

serviços de TI, pois estes resultam essencialmente de formulação abstrata, a BRASSCOM propõe ao MCTI que considere

outras opções mais simples para se reconhecer, nas licitações, os bens e serviços que tenham desenvolvimento nacional, a

exemplo de declaração acompanhada da documentação referente aos projetos, incluindo informações como:

i. Indicador de investimento em P&D, conforme padrões fixados por meio de discussões técnicas da

indústria com o governo;

ii. Indicador de emprego direto ou indireto de mestres, doutores e desenvolvedores;

iii. Convênios com Universidades e centros de pesquisa;

iv. Indicador de renda gerada pela empresa por meio do uso de parceiros de negócios e canais de venda, de

forma a dar fomento a um parque empresarial de empresas de TI no País. </mtmet>

Dessa forma, as presentes contribuições da BRASSCOM buscam estabelecer um processo cooperativo e franco de

discussão com o MCTI e todas as demais partes do governo que venham a ser envolvidas nesta definição. Estamos

absolutamente abertos para discutir essas e outras opções que sejam satisfatórias. Afinal, a melhor resultante de um

processo como esse pode ser, por exemplo, algo muito positivo que ocorreu na definição do novo regime automotivo.

Governo e indústria tomaram como ponto de partida a inovação e a eficiência dos veículos e chegaram a um bom modelo

de política setorial, de difícil questionamento em fóruns internacionais. Com diálogo e cooperação técnica qualificada,

acreditamos ser possível obter o mesmo êxito nas políticas de software e serviços de TI.

São Paulo, 12 Dezembro de 2012

____________________________________

Antonio Gil

Presidente




Qua, 12 de Dez de 2012 16:26

Assunto : Re: CERTICS - Contato

Para : Eduardo Santos

Prezado,



CERTICS.

Atenciosamente,

Angela


De: "Eduardo Santos"



Assunto: CERTICS - Contato


todas referentes ao item 4 - Modelo de Referência para Avaliação CERTICS. Em meu






























mesmo.





</mtmet>






software.”




públicos.




Organizacional.




que realizaram.”



















estrangeiras.










software.”





























mesmas regras”
















realizadas.




item:

















<mtmet> 4.6 Área de competência Gestão de Pessoas, Processos e Conhecimento (PPC)













--

Eduardo Santos

LightBase Consultoria em Software Público

===</thread>===[sequencial: 14]==========================================

===<thread>===[sequencial: 15]===========================================

De : Ricardo Jurczyk Pinheiro

Qua, 12 de Dez de 2012 08:57

Assunto : CERTICS - Contato

Para : Consulta publica <[email protected]>

Prezados,

Gostaria de manifestar-me a respeito da Consulta Pública que versa sobre

Software Nacional, e questionar por que o Software Livre não é contemplado nessa

Consulta.

Tenho certeza de que o processo de Consulta busca melhorar as estratégias brasiLeiras

referentes as tecnologias de desenvolvimento de software no Brasil, mas fico preocupado

com a falta de participação da sociedade, visto que esta Consulta Pública não foi

divulgada. Por questões de ética e seriedade isto deveria ter feito.

"Brasil: Um Pais de Todos", assim diz o slogan das campanhas publicitárias

governamentais, mas pelo visto não é exatamente de todos.

Nosso País é democrático, e decisões como essa deve ser em Consultas públicas, mas que

estas Consultas sejam divulgadas amplamente. Ou há quem não queira que a consullta não

seja tão pública assim?

O que me causa muita estranheza é que um processo como esse, nem cita o chamado software

Livre, que já é amplamente usado pelo Governo em todas as suas esferas (federal,

estaduais e municipais), desde projetos com o Software Público, passando por tantos

sistemas governamentais, e em tantas instâncias. Justamente, por ter seu código aberto e

auditável, é mais seguro. E por promover o desenvolvimento, estimula o serviço como uma

forma de geração de renda, sem ter que pagar royalties a empr esas estrangeiras ou

encontrar de frente com barreiras impostas pelas licenças de uso, tão restritivas.

Nós, usuários e membros das inúmeras comunidades de Software livre, queremos ser

respeitados e defendemos nosso direito de fazer parte dessa Consulta. O Software Livre é

mais socialmente justo, mais eficiente, de melhor qualidade, reduz custos e permite que a

tão propalada inclusão digital realmente ocorra.

Portanto, gostaríamos de que o software livre fosse contemplado nessa Consulta, e também

sermos respondidos sobre o por que não foi contemplado antes.

Grato,

--


Ricardo Jurczyk Pinheiro

Ecclesia Reformata, Semper Reformanda



Re: Consulta Pública sobre software nacional


Qua, 12 de Dez de 2012 16:27

Assunto : Re: Consulta Pública sobre software nacional

Para : Roberto Bittar

Prezado,



CERTICS.

Atenciosamente,

Angela


De: "Roberto Bittar"



Assunto: Consulta Pública sobre software nacional

Gostaria de incluir uma importante questão na discussão.

Os softwares subvencionados (por edital público na FINEP = desenvolvidos com recursos do

FNDCT) serão automaticamente classificados e certificados?

Se a subvenção é feita com base em Políticas Públicas definidas pelo processo

democrático, e uma empresa consegue a subvenção por EDITAL PÚBLICO, já não seria

suficiente para evitar tantas outras burocracias, avaliações e considerações editalícias?

Roberto Bittar

PPV Informática



De : Deyson Thome

Ter, 11 de Dez de 2012 15:47

Assunto : Consulta Pública


Prezados senhores

E o Software Livre ?

Ciente de que o referido processo de Consulta busca melhorar as estratégias brasiLeiras

referentes as tecnologias de desenvolvimento de software no Brasil.

Fico apreensivo em saber se nós cidadãos poderemos participar, inclusive discordando dos

métodos usados, já que não houve divulgação antcipada, que por questões de ética e

seriedade deveri am ter feito.

O Brasil não é de vocês , é nosso, não admito como cidadão crente na democracia, que

definam os rumos numa área tão importante e tão abusada pelas multinacionais gigantescas

em detr imento dos direitos dos cidadãos brasiLeiros.

Mais tempo deve ser dado para que possamos participar com projetos e sugestões a serem

agregados ao material que servirá de base para as decisões.

Temos o direito, diante de tantos absurdos que temos presenciado e visto pela mídia,

absurdos de cunho imoral por parte dos nossos dirigentes, que deveriam lutar pelo nosso

País , mas que traem a todos em busca de melhorias pessoais de ordem financeira.

Não acredito nos processos apresentados a nós como lícitos, simpl ismente por não terem

citado o software Livre, único apto a ser usado de forma coerente por qualquer governo,

por ter seu código aberto, auditável e promover o crescimento te todos igualmente,

estimulando o serviço como base para a geração de renda, sem os injustos impedimentos

proprietários e sem a ridícula e desnecessária transferência de royalties.

Nós do Software livre, exigimos espaço para apresentar nossa vocação, comprometida com a

qualidade e eficiência, ao mesmo tempo que reduz custos e estimula de forma honesta a

inclusão digital.


Vamos nos mobilizar contra coisas erradas, pois sabemos estar certos.

Chega de violações, queremos respostas, queremos execer nosso direito de cidadania.

Queremos respostas.

Deyson Baptista Thomé



Re: Submissão de contribuição da FNTI para a Chamada Pública da Certics


Qua, 12 de Dez de 2012 16:28

Assunto : Re: Submissão de contribuição da FNTI para a Chamada Pública da Certics

Para : Roberto C. Mayer

Prezado,



CERTICS.

Atenciosamente,

Angela


De: "Roberto C. Mayer"


Cc: "Anselmo Gentile", "Manoel Santos", "Gerson Schmitt"

"A rnaldo Bacha de Almeida", "Ruben Delgado"

, "EDSON LUIZ LEA L", "John Lemos Forman", "MGB" , "Luis Mario Luchetta"


Assunto: Submissão de contribuição da FNTI para a Chamada Pública da Certics

Bom dia!

Em nome da Frente Nacional das Entidades de TI, submetemos em anexo documento elaborado

em conjunto pelas Entidades representativas do Setor de TI (A BES, A ssespro, Fenainfo,

Softex e Sucesu) para a CerTICs. Confirmamos que esta proposta foi entregue em mãos,

durante audiência no dia de ontem, ao Secretário Virgílio A lmeida, da SEPIN.

Att.,

--

Roberto C

Roberto C. Mayer

Assespro Vice-Presidente de Relações Públicas da/Public Relations Vice-President at

Assespro Nacional (www.assespro.org.br) - Associação BrasiLeira das Empresas de

Tecnologia da Informação/A ssociation of Brazilian IT Companies ALETI

Presidente/President na/at ALETI - Federação Ibero-Americana de Entidades de Tecnologia

da Informação/Ibero

American Federation of IT Associations (www.aleti.org)


ANEXO FNTI

Contribuição da FNTI à Chamada

Pública sobre a CerTICs

Brasil

11/Dezembro/2012


Introdução

Em agosto de 2012 o governo brasileiro lançou o Programa Estratégico de Software e

Serviços de Tecnologia da Informação (TI Maior), apresentando a CerTICs como um

instrumento de certificação que visa credenciar e diferenciar softwares e serviços

associados para que as empresas fornecedoras participem dos processos licitatórios

aproveitando margem de preferência1. Apostando no empreendedorismo no setor de

TI, o objetivo desse programa é alavancar três eixos estruturantes para o

desenvolvimento sustentável do país: "a autonomia tecnológica, o potencial de

inovação e a geração de negócios com base em conhecimento.”. 2

Tal objetivo é louvável e muito necessário, visto que o mercado brasileiro de software

e serviços de TI vem crescendo a taxas médias de 8% ao ano, e já representa o maior

mercado da América Latina e o décimo no ranking mundial, movimentando cerca de

US$ 19 bilhões3 e gerando 600 mil empregos diretos. Não obstante, alguns aspectos

da proposta do governo precisam ser revistos sob pena de comprometer os objetivos

do programa, especialmente no que se refere à possibilidade de exclusão das micro e

pequenas empresas, que possuem grande potencial de inovação, de geração de

negócios e postos de trabalho, o que acabaria minimizando os ganhos para o setor de

TI e representando ainda mais custos para o governo. Visando participar da consulta pública referente à metodologia da CerTICs, a Frente

Nacional das entidades de TI – FNTI4 elaborou este documento trazendo uma proposta

alternativa que se aproxime mais da realidade do setor de TI, simplificando e barateando o

processo de certificação de modo a beneficiar um maior número de empresas. 1

A margem de preferência para produtos e serviços resultantes de desenvolvimento dentro do

país está prevista na Lei 8.666/93, e é calculada sobre o preço dos produtos e serviços estrangeiros, neste caso, estabelece-se uma margem de “ preferência normal” (Inciso I, do art. 2º, do Decreto 7.546/2011), podendo também ser fornecida uma margem de “ preferência adicional”, com percentuais de até 25%, para produtos e serviços nacionais que apresentem inovação tecnológica (Inciso II, do art. 2º, do Decreto 7.546/2011). 2 <http://www.certics.cti.gov.br/certics.html>

3 É importante lembrar que o tamanho do mercado brasileiro se situa numa faixa entre U$ 19 e 22 Bi

(dependendo da fonte). 4

Formada pela Associação Brasileira das Empresas de Software (ABES), Associação para a

Promoção da Excelência do Software Brasileiro (SOFTEX), Associação das Empresas Brasileiras de Tecnologia da Informação (Assespro), Federação Nacional da Informática (Fenainfo) e Associação de Usuários de Informática e Telecomunicações (Sucesu).


CAPÍTULO I

Panorama da Indústria Brasileira de Software e Serviços de TI (IBSS)

Neste capítulo procura-se dimensionar o mercado brasileiro de desenvolvimento

de softwares e serviços trazendo dados sobre o número de empresas e de

pessoas ocupadas, receita líquida, estimativas de crescimento e de investimento

do setor público. Por fim, são analisados os impactos que a criação de uma

margem de preferência para as compras públicas pode ter sobre o setor de TI.

O mercado de software e serviços de TI no Brasil Em 2012 o Observatório SOFTEX lançou o segundo volume da publicação Software e

Serviços de TI: A Indústria Brasileira em Perspectiva5, trazendo informações

confiáveis e detalhadas sobre a Indústria Brasileira de Software e Serviços de TI

(IBSS).6 Trabalhando com uma série histórica iniciada em 2003, a SOFTEX traz dados

concretos e realiza estimativas para o crescimento do setor até 2014. Segundo o estudo, existem hoje pouco mais de 73 mil empresas desenvolvedoras

de software e serviços no Brasil. A figura 1 mostra que, mantida a taxa média de

crescimento em 4,3% ao ano, esse número pode chegar a 80 mil em 2014.

5

Disponível em: <http://www.mbi.com.br/mbi/biblioteca/papers/2012-06-softex-industria-software-ti-perspectiva-volume-2/> Acesso em: 26.nov.2012. 6

A SOFTEX utiliza a Classificação Nacional das Atividades Econômicas (CNAE) e permite a comparação com outros países cujas metodologias também estejam baseadas no padrão

internacional ISIC (International Standard Industry Classification), como é o caso da OECD

(Organisation for Economic Co-operation and Development) e da Eurostat (Gabinete de Estatísticas

da União Européia). Além disso, trabalha em parceria com o IBGE (Instituto Brasileiro de Geografia

e Estatística) obtendo cruzamentos de diversas pesquisas provenientes desta instituição, bem como

utiliza bases do Ministério do Trabalho e Emprego (MTE), RAIS, Raismigra e CAGED, garantindo

um material bastante consistente para mapear e monitorar o mercado formal de trabalho na IBSS.


Figura 1 – Número de empresas da IBSS – Brasil, período 2003-2009 e

estimativas período 2010-2014

Fonte: Observatório SOFTEX, a partir de tabelas especiais da Pesquisa Anual de

Serviços/Instituto Brasileiro de Geografia e Estatística (PAS/IBGE), Diretoriade

Pesquisas/Coordenação de Serviços e Comércio, anos diversos. Uma das características mais marcantes do mercado brasileiro de TI é a alta

concentração de micro e pequenas empresas, muitas vezes com apenas um sócio e

pouca estrutura empresarial para prestar serviços. A figura 2 mostra que 96% das

empresas da IBSS são compostas de até 19 pessoas ocupadas (PO), enquanto

aquelas que possuem 100 ou mais POs, embora concentrem mais de 50% da receita

líquida total, não chegam a representar 0,5% das empresas da IBSS. Figura 2 – Distribuição percentual do número de empresas da IBSS,

considerando faixas do pessoal ocupado – Brasil, 2009

Fonte: Estimativa do Observatório SOFTEX, a partir de tabelas especiais da PAS/IBGE, Diretoria

de Pesquisas/Coordenação de Serviços e Comércio, 2009.


A taxa média de crescimento para PO na IBSS foi de mais de 10% entre 2003 e 2009,

com estimativas de que quase 600 mil pessoas, entre sócios e empregados, estejam

trabalhando nessas empresas em 2012, e pouco mais de 720 mil em 2014.

Figura 3 - Número de pessoas ocupadas na IBSS – Brasil, período 2003-

2009 e estimativas 2010-2014

Fonte: Observatório SOFTEX, a partir de tabelas especiais da PAS/IBGE, Diretoria de

Pesquisas/Coordenação de Serviços e Comércio, anos diversos

O faturamento do mercado brasileiro de software e serviços chegou a US$ 21,4

bilhões em 2011, incluindo as exportações, avaliadas em U$ 1,9 bilhão. Desse total,

US$ 6,3 bilhões são provenientes do segmento de software e US$ 15,1 bilhões vêm

dos serviços de TI, representando um crescimento de 12,6% em relação a 2010.

Esses dados são resultados de estudos realizados pela ABES7 que,

juntamente com o IDC, desde 2005, monitoram e apresentam tendências para

o mercado de software e serviços. A figura 4 mostra a evolução desses dois segmentos desde 2004, apresentando

taxas de crescimento de dois dígitos, exceto em 2009, cujo índice de 2,4% reflete

a crise econômica mundial, mas já em 2010 o setor se recupera e apresenta uma

elevação da ordem de 23,9%, continuando com a tendência positiva em 2011.

7

ABES – Associação Brasileira das Empresas de Software (2012) Mercado Brasileiro de

Software: panorama e tendências. São Paulo: junho/2011. Disponível em: <http://www.abessoftware.com.br/dados-do-setor/dados-2011> Acesso em: 29.nov.2012.


Figura 4 – Indicadores de Mercado e Evolução 2004-2011 (US$ bilhões)

Fonte: ABES - Mercado Brasileiro de Software: panorama e tendências, 2012

Segundo o relatório da ABES (2012), apesar das turbulências que afetaram a

economia global em meados de 2008, o mercado brasileiro de software

conseguiu manter a 12ª posição no ranking mundial nos anos de 2008 e 2009,

e hoje já está em 10º lugar com um mercado interno de U$ 19,5 bilhões, e

representa 52% do mercado total da América Latina. Figura 5 - Ranking mundial de software e serviços – Em US$ bilhões*

Fonte: IDC Wordwide Black Book, Q4, 2011


Não obstante os bons resultados do setor, o relatório da ABES (2012) chama a

atenção para o que chamou de “risco de colonização tecnológica do Brasil”, já

que apenas 20% dos softwares são desenvolvidos no país, enquanto 78% são

importados, como podemos verificar na tabela abaixo. Tabela 1 – Principais indicadores do mercado brasileiro de software e

serviços – 2011 (US$) bilhões

Fonte: ABES – Mercado Brasileiro de Software: panorama e tendências, 2012

O déficit da balança comercial do segmento de software e serviços ultrapassou

os US$ 3,0 bilhões em 2011, já que não consegue atender a demanda interna

com soluções inovativas que possam competir com os aplicativos e serviços

estrangeiros. Nesse sentido, pode-se inferir que o crescimento do setor acima

de 20% está sendo realizado a partir de pouco investimento em P&D, e baixo

índice de empresas que realmente inovam.


O censo do Setor de TI realizado pela Assespro Nacional no primeiro semestre de 20128

mostra que a maior parte das empresas pesquisadas apresenta uma alta inovação

mercadológica (82,3%), ou seja, a empresa disponibiliza software/serviços com

características inovadoras para os clientes que não dispunham deles anteriormente. Figura 6 – Inovação de mercado nas empresas brasileiras

Alta (Concorda)

82,3%

Int erm ediária

B aixa 12,4%

(Discorda)

5,3%

Fonte: Censo Assespro, 2012. A figura 7 mostra que a inovação mercadológica não está sendo acompanhada

de uma inovação evolutiva, definida como aquela feita a partir de investimentos

em P&D com fins de diferenciar-se da concorrência. Vemos uma distribuição

mais equilibrada entre alta inovação evolutiva (59,2%), inovação intermediária

(21,6%) e baixo grau desse tipo de inovação (19,2%). Figura 7 – Inovação evolutiva nas empresas brasileiras

8

O censo foi realizado com base em 285 questionários validados no período de maio a julho

de 2012, tendo a participação de empresas de todo o país. O questionário está disponível em: <http://assespro.org.br/files/assespro/biblioteca/dados-mercado/Censo-Assespro-do-Setor-de-TI-2012-Download.pdf> Acesso em 01.dez.2012.


Alta (Concorda) Intermediária

21,6%

59,2%

Baixa

(Discorda) 19,1%

Fonte: Censo Assespro, 2012.

Se a inovação com investimentos em P&D já estava fraca com relação à

inovação meramente mercadológica, vemos que a inovação denominada de

‘agressiva’, aquela que além dos investimentos na diferenciação dos produtos

ainda cria barreiras para potenciais concorrentes, (seja p.ex. através de

patentes ou de conhecimento exclusivo), cai para 34%, o que indica que o

conjunto de empresas nacionais que realmente inovam ainda é pequeno. Figura 8 – Inovação agressiva nas empresas brasileiras

Alta (Concorda) 34,4%

Baixa

(Discorda) 38,0% Intermediária

27,5%



Investimentos do Setor Público A participação do setor público federal como cliente dessas empresas é maior

quando se trata de inovação evolutiva, e bem mais fraca quando se trata de

inovação agressiva, ou seja, o setor público é um dos que menos compra de

empresas que realmente inovam, já que ele desenvolve internamente todos

aqueles projetos tecnológicos que são considerados estratégicos9.

Segundo estudos10

realizados pela Softex desde 2004, um dos grandes

problemas percebidos nas compras em âmbito federal11

é a concentração em

poucas empresas favorecidas. Em 2006, dos R$ 1,1 bilhão que o governo

gastou em Consultoria em TI, 98% ficaram com as doze principais favorecidas,

sendo que mais de 90% desses recursos foram direcionados a duas grandes

empresas públicas - Serviço Federal de Processamento de Dados (Serpro) e

Empresa de Tecnologia e Informações da Previdência Social (Dataprev). O mesmo aconteceu com as atividades de suporte técnico, manutenção e

outros serviços em TI, que vendeu para o governo o equivalente a R$ 278,8

milhões, tendo 86,6% dos recursos destinados às doze principais empresas,

concentrando 72,2% nas quatro primeiras do ranking. As atividades de desenvolvimento de programas de computador sob encomenda

reuniu 92,3% dos R$ 241,1 milhões investimentos públicos nas doze principais

fornecedoras, especialmente nas empresas CTIS Tecnologia e Datamec, ambas

são sociedades anônimas, sendo que a primeira é formada por capital nacional e,

a segunda, inicialmente controlada pela União e vinculada à Caixa Econômica

Federal, encontrando-se atualmente sob controle acionário da Unisys.

9

Nos termos do Art. 67º da lei 12.249/2010 (que modificou a chamada Lei do Serpro – Lei

5.615/1970) que dispensa de licitação os serviços de TI prestados pelo Serpro no âmbito de todo o Governo Federal. Disponível em: <http://www.planalto.gov.br/ccivil_03/_ato2007-2010/2010/lei/l12249.htm> Acesso em 07.dez.2012. 10

Os dados foram obtidos através do Portal da Transparência e podem ser consultados nas publicações de 2009 e 2012. Disponível no site: <http://www.softex.br/observatoriosoftex/_home/default.asp> Acesso em 01.dez.2012. 11

É provável que essa concentração ocorra também nos Estados e municípios, porém não foi possível reunir dados que fundamentassem essa afirmativa.


Com montantes mais modestos, as atividades de tratamento de dados,

provedores de serviços de aplicação e serviços de hospedagem na Internet (R$

24,8 milhões); e as atividades de desenvolvimento e licenciamento de

programas de computador customizáveis (R$ 10,4 milhões), também seguiram

na mesma linha de favorecimento de poucas empresas. A tabela 2 mostra o ranking geral das fornecedoras de software e serviços de

TI no ano de 2006: Tabela 2 – Ranking das 12 principais empresas favorecidas por

aplicações diretas do governo federal – ativ. 6202, 6203, 6204, 6209, 6311

e 6319 – Brasil, período 2004 a 2008

Valores incluem as várias unidades locais das empresas beneficiadas com compras

governamentais. Fonte: Elaboração Observatório SOFTEX, a partir de dados do site

www.portaldatransparencia.gov.br (consulta outubro 2008 e fevereiro 2009). O favorecimento de poucas empresas se repete para os anos de 2004 e 2005,

mas com uma tendência de diminuição da concentração nas quatro, oito e

doze primeiras colocadas do ranking em todas as atividades em 2007 e 2008. Em 2011 a canalização dos recursos para as empresas públicas já se encontram em

patamares mais baixos, caindo para 47,2%, o que já é um avanço significativo. No

entanto ainda há poucas empresas favorecidas pelo processo de compras

governamentais já que as 12 principais fornecedoras somam quase 70% dos

recursos.


Tabela 3 – Compras públicas: 12 principais favorecidas, 2011

Fonte: Softex, 2012. Disponível em

http://softex.w3pro.com.br/linkspdf/COMPRASPUBLICAS_VIRGINIADURATE.pdf As atividades de consultoria em TI ainda são as que mais vendem para o governo (R$

1,6 bilhões), mas podemos perceber que ao longo dos anos há um aumento da

participação das empresas de desenvolvimento de software sob encomenda (R$ 616,4

milhões) e suporte técnico (R$ 407,8 milhões). Vê-se ainda que o governo compra

pouco de empresas de software não customizável (R$ 112,2 milhões) ou customizável

(R$ 33,2 milhões). As atividades de Portais, provedores de conteúdo e serviços de

informação para a internet têm a maior concentração de recursos governamentais nas

4,8 e 12 principais fornecedoras, chegando a 97,4% na R12.

Figura 9 - Compras governamentais por atividade e participação das 4, 8

e 12 principais fornecedoras


Fonte: Dados retirados da apresentação da Softex, 2012. Disponível em

http://softex.w3pro.com.br/linkspdf/COMPRASPUBLICAS_VIRGINIADURATE.pdf A partir dos dados apresentados, pode-se concluir que as compras governamentais estão

concentradas em poucas empresas favorecidas. Apesar de ter sido um mecanismo

importante de apoio a essas empresas, a participação do governo como cliente representa

pouco no total da receita bruta de IBSS, conforme é possível verificar na


tabela abaixo, essa participação não ultrapassou 5,7% entre 2007 e 2009. Essa

situação é ainda pior quando se trata de software customizável, cuja

participação do governo representa apenas 0,1% de sua receita bruta. Tabela 4 – Compras do governo de empresas da IBSS, por atividade principal Fonte: Softex, 2012. Disponível em: http://softex.w3pro.com.br/linkspdf/COMPRASPUBLICAS_VIRGINIADURATE.pdf Tabela 5 – Compras do governo na receita bruta da IBSS 20 ou mais

PO, por atividade, 2007-2009

onte: Softex, 2012. http://softex.w3pro.com.br/linkspdf/COMPRASPUBLICAS_VIRGINIADURATE.pdf

A única fonte de informação que conseguimos identificar que relaciona as compras públicas

com a inovação, em todos os níveis de governo (federal, estadual e municipal),é o já citado

Censo da Assespro do Setor de TI. Além de avaliar o tipo de inovação praticado pelas

empresas, foi apurada informação sobre os principais clientes das empresas (representados

pelos setores da economia que respondem por 33% ou mais do faturamento de cada empresa).


Figura 10 - Atividades Econômicas que representam um terço do faturamento

Profissionais Liberais/Pessoas 2,8%

Físicas

3,2%

Setor Primário

10,9%

Infra-Estrutura

14,0%

Tecnologia da Informação

18,6%

Setor Financeiro

27,0%

Setor Público

Indústria da Construção e 34,7%

Transformação 36,1%

Atacado e Varejo

42,8% Serviços

Esses dados revelam que o Setor Público é o quarto mais importante, em número de

empresas que o atendem, em toda a economia. Ainda, ao comparar esses dados com

o porte das empresas, revela-se que o Setor Público encontra-se na média de todos

os setores da economia, distribuindo suas compras por empresas de todos os portes.

Figura 11 - Atividades econômicas que representam 1/3 do faturamento x

Porte da empresa

S eto r Fin anceiro

1,9% 20,8% 67,9% 9,4%

In dústria d a Con strução e 9,1% 56,6% 34,3%

Transformação

Setor Prim ário 11,1% 55,6% 33,3%

In fra-Estru tu ra 12,9% 38,7% 41,9% 6,5%

Setor Pú blico 14,3% 39,0% 40,3% 6,5%

Serviços 18,0% 46,7% 33,6% 1,6%

Atacad o e Varejo

29,1% 48,5% 21,4% 1,0%

T ecno logia da I nformação 32,5% 42,5% 20,0% 5,0%

Profission ais 50,0% 50,0%

Liberais/Pessoas Físicas

Micro -Empresa Empresa de Pe queno Porte Empresa de Porte Mé dio Grande Empresa

Quando estes dados são cruzados com as informações sobre os tipos de

inovação praticados pelas empresas, os resultados obtidos para a inovação de

mercado, na próxima Figura, revelam que o setor público perde uma posição


no ranking dos setores em relação a distribuição anterior. Figura 12 - Inovação de Mercado x Principais Atividades Econômicas dos Clientes

Atacado e Varejo 73,5% 14,3% 12%

Tecnologia da Informação 75,0% 15,0% 10%

Setor Financeiro 80,8% 15,4% 4%

Setor Público 81,8% 13,0% 5%

Serviços 84,4% 13,1% 2%

Indústria da Construção e Transformação 86,9% 10,1%3%

Setor Primário 88,9% 11,1%

Infra-Estrutura 93,5% 6,5%

Profissionais Liberais/Pessoas Físicas 100,0%

Alta (Concorda) Intermediária Baixa (Discorda)

Repetindo-se a mesma análise para a inovação evolutiva, o Setor Público retoma

sua posição na média dos demais, embora com percentuais mais baixos. Figura 13 - Inovação Evolutiva x Principais Atividades Econômicas dos Clientes

Atacado e Varejo 43,6% 24,8% 31,7%

Tecnologia da Informação 51,3% 28,2% 20,5%

Setor Financeiro 58,5% 20,8% 20,8%

Serviços 61,2% 23,1% 15,7%

Setor Público 62,3% 15,6% 22,1%

Indústria da Construção e Transformação 63,6% 22,2% 14,1%

Setor Primário 66,7% 33,3%

Profissionais Liberais/Pessoas Físicas 75,0% 25,0%

Infra-Estrutura 87,1% 3,2%9,7%

Alta (Concorda) Intermediária Baixa (Discorda) Finalmente, ao avaliar a inovação agressiva, o Setor Público acaba ficando

entre os três setores da economia que menos compram das empresas que

mais praticam esse tipo de inovação. Figura 14 - Inovação Agressiva x Principais Atividades Econômicas dos Clientes


Atacado e Varejo 23,7% 21,6% 54,6%

Indústria da Construção e Transformação 24,2% 36,4% 39,4%

Setor Público 32,9% 27,4% 39,7%

Serviços 36,4% 31,4% 32,2%

Tecnologia da Informação 38,5% 25,6% 35,9%

Setor Financeiro 41,5% 30,2% 28,3%

Setor Primário 55,6% 22,2% 22,2%

Infra-Estrutura 56,7% 23,3% 20,0%

Profissionais Liberais/Pessoas Físicas 60,0% 20,0% 20,0%

Alta (Concorda) Intermediária Baixa (Discorda)

Este dado confirma numericamente a realidade conhecida pelo Setor de TI: os

governos não estão interessados em comprar produtos realmente inovadores.

CAPÍTULO 2

Proposta da FNTI diante da CerTICs

Neste capítulo a FNTI apresenta uma proposta alternativa ao modelo de certificação CerTICs

que o governo pretende implementar pelo Programa Estratégico de Software e Serviços de

Tecnologia da Informação (TI Maior). Essa certificação tem como objetivo atestar junto ao

Ministério da Ciência, Tecnologia e Inovação (MCTI) o desenvolvimento local e inovação de

produtos tecnológicos em atendimento ao art. 6º do Decreto 7174/2010 que regulamenta a

contratação de bens e serviços de informática pelo governo12

. A metodologia originalmente proposta

13 pretende avaliar softwares e seus serviços associados

de forma a credenciar as empresas interessadas a participarem de processos de licitação com

direito a uma margem de preferência. Seu modelo de referência está estruturado em quatro

camadas hierárquicas: 1) A verificação de desenvolvimento tecnológico e inovação realizados

no país; 2) A avaliação de cinco áreas de competências (Desenvolvimento; Gestão de

Tecnologia; Gestão de Negócios; Gestão de Parcerias e Alianças; e Gestão de Pessoas,

Processos e Conhecimento); 3) Cinco conjuntos de Resultados Esperados relacionado às cinco

áreas de competência citadas; 4) Orientações e Indicadores que detalham os resultados

esperados. O processo é realizado em cinco fases sequenciais: exploração, preparação, visita, validação e

conclusão da avaliação, e é todo realizado no âmbito do governo. Desse modo, a avaliação é

realizada pelo Centro de Tecnologia da Informação Renato Archer (CTI) e a certificação é

emitida pelo MCTI por meio da Secretaria de Política da Informática (SEPIN). A proposta alternativa aqui apresentada pela FNTI pretende aproveitar os aspectos mais


positivos dessa metodologia, visto que foi elaborada por uma rede de profissionais

especializados que trabalharam de forma séria para sistematizar o processo. Não obstante, as

entidades representativas que compõem a FNTI entendem que é preciso levar em conta um

panorama mais realista do Setor que, como vimos no capítulo anterior, tem apresentado um

ótimo desempenho nos últimos anos, a despeito de não receber o devido incentivo no que se

refere às compras governamentais, centralizadas

12

Disponível em: <http://www.planalto.gov.br/ccivil_03/_Ato2007-2010/2010/Decreto/D7174.htm> 13

Metodologia completa disponível em: <http://www.certics.cti.gov.br/downloads/MetodologiaCERTICS_20ago2012_v1.pdf>

22


em poucas empresas de médio e grande porte, especialmente nas próprias empresas públicas

conforme vimos nos dados expostos no Capítulo 1. Nesse contexto, a metodologia de certificação da CerTICs acaba não levando em conta que

seu modelo constituído por camadas de competência, tal como se apresenta, inviabiliza a

participação da maioria das empresas que compõem o mercado brasileiro de software e

serviços, formado em mais de 90% por micro e pequenas empresas, especialmente pelas

startups, empresas de pequeno porte, geralmente criadas a partir de ideias inovadoras mas

com baixo custo de manutenção, e que dificilmente conseguirá atender alguns critérios da

CerTICs, como aqueles relacionados à gestão de parcerias e alianças. Desse modo, as entidades que compõem a FNTI acreditam que não basta criar um instrumento

de certificação padronizado para todas as empresas, há que se levar em conta suas

características específicas e o seu potencial para gerar valor agregado e implementar

inovações, sob pena de gerar apenas mais burocracia e custos para essas empresas sem,

contudo, aumentar suas vantagens competitivas, e muito menos ajudar no desenvolvimento

sustentável do país.

Da forma como se encontra elaborada, além de excluir as startups e a maioria das empresas

que realmente precisam de incentivo para inovar, essa metodologia representa um gasto

desnecessário de recursos humanos e financeiros, já que temos entidades representativas

atuando intensivamente junto a esse setor com o objetivo de ajudá-lo a desenvolver seu

potencial inovativo de maneira sustentável e competitiva, gerando riqueza e postos de trabalho,

e levando o Brasil a uma participação cada vez maior no mercado global.

Para compor esta contraproposta, as entidades da FNTI partiram de alguns pressupostos

básicos, como:

A simplificação do processo de certificação tornando-o mais acessível aempresas de

todos os tamanhos, especialmente em atenção ao objetivo de fomentar as micro e

pequenas empresas nacionais a realizarem inovação tecnológica em seus produtos;

A participação das entidades representativas de classe, gerando uma capilaridade

essencial no atendimento às empresas, especialmente em um primeiro momento,

quando poderá surgir uma demanda maior;

O aproveitamento das certificações de processos e documentação que asempresas

já possuírem;

A criação de um sistema de pontuação que torne mais transparentes os critérios que

identificam as empresas de TI participantes do processo de compras governamentais.

Quesitos para a identificação da produção local

O atestado de origem nacional é obrigatório para a participação das empresas nos processos

de compras governamentais com benefício de margem de preferência (§ 5º do art. 3º da lei nº

8.666/93). A proposta aqui apresentada sugere que este atestado seja emitido pelas entidades

representativas do setor de TI segundo o disposto na Tabela de Pontuação para Margem de


Preferência com comprovação de produção nacional apresentada a seguir.

Para emitir o atestado de que a empresa desenvolve produtos e serviços em território nacional,

a entidade de classe examinará a documentação que obedeça a alguns dos seguintes

quesitos:

Declaração de cumprimento das regras de origem do representante legal de empresa

constituída em território nacional, que comprovam que o programa de computador em questão

atende aos requisitos do artigo 3 parágrafo V da Lei 8.666/93. Esta declaração não vale

pontos, mas será obrigatória para todas as empresas, independente do cumprimento dos

demais quesitos mencionados na tabela, e deverá ser preenchida e enviada a uma das

entidades representativas.

Certificação ISO 9000 - A utilização do certificado ISO 9000 comprova atendimento das

normas técnicas brasileiras, conforme exigência do § 5º do artigo 3º da Lei 8.666/93. Vale 1,0

ponto.

Carta declaratória de cliente indicando que adquiriu ou avaliou o produto de software. Esta

carta deverá ser escrita por clientes da empresa interessada como forma de recomendação do

produto adquirido. Serão aceitas no máximo três cartas, com validade de 0,5 pontos cada uma.

Documentação técnica em português (Requisitos, arquitetura e/ou modelagem de base de

dados). Documentação gerada no processo de desenvolvimento, implementação e avaliação

do produto, visando assegurar que o mesmo tenha sido produzido para o cliente nacional. Vale

1,0 ponto. Caso conste aprovação formal do cliente, essa documentação valerá 1,5 pontos.

Código fonte depositado junto a terceiros, comprovado por meio de cláusula contratual ou

documento de registro emitido pelo cliente, valerá 1,0 ponto.

Produto cadastrado para venda por meio do Cartão BNDES. O processo de cadastro de

produtos para serem adquiridos com cartão BNDES impõe regras de origem bem definidas que

podem comprovar com eficácia o desenvolvimento dentro do território nacional. Vale 1,0 ponto.

Declaração RAIS detalhando as ocupações em desenvolvimento de software. O

preenchimento da declaração RAIS – Relação Anual de Informações Sociais possibilita a

disponibilização de informações que envolvem os trabalhadores ocupados na empresa, logo, é

fonte de dados que comprovam o estabelecimento de equipes de desenvolvedores no país.

Vale 1,0 ponto.

URL de currículo publicado no sistema Lattes, indicando vínculo com a empresa e

conhecimento/experiência relacionados a TI. Este item é focado na equipe desenvolvedora

que, por meio de sua experiência profissional, pode atestar participação no desenvolvimento de

produtos e serviços para a empresa. Serão aceitas no máximo três URL’s, com validade de 0,5

pontos cada.

Certificados de Treinamento Técnico da Equipe Técnica Local. Este item também é focado na

equipe desenvolvedora, e demonstra o comprometimento da empresa com a qualificação de

seus colaboradores no âmbito nacional. Vale 1,0 ponto.

Prêmio concedido ao produto. A empresa deve apresentar certificados, títulos ou declarações

de premiação nacional ou referente à produção nacional. Vale 1,0 ponto.

Disponibilização de Logs de Alterações e/ou Logs de defeitos do software e suas


correções. Neste caso, a empresa precisa apresentar documentação que comprove a evolução

do produto ao longo de pelo menos 90 dias, identificando o autor das alterações, ou registro

dos defeitos por colaborador da empresa que se comprove trabalhar no país. Vale 1,0 ponto.

Disponibilização de Base de Dados de Alocação de Horas-homem ou tarefas. A

empresa deve apresentar relatórios de controle e alocação dos recursos humanos

atestando o trabalho da equipe em determinado local do território nacional. Vale 1,0

ponto.

Manual de Usuário em Português, com identificação do(s) autor(es) local(is). Este

quesito demonstra que a empresa elaborou sua documentação a partir de equipe dentro

do país. Vale 1,5 pontos.

Resultados de Pesquisa de Satisfação dos Clientes contratado junto a terceiros. A

pesquisa de satisfação demonstra o interesse da empresa em avaliar a qualidade de seu

produto e/ou serviços junto aos seus clientes, contribuindo para o desenvolvimento do

país. Vale 1,0 ponto.

Registro de Propriedade Intelectual do Software no INPI. Nesse documento consta a

declaração de origem de desenvolvimento do produto. Vale 3,0 pontos.

Apresentação de Interface de Usuário em Português Brasileiro. Os produtos devem ter

sido produzidos visando facilitar a sua utilização para o usuário brasileiro, portanto sua interface deve estar em língua nativa. Vale 1,0 ponto.

A seguir a tabela com a pontuação proposta para caracterizar origem nacional dos produtos e

serviços. É importante verificar que para ter direito à margem de preferência do tipo “normal”,

ou seja, referente ao desenvolvimento de software e serviços em território nacional, a empresa

deve somar pelo menos cinco pontos a partir dos quesitos abaixo, sendo que o primeiro quesito

é obrigatório, conforme mencionado anteriormente.

6


Tabela 6 – Tabela de Pontuação para Margem de Preferência com

comprovação de PRODUÇÃO NACIONAL

Forma de Comprovação Pontos

Declaração de cumprimento das regras de origem do representante legal de empresa constituida em território nacional, que comprovam Obrigatório, mas que o programa de computador em questão atende aos requisitos do não vale pontos artigo 3 parágrafo V da Lei 8.666/93

Certificação ISO 9000 1

Carta declaratória de cliente indicando que adquiriu ou avaliou o 0,5 cada carta produto de software (máximo de três) Documentação Técnica em português (Requisitos, arquitetura

e/ou modelagem de base de dados) Documentação Técnica em português (Requisitos, arquitetura e/ou

modelagem de base de dados) com aprovação formal do cliente Código Fonte depositado Junto a Terceiros Produto cadastrado para venda por meio do Cartão BNDES Declaração RAIS detalhando as ocupações em desenvolvimento

de software

1

1,5 1 1 1


URL de currículo publicado no sistema Lattes, indicando vínculo com a 0,5 cada

empresa e conhecimento/experiência relacionados a TI (máximo de três)

Certificados de Treinamento Técnico da Equipe Técnica Local 1

Prêmio concedido ao produto 1

Disponibilização de Logs de Alterações e/ou Logs de defeitos do 1

software e suas correções

Disponibilização de Base de Dados de A locação de Horas-homem ou 1

tarefas

Manual de Usuário em Português, com identificação de autor local 1,5

Resultados de Pesquisa de Satisfação dos Clientes contratado junto a 1

terceiros

Registro de Propriedade Intelectual do Software no INPI 3

Apresentação de Interface de Usuário em Português Brasileiro 1

Quesitos para identificar indícios de inovação

Para obter uma margem de preferência adicional, e poder chegar a 25% do valor

cobrado pela empresa estrangeira (§7º e §8º do art. 3º da lei nº 8.666/93), as

empresas nacionais devem apresentar produtos e serviços inovadores. Neste

caso, a FNTI sugere que a emissão de documentos atestando que a empresa é

inovadora seja feita pela rede de agentes autorizados a aplicar a metodologia

CerTICs, aproveitando a equipe já montada para elaborar a metodologia. A despeito da criação de uma proposta alternativa, a FNTI ressalta a importância da

metodologia da CerTICs ao levantar uma série de quesitos estratégicos para avaliar se

a empresa é ou não inovadora. Dessa forma, a maior parte dos quesitos foi mantida,

priorizando aqueles que podem ser avaliados de forma objetiva através de

documentos já disponíveis ou de fácil obtenção, sem necessidade de fazer auditoria, o

que garante custos reduzidos, maior agilidade e simplicidade ao processo. Uma das características principais desta proposta é levar em consideração as

certificações de processo (mps.br, CMMi, ISO 29110) como uma das formas de

demonstrar competência e aproveitar a documentação que as empresas de TI já

possuem para atender as normas técnicas brasileiras que regem o

desenvolvimento de produtos e serviços no país. No entanto, como o foco dessas

certificações é no processo de desenvolvimento e não no produto de software,

entende-se que elas não devem substituir a CerTICs, mas podem funcionar como

quesitos que demonstram inovação das empresas no âmbito do desenvolvimento

local. Na figura 14 é possível verificar que quase 20% empresas possuem

certificação mps.br e 7% apresentam CMMi em seus diferentes níveis.


Figura 15 – Certificações Empresariais

Certificações

0,4%

regionais

(emitidas por

0,4%

CMMi for Services

0,4%

ISO 27000

(segurança da

informação)

0,4%

ITIL (ITSM)

ISO 14000

0,7%

(ambiental)

ISO 20000

1,8%

(gestão de

infraestutura de

3,2%

mps.br nível A a D

6,7%

CMMi nível 2 ou 3

ISO 9000

13,0%

(qualidade de

processos)

mps.br nível E a G

15,


Para verificar a inovação dos produtos e serviços oferecidos pelas empresas, a

rede de agentes autorizados examinará documentação que obedeça a alguns

dos seguintes quesitos e pontuará de acordo com a Tabela 7:

Desenvolvimento Local

Certificação mps.br – Melhoria de Processos do Software Brasileiro – é um

modelo desenvolvido pela Softex, em parceria com o governo federal e

universidades para realizar uma certificação nacional de baixo custo voltado

às pequenas e médias empresas. Possui sete níveis que nesta proposta

foram valorados na escala de 0,8 a 2,0 pontos conforme descrição a seguir:

A - Otimização = 2,0 B - Gerenciado quantitativamente = 1,8 C – Definido = 1,6 D - Largamente Definido = 1,4 E - Parcialmente Definido = 1,2 F – Gerenciado = 1,0 G - Parcialmente Gerenciado = 0,8


Certificação CMMi (Capability Maturity Model Integration) – é modelo de

certificação internacional direcionado às melhores práticas de

gerenciamento dos processos da empresa, e propõe uma evolução no

grau de maturidade desses processos segundo cinco níveis que aqui

estão sendo valorados entre 0,8 e 2,0, começando pelo nível 2, já que o

nível 1 representa a ausência dessa certificação:

Nível 2: 0,8 Nível 3: 1,2 Nível 4: 1,6 Nível 5: 2,0

Certificação ISO 29110 (Produto de Desenvolvimento de Software para

MPE) – é um modelo de certificação de baixo custo direcionado a micro

e pequenas empresas brasileiras que propõe agregar valor aos

processos de desenvolvimento de software no país. Vale 1,5 pontos.

Patente depositada no INPI - Instituto Nacional da Propriedade Industrial atesta

de forma legítima o conhecimento transformado em inovação, trazendo um

diferencial competitivo aos produtos desenvolvidos. Vale 2,5 pontos.

Contrato de Cessão/Venda da Tecnologia a outras Empresas no País. A

documentação de contrato de negócios realizados no mercado interno

vale 2,5 pontos.

Contrato de Cessão/Venda da Tecnologia a outras Empresas no Exterior. A

documentação de contrato de negócios via exportação vale 3,5 pontos.

Negócios

Participação em Feiras e Congressos no país trazem novas oportunidades

de negócios e atestam sua busca por conhecimento e inovação. Vale

0,5 para cada evento, aceitando-se no máximo dois.

Parcerias e Alianças

Contratos que comprovam a existência de ecossistemas de empresas que

compõem a rede de comercialização e suporte ao produto. Vale 1,0 ponto.

30


M

a

n

u

t

e

n

ç

ã

o

d

e

A

l

i

a

n

ç

a

F

o

r

m

a

l

c

o

m

p

l

a

y

e

r do Setor de TI. Contratos com outras empresas de TI com o

objetivo de estabelecer uma aliança formal valem 0,5 cada, para

no máximo dois contratos.

Comprovação de usufruto de benefícios fiscais da Lei do Bem. A

Lei 11.196/2005, também conhecida como Lei do Bem, beneficia

empresas que investem em pesquisa e desenvolvimento de

inovação tecnológica. Vale 1,0 ponto.

Tecnologia

Papers acadêmicos, dissertações ou teses escritos por colaboradores da

empresa, relacionados ao alvo do software avaliado atestam a valorização

de pesquisa e desenvolvimento visando inovação do produto. Cada tipo de

documentação apresentada receberá uma pontuação de acordo com os

seguintes critérios:

Paper/ artigo acadêmico publicado em revistas especializadas - 1,5

TCC/monografia apresentada em curso de graduação,

pós-graduação, especialização etc. - 0,5

Dissertação de mestrado - 1,0

Tese de doutorado - 1,5

Qualquer tipo de publicação em revistas acadêmicas

que contam como produção científica - bônus de 0,5

Centro de P&D Local credenciado pelo CATI. As empresas que

possuem centros de pesquisa e desenvolvimento local

credenciadas pelo CATI/MCT podem apresentar seus plano de

P&D, projetos e relatórios de pesquisa. Vale 1,0 ponto.

Contrato de Cooperação com Instituição Acadêmica ou Instituto

Científico-Tecnológico em Território Nacional atestam a parceria

das empresas com o meio acadêmico e o comprometimento com

a busca de inovação tecnológica. Vale 1,0 ponto.

Declaração RAIS detalhando as ocupações em pesquisa e

desenvolvimento - O preenchimento da RAIS disponibilizando as

informações sobre os trabalhadores ocupados em categorias

relacionadas à P&D vale 1,5 pontos.


Projeto apresentado a órgãos de fomento no país ou no Exterior. A

produção de conhecimento através da elaboração e apresentação de

projetos buscando parcerias em órgãos de fomento no país e no exterior

conta 1,0 ponto para atestar inovação da empresa. Projeto aprovado junto a órgãos de fomento no país ou no Exterior. Caso

o projeto passe pelos critérios de aprovação dos órgãos de fomento,

atestando sua qualidade e viabilidade, a empresa recebe 2,0 pontos. URL de currículo publicado no sistema Lattes, indicando vínculo com a empresa ou

co-participação em projeto, conhecimento/experiência relacionados a TI e título de

doutor strictu sensu. Vale 0,5 pontos cada, no máximo três URL’s.

A seguir a tabela com a pontuação proposta para caracterizar inovação. É importante

verificar que para ter direito à margem de preferência do tipo “adicional”, ou seja,

referente ao desenvolvimento de software e serviços que apresentem inovação, a

empresa deve somar pelo menos sete pontos a partir dos quesitos abaixo:


Tabela 7 – Tabela de Pontuação para Margem de Preferência com comprovação

de INOVAÇÃO

Quesito Forma de Comprovação Pontos

0,6 a 2 (1)

Certificação mps. br

(conforme A: 2,0

nível 1)

B: 1,8

C: 1,6

Certificação CMMi

1 a 2 D: 1,4

(conforme E: 1,2

F: 1,0

nível 2)

Certificação ISO 29110 (Produto de G: 0,8

Desenvolvimento de Software para MPE) 1,5

(2)

Desenvolvimento Local Patente depositada no INPI

2,5

Nível 2: 0,8

Contrato de Cessão/Venda da Tecnologia a outras

Nível 3: 1,2

Empresas no País

2,5 Nível 4: 1,6

Contrato de Cessão/Venda da Tecnologia a outras Nível 5: 2,0

Empresas no Exterior 3,5

Negócios Participação em Feiras e Congressos no país 0,5 cada

(máximo

de dois)

Contratos que comprovam a existência de

ecossistemas de empresas que compõem a rede de

comercialização e suporte ao produto 1

Parcerias e Alianças Manutenção de Aliança Formal com player do Setor 0,5 cada

(máximo

de TI

de dois)

Comprovação de usufruto de benefícios fiscais da Lei

do Bem 1

Papers acadêmicos, dissertações ou teses escritos

por colaboradores da empresa, relacionados ao alvo

do software avaliado 2

Centro de P&D Local credenciado pelo CATI 1

Contrato de Cooperação com Instituição Acadêmica

Tecnologia ou Instituto Científico-Tecnológico em Território

Nacional 1

Declaração RAIS detalhando as ocupações em

pesquisa e desenvolvimento 1,5

Projeto apresentado a órgãos de fomento no país ou

no Exterior 1

Projeto aprovado junto a órgãos de fomento no país

ou no Exterior 2

URL de curriculo publicado no sistema Lattes,

indicando vínculo com a empresa ou co-participação

em projeto, conhecimento/experiência relacionados 0,5 cada

a TI e título de doutor strictu sensu (máximo

de três)

33


CONCLUSÕES

Apostando no empreendedorismo em TI, o governo criou a CerTICs como instrumento de

qualificação de empresas de software e serviços que pretendem atuar como fornecedoras

do setor público. No entanto, é possível perceber que alguns aspectos da metodologia

proposta tornam o processo muito burocrático e dispendioso, dificultando a participação

das micro e pequenas empresas, que não conseguiriam atender requisitos que podem ser

considerados muito complexos e até mesmo desnecessários, tanto para comprovar a

origem nacional quanto para atestar inovação de fato. Os dados apresentados neste relatório mostram que o mercado de TI é formado

majoritariamente por micro e pequenas empresas, mas que a receita líquida

encontra-se concentrada em apenas 0,5% (formadas por 100 ou mais PO). Isso

significa que o setor precisa equilibrar esse cenário através de incentivos reais

para o crescimento das PME’s, apostando em seu potencial de inovação. O censo da Assespro (2012) mostrou que a maioria das empresas pesquisadas

apresenta alto grau de inovação mercadológica, mas com fraca inovação

agressiva, já que encontram dificuldades em investir em P&D. Apesar de ter uma participação relevante neste mercado, as compras do

governo federal estão concentradas em poucas empresas, especialmente nos

fornecedores internos (empresas públicas). Ao comparar os dados do censo da

Assespro com os clientes do Setor como um todo, o que inclui os governos

estaduais e municipais, a situação se repete: o Setor Público está entre os que

menos compram das poucas empresas inovadoras. Esses fatos minimizam o impacto das medidas propostas, comprometendo o objetivo

de alavancar as pequenas empresas que podem apresentar um alto grau de inovação,

agregando valor aos seus produtos e recursos humanos, e crescendo de forma

sustentável, por meio da fixação de margens de preferência nas compras públicas. Outro aspecto avaliado pelas entidades representativas do setor de TI foi a

complexidade do sistema avaliativo proposto, baseado em um processo longo

e de alto custo. É importante levar em conta as certificações já existentes,

como a ISO 9000 e modelos de processos como o CMMi e o MPS.Br. Desta

forma, a FNTI sugere um método de certificação mais simplificado, que

verifique de forma consistente, através de um sistema de pontuação objetivo e

transparente, a adequação das empresas às exigências da lei 12.349/2010.


O formato jurídico proposto para a certificação da CerTICs estabelece regra

única para um negócio feito de duas partes – margem de preferência normal e

adicional. Não obstante, estamos diante de duas exigências diferentes, já que

pela norma jurídica a preferência normal não exige inovação. No intuito de contribuir com o Governo Federal, as entidades desenvolveram,

por meio de sua assessoria jurídica, a minuta de Decreto e Portaria

apresentados nos Apêndices I e II. Na proposta original da CerTICs é declarada a necessidade de criar condições para que

as empresas conquistem mercado e gerem faturamento, incentivando aquelas que

desejam ser fornecedoras do governo a investirem em inovação. A FNTI considera que a

proposta do governo não terá um impacto significativo no desempenho do setor de TI

como um todo, enquanto não ampliar as possibilidades de participação de empresa de

todos os tamanhos, focando no potencial de inovação, e enquanto permanecer a

estratégia de compras concentradas nas empresas menos inovadoras. Dessa forma, a FNTI entende que, para que o Setor de TI seja realmente

alavancado, é necessário ir muito além de uma certificação que fomente empresas

locais e inovadoras. Será preciso equacionar diversos outros aspectos, incluindo a

diversificação nas compras governamentais em TI, incluindo as PMEs

(especialmente inovadoras), a implementação dos programas de fomento à

inovação, a relação entre o plano TI Maior, a estratégia de software livre e o portal

de Software Público, além de vários outros aspectos regulatórios. A FNTI propõe

que estes temas sejam objeto de continuado diálogo entre o governo com as

entidades representativas do Setor e a sociedade civil organizada.

35


APÊNDICE I

Minuta de Decreto DECRETO Nº , DE DE DE 2012

Estabelece a aplicação de margem de

preferência nas licitações realizadas no âmbito

da Administração Pública Federal para

aquisição de programas de computador

(“software”) nacionais e serviços técnicos

complementares nacionais descritos no Anexo

I, para fins do disposto no art. 3o da Lei n

o

8.666, de 21 de junho de 1993.

A PRESIDENTA DA REPÚBLICA, no uso das atribuições que lhe confere o art. 84,

caput, inciso IV, da Constituição, e tendo em vista o disposto no art. 3o, §§ 5

o, 6

o, 7º, 8

o e 9

o,

da Lei no 8.666, de 21 de junho de 1993,

DECRETA:

Art. 1o Fica estabelecida a aplicação de margem de preferência para aquisição de

programas de computador (software) nacionais e serviços técnicos complementares nacionais,

conforme percentuais e descrições do Anexo I, nas licitações realizadas no âmbito da

administração pública federal, com vistas à promoção do desenvolvimento nacional su

stentável.

Parágrafo Primeiro. A aplicação da margem de preferência Normal de que trata o § 5º

do art. 3o, da Lei no 8.666, de 21 de junho de 1993, observará o quanto disposto neste

Decreto.

Parágrafo Segundo. A aplicação da margem de preferência Adicional será conferida

aos programas de computador (software) nacionais e serviços técnicos complementares

nacionais resultantes de desenvolvimento e inovação tecnológica realizados

no País que, adicionalmente ao disposto neste decreto, obtiverem o CERTIFICADO

CERTICS por meio da Secretaria de Política da Informática (SEPIN), em conformidade com

Portaria publicada pelo Ministério de Estado Ciência, Tecnologia e Inovação (MCTI)

estabelecendo os critérios da referida certificação.

Parágrafo Terceiro. Os editais para aquisição dos programas de computador (software)

nacionais e serviços nacionais descritos no Anexo I, publicados após a data de entrada em

vigor deste Decreto, deverão contemplar a aplicação da margem de preferência de que trata o

caput.


Parágrafo Quarto. A aplicação da margem de preferência de que trata o caput somente

será conferida aos serviços técnicos complementares nacionais que estejam diretamente

vinculados e sejam aplicáveis aos programas de computador (software) nacionais que atendam

às regras de aplicação das margens de preferência de que tratam os parágrafos anteriores.

Art. 2o Será aplicada a margem de preferência de que trata o art. 1

o apenas para os

programas de computador (software) nacionais e serviços técnicos complementares nacionais,

conforme as regras de origem estabelecidas em portaria do Ministro de Estado Ciência,

Tecnologia e Inovação (MCTI)

§ 1o O licitante deverá apresentar, juntamente com a proposta, formulário de declaração

de cumprimento das regras de origem, conforme modelo publicado em portaria Ministro de

Estado Ciência, Tecnologia e Inovação (MCTI).

§ 2o Na modalidade pregão eletrônico:

I - o licitante declarará, durante a fase de cadastramento das propostas, se o produto

atende às regras de origem; e

II - o formulário referido no § 1o deverá ser apresentado com os documentos exigidos

para habilitação.

§ 3o Os programas de computador (software) nacionais e serviços técnicos

complementares nacionais que não atenderem às regras de origem ou cujo licitante não

apresentar tempestivamente o formulário referido neste artigo serão considerados como

programas de computador (software) e serviços técnicos complementares estrangeiros para

fins deste Decreto.

Art. 3o A margem de preferência de que trata o art. 1

o será calculada sobre o menor

preço ofertado de programas de computador (software) e serviços técnicos complementares

estrangeiros, conforme a fórmula prevista no Anexo II e as seguintes condições:

I - o preço ofertado de programas de computador (software) e serviços técnicos

complementares nacionais será considerado menor que PE, sempre que seu valor for igual ou

inferior a PM; e

II - o preço ofertado de programas de computador (software) e serviços técnicos

complementares nacionais será considerado maior que PE, sempre que seu valor for superior a

PM.

Art. 4o A margem de preferência de que trata o art. 1

o será aplicada para classificação

das propostas:

I - após a fase de lances, na modalidade de pregão; e

II - no julgamento e classificação das propostas, nas demais modalidades de licitação.


§ 1o A margem de preferência prevista não será aplicada caso o preço mais baixo ofertado seja de programas de

computador (software) e serviços técnicos complementares nacionais.

§ 2o Caso o licitante da proposta classificada em primeiro lugar seja inabilitado, ou deixe de cumprir a obrigação prevista

no inciso II do § 2o do art. 2

o, deverá ser realizada a reclassificação das propostas, para fins de aplicação da margem de

preferência.

§ 3o Caso a licitação tenha por critério de julgamento o menor preço do grupo ou lote, a margem de preferência só será

aplicada se todos os itens que compõem o grupo ou lote atenderem às regras de origem de que trata o art. 2o.

§ 4o A aplicação da margem de preferência não exclui a negociação entre o pregoeiro e o vencedor da fase de lances,

prevista no § 8o do art. 24 do Decreto no 5.450, de 31 de maio de 2005.

§ 5o A aplicação da margem de preferência não exclui o direito de preferência das microempresas e empresas de

pequeno porte, previsto nos arts. 44 e 45 da Lei Complementar no 123, de 14 de dezembro de 2006.

§ 6o A aplicação da margem de preferência estará condicionada ao cumprimento, no momento da licitação, do disposto

no § 9o do art. 3o da Lei no 8.666, de 21 de junho de 1993.

Art. 5o Os estudos previstos no § 6o do art. 3o da Lei no 8.666, de 1993, serão revistos anualmente a partir da data de

publicação deste Decreto.

Art. 6o As margens de preferência de que trata o art. 1

o serão aplicadas até 31 de Dezembro de 2014, no caso dos

programas de computador (software) e serviços técnicos complementares nacionais descrito no Anexo I.

Art. 7o Este Decreto entra em vigor na data da sua publicação.

Brasília, __ de ______________ de 2012; 191o da Independência e 124

o da República.

DILMA ROUSSEFF

Marco Antonio Raupp


ANEXO I

Programas de computador (software) e Margem de Margem de Preferência

serviços técnicos complementares Código NBS Preferência

Adicional

Normal

Grupo 1 - Licenciamento de direitos e Cessão de Direitos sobre programas de computador e Bancos de Dados

Licenciamento de direitos de uso de programas 1.1103.21.00 18% 7%

de computador ou bancos de dados

Licenciamento de outros direitos sobre 1.1103.29.00 18% 7%

programas de computador ou bancos de dados

Cessão de direitos sobre programas de 1.1104.20.00 18% 7%

computador ou bancos de dados

Cessão de direitos sobre programas de 1.2701.20.00 18% 7%

computador ou bancos de dados

Grupo 2 – Serviços Técnicos Complementares

Serviços de projeto, desenvolvimento e

18% 7%

instalação de aplicativos e programas não 1.1502.10.00

personalizados (não customizados)

Serviços de projeto e desenvolvimento,

18% 7%

adaptação e instalação de aplicativos 1.1502.20.00

personalizados (customizados)

Serviços de projeto e desenvolvimento de 1.1502.30.00 18% 7%

estruturas e conteúdo de páginas eletrônicas

Serviços de projeto e desenvolvimento de 1.1502.40.00 18% 7%

estruturas e conteúdo de bancos de dados

Serviços de integração de sistemas em 1.1502.50.00 18% 7%

tecnologia da informação (TI)

Outros serviços de projeto e desenvolvimento

18% 7%

de programas de computador ou bancos de 1.1502.90.00

dados

Serviços de hospedagem de sítios na rede 1.1506.10.00 18% 7%

mundial de computadores

Serviços de hospedagem de aplicativos, 1.1506.20.00 18% 7%

programas ou bancos de dados

Outros serviços de infraestrutura para 1.1506.90.00 18% 7%

hospedagem em tecnologia da informação (TI)

Serviços de gerenciamento de sistemas 1.1507.20.00 18% 7%

Outros serviços de gerenciamento de 1.1507.90.00 18% 7%

infraestrutura de tecnologia da informação (TI)

Serviços de manutenção de aplicativos, 1.1508.00.00 18% 7%

39


programas e bancos de dados

Suporte Técnico em informática, inclusive

18% 7%

Instalação, configuração e manutenção de 1.1508.00.00

programas de computador e bancos de dados

Outros serviços de gerenciamento de 1.1510.00.00 18% 7%

tecnologia da informação (TI)

18% 7%

Assessoria e Consultoria em informática 1.1510.00.00


ANEXO II

Fórmula

PM = PE x (1 + M), sendo:

PM - preço com margem;

PE - menor preço ofertado de programas de computador (software) e serviços técnicos

complementares estrangeiros;

M - margem de preferência em percentagem, conforme estabelecido no Anexo I a este

Decreto.;

Notas em relação ao Anexo I, em conformidade com o anexo e notas técnicas do Decreto 7.708/2012

a) a expressão “programas não-personalizados (não customizados)” diz respeito aos programas para

computadores adquiridos na forma que se apresentam e que, em regra, não permitem alterações

com o intuito de atender necessidades particulares;

5 “aplicativos personalizados” são programas customizados, que atendem às necessidades

específicas do seu adquirente ou usuário.

6 -- Serviços de projeto e desenvolvimento, adaptação e instalação de aplicativos e programas não personalizados (não customizados), que se classificam na subposição 1.1502.10;

d) Serviços de projeto e desenvolvimento, adaptação e instalação de aplicativos personalizados

(customizados), se classificam na subposição 1.1502.20;

e) - Serviços de projeto e desenvolvimento de estruturas e conteúdo de páginas eletrônicas, se

classificam na subposição 1.1502.30;

f) Serviços de projeto e desenvolvimento de estruturas e conteúdo de bancos de dados, se

classificam na subposição 1.1502.40; e

g) - Serviços de integração de sistemas em tecnologia da informação, que se

classificam na subposição 1.1502.50. h) O decreto nº 7.708, de 2 de abril de 2012 Institui a Nomenclatura Brasileira de

Serviços, Intangíveis e Outras Operações que Produzam Variações no Patrimônio -

NBS e as Notas Explicativas da Nomenclatura Brasileira de Serviços, Intangíveis e

Outras Operações que Produzam Variações no Patrimônio - NEBS.


APÊNDICE II

Minuta de Portaria

PORTARIA MCTI Nº _____/2012 - LICITAÇÃO - MARGEM

PREFERÊNCIA PROGRAMAS DE COMPUTADOR (“SOFTWARE”)

NACIONAIS E SERVIÇOS TÉCNICOS COMPLEMENTARES NACIONAIS

- REGULAMENTAÇÃO TEXTO - REPUBLICAÇÃO

Portaria nº ______, de __ de ___________ de 2012

Dispõe sobre a aplicação de margem de preferência nas licitações realizadas no

âmbito da Administração Pública Federal para aquisição de programas de

computador (“software”) nacionais e serviços técnicos complementares nacionais

descritos no Anexo I, para fins do disposto no art. 3o da Lei no 8.666, de 21 de junho

de 1993.

O MINISTRO DE ESTADO DA CIÊNCIA, TECNOLOGIA E INOVAÇÃO (MCTI) de acordo com o § 6º, do art. 8º, do Decreto ______, de ____ de _______ de 2012, resolve:

Art. 1º Fica instituído o Regime de Origem para a aplicação de margem de preferência nas

licitações realizadas no âmbito da Administração Pública Federal para aquisição de programas

de computador (“software”) nacionais e serviços técnicos complementares nacionais.

Art. 2º O presente Regime define as normas de origem que deverão ser consideradas

para que programas de computador (“software”) e serviços técnicos complementares atenda o

conceito de programas de computador (“software”) nacionais e serviços técnicos

complementares nacionais disposto no art. ____, do Decreto nº____, de ____ de _______ de

2012,.

Art. 3º Para efeitos do presente Regime:

a) programa de computador” é a expressão de um conjunto organizado de

instruções em linguagem natural ou codificada, contida em suporte físico de

qualquer natureza, de emprego necessário em máquinas automáticas de tratamento

da informação, dispositivos, instrumentos ou equipamentos periféricos, baseados em

técnica digital ou análoga, para fazê-los funcionar de modo e para fins determinados.

b) a expressão “programas não-personalizados (não customizados)” diz respeito aos programas para computadores adquiridos na forma que se apresentam e que, em

regra, não permitem alterações com o intuito de atender necessidades particulares;


“aplicativos personalizados” são programas customizados, que atendem às

necessidades específicas do seu adquirente ou usuário.

-- Serviços de projeto e desenvolvimento, adaptação e instalação de aplicativos e

programas não personalizados (não customizados), que se classificam na subposição

1.1502.10;

Serviços de projeto e desenvolvimento, adaptação e instalação de

aplicativos personalizados (customizados), se classificam na subposição 1.1502.20;

f) - Serviços de projeto e desenvolvimento de estruturas e conteúdo de páginas

eletrônicas, se classificam na subposição 1.1502.30;

Serviços de projeto e desenvolvimento de estruturas e conteúdo de bancos

de dados, se classificam na subposição 1.1502.40; e

- Serviços de integração de sistemas em tecnologia da informação, que se

classificam na subposição 1.1502.50.

Art. 4º Serão considerados programas de computador (“software”) nacionais e

serviços técnicos complementares nacionais, que fazem jus a margem de

preferência normal (a ser complementado com a pontuação proposta no Capítulo 2):

Declaração de cumprimento das regras de origem do representante legal de

empresa constituída em território nacional, que comprovam que o programa

de computador em questão atende aos requisitos do artigo 3 parágrafo V da

Lei 8.666/93. Esta declaração será obrigatória para todas as empresas,

independente do cumprimento dos demais quesitos mencionados na tabela, e

deverá ser preenchida e enviada a uma das entidades representativas.

Certificação ISO 9000 - A utilização do certificado ISO 9000 comprova atendimento das normas técnicas brasileiras, conforme exigência do § 5º do artigo 3º da Lei 8.666/93.

c) Carta declaratória de cliente indicando que adquiriu ou avaliou o produto de

software. Esta carta deverá ser escrita por clientes da empresa interessada

como forma de recomendação do produto adquirido.

d) Documentação técnica em português (Requisitos, arquitetura e/ou modelagem

de base de dados). Documentação gerada no processo de desenvolvimento,

implementação e avaliação do produto, visando assegurar que o mesmo

tenha sido produzido para o cliente nacional.


Documentação técnica em português (Requisitos, arquitetura e/ou modelagem

de base de dados) em que conste aprovação formal do cliente.

Código fonte depositado junto a terceiros, comprovado por meio de cláusula

contratual ou documento de registro emitido pelo cliente.

Produto cadastrado para venda por meio do Cartão BNDES. O processo de

cadastro de produtos para serem adquiridos com cartão BNDES impõe regras de

origem bem definidas que podem comprovar com eficácia o desenvolvimento

dentro do território nacional.

Declaração RAIS detalhando as ocupações em desenvolvimento de software. O

preenchimento da declaração RAIS – Relação Anual de Informações Sociais

possibilita a disponibilização de informações que envolvem os trabalhadores

ocupados na empresa, logo, é fonte de dados que comprovam o estabelecimento

de equipes de desenvolvedores no país.

URL de currículo publicado no sistema Lattes, indicando vínculo com a empresa

e conhecimento/experiência relacionados a TI. Este item é focado na equipe desenvolvedora que, por meio de sua experiência profissional, pode atestar

participação no desenvolvimento de produtos e serviços para a empresa. Serão

aceitas no máximo três URL’s, com validade de 0,5 pontos cada.

Certificados de Treinamento Técnico da Equipe Técnica Local. Este item

também é focado na equipe desenvolvedora, e demonstra o comprometimento

da empresa com a qualificação de seus colaboradores no âmbito nacional.

Prêmio concedido ao produto. A empresa deve apresentar certificados, títulos ou

declarações de premiação nacional ou referente à produção nacional.

Disponibilização de Logs de Alterações e/ou Logs de defeitos do software e suas correções.

Neste caso, a empresa precisa apresentar documentação que comprove a evolução do

produto ao longo de pelo menos 90 dias, identificando o autor das alterações, ou registro dos

defeitos por colaborador da empresa que se comprove trabalhar no país.

Disponibilização de Base de Dados de Alocação de Horas-homem ou tarefas. A

empresa deve apresentar relatórios de controle e alocação dos recursos humanos

atestando o trabalho da equipe em determinado local do território nacional.

Manual de Usuário em Português, com identificação do(s) autor(es) local(is). Este quesito

demonstra que a empresa elaborou sua documentação a partir de equipe dentro do país.

44


Resultados de Pesquisa de Satisfação dos Clientes contratado junto a terceiros. A pesquisa

de satisfação demonstra o interesse da empresa em avaliar a qualidade de seu produto e/ou

serviços junto aos seus clientes, contribuindo para o desenvolvimento do país.

Registro de Propriedade Intelectual do Software no INPI. Nesse documento

consta a declaração de origem de desenvolvimento do produto.

Apresentação de Interface de Usuário em Português Brasileiro. Os produtos

devem ter sido produzidos visando facilitar a sua utilização para o usuário

brasileiro, portanto sua interface deve estar em língua nativa.

Serão considerados programas de computador (“software”) nacionais e serviços

técnicos complementares nacionais, que fazem jus a margem de preferência

adicional (a ser complementado com a pontuação proposta no Capítulo 2): Desenvolvimento Local a) Certificação mps.br – Melhoria de Processos do Software Brasileiro – é um modelo

desenvolvido pela Softex, em parceria com o governo federal e universidades para realizar

uma certificação nacional de baixo custo voltado às pequenas e médias empresas. b) Certificação CMMi (Capability Maturity Model Integration) – é modelo de

certificação internacional direcionado às melhores práticas de gerenciamento dos

processos da empresa, e propõe uma evolução no grau de maturidade desses

processos segundo diferentes níveis. c) Certificação ISO 29110 (Produto de Desenvolvimento de Software para MPE) – é

um modelo de certificação de baixo custo direcionado a micro e pequenas

empresas brasileiras que propõe agregar valor aos processos de

desenvolvimento de software no país. d) Patente depositada no INPI - Instituto Nacional da Propriedade Industrial atesta

de forma legítima o conhecimento transformado em inovação, trazendo um

diferencial competitivo aos produtos desenvolvidos. e) Contrato de Cessão/Venda da Tecnologia a outras Empresas no País. A

documentação de contrato de negócios realizados no mercado interno.


f) Contrato de Cessão/Venda da Tecnologia a outras Empresas no Exterior. A

documentação de contrato de negócios via exportação. Negócios

g) Participação em Feiras e Congressos no país trazem novas oportunidades de

negócios e atestam sua busca por conhecimento e inovação. Parcerias e Alianças

h) Contratos que comprovam a existência de ecossistemas de empresas que

compõem a rede de comercialização e suporte ao produto.

i) Manutenção de Aliança Formal com player do Setor de TI. Contratos com outras

empresas de TI com o objetivo de estabelecer uma aliança formal.

j) Comprovação de usufruto de benefícios fiscais da Lei do Bem. A Lei

11.196/2005, também conhecida como Lei do Bem, beneficia empresas que

investem em pesquisa e desenvolvimento de inovação tecnológica. Tecnologia k) Papers acadêmicos, dissertações ou teses escritos por colaboradores da

empresa, relacionados ao alvo do software avaliado atestam a valorização de

pesquisa e desenvolvimento visando inovação do produto. l) Centro de P&D Local credenciado pelo CATI. As empresas que possuem centros

de pesquisa e desenvolvimento local credenciadas pelo CATI/MCT podem

apresentar seus plano de P&D, projetos e relatórios de pesquisa. m) Contrato de Cooperação com Instituição Acadêmica ou Instituto Científico-

Tecnológico em Território Nacional atestam a parceria das empresas com o meio

acadêmico e o comprometimento com a busca de inovação tecnológica.

n) Declaração RAIS detalhando as ocupações em pesquisa e desenvolvimento –

declaração da RAIS preenchida com as informações sobre os trabalhadores

ocupados em categorias relacionadas à P&D.


o) Projeto apresentado a órgãos de fomento no país ou no Exterior. A produção de

conhecimento através da elaboração e apresentação de projetos buscando

parcerias em órgãos de fomento no país e no exterior.

p) Projeto aprovado junto a órgãos de fomento no país ou no Exterior. Agrega

mais valor caso o projeto passe pelos critérios de aprovação dos órgãos de

fomento, atestando sua qualidade e viabilidade.

q) URL de currículo publicado no sistema Lattes, indicando vínculo com a

empresa ou co-participação em projeto, conhecimento/experiência relacionados

a TI e título de doutor strictu sensu. Vale 0,5 pontos cada, no máximo três

URL’s.

Art. 5º Para os produtos do Anexo I que estejam sujeitos a requisitos específicos

baseados na regra de participação percentual do “valor CIF dos componentes de

origem externa”, dever-se-á utilizar a seguinte fórmula:

valor CIF dos componentes de origem externa x 100 = VCOE%

valor de comercialização do programa de computador pelo ofertante

§ 1º Considera-se "valor CIF dos componentes de origem externa" o valor dos componentes

importados convertidos em Reais (R$) na data de fechamento do câmbio em pagamento das

licenças de uso ou dos direitos de distribuição/comercialização correspondentes. § 2º Considera-se "valor de comercialização do programa de computador pelo ofertante” o

valor contido na nota fiscal emitida pelo estabelecimento conforme a legislação nacional

aplicável.

Art. 6º A Declaração de Origem é o documento pelo qual o licitante manifesta

que o programa de computador ou dos serviços técnicos complementares objeto de

licitação cumprem com a regras do presente regime.

Parágrafo único. O licitante se comprometerá a fornecer os documentos

necessários à comprovação de origem do produto e garantirá as condições de

verificação no local de produção ou da prestação dos serviços correspondentes.

Art. 7º Deverá ser apresentada uma Declaração de Origem por programa de

computador ofertado, objeto da licitação, declaração essa que será extensiva para os

serviços técnicos que lhe serão complementares.


Art. 8º A Declaração de Origem deverá ser preenchida e assinada pelo licitante,

conforme modelo disposto no Anexo II e não deverá conter rasuras.

Art. 9º. Esta Portaria entra em vigor na data da sua publicação.

Marco Antonio Raupp

Metodologia de Avaliação CERTICS para Software


Apêndice III - Declaração de Origem

A empresa xxxxxxxxxxxx, constituída e registrada em território nacional, sob o CNPJ

99.999.999/9999-99, com sede em <endereço completo>, desenvolvedora do produto de

software denominado <nome do produto>, declara sob as penas da Lei que cumpre com

as exigências do Decreto xxxx e da Portaria yyyy que definem as normas de qualificação

à margem de preferência nas compras públicas para produtos de software nacionais, por

dispor de e apresentar os seguintes documentos: - aqui devem ser relacionados os documentos apresentados

Local e data.

As Entidades de Classe emitirão Certidão explícita indicando terem recebido a

Declaração de Origem e todos os documentos nela constantes, indicando a pontuação

alcançada pela empresa e declarando-a portanto habilitada ao direito de usufruir da

margem de preferência NORMAL nas compras públicas para produtos nacionais.





De : Ruben Delgado

Qua, 12 de Dez de 2012 09:34

Assunto : Submissão de contribuição da FNTI para a Chamada Pública da Certics

4 anexos

Para : Roberto C. Mayer Consulta publica

<[email protected]>

Cc : 'A nselmo Gentile', Manoel Santos

, Gerson Schmitt >,Arnaldo Bacha de A lmeida, EDSON LUIZ LEA L, John Lemos

Forman, MGB, Luis Mario Luchetta

Desculpem senhores, posso ter me passado, mas houve uma reuni ao com a SEPIN da

FNTI? Eu nao me lembro de ter sido convidado. Pode ter sido erro meu.

abs a todos

RUBEN



Re: CERTICS-Contribuição Fundação Vanzollini


Qua, 12 de Dez de 2012 16:28

Assunto : Re: CERTICS-Contribuição Fundação Vanzollini

Para : Marcelo Pessoa

Prezado,


Todas as contribuições da Consulta Pública serão analisadas e serão publicadas no

site da CERTICS.

Atenciosamente,

Angela Maria A lves

Coordenadora Executiva


De: "Marcelo Pessoa"

Para: "Consulta publica" <[email protected]>, "Jose Joaquim A.

Ferreira"

, "Airton C. Gonzalez", "Sarah Kohan"


Assunto: CERTICS-Contribuição Fundação Vanzollini

Anexo segue carta de contribuição da Fundação Carlos Alberto Vanzolini

--

Marcelo Pessoa

Fundação Vanzolini



ANEXO VANZOLINI





Re: SUGESTÃO METODOLOGIA


Qua, 12 de Dez de 2012 16:29

Assunto : Re: SUGESTÃO METODOLOGIA

Para : Marcelo Massao

Prezado,



site da CERTICS.

Atenciosamente,

Angela


De: "Marcelo Massao"


Enviadas: Terça-feira, 11 de Dezembro de 2012 15:59:35

Assunto: SUGESTÃO METODOLOGIA

Prezados,

Como sugestão na Área de Competência Desenvolvimento:

Descrição: refere-se ao domínio do conjunto de tecnologias utilizado para o

desenvolvimento de determinado software. Esse domínio de conhecimento deve estar

focado na arquitetura do software, na plataforma utilizada para sua construção e

na plataforma de execução. No seu desenvolvimento o mesmo deve contemplar:

1. A liberdade de executar o programa, para qualquer propósito(liberdade nº 0)

2. A liberdade de estudar como o programa funciona e adaptá-lo para as suas

necessidades (liberdade nº 1). O acesso ao código-fonte é um pré-requisito para

esta liberdade.

3. A liberdade de redistribuir cópias de modo que você possa ajudar ao seu

próximo (liberdade nº 2).

4. A liberdade de aperfeiçoar o programa, e liberar os seus aperfeiçoamentos, de

modo que toda a comunidade se beneficie deles (liberdade nº 3). O acesso ao

código-fonte é um pré-requisito para esta liberdade.

Grato pela atenção

--

http://www.prontofaLei.blog.br

AGORA É LEI: 5978 de 24/05/211

"Os órgaõs e entidades da administração pública direta, indireta, autárquica e

fundacional do Estado do Rio de Janeiro, bem como os órgãos autônomos e empresas

sob o controle estatal adotarão preferêncialmente, formatos abertos de arquivos

para a criação, armazenamento e disponibilização digital de documentos".

Atenção! Caso haja documentos de escritório anexados neste e-mail, eles poderão

estar no formato ODF, um padrão aberto, gratuito e homologado pela ISO e ABNT.

Para abrir e editá-los, basta baixar e instalar o BrOffice, disponível em

http://libreoffice.org.br

Marcelo Massao Osava

Padrão Aberto de Documentos (ODF)

http://acessa.me/a6d2

Linux user number 436596



Re: Contribuições ISPM para Metodologia CERTICS


Qua, 12 de Dez de 2012 16:29

Assunto : Re: Contribuições ISPM para Metodologia CERTICS

Para : Renato Salvadori

Prezado,



site da CERTICS.

Atenciosamente,

Angela




De: "Renato Salvadori"



Assunto: Contribuições ISPM para Metodologia CERTICS

Prezados Senhores,

Boa tarde.

Seguindo recomendações disponíveis no site do CERTICS, venho através deste e-

mail, em nome da empresa ISPM, apresenta-los nossas contribuições quanto à

sugestões que julgamos importantes para o processo de certificação de

desenvolvimento de Software - CERTICS.

Desde já, agradecemos pela oportunidade.

Cordialmente,

Renato Salvadori, PMP

ITIL/COBIT/MCP/CPP

Engenheiro de Pré-Vendas

ISPM - Soluções para Gestão de Nível de Serviço



De : Jacson Renzo Querubin

Ter, 11 de Dez de 2012 15:54

Assunto : Consulta


Boa Tarde,

Gostaria de saber se há a possibilidade da certificação de alguma solução

baseada em software livre?

Grato,

Att.

Jacson R. Querubin

Analista Suporte | Divisão de Suporte Técnico - SIPS.GG

OBSERVAÇÃO:

A ITAIPU esclarece que, por força de seu Estatuto, a presente mensagem não

implica a assunção de obrigações em seu nome.



De : Fernando Botelho

Ter, 11 de Dez de 2012 14:56

Assunto : definição de software nacional


Prezados,

Quero pedir que todo software livre, ou seja, todo software com lisença GPL, seja

automaticamente considerado software nacional. Isto traria grandes beneficios

para micro e pequenas empresas, o nível de inovação tecnológica no Brasil, e

consequentemente, aceleraria o nosso crescimento econômico.

Agradeço a sua consideração,

Fernando

________________________________________

Fernando H. F. Botelho, Fellow da Ashoka



Re: CP CERTICS


Qua, 12 de Dez de 2012 16:29

Assunto : Re: CP CERTICS

Para : Francisco Carlos Soares

Prezado,



site da CERTICS.



Atenciosamente,

Angela


De: "Francisco Carlos Soares"



Assunto: CP CERTICS

Prezados Senhores,

Seguem, anexo, os comentários da Qualcomm quanto a Consulta Pública em

referência. Esperamos poder estar contribuindo positivamente, nesse processo

liderado pelo Ministério da Ciencia, Tecnologia e Inovação. Caso seja desejável e

necessário esclarecimentos adicionais, estamos a disposição do Ministério para

discutir o assunto a qualquer momento.

Atenciosamente,

FRANCISCO GIACOMINI SOARES

Diretor Sênior - Relações Governamentais



ANEXO QUALCOMM





RE: CERTICS - Contato

De : ALESSANDRO QUATTRINI

Qua, 05 de Dez de 2012 17:32

Assunto : RE: CERTICS - Contato


Cc : Carolina Mattos

Cara Angela, boa tarde,

Gostaríamos de verificar qual é o prazo final para apresentação de nossas

contribuições à Metodologia CERTICS para Software ("Metodologia"). V.Sas, podem

por favor nos informar?

Atenciosamente,

ALESSANDRO QUA TTRINI



-----Original Message-----

From: Consulta Publica [mailto:[email protected]]

Sent: quarta-feira, 12 de setembro de 2012 12:36

To: ALESSANDRO QUATTRINI

Cc: Carolina Mattos

Subject: Re: CERTICS - Contato

Prezado Alessandro,

É isso mesmo. O prazo final será 19SET2012.

Não sabemos ainda se haverá prorrogação. Acho mais sensato trabalhar com a data

de 19SET.

Sim, as Consultas devem ser enviadas para

[email protected]

Att.

Angela Maria Alves


De: "ALESSANDRO QUA TTRINI"


Enviadas: Quarta-feira, 12 de Setembro de 2012 10:43:01


Prezados Srs.,

A Ericsson do Brasil está trabalhando para apresentar nossas contribuições à

Metodologia CERTICS para Software ("Metodologia"). Gostaríamos de saber de V.

Sas. o prazo final para apresentação de nossos comentários. Considerando que a

Metodologia foi colocada em Consulta Pública em 20/08 com um prazo de 30 dias, o

prazo final para as contribuições é 19/9/2012? As contribuições devem ser

enviadas a este e-mail [email protected] ?

Atenciosamente,






De : Alberto Bastos

Seg, 03 de Dez de 2012 10:07

Assunto : RE: CERTICS - Contato


Prezado Clenio, obrigado pela resposta.

Significa então que sugestões e comentários serão recebidos até 12/12/2012 porém

sem necessidade de uma reunião (audiência), certo?

Temos interesse em proceder com a certificação assim que estiver disponível,

gostaria de receber qualquer orientação neste sentido, ok?

Atenciosamente,

Alberto Bastos



Diretor de Tecnologia



Sent: segunda-feira, 3 de dezembro de 2012 09:50

To: Alberto Bastos


Prezado Alberto

Teve duas audiências públicas: uma dia 15/10 em Brasília e outra no dia

22/10 em Campinas. A Consulta Pública está aberta até deia 12/12/2012.

Atenciosamente

Clenio F. Salviano (pela equipe CERTICS)


De: "Alberto Bastos"


Enviadas: Segunda-feira, 26 de Novembro de 2012 19:51:28


Caros,

Gostaria de saber se o encerramento da Consulta Pública terá também uma

Audiência Pública ou se apenas o envio de comentários pelo email?

Atenciosamente,

Alberto Bastos



Seg, 03 de Dez de 2012 09:50


Para : Alberto Bastos

Prezado Alberto

Teve duas audiências públicas: uma dia 15/10 em Brasília e outra no dia 22/10 em

Campinas.

A Consulta Pública está aberta até deia 12/12/2012.

Atenciosamente



De: "Alberto Bastos"




Caros,

Gostaria de saber se o encerramento da Consulta Pública terá também uma Audiência

Pública ou se apenas o envio de comentários pelo email?

Atenciosamente,

Alberto Bastos




Re: Contribuições Certics - CPqD


Qua, 12 de Dez de 2012 16:30

Assunto : Re: Contribuições Certics - CPqD

Para : Antonio C. Bordeaux Rego

Prezado,



site da CERTICS.

Atenciosamente,

Angela


De: "Antonio C. Bordeaux Rego"




Cc: "CLeida Aparecida Queiroz Cunha"


Assunto: Contribuições Certics - CPqD

Prezados Giancarlo, Clênio e Angela

Visando contribuir para o esforço de aprimoramento da Metodologia CERTICS para

Software, a Fundação CPqD encaminha as seguintes contribuições:

Contribuição 1: Abrangência geral

1) a forma de cálculo do resultado final deve constar na Metodologia, como uma

fase ou sub-fase, porque hoje é apresentada como um exemplo de um só caso.

2) sugerimos que a nota final da avaliação com sucesso considere um a

porcentagem, que seja a média aritmética ou ponderada, do atendimento dos

resultados esperados.

Contribuição 2: referente à Área de Competência: Gestão de Tecnologia (TEC)

TEC.3. As tecnologias relevantes e estratégicas para o software são


Sugestão: Como indicador de que ocorrem ações voltadas para a apropriação do

conhecimento tecnológico, sugere-se considerar dois outros pontos como evidências

de capacitação nas tecnologias chaves: existência de colaborados certificados nas

tecnologias chaves e a participação da organização em fóruns nacionais e

internacionais que visam a padronização das tecnologias relevantes.

Contribuição 3: referente à Área de Competência: Gestão de Tecnologia (TEC)

TEC.5. A organização tem autonomia sobre as tecnologias relevantes e estratégicas

que estão presentes no software .

Sugestão: Quando houver necessidade da aquisição de uma tecnologia estratégica e

relevante desenvolvida por outra organização, fora ou dentro do País, para compor

um software desenvolvido no País, e o componente adquirido puder ser substituído

por outro de mercado sem comprometer as características e funcionalidades do

software, fica garantida a autonomia sobre as tecnologias relevantes de

estratégicas do software. Entretanto, deverá se justificada a necessidade de uso

deste componente.

Contribuição 4: referente à Área de competência Gestão de Parcerias e Alianças

(GPA)

Abrangendo os 3 critérios:

GPA.1 - Prospecções para novas parcerias e alianças relacionadas ao software são

realizadas.

GPA.2. - Parcerias e alianças relacionadas ao software são formalizadas para

pesquisa e desenvolvimento de tecnologia ou para atuação no mercado.

GPA.3. - A coordenação do conjunto de parcerias e alianças é realizada, incluindo

a gestão da execução, monitoramento de resultados e revisões.

Sugestão:

A questão da gestão de parcerias e alianças ocorre de forma diferente em

instituições de P&D, como é o caso da Fundação CPqD, uma vez que essas

instituições realizam pesquisa e desenvolvimento com pessoal próprio, onde se

inclui o próprio desenvolvimento de software.

Para as instituições de P&D, que não são universidades, mas que têm capacidade de

realizar atividades de pesquisa e desenvolvimento associado ou suportando o

desenvolvimento de software, sugerimos que seja previsto a suspensão da análise

dos três quesitos da área de competência de gestão de negócios.

Atenciosamente,

Bordeaux

Antonio Carlos Bordeaux Rego

Assessor Executivo em Inovação Tecnológica - CPqD



Re: CERTICS - Consulta Pública


Qua, 12 de Dez de 2012 16:31

Assunto : Re: CERTICS - Consulta Pública

Para : Atendimento <[email protected]>

Prezado,



site da CERTICS.



Atenciosamente,

Angela


De: "Atendimento" <[email protected]>

Para: "Americo Borghi Moreira Jacinto

Cc: "Consulta publica" <[email protected]>

Enviadas: Segunda-feira, 3 de Dezembro de 2012 9:22:55

Assunto: Re: CERTICS - Consulta Pública

Prezado Américo

Estamos aguardando o término da Consulta Pública (que será em 12/12/2012) para

concluir a compilação de todos os comentários e sugestões (inclusive os das duas

audiências públicas) e então faremos uma análise sobre os comentários e

sugestões.

Nesta ocasião divulgaremos este resultado, principalmente para o MPOG que tem

sido um parceiro.

Atenciosamente



De: "Americo Borghi Moreira Jacinto"


Cc: [email protected]

Enviadas: Quarta-feira, 21 de Novembro de 2012 10:45:53

Assunto: CERTICS - Consulta Pública

Prezados,

Entre em contato para verificar a possibilidade de compartilhamento de

informações relativas a Consulta Pública em andamento.

Gostaria de saber se existe material consolidado das participações na audiência

pública e sugestões enviadas (documentos, áudios, etc), e se vocês podem

disponibilizá-las.

Fico no aguardo. Agradeço a gentileza de sua atenção.

Atenciosamente,

--

Américo Borghi Moreira Jacinto

Analista em Tecnologia da Informação

Ministério do Planejamento, Orçamento e Gestão



De : (OASyS) Oscar Ribeiro

Sex, 30 de Nov de 2012 07:29

Assunto : CERTICS


Responder para : oasys info

Prezados Senhores,

Bom dia! Espero que estejam bem.

Eu desenvolvi um sistema administrativo integrado que auxilia na administração

completa de uma empresa: Compra de Materiais, Administração do Estoque, Vendas,

Produção, Financeiro e Fiscal.

Em que sentido o CERTICS pode me auxiliar? Como posso participar?

Aguardo,

Oscar B. Ribeiro Filho

OASyS Informática

"Aviso de confidencialidade profissional" - Esta mensagem eletrônica e seus

anexos são destinados exclusivamente ao(s) destinatário(s) acima e podem conter

informações confidenciais sujeitas a restrição legal de comunicação entre as

partes. Caso tenha recebido esta mensagem por engano, fica V.Sa. ciente de que a

distribuição, divulgação ou disseminação das informações aqui contidas ou

anexadas é terminantemente proibida, sujeitando o responsável às penalidades

aplicáveis.





Re: Contribuição para Consulta Pública CERTICS


Seg, 03 de Dez de 2012 09:53

Assunto : Re: Contribuição para Consulta Pública CERTICS

Para : sueli varani

Prezadas Sueli e Marcia Martinez

Obrigado pelas sugestões

Atenciosamente



De: "Sueli A . Varani"



Assunto: Contribuição para Consulta Pública CERTICS

Prezados,

Segue um texto com sugestões para a Metodologia CERTICS para Software.

Obrigada.

Sueli e Márcia Martinez

ANEXO CTI

Comentários para Consulta Pública da Metodologia CERTICS para Software

<mtmet> GPA.2. – página 41 – Item “Orientações”

a) Explicar melhor os dois termos: “resultados obtidos pelo software” e “resultados obtidos pelos projetos em parcerias, para a geração do software”. </mtmet>

<mtmet> GPA.3. – página 42 – Item “Orientações”

a) Explicar, dando exemplos, o termo “em outro contexto”; b) Os dois termos “acompanhar” e “monitorar” aparecem ao longo da descrição desse Resultado Esperado. Explicar se

há diferença entre eles e, caso não haja, padronizar os termos. </mtmet> c)

<mtmet> GNE.4. – página 35

a) Definir melhor a diferença entre instrumentos e ferramentas. Assumimos “ferramentas” como exemplos de instrumentos. Sugerimos incluir exemplos de instrumentos, além do que já está no texto (que são exemplos de ferramentas). </mtmet>

b) ===</thread>===[sequencial: 32]========================================= c) d) ===<thread>===[sequencial: 33]========================================== e) f) De : Jonas Sousa g) Qui, 22 de Nov de 2012 17:31 h) Assunto : INFORMA ÇÕES SOBRE TI MAIOR i) Para : Consulta publica <[email protected]> j) k) Gostaria de obter mais detalhe se possível enviando material que posa ter mais

embasamento e fico agradecido.

l) Jonas Sousa m) Coordenação de Ciência e Tecnologia n) Prefeitura Municipal de Limoeiro do Norte o) Secretaria de Educação Básica p) q) ===</thread>===[sequencial: 33]========================================== r) s) ===<thread>===[sequencial: 34]========================================== t) u) De : Kazuhiko Oi v) Qua, 21 de Nov de 2012 20:05 w) Assunto : Comments on the software certification methodology in Brazil x) 1 anexo



y) Para : Consulta publica <[email protected]> z) aa) Dear Dr. Virgilio Almeida, bb) Please find attached our comments regarding the software certification

methodology, the CERTIS and related policies in Brazil.

cc) We much appreciate in advance your consideration. dd) Best regards, ee) Kazuhiko Oi ff) Japan Electronics and Information Technology Industries Association(JEITA ) gg) ------------------------------------------------ hh) Kazuhiko Oi ii) JEITA Washington DC Office



ANEXO JEITA





CERTICS - Contato

De : Célio Fabiano de Souza - DeskManager

Sex, 09 de Nov de 2012 21:15

Remetente : celio souza



Boa noite,

Somos da Desk Manager Software, fabricante do software para Servicedesk e Centro

de suporte.

Gostaria de saber como podemos fazer o cadastro para avaliação de nossa empresa e

processo para certificação.

Desde já muito obrigado

Abraços

--

Atenciosamente,

Célio Fabiano de Souza

Cobit4.1



Re: DIGITALEUROPE comments on software certification


Qua, 12 de Dez de 2012 16:32

Assunto : Re: DIGITA LEUROPE comments on software certification

Para : Julia Jasinska

Prezado,



site da CERTICS.

Atenciosamente,

Angela


De: "Julia Jasinska"



Assunto: DIGITALEUROPE comments on software certification

Dear Sir/Madame,

Please find attached DIGITA LEUROPE comments prepared for your Consultation on

Software Assessment Methodology. Our position attached. Please don’t hesitate to

contact us in case you have any questions.

Julia Jasinska

Manager, Public A ffairs

Trade Policy

DIGITALEUROPE >> 14 Rue de la Science, 1040 Brussels

T. +32 2 609 5323 >> M . +32 471 910548

http://www.digitaleurope.org

The information in this email is confidential and is intended solely for the

addressee. A ccess to this email by anyone else is unauthorised. If you are not

the intended recipient, you must not read, use or disseminate the information.

Any views expressed in this message are those of the individual sender, except

where the sender specifically states them to be the views of DIGITALEUROPE.



ANEXO DIGITAL EUROPE




De : Adelcio Cabral

Dom, 04 de Nov de 2012 12:10

Assunto : Informações sobre o AVISO DE A UDIÊNCIA PÚBLICA


Cc : [email protected]

Bom dia,

Sobre o Aviso de Audiência Pública -

http://www.certics.cti.gov.br/downloads/Aviso%20Audiências%20Publicas_ver04.pdf -

citada no link mencionado anteriormente, é possível ter acesso ao que foi

tratado?

Pesquisei no site mais não localizei o material conforme cita o item 3. Do

registro e divulgação dos resultados da audiência

Desde já, obrigado pelo retorno.

Atenciosamente,

Adelcio



RES: Consulta Pública

De : Felipe Herzog

Qua, 24 de Out de 2012 12:47

Assunto : RES: Consulta Pública


Ótimo, Angela.

Obrigado.

-----Mensagem original-----

De: Consulta Publica [mailto:[email protected]]

Enviada em: quarta-feira, 24 de outubro de 2012 12:45

Para: Felipe Herzog

Assunto: Re: Consulta Pública

Prezado Felipe

A Consulta Pública foi prorrogada até o dia 12DEZ2012. O site deverá refletir

esta alteração no mais tardar amanhã.

Att.

Angela


From: "Felipe Herzog"


Sent: Wednesday, October 24, 2012 10:36:27 A M


Prezados,

Saberiam me informar quando será publicada o novo prazo da Consulta Pública?

Grato,



De : Igor Gavazzi Vazzoler

Seg, 22 de Out de 2012 12:07

Assunto : Programa TI Maior: Sugestão


Cc : Daniane Bergamini, Eduardo Artur Cunha

Caro organizador do programa TI Maior,

como estamos em fase de envio de sugestões para a implementação do programa, eu

gostaria de contribuir com a seguinte sugestão:

É importante que estejam contempladas no programa empresas de tecnologia que não

lidam exclusivamente com desenvolvimento de software "puro". Eu acho que seria

bastante relevante que pudessem ser habilitadas empresas do tipo industrial, como



a minha empresa, Progic, desde que estas tenham no desenvolvimento de software

uma componente importante do seu investimento em P&D.

O exemplo da minha empresa (Progic) é ilustrativo: a empresa é do tipo indústria

e comércio, temos desenvolvimento de produtos eletrônicos, temos fabricação

própria dos produtos eletrônicos que desenvolvemos, mas o maior investimento da

empresa é no desenvolvimento de software.

Existe uma tendência de empresas de tecnologia se tornarem mais verticalizadas,

entregarem soluções mais completas, como o nosso caso. A Progic possui como

principal produto uma solução composta de hardware próprio e software próprio

trabalhando integrados. No que diz respeito ao software, inclui desde software

que é executado internamente pelo hardware quanto software de internet que é

executado a partir de um data-center, controlando remotamente os equipamentos

produzidos pela empresa.

Um outro exemplo, guardadas as devidas proporções, é a Apple. É uma empresa de

hardware que tem a maior parte de seu investimento de P&D na área de software.

Não dá pra dizer que a Apple não é uma empresa de TI, assim como não dá pra dizer

que a Progic não é uma empresa de TI.

É por esta razão que eu acho que empresas industriais eletrônicas como a Progic

devem ser contempladas no programa, mesmo que não sejam exclusivamente empresas

de desenvolvimento de software, pois a parte de desenvolvimento de software da

empresa é muito relevante e bastante intensa e estratégica para esta.

Espero que posso ter contribuído.

Atenciosamente,

Igor Gavazzi Vazzoler

Diretor Geral



Re: Certificação de software


Sex, 19 de Out de 2012 12:11

Assunto : Re: Certificação de software

Para : Claudio Minei


Prezado Cláudio,

Sua contribuição será avaliada quando da consolidação da Consulta Pública.

Att.

Angela


From: "Claudio Minei"


Sent: Friday, October 19, 2012 12:08:16 PM

Subject: Certificação de software

Prezado Administrator,

Antes de propor a sugestão gostaria de tecer a seguinte consideração.

A instrução normativa número 4 de 2008 já trata da recomendação de compra de

software pelo Governo. Embora ela tenha esse carater oficial, em termos práticos,

não sabemos se ela é realmente seguida. Por isso, a sugestão seria colocar na

certificação de software, os atributos de usabilidade e acessibilidade. A

usabilidade é um dos atributos que mede a qualidade de um software. Quanto a

acessibilidade, podemos afirmar que ela é um subconjunto da usabilidade, mas que

se reveste de uma importância sociocultural e econômica elevada.

Muito obrigado,

Claudio Norio Minei



Re: Prazo de contribuiçoes


Sex, 19 de Out de 2012 12:06

Assunto : Re: Prazo de contribuiçoes

Para : Claudio Norio



Prezado Cláudio,

O prazo, conforme publicado no site da CERTICS, é até 28NOV2012.

Att.

Angela


From: "Claudio Norio"


Sent: Friday, October 19, 2012 11:42:58 AM

Subject: Prazo de contribuiçoes

Prezado Administrador,

Gostaria de saber o prazo para se fazer contribuições sobre certificação de

software (Consulta Pública).

Grato, Cláudio



Re: CERTICS - Contato


Sex, 19 de Out de 2012 12:06


1 anexo

Para : Nelson Mitsuo Hirano

Prezado Nelson,

Veja resposta às suas questões abaixo, no corpo da mensagem por você enviada.

Att.

Angela


From: "Nelson Mitsuo Hirano"


Sent: Friday, October 19, 2012 9:06:37 A M

Subject: CERTICS - Contato

Prezados Srs,

Bom dia.

Temos total interesse em participar do Programa TI Maior como uma Empresa A

celeradora visando apoiar os Start-ups.

> O CTI é responsável pelo desenvolvimento da Metodologia de certificação de

tecnologia nacional em software, que uma parte do TI maior.

Perdemos a Audiência Públiica que ocorreu no dia 15 de Outubro em Brasília. Porém

estaremos presentes na segunda reunião que será no dia 22 Outubro.

Perguntas:

1- Temos que nos credenciar para participar desta audiência ?

>Não. A reunião da audiência é pública. Basta comparecer ao local na data e hora

marcadas.

2- Existe algum material da primeira reunião já disponível ?

>Não. Todo material só pode ser publicado após o término da Consulta Pública e

das reuniões da audiência pública.

3- Gostaria de conhecer o Centro de Tecnologia da Informação Renato Archer, ...é

possível ?

> Anexo a mensagem está o nosso canal para contato no CTI.

4- Existe alguma outra documentação ou formato para atuar como Empresa

Aceleradora, ou seja, já foi discutido este ponto na primeira reunião ?

> Não tratamos das ações para aceleradoras. Tratamos de certificação de

tecnologia nacional.

Aguardo retorno.

Att.

Descrição: cid:image001.png@01CDAA C1.9ED56E50

ALERTA - Esta mensagem e seus anexos provêm da empresa NC Games e contêm

informações confidenciais reservando os seus direitos sobre as informações e

conteúdo deste e-mail. Se, por engano, receber esta mensagem, por favor,

notifique o remetente respondendo por e-mail e exclua esta mensagem e seus

anexos, sem guardar cópia.

NOTICE - This message and its attachments come from the company NC Games and

contain confidential and privileged information. If you have received this



message in error, please notify the sender by reply e-mail and delete this

message and its attachments without retaining a copy valquiria.png



Re: Consulta publica (15 de outubro)


Sex, 19 de Out de 2012 11:59

Assunto : Re: Consulta publica (15 de outubro)

Para : João Paulo Rimes

Prezado João,

Sim, haverá a publicação, no site da CERTICS, de um documento contento as peças

que você citou.

O áudio das reuniões das audiências também será disponibilizado.

Att.

Angela


From: "João Paulo Rimes"

To: [email protected]

Cc: "Consulta publica" <[email protected]>

Sent: Wednesday, October 17, 2012 5:15:06 PM

Subject: Consulta publica (15 de outubro)

Boa tarde,

Estou acompanhando as discuções e a Consulta publica a respeito do CERTICS.

A respeito da 1ª Consulta publica, haverá publicação da ata ou registro dos

assustos discutidos nesse primeiro encontro?

Obrigado,

João Rimes.



Re: PROPOSTA DE MELHORIA CERTICS


Sex, 19 de Out de 2012 11:57

Assunto : Re: PROPOSTA DE MELHORIA CERTICS

Para : João Paulo Rimes

Prezado João,

No final da Consulta Pública haverá uma consolidação de todas as contribuições

referidas. Neste documento estará o tratamento, ou parecer, sobre sua

contribuição. O documento é público e estará disponível no site da CERTICS.

Att.

Angela

De : João Paulo Rimes

Qua, 17 de Out de 2012 16:54

Assunto : Re: PROPOSTA DE MELHORIA CERTICS


Boa tarde,

Gostaria de debater um pouco mais sobre a idéia e saber qual foi o parecer diante

da proposta enviada.

Desde ja obrigado,

João Rimes.

Em 10 de outubro de 2012 11:26, Consulta Publica

<[email protected]> escreveu:

Prezado João,

Agradecemos sua participação na Consulta Pública.

Suas sugestões serão analisadas pela equipe da Metodologia.

Att.

Angela




From: "João Paulo Rimes"

To: "Consulta publica" <[email protected]

Sent: Tuesday, October 9, 2012 2:52:24 PM

Subject: PROPOSTA DE MELHORIA CERTICS

Bom dia,

Meu nome é João Rimes e sou pesquisador e me especializei na área de qualidade e

teste de software.

Gostaria de parabenizar pelo conteúdo da Metodologia CERTICS, pois li e gostei do

conteúdo, mas tenho algumas observações importantes.

O Brasil esta caminhando para se tornar referencia em software e serviços. O

setor de teste de software esta evoluindo e se desenvolvendo no mercado nacional.

Vejo como uma sugestão adicionar mais informações no CERTICS a respeito do teste

de software como parte do processo de desenvolvimento e também como serviço.

Me disponho a debater nesse assunto e a fornecer materiais que contribuirão com o

CERTICS. A guardo um possível retorno e agradeço pela oportunidade em debater

sobre esse assunto.

João Rimes

--

Engº. João Paulo Cesar Rimes

Engenheiro de Testes

FLEXTRONICS - FACENS - SOROCA BA



De : Fabio Rodolfo Marques Benatti

Dom, 14 de Out de 2012 11:01

Assunto : Audiência Publica


Bom dia,

Por gentileza, gostaria de me inscrever na Audiência publica, caso tenha perdido

a primeira, poderia me inscrever na segunda?

obrigado

Fabio Rodolfo Marques Benatti

Escritório de Processos



Re: Consulta Pública CERTICS


Qui, 11 de Out de 2012 10:42

Assunto : Re: Consulta Pública CERTICS

Para : Almir Firmino

Prezado Firmino,

A forma de participação é via email. Para este mesmo endereço que você enviou

este mensagem.

Att.

Angela


From: "Almir Firmino"


Sent: Thursday, October 11, 2012 10:36:09 A M

Subject: Consulta Pública CERTICS

Prezados Senhores(as):

Gostaria de obter mais informações sobre como podemos participar desta Consulta

Pública.

Cordialmente,

Almir Firmino,

Diretor de TI,





Re: Custo Certificação Certics


Qua, 10 de Out de 2012 14:11

Assunto : Re: Custo Certificação Certics

Para : Rogério Mendonça

Prezado Rogério,

Sugiro que você Leia, detalhadamente, as informações publicadas no site.

Lá você encontrará respostas para estas questões.

Att.

Angela


From: "Rogério Mendonça"

To: "Consulta Publica" <[email protected]>


Subject: Re: Custo Certificação Certics

A certificas será a principal certificação, substituindo as entidades

certificadoras que hoje predominam?

Em quarta-feira, 10 de outubro de 2012, Consulta Publica escreveu:

Prezado Rogério,

Existe sim uma previsão.

Está previsto para a segunda quinzena de fevereiro de 2013.

Att.

Angela



To: "Consulta Publica" < [email protected] >


Subject: Re: Custo Certificação Certics

Então ainda não há previsão para o inicio do processo de certificação?

Att.

Em 10 de outubro de 2012 11:27,Consulta Publica


Prezado Rogério,

O custo da certificação ainda é objeto de estudo pela equipe CERTIC S.

Att. Angela



To: "Consulta publica" < [email protected] >

Sent: Monday, October 8, 2012 4:24:03 PM

Subject: Custo Certificação Certics

Boa tarde,

Qual é o custo da certificação?

Obrigado.



CERTICS - Contato

De : Edmilson Púlice de Castro

Ter, 02 de Out de 2012 16:29



Senhores,



Boa tarde!

Somos um empresa no ramo de tecnologia da informação e gostaríamos de maiores

detalhes quanto ao processo de certificação.

Para exemplificar, seguem algumas dúvidas relevantes:

1 – Como a empresa deve proceder para obter a certificação?

2 – Qual o custo total?

3 – em quanto tempo se dará a certificação?

Ficamos no aguardo.

Obrigado pela atenção.

Edmilson Púlice de Castro



Re: Duvidas referente a Consulta Publica - Certics


Qua, 03 de Out de 2012 09:46

Assunto : Re: Duvidas referente a Consulta Publica - Certics

Para : Maria Jose Ferreira de Lima Shimakawa

Prezada Maria Jose Ferreira de Lima Shimakawa

Sobre o primeiro ítem, é isto mesmo. Para um determinado Software ter a

certificação CERTICS, todas as áreas de competências precisar ser atendidas para

este Software. Como as áreas de competência são compostas pelos seus respectivos

Resultados Esperados, então todos os Resultados Esperados de todas as áreas

precisam ser atendidos. Sobre o segundo ítem, acho que existe um entendimento

equivocado.

Conforme descrito na Metodologia:

"4.5 Área de competência Gestão de Parcerias e Alianças (GPA)

Pergunta-chave

Parcerias e alianças possibilitam geração de negócios, atualização tecnológica ou

desenvolvimento tecnológico, relacionados ao software?

Descrição

A Área de Competência “Gestão de Parcerias e Alianças” envolve a formação,

operação e avaliação de projetos e acordos de cooperação, tecnológica e

comercial, entre a organização e fornecedores, financiadores, instituições de

ciência e tecnologia, universidades e outras organizações privadas e públicas,

que tenham como foco o software.

As parcerias e alianças podem ocorrer para desenvolver tecnologias, incorporar

novas competências e/ou promover o aprendizado de novos conhecimentos,

aperfeiçoar e desenvolver novas oportunidades para a organização em relação ao

software, explorar soluções inovadoras nesse software, obter novos recursos para

ele, minimizar custos, superar barreiras de mercado, criar economias de escala,

criar valor a partir do compartilhamento de recursos, posições, habilidades e

conhecimento, promover um melhor posicionamento estratégico, acessar um mercado,

ampliar rentabilidade, atender a necessidades legais e contratuais, licenciar

tecnologias, etc. Qualquer dessas ações deve ter como foco o software.

(...)"

Os Resultados Esperados desta Área são:

"

• GPA.1. Prospecções para novas parcerias e alianças relacionadas ao software são

realizadas.

• GPA.2. Parcerias e alianças relacionadas ao software são formalizadas para

pesquisa e desenvolvimento de tecnologia ou para atuação no mercado.

• GPA.3. A coordenação do conjunto de parcerias e alianças é realizada, incluindo

a gestão da execução, monitoramento de resultados e revisões."

Então a Metodologia não pede que tenha parceria para o processo de “Fabricação de

software, Implantação e Manutenção do software”.

A Metodologia pede que tenha parceira e alianças relacionadas ao Software e elas

podem ser "tecnológica e comercial, entre a organização e fornecedores,

financiadores, instituições de ciência e tecnologia, universidades e outras

organizações privadas e públicas".

A lógica da inclusão desta área na Metodologia está relacionada à importância de

ter alianças e parcerias.

No site da Ábaco, na primeira tela, tem o seguinte:

"Parceiros

A Ábaco está sempre preocupada em atender a seus clientes, com produtos de

qualidade, segurança e alto desempenho. E para



que isso seja realmente possível, a Ábaco é parceira de empresas mundialmente

reconhecidas, fornecendo software, hardware, segurança para qualquer finalidade

que atenda com qualidade os nossos clientes."

Acredito que estas parcerias devem atender ao que a Metodologia pede. Mas note

que isto precisa ser comprovado em uma

avaliação CERTICS e evidenciado que as parceiras estão relacionados com o

Software da Ábaco que esteja sendo avaliado.

Espero que esta resposta tenha ajudado a entender melhora a CERTICS

Quero fazer mais dois comentários:

a) Primeiro elogiar a forma e o conteúdo de sua pergunta. Houve um cuidado em

comunicar bem claro qual era a dúvida e

isto nos ajuda muito a responder. Isto também nos ajuda a entender onde existe

mais problemas de entendimento

b) Segundo, parece que não ficou claro para vocês que a certificação CERTICS é

para um determinado Software da empresa e não

para a empresa. Foi este o entendimento seus? A CERTICS busca certicar um

determinado Software e para tanto são analisados

as atividades realizadas para o desenvolvimento e comercialização deste software.

Clenio F. Salviano pela Equipe da CERTICS


De: "Maria Jose Ferreira de Lima Shimakawa"


Enviadas: Segunda-feira, 1 de Outubro de 2012 17:11:58

Assunto: Duvidas referente a Consulta Publica - Certics

Prezados !

Verificamos a Metodologia CERTICS e sugiram questionamentos:

•

Para pLeitearmos a certificação é necessário (Obrigatório) atender a todas as

áreas de competências Tecnológicas, descritas na

Metodologia? (Desenvolvimento , Gestão de Tecnologia, Gestão de parcerias e

alianças , gestão de negócios e gestão de Pessoas,

Processos e conhecimento).

•

Hoje trabalhamos de forma que todo o processo de “Fabricação de software,

Implantação e Manutenção do software” é realizado

pela empresa Ábaco, sem a participação de terceiros ou parceiros, o que nos gerou

duvidas referente à “Área de Competência

Gestão de Parcerias”. Como poderíamos participar e atender a esse i tem ?

Segue abaixo um histórico da nossa empresa

A ÁBACO TECNOLOGIA DE INFORMA ÇÃO LTDA , iniciou suas atividades em 17/07/1992,

contando atualmente com um contingente superior a 450 profissionais entre

colaboradores, funcionários e consultores, para atendimento às áreas: atendimento

ao cliente, consultoria, desenvolvimento em tecnologia e implantação de novos

projetos e produtos. Ábaco Tecnologia de informação desenvolve soluções na área

de tecnologia da Informação, otimizando o processo de gestão de Empresas públicas

e privadas. E se faz presente em diversos estados como: Acre, Alagoas, Espírito

Santo, Minas Gerais, Mato Grosso do Sul, Pará, Paraná, Rio Grande do Norte, Rio

Grande do Sul e São Paulo.

A Ábaco conta permanentemente em seu quadro de funcionários efetivo,

profissionais com certificação oficial nas tecnologias Microsoft, Oracle, IBM –

Lotus Notes, Linux, segurança da informação, gerenciamento de projetos, Genexus,

Java e conta com uma sólida equipe que desenvolve soluções na área de tecnologia

da informação, provendo melhorias na gestão administrativa de empresas públicas e

privadas. A estrutura de seus produtos baseia-se em uma arquitetura de

aplicativos que integra os processos que compõem todas as áreas da administração,

tornando rápido e confiável o acesso às informações necessárias para atingir as

Metas do gerenciamento organizacional.

A empresa é certificada NBR ISO 9001:2008- Sistemas de Gestão da Qualidade e

nossos processos são padronizados e controlados.

Temos interesse e necessidade em adquirir a certificação CERTICS,

Aguardamos retorno !

Atenciosamente

Maria José Ferreira de Lima Shimakawa

Representante da Direção

SGQ-Sistema de Gestão da Qualidade





Re: Consulta Pública Certics


Seg, 24 de Set de 2012 16:21

Assunto : Re: Consulta Pública Certics

Para : Geraldo Couto

Prezado Geraldo,

Todas as informações necessárias para a participação na Consulta Pública

encontra-se disponível no site www.certics.cti.gov.br.

As sugestões e participação na Consulta publica pode ser feita via email por meio

do canal [email protected]

Att.

Angela


From: "Geraldo Couto"


Cc: "Junior Couto" Sent: Thursday, September 20, 2012 9:57:54 PM

Subject: Consulta Pública Certics

Prezados Senhores,

Gostaria de saber como obter maiores informações sobre a Consulta Pública que

está em andamento, assim sobre como obter o acesso às informações e documentos

necessários.

Att,

logomarca Via 4.jpg

Geraldo Couto | Diretor-Presidente | MSA Enterprise Search Platform | MCTS

[image/png:2B48E444-24EC-4919-9A92-CE4743845BB5[6].png]



Re: CERTICS - Contato


Qui, 20 de Set de 2012 13:07


Para : Marcelo Antônio Osller Malagutti

Prezado Marcelo,

Peço desculpas pela duplicação da resposta à sua mensagem.

Acontece que respondi primeiramente fora do ambiente apropriado (na tentativa de

ser rápida no atendimentos das questões colocadas).

Agora estou respondendo no ambiente correto de forma a registrar a resposta.

Desculpas novamente.

Att.

Angela Maria Alves

Prezado Marcelo,

Vou também responder por partes e no corpo de sua mensagem abaixo.

Agradecemos sua contribuição. Elas são um feedback de enorme valor para nossa

equipe.

Após a Leitura das respostas, se ficar alguma dúvida, não hesite em nos escrever

novamente.

Vamos às respostas.

Att.

Angela Maria A lves

Enviado via iPad

Em 20/09/2012, às 08:18, Marcelo Antônio Osller Malagutti escreveu:

Prezados Senhores,

Meu nome é Marcelo Malagutti, e sou sócio fundador da Fóton Informática, uma das

3 empresas que atualmente possuem registro de software nacional junto ao MCTI,

conforme Portaria Ministerial 58/2002. Nossa empresa desenvolve produtos de

software para o setor de Automação Bancária há 19 anos, sendo também associada e

fundadora do TecSoft, representação do Softex do DF.



Gostaria de registrar nossas contribuições nessa Consulta Pública, dividindo-as

em duas partes.

Primeiramente, o arquivo anexo, contém o texto original com propostas de

alterações na redação. Para facilitar a identificação, realizei uma conversão do

arquivo do formato PDF para o formato do editor Microsoft Word, no qual pude

acionar a opção de registro de alterações. Observe-se que nessa conversão o texto

perdeu sua formatação original. Em segundo lugar, da Leitura do texto facilmente

se depreende a consistência do mesmo quanto ao QUE se pretende e quanto ao COMO.

O QUANDO também fica mais ou menos claro no noticiário especializado. Ocorre que,

para nós da iniciativa privada, ao menos duas outras questões são igualmente

importantes, e não são mencionadas: QUANTO se estima deverá custar esse processo,

e QUANTO TEMPO ele deve levar em média.

>É verdade. O quanto custará ainda não foi divulgado.

>O modelo foi criado tendo em vista duas restrições fundamentais: preço

compatível com o porte e faturamento das empresas e o menor tempo possível.

>Creio que atingimos os dois objetivos.

>A avaliação terá a duração de uma semana com uma visita "on site".

>O preço esta sendo modelado considerando demanda prevista, modelo de negócio,

etc.

>Já sabemos que os preços serão diferenciados para as micro, pequena, média e

grande empresa.

>Acredito que pelo menos a faixa de preço deva ser brevemente anunciada. Concordo

plenamente que esta é uma variável relevante para as >empresas.

No tocante ao Quanto Custará, poder-se-ia tentar inferir algo com base na A

valiação MPS-Br, mas nesse caso temos um diferença fundamental: CERTICS pode se

referir a vários produtos de uma mesma empresa, enquanto que no caso do MPS temos

uma única avaliação para toda a empresa.

>Na verdade o MPS-Br., bem como os demais modelos de capacidade/maturidade

avaliam UNIDA DES ORGANIZACIONAIS e não

toda a empresa como é senso >comum.

>No caso da CERTICS você pode sim avaliar um conjunto de produtos simultaneamente

desde que ele faça parte de uma linha de produto ou tenha a >base de competências

tecnológicas igual a de outros produtos.

Isso é determinante para o custo das certificações, de forma que a otimização das

visitas deveria refletir diretamente no custo do processo. Em nosso caso, aqui na

Fóton, temos ao menos 11 produtos de software que desejamos certificar. Isso

provavelmente inviabilizaria a certificação simultânea de todos numa única visita

ou vistoria, mas certamente o processo poderia ser otimizado com a realização de

2 ou 3 vistorias numa única visita.

>Conforme a resposta anterior poderá ocorrer uma otimização para a avaliação de

produtos similares.

>O precessões de certificação contará com uma fase que estamos chamando de

análise de prontidão. Ela será totalmente automatizada, não terá >custo algum

para a empresa e possibilitará que você perceba a lógica da Metodologia e faça os

arranjos que forem mais adequados para seu caso.

Já no tocante à Duração, não existe nenhuma previsão da duração de cada fase, e

nem do tempo estimado entre cada fase.

>A avaliação deverá ter a duração de uma semana, depois teremos a validação da

avaliação e a certificação que será emitida pelo

MCTI/SEPIN. >Estamos prevendo no máximo um mês para todo o ciclo.

Estamos seguros que essas duas questões serão determinantes para o sucesso dessa

certificação. Principalmente se considerarmos

o tamanho médio das empresas que atuam no mercado nacional, conforme dados

divulgados recentemente pelo SofTex e pela SEPIN. Ressalte-se que a Fóton faz

parte daquela minoria de empresas médias nesse mercado.

>Reforço que estas questões nortearam todo o processo de construção da

Metodologia. A final o objetivo máximo do mecanismo que ela implementa é

fortalecer e cuidar para que o setor de software no Brasil seja fortalecido.

Por fim, gostaríamos de maiores esclarecimentos sobre o sequência dessa Consulta

Pública, no intuito de podermos contribuir naquilo que estiver ao nosso alcance.

>Agradecemos mais uma vez sua contribuição e contamos com outr as de mesma

natureza e mesmo reflexões sobre a aplicação e resultados do processo.

Desde já agradecemos a atenção e nos colocamos ao seu dispor par a eventuais

esclarecimentos.

Cordialmente,

Marcelo A . O. Malagutti





Re: dúvidas para obter certificação certics

De : Ângela

Seg, 17 de Set de 2012 21:07

Assunto : Re: dúvidas para obter certificação certics

Para : Gustavo Barbosa

Cc : Consulta publica <[email protected]>

Prezado Gustavo,

O processo de certificação ainda não foi iniciado.A Metodologia estável Consulta

publica até 28OUT2012.

Att.

Angela Maria A lves

Enviado via iPad

Em 17/09/2012, às 17:56, Gustavo Barbosa escreveu:

Olá, gostaria de inscrever minha empresa no processo de certificação da

CERTICS, mas não consegui fazer, via site. Como poderiamos prosseguir?

Fico no aguardo de um retorno para avançarmos.

Grato,

Gustavo Barbosa



Re: Duvidas


Ter, 25 de Set de 2012 14:35

Assunto : Re: Duvidas

Para : Robson Cardoso da Silva

Prezado Robson,

A participação pode ser feita utilizando este mesmo canal.

Basta colocar suas sugestões, críticas, impressões no formado de email e

encaminha-los.

Att.

Angela


From: "Robson Cardoso da Silva"


Sent: Monday, September 17, 2012 3:09:32 PM

Subject: Duvidas

Gostaríamos de saber mais informações sobre como participar, form ular questões,

etc.

Att

Robson Cardoso da Silva

Diretor Executivo

Via Lógica Consultoria e Sistemas Ltda



De : ALESSANDRO QUATTRINI

Seg, 17 de Set de 2012 10:03



Cara Angela, bom dia,

Com a publicação no Diário Oficial na última sexta-feira, 14/9, da Consulta

Pública sobre o modelo de certificação de SW nacional, entendemos que fica

oficialmente aberta a recepção de sugestões ao tema, por um prazo de 45 dias a

contar de 14/9.

Este nosso entendimento está correto? O prazo deixa de ser 19/9/12 e passa a ser

29/10/12? As contribuições devem ser enviadas a este e-mail

[email protected] ?



Obrigado,






Sent: quarta-feira, 12 de setembro de 2012 12:36

To: ALESSANDRO QUA TTRINI

Cc: Carolina Mattos


Prezado Alessandro,

É isso mesmo. O prazo final será 19SET2012.

Não sabemos ainda se haverá prorrogação. Acho mais sensato trabalhar com a data

de 19SET.

Sim, as Consultas devem ser enviadas para [email protected].

Att.

Angela Maria Alves


De: "ALESSANDRO QUA TTRINI"




Prezados Srs.,

A Ericsson do Brasil está trabalhando para apresentar nossas contribuições à

Metodologia CERTICS para Software ("Metodologia").

Gostaríamos de saber de V. Sas. o prazo final para apresentação de nossos

comentários. Considerando que a Metodologia foi colocada em Consulta Pública em

20/08 com um prazo de 30 dias, o prazo final para as contribuições é 19/9/2012?

As contribuições devem ser enviadas a este e-mail

[email protected] ?

Atenciosamente,






RES: Consulta Pública

De : Felipe Herzog

Sex, 14 de Set de 2012 17:43

Assunto : RES: Consulta Pública


Obrigado!



Enviada em: sexta-feira, 14 de setembro de 2012 17:42

Para: Felipe Herzog

Assunto: Re: Consulta Pública

Prezado Felipe,

Vou reproduzir para você o comunicado da mudança de data de encerramento da

Consulta Pública. Veja abaixo, por favor:

COMUNICADO IMPORTANTE

Alteração de data

Segundo publicação no Diário Oficial da União de 14 de setembro de 2012

informamos que as contribuições e sugestões acerca

da Metodologia CERTICS - CERTICS proposta poderão ser enviadas até o dia 28 de

outubro de 2012, utilizando o canal de

comunicação [email protected].

A data final da Consulta é então 28OUTUBRO2012.

Att.

Angela Maria Alves




From: "Felipe Herzog"


Sent: Friday, September 14, 2012 4:41:54 PM


Prezados,

Com a publicação da portaria abaixo na data de hoje vocês poderiam pf confirmar a

data de encerramento da Consulta Pública.

Grato,

Felipe



RES: CERTICS - Contato

De : Marcos Gomes

Sex, 14 de Set de 2012 13:10

Assunto : RES: CERTICS - Contato

Para : 'Consulta Publica' <[email protected]>

Obrigado Carolina.

Atenciosamente,

Marcos André Gomes



Enviada em: sexta-feira, 14 de setembro de 2012 12:44

Para: Marcos Gomes

Cc: Carolina Mattos

Assunto: Re: CERTICS - Contato

Prezado Marcos,

A data de finalização da Consulta Pública foi alterado. Por favor, veja abaixo.


Alteração de data


informamos que as contribuições e sugestões acerca da Metodologia de A valiação -

CERTICS proposta poderão ser enviadas até o dia 28 de outubro de 2012, utilizando

o canal de comunicação [email protected]

Att.

Angela


From: "Marcos Gomes"


Sent: Thursday, September 13, 2012 5:04:54 PM


Prezados Senhores,

Gostaria de saber a data final da Consulta publica do CERTICS.

Atenciosamente,

Marcos André Gomes




Sex, 14 de Set de 2012 12:41


Para : CLeida


Prezada CLeida,

A data de finalização da Consulta Pública foi alterado. Por favor, veja abaixo.


Alteração de data




informamos que as contribuições e sugestões acerca da Metodologia de A valiação -

CERTICS proposta poderão ser enviadas até o dia 28 de outubro de 2012, utilizando

o canal de comunicação [email protected].

Att.

Angela


From: "CLeida"


Sent: Friday, September 14, 2012 9:03:33 A M


Para a equipe da Certics,

Qual é o prazo máximo de envio de contribuições para a Consulta Pública?

Como o material é muito extenso estamos com dificuldade para concluir

a análise e hamonizar as contribuições finais até o dia 21/09/12 e

gostaríamos de contar com um prazo adicional.

Att,

--

CLeida A. Queiroz Cunha.

Diretoria de Gestão da Inovação

CPqD - Centro de Pesquisa e Desenvolvimento em Telecomunicações




Seg, 10 de Set de 2012 14:31


Para : Rodrigues Matheus-QMR002

Prezado Matheus,

A Consulta Pública foi lançada no dia 21AGO2012 e encontra-se aberta. Para sua

pergunta você utilizou o canal que deverá também ser utilizado para suas

contribuições para a Consulta. As contribuições devem referir-se á Metodologia

propriamente dita.

Att. Angela


From: "Rodrigues Matheus-QMR002"




Bom dia,

Gostaria de informações sobre a Consulta publica respeito sobre a Metodologia de

certificação CERTICS.

Grato,

Matheus A . Rodrigues

Brazil R&D

Motorola Solutions, Inc.



Re: Consulta Publica


Assunto : Re: Consulta Publica

Para : Maria Medrano


Prezada Maria,

A priori a data final da Consulta Pública é 19SET2012. Por favor envie suas

contribuições para o canal [email protected]

Att.

Angela Maria A lves




De: "Maria Medrano"



Assunto: Consulta Publica

Prezados Senhores,

Gostaríamos de saber a data final para a Consulta Pública da Metodologia de

certificação. Estamos muito interessados em apresentar observações e gostariamos

de saber quando o período de comentários públicos termina.

Obrigada,

Maria

Maria Medrano

Director, Global Policy

Information Technology Industry Council (ITI)




Assunto : Consulta Publica

Para : angela alves

De : Rodrigues Matheus-QMR002



Bom dia,

Segue anexado abaixo o documento conforme combinado.



Para : Rodrigues Matheus-QMR002

Prezado Matheus,

A Consulta Pública foi lançada no dia 21AGO2012 e encontra-se aberta. Para sua

pergunta você utilizou o canal que deverá também ser utilizado para suas

contribuições para a Consulta. As contribuições devem referir-se á Metodologia

propriamente dita.

Att. Angela


From: "Rodrigues Matheus-QMR002"




Bom dia,

Gostaria de informações sobre a Consulta publica respeito sobre a Metodologia de

certificação CERTICS.

Grato,

Matheus A . Rodrigues

Brazil R&D

Motorola Solutions, Inc.



De : Consulta Publica <[email protected] >

Assunto : Re: CERTICS

Para : Guilherme

Prezado Guilherme,

As inscrições ainda não estão abertas.

Temos alguns caminhos que ainda devem ser trilhados: terminar a Consulta Pública,

as duas audiências públicas e a publicação da portaria do MCTI que regulamentará

a certificação.

De qualquer forma a data de início da certificação será amplamente divulgada

inclusive pelo www.certics.cti.gov.br

.

Att.



Angela Maria Alves


De: "Guilherme"


Enviadas: Segunda-feira, 10 de Setembro de 2012 11:16:25

Assunto: CERTICS

Olá, bom dia.

Gostaria de saber como faço a inscrição de uma empresa para obtenção da

certificação.

Atenciosamente,

Guilherme Tirado Leite

Estagiário



De : Pedro Antônio de Oliveira Gonçalves

Assunto : RES: RES: Consulta Pública CERTICS


Grato!



Enviada em: quarta-feira, 5 de setembro de 2012 12:15

Para: Pedro Antônio de Oliveira Gonçalves

Assunto: Re: RES: Consulta Pública CERTICS

Prezado Pedro,

A Consulta deverá fechar em 19SET2012 (30 dias contados a partir do dia 21A

GO2012)

Att.

Angela


From: "Pedro Antônio de Oliveira Gonçalves"


Sent: Wednesday, September 5, 2012 12:04:53 PM

Subject: RES: Consulta Pública CERTICS

Olá! Muito obrigado pela resposta!

E qual é a data final para envio de sugestões?



Enviada em: quarta-feira, 5 de setembro de 2012 12:01

Para: Pedro Antônio de Oliveira Gonçalves

Assunto: Re: Consulta Pública CERTICS

Prezado Pedro,

A Consulta Pública foi lançada no dia 21AGO2012 e encontra-se aberta.

Para sua pergunta você utilizou o canal que deverá também ser utilizado para suas

contribuições para a Consulta.

Att. Angela


From: "Pedro Antônio de Oliveira Gonçalves"


Cc: "Pedro Antônio de Oliveira Gonçalves"

Sent: Wednesday, September 5, 2012 11:13:27 AM

Subject: Consulta Pública CERTICS

Prezados amigos,

Gostaria de lhes Consultar se há alguma data provável para o lançamento da

Consulta Públicas acerca do CERTICS.

Ficamos no aguardo.

Cordialmente,



Pedro




Assunto : Re: Sobre a avaliação CERTICS para Software

Para : Renato Lundberg

Prezado Renato,

A certificação CERTICS tem por objetivo avaliar em que medida um software é

resultado de desenvolvimento tecnológico e inovação realizados no País. Esta

avaliação baseia-se na identificação de competências geradas a partir deste

desenvolvimento.

A priori, uma solução que é composta por varios softwares pode ser certificada

CERTICS se as tecnologias mais relevantes desta solução tiverem sido

desenvolvidas no Brasil. Ou seja, os software que representam o diferencial da

solução, que agregam m ais inteligência, mais densidade tecnológica à solução

tiver sido desenvolvida no Brasil, gerando competências aqui. Por exemplo,

soluções geralmente agregam bancos de dados, interfaces, etc, que são importadas,

porém o escopo da solução resulta do desenvolvimento de um sistema que é inédito

e que é o que mais agrega conhecimentos, incluindo regras de negócios, à solução.

Uma solução que é somente uma integração de ferramentas diversas, sem

desenvolvimento local não será certificada CERTICS. O mesmo raciocinio vale para

um solução com componentes. Os componentes mais relevantes precisam ter sido

desenvolvidos aqui.

Att.

Giancarlo Stefanuto


From: "Renato Lundberg"


Sent: Friday, August 31, 2012 7:14:10 PM

Subject: Sobre a avaliação CERTICS para Software

Boa noite

Meu nome é Renato Lundberg, da MA PS Soluções e Serviços, e tem os grande

interesse na avaliação CERTICS para software nacional, e algumas dúvidas quanto a

alguns pontos.

Atualmente oferecemos soluções completas, compostas por alguns softwares que

operam de forma integrada para atingir uma finalidade. No caso da solução ser

composta por múltiplos softwares, a certificação se aplica à solução completa, ou

apenas a cada software de forma isolada?

Nossas soluções também possuem como característica uma intensa componentização e

reutilização de código, e a própria plataforma de desenvolvimento e seus

componentes são em si um produto. A avaliação se aplica a plataformas de

desenvolvimento (frameworks), assim como a soluções finais?

Atenciosamente

--

Renato Urquiza Lundberg

MAPS Soluções e Serviços




Assunto : Re: Imformações do Programa do CERTICS

Para : Anderson Oliveira - Conecte Soluções

Prezado Anderson,

As resposas as suas primeira pergunta pode ser obtida após uma Leitura atenta das

informações constantes do site e também da Metodologia lá disponibilizada.

Quanto a segunda questão, sobre a obrigatoriedade, a resposta é NÃ O, a

certificação não é obrigatória.

Att.

Angela


From: "Anderson Oliveira - Conecte Soluções"




Sent: Friday, A ugust 31, 2012 9:42:10 A M

Subject: Imformações do Programa do CERTICS

Bom Dia,

Ao ler o material do CERTICS não tivemos um esclarecimento sobre o programa

implantado do governo, queria um pouco mais de informação sobre o mesmo que será

implantado em nossa empresa, através dessa queria saber para que servira esse

programa e no que ira nós favorecer após a implantação do mesmo.

Pois o material não foi muito claro nos objetivos estou na duvida ainda se

implantarei ou não, pois queria saber se é obrigatório ou não. Pois aguardo mais

esclarecimento do mesmo.

http://www.comvixcom.com.br/ass-anderson.jpg




Assunto : Re: Sobre Ceritificação

Para : Cleber Nardelli (IPM)

Prezado Cleber,

Na verdade NÃO é a reposta para a sua pergunta. Veja bem, o propósito dos modelos

que citados e a CERTICS são diferentes. Nos primeiros você está tratando de SPI

(melhoria de processo). No caso da CERTICS não é este o caso. Seus processos não

serão avaliados com vistas a melhoria mas sim sob o ponto de vista de

desenvolvimento tecnológico nacional. Você estava lendo a documentação da

Metodologia. Então, caso ainda tenha perguntas nos mande. Vamos respondendo até

que você se sinta confortável.

Att. Angela


From: "Cleber Nardelli (IPM)"


Sent: Tuesday, A ugust 28, 2012 5:23:17 PM

Subject: Re: Sobre Ceritificação

Prezado Clenio.

Primeiramente obrigado pela resposta. Em sua visão (até como conhecedor dos dois

modelos), a adaptação que teríamos que fazer, já que fomos avaliados MPS.Br, para

cumprir as necessidades desse modelo seriam muitas, levando-se em consideração

que nosso ERP é construído sob um mesmo processo de software?

Att.

Em 28 de agosto de 2012 14:36, Consulta Publica

<[email protected] > escreveu:

Prezado Cleber Nardelli

A principal diferença entre MPS.BR Nível G (na verdade qualquer nível do MPS.BR )

e o CERTICS é que eles medem aspectos diferentes: a) O MPS.BR mede a maturidade

do processo de uma organização e o resultado da avaliação é referente a uma

Unidade Organizacional b) o CERTCS mede se um determinado software de uma

organização é resultante de desenvolvimento tecnológico e inovação realizadas no

País e o resultado é referente a um determinado software.

No seu caso, para o Nível G do MPS.BR voces devem ter evidênciado que os

processos de desenvolvimento de software da organização (talvez aqueles processam

que desenvolveram e evoluiram o ERP) realizam a Gerencia de Projeto e a Gerencia

de Requisitos. Cada um destes processos no MPS.BR é caracterizado por um conjunto

de Resultados Esperados. No caso do CERTICS, caso voces queiram submeter o ERP

para avaliação e certificação. voces terão de evidênciar que o ERP "é resultante

de desenvolvimento tecnológico e inovação realizadas no País e o resultado é

referente a um determinado software". Neste caso teria de evidênciar 24

Resultados Esperados que estão descritos no modelo. Uma semelhança é que ambos

foram estruturados segundo os Requisitos para Modelos e Métodos de Avaliação

definidos na Norma ISO/IEC 15504 (SPICE).

Atenciosamente

Clenio F. Salviano (pela Equipe CERTICS)




De: "Cleber Nardelli (IPM)"

Para: "Consulta publica" < [email protected] >

Enviadas: Segunda-feira, 27 de Agosto de 2012 14:12:59

Assunto: Sobre Ceritificação

Olá, meu nome é Cleber Nardelli e trabalho na empresa IPM Informática Ltda.

Nós somos uma empresa que produz software ERP para gestão pública municipal e

gostaríamos de participar no que for possível deste processo.

Para começar, gostaria de fazer um questionamento: Para uma em presa que possui

avaliação MPS.Br nível G, quais seriam as diferenças centrais para avaliação

CERTCS?

Estou em fase de Leitura do documento "Metodologia CERTICS", assim que puder

envio comentários.

Att.

--

Cleber Nardelli

IPM Fábrica - Gerente de Pesquisa e Desenvolvimento




Assunto : Re: Metodologia de certificação de software e seus serviços associados

- CERTICS

Para : Marcelo Marques

Prezado Marcelo,

O guia de uso para software Livre e Código Aberto está em construção.

Não esta pronta para ser colocada em Consulta Pública.

Veja que no texto que você citou temos ... será tratada ....

Certamente, assim que estiver pronta ela será amplamente divulgada.

Att.

Angela


From: "Marcelo Marques"

To: "Consulta publica" <[email protected]>,

[email protected]

Cc: "Rodolfo Gobbi"

Sent: Tuesday, A ugust 28, 2012 5:06:46 PM

Subject: Metodologia de certificação de software e seus serviços associados -

CERTICS

Olá, boa tarde,

Eu e meu sócio lemos a Consulta Pública. Para podermos contribuir, precisamos do

acesso à Metodologia para Software Livre e Código Aberto (nosso negócio é todo

baseado nesse segmento), pois conforme indica na página 7 do documento, existe um

"guia de uso" conforme abaixo:

" A Metodologia desenvolvida também partiu da premissa de ser aplicável para

qualquer tipo de licença de software. A aplicação da Metodologia CERTICS em

software livre e de código aberto será tratada em uma guia de uso, que considera

suas especificidades para esta aplicação. "

É possível termos acesso à este "Guia de Uso"?

aguardo,

--

obrigado,

Marcelo Marques

Diretor de Vendas



De : Felipe Herzog



Prezados,

Vocês poderiam por favor confirmar se já foi aberta Consulta Pública e a data de

encerramento?





De : Felipe Herzog



Prezados,

Gostaria de participar da Consulta Pública e gostaria de saber o que será

necessário para tanto.



Para : Felipe Herzog

Prezado Felipe,

Basta enviar sua contribuição para este mesmo endereço de email.

A contribuição será automaticamente registrada e encaminhada.

Att,

Angela





Para : luiz wolf

Prezado Luiz,

Os atributos pontuados durante a avaliação que levará a certificação estão

descritos na A BA CONCEPÇÃO do

www.certics.cti.gov.br

Att.

Angela


From: "luiz wolf"


Sent: Monday, A ugust 27, 2012 11:44:46 AM


Bom dia,

Atuamos no desenvolvimento de ferramentas de software para o setor de

governo e varejo. Temos mais de 150.000 horas de desenvolvimento próprio

em Java, c++ e outras linguagens. Frequentemente utilizamos códigos

livres em nossas soluções, a fim de agilizar nosso processo.

Gostaria de saber se a certificação considera ou pontua a favor ou

contra este tipo de prática.

Atenciosamente,

--

Luiz Wolf

REGLARE

Business Centric Rules




Assunto : Re: Processo de Credencianciamento

Para : Izoulet Lima Moreira Cortes Filho

Prezado Izoulet Lima Moreira Cortes Filho

Obrigado pelo interesse e pelas perguntas.

Estamos trabalhando justamente na definição e detalhamento da Rede de A valiação

para o CERTICS. Suas perguntas são bem pertinentes. Já estamos considerando

praticamente todas elas neste trabalho. As perguntas serão respondidas como



resultados desta definição e detalhamento. A divulgação desta definição e

detalhamento será feita após o resultado da Consulta Pública do CERTICS.

Atenciosamente

Clenio F. Salviano (Pela Equipe CERTICS)


De: "Izoulet Lima Moreira Cortes Filho"

Para: [email protected], "Consulta publica"

<[email protected]>

Enviadas: Terça-feira, 28 de Agosto de 2012 11:23:00

Assunto: Processo de Credencianciamento

Bom dia!

Solicitamos informações relacionadas ao processo de Credenciamento / Acreditação

de entidades para atuar na CERTICS, independentem ente se ainda em processo de

Consulta ou em processos já definidos, à saber:

1) Qual o perfil institucional exigido: ICTs, empresas e/ou entidades da esfera

pública e/ou privada?

2) Quais as exigências ao processo de credenciamento para A valiação das CERTICS?

3) Quando o processo de credenciamento será efetivamente aberto?

4) Quando as empresas interessadas poderão iniciar a solicitação de CERTICS?

5) Existe algum critério de divisão regional para as Credenciadas C TI ao

processo de avaliação, como:

a. A divisão territorial será por região (Sul, Sudeste, Centro-Oeste, Norte,

Nordeste), por Unidade da Federação, por Município, Micro-Região, Região

Metropolitana ou qual outro critério?

b. A lguma limitação ao número de credenciados por Estado?

c. Como se dará o processo de relacionamento com os credenciados? Existirá figura

de algum responsável por região entre o CTI e os Credenciados?

6) Como será feita a apresentação e capacitação na Metodologia CERTICS, após o

processo de credenciamento

7) Como será feito o processo de avaliação: exclusivamente pelos credenciados, ou

também pelo CTI?

8) Os credenciados deverão ter corpo próprio para avaliação ou poderão contratar

também serviços de terceiros?

a. No caso de possibilidade de contratação de serviços de terceiros, existe um

limite percentual de contratação? Qual?

9) Qual o perfil profissional exigido dos recursos humanos alocados no processo

de avaliação no credenciamento.

10) A rede de credenciados atuará exclusivamente no processo de avaliação ou

também poderá atuar em outras etapas/processos da CER TICS?

11) Processo de avaliação:

a. Já existem todos os requisitos definidos para a avaliação?

b. Quais serão os requisitos a serem avaliados?

c. Qual o perfil da avaliação: auditoria ou outro? Qual?

d. Quantas horas serão necessárias ao processo de avaliação?

e. As avaliação serão feitas em conjunto?

12) Sistema de remuneração:

a. Como será definido o sistema de remuneração?

b. Já existem valores definidos para a remuneração de consultoria contratada

pelos processos de avaliação?

Permaneço à disposição e aguardo seus retornos.

Atenciosamente

cid:[email protected]

Izoulet Lima M. Cortes Filho

Gerente de Projetos | Project Manager




Assunto : Re: Consulta Publica

Para : Silvio Viegas

Prezado Sivio Cesar Viegas

As orientações para participar da Consulta Pública estão no site do CERTICS


Em resumo: Contribuições, dúvidas e informações durante a Consulta Pública, envie

um email para [email protected]

Atenciosamente



Clenio F. Salviano (Equipe CERTICS)


De: "Silvio Viegas"


Enviadas: Domingo, 26 de A gosto de 2012 9:15:09

Assunto: Consulta Publica

Bom dia

Gostaria de participar da Consulta Pública

Msc Silvio Cesar Viegas





Para : Marcelo Antônio Osller Malagutti

Prezado Sr. Marcelo,

Obrigada pelo interesse e disposição para contribuir.

A Metodologia encontra-se em Consulta publica.

Este mecanismo permite que toda a sociedade possa participar e contribuir.

Todas as suas contribuições devem ser enviadas para o endereço:

[email protected]

As contribuições serão tratadas e devidamente registradas.

Atenciosamente

Angela Maria A lves


De: "Marcelo A ntônio Osller Malagutti"


Enviadas: Quarta-feira, 22 de A gosto de 2012 16:41:09


Prezados Senhores,

Meu Nome é Marcelo Malagutti e sou Diretor de Produtos e Servi ços da Fóton

Informática em Brasília.

A Fóton é uma tradicional desenvolvedora, 100% brasiLeira, de produtos para

automação de canais de atendimento bancários, e é uma das poucas empresas

agraciadas com o reconhecimento do MCT de produto de software desenvolvido no

Brasil desde 2002.

Ainda ontem baixei o pdf do CERTICS, e tenho diversas sugestões que gostaria de

encaminhar. Num primeiro momento, a maior parte das sugestões diz respeito mais à

redação do documento que ao seu teor técnico.

Gostaria de saber qual a forma de encaminhar tais sugestões, um a vez que o

formato pdf não permite o controle de alterações do texto. Caso os senhores

tenham interesse, sendo possível o envio de uma versão ODT ou DOC do documento,

eu teria prazer em registrar as alterações e submetê-las aos senhores para

apreciação.

Fico no aguardo de seu manifestação.

Cordialmente,

Marcelo A . O. Malagutti

Fóton Informática S.A .

Diretor de Produtos e Serviços – DPS

MPS.BR Nível C

ISO 9001:2008



ANEXO FÓTON

CTI RENATO ARCHER

Metodologia de

Avaliação CERTICS para

Software

20/8/2012

Este documento foi elaborado no âmbito do projeto CTENIC e desenvolvido na Divisão de

Melhoria de Processo de Software – DMPS, do Centro de Tecnologia da Informação Renato

Archer – CTI (www.cti.gov.br), Rodovia Dom Pedro I, km 143,6, Campinas – SP – Brasil.



Resumo Executivo

A Metodologia CERTICS será utilizada inicialmente apenas para software. É composta por

um Modelo de Referência e um Método de Avaliação. CERTICS é uma certificação que

identifica, credencia e diferencia software, gerando valor local e competitividade global

para o País. O termo Software, no âmbito da metodologia, significa Software e seus Serviços

Associados. O Modelo de Referência para Avaliação CERTICS está estruturado em quatro

camadas hierárquicas, com uma estrutura lógica orientada por objetivos e uma engenharia de

processamento de informações baseada em evidências que orientam uma avaliação.

A primeira camada define Software resultante do desenvolvimento tecnológico e inovação

realizados no País como aquele cujo desenvolvimento cria ou amplia competências

tecnológicas e correlatas no País, contribuindo para a criação de negócios baseados em

conhecimento e aumento de autonomia tecnológica. Competências tecnológicas são

conhecimentos e habilidades de uma organização para criar ou modificar uma tecnologia em

seus princípios ou funcionalidades. As Competências correlatas são complementares às

tecnológicas que, simultaneamente, as potencializam e são por elas potencializadas, e que são

necessárias para a consecução de negócios baseados em conhecimento.

A segunda camada é composta por cinco Áreas de Competência que detalham a primeira

camada: Desenvolvimento; Gestão de Tecnologia; Gestão de Negócios; Gestão de Parcerias e

Alianças; e Gestão de Pessoas, Processos e Conhecimento. Cada Área de Competência envolve,

com ênfases diferentes, tanto aspectos de competências tecnológicas quanto de competências

correlatas. Cada Área de Competência é caracterizada por uma pergunta-chave:

Desenvolvimento - “O software é resultante de desenvolvimento tecnológico no País?”;

Gestão de Tecnologia - “O software é mantido tecnologicamente autônomo e competitivo?”;

Gestão de Negócios - “O software potencializa negócios baseados em conhecimento e é

direcionado por esses negócios?”; Gestão de Parcerias e Alianças - “Parcerias e alianças

possibilitam geração de negócios, atualização tecnológica ou desenvolvimento tecnológico,

relacionados ao software?”; e Gestão de Pessoas, Processos e Conhecimento - “Pessoas,

processos e conhecimento são gerenciados para apoiar e potencializar negócios e o

desenvolvimento tecnológico do software?”.

A terceira camada é composta por cinco conjuntos de Resultados Esperados. Cada um destes

conjuntos detalha uma das cinco Áreas de Competência. A quarta camada é composta por

conjuntos de Orientações e Indicadores, e cada um deles detalha um Resultado Esperado.

O processo de avaliação segue o Método de Avaliação CERTICS composto por cinco fases

sequenciais, que são as fases de exploração, preparação, visita, validação e conclusão da

avaliação. Para garantir que os resultados da avaliação sejam objetivos, imparciais,

consistentes, repetíveis e representativos a Metodologia CERTICS segue os requisitos

estabelecidos na Norma ISO/IEC 15504. O resultado positivo de uma avaliação é utilizado para

comprovar junto ao MCTI o efetivo desenvolvimento local em atendimento ao decreto



7174/2010 resultando na emissão pela SEPIN do Certificado CERTICS.



1. Introdução

CERTICS é uma certificação que identifica, credencia e diferencia software, gerando valor local

e competitividade global para o País.

Este documento descreve uma versão preliminar da Metodologia CERTICS para Software

composta por dois componentes principais: o Modelo de Referência para Avaliação CERTICS e

o Método de Avaliação CERTICS. Neste documento o termo Software significa Software e

seus Serviços Associados.

A Secretaria de Política de Informática (SEPIN) do Ministério da Ciência, da Tecnologia e

Inovação (MCTI) em parceria com o Centro de Tecnologia da Informação Renato Archer (CTI

Renato Archer) implementaram o projeto de Certificação de Tecnologia Nacional de

Tecnologia da Informação e Comunicação (CTENIC) para construir uma Metodologia

CERTICS de Software Resultante de Desenvolvimento Tecnológico e Inovação Realizados no País. A

presente metodologia é resultado deste Projeto.

A metodologia foi preparada para servir à comprovação, frente ao MCTI, de que trata o art.

6° do Decreto 7174/ 2010 quanto à tecnologia desenvolvida no País, pelo estabelecimento

dos requisitos e critérios para verificação de softwares como resultantes de

desenvolvimento e inovação tecnológica realizada no País.

2. Termos e definições

Esta seção apresenta alguns termos e definições utilizados no escopo deste documento.

Arquitetura do software – representa uma visão macro do software em termos das ideias e

conceitos básicos relacionados às regras de negócio, aos aspectos tecnológicos e à interação

existente entre os componentes do software. Os aspectos tecnológicos considerados na

metodologia são as tecnologias relevantes e estratégicas para o software e seus serviços

associados. Geralmente a arquitetura do software é documentada por meio de um projeto de

arquitetura.

Atividade definida – atividade que está minimamente documentada e é praticada na Unidade

Organizacional.

Autonomia tecnológica – capacidade de uso da base tecnológica para tomada de decisões de

forma independente e para controlar conjuntamente processos que se produzem dentro e

além das fronteiras nacionais.

Bibliometria – estudos que tentam quantificar os processos de comunicação escrita.

Desenvolvimento – área de competência que aborda as atividades de geração de um novo

software e seus serviços associados bem como suas evoluções e manutenções.



Gestão – refere-se à execução de ações de acompanhamento dos conceitos que as áreas de

competência Gestão de Tecnologia, Gestão de Negócios, Gestão de Parcerias e Alianças, e

Gestão de Pessoas, Processos e Conhecimento tratam e os desdobramentos do resultado

desse monitoramento na organização.

Gatekeeper – é um papel de facilitador que atua como ponto focal na interação da Unidade

Organizacional com outras instituições envolvidas no desenvolvimento do software e seus

serviços associados.

Negócios baseados em conhecimento – desenvolvimento de negócios onde o conhecimento

não é apenas o fator-chave de produção, mas também o bem comercializado. São negócios

fortemente baseados em conhecimento especializado que envolvem recursos humanos

altamente qualificados e aprendizado por meio de networking, e que requerem forte

interação fornecedor-cliente.

Processo definido – processo que está minimamente documentado e é praticado na Unidade

Organizacional.

Roadmap – é uma ferramenta utilizada para alinhar no tempo, perspectivas externas

(ambiente, mercado, regulação) com internas (produtos, tecnologias, capacitações) e

identificar gargalos ou oportunidades para produtos e serviços por meio da construção de uma

visão de longo prazo. Identificam possíveis caminhos a serem perseguidos pelos projetos de

pesquisa, desenvolvimento e inovação e apoiam o planejamento de estratégias para que

capacitações tecnológicas aproveitem oportunidades de mercado e para que gaps nos

produtos e nos mercados sejam previstos e superados. Também podem ser utilizados para

avaliar impactos de uma descontinuação de mercado para os produtos e serviços.

Tecnologias relevantes e estratégicas para o software e seus serviços associados – são

tecnologias presentes no software e que cumprem os seguintes critérios:

a) A tecnologia licenciada (adquirida) é parte significativa do valor de mercado do

software.

b) A tecnologia promove um diferencial tecnológico ou de negócios para o software

frente aos concorrentes.

c) A tecnologia está no escopo das tecnologias estratégicas definidas pelo MCTI.

TIC – Tecnologia da Informação e Comunicação.

Unidade Organizacional – é o conjunto de processos para todos os aspectos do software e

seus serviços associados.



3. Visão Geral, Estrutura e Regras de Pontuação da

Metodologia

Esta seção apresenta uma visão geral da Metodologia CERTICS para Software a partir do

Modelo de Referência CERTICS e do Método de Avaliação CERTICS, incluindo sua estrutura e

regras de pontuação.

A estrutura do Modelo e do Método de avaliação segue os requisitos para modelos e métodos

estabelecidos pela Norma ABNT ISO/IEC 15504-2 (2008) - Tecnologia da informação - Avaliação

de processo - Parte 2: Realização de uma avaliação. Esta Norma é uma tradução da Norma

Internacional ISO/IEC 15504-2 - Information technology - Process assessment Part 2:

Performing an assessment, publicada em 2003. A Norma trata da avaliação de processo e de

sua aplicação para a melhoria e determinação da capacidade. Ela define o conjunto mínimo de

requisitos para a realização de uma avaliação. Estes requisitos irão garantir que os resultados

da avaliação sejam objetivos, imparciais, consistentes, repetíveis e representativos com

relação aos processos avaliados.

A Metodologia CERTICS e o seu desenvolvimento seguem os seguintes princípios:

• Software e seus serviços associados devem ser entendidos como um sistema de

software e seus serviços associados incluindo famílias e plataformas de software e

serviços.

• A Avaliação é do software, não da empresa, e é baseada na análise dos processos

empregados no software da Unidade Organizacional produtora ou mantenedora do

software.

• A Metodologia CERTICS é baseada na Norma ABNT ISO/IEC 15504 (SPICE) e na

experiência do CTI e de seus parceiros.

• Um conceito novo (“Software Resultante de Desenvolvimento Tecnológico e Inovação Realizados no País”)

demandou um novo modelo e um novo método para avaliação.

• A Metodologia proposta está alinhada e é complementar a outras metodologias e

modelos de processo para Empresas, Engenharia de Software e Sistemas, e

Serviços, entre outros.

• Seu monitoramento indicará gradualmente mais indicadores para aprimorar sua

avaliação.

• A metodologia proposta possibilitará uma parametrização por vários fatores:

utilização, tamanho, setor, etc.

A metodologia desenvolvida também partiu da premissa de ser aplicável a qualquer tipo de

licença de software. A aplicação da Metodologia CERTICS em software livre e de código

aberto será tratada em uma guia de uso, que considera suas especificidades para esta

aplicação.



Segundo a ISO/IEC 15504-1, uma Unidade Organizacional é a parte de uma organização na

qual os processos serão avaliados ou melhorados. A Unidade Organizacional realiza um ou

mais processos que têm um contexto coerente de processo e operam sob um conjunto

coerente de objetivos estratégicos. É tipicamente uma parte de uma organização maior,

embora em uma pequena organização a Unidade Organizacional possa ser toda a organização.

Para esta Metodologia CERTICS, a Unidade Organizacional é o conjunto de processos para

todos os aspectos do software e seus serviços associados.

O Modelo de Referência para Avaliação CERTICS está estruturado em quatro camadas

hierárquicas.

A primeira camada define o conceito de Software resultante do desenvolvimento tecnológico

e inovação realizados no País como aquele cujo desenvolvimento cria ou amplia competências

tecnológicas e correlatas no País, contribuindo para a criação de negócios baseados em

conhecimento e aumento de autonomia tecnológica. Competências tecnológicas são

conjuntos de conhecimentos e habilidades de uma organização para criar ou modificar uma

tecnologia em seus princípios ou funcionalidades. Competências correlatas são conjuntos de

conhecimentos e habilidades, complementares às competências tecnológicas que,

simultaneamente, as potencializam ou são por elas potencializadas, e que são necessárias para

a consecução de negócios baseados em conhecimento. Negócios baseados em conhecimento

são negócios onde o conhecimento não é apenas o fator-chave de produção, mas também o

principal aspecto do bem comercializado. Referem-se a negócios fortemente baseados em

conhecimento especializado, que envolvem recursos humanos altamente qualificados, e

aprendizado por meio de networking, e que requerem forte interação fornecedor-cliente.

O aumento da autonomia tecnológica no País constitui-se de contribuições para a

ampliação da base tecnológica nacional e para a capacidade de uso desta base para

tomada de decisões de forma independente e para controlar conjuntamente processos que

se produzem dentro e além das fronteiras nacionais.

A segunda camada é composta por cinco Áreas de Competência que detalham o conceito de

Software resultante do desenvolvimento tecnológico e inovação realizados no País,

apresentadas na Figura 1: Desenvolvimento (DES); Gestão de Tecnologia (TEC); Gestão de

Negócios (GNE); Gestão de Parcerias e Alianças (GPA), Gestão de Pessoas, Processos e

Conhecimento (PPC). Cada Área de Competência envolve, com ênfases diferentes, tanto

aspectos de competências tecnológicas quanto de competências correlatas.



Figura 1 – Áreas de Competências

Cada uma das cinco Áreas de Competência é caracterizada por uma pergunta-chave e está

descrita brevemente a seguir.

Área de Competência Desenvolvimento:

Pergunta-chave: O software é resultante de desenvolvimento tecnológico no País?

Descrição: refere-se ao domínio do conjunto de tecnologias utilizado para o

desenvolvimento de determinado software. Esse domínio de conhecimento deve estar

focado na arquitetura do software, na plataforma utilizada para sua construção e na

plataforma de execução.

Área de Competência Gestão de Tecnologia:

Pergunta-chave: O software é mantido tecnologicamente autônomo e competitivo?

Descrição: envolve o estabelecimento de ações direcionadoras para o

desenvolvimento de tecnologias, absorção de tecnologias (ex.: engenharia reversa)

e/ou aquisição de tecnologias, a serem adotadas no desenvolvimento do software,

levando em consideração a autonomia tecnológica como um dos fatores relevantes;

Área de Competência Gestão de Negócios:

Pergunta-chave: O software potencializa negócios baseados em conhecimento e é

direcionado por esses negócios?

Descrição: refere-se à administração de ações voltadas para a promoção e o aumento

de negócios baseados em conhecimento a partir do software. Compreende desde

esforços relacionados ao monitoramento de tendências de mercado, até iniciativas

voltadas para manutenção e ampliação da carteira de clientes, via pesquisas de

satisfação e avaliação da qualidade do atendimento, além de esforços direcionados à

prospecção de novas soluções para clientes em potencial;


206

Área de Competência Gestão de Parcerias e Alianças:

Pergunta-chave: Parcerias e alianças possibilitam geração de negócios, atualização

tecnológica ou desenvolvimento tecnológico, relacionados ao software?

Descrição: envolve a formação, operação e avaliação de projetos e acordos de

cooperação, tecnológica ou comercial, entre a organização e fornecedores,

financiadores, instituições de ciência e tecnologia, universidades e outras organizações

privadas e públicas, que tenham como foco desenvolvimentos tecnológicos e

promoção de negócios relacionados ao software;

Área de Competência Gestão de Pessoas, Processos e Conhecimento:

Pergunta-chave: Pessoas, processos e conhecimento são gerenciados para apoiar e

potencializar negócios e o desenvolvimento tecnológico do software?

Descrição: abrange um conjunto de atividades, coerentes entre si, que apoiam e

potencializam de forma integrada as outras áreas de competência do modelo. A

Gestão de Pessoas está voltada para a administração, capacitação e motivação de

recursos humanos que atuam em processos relacionados ao software. A Gestão de

Processos inclui a avaliação e melhoria contínua desses processos. A Gestão de

Conhecimento está voltada para a identificação, documentação, disseminação e

atualização de conhecimento relevante sobre as tecnologias, os negócios, e outros

aspectos relacionados ao software.

A terceira camada é composta por cinco conjuntos de Resultados Esperados. Cada conjunto

detalha uma das cinco Áreas de Competência. Um Resultado Esperado, conforme definido na

Norma NBR ISO/IEC 15504-2, descreve um dos seguintes itens:

- A produção de um artefato;

- Uma mudança significativa de estado;

- O atendimento das especificações, como por exemplo, requisitos, metas, etc.

A quarta camada é composta por conjuntos de Orientações e Indicadores. Cada um destes

conjuntos detalha um Resultado Esperado. Cada conjunto de Orientações e Indicadores de

cada resultado esperado orienta a avaliação deste resultado esperado a partir de evidências. O

resultado desta avaliação é expresso como uma pontuação em uma escala de quatro valores,

conforme definido na Norma ABNT ISO/IEC 15504-2 (2008) que traduz a Norma Internacional

ISO/IEC 15504-2 (2003).

O Quadro a seguir reproduz a escala de pontuação de atributos de processo prevista na

norma, com a alteração de “atributo definido no processo avaliado” para “Resultado Esperado

pelo software em avaliação”. O software é avaliado a partir das evidências geradas pelos

processos do entorno do software.


207

A escala de pontuação ordinal definida a seguir deve ser utilizada para expressar o alcance do

Resultado Esperado pelo software em uma avaliação:

N Não atendido: Existe pouca ou nenhuma evidência do alcance do Resultado Esperado pelo

software em avaliação.

P Parcialmente atendido: Existe alguma evidência de aproximação e algum alcance do

Resultado Esperado pelo software em avaliação. Alguns aspectos de alcance são imprevisíveis.

L Largamente atendido: Existe evidência de aproximação sistemática e de alcance

significativo do Resultado Esperado pelo software em avaliação. Existem alguns pontos fracos

relacionados a este Resultado Esperado pelo software em avaliação, porém estes não são

críticos para a obtenção do Resultado Esperado.

F Completamente (Fully) atendido: Existe evidência de uma aproximação completa e

sistemática e de alcance total do Resultado Esperado pelo software em avaliação. Não existem

pontos fracos significativos relacionados com este Resultado Esperado pelo software em

avaliação.

Os pontos ordinais definidos nesta escala devem ser entendidos em termos de uma escala

percentual que representa a extensão do alcance. Os valores correspondentes devem ser:

N Não atendido 0 a 15% de alcance

P

Parcialmente atendido

> 15% a 50% de alcance

L

Largamente atendido


F

Completamente atendido


Em todos os casos deve ser indicado o racional utilizado na atribuição da pontuação N, P, L ou

F.

Quando a pontuação atribuída for diferente de F, além do conteúdo do racional utilizado

deve ser indicado pelo menos um ponto fraco encontrado.

Cada área de competência é pontuada em uma escala binária (Sim ou Não) com base no

resultado das avaliações de cada um de seus resultados esperados. A pontuação será Sim se

cada resultado esperado estiver pontuado como F ou L. A pontuação será Não caso contrário.

Software Resultante de Desenvolvimento Tecnológico e Inovação Realizados no País é também pontuado em uma

escala binária (Sim ou Não) com base no resultado das avaliações de cada


208

uma das áreas de competência. A pontuação será Sim se cada área de competência estiver

pontuada como Sim. A pontuação será Não caso contrário.

Esta pontuação é construída durante a realização de uma avaliação que segue o Método de

Avaliação CERTICS. O método é composto por cinco fases seqüenciais, que são as fases de

exploração, preparação, visita, validação e conclusão da avaliação. Para garantir que os

resultados da avaliação sejam objetivos, imparciais, consistentes, repetíveis e representativos

com relação ao software avaliado, a Metodologia CERTICS segue os requisitos

estabelecidos na Norma ABNT ISO/IEC 15504-2 (2008).

A Figura 2 ilustra a estrutura em quatro camadas do modelo, a estrutura lógica orientada pelo

objetivo que direcionou o desenvolvimento do modelo e a engenharia de processamento de

informações baseada em evidências, que norteia a realização de uma avaliação.

Figura 2 – Estrutura lógica do Modelo e Engenharia de processamento de informações do Método


209

4. Modelo de Referência para Avaliação CERTICS

Esta seção apresenta o Modelo de Referência para Avaliação CERTICS. Este modelo é

composto por cinco Áreas de Competência:

• Desenvolvimento

• Gestão de Tecnologia

• Gestão de Negócios

• Gestão de Parcerias e Alianças

• Gestão de Pessoas, Processos e Conhecimento

Cada área de competência é descrita em termos de uma pergunta-chave, descrição e um

conjunto de resultados esperados. Para cada resultado esperado, o modelo apresenta uma

descrição, orientações e uma lista de exemplos de tipos de evidências. Esta lista não deve ser

considerada uma lista fechada, mas uma orientação para facilitar o entendimento de cada

resultado esperado.

4.1 Software Resultante de Desenvolvimento Tecnológico e Inovação

Realizados no País

Definição

Um determinado Software Resultante de Desenvolvimento Tecnológico e Inovação Realizados no País é aquele

cujo desenvolvimento cria ou amplia competências tecnológicas e correlatas no País,

contribuindo para a criação de negócios baseados em conhecimento e aumento de

autonomia tecnológica.

Descrição

O conceito de Software Resultante de Desenvolvimento Tecnológico e Inovação Realizados no País utiliza os

conceitos de competências tecnológicas e correlatas. Competências tecnológicas são conjuntos

de conhecimentos e habilidades de uma organização para criar ou modificar uma

tecnologia em seus princípios ou funcionalidades. Competências correlatas são conjuntos de

conhecimentos e habilidades complementares às competências tecnológicas que,

simultaneamente, as potencializam ou são por elas potencializadas e que são necessárias para

a consecução de negócios baseados em conhecimento.

Este conceito é operacionalizado por um conjunto de cinco Áreas de Competência. Desta

forma para um determinado Software ser considerado como resultante de desenvolvimento

tecnológico e inovação realizados no País, ele tem que satisfazer as cinco áreas de

competência. As cinco áreas de competência são: Desenvolvimento (DES); Gestão de

Tecnologia (TEC); Gestão de Negócios (GNE); Gestão de Parcerias e Alianças (GPA), Gestão de


210

Pessoas, Processos e Conhecimento (PPC). Cada Área de Competência envolve, com ênfases

diferentes, tanto aspectos de competências tecnológicas quanto de competências correlatas.

Para apoiar um entendimento deste conceito, o restante desta descrição apresenta uma

racionalidade do conceito.

A partir de levantamentos e estudos realizados ficou evidente que a variedade de formas

que um software pode ser disponibilizado, e sua transversalidade a diversos processos

produtivos e nichos, demandaria uma metodologia de alta complexidade para avaliação, se

focalizássemos a análise do artefato software. A estratégia adotada foi então a de

focalizar os processos relacionados a determinado desenvolvimento de software, ou seja,

avaliar em que medida os processos correlatos ao desenvolvimento de um artefato de

software criaram novos conhecimentos, novas capacidades e novos negócios no País.

O consenso que se formou foi o de focalizar a agregação de competências no País e não

propriamente a origem da tecnologia da informação. Em outras palavras, determinadas

tecnologias podem ter sido geradas no exterior, mas sua absorção e domínio no País levou à

construção de diversos resultados, que posteriormente viemos a definir como competências. O

fio condutor para o entendimento destes resultados é a avaliação dos processos correlatos ao

software ao longo do tempo e a maneira como se dão esses processos no presente

momento.

Para definir que tipos de resultados seriam focalizados na metodologia, cada software foi

analisado sob a ótica de sua contribuição para o desenvolvimento do País, focalizando: 1) a

contribuição para o aumento da autonomia tecnológica do País; 2) a contribuição para o

aumento do potencial de inovação; 3) a contribuição para a geração de negócios baseados em

conhecimento. Estas três dimensões tem ligações intrínsecas e se reforçam mutuamente. Estas

três dimensões escolhidas estão também presentes na literatura utilizada para o

desenvolvimento do trabalho. Para atender a estas dimensões foi construído, também, um

novo olhar para o conceito de Software Resultante de Desenvolvimento Tecnológico e Inovação

Realizados no País: avaliar o quanto um software, a partir do seu desenvolvimento, cria ou

amplia em competências no País.

O item a seguir apresenta em maior detalhe o conceito de competências, mas a visão mais

ampla é a de que o conceito de competência, para efeito da aplicação da metodologia, foi

definido de maneira a se criar uma unidade de referência para medição de resultados

agregados ao País. O que se espera destes resultados é a construção de uma base de

conhecimentos e habilidades que se reforcem mutuamente e diminuam a fragilidade do setor

de software no Brasil, fortalecendo-o para uma reformulação de sua inserção no contexto

nacional. A metodologia não restringe a aquisição de tecnologia de software originalmente

desenvolvida fora do País ou acesso a padrões abertos e plataformas livres, mas busca

evidenciar o quanto foi feito no Brasil e o quanto este contribuiu para o desenvolvimento

de competências locais. Um software pode incluir componentes importados, mas a

metodologia procura avaliar em que medida o corpo principal de conhecimentos, o

diferencial de determinado software, foi desenvolvido e apropriado pelo País. Avalia

também a autonomia que se tem em modificar, utilizar e disseminar estes


211

conhecimentos. Em última instância, quanto mais apropriado e disseminado no País, mais

gerará competências tecnológicas aqui.


212

Entretanto a metodologia vai além, ao incorporar também a expectativa de que o corpo de

conhecimentos técnicos e habilidades sejam perpetuados no País e se sustentem ao longo do

tempo, o que demanda a existência de outras competências que são complementares às

tecnológicas e que se tornam relevantes porque promovem a realização de negócios baseados

em conhecimentos, que são aqui denominadas competências correlatas. Estas competências

procuram evidenciar as capacidades dinâmicas das empresas em planejar e gerenciar os

negócios, parcerias, recursos humanos e processos, vinculados àqueles softwares e serviços.

A verificação de ambos os conjuntos de competências constrói para o comprador da

tecnologia um panorama mais amplo do entorno de determinado software e seus

serviços, sua possibilidade de sustentação no mercado e capacidade de aprimoramento. Mais

que isto, o desenvolvimento destes dois conjuntos de competências dá origem à

ampliação da capacidade de inovação, como se verá mais adiante. Esta nova visão para o

Software Resultante de Desenvolvimento Tecnológico e Inovação Realizados no País procura olhar os

artefatos de software a partir do seu entorno, o que facilita muito o processo de avaliação,

pois, ao contrário do hardware, tornar-se-ia complexo avaliar um software a partir de suas

linhas de código, de sua procedência. Isto encareceria o processo de avaliação e o tornaria

muito extenso e não efetivo. Ao avaliar o que foi gerado (outputs) a partir do desenvolvimento

e o quanto isto é relevante para o País, ganha-se flexibilidade e agilidade. Assim, determinada

empresa pode ter acesso a uma tecnologia desenvolvida fora do País ou acesso a uma

plataforma livre e comercializar serviços que podem ser caracterizados como resultados de

desenvolvimento e inovação tecnológica realizada no País, desde que ela possa comprovar que

de fato passou a dominar aquela tecnologia e que possui um corpo de competências, internas

à empresa, que garantam o aprimoramento da tecnologia e a consecução de negócios para a

sua exploração. No caso específico de um desenvolvimento colaborativo, determinado

software ou serviço conta com competências adicionais às que ele possui em seu entorno,

providas por modelos colaborativos, que podem reforçar aspectos e resultados de autonomia,

consecução de negócios e inovação.

Sob outro ponto de vista, empresas com capital de origem estrangeira também podem obter a

certificação conferida pela aplicação da metodologia para software e serviços, desde que

tragam, disseminem e permitam o domínio daquelas competências, de modo a instalarem no

País laboratórios que efetivamente sejam locus de capacitação de recursos humanos e da

construção de uma capacidade de inovação efetiva sobre certa tecnologia, e não apenas elos

de baixa agregação de valor em uma cadeia global de produção. De uma perspectiva

macroscópica, espera-se que este viés de aferição por meio do rastreamento e exigência das

competências possa trazer impactos para o País, auxiliando e estimulando a construção e

ampliação dessas competências, qualificando os recursos humanos radicados no País,

aumentando a competitividade em negócios e ampliando a inovação. O objetivo a ser atingido

é construir um tecido de empresas que desenvolvam conhecimentos e habilidades que

contribuam para o desenvolvimento nacional, um ecossistema de tecnologia da informação

como insumo para o desenvolvimento nacional sustentável.

Para construir o conceito de competências tecnológicas e correlatas, consideramos as

definições de capacidades dinâmicas de capacidades tecnológicas e organizacionais. O

conceito então formulado foi o de que uma competência é a capacidade de saber mobilizar,

integrar, transferir conhecimentos, recursos e habilidades. Como apontado nos estudos, o


213

desenvolvimento da tecnologia a partir de atividades de pesquisa e desenvolvimento e a

geração de inovações tecnológicas não são suficientes para a geração de negócios e aumento

do market share. Há a necessidade do desenvolvimento de outras competências que

complementam a capacidade de desenvolvimento tecnológico. Estas competências

relacionam-se tanto ao ambiente interno da organização (gestão de recursos humanos,

processos produtivos), como ao ambiente externo (monitoramento de tendências, suporte ao

cliente). É este conjunto de competências (tecnológicas e correlatas), necessárias para a

consecução de negócios baseados em conhecimento, detidas pelas organizações aqui

localizadas, que possibilitam que o desenvolvimento tecnológico tenha resultados efetivos

para o desenvolvimento do País. Estes resultados vão desde a geração de emprego, renda e

arrecadação, até servirem de fundamento para uma sucessiva incorporação de novos

conhecimentos e habilidades que, por sua vez, em razão de serem forças motrizes de indução

de competitividade, levam ao aumento da capacidade de inovação do País e do uso estratégico

destes conhecimentos e habilidades no desenvolvimento nacional.

Assim define-se software como resultante de desenvolvimento tecnológico e inovação

realizados no País quando cria e amplia competências tecnológicas e correlatas no País,

contribuindo para a criação de negócios baseados em conhecimento e aumento da autonomia

tecnológica. Como consequência, quanto mais determinado software agrega competências

no Brasil, mais é intensivo como vetor de desenvolvimento tecnológico e inovação

realizados no País. O Software Resultante de Desenvolvimento Tecnológico e Inovação Realizados no País

pode, então, apresentar-se tanto na forma de software de infraestrutura, software básico

(linguagem de programação, bancos de dados) ou embarcado, quanto na forma de plataformas

ou aplicativos intensivos em conhecimento.

A verificação da geração de competências pode eventualmente transcender a fronteira da

organização detentora do software. Uma competência tecnológica pode, por exemplo, ter sido

gerada em uma universidade ou centro de pesquisa, localizado no Brasil, e que possui

convênio com a organização que detém a propriedade deste software. A busca de evidências

de competências tecnológicas e correlatas nas empresas é o eixo de ação do processo de

avaliação.


214

4.2 Área de competência Desenvolvimento (DES)

Pergunta-chave

O software é resultante de desenvolvimento tecnológico no País?

Descrição

A área de Desenvolvimento abrange as atividades do ciclo de vida do software por meio das

quais são criadas ou ampliadas as competências tecnológicas e correlatas, relacionadas com o

conjunto de tecnologias utilizado para o desenvolvimento. O termo desenvolvimento é

utilizado abrangendo todas as atividades do ciclo de vida do software podendo incluir,

entre outras, concepção, especificação, projeto, construção, teste, implantação, operação,

evolução, manutenção, customização e atendimento ao cliente. A atividade de retirada do

software do mercado, que é uma das atividades típicas de um ciclo de vida, não será tratada

nesse modelo.

As tecnologias utilizadas no software podem ser desenvolvidas ou adquiridas pela Unidade

Organizacional. O domínio de conhecimento nessas tecnologias deve estar focado na

arquitetura do software, na plataforma utilizada para sua construção e na plataforma de

execução. Caso as tecnologias sejam adquiridas, os colaboradores da Unidade Organizacional

devem ter pleno conhecimento sobre elas e capacidade para efetuar manutenções e

evoluções, quando necessário.

A Unidade Organizacional deve mostrar que tem domínio sobre os requisitos do software e

que há rastreabilidade desses requisitos até o código desenvolvido.

Resultados esperados

Como resultado de uma implementação bem-sucedida da área de competência

Desenvolvimento a Unidade Organizacional deve demonstrar que:

• DES.1. O software teve seus requisitos concebidos no País.

• DES.2. A arquitetura do software e a solução técnica (design) estão definidas, com

indicação do que foi desenvolvido na Unidade Organizacional.

• DES.3. As fases e disciplinas realizadas para o desenvolvimento estão definidas e são

compatíveis com o software gerado.

• DES.4. Os papéis e pessoas que desenvolveram o software estão identificados, são

compatíveis com o desenvolvimento e geraram competência tecnológica na Unidade

Organizacional.

• DES.5. Dados técnicos relevantes da tecnologia do software estão documentados.

• DES.6. Atividades de operação relacionadas ao software estão definidas.


215

Explicação detalhada dos resultados esperados

DES.1. - O software teve seus requisitos concebidos no País.

A concepção do software deve ter sua origem no País, gerando competências

tecnológicas e correlatas associadas ao domínio de conhecimento necessário ao

desenvolvimento do produto e seus serviços associados.

A partir de um conjunto de necessidades são levantados, analisados e documentados

os requisitos para o desenvolvimento do software.

A documentação dos requisitos servirá de insumo para a definição da solução técnica

(design), podendo também ser utilizada para a verificação e validação do produto resultante e

seus serviços associados. Em função da sua relevância para as etapas posteriores do

desenvolvimento, a documentação de requisitos deve ser verificada pelos colaboradores e

validada pelo cliente.

No caso de necessidade de mudança (manutenção ou evolução) do software, uma

análise de impacto deve ser executada para garantir que é possível a realização da mudança,

bem como a identificação dos componentes afetados, tais como documentação de requisitos e

solução técnica (design). A análise de impacto deve utilizar a visualização da rastreabilidade a

partir de um requisito até o código fonte e vice-versa, passando pelos diferentes artefatos

produzidos ao longo do processo de desenvolvimento.

Orientações

Para que esse resultado esperado seja atendido é necessário encontrar informações

que mostrem que a ideia que originou o software foi concebida no País. Geralmente, essa ideia

está refletida na documentação dos requisitos e na documentação da arquitetura e solução

técnica (design do software) que foram adotadas. É necessário identificar quais foram os

recursos humanos envolvidos, se eles estão fixados no País e se dominam a tecnologia

existente, a ponto de executar manutenção no software.

Em alguns casos, podem ser encontrados registros dessa ideia ou desdobramentos

dela em atas de reuniões, no escopo de uma proposta técnica ou contrato, em apresentações,

em ferramentas que fazem a gestão dos requisitos ou naquelas que documentam a

arquitetura da solução, nos documentos dos cenários operacionais, etc. Em todos esses casos

é necessário mostrar que houve geração de competência tecnológica no País.

Exemplos de tipos de evidências

• Definição e documentação dos requisitos do software.

• Documentação de Conceitos Operacionais do Sistema, especificando as

responsabilidades alocadas ao software.

• Apresentação do escopo a ser desenvolvido para o software e seus serviços,

incluindo produtos internos e produtos que devem ser entregues para o cliente.

• Aprovação dos requisitos pelo cliente.

• Aceite dos requisitos pela equipe técnica responsável pelo desenvolvimento.


216

• Proposta técnica elaborada contendo o escopo do desenvolvimento do software.

• Documentação da análise de impacto feita devido a uma alteração no software.

• Árvore de rastreabilidade dos requisitos com os demais artefatos gerados pelo

processo de desenvolvimento do software e seus serviços relacionados.

DES.2. – A arquitetura do software e a solução técnica (design) estão definidas, com

indicação do que foi desenvolvido na Unidade Organizacional.

A arquitetura do software e a solução técnica (design) devem estar definidas a partir

dos requisitos considerando aspectos de qualidade, aspectos de desempenho que são críticos

para o sucesso da solução proposta, as principais interfaces internas e todas as interfaces

externas. A arquitetura e design definem como o software é construído, em alto nível de

abstração (Arquitetura) e em nível detalhado (Design).

Os arquitetos da Unidade Organizacional devem ser capazes de formular, desenvolver

e atualizar a arquitetura, tomando decisões sobre a alocação de requisitos e os componentes

de software. Se o projeto de arquitetura passar por algum tipo de verificação pelos pares, os

colaboradores que elaboraram o projeto de arquitetura não devem participar dessa atividade

para não influenciar no resultado.

O uso de componentes adquiridos para compor a solução arquitetural e tecnológica do

software pode ser necessário e, nesse caso, deve estar explicitado no projeto de arquitetura.

Quando se tratar das tecnologias relevantes e estratégicas, ações tais como “capacitar os

colaboradores da Unidade Organizacional” ou “selecionar um componente desenvolvido na

linguagem de programação conhecida” ou “selecionar um componente com código fonte

aberto”, devem ser executadas para manter a apropriação e autonomia tecnológica sobre o

software. Nesse caso, deve existir pelo menos uma alteração significativa no projeto de

arquitetura que foi executada pelos colaboradores da Unidade Organizacional.

Nota: alguns critérios foram adotados no escopo deste modelo para apoiar na

identificação das tecnologias relevantes e estratégicas para o software:

a) A tecnologia licenciada (adquirida) é parte significativa do valor de mercado do

software.

b) A tecnologia promove um diferencial tecnológico ou de negócios para o software

frente aos concorrentes.

c) A tecnologia está no escopo das tecnologias estratégicas definidas pelo MCTI.

Orientações


sobre a arquitetura do software na Unidade Organizacional. A equipe da Unidade

Organizacional envolvida na definição da arquitetura ou que recebeu capacitação nessa

arquitetura deve ser capaz de mostrar e explicar as camadas definidas e o que foi necessário

fazer para modifica-la. É necessário verificar a existência de pelo menos uma modificação

significativa realizada pela equipe da Unidade Organizacional na solução arquitetural.


217

É necessário identificar quais foram os recursos humanos envolvidos na elaboração ou

na manutenção da solução arquitetural, os perfis e se foram geradas competências na Unidade

Organizacional.

Nos casos em que foi necessário o uso de componentes adquiridos para compor a

solução arquitetural e tecnológica do software é necessário encontrar informações sobre: a

capacitação da equipe da Unidade Organizacional nos aspectos tecnológicos desses

componentes, a autonomia da Unidade Organizacional para tomar decisões sobre esses

componentes, a autonomia da Unidade Organizacional para efetuar modificação na solução

arquitetural nesses componentes, a competência da equipe da Unidade Organizacional para

executar tais modificações e a execução de pelo menos uma modificação significativa realizada

pela equipe da Unidade Organizacional, na solução arquitetural adquirida.


• Realização de reunião para a definição do projeto de arquitetura do software.

• Projeto de arquitetura do software, documentado pelos colaboradores

gerenciados pela Unidade Organizacional e de acordo com os requisitos do

software desenvolvido.

• Especificação da solução técnica para o desenvolvimento do software.

• Resultado da realização da atividade de verificação entre os requisitos do software

e a definição do projeto de arquitetura, executada pelos colaboradores

gerenciados pela Unidade Organizacional.

• Histórico de atualização do projeto de arquitetura do software desenvolvido ou

adquirido, indicando que a modificação ou parte significativa dela foi realizada

pelos colaboradores gerenciados pela Unidade Organizacional.

• Definição e documentação do detalhamento dos cenários operacionais.

• Capacitação dos colaboradores da Unidade Organizacional nos aspectos

tecnológicos do componente adquirido.

• Apropriação e autonomia tecnológica pela Unidade Organizacional, da arquitetura

adquirida.

• Árvore de rastreabilidade demonstrando os relacionamentos do projeto de

arquitetura do software com os respectivos requisitos do software e demais

artefatos gerados pelo processo de desenvolvimento.

DES.3. – As fases e disciplinas realizadas para o desenvolvimento estão definidas e são

compatíveis com o software gerado.

O desenvolvimento do software foi definido e executado, ou seja, cada disciplina

aplicável à construção do software aconteceu no momento definido para sua realização.

A realização das fases e disciplinas do desenvolvimento pode ser obtida por meio dos

componentes da gestão de configuração (repositório do projeto, sistema de versionamento,

sistema de controle de mudanças e sistema de gerenciamento de builds – versões integradas),

ou internamente nos documentos gerados para o software (histórico de alteração, atas de

reunião, mensagens eletrônicas, etc).


218

Por meio do resultado da execução das fases e disciplinas do desenvolvimento é

possível verificar a compatibilidade existente entre o software, com a sua complexidade,

tamanho, quantidade de colaboradores envolvidos e duração do projeto.

Orientações

Para que esse resultado esperado seja atendido é necessário encontrar informações de

como aconteceu o desenvolvimento do software, desde a fase de elaboração até a liberação

da versão final. Devem ser verificados os documentos gerados como resultado da execução

das fases previstas, identificando-se quantos e quais foram os recursos envolvidos nessa

geração, se as datas e duração das atividades realizadas estão de acordo com a complexidade

e o tamanho do software desenvolvido, bem como a adequação dos perfis envolvidos.

Em especial, deve ser feita uma verificação da solução técnica e da arquitetura, versus

a documentação dos requisitos, checando se o escopo, os seus desdobramentos no projeto de

arquitetura, as datas de realização, os colaboradores envolvidos (quantos, quem e onde

estavam) e o conhecimento gerado são compatíveis com o software desenvolvido.


• Estimativas para o desenvolvimento do software.

• Cronograma com as fases de desenvolvimento do software.

• Atividades realizadas de acordo com o planejamento e de acordo com a sua

complexidade, tamanho e equipe alocada.

• Registros de controle de versão (versionamentos de documentos gerados durante

a execução das fases do desenvolvimento do software).

• Registros das alterações nos documentos do software (data, versão, autor,

descrição da alteração).

• Evidências de verificação e validação para o software desenvolvido e compatível

com a fase executada.

DES.4. – Os papéis e pessoas que desenvolveram o software estão identificados, são

compatíveis com o desenvolvimento e geraram competência tecnológica na Unidade

Organizacional.

As equipes de trabalho envolvidas no desenvolvimento do software são identificadas,


que realizaram.

As atividades executadas pelas equipes de trabalho no desenvolvimento do software,

em especial aquelas relacionadas com a definição de requisitos e definição do design

(especificação da solução técnica e arquitetura) devem resultar na geração de competência

tecnológica na Unidade Organizacional.

Nota: atividades tais como codificação e testes não necessariamente resultam na

geração de competências tecnológicas na Unidade Organizacional.

Orientações

Para que esse resultado esperado seja atendido é necessário identificar quem foram os

colaboradores envolvidos no desenvolvimento tecnológico do software (foco na definição dos

requisitos, especificação da solução técnica e arquitetura), onde foram executadas as

atividades de desenvolvimento e se houve apropriação de competência tecnológica pela

Unidade Organizacional a ponto de serem efetuadas manutenções na tecnologia gerada no


219

software. É necessário obter informações sobre o perfil profissional dos colaboradores e suas

competências tecnológicas para verificar se existe um alinhamento com as atividades que

realizaram e os resultados que geraram no software.


• Registro/controle de homens-hora no projeto, identificação do colaborador que

fez o trabalho (quem fez o quê? com qual papel?). Ex. cronograma, planilha de

alocação de horas, indicação do autor envolvido na alteração de documentos do

software (foco na definição dos requisitos, especificação da solução técnica e

arquitetura).

• A competência tecnológica relacionada ao software está na Unidade

Organizacional ou em outra empresa nacional participante do desenvolvimento.

Ex. colaboradores capacitados, registros do conhecimento tecnológico em

ferramentas de Gestão do Conhecimento, documentação tecnológica do Software.

• Colaboradores capacitados ou planejamento da capacitação para a geração de

competência tecnológica na Unidade Organizacional, necessária à execução das

atividades de desenvolvimento do software. Ex.: registros de treinamentos

realizados ou a realizar, certificados específicos de uma tecnologia relevante,

avaliação de eficácia de treinamentos realizados, divulgação do material de

treinamento.

DES.5. Dados técnicos relevantes da tecnologia do software estão documentados

Para que o desenvolvimento, a evolução, a manutenção, o atendimento ao cliente ou a

customização do software possam acontecer de forma satisfatória, um conjunto mínimo de

documentos, que contém as informações tecnológicas e que servem de insumos para o

trabalho da equipe envolvida, é elaborado. São exemplos desses documentos: documentação

de requisitos, documento de detalhamento de cenários para os requisitos mais complexos,

projeto de componentes, projeto de arquitetura, documentação das atividades de verificação

e validação.

Orientações


documentadas sobre a tecnologia-chave presente no software. Essa documentação deve ter

sido utilizada no desenvolvimento, na evolução, na manutenção, no atendimento ao cliente ou

na customização do software.

Essa documentação deve estar armazenada em local seguro e de fácil recuperação

pelos envolvidos nas atividades de desenvolvimento, evolução, manutenção, atendimento ao

cliente ou customização do software.

Um caso especial de utilização dessa documentação pode ser o de reuso em novas

soluções ou para a capacitação de novos integrantes da equipe responsável pelo software.


• Documentação de requisitos.

• Documento de detalhamento de cenários para os requisitos mais complexos.

• Documento do projeto de Arquitetura do software.

• Documento de evidências de execução de atividades de verificação e validação.


220

• Registro de tomada de decisão para adoção de uma tecnologia mais atual.

• Código-fonte documentado.

DES.6. – Atividades de operação relacionadas ao software estão definidas.

As atividades de operação consideradas nesse modelo são aquelas executadas após o

software estar liberado para uso. Podem incluir atividades de manutenção corretiva e

evolutiva (ou adaptativa), atividades de implantação e atividades de atendimento ao cliente.

Tais atividades, quando pertinentes às características do software, devem estar definidas e

serem executadas.

Nota: nem sempre o serviço de implantação é pertinente a todo software. É o caso do

software de prateleira (COTS – commercial off-the-shelf, também conhecido como pacotes) em

que o próprio usuário faz a sua instalação e configuração.

Atividades para a manutenção corretiva e evolutiva (adaptativa) do software

consistem na execução de atividades de correção a partir da identificação de incidências no

software. A correção pode acontecer devido a uma solicitação interna da organização ou pelos

clientes. A evolução do software consiste da inclusão de novas soluções e funcionalidades e/ou

migração para tecnologias mais atuais. A evolução pode acontecer devido a uma demanda do

mercado, estratégia interna da organização ou por solicitação dos clientes. Alguns contratos de

suporte e manutenção de software definem critérios para liberação de uma ou mais releases e

versões por ano, nas quais podem constar correções e evoluções realizadas no período. Um

caso particular da atividade de manutenção é a customização que consiste em introduzir

modificações específicas no software que o torne aderente às necessidades particulares de um

cliente ou linha de negócio. A grande dificuldade desse tipo de serviço para a organização está

na manutenção de diversas variantes de um mesmo produto.

O serviço de implantação consiste da preparação do ambiente alvo no qual o software

será disponibilizado para uso, envolvendo questões como recursos de hardware, software,

migração de dados, instalação, configuração, parametrização, treinamento dos usuários,

entre outros. A implantação pode ocorrer devido a uma entrega contratada pelo cliente ou

devido à liberação de novas releases ou versões.

As atividades de atendimento ao cliente podem estar associadas ao fornecimento de

assistência ao uso ou à identificação de defeitos encontrados no software. Treinamentos,

fornecimento de documentação, operação assistida, esclarecimentos e orientações para o uso

correto do software são exemplos de fornecimento de assistência ao uso. Apoio na abertura

de chamados pelos clientes e atendimentos para que correções sejam executadas no software

em ambiente de produção são exemplos de fornecimento de assistência aos usuários na

identificação de defeitos.

A Unidade organizacional deve estar preparada para executar as atividades de

operação relacionadas ao software. Estar preparada significa ter colaboradores capacitados e

disponíveis no momento adequado à execução das atividades de operação, que saibam se

comunicar com o cliente, que conheçam a tecnologia presente no software e que saibam atuar


221

junto aos recursos existentes no ambiente alvo onde o produto está ou será implantado, a fim

de dar o devido tratamento às necessidades que foram reportadas pelos clientes.

Orientações


que mostrem que o software terá continuidade, após liberado para o uso. Para tal, é

necessário encontrar evidências relacionadas à existência de colaboradores disponíveis na

Unidade Organizacional e com competência tecnológica para atuar nas atividades previstas

para a continuidade do software tais como, atividades de manutenção corretiva e evolutiva,

implantação e atendimento ao cliente.

É necessário encontrar informações que mostrem que essas atividades, quando

aplicáveis às características do software, estão definidas (minimamente documentadas). A

atividade de customização é executada sob demanda. A atividade de implantação não é

executada para software de prateleira (COTS – commercial off-the-shelf). As demais atividades

(manutenção e atendimento ao cliente) devem ser executadas, independente das

características do software.

Dessa forma, é necessário encontrar informações que mostrem que as atividades de

operação aplicáveis ao software estão definidas (minimamente documentadas), foram

realizadas por colaboradores identificados, com capacitação para isso, e geraram competência

tecnológica na Unidade Organizacional.


• Registro da necessidade de uma manutenção evolutiva do software em uma

ferramenta. Ex.: ferramenta de roadmap.

• Manutenção evolutiva do software, a partir da indicação de outros departamentos

da organização (ex.: atas de reunião, material de apresentação, e-mail ou

documento específico, entre outros) ou ferramenta de gestão do produto (ex.:

ferramenta de roadmap), sobre uma nova tendência do mercado.

• Informação sobre a localização física do colaborador que executou atividades de

operação relacionadas ao software. Ex. contrato de trabalho no País, plano de

trabalho, cadastro de pessoal, folha de presença.

• Colaboradores capacitados ou planejamento da capacitação para a geração de

competência tecnológica na Unidade Organizacional, necessária à execução das

atividades de operação relacionadas ao software. Ex.: registros de treinamentos

realizados ou a realizar, certificados específicos de uma tecnologia relevante,

avaliação de eficácia de treinamentos realizados, lista de presença de workshop

realizado para uma versão do software evoluído.

• Colaboradores capacitados e disponíveis para atuar nas atividades de operação

relacionadas ao software.

• Controle de homens-hora no projeto de manutenção ou customização ou

implantação ou atendimento ao cliente. Identificação do colaborador que fez a

atividade (quem fez o quê?).


222

Ex. cronograma, planilha de alocação de horas, registros na ferramenta de

roadmap do produto, gestão das atividades de atendimento ao cliente.

• Acompanhamento da legislação aplicável ao software para atendimento das novas

exigências legais.

• Existência de canal de comunicação com o cliente.

• Abertura de um chamado pelo cliente para correção de um defeito encontrado.

• Registro de práticas para garantir o atendimento às solicitações dos clientes.

• Tratamento da solicitação de correção efetuada no software entregue ao cliente.

• Controle de versão (versionamento de documentos gerados durante a

manutenção corretiva ou evolutiva ou customização do software).

• Histórico de alteração de documentos do software (data, versão, autor, descrição

da manutenção corretiva ou evolutiva, ou customização, ou implantação).

• Atualização no projeto de arquitetura do software devido à necessidade de

evolução ou correção emergencial.

• Rastreabilidade dos chamados para manutenção do software, com a identificação

dos colaboradores envolvidos, na abertura, tratamento e encerramento.

• Planejamento das atividades de implantação do software. Ex.: cronograma de

atividades e alocação de colaboradores capacitados.

• Documentação sobre o levantamento dos recursos existentes no ambiente alvo

para a implantação do software.

• Registro da aceitação pelo cliente, do software implantado.

• Relação dos chamados de atendimento recebidos para o software, versus a relação

dos chamados tratados.

• Resultado da pesquisa de satisfação dos clientes do software.

• Solicitação e realização de um treinamento do tipo “operação assistida” aos

usuários do software.


223

4.3 Área de competência Gestão de Tecnologia (TEC)

Pergunta-chave

O software é mantido tecnologicamente autônomo e competitivo?

Descrição

A área de competência “Gestão de Tecnologia” envolve o estabelecimento de ações

direcionadoras para o desenvolvimento de tecnologia no País que seja relevante e estratégica

para o software, buscando obter um alto grau de autonomia tecnológica.

Essa área de competência se preocupa com o acompanhamento das evoluções tecnológicas

relacionadas com o software para que ele se mantenham atualizado tecnologicamente,

tornando-o competitivo.


Como resultado de uma implementação bem-sucedida da área de competência Gestão de

Tecnologia a Unidade Organizacional deve demonstrar que:

• TEC.1. O desenvolvimento do software utiliza resultados de pesquisa e

desenvolvimento.

• TEC.2. O desenvolvimento do software potencializa pesquisa e desenvolvimento no

País.

• TEC.3. As tecnologias relevantes e estratégicas para o software são identificadas,

apropriadas e monitoradas pela organização.

• TEC.4. Ações para introduzir inovações tecnológicas no software são estimuladas e

realizadas.

• TEC.5. A organização tem autonomia sobre as tecnologias relevantes e estratégicas



TEC.1. O desenvolvimento do software utiliza resultados de pesquisa e desenvolvimento.

A criação do software, bem como sua evolução ou manutenção deve usufruir de

resultados oriundos de pesquisa e desenvolvimento realizada pela própria organização, ou por

uma organização de pesquisa e desenvolvimento nacional, ou por uma organização

estrangeira. Qualquer que seja a situação, a utilização de resultados de pesquisa e

desenvolvimento deve promover a formação de competência no País e para isto, a

apropriação dos resultados dessa pesquisa pela Unidade Organizacional deve acontecer.


224

Orientações

É necessário verificar se a organização tem alguma área responsável por projetos de

pesquisa e desenvolvimento para consumo próprio ou se tem a prática de trabalhar com

outras organizações (nacionais ou estrangeiras) para atuação conjunta em projetos de

pesquisa e desenvolvimento. Dependendo da característica dessa atuação será necessário

verificar as regras de cooperação existente e como ocorre a formação das competências na

pesquisa desenvolvida e no resultado gerado. É essencial que sejam obtidas informações que

comprovem a geração de competências no País e a apropriação do resultado de pesquisa

utilizado.

Para que esse resultado esperado seja atendido é necessário identificar a utilização do

resultado de um projeto de pesquisa e desenvolvimento na geração do software. Esse tipo de

informação pode ser obtido na documentação do projeto que gerou o software. É necessário

encontrar informações sobre o projeto de pesquisa e desenvolvimento para verificar se foram

geradas competências tecnológicas relacionadas na Unidade Organizacional onde o software

foi executado e se ocorreu a apropriação do resultado de pesquisa utilizado pela Unidade

Organizacional.


• Instrumento legal ou carta de intenção firmado com órgãos de pesquisa que

resultou no desenvolvimento de um projeto de pesquisa e desenvolvimento,

utilizado no software.

• Projeto de pesquisa e desenvolvimento que gerou o software ou um componente

deste.

• Documentação de requisitos do software ou componente deste, resultante de

projeto de pesquisa e desenvolvimento.

• Definição da solução técnica presente no software a partir de um projeto de

pesquisa e desenvolvimento executado com parceiro(s) de base tecnológica.

• Uso do resultado de um projeto de pesquisa e desenvolvimento, na tomada de

decisão para o desenvolvimento do software.

• Identificação do ponto focal (gatekeeper) que promoveu a interação com as

instituições de pesquisa e desenvolvimento para o software.

• Capacitação dos colaboradores da Unidade Organizacional nos resultados de um

projeto de pesquisa e desenvolvimento relacionado ao software que foi executado

por outras organizações.


A criação do software, bem como sua evolução ou manutenção deve intensificar a

pesquisa e desenvolvimento no País. A pesquisa e desenvolvimento pode ter sido intensificada

na própria organização ou em outra organização de pesquisa e desenvolvimento nacional ou

com base no País.

Orientações


225


que mostrem a geração de um projeto de pesquisa e desenvolvimento para atender uma ou

mais necessidades do software e/ou as contribuições que o software forneceu para a

intensificação da área de pesquisa e desenvolvimento no País, seja motivando novas pesquisas

relacionadas, a continuidade da pesquisa existente, a utilização do resultado da pesquisa

gerada em outras frentes, etc. Em qualquer um desses casos, será necessário verificar as

informações relacionadas para comprovação da ocorrência de potencialização de pesquisa e

desenvolvimento no País a partir do software.


• Desenvolvimento do software que necessitou da execução de pesquisas associadas

e que geraram atualização no próprio produto.

• Instrumento legal ou carta de intenção firmado com órgãos de pesquisa que

resultou no desenvolvimento de um projeto de pesquisa e desenvolvimento,

utilizado no software.

• Identificação do ponto focal (gatekeeper) que promoveu a interação com as


• Software que gerou mais software (open innovation).

• Publicação ou apresentação em eventos de pesquisa e desenvolvimento para

divulgação dos resultados alcançados com o desenvolvimento do software.

• Dissertação de mestrado e/ou tese de doutorado resultante do desenvolvimento

do software.

TEC.3. As tecnologias relevantes e estratégicas para o software são identificadas,

apropriadas e monitoradas pela organização.

A organização deve definir e manter ações de vigilância e prospecção para identificar

as tecnologias que sejam ou que possam ser relevantes para o seu negócio. Estas ações devem

ser aplicadas na busca e identificação das tecnologias que fazem ou farão parte do software.

O software pode utilizar uma ou mais tecnologias. Algumas delas que tratam os

aspectos tecnológicos relevantes e estratégicos para o software devem ser de domínio e

conhecimento dos colaboradores envolvidos no desenvolvimento.

No caso de tecnologias relevantes e estratégicas desenvolvidas por terceiros serem

utilizadas no software é necessário que o conhecimento tecnológico seja apropriado pela

Unidade Organizacional. Quando uma Unidade Organizacional se apropria de uma tecnologia,

seja ela desenvolvida no País ou não, a base tecnológica nacional amplia-se.

Orientações

É necessário verificar quais ações de vigilância e de prospecção foram realizadas para

selecionar as tecnologias relevantes e estratégicas que estejam ou possam estar presentes no

software.


226

A organização deve, ainda, apresentar informações que demonstrem esforços voltados

para a apropriação do conhecimento tecnológico presente no software, pelos colaboradores

da Unidade Organizacional.

A realização de ações voltadas à apropriação do conhecimento tecnológico pode ser

verificada nas informações de capacitação dos colaboradores da Unidade Organizacional em

tecnologias consideradas relevantes (principalmente nos casos em que os aspectos

tecnológicos mais relevantes foram gerados por outras organizações e adquiridos pela

empresa em questão, e repassados aos colaboradores envolvidos com as atividades do

software), no aprendizado tecnológico divulgado internamente na Unidade Organizacional, na

documentação tecnológica que os colaboradores geraram para o software ou nos registros

da gestão de conhecimento relacionados ao aspecto tecnológico utilizados para formação

de competências e resolução de problemas, entre outros.


• Existência de ações de prospecção de tecnologias e estudos de tendências que

possam ser identificadas como relevantes para o software.

• Existência de ações de vigilância das tecnologias identificadas como relevantes

para o software.

• Existência de um grupo de estudos direcionado para a busca de tecnologias

relevantes e estratégicas para o software.

• Análise de novas tecnologias relevantes e estratégicas a serem incorporadas ao

software.

• Divulgação na organização de tecnologias relevantes e estratégicas no mercado

global e que podem ser estratégicas para o software.

• Ações voltadas à apropriação do conhecimento tecnológico pelos colaboradores

da organização.

• Existência na organização de um grupo de especialistas em determinada

tecnologia.

• Participação da organização em grupos de pesquisa sobre determinada tecnologia.

• Registros/declaração de participação ativa em fóruns de discussão tecnológica e

eventos tecno-científicos.

• Roadmaps tecnológicos relacionados com o software são conhecidos e utilizados

efetivamente na tomada de decisão.

• Registro do uso efetivo de roadmap tecnológico no software.

TEC.4. Ações para introduzir inovações no software são estimuladas e realizadas.

A organização deve atuar de forma proativa para identificar, selecionar e introduzir

inovações no software seja de maneira isolada ou em conjunto com parceiros. Tais iniciativas

são estimuladas e realizadas na organização, por exemplo, por meio de investimentos

financeiros em projetos de inovação ou por programas de premiação e reconhecimento, que

são geralmente implantados nas organizações como motivadores para a geração de ideias

inovadoras pelos seus colaboradores.

Orientações


227

É necessário verificar se a organização se preocupa com a inovação, se incentiva seus

colaboradores na busca de ideias que sejam inovadoras e se as implementa quando aplicáveis.


que mostrem a realização de ações voltadas à implementação do aspecto inovador no

software. Não precisa ter a inovação implementada, mas devem ser encontradas evidências de

ações para isso.


• Ação estruturada que estimule colaboradores a indicar inovação tecnológica para

ser implementada no software.

• Envolvimento dos colaboradores da equipe de desenvolvimento na decisão pela

adoção ou não de uma inovação no software.

• Lançamento do software e seus serviços no mercado, incluindo a inovação

realizada.

• Existência de um comitê para direcionar a introdução da inovação.

• Identificação do ponto focal (gatekeeper) que atua na interação com as


TEC.5. A organização tem autonomia sobre as tecnologias relevantes e estratégicas que

estão presentes no software.

A organização deve definir e manter critérios para identificação das tecnologias

relevantes e estratégicas para o seu negócio. Estes critérios devem ser aplicados na

identificação das tecnologias que fazem parte do software.

A organização deve ter autonomia técnica e decisória para efetuar modificações nas

tecnologias proprietárias e naquelas que foram apropriadas que estão presentes no software.

A organização deve ser capaz de prover essas modificações.

Uma ou mais tecnologias podem ser geradas no desenvolvimento do software.

Aquelas que são relevantes e estratégicas para o software devem ser de domínio e

conhecimento dos colaboradores que atuam no seu desenvolvimento. O domínio e

conhecimento nessas tecnologias devem estar focados na arquitetura do software, na

plataforma utilizada para sua construção e na plataforma de execução.

Quando for adquirida uma das tecnologias relevantes e estratégicas do software, por

exemplo, um componente, ela deverá no mínimo estar descrita para que novos colaboradores

possam entendê-la e, se necessário, evoluí-la para outras plataformas. Caso os colaboradores

não tenham o domínio dessa tecnologia, deve ser demonstrado o planejamento e a realização

da capacitação necessária. Dessa forma, fica garantida a continuidade do software.

Quando o software for desenvolvido fora do País, porém comercializado, implantado e

atualizado no País, é relevante que a equipe envolvida na execução das atividades de

evolução, suporte e manutenção no País, tenha autonomia técnica e decisória para realizar as

modificações necessárias no software. Ex.: o software foi desenvolvido por uma organização

estrangeira e será comercializado, implantado e atualizado por meio de organizações nacionais


228

(filiais ou não). Nesse caso, a equipe de colaboradores da organização nacional deverá ter

autonomia técnica e decisória para realizar as modificações no software, que julgue

necessárias à sua comercialização, o que a torna independente da organização estrangeira

desenvolvedora.

Orientações


que mostrem que a Unidade Organizacional possui autonomia tecnológica e de decisão sobre

o software. Uma forma é identificar os colaboradores que foram capazes de modificar a

documentação relacionada à tecnologia presente no software, independente se essa

tecnologia foi desenvolvida por eles ou não, suas competências tecnológicas, se eles

pertencem à Unidade Organizacional ou a outra empresa nacional participante do

desenvolvimento.

É necessário encontrar informações que mostrem que a decisão de efetuar

modificações na tecnologia do software bem como de sua execução foi da Unidade

Organizacional.


• Lista dos critérios para identificação das tecnologias relevantes e estratégicas para

o negócio da organização.

• Lista das tecnologias identificadas como relevantes e estratégicas para a

organização.

• Execução de atualização pelos colaboradores da Unidade Organizacional, na

tecnologia do software (caso em que a Unidade Organizacional desenvolveu o

produto).

• Tomada de decisão, pela Unidade Organizacional, para atualização na tecnologia

do software.

• Documentação de atualização significativa realizada pelos desenvolvedores da

Unidade Organizacional, no componente tecnológico que foi adquirido para

compor a solução do software.

• Registro de patente ou de propriedade intelectual, realizada no Brasil.

• Atestado de propriedade do software, fornecido por associações/instituições

reconhecidas.


229

4.4 Área de competência Gestão de Negócios (GNE)

Pergunta-chave

O software potencializa negócios baseados em conhecimento e é direcionado por esses

negócios?

Descrição

A área de competência Gestão de Negócios refere-se às ações voltadas para a promoção e o

aumento de negócios baseados em conhecimento, por meio do software. Entende-se por

negócios baseados em conhecimento aqueles que envolvem conhecimento aprofundado das

tecnologias envolvidas e sua integração, do negócio do cliente ou do domínio de aplicação

do software, entre outros.

A gestão de negócios compreende desde esforços relacionados ao monitoramento de

tendências de mercado até o pós-venda, incluindo a interface com o cliente para verificar o

nível de satisfação com o software fornecido.

Ações e práticas relacionadas à estratégia de negócios (de longo prazo) devem ser planejadas

antes de serem executadas, pois não ocorrem ao acaso.

Destacam-se, ainda, práticas voltadas para revisões periódicas da direção dos negócios da

organização, que podem incluir a utilização de ferramentas tais como roadmaps e outras ações

relativas à antecipação de tendências.



Negócios a Unidade Organizacional deve demonstrar que:

• GNE.1. Ações de monitoramento de tendências de mercado, que impactam negócios

baseados em conhecimento relacionados ao software são planejadas e realizadas.

• GNE.2. A análise de produtos concorrentes ao software é planejada e realizada.

• GNE.3. Ações de antecipação e atendimento de necessidades de clientes, que

impactam negócios baseados em conhecimento relacionados ao software são

planejadas e realizadas.

• GNE.4. Instrumentos para direcionar a evolução do negócio relacionado ao software


• GNE.5. Ações para ampliação de negócios relacionados ao software são planejadas e

realizadas.



230

GNE.1. Ações de monitoramento de tendências de mercado, que impactam negócios

baseados em conhecimento relacionados ao software são planejadas e realizadas.

Monitorar tendências significa observar e informar-se em relação ao desenvolvimento

de uma área de interesse. Para monitorar tendências é preciso dispor de procedimentos que

gerem informações, indicadores e/ou mapeamentos sobre a evolução do mercado de software

e de seus serviços associados.

As ferramentas de monitoramento (como a bibliometria, por exemplo) podem ter foco

na tecnologia (monitoramento tecnológico), na produção de tecnologia (marketing,

comercialização, organização, etc.), ou em questões institucionais (regulação, legislação,

financiamento, etc.). Em geral, os exercícios de monitoramento utilizam artigos científicos e

patentes como principais fontes de dados, visto que essas informações auxiliam na

identificação de mudanças tecnológicas e de inovação.

A realização de ações de monitoramento não deve servir apenas como varredura de

informações, mais ou menos completa, mas deve estar integrada às rotinas de planejamento e

de aprendizado da organização.

Orientações

É necessário verificar se a organização executa ações de monitoramento de mercado

dos produtos e serviços que ela gera. Algumas organizações bem estruturadas têm uma área

especializada com equipe própria só para executar esse tipo de monitoramento. Já outras

organizações menores e não estruturadas fazem esse tipo de atividade de maneira informal.


que mostrem a execução de ações de monitoramento de mercado para o software, as

decisões tomadas a partir das informações obtidas nesse monitoramento, os resultados

gerados para o software e a geração de conhecimentos.


• Investimento em pesquisa de mercado onde o software se insere.

• Documentação de pesquisa gerada por um ou mais colaboradores da organização,

ou contratados por ela, que realizaram atividades de estudo e monitoramento de

mercado onde o software se insere.

• Comunicação aos tomadores de decisão sobre tendências que estão convergindo,

divergindo, ampliando, diminuindo ou interagindo.

• Decisões de negócio tomadas e/ou desenvolvimento de software (ou parte dele)

realizado em virtude de reflexões baseadas em monitoramento (com

comprovação).

• Envolvimento com parceiros técnicos para conhecer as necessidades do mercado

alvo a serem incorporadas no software.

• Envolvimento com parceiros de negócios para conhecer o funcionamento do

mercado alvo e definir as estratégias a serem incorporadas no software.

• Prospecção de necessidades de clientes potenciais.


231

• Participação em eventos científicos, técnicos ou socioeconômicos significativos

relacionados ao mercado ou nicho onde o software está inserido.

• Assinatura de revistas especializadas, participação em associações, fóruns, e

outros meios de discussão que forneçam informações do mercado para o

software.

• Análise de fornecedores como fonte de tendência de mercado, tecnologia e

oportunidades.


A busca das melhores práticas e soluções que podem conduzir a um desempenho

superior é vista como algo positivo e proativo. A organização deve examinar práticas,

produtos, soluções e serviços de outras organizações a fim de melhorar a forma como realiza

algo semelhante, visando potencializar o seu próprio negócio.

A análise de soluções concorrentes permite maior conhecimento sobre pontos fortes e

pontos fracos do software, apoiando a tomada de decisões sobre sua evolução.

Orientações

É necessário verificar se a organização conhece quem são os seus concorrentes. É

necessário verificar se a organização executa ações para descobrir o que os produtos e serviços

concorrentes do software possuem. Pode acontecer da organização não ter nenhum

concorrente e o seu produto ou serviço ser único no mercado.


que mostrem a execução de ações pela organização para conhecer os concorrentes do

software, mesmo que resulte na inexistência de concorrentes. Se existir pelo menos um

produto ou serviço concorrente do software é necessário encontrar informação sobre a

execução de ações de levantamento e análise, pela organização, sobre o que contém o

produto ou serviço concorrente. É necessário identificar os colaboradores da organização

envolvidos nessa atividade de descoberta.


• Mapeamento dos concorrentes do software.

• Análise da documentação de pesquisas sobre as soluções existentes em outros

produtos e serviços que sejam similares ao do software.

• Participação em feiras de tecnologia, como expositor ou visitante, para conhecer

as opções fornecidas pelos concorrentes do software.

• Conhecer ameaças potenciais, implícitas a partir da participação em eventos

científicos, técnicos ou socioeconômicos significativos relacionados ao mercado ou

nicho onde o software está inserido.

• Divulgação ou encaminhamento na organização, das informações obtidas nos

produtos e serviços concorrentes. Exemplos: reuniões, apresentações para comitês

e conselhos, ferramentas de trabalho específicas.


232

GNE.3. Ações de antecipação e atendimento de necessidades de clientes, que impactam

negócios baseados em conhecimento relacionados ao software são planejadas e realizadas.

Inclui aspectos relacionados à utilização da capacidade da organização de (a) antecipar

as necessidades do cliente, desenvolver e oferecer soluções criadas com base no que espera

que o cliente demande para o software; (b) atender às demandas em termos de qualidade e

prazos; (c) acompanhar a satisfação do cliente.

A adoção das antecipações de necessidades de clientes no software geralmente

depende de decisões estratégicas da organização.

A comprovação da utilização de resultados da execução de ações de antecipação pode

ser obtida por meio de evidências que mostram, por exemplo, o desenvolvimento de alguma

funcionalidade no software.

Orientações

É necessário verificar se a organização executa ações de antecipação e de atendimento

às necessidades de clientes e como são realizadas. Algumas organizações trabalham com

equipes dedicadas à antecipação das necessidades dos clientes e têm um canal de

comunicação bem estabelecido com os clientes utilizado tanto para atender as necessidades

explícitas como para antecipar futuras necessidades. Outras organizações executam essas

ações, porém de modo informal.


que mostrem a execução de ações de antecipação e de atendimento às necessidades dos

clientes do software. É necessário identificar os colaboradores envolvidos nas atividades de

antecipação e de atendimento às necessidades dos clientes. É necessário encontrar os

desdobramentos e resultados gerados por essas atividades (registros, e-mail, documentação

do software, apresentações, ferramentas, etc).


• O atendimento das antecipações de necessidades de clientes refletido no

software.

• Existência de colaboradores na organização e/ou área estruturada para atuar nas

antecipações de mercado ou necessidades ainda não demandadas pelos clientes.

• Decisões de portfólio para atender tendências ou futuras necessidades de clientes

ou mercado.

• Ampliação do objeto dos contratos baseada em ações de antecipação de mercado.

• Existência de estratégia de comunicação na organização que demonstre a difusão

do conhecimento sobre antecipações de mercado ou futuras demandas dos

clientes. Exemplos: reuniões, comitês, conselhos, ferramentas de trabalho

específicas.

• Realização de pesquisa de satisfação com cliente e uso do resultado obtido para o

atendimento das necessidades de clientes.

GNE.4. Instrumentos para direcionar a evolução do negócio relacionado ao software são

definidos e realizados


233

A organização precisa ter um plano diretor que orienta a evolução do negócio e, mais

especificamente, do software e de seus serviços associados. Esse planejamento deve estar

baseado no resultado das ações de monitoramento de tendências de mercado executadas

para o software.

A partir de uma abordagem flexível e estruturada, e frequentemente gráfica, os

roadmaps são utilizados para alinhar temporalmente perspectivas externas (ambiente,

mercado, regulação) com internas (produtos, tecnologias, capacitações) e identificar gargalos e

oportunidades por meio da construção coletiva de uma visão e estratégia de longo prazo.

Identificam possíveis caminhos a serem perseguidos pelos projetos de Pesquisa,

Desenvolvimento e Inovação e apoiam o planejamento de estratégias para que capacitações

tecnológicas aproveitem oportunidades de mercado e para que gaps nos produtos e nos

mercados sejam previstos e superados. Também podem ser utilizados para avaliar impactos de

uma descontinuação de mercado.

Ferramentas que apoiam o planejamento estratégico, tais como, forecasting, foresight,

Delphi, cenários, balanced scorecard, SWOT, Quality Function Deployment - QFD, matriz de

inovação, análise bibliométrica, análise de citações, análise de patentes, dentre outras, podem

ser utilizadas para o desenvolvimento de uma estratégia tecnológica e podem refletir uma

prática de planejamento que direciona a evolução do negócio relacionado ao software de

maneira proativa.

Orientações

É necessário verificar se a organização utiliza ferramentas usuais para apoiar no

direcionamento estratégico do seu negócio.

Para que esse resultado esperado seja atendido é necessário identificar na organização

a utilização de ferramentas para apoiar o direcionamento estratégico e tecnológico do seu

negócio, relacionado ao software. É necessário identificar os direcionamentos tecnológicos

que foram implementados no software e o resultado que foi atingido. É necessário identificar

os colaboradores da organização envolvidos na gestão das informações fornecidas por essas

ferramentas e na implementação tecnológica decorrente dessa gestão.






• Roadmaps monitorados e realizados.

• Utilização de ferramentas de planejamento e gestão estratégicas para apoiar a

evolução tecnológica do negócio, relacionado ao software.

• Definição de metas para medir a evolução tecnológica do negócio gerado com o

desenvolvimento do software.

• Relatórios de acompanhamento de desempenho tecnológico do negócio,

resultante do desenvolvimento do software.


234

GNE.5. Ações para ampliação de negócios relacionados ao software são planejadas e

realizadas

Ações para ampliação de negócios, incluindo clientes atuais, ampliação da carteira de

clientes e inserção em novos mercados, relacionados ao software são identificadas, planejadas

e realizadas.

Orientações

É necessário verificar quais ações a organização executa para ampliar seus negócios

relacionados com o software. Algumas organizações têm equipes dedicadas e que executam

ações estruturantes para a conquista de novos mercados enquanto que outras organizações

executam ações para ampliação do seu negócio, de modo informal.


que mostrem a execução de ações para ampliação de negócios relacionados ao software. É

necessário identificar os colaboradores envolvidos na execução dessas ações. É necessário

encontrar os resultados gerados por essas ações.




• Prospecção de necessidades de clientes potenciais.

• Diversificação dos clientes (ampliação da carteira de clientes atendidos pela

mesma solução).

• Oferta do software, aos clientes da organização que ainda não adquiriram essa

solução.



• Financiamento junto a órgãos de fomento para colocar o software no mercado

alvo.

• Propostas comerciais feitas e encaminhadas para o mercado alvo (não

necessariamente aceitas).

• Contratos de licenciamento ou fornecimento de serviços aceitos pelos clientes.

• Comercialização conjunta - parcerias com outras organizações para inserir o

software em outros produtos.

• Participação em feiras, como expositor, na qual os clientes em potencial do

software estavam presentes.

• Distribuição de material de divulgação, impresso ou eletrônico, sobre o software e

as competências existentes na organização.


235

4.5 Área de competência Gestão de Parcerias e Alianças (GPA)

Pergunta-chave

Parcerias e alianças possibilitam geração de negócios, atualização tecnológica ou

desenvolvimento tecnológico, relacionados ao software?

Descrição

A Área de Competência “Gestão de Parcerias e Alianças” envolve a formação, operação e

avaliação de projetos e acordos de cooperação, tecnológica e comercial, entre a organização e

fornecedores, financiadores, instituições de ciência e tecnologia, universidades e outras

organizações privadas e públicas, que tenham como foco o software.

As parcerias e alianças podem ocorrer para desenvolver tecnologias, incorporar novas

competências e/ou promover o aprendizado de novos conhecimentos, aperfeiçoar e

desenvolver novas oportunidades para a organização em relação ao software, explorar

soluções inovadoras nesse software, obter novos recursos para ele, minimizar custos, superar

barreiras de mercado, criar economias de escala, criar valor a partir do compartilhamento de

recursos, posições, habilidades e conhecimento, promover um melhor posicionamento

estratégico, acessar um mercado, ampliar rentabilidade, atender a necessidades legais e

contratuais, licenciar tecnologias, etc. Qualquer dessas ações deve ter como foco o software.

A realização de parcerias e alianças envolve uma complexidade adicional na gestão da

organização. Sua execução de maneira sistematizada, coordenada e bem sucedida, pode

sinalizar não só a competência da organização em identificar e ocupar espaços potenciais de

expansão comercial e tecnológica, mas também a capacidade de definir seus próprios

objetivos estratégicos, que devem ser compatíveis com o de seus possíveis parceiros. A

organização deve, ainda, possuir uma imagem de confiança no mercado em relação ao

software.

A gestão de parcerias e alianças comerciais para um software sinaliza capacidades tais como

prospecção de novos negócios em toda a cadeia produtiva em questão, realização de análise

de custos de transação, gestão de contratos, desenvolvimento e condução de estratégia de

atuação em novos mercados, etc.

A gestão de parcerias e alianças tecnológicas para um software sinaliza capacidades tais como

a prospecção de tecnologias, seja por meio da participação de redes, gestão de equipes de

pesquisa e desenvolvimento, apropriação e transferência de conhecimento, gestão da

propriedade intelectual, etc.

Parcerias e alianças podem acontecer com organizações e/ou instituições estrangeiras, desde

que o resultado dessa atuação conjunta gere competências no País.


236

A coordenação, das diferentes parcerias e alianças para um software em uma organização

sinaliza um nível mais elevado de gestão estratégica dos negócios e tecnologia, representando

maior agregação de competências no País.



Parcerias e Alianças a Unidade Organizacional deve demonstrar que:

• GPA.1. Prospecções para novas parcerias e alianças relacionadas ao software são

realizadas.

• GPA.2. Parcerias e alianças relacionadas ao software são formalizadas para pesquisa e

desenvolvimento de tecnologia ou para atuação no mercado.

• GPA.3. A coordenação do conjunto de parcerias e alianças é realizada, incluindo a

gestão da execução, monitoramento de resultados e revisões.


GPA.1. Prospecções para novas parcerias e alianças relacionadas ao software são realizadas.

A prospecção para novas parcerias e alianças inclui a utilização de ferramentas e

práticas voltadas para a identificação de potenciais parceiros para desenvolvimentos

tecnológicos e promoção de negócios relacionados com o software. Pode incluir a

identificação de novas instituições para potenciais parcerias ou a identificação de novas

oportunidades com instituições parceiras da organização.

As parcerias e alianças para o desenvolvimento tecnológico de um software são

caracterizadas por interações da organização com outras organizações ou instituições de

ensino, ou instituições de ciência e tecnologia (ICTs) para o desenvolvimento conjunto, parcial

ou integral, de uma tecnologia presente no software.

As parcerias e alianças para a promoção de negócios de um software são

caracterizadas por contratos e convênios com fornecedores, distribuidores, agências de

fomento ou outras organizações para o fornecimento de um serviço ou insumo, recursos

financeiros ou acordos comerciais.

Orientações

Para que esse resultado esperado seja atendido é necessário identificar as ações de

prospecção para parcerias e alianças executadas pela Organização para o desenvolvimento

tecnológico e promoção de negócios do software. Essas ações podem estar refletidas em

registros de reuniões com organizações ou instituições de ensino, instituições de ciência e

tecnologia ou com entidades para promoção de negócios (fornecedores, distribuidores,

agências de fomento, entre outros) candidatas à realização de um trabalho conjunto para o

software.


237

Resultados gerados a partir da prospecção de parcerias e alianças realizadas pela

organização e reutilizados pelo software indicam a presença de uma cultura organizacional

voltada à atuação com parcerias e alianças.


• Existência de uma cultura organizacional voltada à prospecção de parcerias e

alianças.

• Existência de colaboradores na organização e/ou área estruturada que atuem na

prospecção de parceiros no desenvolvimento tecnológico e promoção de negócios

para o software.

• Documento impresso ou eletrônico que comprove a divulgação pública sobre

áreas de pesquisa de interesse da empresa com vistas à prospecção de parceiros

(open innovation)

• Utilização de práticas formalizadas ou ferramentas para prospecção de parcerias e

alianças para o desenvolvimento do software.

• Mapeamento ou monitoramento de organizações e/ou instituições de ensino,

instituições de ciência e tecnologia que atuem em áreas correlatas e/ou que

tenham competências complementares às da organização, para desenvolvimento

tecnológico conjunto no software.

• Mapeamento ou monitoramento de parceiros comerciais (fornecedores ou outras

organizações que atuem em áreas correlatas ou complementares), para promoção

de negócios do software.

• Participação em feiras e congressos relacionados ao software para prospecção de

parceiros tecnológicos e/ou parceiros de negócios.

• Estudos realizados internamente ou contratados de terceiros sobre organizações

e/ou ICTs, editais de financiamento (com parcerias) e parceiros comerciais.

• Contatos realizados com o intuito de firmar acordos, parcerias e alianças para o

desenvolvimento do software.

GPA.2. Parcerias e alianças relacionadas ao software são formalizadas para pesquisa e

desenvolvimento de tecnologia ou para atuação no mercado.

A existência de parcerias e alianças formalizadas para pesquisa e desenvolvimento de

tecnologia no software envolve a efetivação de contratos ou convênios com organizações e/ou

instituições de ensino, ou instituições de ciência e tecnologia (ICTs) que atuem em áreas

correlatas e/ou que tenham competências complementares às da organização para

desenvolvimento tecnológico conjunto. Incluem-se, aqui, projetos executados como parte da

estratégia corporativa e financiados com recursos próprios e projetos executados como parte

dos requisitos para usufruto dos benefícios de uma legislação específica, bem como aqueles

que sejam fruto de editais de agências de fomento ou bancos de desenvolvimento. Parcerias e

alianças podem também acontecer com organizações e/ou instituições de ensino estrangeiras

ou instituições de ciência e tecnologia estrangeiras, desde que o resultado dessa atuação

conjunta gere competências no País sobre o desenvolvimento tecnológico obtido na pesquisa.


238

A existência de parcerias e alianças formalizadas para atuação no mercado envolve a

efetivação de contratos ou convênios com fornecedores, distribuidores ou organizações

voltados para o fornecimento de serviços ou insumos, obtenção de recursos para financiar

investimentos ou acordos comerciais de outras naturezas, com o fim de promover os negócios

da organização relacionados com o software.

Outros tipos de alianças podem acontecer, tais como quando uma organização compra

outra organização, ou quando ocorre a fusão entre organizações. Esses tipos de alianças

podem resultar na ampliação da competência tecnológica ou na melhoria da colocação do

software no mercado.

Orientações

Para que esse resultado esperado seja atendido é necessário identificar as parcerias e

alianças tecnológicas e de mercado realizadas para o desenvolvimento conjunto do software. É

necessário encontrar a documentação legal que geriu os acordos ou contratos firmados com as

organizações parceiras. É necessário encontrar informações dos resultados obtidos pelo

software devido ao envolvimento de organizações parceiras.

Resultados gerados a partir de parcerias e alianças realizadas pela organização e

reutilizados no software indicam a presença de uma cultura organizacional voltada à atuação

com parcerias e alianças.


• Existência de colaboradores na organização e/ou área estruturada que atuem na

elaboração de propostas de projetos de parceria tecnológica ou de mercado para o

software.

• Contratos das parcerias realizadas com instituições de ensino, instituições de

ciência e tecnologia ou outras organizações, para desenvolvimento tecnológico

conjunto do software.

• Parcerias com universidades para captação de recursos humanos.

• Relações com os clientes para ampliar a visão sobre o negócio, de modo a permitir

que a organização antecipe uma necessidade ou mesmo atenda a uma demanda

percebida.

• Proposta de projetos em parceria que foi submetida para o desenvolvimento do

software.

• Documento que comprove parcerias como parte da estratégia da organização.

• Utilização de recursos da Lei de Informática, como caminho para a prática de

parcerias realizadas para o software.

• Uso de ferramentas para desenvolvimento colaborativo ou práticas formalizadas

de execução de parcerias e alianças utilizadas no desenvolvimento do software.

• Histórico de propostas de projetos de pesquisa e desenvolvimento ou

documentação relacionada à execução e aos resultados gerados pelos projetos

desenvolvidos em parcerias, para a geração do software.


239

• Histórico de propostas comerciais ou documentação relacionada à execução e aos

resultados gerados pelos serviços prestados por parceiros comerciais, no nicho de

mercado do software.

• Lista dos distribuidores do software.

• Contratos de fornecimento e distribuição do software.

• Contratos de venda do software realizados devido ao envolvimento de parceiros

no desenvolvimento ou no mercado.

• Contratos para obtenção de financiamento externo para o software.

• Acordos comerciais realizados para o software.

• Fusões e/ou aquisições entre organizações para que a organização se aproprie de

competências que não possui internamente.

GPA.3. A coordenação do conjunto de parcerias e alianças é realizada, incluindo a gestão da

execução, monitoramento de resultados e revisões.

A gestão de parcerias e alianças envolve o desenvolvimento de práticas e esforços

voltados para planejar e monitorar a execução e os resultados gerados pelas parcerias e

alianças. As parcerias e alianças podem ocorrer no âmbito do software ou os resultados

gerados pelas parcerias e alianças em outro contexto podem ser reutilizados pelo software.

Pode incluir a utilização de ferramentas de gestão de projetos e recursos humanos, bem como

a adoção de metodologias padrão ou métodos próprios desenvolvidos com este fim.

Orientações

Para que esse resultado esperado seja atendido é necessário identificar ações de

planejamento e acompanhamento executadas pela Unidade Organizacional com as parcerias e

alianças envolvidas com o software. Reuniões de acompanhamento periódico para verificar o

cumprimento das metas e objetivos estabelecidos, a análise das entregas pela organização

parceira, a definição de atividades de integração e a tomada de decisões para redirecionar o

trabalho conjunto são exemplos dessas ações. É necessário verificar a existência de pelo

menos um colaborador responsável pela gestão das entidades parceiras.

Resultados gerados a partir de parcerias e alianças realizadas pela organização em

outro contexto podem ser reutilizados pelo software. Nesse caso, a gestão passa a ser no

planejamento e monitoramento do reuso dos resultados e não mais nas entidades parceiras, o

que indiretamente indica a presença de uma cultura organizacional voltada à atuação com

parcerias e alianças.


• Realização de reuniões de acompanhamento periódico com as parcerias existentes

para o software.

• Relatórios de acompanhamento dos projetos desenvolvidos em parceria, para o

software.

• Área ou equipe responsável pela execução da gestão das alianças e parcerias

existentes para o software.


240

• Uso de ferramentas ou práticas formalizadas de gestão de parcerias e alianças, tais

como formulários específicos para alinhamento de expectativas quanto aos

produtos gerados pelas partes, prazos, atividades desenvolvidas pelas equipes,

serviços prestados e resultados obtidos.

• Análise geral sobre o registro de informações sobre os projetos: recursos

financeiros investidos (valores e fonte), período de execução, resultados gerados,

avaliações sobre a interação e sobre a instituição parceira.

• Documentos que permitam análises sobre a evolução dos recursos investidos em

parcerias para promoção de negócios.


241

4.6 Área de competência Gestão de Pessoas, Processos e

Conhecimento (PPC)

Pergunta-chave

Pessoas, processos e conhecimento são gerenciados para apoiar e potencializar negócios e o

desenvolvimento tecnológico do software?

Descrição

Esta área de competência abrange um conjunto de atividades, coerentes entre si, que apoiam

e potencializam de forma integrada as outras áreas de competências.

Gestão de Pessoas inclui a adoção de práticas para o software voltadas à administração,

capacitação e motivação de seus recursos humanos, buscando continuamente a melhoria das

relações interpessoais que contribuam com a constante melhoria do processo produtivo da

organização, gerando crescimento, potencialização de negócios e desenvolvimento

tecnológico no País, tornando a organização competitiva e atrativa para investimentos.

Gestão de processos inclui a avaliação e melhoria contínua dos processos relacionados ao

software.

Gestão de Conhecimento inclui a identificação, criação, renovação e aplicação dos

conhecimentos que são estratégicos na vida de uma organização. É a administração dos ativos

de conhecimento das organizações. Permite à organização explicitar e organizar o que seus

colaboradores sabem.

A Gestão do Conhecimento tem por objetivo assegurar que toda informação, conhecimento e

habilidade relevantes sejam coletados, compartilhados, reutilizados e melhorados, por toda a

organização.

Gestão do Conhecimento tratada por essa área de competência inclui a identificação,

documentação, disseminação e atualização do conhecimento mais relevante sobre as

tecnologias, os domínios de aplicação, os negócios, e outros aspectos relacionados ao

software.

Este modelo enfatiza ações e estratégias da organização relacionadas com o uso da memória

organizacional (documentação do conhecimento) para a capacitação das pessoas, nas

tecnologias desenvolvidas no software.

No geral, organizações comprometidas com o desenvolvimento e fortalecimento do software

(criação de negócios baseados em conhecimento e aumento de autonomia tecnológica)

buscam a retenção de conhecimento e comprovação de propriedade intelectual, redução de

riscos na contratação com o poder público, maior facilidade no atendimento das mudanças da


242

legislação, maior capacidade de sobrevivência em relação aos impactos financeiros e, redução

de riscos de investimentos e contratações (atração de investidores e parceiros).

A contratação de colaboradores em organizações de serviços é voltada para o atendimento

dos clientes, sendo comum a contratação irregular dos trabalhadores (preferência na redução

de custos das contratações, com adoção de práticas ilegais – terceirizações ilícitas, CLT-Flex)

objetivando reduzir o custo da operação para atendimento aos clientes e obtenção de preços

competitivos. Com isto, existe rotatividade de prestadores de serviços; dificuldade de

comprovação de origem e propriedade intelectual do software desenvolvido; desvalorização

patrimonial da organização (aumento de passivos); e atuação contrária à legislação vigente e

risco de autuação administrativa e judicial que possam inviabilizar a continuidade das

atividades empresariais gerando fragilidade da organização empresária e aumento no risco de

investimentos.



Pessoas, Processos e Conhecimento a Unidade Organizacional deve demonstrar que:

• PPC.1. Colaboradores com perfil adequado são contratados, alocados e incentivados

para realizar atividades relacionadas ao software.

• PPC.2. Equipes são formadas e coordenadas para realizar de forma eficiente e eficaz

atividades relacionadas ao software.

• PPC.3. Treinamentos ou outros mecanismos de aprendizagem são identificados e

realizados pelos colaboradores para melhorar suas habilidades e conhecimentos

relacionados ao software.

• PPC.4. O conhecimento gerado nas atividades tecnológicas e de negócio relacionado

ao software é documentado, disseminado e atualizado.

• PPC.5. Melhorias nos processos das atividades tecnológicas e correlatas relacionadas

ao software são identificadas, definidas e realizadas.


PPC.1. Colaboradores com perfil adequado são contratados, alocados e incentivados para

realizar atividades relacionadas ao software.

As atividades relacionadas ao software são realizadas por pessoas qualificadas. Estas

pessoas foram contratadas pela organização e posteriormente alocadas para a execução de

atividades relacionadas ao software. Estas pessoas são gerenciadas para manter e melhorar as

condições e os incentivos para realização destas atividades.

Orientações

Para que esse resultado esperado seja atendido é necessário verificar quais ações

foram realizadas antes da alocação dos colaboradores em atividades relacionadas ao software.

É necessário encontrar informações sobre a seleção de profissionais com perfis adequados,


243

realização de ações de engajamento desses profissionais na equipe de trabalho e o

comprometimento deles na execução das atividades relacionadas ao software.


• Seleção de novos colaboradores qualificados para atuação nas atividades


• Número de colaboradores contratados no regime da CLT: Indicador de que a

propriedade intelectual do software desenvolvido por seus colaboradores, no

âmbito do contrato de trabalho, pertence à organização (colaborador contratado

para atividades específicas de natureza contínua e prazo indeterminado).

• Contratos de trabalho firmados e executados no Brasil: comprovação de origem da

tecnologia desenvolvida (normas aplicáveis aos contratos de trabalho => as do

local da prestação dos serviços – princípio da “lex loci executinis”).

• Formalização de Planos de Gestão e Capacitação dos Recursos Humanos com

contínua atualização e investimentos.

• Política ou programas de premiação definidos e em execução.

PPC.2. Equipes são formadas e coordenadas para realizar de forma eficiente e eficaz

atividades relacionadas ao software.

Atividades relacionadas ao software são realizadas por equipes. Estas equipes devem

ser coordenadas para estabelecer grupos que realizam de forma eficiente e eficaz as atividades

previstas. A eficiência diz respeito a como realizar as atividades e está relacionada às ações a

serem realizadas, definidas em nível operacional. Busca otimizar o custo-benefício, ou seja, ter

o mínimo de perdas e/ou desperdício na relação entre os resultados obtidos e os recursos

empregados. Já a eficácia está relacionada ao nível tático e diz respeito a fazer o que deve ser

feito, realizar o que foi proposto, ou seja, cumprir as metas definidas.

Orientações

Para que esse resultado esperado seja atendido é necessário identificar: as equipes de

trabalho que atuaram no desenvolvimento do software; os resultados que as equipes de

trabalho alcançaram frente aos objetivos estabelecidos (prazo, custo, tratamento do escopo,

grau de satisfação dos clientes, entre outros); as ações realizadas pela organização responsável

pelas equipes para apoia-las no cumprimento das atividades planejadas, tais como ações

motivacionais, de gestão, administração de conflitos, investimentos, parcerias, entre outros; as

ações de contorno que foram executadas e os resultados obtidos frente aos recursos

empregados.


• Mudança ocorrida no organograma ou em outros mecanismos de registro das

relações existentes na organização para melhorar os resultados gerados pelas

equipes de trabalho.

• Estratégia utilizada na formação das equipes envolvidas no desenvolvimento do

software, o resultado alcançado com essa estratégia, os sucessos, as dificuldades e

as mudanças que foram necessárias.


244

• Registros de atividades em grupo, com indicação de como elas foram organizadas

para melhorar o resultado a ser obtido frente ao alcance pretendido.

• Acompanhamento das metas ou objetivos definidos para o resultado a ser obtido

pelas equipes envolvidas no desenvolvimento do software.

PPC.3. Treinamentos ou outros mecanismos de aprendizagem são identificados e realizados

pelos colaboradores para melhorar suas habilidades e conhecimentos relacionados ao

software

Treinamentos ou outros mecanismos de aprendizagem, tais como mentoring,

coaching, ensino a distância, entre outros, são em geral utilizados como forma de desenvolver

ou aprimorar a competência dos colaboradores. Visando melhorar as habilidades e o

conhecimento dos colaboradores em relação ao software, treinamentos e outros mecanismos

de aprendizagem devem ser identificados, desenvolvidos internamente ou adquiridos

externamente e realizados.

Orientações

As organizações devem estar preocupadas com o desenvolvimento e aprimoramento

das competências de seus colaboradores. Para tal, devem prover treinamentos ou outros

mecanismos de aprendizado.

Para que esse resultado esperado seja atendido é necessário verificar quais ações

foram realizadas para a geração de competências nos colaboradores envolvidos no

desenvolvimento do software. É necessário encontrar a identificação de treinamentos ou

outros mecanismos de aprendizado necessários e dados da sua realização.

Treinamentos relacionados ao software podem ser ministrados por recursos internos

da organização ou ministrados por outras empresas contratadas. Deve ser verificado se os

colaboradores treinados foram capazes de aplicar os conhecimentos adquiridos nas atividades



• Política ou diretrizes de treinamento da organização.

• Formalização de Planos de Gestão e Capacitação dos Recursos Humanos com

contínua atualização e investimentos.

• Identificação, desenvolvimento ou aquisição e realização de treinamentos

relacionados ao software.

• Avaliações da efetividade dos treinamentos realizados, relacionados ao software.

• Disseminação do conhecimento formalizada ou processo de disseminação do

conhecimento definido. Por exemplo: rodízio de desenvolvedores pelos grupos,

desenvolvimento em dupla de programadores, treinamento on the job.

• Treinamento dos colaboradores no uso do Sistema de Ativos de Conhecimento da

organização para que sejam capazes de extrair informações relacionadas ao

software para aprendizado.


245



A gestão do conhecimento inclui a identificação, documentação, disseminação e

atualização do conhecimento mais relevante sobre as tecnologias, os domínios de aplicação, os

negócios, e outros aspectos relacionados ao software.

Orientações

Algumas organizações utilizam ferramentas formais para a gestão do conhecimento.

Outras organizações não utilizam tais ferramentas, mas executam ações para garantir que os

conhecimentos tecnológicos e de negócios gerados no desenvolvimento do software, sejam

agregados na organização.

Para que esse resultado esperado seja atendido é necessário verificar como os

conhecimentos tecnológicos e de negócios gerados com o desenvolvimento do software foram

identificados, documentados e disseminados na organização. Quando a organização utiliza

ferramentas formais para apoiar a gestão do conhecimento, as informações nelas registradas

devem estar atualizadas, os colaboradores devem estar capacitados e motivados no uso de

tais ferramentas e informados sobre novos registros ou atualizações efetuadas. Nas

organizações onde não ocorre o uso de ferramentas formais, outras estratégias devem ser

definidas e praticadas para garantir que o conhecimento tecnológico gerado permaneça na

organização. São exemplos dessas estratégias: Levantamento, registro e divulgação de lições

aprendidas (positivas ou negativas) percebidas durante o desenvolvimento do software;

documentação e divulgação das tecnologias relevantes e estratégicas para o software;

É necessário identificar os colaboradores capacitados da organização envolvidos com a

gestão do conhecimento e o que fazem com a documentação do conhecimento. Ex.: coletas,

compartilhamento de informações, ações de motivação para reuso e aperfeiçoamento dos

conhecimentos, por toda a organização.


• Política interna da organização ou diretrizes para que os registros das informações

tecnológicas e correlatas relacionadas ao software sejam formalizados e utilizados.

• Processo de registro de informações definido.

• Sistema de Gestão dos Ativos de Conhecimento com uma infraestrutura e um

mecanismo para apoiar as atividades de identificar, classificar, trocar e utilizar

ativos de conhecimento, em operação na organização.

• Informações tecnológicas e correlatas relacionadas ao software documentadas no

Sistema de Gestão dos Ativos do Conhecimento e utilizadas na organização.

• Realização de comunicação sobre atualizações executadas na "documentação do

conhecimento".

• Conhecimento, informação e habilidades individuais desenvolvidas na execução de

atividades tecnológicas e correlatas relacionadas ao software coletados,

compartilhados, reutilizados e aperfeiçoados por toda a organização.


246

• Treinamento na operação do sistema (classificação dos ativos e critérios) para

administradores e usuários dos ativos de conhecimento da organização.

PPC.5. Melhorias nos processos das atividades tecnológicas e correlatas relacionadas ao

software são identificadas, definidas e realizadas.

O foco desse resultado esperado é verificar se: na execução das atividades

tecnológicas e correlatas relacionados ao software são seguidos processos documentados; se

esses processos são analisados para identificar problemas e oportunidades de melhoria; e se, a

partir dessa identificação, as melhorias são definidas e realizadas.

Melhoria de processo deve ser uma atividade contínua. Independentemente da metodologia

utilizada e da maturidade do processo, oportunidades e incentivos para sugestões e

implementações de melhoria devem ser estabelecidos e mantidos.

Orientações

Algumas organizações têm equipes dedicadas e responsáveis pela execução de ações

de melhoria dos seus processos produtivos enquanto que outras organizações executam tais

ações de modo informal. As duas situações devem ser consideradas.

É necessário verificar se existem processos minimamente documentados, se foram

executadas ações para melhoria dos processos relacionados ao software e qual é o operacional

para a melhoria de processos.


que mostrem a existência de processos minimamente documentados e que foram executados

pelos colaboradores envolvidos no desenvolvimento do software. É necessário encontrar

melhorias sugeridas para esses processos. É necessário encontrar os resultados gerados a

partir dessas melhorias. É necessário identificar os colaboradores envolvidos na execução

dessas melhorias.

Nota: só ter colaboradores que conhecem sobre a execução dos processos, sem que

esses processos estejam minimamente documentados, não é suficiente para que esse

resultado esperado seja atendido.


• Processos documentados praticados nas atividades tecnológicas e correlatas, que

estejam relacionados ao software.

• Oportunidades de melhoria de processo identificadas durante a execução das

atividades tecnológicas e correlatas que estejam relacionadas ao software.

• Análises sobre os processos correntes na organização e os seus resultados

orientando o investimento em melhoria de processo.

• Melhorias de processo selecionadas, desenvolvidas, implementadas e divulgadas

aos colaboradores da organização.

• Utilização dos resultados da pesquisa de satisfação dos clientes para melhoria de

processos correntes na organização.


247

5. Método de Avaliação CERTICS

O Método de Avaliação CERTICS orienta a realização de uma avaliação de um determinado

software e seus serviços associados, tendo como referência o Modelo para Avaliação CERTICS.

O objetivo da avaliação é determinar se o software é ou não um software com tecnologia

desenvolvida no País, com base na análise de evidências objetivas relacionadas ao software.

A avaliação é realizada por uma equipe de avaliadores credenciada para aplicação do Método

de Avaliação CERTICS, com conhecimento, treinamento e experiência relevantes, sob a

liderança de um avaliador líder.

Para a gestão e o armazenamento dos artefatos utilizados e produzidos durante a avaliação é

utilizado o Sistema de Apoio à Avaliação (SAA).

Uma avaliação gera como resultado principal um Laudo da Avaliação com informações sobre o

contexto da avaliação, a pontuação do grau de atendimento dos requisitos do modelo, a

justificativa para cada pontuação e a conclusão.

5.1 Termos e definições

Instituição Credenciada para Avaliação: Instituição credenciada pelo CTI Renato Archer a

realizar avaliações segundo a Metodologia CERTICS. Para realizar uma avaliação a

instituição também tem que contar com avaliadores capacitados e credenciados.

Instituição Responsável pela Metodologia: instituição que controla o desenvolvimento,

monitoramento e melhoria contínua da Metodologia CERTICS para Software. Esta

instituição é o Centro de Tecnologia da Informação Renato Archer (CTI).

Organização Solicitante: Uma organização sediada no Brasil que tenha um Software para ser

avaliado.

Sistema de Apoio à Avaliação (SAA): um sistema de software projetado para prover suporte às

diversas etapas de um processo de avaliação. No modo de edição, o SAA permite as operações

de cadastro, alteração, validação, exibição e remoção de evidências. Este sistema fornece

apoio para a gestão da avaliação, permite o armazenamento e o compartilhamento das

informações e evidências relevantes para a avaliação, apoia a comunicação entre as

organizações e pessoas envolvidas, e registra os resultados da avaliação.

Unidade de Avaliação: organização que administra e realiza as avaliações de acordo com a

Metodologia CERTICS para Software. Promove e assegura o credenciamento dos

avaliadores, que podem ser membros do seu próprio corpo funcional ou fornecidos por


248

Instituições Credenciadas especificamente para esta finalidade. Negocia a avaliação com a

Organização Solicitante, designa a equipe de avaliação e seu líder, conduz a avaliação e produz

o Relatório Final da Avaliação.

Unidade Organizacional: Conforme definido na Seção 2 do Modelo para Avaliação CERTICS, “é

o conjunto de processos para todos os aspectos do software e seus serviços associados”. É a

parte integrante da Organização Solicitante responsável pelos diversos aspectos do software

em avaliação. Ela fornece os detalhes e as evidências do software que serão analisados

durante a visita de avaliação e servirão para determinar o resultado da avaliação. Usualmente

inclui a equipe de desenvolvimento do software e se engaja ativamente na visita de avaliação,

contribuindo para o seu sucesso, fornecendo ou buscando as informações e os recursos que

forem necessários.

5.2 Papéis e responsabilidades

Patrocinador da Avaliação: representante da Organização Solicitante com cargo de direção

apropriado para garantir os recursos necessários à avaliação e demandar o atendimento dos

seus objetivos. O patrocinador deve ter a autoridade necessária para garantir que recursos e

competências adequados sejam disponibilizados quando necessários, para que uma avaliação

possa ser realizada em conformidade com a Metodologia CERTICS para Software. São

exemplos de recursos relevantes solicitados pela equipe de avaliação: pessoas-chave para

entrevistas, infraestrutura durante a avaliação e artefatos a serem examinados.

Participantes da Avaliação: são os colaboradores da Organização Solicitante que podem

fornecer informações sobre o software sendo avaliado e se envolvem com a avaliação, estejam

eles diretamente ligados ao desenvolvimento do software ou não. Entre estes colaboradores

estão:

• Responsáveis pelo software: integrantes da organização que são os responsáveis

maiores pelo software.

• Equipe de gerência do desenvolvimento: pessoas que tiveram, ou ainda têm, papel

gerencial no desenvolvimento do software, isto é, participaram de planejamento,

coordenação e controle das atividades.

• Equipe técnica de desenvolvimento: pessoas que participaram, ou participam, de

atividades técnicas de desenvolvimento ou customizações, tais como: atividades de

captura de requisitos, análise de requisitos, projeto (design) de software, projeto

(design) de bancos de dados, programação, testes, integração de software e

eventualmente outras cujo objetivo tenha sido elaborar elementos que integram o

software.

• Equipe de apoio ao desenvolvimento: pessoas que participaram, ou participam, de

atividades consideradas auxiliares ou de apoio ao desenvolvimento, tais como:

elaboração de documentação e manuais, atividades de gerência de configuração,

atividades de revisão, tanto de documentos como de código e outros elementos do

desenvolvimento, garantia da qualidade, etc.


249

• Equipe de suporte técnico do software: pessoas que participam de atividades de

apoio ao usuário do software, tais como: solução de dúvidas, prestação de

esclarecimentos sobre a operação do software, orientação de utilização, recebimento

e identificação de problemas e falhas do software, etc.

• Equipe de manutenção do software: pessoal que executa as atividades que mantêm o

software atendendo às necessidades para as quais ele foi desenvolvido, tais como:

remoção de defeitos identificados, introdução de novas funcionalidades e realização

de melhorias gerais.

Ponto de Contato: um representante da Unidade Organizacional encarregado de facilitar e

concentrar a comunicação entre as organizações e pessoas participantes da avaliação,

engajando-se em providenciar os recursos que forem necessários, remover os obstáculos,

acionar o que for preciso, tomar ou escalar decisões, etc.

Avaliador Líder: é o membro da equipe de avaliação responsável por liderar a avaliação, por

garantir que ela atinja sua finalidade e esteja em conformidade com a Metodologia

CERTICS para Software. É um Avaliador credenciado para atuar como Avaliador Líder.

Este Avaliador pode estar relacionado à Unidade de Avaliação ou a uma Instituição

Credenciada para Avaliação. O avaliador líder deve:

• Confirmar o comprometimento do patrocinador para realizar a avaliação;

• Garantir que a avaliação seja conduzida de acordo com a Metodologia CERTICS

CERTICS para Software;

• Garantir que os participantes da avaliação sejam informados sobre o propósito, o

escopo e a abordagem da avaliação;

• Garantir que todos os membros da equipe de avaliação tenham sido previamente

credenciados;

• Garantir que todos os membros da equipe de avaliação tenham acesso às orientações

documentadas e apropriadas sobre como executar as atividades da avaliação;

• Garantir a inexistência de relações de hierarquia entre entrevistados durante a

realização de entrevistas coletivas;

• Na conclusão da avaliação, verificar e documentar a extensão de conformidade da

avaliação com a Metodologia CERTICS para Software;

• Confirmar o recebimento, pelo patrocinador, do resultado da avaliação que foi

encaminhado.

Avaliador: colaborador relacionado à Unidade de Avaliação ou a uma Instituição Credenciada

para Avaliação (por solicitação da Unidade de Avaliação) que, conjuntamente com o Avaliador

Líder, vai administrar e efetivamente realizar a avaliação, compondo a Equipe de Avaliação e

visitando a Organização Solicitante.

Equipe de Avaliação: Equipe formada pelo Avaliador Líder e um ou mais Avaliadores.

Validador da Avaliação: um colaborador da Unidade de Avaliação, avaliador credenciado, que

não tenha participado de uma determinada avaliação e seja encarregado de verificar se esta

avaliação foi conduzida adequadamente, em conformidade com a Metodologia CERTICS

para Software, encarregando-se também por validar o resultado final da avaliação.


250

Responsável pela Unidade de Avaliação: um colaborador da Unidade de Avaliação

responsável por todo o processo de avaliação e ponto de contato com o CTI.

Responsável pela Metodologia: Um Grupo de Trabalho do CTI responsável pela emissão do

Laudo de Avaliação e pelo controle do desenvolvimento, monitoramento e melhoria contínua

da Metodologia CERTICS para Software.

5.3 Notação da descrição do Método

O Método de Avaliação CERTICS está descrito na notação visual para representação de fluxos

de processos BPMN (Business Process Modeling Notation) com detalhamento de cada fase e

atividade que o compõe. Cada atividade está descrita com uma visão geral dos seus objetivos e

a relação dos principais papéis envolvidos na atividade. É importante ressaltar que cada

atividade tem um único papel designado como responsável por assegurar que ela seja bem

sucedida e que atinja seus objetivos.

5.4 Fases do Método de Avaliação

O Método de Avaliação CERTICS se compõe de cinco fases sequenciais:

Figura 3 – Fases do método de avaliação

As fases do Método de Avaliação CERTICS estão descritas a seguir e ilustradas com diagramas

da notação do processo. Cada fase é composta por um conjunto de atividades.


251

Figura 4 – Diagrama do método de avaliação

5.4.1 Fase 1: Exploração

Esta fase contempla os passos iniciais de uma avaliação, em que uma organização interessada

em que um software seu seja avaliado, registra uma solicitação no SAA, obtém informações

sobre o processo de avaliação, inicia o fornecimento de informações relevantes sobre a

própria organização e sobre o software no SAA, e decide prosseguir ou não com a avaliação.

Figura 5 – Diagrama da fase Exploração

As quatro atividades que compõem esta fase estão relacionadas e descritas a seguir, todas

conduzidas pela Organização Solicitante.

Atividade A.1.1: Solicitação de Avaliação

Uma Organização Solicitante registra no SAA uma solicitação de avaliação para um

determinado software, recebendo uma identificação de usuário e uma senha para prosseguir


252

acessando o sistema. Nesta atividade é produzido um Termo de Confidencialidade indicando

que a Unidade de Avaliação assume o compromisso de utilizar as informações fornecidas no

SAA estritamente para a realização da avaliação, não sendo utilizadas para qualquer outra

finalidade. Em resposta ao Termo de Confidencialidade, a Organização Solicitante reconhece

seu recebimento e expressa concordância com seus termos. O Patrocinador designa um

colaborador para exercer o papel de Ponto de Contato para a avaliação.

Responsável pela atividade: Patrocinador da Avaliação

Outros participantes da atividade: Ponto de Contato

Atividade A.1.2: Informações Iniciais

Uma vez registrado o usuário, ele pode obter mais informações sobre o processo de avaliação,

relativas à aplicação da Metodologia CERTICS para Software, sobre os recursos e

informações que deverão ser disponibilizados, sobre como se conduz a visita de avaliação, etc.

Nessa atividade o SAA solicita e valida um conjunto inicial de informações, incluindo:

a) Informações cadastrais da Organização Solicitante

Devem ser fornecidos dados sobre a Organização Solicitante da avaliação do software e seus

serviços associados.

Nome da Organização Solicitante:

Razão Social:

CNPJ:

Origem do capital da organização:

Tipo de organização:

( ) Empresa privada

( ) Empresa pública

( ) Instituição privada de ciência e tecnologia

( ) Instituição pública de ciência e tecnologia

Endereço:

Ano de fundação da Empresa no Brasil:

Número de colaboradores:

Faturamento no último ano fiscal:

Organograma:


253

Nome do Patrocinador da Avaliação:

Devem ser informados no SAA, os dados do Ponto de Contato responsável pelo fornecimento

das informações cadastrais da Organização Solicitante da avaliação.

Nome :

Endereço:

Telefone: Celular: Email:

Cargo/função na organização:

b) Informações cadastrais sobre o Software e seus Serviços associados

Devem ser fornecidas informações sobre as características do software e seus serviços

associados para o qual está sendo solicitada a avaliação.

Identifique o software a ser avaliado:

Nome:

Versão:

Indique o responsável pelo software e seus serviços associados:

Área responsável pelo software e seus serviços associados:

Nome do responsável pelo software e seus serviços associados:

Endereço:



Informe as seguintes características sobre o software a ser avaliado

- Domínio de Aplicação: administração de recursos humanos, administração de

serviços, administração escolar, administração jurídica, automação bancária, automação

comercial, educação à distância, contabilidade, geoprocessamento, segurança da informação,

outros (informe qual).

- Usuários potenciais: administração privada, administração pública, agropecuária,

bancário, comércio, educação, entretenimento, indústria, financeiro, meio ambiente, saúde,

serviços, transportes, turismo, outros (informe qual).

Indique as plataformas-alvo (ex.: plataforma Windows, Unix, etc.) e recursos de ambiente

necessários para a correta execução do software (exemplo: gerenciador de banco de dados,

processador de texto, gerenciador de mail, etc.):


254

- Plataformas-alvo:

- Recursos de ambiente necessários para correta execução do software:

Informe o principal aspecto tecnológico presente na solução do software:

Informe o principal diferencial inovador da solução presente no software:

Informe as datas de início do projeto referente ao software a ser avaliado e a data de liberação

do software para uso (comercialização ou uso interno):

Data de início do projeto:

Data de liberação para uso:

Sobre o “tamanho/complexidade” do software, informe um indicador e sua unidade (Ponto de

função, Número de módulos, Número de funcionalidades, ou outra):

Identifique os serviços associados ao software a ser avaliado, se houver. Para cada serviço,

descreva o escopo.

- Serviço 1:

Escopo do Serviço:

- Serviço 2:

Escopo do Serviço:

Esta atividade é concluída com o aceite pelo SAA do conjunto de informações preenchidas na

solicitação de avaliação.

Responsável pela atividade: Ponto de Contato

Atividade A.1.3: Edição de Evidências

A partir do aceite da solicitação de avaliação, o SAA permite editar o conjunto de evidências,

composto pela identificação e por informações sobre evidências objetivas para cada resultado

esperado do modelo. São fornecidas apenas identificações e descrições das evidências, não

sendo fornecidos ou anexados os próprios documentos ou arquivos das evidências.

Esta edição é feita por meio de três cadastros e seus relacionamentos: Cadastro de

Colaboradores, Cadastro de Evidências e Cadastro de Relacionamentos entre Resultados

Esperados e Evidências, conforme descrito a seguir:

a) Colaboradores relacionados ao software e seus serviços associados


255

Devem ser cadastrados os dados de identificação, contato e a contribuição dada por cada um

dos colaboradores que estiveram envolvidos nas diferentes etapas do ciclo de vida do software

e seus serviços associados.

Nome:

Endereço:


Área (divisão) de atuação na organização:


Contribuição para o software:

Contribuição para os serviços associados:

Permanece na organização? (sim/não).

b) Evidências sobre o ciclo de vida do software e seus serviços associados.

Devem ser cadastrados os nomes das evidências geradas pelos processos do entorno do

software e seus serviços associados, que respondem aos objetivos dos resultados esperados

do modelo e que nortearão a realização de uma avaliação preliminar. Não será permitido

anexar documentos relacionados às evidências. A análise do conteúdo dos documentos

relacionados às evidências cadastradas e outras evidências adicionais será realizada

presencialmente, na visita da equipe de avaliação, se a organização solicitante for considerada

apta para fase de visita de avaliação prevista no método.

Para cada evidência cadastrada deve ser associado um ou mais colaboradores (cadastrados

anteriormente) que estiveram envolvidos na geração da evidência.

Nome da evidência:

Descrição:

Colaboradores associados (e grau de envolvimento) à geração da evidência:

c) Associação das Evidências aos Resultados Esperados

Devem ser indicadas as evidências cadastradas que estejam relacionadas aos objetivos dos

resultados esperados, e justificar essa relação.

Não é necessário relacionar todas as evidências para um dado resultado esperado; é possível

que uma ou mais evidências cadastradas não estejam relacionadas a nenhum dos resultados

esperados.


256

Devem ser relacionadas no mínimo uma e no máximo quatro evidências para cada resultado

esperado.

A Figura a seguir ilustra um exemplo com os três cadastros e os relacionamentos.

Figura 6 – Exemplo dos três cadastros e relacionamentos

Descrição do exemplo: dois colaboradores estão cadastrados, com os dados necessários. Uma

evidência indicada por #12 está cadastrada, com uma descrição sobre ela, e para esta

evidência é indicado que o colaborador identificado por #32 atuou/conhece largamente esta

evidência e a colaboradora #72 atuou/conhece parcialmente esta evidência. Para o resultado

esperado DES.1, esta evidência é relacionada indicando que ela evidencia o atendimento do

resultado esperado.

Esta atividade é concluída com o envio do conjunto de evidências e o aceite pelo SAA. O aceite

é dado se forem fornecidas identificação e informações sobre evidências objetivas para pelo

menos 50 % dos resultados esperados do modelo.

Responsável pela atividade: Ponto de Contato

Atividade A.1.4: Decisão sobre a Avaliação

Concluídas as atividades anteriores e com maior conhecimento sobre o processo de avaliação,

a Organização Solicitante deve analisar se atende às condições necessárias para realizar uma

avaliação e decidir se seria mesmo o momento adequado para se engajar ou não na realização

de uma avaliação. Caso a decisão seja não realização da avaliação, o processo é encerrado.

Caso contrário é iniciada a execução da Fase 2 do Método de Avaliação CERTICS.

Responsável pela atividade: Patrocinador da Avaliação

Outros participantes da atividade: Ponto de Contato

5.4.2 Fase 2: Preparação


257

Esta fase contempla as interações entre a Organização Solicitante e a Unidade de Avaliação,

antes da avaliação propriamente dita ser iniciada, momento no qual é negociado um contrato

entre elas, é designado um avaliador credenciado e experiente como Avaliador Líder, são

identificados os recursos, as pessoas e as evidências que serão requeridos durante a visita de

avaliação (Fase 3 do Método de Avaliação CERTICS) e um Plano da Avaliação é elaborado de

comum acordo entre as partes envolvidas.

Seu objetivo principal é assegurar que a Organização Solicitante e a Unidade de Avaliação

negociem e estabeleçam as condições para que uma visita de avaliação possa ser realizada de

forma rápida e eficaz, em conformidade com a Metodologia CERTICS para Software.

Figura 7 – Diagrama da fase Preparação

Esta fase é composta por cinco atividades que estão relacionadas e descritas a seguir.

Atividade A.2.1: Estabelecimento de Contrato

A partir do aceite do Conjunto de Evidências, serão tratadas todas as questões necessárias

para se construir um acordo para a avaliação. Esta atividade inclui contatos entre o

Responsável pela Unidade de Avaliação (ou alguém designado por ele) e o Patrocinador da

Avaliação para estabelecer um Contrato para a realização da Avaliação. Este contrato

documenta a escolha e comprometimento do Avaliador Líder e outros membros da equipe de

avaliação. O Avaliador Líder e o Avaliador da Equipe de Avaliação serão da Unidade de

Avaliação ou de uma Instituição Credenciada para Avaliação. São estabelecidos também os

objetivos da avaliação, incluindo a decisão sobre a avaliação ser seguida pela emissão de

certificado pelo MCTI caso o resultado da avaliação seja positivo, ou se o interesse da

Organização Solicitante é apenas pelo resultado da avaliação sem a emissão do certificado. Um

contrato para a avaliação é estabelecido, estipulando as condições para a realização da

avaliação bem como o fechamento do Plano da Avaliação.

Responsáveis pela atividade: Responsável pela Unidade de Avaliação

Outros participantes da atividade: Patrocinador da Avaliação, Ponto de Contato, Avaliador

Líder e Avaliador


258

Atividade A.2.2: Análise e Edição de Evidências

A partir do estabelecimento do contrato, análises sobre a pertinência do tipo de evidências

fornecidas são realizadas pela equipe de avaliação. Caso essas evidências não sejam

consideradas satisfatórias para a realização da avaliação, a equipe poderá solicitar informações

ou detalhes adicionais sobre as evidências à Organização Solicitante, dentro de um prazo

previamente estipulado. Durante este prazo podem ocorrer interações com a organização,

bem como revisões e complementações das informações fornecidas. Esta análise deve

fornecer base à equipe para a realização da avaliação. Esta atividade pode ser conduzida em

paralelo à próxima.

Responsáveis pela atividade: Avaliador Líder

Outros participantes da atividade: Equipe de Avaliação e Ponto de Contato

Atividade A.2.3: Preparação para a Visita

A partir da análise das informações sobre o software e do conjunto de evidências inseridos no

SAA, a equipe de avaliação tem condições de preparar a visita de avaliação. Pode ser

necessário manter contatos com a Organização Solicitante para esclarecer alguns pontos

duvidosos ou para solicitar evidências adicionais.

Após as interações que se mostrarem necessárias, para complementações de informações

faltantes, esclarecimentos de dúvidas, ajustes de expectativas, negociações de datas, entre

outras, esta atividade é concluída com o estabelecimento do Plano da Avaliação, que contém

no mínimo as seguintes informações:

• Identificação e informações da Organização Solicitante

• Identificação e informações do Patrocinador da Avaliação

• Identificação e informações do software a ser avaliado

• Identificação e informações da Unidade Organizacional

• Identificação da Equipe de Avaliação

• Agenda para a realização da avaliação

• Assinatura dos responsáveis pela organização e pela equipe de avaliação para

evidenciar o acordo

Com base no conteúdo do Plano da Avaliação, a Organização Solicitante deve se preparar para

a realização da avaliação. Ela deve estar ciente de como funciona o processo de avaliação,

assim como das providências que deve tomar, tais como quais pessoas e recursos devem ser

disponibilizados para assegurar que a visita de avaliação seja bem sucedida.

Responsável pela atividade: Avaliador Líder

Outros participantes da atividade: Avaliador e Ponto de Contato


259

Atividade A.2.4: Análise da Prontidão

A partir do estabelecimento do Plano da Avaliação e dentro de um prazo previamente

estipulado é realizada pela equipe de avaliação uma checagem relativa à disponibilização por

parte da Organização Solicitante dos recursos necessários à visita de avaliação, como por

exemplo: sala adequada para as reuniões e entrevistas; pessoas que serão entrevistadas;

documentos e arquivos que apresentem evidências dos resultados esperados; facilidades de

comunicação; entre outros. Durante esta checagem podem ocorrer interações entre as

organizações, bem como revisões e complementações das informações fornecidas. Após a

conclusão da análise das informações ou no final do prazo estipulado (o que acontecer

primeiro), a equipe de avaliação emite um parecer sobre a prontidão ou não da Organização

Solicitante para a realização da visita de avaliação. Se o parecer for pela não prontidão, a visita

de avaliação não será agendada e a Organização Solicitante será comunicada das providências

que deverá tomar antes de solicitar uma nova análise da prontidão. Caso contrário, se o

parecer for pela prontidão, a equipe de avaliação e a Organização Solicitante podem agendar a

visita de avaliação e passar para a próxima fase.


Outros participantes da atividade: Avaliador, Patrocinador da Avaliação e Ponto de Contato

Atividade A.2.5: Providências para a Visita

Uma vez confirmada a prontidão da Organização Solicitante para a realização da visita de

avaliação, providências devem ser tomadas tanto pela Organização Solicitante como pela

Unidade de Avaliação para assegurar que a visita de avaliação possa ser realizada com sucesso.

São exemplos dessas providências: ajustes e acordos finais na agenda, local físico,

participantes da avaliação e recursos envolvidos, aquisição de passagens e reservas em hotéis,

entre outras.


Outros participantes da atividade: Responsável pela Unidade de Avaliação, Avaliador e Ponto

de Contato.

5.4.3 Fase 3: Visita

Esta fase contempla uma visita da Equipe de Avaliação à Organização Solicitante, que se reúne

com o Patrocinador da Avaliação e os Participantes da Avaliação, analisa as evidências

fornecidas que servirão de base ao resultado da avaliação, elabora um relatório preliminar da

avaliação e o compartilha com a Organização Solicitante.


260

Normalmente esta visita é realizada em um único dia, de forma que os Participantes da

Avaliação devem estar previamente preparados e com os recursos necessários à avaliação

anteriormente identificados, disponíveis. Excepcionalmente podem ser alocados dois ou mais

dias para a visita de avaliação, mas o motivo para isso deverá estar claro e justificado no Plano

da Avaliação. O objetivo principal desta fase é estabelecer a pontuação e o resultado da

avaliação, após análise de todos os dados, informações e evidências encontradas pela Equipe

de Avaliação na Unidade Organizacional.

Figura 8 – Diagrama da fase Visita

Esta fase é composta por cinco atividades que estão relacionadas e descritas a seguir.

Atividade A.3.1 Início da Visita

Conforme negociado no Plano da Avaliação, a Visita de Avaliação começa com uma reunião

entre a Equipe de Avaliação, o Patrocinador da Avaliação e os Participantes da Avaliação,

marcando o início das atividades da visita às instalações da Organização Solicitante. Nessa

reunião, busca-se um entendimento geral compartilhado do processo de avaliação e

esclarecimento de possíveis dúvidas que ainda possam existir. Deve ser feita uma

apresentação aos Participantes da Avaliação sobre os objetivos e as atividades da avaliação.

Essa apresentação deve ser feita pelo Patrocinador da Avaliação, como representante mais

graduado da organização nesse processo de avaliação e pelo Avaliador Líder.

Responsáveis pela atividade: Avaliador Líder

Outros participantes da atividade: Avaliador, Patrocinador da Avaliação, Ponto de Contato e

Participantes da Avaliação.

Atividade A.3.2 Análise das Evidências

Conforme agenda negociada previamente e documentada no Plano da Avaliação, são

realizadas sessões de entrevistas com os Participantes da Avaliação e análise de evidências,

visando um melhor entendimento e possíveis complementações das informações obtidas com

as evidências.


261

No decorrer das entrevistas a Equipe de Avaliação pode identificar a necessidade de realizar

entrevistas adicionais com os Participantes da Avaliação ou outros colaboradores da

Organização Solicitante, assim como validações dos entendimentos originados nas entrevistas

já realizadas, dentro dos limites e condições previamente acordados no Plano da Avaliação.

Nesse caso, a Organização Solicitante deve se empenhar em providenciar a disponibilização

dos colaboradores e recursos adicionais identificados.

Esta atividade é encerrada tão logo a Equipe de Avaliação considere já ter obtido um

entendimento suficiente do software, por meio das evidências, considerando todos os

aspectos solicitados pela Metodologia CERTICS para Software.


Outros participantes da atividade: Avaliador, Ponto de Contato e Participantes da Avaliação.

Atividade A.3.3. Pontuação do Atendimento

Com base no entendimento suficiente do software em todos os aspectos solicitados pela

Metodologia CERTICS para Software, a Equipe de Avaliação realiza uma análise do grau de

atendimento aos requisitos do modelo e atribui as pontuações. Cada pontuação é

justificada com pelo menos uma frase para comunicar a racionalidade da pontuação. As

pontuações obtidas, acompanhadas pelas racionalidades documentadas, geram o resultado da

avaliação. Este resultado representa a recomendação da Equipe de Avaliação para o resultado

da avaliação. Um relatório preliminar da avaliação é produzido pela Equipe de Avaliação. Este

relatório é apresentado ao Patrocinador da Avaliação e será posteriormente concluído pela

Equipe de Avaliação.


Outros participantes da atividade: Avaliador

Atividade A.3.4. Apresentação do Resultado

Em uma reunião executiva, o Avaliador Líder apresenta o resultado da avaliação para o

Patrocinador da Avaliação e outras pessoas por ele convidadas. Caso acordado no Plano da

Avaliação, o Avaliador Líder ou a Equipe de Avaliação podem apresentar o resultado para

um grupo maior de convidados do Patrocinador da Avaliação.


Outros participantes da atividade: Patrocinador da Avaliação, Avaliador e Ponto de Contato

Atividade A.3.5. Conclusão da Visita


262

Na conclusão dos trabalhos da visita de avaliação, as seguintes tarefas são realizadas:

organização das informações relevantes sobre a avaliação; armazenamento destas

informações no SAA; elaboração e registro de análises individuais (feedback) sobre a avaliação

realizada e sobre o processo utilizado, tanto pelos membros da Equipe de Avaliação quanto

pelo Patrocinador da Avaliação. Todos os documentos produzidos passarão por uma atividade

de validação na Unidade de Avaliação.


Outros participantes da atividade: Patrocinador da Avaliação, Avaliador e Ponto de Contato

5.4.4 Fase 4: Validação

Esta fase contempla a execução de um conjunto de atividades que visa assegurar que a

avaliação foi realizada em conformidade com a Metodologia CERTICS para Software.

Um Validador da Avaliação credenciado verifica se o processo de avaliação foi conduzido

adequadamente e valida o resultado final da avaliação. O relatório preliminar que foi

elaborado durante a visita é revisado e concluído, gerando-se o relatório final validado.

Figura 9 – Diagrama da fase Validação

Esta fase é composta por quatro atividades que estão relacionadas e descritas a seguir.

Atividade A.4.1: Consolidação do Relatório

O relatório preliminar elaborado durante a visita de avaliação é revisado, retrabalhado onde

necessário e concluído, dando origem ao relatório final da avaliação, que ainda passará por

uma etapa de validação. Esta atividade é realizada pela própria Equipe de Avaliação.


Outros participantes da atividade: Avaliador


263

Atividade A.4.2: Designação do Validador

Um Validador da Avaliação credenciado é designado pela Unidade de Avaliação como

Validador da Avaliação para a avaliação realizada. No caso de um Validador da Avaliação

também ser um Avaliador credenciado, ele não poderá atuar na validação da avaliação que

tenha participado.

Responsável pela atividade: Responsável pela Unidade de Avaliação

Outros participantes da atividade: Validador da Avaliação

Atividade A.4.3: Validação

Nesta atividade o Validador da Avaliação analisa o relatório final da avaliação e verifica se o

processo de avaliação foi conduzido adequadamente, em conformidade com a Metodologia

CERTICS para Software, e valida se os resultados produzidos também estão em

conformidade. Durante a validação, o Validador da Avaliação pode interagir com o Avaliador

Líder para possíveis ajustes no relatório. Uma validação bem sucedida terá como resultado

principal um relatório final da avaliação validado.

Responsável pela atividade: Validador da Avaliação

Outros participantes da atividade: Avaliador Líder.

Atividade A.4.4: Conclusão da Validação

Uma vez validados os resultados e a recomendação da pontuação, estas informações são

organizadas em um Relatório Final da Avaliação Validado, com o resultado final da avaliação. A

Equipe de Avaliação e o Validador da Avaliação conduzem uma sessão de discussão e

registram as lições aprendidas durante essa avaliação.

Responsável pela atividade: Validador da Avaliação

Outros participantes da atividade: Avaliador Líder

5.4.5 Fase 5: Conclusão

Esta fase contempla um conjunto de atividades para a conclusão do processo de avaliação. Um

Laudo da Avaliação é produzido, enviado à Organização Solicitante e, caso apropriado, enviado

ao MCTI para emissão do Certificado CERTICS. As informações utilizadas e geradas durante a

avaliação que devem ser preservadas são organizadas e armazenadas no SAA com níveis de

segurança e sigilo de dados adequados. Todas as informações da avaliação não preservadas

são destruídas.


264

Figura 10 – Diagrama da fase Conclusão

Esta fase é composta por duas atividades que estão relacionadas e descritas a seguir.

Atividade A.5.1: Envio do Resultado

Nesta atividade é produzido pelo Responsável pela Metodologia um Laudo da Avaliação a

partir das informações do Relatório Final da Avaliação Validado.

A Unidade de Avaliação envia o Laudo da Avaliação e o Relatório Final da Avaliação Validado à

Organização Solicitante. Caso o resultado final da avaliação tenha sido positivo e a Organização

Solicitante tenha especificado no contrato o interesse em obter o certificado, o Laudo da

Avaliação é enviado ao MCTI para emissão do Certificado.

Caso o resultado final da avaliação tenha sido negativo, essa informação é repassada apenas à

Organização Solicitante e não é tornada pública.


Outros participantes da atividade: Responsável pela Metodologia (CTI), Avaliador Líder

Atividade A.5.2: Conclusão da Avaliação

As informações relativas à avaliação são processadas e organizadas, eliminando-se detalhes

irrelevantes ou questões sensíveis para seu armazenamento definitivo no SAA. Dessa forma, a

base de conhecimento relacionada à Metodologia CERTICS para Software é alimentada.

Os principais artefatos utilizados e produzidos na avaliação são armazenados no SAA e a

avaliação é concluída.

O Contrato para Avaliação é terminado com a emissão do Termo de Quitação.


265


Outros participantes da atividade: Avaliador Líder, Responsável pela Metodologia


266

6. Exemplo do resultado de uma avaliação

Esta seção apresenta um exemplo ilustrativo de uma avaliação. O exemplo apresentado a

seguir utilizou dados fictícios e foi criado para auxiliar o entendimento da atividade de

avaliação de um software segundo a Metodologia CERTICS para Software. A seguir são

mostrados os critérios definidos no escopo da Metodologia CERTICS e sua utilização em

um caso específico.

Conforme previsto na Metodologia CERTICS, cada Resultado Esperado é analisado com

base em evidências e o resultado é pontuado em uma escala com quatro valores (N, P, L e F) e

justificada.

A regra de pontuação é:

A escala de pontuação ordinal definida a seguir deve ser utilizada para expressar o alcance do

Resultado Esperado pelo software em uma avaliação:

N Não atendido: Existe pouca ou nenhuma evidência do alcance do Resultado Esperado pelo

software em avaliação.

P Parcialmente atendido: Existe alguma evidência de aproximação e algum alcance do

Resultado Esperado pelo software em avaliação. Alguns aspectos de alcance são imprevisíveis.

L Largamente atendido: Existe evidência de aproximação sistemática e de alcance

significativo do Resultado Esperado pelo software em avaliação. Existem alguns pontos fracos

relacionados a este Resultado Esperado pelo software em avaliação, porém estes não são

críticos para a obtenção do Resultado Esperado.

F Completamente (Fully) atendido: Existe evidência de uma aproximação completa e

sistemática e de alcance total do Resultado Esperado pelo software em avaliação. Não existem

pontos fracos significativos relacionados com este Resultado Esperado pelo software em

avaliação.

Os pontos ordinais definidos nesta escala devem ser entendidos em termos de uma escala

percentual que representa a extensão do alcance. Os valores correspondentes devem ser:

N Não atendido 0 a 15% de alcance

P

Parcialmente atendido


L

Largamente atendido


F

Completamente atendido


Em todos os casos deve ser indicado o racional utilizado na atribuição da pontuação N, P, L ou

F.


267

Quando a pontuação atribuída for diferente de “F”, além do conteúdo do racional utilizado

deve ser indicado pelo menos um ponto fraco encontrado.

Cada área de competência é pontuada em uma escala binária: Sim ou Não com base no

resultado das avaliações de cada um de seus resultados esperados. A pontuação será Sim se

cada resultado esperado estiver pontuado como F ou L. A pontuação será Não caso contrário.

O Software Resultante de Desenvolvimento Tecnológico e Inovação Realizados no País é pontuado também em

uma escala binária: Sim ou Não com base no resultado das avaliações de cada uma das áreas

de competência. A pontuação será Sim se cada área de competência estiver pontuada como

Sim. A pontuação será Não caso contrário.

6.1 Justificativa e Pontuação para cada Resultado Esperado

A tabela a seguir descreve o exemplo. Este caso ilustrativo é de uma avaliação hipotética de

um software desenvolvido por organização nacional de pequeno porte que obtém a

certificação. O software foi desenvolvido por uma equipe composta de 6 colaboradores, sendo

dois deles estrangeiros e que, ao final do desenvolvimento voltaram ao seu país de origem. O

software foi desenvolvido segundo a metodologia SCRUM.

Área Resultado

esperado

Justificativa: Descrição da análise realizada e das evidências

consideradas Pontu

ação

Desenv

olvimen

to

DES.1. A concepção do software está refletida na documentação

dos requisitos e na solução técnica, elaboradas pela equipe e

aprovada pelo Patrocinador. A equipe e o patrocinador

pertencem ao quadro de colaboradores da organização que

é nacional.

Documentação verificada: Doc_Req. doc versão 2.0,

Solucao_tec.doc versão 2.0 e Cadastro de colaboradores

disponível na intranet.

F

DES.2. O projeto de arquitetura do software foi elaborado e

validado pelos colaboradores (arquiteto e equipe de

requisitos) capacitados. Foi verificado que alguns

colaboradores ainda pertencem à organização, o que

demonstra que o domínio da solução gerada permanece.

Documentação verificada: Arquitetura.doc versão 3.0,

Cronograma.xls versão 7.2, Cadastro de colaboradores

disponível na intranet e Certificados de Especialização do

arquiteto.

F

DES.3. As fases de desenvolvimento do software foram definidas

no cronograma. A documentação gerada em cada fase foi

armazenada no repositório do projeto. Foi utilizada a

ferramenta Subversion para o versionamento e gestão de

configuração. Foi possível verificar a compatibilidade

existente entre o software desenvolvido, versus a sua

complexidade (simples), tamanho (pequeno), quantidade de

colaboradores envolvidos (6), datas de realização e duração

do projeto (3 meses). Foi verificado por meio de registros

F


268

que a equipe definida no cronograma atuou nas fases,

pertence ao quadro de colaboradores e desempenhou o seu

papel.

Documentação verificada: Cronograma.xls versão 7.2,

Cadastro de colaboradores disponível na intranet, Lista dos

requisitos na pasta Aprovação, Documentação dos requisitos

na pasta REQ, Arquitetura e Solução Técnica na pasta ARQ,

Código fonte na pasta Codigo, Evidencias de Testes na pasta

Teste.

DES.4. No cronograma foi possível identificar os colaboradores que

atuaram no desenvolvimento do software. No cadastro de

colaboradores foi verificado que a maioria (4) dos

colaboradores que participou desse desenvolvimento está

na organização que é nacional. Apenas dois deles que eram

colaboradores estrangeiros retornaram ao seu país de

origem e não pertencem mais ao quadro de colaboradores.

Foi verificado por meio da folha de frequência que todos os

colaboradores da equipe estavam no País, quando o

desenvolvimento do software aconteceu.

Foi verificado por meio de registros que a equipe foi

capacitada na tecnologia presente no software

desenvolvido. Foi verificado nos documentos gerados

(requisitos, arquitetura, solução técnica, casos de uso,

código e evidências de testes) os nomes desses

colaboradores como autores ou revisores. Documentação

verificada: Cronograma.xls versão 7.2, Cadastro de

colaboradores disponível na intranet , Folha_freqüência.doc

dos meses 1, 2 e 3, Lista de presença do Workshop realizado

para repasse da tecnologia, certificados, Documentação dos

requisitos na pasta REQ, Arquitetura e Solução Técnica na

pasta ARQ, Casos de Uso na pasta UC, Código fonte na pasta

Codigo, Evidencias de Testes na pasta Teste.

Justificativa: A maioria dos colaboradores estava e

permaneceu no País, não todos.

L

DES.5. Foi verificado que as informações tecnológicas do software

desenvolvido foram documentadas pela equipe envolvida e

estão armazenadas no repositório. Documentação

verificada: Documentação dos requisitos na pasta REQ,

Arquitetura e Solução Técnica na pasta ARQ, Casos de Uso

na pasta UC, Código fonte na pasta Codigo, Evidencias de

Testes na pasta Teste

F

DES.6. Foi verificado que a organização é capaz de realizar evolução

ou manutenção no software desenvolvido. A mesma equipe

de colaboradores que desenvolveu o software atuou na

inclusão de uma nova funcionalidade baseada na tendência

de mercado e executou a correção de um defeito

encontrado em campo.

Foi verificado que a organização é capaz de realizar

customizações no software desenvolvido. A mesma equipe

de colaboradores que desenvolveu o software atuou na

L


269

customização do software para um cliente específico.

Foi verificado que a organização executa a implantação do

software desenvolvido. A mesma equipe de colaboradores

que desenvolveu o software atuou na implantação no

ambiente alvo.

Foi verificado que a organização possui uma estrutura de

suporte ao cliente bastante ativa e relativamente bem

estruturada. Há colaboradores capacitados e disponíveis

para atuar nas atividades de suporte ao cliente. Há um

sistema de gerenciamento das solicitações dos clientes, há a

realização de pesquisa de satisfação dos clientes, com

desdobramentos no planejamento do negócio (ações e

registros na ferramenta de roadmap). Há também um

planejamento das atividades necessárias para o

atendimento de determinada demanda (quando aprovada

sua implementação) e disseminação das melhorias para a

rede de clientes. Há também o planejamento da capacitação

necessária para a execução das atividades de suporte ao

cliente

Documentação verificada: Plano_evolucao.doc versão 1.2,

Doc_Req.doc versão 3.0, Solucao_tec.doc versão 3.0,

código-fonte relacionado, Registro do defeito, e-mail de

liberação da release que contém a correção do defeito.

Cronograma da Customização versão 1.0, Documentação

dos requisitos na pasta REQ, Arquitetura e Solução Técnica

na pasta ARQ, Casos de Uso na pasta UC, Código fonte na

pasta Codigo, Evidencias de Testes na pasta Teste,

Cronograma da implantação versão 1.0,

aceite_homologacao.doc versão 1.0.

Controle de homens-hora nas atividades de suporte ao

cliente (Identificação do colaborador que executou a

atividade e resultado); . Plano de trabalho da equipe de

suporte, cadastro de pessoal e folha de presença. Registros

de treinamentos realizados ou a realizar, certificados

específicos para as tecnologias relevante, avaliação de

eficácia de treinamentos realizados, lista de presença de

workshop realizado para uma nova versão do software

Justificativa: A maioria dos colaboradores estava e

permanece no País, não todos.

Gestão

de

Tecnolo

gia

TEC.1. A tecnologia presente no software utilizou resultado de um

projeto de pesquisa e desenvolvimento desenvolvido na

organização que é nacional. Foi verificado na documentação

de requisitos e na solução técnica, a adoção da tecnologia

desenvolvida. Foi verificado em registros de capacitação que

os colaboradores envolvidos no desenvolvimento do

software receberam treinamento na tecnologia.

Documentação verificada: Carta de intenção com órgão de

pesquisa envolvido no projeto de pesquisa e

desenvolvimento, Documentação dos requisitos na pasta

REQ, Solução Técnica na pasta ARQ, Lista de presença do

Workshop realizado para repasse da tecnologia.

F


270

TEC.2. O software desenvolvido foi o motivador para a execução de

um projeto de pesquisa e desenvolvimento na organização

para a criação da tecnologia adotada. Foi verificado nos

registros das atas de reunião que antecederam a concepção

do software, a decisão de envolver um órgão de pesquisa

para que a solução tecnológica pretendida fosse estudada e

desenvolvida . Foi verificada a existência da carta de

intenção junto ao órgão de pesquisa selecionado. Além da

tecnologia desenvolvida, o projeto de pesquisa e

desenvolvimento resultou em uma dissertação de Mestrado

e uma tese de Doutorado, ambas publicadas na USP.

Documentação verificada: Atas de reunião na pasta ATAS,

Carta de intenção com órgão de pesquisa envolvido no

projeto de pesquisa e desenvolvimento, Documentação do

projeto de pesquisa e desenvolvimento , Dissertação de

Mestrado, Tese de Doutorado.

F

TEC.3. A tendência tecnológica é acompanhada pelos

colaboradores da organização para que o software se

mantenha atualizado e competitivo. Esse acompanhamento

é feito de maneira informal. Por exemplo buscas na internet,

em revistas, associações, etc. Todas as informações

tecnológicas relevantes para o software são levadas ao

conhecimento dos superiores para análise e tomada de

decisão para adoção ou não. Foi verificado em registros, a

inclusão de uma nova funcionalidade no software

desenvolvido devido a abordagem móbile presente no

mercado alvo.

Foi verificado que os colaboradores da unidade

organizacional dominam a tecnologia presente no software,

pois participaram de vários treinamentos e foram capazes

de realizar manutenção na parte tecnológica do software. A

maioria desses colaboradores (4) está na organização que é

uma empresa nacional.

Documentação verificada: Registros das informações da

tecnologia móbile, ata de reunião técnica, registro da

decisão tomada, Cronograma da modificação versão 1.0,

Documentação dos requisitos na pasta REQ, Arquitetura e

Solução Técnica na pasta ARQ, Casos de Uso na pasta UC,


Teste, Lista de presença do Workshop realizado para repasse

da tecnologia, Cadastro de colaboradores na intranet.

Justificativa: A maioria dos colaboradores está no País, não

todos.

L

TEC.4. Os colaboradores da organização são motivados a

apresentar ideias inovadoras. A tecnologia presente no

software é uma inovação e o colaborador que trouxe a ideia

recebeu uma premiação.

Documentação verificada: Registros da ideia inovadora,

apresentação do resultado financeiro, fotos da premiação,

Prática de Reconhecimento.

F

TEC.5. Foi verificado o registro de software no Brasil. A organização F


271

detém a propriedade intelectual garantida por contratos de

cessão de direitos de autoria anexos aos contratos de

trabalho dos seus colaboradores submetidos ao regime de

CLT - todos os colaboradores envolvidos no

desenvolvimento firmaram o instrumento de cessão de

direitos autorais; que o domínio tecnológico foi apropriado

por ela com a realização de treinamentos tecnológicos para

a equipe de colaboradores e que essa equipe foi capaz de

atualizar a tecnologia desenvolvida para incorporar uma

solução mais atual.

Documentação verificada: Registro de Direito Autoral de

Software, Contratos de trabalho e cessão de direitos de

autoria dos colaboradores CLT, Cronograma.xls versão 7.2,

Documentação dos requisitos na pasta REQ, Arquitetura e

Solução Técnica na pasta ARQ, Casos de Uso na pasta UC,


Teste

Gestão

de

Negócio

s

GNE.1. Foi verificado que há a ocorrência de pesquisa de mercado

não estruturada , realizada por alguns colaboradores da

organização , que varrem artigos em revistas, sites e

palestras on-line. Estes colaboradores geram um resumo dos

principais achados relacionados ao software avaliado e este

resumo é apresentado em reuniões periódicas realizadas

com a direção da organização, time de desenvolvedores e

suporte à vendas. Estas reuniões geram insumos que

alimentam periodicamente a ferramenta de roadmap para

aquele software. Ocasionalmente, os colaboradores

participam de eventos nacionais e internacionais,

relacionados ao mercado ou nicho onde o software está

inserido. Também há intensa comunicação com os clientes,

que solicitam melhorias e aprimoramentos no software,

para se adequar a determinada tendência. Documentação

verificada: slides de apresentação de tendências de

mercado, documentação extraída da ferramenta de

roadmap, atas de reunião para discussão de melhorias no

software. Registros de solicitação de clientes no sistema de

gerenciamento de mudanças.

F

GNE.2. Foi verificada a participação de colaboradores em feiras de

tecnologia para conhecer as opções fornecidas pelos

concorrentes do software. As informações obtidas foram

relatadas nas reuniões de acompanhamento do

desenvolvimento do software

Documentação verificada: slides das reuniões para melhoria

de software

F

GNE.3. Foi verificado que a organização possui processos

implantados para coleta, análise e encaminhamento de

demandas de clientes. O sistema de gerenciamento de

mudanças possui conjunto de funcionalidades que registram

e acompanham o atendimento das demandas. As demandas

que implicam em mudanças no software, que ainda não

estão presentes no mercado são avaliadas em reuniões

F


272

periódicas e resultam na revisão das informações do

software na ferramenta de roadmap. Demandas não

implementadas geram retorno (justificativa) para o cliente.

Há também equipe própria e metodologia para suporte pós-

vendas e assistência técnica do software. Ampliação do

objeto dos contratos baseada em ações de antecipação de

mercado. Há também pesquisa de satisfação com clientes.

Foi verificado que determinadas demandas geraram

aprimoramentos que foram aproveitadas para ingresso em

novo mercado e ampliação do escopo de atuação nos

principais clientes.

Documentação verificada: Documentação do roadmap do

software, registros de solicitação de mudanças do sistema

de gerenciamento de atividades, documentos da pesquisa

de satisfação, documento de procedimentos (Workflow)

para monitoramento de clientes. Objetos dos contratos dos

novos clientes

GNE.4. Foi verificado que a organização tem uma ferramenta de

roadmap para o software, que é revisado periodicamente. A

ferramenta de roadmap recebe insumos de várias áreas e

atividades da organização: reuniões para melhoria do

software, resultados dos estudos de tendências

tecnológicas, consultorias especializadas, etc.

Documentação verificada: Documentação do roadmap e

principais documentos utilizados

F

GNE.5. Foi verificada a expansão para novos nichos de mercado e

exportação para um país do continente africano, que

envolveu a construção de um arcabouço jurídico e estratégia

de abordagem do mercado. Nesta situação específica, houve

o estabelecimento de parcerias locais e contratos de

prestação de serviços. A solução comercializada naquele

país foi resultante de uma parceria técnica e comercial com

um fornecedor local, de modo a atender à oportunidade

identificada. Também verificou-se planejamento de

atividades e material de divulgação específico para entrada

em novos nichos de mercado no Brasil. Documentação

verificada: Contratos do estabelecimento de parceria

técnico-comercial na África, slides com o arcabouço jurídico e

estratégia de mercado na África, plano de atividades para

inserção em novos nichos, material de divulgação para novos

nichos e para clientes tradicionais. Escopo dos contratos

recentes com clientes tradicionais

F

Gestão

de

Parceri

as

e

Aliança

s

GPA.1. Foram verificadas ações informais para prospecção de

parcerias. Há colaboradores com atividades periódicas de

varredura de potenciais parceiros comerciais e tecnológicos,

contatos, reuniões de trabalho e encaminhamento. Há

evidências de parcerias comerciais realizadas e de parcerias

informais com universidades estaduais. Há também

evidências no planejamento estratégico da organização para

a constituição de parcerias estratégicas. Documentação

verificada: Estudos de levantamento

F


273

(realizados internamente ou contratados de terceiros) sobre

organizações e/ou ICTs, editais de financiamento (com

parcerias) e parceiros comerciais. Atas de reunião e slides

de interação para estabelecimento de alianças comerciais e

parcerias com institutos para capacitação de recursos

humanos e desenvolvimento de tecnologia. Contratos

comerciais firmados. Planejamento estratégico da

organização

GPA.2. Foi verificado o estabelecimento de três alianças comerciais

formalizadas. Duas no Brasil e uma no exterior. As três dizem

respeito ao fornecimento de uma solução em que o software

complementa as funcionalidades de um pacote mais amplo.

Duas das alianças aconteceram como decorrência de uma

busca de parceiros pela organização e a terceira a

organização foi procurada. Documentação verificada:

Contratos das alianças comerciais realizadas.

F

GPA.3. Foi verificada a existência de colaboradores que atuam

como interface de comunicação e acompanhamento das

alianças comerciais. Há um planejamento informal das

atividades e acompanhamento dos resultados. Os resultados

são apresentados em reuniões de acompanhamento de

atividades.

Documentação verificada: Atas de reunião com parceiros.

Slides com relato dos resultados

F

Gestão

de

Pessoas

,

Process

os

e

Conheci

mento

PPC.1. A organização só contrata pelo regime CLT, exceto os

estagiários. Os colaboradores da organização que

desenvolveram o software estão contratados no regime CLT.

A alocação dos colaboradores nas atividades do

desenvolvimento do software está documentada no

cronograma . Antes da alocação acontecer foi verificado no

Cadastro de Colaboradores, o perfil necessário à atividade e

alocado o colaborador adequado. Nos casos da falta de

competência foi planejado o treinamento do colaborador,

antes da atividade ser executada por ele. Os colaboradores

são gerenciados e motivados para a realização das

atividades a eles atribuídas. Um colaborador recebeu uma

premiação pela ideia inovadora que resultou no

desenvolvimento do software. Documentação

verificada: Cronograma.xls versão 7.2,

Contrato de trabalho dos colaboradores alocados, Cadastro

de colaboradores disponível na intranet, Plano de

Capacitação, Registro do treinamento realizado, Prática de

Reconhecimento, Fotos da premiação recebida.

F

PPC.2. O desenvolvimento do software foi realizado por uma

equipe multidisciplinar de colaboradores. A metodologia

utilizada para o desenvolvimento do software foi o SCRUM,

o que por definição exige maior proximidade física dos

postos de trabalho, entrosamento, boa comunicação,

comprometimento e cumprimento do prazo. Foi verificado

no cronograma que o prazo planejado foi o realizado. Foi

F


274

verificado nos registros de defeitos que apenas 15 defeitos

de gravidade baixa foram encontrados e tratados no

software desenvolvido.

Documentação verificada: Cronograma.xls versão 7.2,

Cadastro de colaboradores disponível na intranet, Registros

de defeitos.

PPC.3. A organização tem como diretriz que todo colaborador deve

ser treinado em novas tecnologias, antes de utiliza-las no

desenvolvimento. Foi verificado que todos os colaboradores

receberam treinamento presencial na tecnologia criada no

projeto de pesquisa e desenvolvimento que era base para o

desenvolvimento do software . Pelo menos dois

colaboradores fizeram a reciclagem desse treinamento, na

modalidade on the job, após a avaliação de efetividade do

colaborador não ter resultado satisfatório. Documentação

verificada: Documento de diretriz organizacional, Lista de

presença do Workshop realizado

para repasse da tecnologia, Registro de avaliação de

efetividade, Registro do treinamento on the job.

F

PPC.4. O conhecimento gerado no desenvolvimento do software foi

registrado na ferramenta de Gestão do Conhecimento ao

final de cada sprint, durante a reunião de retrospectiva.

Antes do início de uma nova sprint esses registros foram

consultados e disseminados para que a equipe de

colaboradores envolvidos praticasse as lições positivas e

evitasse repetir os erros cometidos anteriormente.

Documentação verificada: Levantamento de lições positivas

e negativas, Registros efetuados na Ferramenta de Gestão

do Conhecimento, Registros das reuniões de retrospectiva

das sprints.

Justificativa: Foi verificado que nem todas as lições

aprendidas levantadas nas reuniões de retrospectiva das

sprints foram registradas na Ferramenta de Gestão do

Conhecimento. Das cinco (05) lições levantadas na sprint 2,

apenas três (03) foram registradas.

L

PPC.5. Foi verificado que a organização não tem um processo

formal documentado para o desenvolvimento de software.

Há um operacional padrão que é executado. Há a prática de

rodízio de colaboradores entre as áreas técnicas,

oportunidade na qual, todos aprendem o operacional da

organização rapidamente e passam a entender as

dificuldades existentes nas interfaces entre áreas. Novos

colaboradores contratados ficam em média um mês em

cada área técnica e, ao final de seis meses, ele passou a

conhecer todo o ciclo de desenvolvimento. Os

colaboradores fornecem sugestão de melhoria para a

execução das atividades dentro de uma determinada área e

sugestões de melhoria entre áreas (entradas e saídas). As

sugestões são analisadas, algumas são realizadas e outras

descartadas. Aquelas realizadas são divulgadas para que o

novo operacional seja adotado.

F

Documentação verificada: Lista dos colaboradores

participantes do rodízio, Registro de sugestões de melhoria,

Registro da realização da melhoria, e-mail de divulgação do

novo operacional associado a melhoria realizada.

6.2 Pontuações derivadas e Quadro Resumo

A partir da pontuação de cada resultado esperado, são realizadas as pontuações derivadas das áreas de

competências e do software como resultante de desenvolvimento tecnológico e inovação realizados no País.

Como a nota (ou pontuação) dos sete Resultados Esperados da Área de Competência de Desenvolvimento

foram respectivamente F, F, F, L, F, F e L (todas são F ou L), esta área é pontuada como Sim.

Como a nota (ou pontuação) dos cinco Resultados Esperados da Área de Competência de Gestão de

Tecnologia foram respectivamente F, F, L, F e F (todas são F ou L), esta área é pontuada como Sim.

Como a nota (ou pontuação) dos cinco Resultados Esperados da Área de Competência de Gestão de

Negócios foram respectivamente F, F, F, F e F (todas são F ou L), esta área é pontuada como Sim.

Como a nota (ou pontuação) dos três Resultados Esperados da Área de Competência de Gestão de

Parcerias e Alianças foram respectivamente F, F e F (todas são F ou L), esta área é pontuada como Sim.

Como a nota (ou pontuação) dos cinco Resultados Esperados da Área de Competência de Gestão de Pessoas,

Processos e Conhecimento foram respectivamente F, F, F, L e F (todas são F ou L), esta área é pontuada como

Sim.

Concluindo a pontuação, como a nota (ou pontuação) das cinco Áreas de Competência foram

respectivamente Sim, Sim, Sim, Sim e Sim (todas são Sim), a recomendação da avaliação é que este software

seja indicado como resultante de desenvolvimento tecnológico e inovação realizados no País.

Quadro Resumo

Áreas de Competências Pontuação

da área

Resultado

Final

Desenvolvimento Sim

Sim

Gestão de Tecnologia Sim

Gestão de Negócios Sim

Gestão de Parcerias e Alianças Sim

Gestão de Pessoas, Processos e Conhecimento Sim



276



Qui, 23 de Ago de 2012 11:15


Para : Fernando Santo Andre

Prezado Sr. Fernando

Criamos um site com informações sobre a certificação CERTICS que é parte do TI MA IOR.

O endereço é :


Neste endereço tem informações sobre a dinâmica da avaliação e posterior certificação e

também o modelo e método.

Acreditamos que suas dúvidas possam ser sanadas com este material.

Mais uma vez obrigada pelo contato

Atenciosamente

Angela Maria A lves


De: "Fernando Santo Andre"


Enviadas: Quinta-feira, 23 de Agosto de 2012 10:43:55


Bom dia!

Gostaria de participar da Consulta Pública da Certics, porém queria entender primeiro o

que preciso ter disponível para fazê-lo.

Por exemplo: meu software precisa já ter um protótipo, precisa estar em fase de testes,

preciso de um plano de negócios bem

definido, com o planejamento de longo prazo bem estruturado...?

Aguardo sua resposta.

Att,

Fernando Santo André




Qui, 23 de Ago de 2012 16:06


Para : Fernando Gebara Filho

Prezado Fernando,

Imediata. Pode começar a contribuir imediatamente.

Att.

Angela


From: "Fernando Gebara Filho"


Sent: Thursday, August 23, 2012 4:00:52 PM

Subject: RE: CERTICS - Contato

Obrigado pela informação. Qual será a data inicial de contribuições?


From: Consulta Publica [mailto:[email protected] ]

Sent: quinta-feira, 23 de agosto de 2012 16:00

To: Fernando Gebara Filho


Prezado Fernando,

A participação na Consulta Pública é muito simples.

Basta você enviar suas contribuições para o endereço eletrônico

[email protected].

A Consulta Pública terá a duração de 30 dias.

Grata

Angela Maria A lves


277


From: "Fernando Gebara Filho"




Boa tarde, gostaria de participar do processo de Consulta Pública da CERTICS.

Por favor, me informem a forma de participação e os prazos disponíveis.

Muito obrigado.

Fernando Gebara Filho - LATA M Regional Standards Officer




Sex, 24 de Ago de 2012 11:20


Para : Eduardo Garcia

Prezado Eduardo,

Sim, fique tranquilo. Sua preocupação será considerada.

Grata pela participação

Angela Maria A Lves


From: "Eduardo Garcia"




Cara A ngela,

Agradeço a sua pronta resposta.

A minha dúvida se dá por dois aspectos: (1) a autonomia de decisão das agências me faz

questionar se elas irão ou não validar nos seus âmbitos regulatórios; (2) qual a

possibilidade e ar ticulação que possam ser estabelecidos para ampliar a abrangência da

certificação,para aspectos específicos dos respectivos marcos regulatórios.

Se você puder incluir essa preocupação, de alguma forma, será interessante.

Atenciosamente,

Eduardo Garcia

Enviado via iPad

Em 23/08/2012, às 16:21, Consulta Publica


Prezado Eduardo,

A CERTICS foi elaborada para atender aos mecanismos que por ora existem e que careciam de

regulação, a saber, conforme texto do site, na aba concepção: " Veja os critérios que

orientaram a elaboração da CERTICS, na exposição de motivos da Lei nº 12.349/2010, que

estabeleceu a margem de preferência de compras, e da Lei 8248/, que dispõe sobre a

capacitação e competitividade do Setor de Informática e Automação (Decreto no 7174".

Da forma que a Metodologia foi concebida, não existe impedimentos para que seja usada por

outros mecanismos regulatórios para atender outras finalidade.

Espero ter respondido a questão. Caso negativo não hesite em encaminha-la novamente.

Att.

Angela Maria Alves


From: "Eduardo Garcia"


Sent: Thursday, A ugust 23, 2012 4:09:02 PM


Prezados senhores,

Com grande satisfação soube do lançamento do CERTiCS, que certamente trará um grande

benefício às empresas de desenvolvimento de software brasiLeiras.


278

Embora ainda não tenha me aprofundado no documento, já me deparei com uma questão sobre a

qual tomo a liberdade de Consulta-los. Segue a questão: Mesmo considerando os benefícios

apontados pelo programa surgiu a questão de como essas certificações serão consideradas

pelas agências reguladoras para que a certificação produza efeitos quanto a aspectos

regulatórios.

Exemplifico a dúvida com um cenário relevante como de aplicati vos de monitoramento de

aspectos de saúde de portadores de doenças crônicas, tema regulado pela ANS e,

eventualmente, pela ANVISA

Agradeço a sua atenção com esta questão.

Atenciosamente,

Eduardo Garcia




Qui, 23 de Ago de 2012 11:23

Assunto : Re: CERTICS - contato

Para : AÇÃ O P&D BRASIL

Prezada,


O endereço do site, com todas as informações sobre a metodologi a e dua dinamica

encontra-se disponível no endereçco:

www.certics.cti.gov.r

Desta forma todas as contribuições devem ser feitas por meio do endereço:

[email protected]

Agradecemos o interesse e disposição para participar do processo.

Atenciosamente

Angela Maria A lves


De: "AÇÃ O P&D BRASIL"


Cc: "AÇÃ O P&D BRASIL", , "Rafael Boeing"

Enviadas: Quarta-feira, 22 de Agosto de 2012 18:12:00

Assunto: CERTICS - contato

Prezados,

Solicitamos informações quanto à Consulta Pública Programa TI Maior, buscando disciplinar

o processo de certificação para desenvolvimento de software.

Temos interesse em contribuir para o documento.

http://www.certics.cti.gov.br/index.html

CERTICS é uma certificação que identifica, credencia e diferencia software e seus

serviços associados * , gerando valor local e

competitividade global para o Brasil. É um instrumento do Programa Estratégico de

Software e Serviços de Tecnologia da Informação(TI Maior) lançado em agosto de 2012.”

No aguardo do contato.

Rosilda Prates

P&D BRA SIL

Associação Nacional das Indústria com Tecnologia Desenvolvida no País.

Rosilda Prates

Diretora Executiva.




Qui, 23 de Ago de 2012 11:25

Assunto : Re: Certificação de software.

Para : Joao Farias

Prezado,


O endereço do site, com todas as informações sobre a metodologi a e sua dinâmica

encontra-se disponível no endereçco:

www.certics.cti.gov.r


279

Desta forma todas as contribuições devem ser feitas por meio do endereço:

[email protected]

Agradecemos o interesse e disposição para participar do processo.

Atenciosamente

Angela Maria A lves


De: "Joao Farias"


Enviadas: Quarta-feira, 22 de A gosto de 2012 16:48:43

Assunto: Certificação de software.

Boa tarde. Gostaria de mais informações sobre a certificação de software. Como funciona o

processo? O quê preciso

submeter?

Muito obrigado.

João Farias

Consultor de Segurança

===========


consulta pÚblica para metodologia de … · relatório final da consulta pública para a...

Documents