Nota Técnica SEFTI/TCU nº 05 – versão 1.0 Brasília, 30 de abril de 2010

Assunto: Condições em que há possibilidade de exigência da demonstração de qualidade de processo em contratações de serviços de software, a exemplo de CMMI e XXX.XX.

I OBJETIVO

1. Caracterizar, a partir do arcabouço técnico, legal e jurisprudencial, as condições em que há possibilidade de exigência da demonstração de qualidade de processo em contratações de serviços de software.

II MOTIVAÇÃO

2. Neste documento, utilizam-se as seguintes definições:

Processo de software: designa o conjunto de atividades relacionadas com a criação (desenvolvimento) e a manutenção (evolutiva, adaptativa ou corretiva) de produto(s) de software, realizadas por pessoal interno, por terceiros contratados ou ainda realizadas de forma mista. Essas atividades incluem as atividades de especificação, projeto, implementação, testes, implantação e a interação com subcontratados, realizadas por meio de ferramentas, métodos, técnicas e protocolos predefinidos e que disciplinam a interação produtiva entre as pessoas envolvidas, com o objetivo de produzir software que atenda ao escopo, à qualidade e ao custo projetados. No Brasil, a norma ABNT NBR ISO/IEC 12207 descreve o ciclo de vida de software e serve de referência para a implementação interna do processo de software e para a contratação de tais serviços no mercado;

Serviços de software: designa todo tipo de serviço contratado de desenvolvimento ou manutenção de software sob encomenda, ou seja, aquele cuja propriedade intelectual pertença ao contratante, nos termos do art. 4º da Lei 9.609/1998. Portanto, aqui não estão incluídos os softwares vendidos prontos, com ou sem customização.

3. A análise sistemática da legislação de licitações e contratos na área de Tecnologia da Informação (TI) demonstrou1 a derrogação da obrigatoriedade de adoção de licitação do tipo técnica e preço para bens e serviços de informática, conforme consta do art. 45, § 4º, da Lei nº 8.666/1993. Em seu lugar, vige atualmente a regra geral de contratação por meio da modalidade pregão (do tipo menor preço), na medida em que os bens e serviços de informática geralmente apresentam padrões de desempenho e qualidade que podem ser objetivamente definidos no edital, por meio de especificações usuais no mercado, conforme disposto pela Lei nº 10.520/2002, art. 1º, c/c Decreto nº 5.450/2005, art. 4º. Esta interpretação está em conformidade com o Acórdão nº 2.471/2008-TCU-Plenário.

4. Os padrões de qualidade em serviços de software, para fins de contratação, são usualmente descritos em termos do enquadramento dos processos de software adotados nos níveis de capacidade dos modelos CMMI ou XXX.XX (GUERRA; XXXXX, 2004, p. 9-18, 33-46; SOFTEX, 2008, p. 5). Por isso, seria prudente adotar nas aquisições públicas de tais serviços mecanismos semelhantes de exigência de demonstração de qualidade, com o objetivo de reduzir os riscos de frustração de resultados do contrato.

5. Porém, predomina no TCU o posicionamento de que não se pode exigir a avaliação formal (popularmente citada como “certificação” ou “atestação”) de qualidade de processo de software como critério de habilitação. Seria então possível a sua exigência como requisito

obrigatório na avaliação da proposta técnica, ou seria possível somente a sua pontuação em licitações do tipo técnica e preço?

6. A presente Nota Técnica pretende solucionar esse aparente conflito por meio de entendimentos que consideram, simultaneamente, os requisitos legais, as práticas usuais no mercado de serviços de software, a regra geral de uso do pregão para aquisição de serviços padronizados e a fundamentação de entendimentos anteriores do TCU, e ainda contribuir para resolver os seguintes problemas:

Diante da mudança da regra geral de licitação de serviços de TI, do tipo técnica e preço para o tipo menor preço pela modalidade pregão, o corpo técnico do TCU carece de esclarecimentos sobre como avaliar a legalidade, a legitimidade e a economicidade da inserção de requisitos obrigatórios de qualidade de processo de software nas contratações de serviços de software;

Os gestores públicos das áreas de TI, jurídica e administrativa, habituados aos posicionamentos do TCU em favor da pontuação de “certificados” de qualidade, carecem agora de orientação jurídica segura sobre a possibilidade de exigência de demonstração de qualidade mínima aceitável de processo de software nas contratações de serviços de software, quando licitadas por pregão;

Há fornecedores de serviços de software que ainda insistem na tese da inadequação do pregão para contratação desse tipo de serviços e com frequência interpõem recursos à Administração, ao TCU ou ao poder judiciário, questionando a exigência de “certificados” de qualidade de processo de software, o que sobrecarrega essas instâncias do poder público.

III ENTENDIMENTOS

Entendimento I. A adoção das normas técnicas brasileiras relativas à Engenharia de Software como referência é recomendável para alcançar a eficácia e a efetividade na realização dos objetivos da contratação de serviços de software e para contribuir com a melhoria da eficiência e da economicidade no consumo dos recursos da Administração envolvidos.

Entendimento II. As normas técnicas brasileiras para avaliação da qualidade de processo e de produto de software conferem objetividade à avaliação das contratações de serviços de software, e podem ser usadas para verificação da conformidade das propostas ofertadas pelos licitantes com os requisitos estabelecidos no edital.

Entendimento III. É vedada a exigência de avaliação (ou “certificado”) de qualidade de processo de software, a exemplo de CMMI ou XXX.XX, como requisito para habilitação em licitação, por ausência de previsão legal, por implicar em despesas anteriores à contratação e desnecessárias à competição e por ferir a isonomia, restringindo injustificadamente a competição.

Entendimento IV. Nas licitações de serviços de software, a comprovação da capacidade técnica da licitante tomará por base atestado(s), que reflita(m) a execução satisfatória de objeto compatível com as características do objeto licitado, segundo o processo de software do contratante e as normas técnicas que regulamentam esses serviços, bem como em termos de quantidades e prazos demandados. O método de avaliação de atestado(s) constará do edital, sendo que a apreciação de avaliação oficial de qualidade de processo de software (como XXX.XX ou CMMI) poderá ser usada para sanar dúvida e aceitar atestado no que refere à compatibilidade de características, mas a mera ausência dessa avaliação não poderá ser causa de invalidação de atestado apresentado.

Entendimento V. Nas licitações de serviços de software, não é possível exigir avaliação (ou “certificado”) de qualidade de processo de software, a exemplo de CMMI ou XXX.XX, como requisito técnico obrigatório da proposta técnica, visto que a avaliação de capacidade técnica se dá exclusivamente na fase de habilitação. Mas é possível incluir, na especificação técnica dos

serviços a serem realizados, todos os resultados esperados que, segundo modelos de qualidade de processo aderentes à norma ABNT NBR ISO/IEC 15.504, tais como CMMI ou XXX.XX, caracterizam um dado nível de capacidade de processo de software, desde que tal nível reflita as escolhas estratégicas da organização para o seu processo de software e a sua real capacidade de avaliar tecnicamente os artefatos e produtos entregues.

Entendimento VI. Em decorrência do disposto no art. 23 da Lei nº 7.232/1984 e no art. 75 da Lei nº 8.666/1993, é permitido exigir, para solução de conflitos contratuais, a avaliação de artefatos específicos por avaliador independente oficialmente autorizado, a custo da contratada, desde que justificado.

IV FUNDAMENTAÇÃO LEGAL

Acórdão 1.603/2008-TCU-Plenário. Acórdão 2.471/2008-TCU-Plenário.

Constituição da República Federativa do Brasil, de 5 de outubro de 1988, art. 37, caput e XXI. Decreto-lei 200/1967, art. 10, § 7º

Decreto n° 1.422, de 20 de março 1995, art. 1º, III, "a". Decreto n° 5.233, de 6 de outubro de 2004, anexo.

Emenda Constitucional nº 19, de 04 de junho de 1998. Lei n° 7.232, de 29 de outubro de 1984, art. 23.

Lei n° 8.078, de 11 de setembro de 1990, art. 20, caput e § 2º, e art. 39, VIII.

Lei n° 8.666, de 21 de junho de 1993, art. 3º, caput e § 1º, I, art. 6º, X, art. 12, II, V e VI, art. 30, II, § 1º e § 3º, art. 40, inciso VII, art. 44, caput e § 1º, art. 45, caput, art. 46, § 1º, § 2º e § 3º, art. 73, I, "b" e art. 75.

Lei n° 9.609, de 19 de fevereiro de 1998, art. 4º.

V ANÁLISE

V.1 Legalidade da exigência de demonstração de qualidade em processo de software

