Nota Técnica SEFTI/TCU nº 05 versão 1.0 Brasília, 30 de abril de PDF
Nota Técnica SEFTI/TCU nº 05 versão 1.0 Brasília, 30 de abril de 2010
Download "Nota Técnica SEFTI/TCU nº 05 versão 1.0 Brasília, 30 de abril de 2010"
Martim Fonseca Chaves
1 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 MPS.BR. 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 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) demonstrou 1 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º /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 MPS.BR (GUERRA; ALVES, 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 SisDoc: Diversos - idsisdoc_ v Teste_claudio.doc SEFTI/SA - marcoaam - PUB 1
2 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 MPS.BR, 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 MPS.BR 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 MPS.BR, 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 SisDoc: Diversos - idsisdoc_ v Teste_claudio.doc SEFTI/SA - marcoaam - PUB 2
3 serviços a serem realizados, todos os resultados esperados que, segundo modelos de qualidade de processo aderentes à norma ABNT NBR ISO/IEC , tais como CMMI ou MPS.BR, 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 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 MPS.BR, 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 , 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. SisDoc: Diversos - idsisdoc_ v Teste_claudio.doc SEFTI/SA - marcoaam - PUB 3
4 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 (qualidade de produto de software), NBR ISO/IEC (modelo de referência para processo de software) e NBR ISO/IEC (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 n os e 2.471/2008-TCU- Plenário): Quadro 1. ABNT, Normas relacionadas à Engenharia de Software. SisDoc: Diversos - idsisdoc_ v Teste_claudio.doc SEFTI/SA - marcoaam - PUB 4
5 Norma Título ABNT NBR ISO/IEC Engenharia de sistemas e software - Processos de ciclo de vida de software ABNT NBR ISO/IEC Tecnologia de informação - Orientação para avaliação e seleção de ferramentas CASE 2 ABNT NBR ISO/IEC Tecnologia de informação - Medição de software - Medição de tamanho funcional Parte 1: Definição de conceitos ABNT ISO/IEC TR Tecnologia da informação - Engenharia de software - Orientação para adoção de ferramentas CASE ABNT NBR ISO/IEC Tecnologia de informação - Avaliação de produto de software (seis partes) ABNT NBR ISO/IEC Engenharia de sistemas e software Processos de ciclo de vida de sistema ABNT NBR ISO/IEC Tecnologia da informação - Avaliação de processo (sete partes) ABNT NBR ISO/IEC Engenharia de sistemas e de software - Processo de medição ABNT NBR ISO/IEC série Engenharia de software - Requisitos e avaliação da qualidade de produtos de software (SQuaRE 3 ) (cinco normas) ABNT NBR ISO/IEC 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 define como propósito e benefícios: A ABNT NBR ISO/IEC 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 , 2008, p. 7-8, grifos 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/ Portanto, a partir do raciocínio esposado por Furtado (2007, p ), 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 pretendidos 4 com a execução do objeto da contratação não se realizam adequadamente; SisDoc: Diversos - idsisdoc_ v Teste_claudio.doc SEFTI/SA - marcoaam - PUB 5
6 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, e que já foram introduzidas no Brasil pela ABNT. 28. Conforme definido na ABNT NBR ISO/IEC (2008, p. 7), o mecanismo de avaliação ali detalhado é um método provado, consistente e confiável para avaliar o estado de seus SisDoc: Diversos - idsisdoc_ v Teste_claudio.doc SEFTI/SA - marcoaam - PUB 6
7 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 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 MPS.BR, 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 e 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 ESW/1/02; melhoria da qualidade e produtividade no setor de software Adoção da gestão da qualidade e produtividade em software ESW/2/01; 2.1.1; 2.1.2; 2.1.3; ESW/2/02; 2.2.1; 2.2.2; ESW/6/01; 6.1.1; 6.1.2; 6.1.3; 6.1.4; Diagnóstico de processo de software ESW/2/04; Treinamento de multiplicadores para o mercado ESW/3/01; 3.1.2; Capacitação em qualidade de software ESW/3/02; 3.2.1; 3.2.4; Envolvimento dos órgãos de orientação ao consumidor com respeito à ESW/4/03; 4.3.2; 4.3.4; SisDoc: Diversos - idsisdoc_ v Teste_claudio.doc SEFTI/SA - marcoaam - PUB 7
8 qualidade de software ESW/5/08; ESW/5/09; Difusão das normas técnicas de software ESW/4/05; 4.5.6; 4.5.7; 4.5.8; 4.5.9; Criação de grupos técnicos de interesse em software ESW/4/06; Alinhamento governamental em torno do PBQP-SW ESW/5/01; 5.1.1; 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; ESW/5/03; 5.3.1; 5.3.2; 5.3.3; ESW/5/04; ESW/5/05; Consolidação da Engenharia de Software ESW/6/02; 6.2.1; 6.2.2; 6.2.3; 6.2.4; 6.2.5; Fonte: BRASIL (2009b) 35. Uma das iniciativas fomentadas pelo PBQP-SW foi o desenvolvimento do MPS.BR (vide estratégia ESW/4/05), hoje mantido pela SOFTEX 5, 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 ). 37. O mesmo ocorre com os modelos CMMI e MPS.BR, modelos mais modernos de avaliação do processo de software, que implementam as normas técnicas ISO/IEC e 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 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. SisDoc: Diversos - idsisdoc_ v Teste_claudio.doc SEFTI/SA - marcoaam - PUB 8
9 Nível de Processos Maturidade 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 - Desempenho de Processo Organizacional; quantitativamente - 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 MPS.BR 43. O modelo de Melhoria de Processo do Software Brasileiro (MPS.BR) é 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 MPS.BR, 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 MPS.BR 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 SisDoc: Diversos - idsisdoc_ v Teste_claudio.doc SEFTI/SA - marcoaam - PUB 9