7. Para examinar a legalidade de exigência de avaliações de qualidade, a exemplo de CMMI e XXX.XX, optou-se nesta Nota Técnica pela avaliação do atendimento aos seguintes princípios e regras legais:

Princípio da eficiência (CF/1988, art. 37, caput), tratado na seção V.1.1;

Princípio do julgamento objetivo (Lei nº 8.666/1993, art. 3º, caput), tratado na seção V.1.2; Pertinência e relevância da exigência editalícia (Lei nº 8.666/1993, art. 3º, §1º, I), tratado na seção V.1.3;

Princípio da isonomia entre os licitantes/interessados (CF/1988, art. 37, XXI; Lei nº 8.666/1993, art. 3º), tratado na seção V.1.4.

V.1.1 Atendimento ao princípio da eficiência

8. O princípio da eficiência foi inserido na Constituição Federal brasileira por meio da Emenda Constitucional nº 19, de 4 de junho de 1998, no contexto da Reforma do Estado, com o propósito de melhorar a desempenho do Estado e de garantir a boa prestação de serviços aos cidadãos. Esse princípio orienta a necessidade de alcance de “resultados favoráveis com os menores custos possíveis” (FURTADO, 2007, p. 112).

9. O Decreto nº 5.233/2004 (já revogado), que estabeleceu as normas para a gestão do Plano Plurianual 2004-2007, definiu em glossário que eficiência “é a medida da relação entre os recursos efetivamente utilizados para a realização de uma meta para um projeto, atividade ou programa frente a padrões estabelecidos”.

10. Assim, o alcance da eficiência pressupõe a adoção de métodos refinados de trabalho que permitam alcançar resultados com a qualidade necessária com menor consumo de recursos. Mas, que padrão de qualidade poderia ser considerado o mínimo necessário? E que métodos de trabalho poderiam realizar tal padrão mínimo de qualidade a custos minimizados?

11. No Brasil, já existem padrões de qualidade em serviços de software bem definidos, publicados e mantidos pela Associação Brasileira de Normas Técnicas (ABNT), instituição integrante do Conselho Nacional de Metrologia (Conmetro) (Decreto nº 1.422/1995, art. 1º, III, alínea “a”). A ABNT dispõe atualmente de diversas normas relativas à Engenharia de Software, tais como NBR ISO/IEC 25000 (qualidade de produto de software), NBR ISO/IEC 12207 (modelo de referência para processo de software) e NBR ISO/IEC 15504 (modelo para avaliação de processo).

12. A legislação dá suporte à exigência de atendimento a padrões de qualidade, como segue.

13. O Decreto-lei nº 200/1967 condiciona as contratações de serviços no mercado à existência de fornecedores desenvolvidos e capacitados:

Art. 10. A execução das atividades da Administração Federal deverá ser amplamente descentralizada. [...] § 7º Para melhor desincumbir-se das tarefas de planejamento, coordenação, supervisão e contrôle e com o objetivo de impedir o crescimento desmesurado da máquina administrativa, a Administração procurará desobrigar-se da realização material de tarefas executivas, recorrendo, sempre que possível, à execução indireta, mediante contrato, desde que exista, na área, iniciativa privada suficientemente desenvolvida e capacitada a desempenhar os encargos de execução. (Decreto-lei nº 200/1967, art. 10, § 7º)

14. A Política Nacional de Informática (Lei nº 7.232/1984) estabeleceu a obrigatoriedade da garantia de qualidade de serviços de TI, a custo de seus produtores, como segue:

Art. 23. Os produtores de bens e serviços de informática garantirão aos usuários a qualidade técnica adequada desses bens e serviços, competindo-lhes, com exclusividade, o ônus da prova dessa qualidade. (Lei nº 7.232/1984)

15. A Lei nº 8.666/1993 considera exigível o atendimento às normas técnicas pertinentes a serviços em geral:

Art. 6º Para os fins desta Lei, considera-se: [...] X - Projeto Executivo - o conjunto dos elementos necessários e suficientes à execução completa da obra, de acordo com as normas pertinentes da Associação Brasileira de Normas Técnicas - ABNT; [...]

Art. 12. Nos projetos básicos e projetos executivos de obras e serviços serão considerados principalmente os seguintes requisitos: [...] II - funcionalidade e adequação ao interesse público; [...] V - facilidade na execução, conservação e operação, sem prejuízo da durabilidade da obra ou do serviço; VI - adoção das normas técnicas, de saúde e de segurança do trabalho adequadas; [...] (Lei nº 8.666/1993, art. 6º, X, e art. 12, II, V e VI, grifos nossos)

16. A Lei nº 8.078/1990 (Código de Defesa do Consumidor) também considera exigível o atendimento aos requisitos de qualidade estabelecidos pela ABNT:

Art. 20. O fornecedor de serviços responde pelos vícios de qualidade que os tornem impróprios ao consumo ou lhes diminuam o valor, [...] § 2° São impróprios os serviços que se mostrem inadequados para os fins que razoavelmente deles se esperam, bem como aqueles que não atendam as normas regulamentares de prestabilidade.

Art. 39. É vedado ao fornecedor de produtos ou serviços, dentre outras práticas abusivas: [...] VIII - colocar, no mercado de consumo, qualquer produto ou serviço em desacordo com as normas expedidas pelos órgãos oficiais competentes ou, se normas específicas não existirem, pela Associação Brasileira de Normas Técnicas ou outra entidade credenciada pelo Conselho Nacional de Metrologia, Normalização e Qualidade Industrial (Conmetro); [...] (Lei nº 8.078/1990, grifos nossos)

17. O Quadro 1 apresenta as normas técnicas da ABNT em vigor para a área de Engenharia de Software, tema que vem recebendo atenção do TCU (Acórdãos nos 1.603 e 2.471/2008-TCU- Plenário):

Quadro 1. ABNT, Normas relacionadas à Engenharia de Software.

Norma	Título
ABNT NBR ISO/IEC 12207	Engenharia de sistemas e software - Processos de ciclo de vida de software
ABNT NBR ISO/IEC 14102	Tecnologia de informação - Orientação para avaliação e seleção de ferramentas CASE2
ABNT NBR ISO/IEC 14143-1	Tecnologia de informação - Medição de software - Medição de tamanho funcional Parte 1: Definição de conceitos
ABNT ISO/IEC TR 14471	Tecnologia da informação - Engenharia de software - Orientação para adoção de ferramentas CASE
ABNT NBR ISO/IEC 14598	Tecnologia de informação - Avaliação de produto de software (seis partes)
ABNT NBR ISO/IEC 15288	Engenharia de sistemas e software — Processos de ciclo de vida de sistema
ABNT NBR ISO/IEC 15504	Tecnologia da informação - Avaliação de processo (sete partes)
ABNT NBR ISO/IEC 15939	Engenharia de sistemas e de software - Processo de medição
ABNT NBR ISO/IEC série 25000	Engenharia de software - Requisitos e avaliação da qualidade de produtos de software (SQuaRE3) (cinco normas)
ABNT NBR ISO/IEC 9126-1	Engenharia de software – Qualidade de produto Parte 1: Modelo de qualidade

Fonte: ABNT (2009)

18. É importante ressaltar que as normas ABNT permitem estabelecer parâmetros objetivos de qualidade e padrões para avaliação de processos e produtos de software de forma a maximizar as chances de alcance da qualidade exigida a custos compatíveis, em serviços internos ou contratados.

19. Por exemplo, veja-se o que a NBR 15.504-1 define como propósito e benefícios:

A ABNT NBR ISO/IEC 15504 provê uma abordagem estruturada para avaliação de processos com os seguintes objetivos:

[...]

Um método para uma organização melhorar a qualidade dos produtos é através da utilização de um método provado, consistente e confiável para avaliar o estado de seus processos e utilizar os resultados como parte de um programa de melhoria coerente.

A utilização da avaliação de processos dentro de uma organização deve favorecer:

- a cultura da melhoria contínua e o estabelecimento de mecanismos apropriados para suportar e manter essa cultura;

- a engenharia de processos para satisfazer necessidades de negócio;

- a otimização de recursos.

Através disto, é esperado que a organização se torne uma organização capaz que maximize sua capacidade de resposta para o cliente e para requisitos de mercado, que minimize o custo total do ciclo de vida de seus produtos e, como resultado, maximize a satisfação do usuário final.

Adquirentes podem se beneficiar com o uso da avaliação de processo. Sua utilização na determinação da capacidade pode:

- reduzir incertezas na seleção de fornecedores por permitir que os riscos associados com a capacidade do fornecedor sejam identificados antes de assinar o contrato;

- permitir controles apropriados para a contenção de riscos;

- prover uma fundamentação quantitativa para escolhas ao equilibrar as necessidades do negócio, requisitos e custo estimado de projeto em relação à capacidade dos fornecedores concorrentes. [...] (ABNT NBR 15504-1, 0000, x. 0-0, xxxxxx nossos)

20. Assim, para estabelecer um padrão de eficiência aceitável de processo de software, há necessidade de estabelecer um padrão de qualidade aceitável, que exprima a expectativa do cliente e represente valor de negócio, o que é exigível pela Lei nº 7.232/1984 . A adoção das normas técnicas é um caminho reconhecido em nível nacional para se alcançar esses objetivos, como previsto na Lei nº 8.078/1990 e na Lei nº 8.666/1993.

21. Portanto, a partir do raciocínio esposado por Xxxxxxx (2007, p. 111-117), pode-se dizer que a não exigência de qualidade em serviços contratados conduz:

a. à ineficácia, ou seja, à incapacidade de se realizar adequadamente o objeto da contratação;

b. à ineficiência, pois, mesmo a custos mais baixos, os benefícios pretendidos4 com a execução do objeto da contratação não se realizam adequadamente;

c. à inefetividade, ou seja, à incapacidade de resolver os problemas que motivaram a contratação; e

d. à falta de economicidade, pois não terá sido obtida a melhor alocação dos escassos recursos públicos em decorrência do não alcance dos melhores benefícios em favor da sociedade.

22. Ante o exposto, chega-se ao seguinte entendimento:

Entendimento I. A adoção das normas técnicas brasileiras relativas à Engenharia de Software como referência é recomendável para alcançar a eficácia e a efetividade na realização dos objetivos da contratação de serviços de software e para contribuir com a melhoria da eficiência e da economicidade no consumo dos recursos da Administração envolvidos.

V.1.2 Atendimento ao princípio do julgamento objetivo

23. A seguir, é necessário examinar se o uso das normas técnicas existentes permite o julgamento objetivo da qualidade das propostas técnicas de licitantes em um certame cujo objeto seja a contratação de serviços de software.

24. A Lei nº 8.666/1993 exige a utilização de critérios objetivos (e veda qualquer critério subjetivo que possa afetar a isonomia) na avaliação das propostas dos licitantes (Lei nº 8.666/1993, art. 3º, caput, art. 40, inciso VII, art. 44, caput e § 1º, art. 45, caput, e art. 46, § 1º, § 2º e § 3º).

25. Assim, é obrigatório que a especificação técnica do objeto da licitação seja feita por meio de requisitos técnicos objetivos, de modo que seja possível avaliar a aderência das propostas dos licitantes aos requisitos definidos no edital por meio de critérios objetivos.

26. Para alcançar objetividade na especificação técnica para contratação de serviços de software de modo a tornar possível a aferição da qualidade de processos e produtos é necessária uma definição do processo de gerenciamento do desenvolvimento e manutenção do software. Uma organização sem esse processo definido:

a. atua de forma reativa a cada demanda que surge;

b. induz seus profissionais a despender a maior parte dos seus esforços, de forma improvisada, em solucionar problemas imediatos, em detrimento dos problemas estruturais;

c. não possui critérios objetivos para avaliar a condução do desenvolvimento e manutenção do software; e

d. não dispõe de mecanismos que induzem e projetam a qualidade do produto.

27. Um processo para desenvolvimento e manutenção de software reúne e aplica diversas disciplinas da Engenharia de Software, que é a área do conhecimento voltada para a especificação, desenvolvimento e manutenção de sistemas de software com a aplicação de tecnologias e práticas, objetivando organização, produtividade e qualidade. Vários elementos (conceitos, modelos, métodos e processos) da Engenharia de Software têm sido largamente referenciados e utilizados no mercado de serviços de software em todo o mundo. Uma das evidências dessa aceitação pelo mercado é a conversão de vários desses elementos da Engenharia de Software em normas mundialmente aceitas, como as normas ISO/IEC 12207, 15504 e 25000 que já foram introduzidas no Brasil pela ABNT.

28. Conforme definido na ABNT NBR ISO/IEC 15504-1 (2008, p. 7), o mecanismo de avaliação ali detalhado é “um método provado, consistente e confiável para avaliar o estado de seus

processos [das organizações]” e “pode prover uma comparação objetiva das organizações”

(grifo nosso).

29. Além disso, como as normas ABNT definem os padrões técnicos para comercialização de bens e serviços de TI no mercado brasileiro, ficam também satisfeitas as exigências legais citadas nos itens 13 a 16.

30. Chega-se, portanto, ao seguinte entendimento:

Entendimento II. As normas técnicas brasileiras para avaliação da qualidade de processo e de produto de software conferem objetividade à avaliação das contratações de serviços de software, e podem ser usadas para verificação da conformidade das propostas ofertadas pelos licitantes com os requisitos estabelecidos no edital.

V.1.3 Pertinência e relevância da exigência de qualidade de processo de software, a exemplo de CMMI e XXX.XX, em contratações públicas

31. Para avaliar se a exigência de demonstração de qualidade de processo de software atende ao requisito legal de pertinência e relevância nas contratações públicas (Lei nº 8.666/1993, art. 3º, § 1º, inciso I), deve-se considerar que as normas NBR ISO/IEC 12207 e 15504 reconhecem que o processo de aquisição de software é parte essencial do processo de software de uma organização. Por isso, pode-se dizer que a qualidade do processo de software de uma organização pública contratante depende da qualidade de seu processo de aquisição de software de terceiros. Por exemplo, se a área de TI do contratante falha em gerenciar os requisitos repassados à contratada e em acompanhar e fiscalizar a sua execução, os produtos gerados dificilmente terão qualidade.

32. Por esse motivo, qualquer organização pública que pretenda contratar serviços de software precisa ter processos internos com qualidade compatível com aquela demandada do contratado, a fim de garantir a efetividade do contrato.

33. Nesse sentido, tem relevo o Programa Brasileiro de Qualidade e Produtividade em Software (PBQP-SW), criado em 1993 (BRASIL, 2009a) para estimular as empresas nacionais a melhorarem seus processos de software como forma de melhorar a competitividade do setor de software brasileiro, considerado estratégico.

O PBQP Software procura estimular a adoção de normas, métodos, técnicas e ferramentas da qualidade e da Engenharia de Software, promovendo a melhoria da qualidade dos processos, produtos e serviços de software brasileiros, de modo a tornar as empresas mais capacitadas a competir em um mercado globalizado. Especificamente, busca-se a melhoria contínua do grau de satisfação dos seus clientes, da qualidade de vida no trabalho e no País, e da lucratividade e competitividade das empresas brasileiras de software. (BRASIL, 2009c)

34. Algumas das estratégias e ações do PBQP-SW podem ser destacadas por envolverem direta ou indiretamente a adoção dos conceitos da qualidade de software na Administração Pública, como segue:

Quadro 2. Estratégias e ações do PBQP-SW relacionados, direta ou indiretamente, à adoção de qualidade de software por organizações governamentais.

Tema da estratégia/ação	Referência (item de estratégia/ação)
Conscientização de dirigentes governamentais acerca da importância da melhoria da qualidade e produtividade no setor de software	ESW/1/02; 1.2.1
Adoção da gestão da qualidade e produtividade em software	ESW/2/01; 2.1.1; 2.1.2; 2.1.3; 2.1.4 ESW/2/02; 2.2.1; 2.2.2; 2.2.3 ESW/6/01; 6.1.1; 6.1.2; 6.1.3; 6.1.4; 6.1.5
Diagnóstico de processo de software	ESW/2/04; 2.4.4
Treinamento de multiplicadores para o mercado	ESW/3/01; 3.1.2; 3.1.3
Capacitação em qualidade de software	ESW/3/02; 3.2.1; 3.2.4; 3.2.5
Envolvimento dos órgãos de orientação ao consumidor com respeito à	ESW/4/03; 4.3.2; 4.3.4; 4.3.5

qualidade de software	ESW/5/08; 5.8.1 ESW/5/09; 5.9.1
Difusão das normas técnicas de software	ESW/4/05; 4.5.6; 4.5.7; 4.5.8; 4.5.9; 4.5.10
Criação de grupos técnicos de interesse em software	ESW/4/06; 4.6.4
Alinhamento governamental em torno do PBQP-SW	ESW/5/01; 5.1.1; 5.1.2
Indução da qualidade e produtividade em software por meio de financiamento estatal e do uso do poder de compra do Estado	ESW/5/02; 5.2.1; 5.2.2 ESW/5/03; 5.3.1; 5.3.2; 5.3.3; 5.3.4 ESW/5/04; 5.4.1 ESW/5/05; 5.5.1
Consolidação da Engenharia de Software	ESW/6/02; 6.2.1; 6.2.2; 6.2.3; 6.2.4; 6.2.5; 6.2.6

Fonte: BRASIL (2009b)

35. Uma das iniciativas fomentadas pelo PBQP-SW foi o desenvolvimento do XXX.XX (vide estratégia ESW/4/05), hoje mantido pela SOFTEX5, entidade parcialmente financiada pelo Ministério de Ciência e Tecnologia - MCT, com o objetivo de, entre outros, reduzir o custo de implementação e avaliação de processo de software.

36. Os modelos de qualidade de processo de software mais adotados no Brasil incluem preocupação com a qualidade exigida nas contratações de terceiros. Por exemplo, o modelo de avaliação de processo de software Capability Maturity Model (CMM, precursor do CMMI explicitado na seção V.1.3.1) inclui a gestão de subcontratação de software como um processo-chave no nível 2 de capacidade/maturidade, no qual prevê-se que a seleção do fornecedor é feita com base na avaliação da sua capacidade de realizar o trabalho, em termos de engenharia e gestão de software (PAULK et al., 1995, p. 163-164).

37. O mesmo ocorre com os modelos CMMI e XXX.XX, modelos mais modernos de avaliação do processo de software, que implementam as normas técnicas ISO/IEC 12207 e 15504 e são bastante usuais e reconhecidos no mercado brasileiro. A gerência da contratação de serviços de software é considerada exigível já no mais baixo nível de maturidade ou capacidade descrita por esses modelos, como apresentado sucintamente a seguir.

V.1.3.1 CMMI

38. O Capability Maturity Model – Integration (CMMI) é um modelo desenvolvido pelo Software Engineering Institute (SEI) da Universidade de Carnegie-Mellon. Evolução do modelo CMM, lançado no início dos anos 90, o CMMI:

[...] é um modelo para melhoria da maturidade dos processos de desenvolvimento de produtos e serviços. Consiste nas melhores práticas que endereçam atividades de desenvolvimento e manutenção, cobrindo o ciclo de vida do produto, desde a concepção até a entrega e manutenção. (SOFTWARE ENGINEERING INSTITUTE, 2008, prefácio , p. i, tradução livre)

39. Nesse modelo, 22 áreas de processo de software são divididas em quatro categorias: gerência de processos, gerência de projetos, suporte e engenharia. Na medida em que os processos preconizados pelo modelo são implantados, a maturidade organizacional tende a aumentar em termos de melhor planejamento, coordenação e controle. Isto pode ensejar a melhoria dos resultados dos processos e maior qualidade dos produtos entregues ao cliente.

40. São cinco os níveis de maturidade do CMMI: Inicial (Nível 1);

Gerenciado (Nível 2);

Definido (Nível 3);

Gerenciado quantitativamente (Nível 4); Otimizado (Nível 5).

41. Cada um dos níveis contém um conjunto de processos com um foco específico. O Quadro 3 aponta os processos que compõem cada nível de maturidade do CMMI.

Quadro 3. Distribuição dos processos em ordem crescente de Maturidade no CMMI, com

destaque para contratação de terceiros.

Nível de Maturidade	Processos
1 – Inicial	- Nem todos os processos do nível 2 foram implementados;
2 – Gerenciado	- Gerenciamento de Requisitos; - Planejamento de Projeto; - Monitoração e Controle do Projeto; - Gerenciamento de Acordo com Fornecedor; - Medição e Análise; - Garantia da Qualidade de Processo e Produto; - Gerência de Configuração;
3 – Definido	- Desenvolvimento de Requisitos; - Solução Técnica; - Integração de Produto; - Verificação; - Validação; - Foco no Processo Organizacional; - Definição de Processo Organizacional; - Treinamento Organizacional; - Gerenciamento Integrado de Projeto; - Gerenciamento de Riscos; - Análise de Decisão e Resolução;
4 – Gerenciado quantitativamente	- Desempenho de Processo Organizacional; - Gerenciamento Quantitativo de Projeto;
5 – Otimizado	- Inovação Organizacional e Deployment; - Análise Causal e Resolução;

Fonte: adaptado de SOFTWARE ENGINEERING INSTITUTE (2008, grifo nosso)

42. Por exemplo, no nível Gerenciado (nível de maturidade 2):

o processo de Gerenciamento de Requisitos permite estabelecer procedimentos para coleta, especificação e entrega dos requisitos, o que é essencial para o bom entendimento do negócio que será apoiado pelo software a ser desenvolvido ou mantido;

os processos de Planejamento de Projeto e Monitoração e Controle de Projeto permitem planejar, coordenar e medir os resultados do desenvolvimento do software a fim de maximizar a produtividade, bem como realizar a entrega do produto em conformidade com a especificação dos requisitos, com a quantidade aceitável de erros e dentro do cronograma estabelecido.

V.1.3.2 XXX.XX

43. O modelo de Melhoria de Processo do Software Brasileiro (XXX.XX) é parte de programa governamental “coordenado pela Associação para Promoção da Excelência do Software Brasileiro (SOFTEX) [...] e baseia-se nos conceitos de maturidade e capacidade de processo para a avaliação e melhoria da qualidade e produtividade de produtos de software e serviços correlatos” (SOFTEX, 2009, p. 4 e 6).

44. Capacidade de um processo é a expressão do “grau de refinamento e institucionalização com que o processo é executado na organização/unidade organizacional” (SOFTEX, 2007, p. 16). Já maturidade de processo refere-se à existência de mecanismos de melhoria contínua do processo de software. Com efeito, a avaliação do nível de maturidade de uma organização, em relação à implementação dos processos propostos pelo XXX.XX, permite identificar se os processos utilizados para o desenvolvimento e manutenção de software seguem boas práticas consolidadas no mercado, potencializando melhorias na entrega ou manutenção do produto e mitigando o risco de erros e atrasos no projeto.

45. O XXX.XX também é dividido em níveis de maturidade. São sete níveis, referenciados pelas letras de G (menor maturidade) a A (maior maturidade), que indicam o aprimoramento da organização na implementação de processos essenciais para a melhoria do desenvolvimento e

manutenção de software em seu ambiente institucional. Ainda, segundo o Guia Geral do XXX.XX, “os níveis de maturidade estabelecem patamares de evolução de processos, caracterizando estágios de melhoria da implementação de processos na organização” (SOFTEX, 2007, p. 16). O Quadro 4 aponta os processos que compõem cada nível de maturidade do XXX.XX.

Quadro 4. Distribuição dos processos em ordem crescente de maturidade no XXX.XX, com destaque para contratação de terceiros.

Nível de Maturidade	Processos
G – Parcialmente Gerenciado	- Gerência de Requisitos - Gerência de Projetos
F – Gerenciado	- Medição - Garantia da Qualidade - Gerência de Configuração - Gerência de Portfólio de Projetos - Aquisição
E – Parcialmente Definido	- Gerência de Projetos (evolução) - Gerência de Reutilização - Gerência de Recursos Humanos - Definição do Processo Organizacional - Avaliação e Melhoria do Processo Organizacional
D – Largamente Definido	- Verificação - Validação - Projeto e Construção do Produto - Integração do Produto - Desenvolvimento de Requisitos
C – Definido	- Gerência de Riscos - Desenvolvimento para Reutilização - Gerência de Decisões
B – Gerenciado Quantitativamente	- Gerência de Projetos (evolução)
A – Em Otimização	Apenas melhoria contínua dos processos dos níveis anteriores

Fonte: adaptado de SOFTEX (2009, p. 22, grifo nosso)

V.1.3.3 Comparando o CMMI e o XXX.XX

46. Em resposta a questionamentos formulados no Ofício nº 37/2008-Sefti-TCU, a SOFTEX (2008) informou que, no desenvolvimento do XXX.XX, procurou manter a compatibilidade com o modelo CMMI. Por exemplo, o nível “F” de maturidade do XXX.XX corresponde ao nível “2” do CMMI, em que o foco está mais voltado para a Gerência de Requisitos e Gerência de Projetos, além de processos correlatos como Gerência de Configuração e Garantia da Qualidade. A correlação dos níveis de maturidade entre CMMI e XXX.XX está detalhada no Quadro 5.

Quadro 5. Comparação entre NBR 15504, CMMI e XXX.XX

Níveis	Níveis	Níveis
NBR ISO/IEC 15504	CMMI	XXX.XX
0	-	-
1	-	-
-	-	G
2	2	F
-	-	E
-	-	D
3	3	C
4	4	B
5	5	A

Fonte: adaptado de SOFTEX (2008)

47. Entretanto, na sua resposta ao ofício precitado, a SOFTEX argumentou que o modelo XXX.XX é ainda mais rigoroso que o CMMI na aderência às normas internacionais, conforme segue:

Para garantir 100% de compatibilidade com o CMMI, todas as práticas do CMMI estão contempladas no MR-MPS [Modelo de Referência do XXX.XX]. Entretanto, visando à conformidade com as normas internacionais ISO/IEC 12207 e 15504-2, as exigências do MR-MPS são maiores do que as do CMMI nos seguintes processos: a) Gerência de Recursos Humanos, que no MR-MPS (conforme disposto nas normas ISO/IEC 12207 e 15504-2) abrange aquisição de pessoal, treinamento organizacional e gerência do conhecimento e no CMMI trata apenas de treinamento organizacional;

b) Gerência de Reutilização e Desenvolvimento para Reutilização estão incluídos no MR-MPS (atendendo requisitos das normas ISO/IEC 12207 e 15504-2) e não existem no CMMI. (SOFTEX, 2008)

48. Além disso, como o número de níveis intermediários de maturidade é maior no XXX.XX, as empresas de software teriam mais facilidade em galgar patamares.

V.1.3.4 Conclusão

49. Como visto na presente seção, as normas técnicas que disciplinam o mercado de serviços de software definem diretrizes claras para o alcance de qualidade em processo de software que tem repercussão na qualidade dos produtos de software. Há modelos comerciais de qualidade de processo software amplamente aceitos no Brasil e que implementam as diretrizes dessas normas.

50. Portanto, a exigência de qualidade em processo de software pode ser considerada pertinente e relevante na contratação de serviços de software.

V.1.4 Atendimento ao princípio da isonomia entre os licitantes/interessados

V.1.4.1 O subprocesso de aquisição de software na NBR ISO/IEC 12207

51. Em decorrência das conclusões das seções anteriores, é possível afirmar que ao gestor incumbe incluir no modelo de gestão contratual os mecanismos necessários e suficientes para garantir a qualidade dos serviços de software contratados e os mecanismos de tratamento das situações em que a qualidade necessária e esperada não estiver sendo alcançada. Mas como fazer isso, sem ferir o princípio da isonomia entre licitantes?

52. Deve-se primeiro ressaltar que o subprocesso de aquisição de software de terceiros também faz parte do ciclo de vida de software (NBR ISO/IEC 12207) e consta dos modelos CMMI (ver os processos do nível 2 no Quadro 3) e XXX.XX (ver os processos do nível F no Quadro 4).

53. Portanto, o ente público que pretenda contratar serviços de software encontrará nas normas NBR ISO/IEC 12207 e 15504, e nos modelos CMMI e XXX.XX, as orientações necessárias para alcançar maturidade nessas contratações. É desejável que os entes públicos utilizem essas referências para sua autoavaliação para fins de melhoria contínua em linha com o princípio da eficiência.

V.1.4.2 A natureza das avaliações de processo de software

54. Em ambos os modelos de avaliação da qualidade de software (CMMI e XXX.XX), são feitas avaliações e não certificações ou atestações de processo, como erroneamente referido com frequência na mídia brasileira e nas contratações públicas. Por essa razão, a presente nota técnica adota o termo “certificação” entre aspas juntamente ao termo correto que é avaliação.

55. A avaliação refere-se exclusivamente a uma subunidade organizacional específica, tem prazo de validade de três anos e refere-se apenas aos subprocessos de software que os

avaliadores credenciados efetivamente encontraram sendo realizados por meio de evidências obtidas in loco em entrevistas e documentos.

56. Por essa razão, nenhuma avaliação garante que a empresa efetivamente adote os processos maduros em todos os seus contratos, especialmente nas demais subunidades organizacionais não avaliadas. Essa ausência de garantia é ainda mais forte quando ocorre prestação de serviços mediante alocação de mão-de-obra na forma de postos de trabalho, pois, nesse caso, o processo de software efetivamente executado pelos empregados da empresa prestadora de serviço não está na sua própria esfera de governabilidade, mas na da organização contratante.

57. Além disso, não há mecanismos de perda do reconhecimento oficial de avaliador caso a empresa pratique processo de software em patamar de qualidade inferior em alguma de suas contratações, porque a avaliação refere-se à subunidade específica, aos seus mecanismos de controle de qualidade e aos seus projetos que foram especificamente avaliados. Portanto, uma avaliação de qualidade de processo de software não pode ser extrapolada para toda a empresa.

V.1.4.3 Vedação à exigência de avaliação independente de processo de software como requisito de habilitação

58. O TCU tem se posicionado predominantemente pela vedação da exigência de “certificados” (na verdade, avaliações) de qualidade como requisito de comprovação da qualificação técnica na fase de habilitação. Exemplos desse posicionamento podem ser observados nos acórdãos nos 1.937/2003, 539/2007, 2.521/2008, 189/2009 e 2.681/2009, todos do Plenário do TCU.

59. A Lei nº 8.666/1993 determina o seguinte:

Art. 30. A documentação relativa à qualificação técnica limitar-se-á a:

[...] II - comprovação de aptidão para desempenho de atividade pertinente e compatível em características, quantidades e prazos com o objeto da licitação, e indicação das instalações e do aparelhamento e do pessoal técnico adequados e disponíveis para a realização do objeto da licitação, bem como da qualificação de cada um dos membros da equipe técnica que se responsabilizará pelos trabalhos;

[...] § 1º A comprovação de aptidão referida no inciso II do "caput" deste artigo, no caso das licitações pertinentes a obras e serviços, será feita por atestados fornecidos por pessoas jurídicas de direito público ou privado, devidamente registrados nas entidades profissionais competentes, limitadas as exigências a:

[...] § 3º Será sempre admitida a comprovação de aptidão através de certidões ou atestados de obras ou serviços similares de complexidade tecnológica e operacional equivalente ou superior. (Lei nº 8.666/1993, art. 30, grifos nossos)

60. O texto legal evidencia que o exame da qualificação técnica visa, entre outros objetivos, a assegurar que o licitante está apto para o desempenho do serviço objeto da licitação. Por consequência, negar habilitação nesse quesito a uma empresa significa dizer que ela não comprovou ter a aptidão para a execução do objeto.

61. Para tal comprovação, será sempre admitida a apresentação de certidões ou atestados de realização de serviços de software em características, quantidades e prazos compatíveis com o objeto licitado (Lei nº 8.666/1993, art. 30, II, § 1º e § 3º). Entretanto, uma avaliação CMMI ou XXX.XX diz respeito somente às características técnicas do processo de software realizado em um projeto específico, mas nada diz a respeito das quantidades e prazos executados, para fins de verificação de sua compatibilidade com o objeto específico licitado, conforme requer a Lei.

62. Por isso, é restritivo à competição afirmar que uma empresa está apta a executar um projeto de software somente se foi avaliada nos modelos de mercado, tais como o CMMI ou XXX.XX. Ao contrário, para atender à lei, sempre se deve admitir que uma empresa que realizou determinado serviço está apta a realizar outro similar em termos de características (tecnologias), quantidades e prazos (operacional).

63. Portanto, as avaliações de software, a exemplo de CMMI ou XXX.XX, não atendem à exigência legal de comprovação de aptidão mediante atestação de serviços prestados em características, quantidades e prazos compatíveis com o objeto da licitação, e restringem injustificadamente a competição (Acórdão nº 2.681/2009-TCU-Plenário).

64. Além disso, deve ser ressaltado que uma empresa não tem custos para obter da Administração atestados de serviços que já realizou com qualidade. Porém, há custos na obtenção de avaliações feitas por avaliadores independentes disponíveis no mercado. Por esse motivo, a exigência de avaliações, que não é uma condição legal para atuar no mercado, pode privilegiar os maiores fornecedores em detrimento dos menores, que não disponham dos recursos necessários para contratar os serviços de avaliação independente, embora invistam na qualidade de seus processos de trabalho para competir no mercado e tenham alcançado sucesso quando atuaram como contratados.

65. Chega-se, assim, ao seguinte entendimento:

Entendimento III. É vedada a exigência de avaliação (ou ―certificado‖) de qualidade de processo de software, a exemplo de CMMI ou XXX.XX, como requisito para habilitação em licitação, por ausência de previsão legal, por implicar em despesas anteriores à contratação e desnecessárias à competição e por ferir a isonomia, restringindo injustificadamente a competição.

V.1.4.4 Obrigatoriedade de avaliação da capacidade técnica de licitante

66. Por outro lado, a Constituição Federal, art. 37, XXI, estabelece a necessidade de buscar garantir que o licitante vencedor seja efetivamente capaz de realizar os serviços licitados, o que se reflete na obrigatoriedade de se avaliar a capacidade técnica de licitante, inscrita no art. 30 da Lei nº 8.666/1993.

67. Ali ficou estabelecido que a avaliação da capacidade técnica ocorrerá exclusivamente mediante atestado(s), sem limitação de antiguidade ou de localidade, os quais serão aceitáveis na medida em que comprovem que o licitante já realizou serviços compatíveis com o objeto licitado, em termos de características, prazos e quantidades. As características a que alude a lei são características técnicas do objeto licitado, o que inclui os métodos, técnicas e protocolos essenciais para a realização dos serviços, que constituem, nesse caso, o processo de software do contratante, em conformidade com as normas técnicas.

68. O pressuposto é de que o licitante que já prestou determinado serviço no passado com sucesso poderá fazê-lo novamente no futuro e de que não é adequado à Administração contratar com licitante que jamais tenha prestado tal serviço. Esse pressuposto é razoável e isonômico.

69. Mas, para que um atestado de capacidade efetivamente cumpra o seu papel em buscar garantir que o licitante vencedor efetivamente tenha a experiência necessária em serviço semelhante ao objeto licitado, o método de sua avaliação deve ser rigorosamente concebido.

70. Para evitar a subjetividade no julgamento do(s) atestado(s), o método de sua avaliação deverá obrigatoriamente constar do edital, por extensão do § 1º do art. 44 da Lei nº 8.666/1993, e por aplicação dos princípios da publicidade, igualdade (XXXXX, 2005, p. 394) e da vinculação ao edital.

71. Ainda assim, dúvidas na interpretação do conteúdo de atestados de capacidade técnica não são raras, requerendo lançar mão de mecanismos adicionais de avaliação de seu teor em relação àquele exigido (XXXXXX XXXXX, 2005, p. 340, 418 e 424), o que também deve ser previsto em edital, tais como: diligenciamento às fontes de informação; inspeção in loco para caracterização das evidências de capacidade; requerimento de acesso aos contratos referidos em atestado ou aos seus artefatos; avaliação específica por agente independente oficialmente habilitado.

72. Coerentemente, a apreciação de avaliações oficiais de qualidade de processo de software (como XXX.XX ou CMMI), que é uma fonte relevante de informação sobre a condição técnica do licitante, poderá ser usada para sanar dúvida e aceitar atestado no que refere à compatibilidade de características. Logicamente, a ausência de avaliação não poderá ser razão para negar validade a atestado de capacidade técnica e para negar habilitação.

73. Chega-se, portanto, ao seguinte entendimento:

Entendimento IV. Nas licitações de serviços de software, a comprovação da capacidade técnica da licitante tomará por base atestado(s), que reflita(m) a execução satisfatória de objeto compatível com as características do objeto licitado, segundo o processo de software do contratante e as normas técnicas que regulamentam esses serviços, bem como em termos de quantidades e prazos demandados. O método de avaliação de atestado(s) constará do edital, sendo que a apreciação de avaliação oficial de qualidade de processo de software (como XXX.XX ou CMMI) poderá ser usada para sanar dúvida e aceitar atestado no que refere à compatibilidade de características, mas a mera ausência dessa avaliação não poderá ser causa de invalidação de atestado apresentado.

V.1.4.5 Condições para exigência de evidência de qualidade em processo de software, a exemplo das diretrizes do CMMI ou XXX.XX

74. Como visto na seção V.1.4.4, a avaliação da capacidade técnica do licitante para realização dos serviços é o propósito do exame de qualificação técnica na fase de habilitação (art. 30 da Lei nº 8.666/1993). Nesse sentido, nas licitações de menor preço6, que é o caso geral das licitações em TI (ver item 3), não cabe na fase de julgamento da proposta técnica a avaliação de qualquer requisito que se refira à capacidade técnica da licitante (típica da fase de habilitação), mas somente de requisitos relativos à proposta técnica de serviços em si (XXXXXX XXXXX, 2005, p. 420-421).

75. Consequentemente, também não é possível exigir avaliação oficial de qualidade de processo de software como requisito obrigatório de proposta técnica, pois esse tipo de avaliação refere- se à capacidade da licitante, mensurada em experiência passada, e não à qualidade da proposta técnica destinada à licitação em andamento.

76. Entretanto, isto não quer dizer que o gestor esteja impedido de exigir qualidade em licitações de serviços de software. Ao contrário, isto é possível e tecnicamente indicado pelas normas pertinentes para qualquer organização que tenha compromisso com seu próprio processo de software, pois tanto no CMMI quanto no XXX.XX, a avaliação de capacidade de processo correspondente ao nível 2 da NBR 15504 já inclui a avaliação do processo de contratação de terceiros (Quadro 3 e Quadro 4). Portanto, a ausência de rigor na contratação de terceiros, segundo a norma NBR ISO/IEC 12207, já seria fator impeditivo de reconhecimento de capacidade de processo de software de um ente público que lance mão de terceirização.

77. Assim, se um ente público investiu na melhoria de seu processo de software, alcançou patamares superiores de capacidade e veio a ser avaliado e reconhecido por entidade avaliadora independente, tal reconhecimento pode ser considerado um dos resultados do investimento (financeiro e humano) realizado e um valor patrimonial intangível a ser preservado.

78. Por outro lado, um ente público pode estar investindo na melhoria de seu processo de software, mas ainda não ter se submetido a avaliações para reconhecimento do nível de capacidade pretendido ou nem ter essa pretensão.

79. Em qualquer dos casos, o ente público precisará garantir que qualquer fornecedor contratado entregue todos os resultados esperados7 que caracterizam o nível de capacidade pretendido, como parte da melhoria de seu processo. Mesmo o ente público que não tem interesse em

avaliação oficial de seu processo está obrigado a exigir serviços que tenham qualidade, o que pressupõe a adoção de processos internos de software com maturidade suficiente para manter contratos com terceiros com padronização, confiabilidade e segurança razoáveis (Acórdão nº 1.603/2008-TCU-Plenário, item 9.1.4).

80. Nesse caso, a exigência de que prestadores de serviços de software executem (como resultado do contrato e não como condição para contratação) o processo de software no nível pretendido e entreguem os artefatos e produtos que atendam aos resultados esperados previstos nesse nível é uma condição para atendimento da norma NBR ISO/IEC 12207 e 15504. Dessa forma, o ente público não pode exigir a avaliação oficial de qualidade de processo de software como requisito técnico obrigatório, mas pode (e deve) definir os resultados esperados necessários à execução do serviço no termo de referência, com base nas normas técnicas e nos modelos de referência, tais como o CMMI ou o XXX.XX, que implementam essas normas técnicas e consolidam as melhores práticas de garantia de qualidade em processo de software.

81. Chega-se, assim, ao seguinte entendimento:

Entendimento V. Nas licitações de serviços de software, não é possível exigir avaliação (ou

―certificado‖) de qualidade de processo de software, a exemplo de CMMI ou XXX.XX, como requisito técnico obrigatório da proposta técnica, visto que a avaliação de capacidade técnica se dá exclusivamente na fase de habilitação. Mas é possível incluir, na especificação técnica dos serviços a serem realizados, todos os resultados esperados que, segundo modelos de qualidade de processo aderentes à norma ABNT NBR ISO/IEC 15.504, tais como CMMI ou XXX.XX, caracterizam um dado nível de capacidade de processo de software, desde que tal nível reflita as escolhas estratégicas da organização para o seu processo de software e a sua real capacidade de avaliar tecnicamente os artefatos e produtos entregues.

V.1.4.6 Tratamento das situações de conflito em relação à qualidade dos serviços prestados

82. Eventualmente, pode acontecer que contratante e contratado discordem sobre o atendimento ou não do nível de qualidade exigido. Nesse caso, o art. 75 da Lei nº 8.666/1993 prevê que é possível contar com a realização de contraprova por entidade independente às custas do contratado, como segue:

Art. 75. Xxxxx disposições em contrário constantes do edital, do convite ou de ato normativo, os ensaios, testes e demais provas exigidos por normas técnicas oficiais para a boa execução do objeto do contrato correm por conta do contratado. (Lei nº 8.666/1993, art. 75)

83. Essa orientação está em linha com o disposto na Política Nacional de Informática:

84. Chega-se, portanto, ao seguinte entendimento:

Entendimento VI. Em decorrência do disposto no art. 23 da Lei nº 7.232/1984 e no art. 75 da Lei nº 8.666/1993, é permitido exigir, para solução de conflitos contratuais, a avaliação de artefatos específicos por avaliador independente oficialmente autorizado, a custo da contratada, desde que justificado.

Xxxxxx Xxxxxxxxxxx xx Xxxxx

AUFC – Matrícula TCU nº 7658-9

Xxxxxxx Xxxxx xx Xxxx

AUFC - Matrícula TCU nº 3164-0

De acordo.

Xxxxxxx Xxxxxxx Xxxxxx

Gerente De acordo.

Xxxxxxx Xxxxx Xxxxxxxx Xxxxxx

Secretário

VI Referências

ABNT. Normas da CE 21. Disponível em: <xxxx://xxx.xxxxxxxxxxxx.xxx.xx/xxxxxxxxx.xxxx>. Acesso em: 10 nov. 2009.

ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS - ABNT. ABNT NBR ISO/IEC 15504-1:2008 -

Tecnologia da informação - Avaliação de processo - Parte 1: Conceitos e vocabulário. Objetivo : Esta parte da ABNT NBR ISO/IEC 15504 provê informações sobre conceitos de avaliação de processo e seu uso em dois contextos, o de melhoria de processo e o de determinação de capacidade de processo. Ela descreve como as partes deste conjunto de Normas se integram e provê orientações para sua seleção e uso. Explica os requisitos contidos na ABNT NBR ISO/IEC 15504 e sua aplicabilidade para realizar avaliações. 2008a. Disponível em:

<xxxx://xxx.xxxxxxxxxxxx.xxx.xx/xxxxx.xxxx?XXx0000>. Acesso em: 16 nov. 2009.

. ABNT NBR ISO/IEC 25000:2008 - Engenharia de software - Requisitos e avaliação da qualidade de produtos de software (SQuaRE) - Guia do SQuaRE. Este documento fornece orientação sobre o uso da nova série de normas denominada Requisitos e Avaliação da Qualidade de Produto de Software (SQuaRE). Seu objetivo é fornecer uma visão geral do conteúdo do SQuaRE, de seus modelos de referência e definições, bem como o relacionamento entre os documentos, permitindo aos usuários do Guia um bom entendimento dessa série de normas, associado aos respectivo propósito de uso. Este documento contém uma explicação do processo de transição das séries ISO/IEC 9126 e ABNT NBR ISO/IEC 14598 para o SQuaRE. Apresenta também informações para utilizar as séries ISO/IEC 9126 e ABNT NBR ISO /IEC 14598, segundo a proposta em suas versões anteriormente publicadas. 2008b. Disponível em:

<xxxx://xxx.xxxxxxxxxxxx.xxx.xx/xxxxx.xxxx?XXx0000>. Acesso em: 16 nov. 2009.

. ABNT NBR ISO/IEC 12207:2009 - Engenharia de sistemas e software - Processos de ciclo de vida de software. Esta Norma estabelece uma estrutura comum para processos de ciclo de vida de software, com terminologia bem definida, que pode ser referenciada pela indústria de software. A estrutura contém processos, atividades e tarefas que serão aplicadas durante a aquisição de um produto de software ou serviço, e durante o fornecimento, desenvolvimento, operação, manutenção e descontinuidade dos produtos de software. O software inclui a parte de software de firmware. 2009. Disponível em: <xxxx://xxx.xxxxxxxxxxxx.xxx.xx/xxxxx.xxxx?XXx00000>. Acesso em: 16 nov. 2009.

BRASIL. Decreto-lei n° 200, de 25 de fevereiro de 1967. Dispõe sobre a organização da Administração Federal, estabelece diretrizes para a Reforma Administrativa e dá outras providências. 1967. Disponível em:

<xxxx://xxx.xxxxxxxx.xxx.xx/xxxxxx_00/xxxxxxx-xxx/Xxx0000.xxx>. Acesso em: 31 jul. 2008.

. Lei n° 7.232, de 29 de outubro de 1984. Dispõe sobre a Política Nacional de Informática, e dá outras providências. 1984. Disponível em: <xxxx://xxx.xxxxxxxx.xxx.xx/xxxxxx_00/Xxxx/X0000.xxx>. Acesso em: 14 out. 2009.

. Constituição da República Federativa do Brasil, de 5 de outubro de 1988. 1988. Disponível em:

<xxxx://xxx.xxxxxxxx.xxx.xx/xxxxxx_00/Xxxxxxxxxxxx/Xxxxxxxxxxxx.xxx>. Acesso em: 31 jul. 2008.

. Lei n° 8.078, de 11 de setembro de 1990. Dispõe sobre a proteção do consumidor e dá outras providências. 1990. Disponível em: <xxxx://xxx.xxxxxxxx.xxx.xx/xxxxxx_00/Xxxx/X0000xxxxxxxxx.xxx>. Acesso em: 31 jul. 2008.

. Lei n° 8.666, de 21 de junho de 1993. Regulamenta o art. 37, inciso XXI, da Constituição Federal, institui normas para licitações e contratos da Administração Pública e dá outras providências. 1993. Disponível em:

<xxxx://xxx.xxxxxxxx.xxx.xx/xxxxxx_00/Xxxx/X0000xxxx.xxx>. Acesso em: 14 out. 2009.

. Decreto n° 1.422, de 20 de março 1995. Dispõe sobre a composição e o funcionamento do Conselho Nacional de Metrologia, Normalização e Qualidade Industrial (Conmetro). 1995. Disponível em:

<xxxx://xxx.xxxxxxxx.xxx.xx/XXXXXX/xxxxxxx/X0000.xxx>. Acesso em: 31 jul. 2008.

. Emenda Constitucional nº 19, de 04 de junho de 1998. Modifica o regime e dispõe sobre princípios e normas da Administração Pública, servidores e agentes políticos, controle de despesas e finanças públicas e custeio de atividades a cargo do Distrito Federal, e dá outras providências. 1998a. Disponível em:

<xxxx://xxx.xxxxxxxx.xxx.xx/xxxxxx_00/Xxxxxxxxxxxx/Xxxxxxx/Xxx/xxx00.xxx>. Acesso em: 31 jul. 2008.

. Lei n° 9.609, de 19 de fevereiro de 1998. Dispõe sobre a proteção de propriedade intelectual de programa de computador, sua comercialização no País, e dá outras providências. 1998b. Disponível em:

<xxxx://xxx.xxxxxxxx.xxx.xx/xxxxxx_00/Xxxx/X0000.xxx>. Acesso em: 31 jul. 2008.

. Lei n° 10.520, de 17 de julho de 2002. Institui, no âmbito da União, Estados, Distrito Federal e Municípios, nos termos do art. 37, inciso XXI, da Constituição Federal, modalidade de licitação denominada pregão, para aquisição de bens e serviços comuns, e dá outras providências. 2002. Disponível em:

<xxxx://xxx.xxxxxxxx.xxx.xx/xxxxxx_00/Xxxx/0000/X00000.xxx>. Acesso em: 14 out. 2009.

. Tribunal de Contas da União. Acórdão 1.937/2003-TCU-Plenário. 2003. Disponível em:

<xxxx://xxxxxx.xxx.xxx.xx/xxxxxxxxxxxxx/XxxxxxXxxxxxxxx?xxxx(xxxxxxxxxxxx0000/0000xxxxxxxxxxxxx)[xxxx][x000]>. Acesso em: 31 jul. 2008.

. Decreto n° 5.233, de 6 de outubro de 2004. Estabelece normas para a gestão do Plano Plurianual 2004-2007 e de seus Programas e dá outras providências. 2004. Disponível em: <xxxxx://xxx.xxxxxxxx.xxx.xx/xxxxxx_00/_Xxx0000- 2006/2004/Decreto/D5233.htm>. Acesso em: 31 jul. 2008.

. Decreto n° 5.450, de 31 de maio de 2005. Regulamenta o pregão, na forma eletrônica, para aquisição de bens e serviços comuns, e dá outras providências. 2005. Disponível em: <xxxx://xxx.xxxxxxxx.xxx.xx/xxxxxx_00/_Xxx0000- 2006/2005/Decreto/D5450.htm>. Acesso em: 14 out. 2009.

. Tribunal de Contas da União. Acórdão 1.890/2006-TCU-Plenário. 2006. Disponível em:

<xxxx://xxxxxx.xxx.xxx.xx/xxxxxxxxxxxxx/XxxxxxXxxxxxxxx?xxxx(xxxxxxxxxxxx0000/0000xxxxxxxxxxxxx)[xxxx][x000]>. Acesso em: 31 jul. 2008.

. . Acórdão 539/2007-TCU-Plenário. 2007. Disponível em:

<xxxx://xxxxxx.xxx.xxx.xx/xxxxxxxxxxxxx/XxxxxxXxxxxxxxx?xxxx(xxxxxxxxxxxx000/0000xxxxxxxxxxxxx)[xxxx][x000]>. Acesso em: 31 jul. 2008.

. . Acórdão 1.603/2008-TCU-Plenário. 2008a. Disponível em:

<xxxx://xxxxxx.xxx.xxx.xx/xxxxxxxxxxxxx/XxxxxxXxxxxxxxx?xxxx(xxxxxxxxxxxx0000/0000xxxxxxxxxxxxx)[xxxx][x000]>. Acesso em: 01 set. 2008.

. . Acórdão 2.471/2008-TCU-Plenário. 2008b. Disponível em:

<xxxx://xxxxxx.xxx.xxx.xx/xxxxxxxxxxxxx/XxxxxxXxxxxxxxx?xxxx(xxxxxxxxxxxx0000/0000xxxxxxxxxxxxx)[xxxx][x000]>. Acesso em: 14 out. 2009.

. . Acórdão 2.521/2008-TCU-Plenário. 2008c. Disponível em:

<xxxx://xxxxxx.xxx.xxx.xx/xxxxxxxxxxxxx/XxxxxxXxxxxxxxx?xxxx(xxxxxxxxxxxx0000/0000xxxxxxxxxxxxx)[xxxx][x000]>. Acesso em: 19 dez. 2008.

. Ministério da Ciência e Tecnologia. Programa Brasileiro da Qualidade e Produtividade em Software. Alinhamento com a PITCE . Brasília: MCT, 2009a. Disponível em:

<xxxx://xxx.xxx.xxx.xx/xxxxx.xxx/xxxxxxx/xxxx/00000.xxxx>. Acesso em: 16 nov. 2009.

. . Programa Brasileiro da Qualidade e Produtividade em Software. Estratégias e ações. Brasília: MCT, 2009b. Disponível em: <xxxx://xxx.xxx.xxx.xx/xxxxx.xxx/xxxxxxx/xxxx/0000.xxxx>. Acesso em: 16 nov. 2009.

. . Programa Brasileiro da Qualidade e Produtividade em Software. Objetivo. Brasília: MCT, 2009c. Disponível em: <xxxx://xxx.xxx.xxx.xx/xxxxx.xxx/xxxxxxx/xxxx/00000.xxxx>. Acesso em: 16 nov. 2009.

. Tribunal de Contas da União. Acórdão 1.215/2009-TCU-Plenário. 2009d. Disponível em:

<xxxx://xxxxxx.xxx.xxx.xx/xxxxxxxxxxxxx/XxxxxxXxxxxxxxx?xxxx(xxxxxxxxxxxx0000/0000xxxxxxxxxxxxx)[xxxx][x000]>. Acesso em: 15 jun. 2009.

. . Acórdão 189/2009-TCU-Plenário. DENÚNCIA. POSSÍVEIS IRREGULARIDADES OCORRIDAS EM PREGÃO ELETRÔNICO. CONHECIMENTO. PROCEDÊNCIA PARCIAL. DETERMINAÇÃO. CIÊNCIA À ENTIDADE E AO INTERESSADO. ARQUIVAMENTO. 2009e. Disponível em:

<xxxx://xxxxxx.xxx.xxx.xx/xxxxxxxxxxxxx/XxxxxxXxxxxxxxx?xxxx(xxxxxxxxxxxx000/0000xxxxxxxxxxxxx)[xxxx][x000]>. Acesso em: 18 fev. 2009.

. . Acórdão 2.681/2009-TCU-Plenário. 2009f. Disponível em:

<xxxx://xxxxxx.xxx.xxx.xx/xxxxxxxxxxxxx/XxxxxxXxxxxxxxx?xxxx0&xx0&xxxx(XX000-00/00- P)[NUMD][B001,B002,B012]>. Acesso em: 16 nov. 2009.

XXXXXXX, Xxxxx Xxxxx. Curso de Direito Administrativo. Belo Horizonte: Fórum, 2007.

GUERRA, Xxx Xxxxxxxx; XXXXX, Xxxxxx Xxxxx. Aquisição de produtos e serviços de software. Rio de Janeiro: Elsevier, 2004.

XXXXXX XXXXX, Xxxxxx. Comentários à lei de licitações e contratos administrativos. 11. ed. São Paulo: Dialética, 2005.

XXXXX, Xxxxxx Xxxxx Xxxxxx. Eficácia nas licitações e contratos. 10. ed. Belo Horizonte: Del Rey, 2005.

XXXXX, Xxxx X.; XXXXX, Xxxxxxx X.; XXXXXX, Xxxx; XXXXXXXX, Xxxx Xxxx. The Capability Maturity Model: guidelines for improving the software process. Indianapolis, IN: Addison-Wesley Longman, 1995.

SOFTEX, Sociedade para Promoção da Excelência do Software Brasileiro. XXX.XX - Melhoria de Processo do Software Brasileiro – Guia geral. São Paulo: SOFTEX, set 2009. Disponível em:

<xxxx://xxx.xxxxxx.xx/xxxxx/_xxxxx/xxxxx/XXX.XX_Xxxx_Xxxxx_0000.xxx>. Acesso em: 27 set. 2009.

. Ofício SOFT/COR/682/08, de 23 de abril de 2008. Resposta ao ofício Sefti/TCU nº 37/2008, de 19 de março de 2008.

SOFTWARE ENGINEERING INSTITUTE - SEI. CMMI for development, version 1.2. Improving processes for better products. Pittsburgh: SEI, 2006. Disponível em: <xxx.xxx.xxx.xxx/xxxxxxxxx/xxxx/XXXX-XXX-x0.0.xxx>. Acesso em: 16 nov. 2009.

VII HISTÓRICO DE REVISÕES

Data	Documento/Evento	Versão
11/09/2009	Apresentação da primeira versão da Nota Técnica SEFTI/TCU nº 05 e início da consulta interna Sefti.	0.4
07/12/2009	Versão final para início da consulta interna Sefti. Contribuições mais significativas: Xxxxxx X. X. xx Xxxxxxxxxx (PhD, UnB), Xxxxxx X. X. xx Xxxxxxx (MSc, Embrapa), especialistas consultadas na fase de estudos iniciais Xxxxxxx Xxxxx Xxxxxx Xxxxxx – revisor Xxxxxx Xxxxxx – Gerente substituto responsável pela revisão nas primeiras versões Xxxxxx Xxxxxx Xxxxxx Xxxxx – Gerente responsável pela revisão nas primeiras versões Signatários: Xxxxxx Xxxxxxxxxxx da Xxxxx – autor Xxxxxxx Xxxxx xx Xxxx – autor Xxxxxxx Xxxxxxx Xxxxxx – Gerente responsável pela revisão final Xxxxxxx Xxxxx Xxxxxxxx Xxxxxx – Secretário	0.4
30/04/2010	Versão final para início da consulta interna TCU. Signatários: Xxxxxx Xxxxxxxxxxx xx Xxxxx – autor Xxxxxxx Xxxxx xx Xxxx – autor Xxxxxxx Xxxxxxx Xxxxxx – Gerente responsável pela revisão final Xxxxxxx Xxxxx Xxxxxxxx Xxxxxx – Secretário	0.5

1 Essa demonstração consta da Nota Técnica nº 2, da Secretaria de Fiscalização de Tecnologia da Informação (Sefti), cujos entendimentos foram aprovados no Acórdão nº 2.471/2008-TCU-Plenário e sua divulgação determinada pelo Acórdão nº 1.215/2009-TCU-Plenário.

2 CASE – Computer-aided Software Engineering (engenharia de software auxiliada por computador).

3 SQuaRe – Software Product Quality Requirements and Evaluation (requisitos e avaliação de qualidade de produto de software).

4 Esses benefícios são objetivos estratégicos de negócio.

5 A Sociedade SOFTEX, que a partir do final de 2004 mudou a razão social para Associação para Promoção da Excelência do Software Brasileiro - SOFTEX, é uma Organização da Sociedade Civil de Interesse Público criada em 03/12/1996, com sede em Campinas (xxxx://xxx.xxxxxx.xx).

6 Nas licitações de técnica e preço ou de melhor técnica, o julgamento das propostas técnicas deve incluir a avaliação da capacitação e da experiência do proponente, além da própria qualidade técnica da proposta (Lei nº 8.666/1993, art. 46, § 1º, I, e § 2º, caput).

7 Os resultados esperados “podem ser evidenciados por um produto de trabalho produzido ou uma mudança significativa de estado ao se executar o processo” (SOFTEX, 2009, p. 16).

Document Metadata

Table of Contents

Nota Técnica SEFTI/TCU nº 05 – versão 1.0 Brasília, 30 de abril de 2010

Document Metadata