e certificações software - qual serve melhor para mim? ISO/IEC / ISO 9000 / CMMI / MPS-BR

Transcrição

1 Normas e certificações em software - qual serve melhor para mim? ISO/IEC / ISO 9000 / CMMI / MPS-BR

2

3 Normas e certificações em software - qual serve melhor para mim? ISO/IEC / ISO 9000 / CMMI / MPS-BR Dezembro 2013

4 2013. Serviço Brasileiro de Apoio às Micro e Pequenas Empresas Sebrae TODOS OS DIREITOS RESERVADOS. A reprodução não autorizada desta publicação, no todo ou em parte, constitui violação dos direitos autorais (Lei nº 9.610/1998). Informações e Contatos Serviço Brasileiro de Apoio às Micro e Pequenas Empresas Sebrae Unidade de Atendimento Coletivo Serviços SGAS 605 Conjunto A Asa Sul CEP: Brasília-DF Telefone: (61) Presidente do Conselho Deliberativo Roberto Simões Diretor-Presidente Luiz Barretto Pereira Filho Diretor-Técnico Carlos Alberto dos Santos Diretor de Administração e Finanças José Claudio dos Santos Gerente da Unidade de Atendimento Coletivo Serviços Juarez de Paula Gerente Adjunta da Unidade de Atendimento Coletivo Serviços Ana Clévia Guerreiro Lima EQUIPE TÉCNICA Rosana Cristóvão de Melo Analista técnica Coordenadora Nacional da Carteira de Economia Criativa Software, Games e APP CONTEUDISTA TÉCNICO DA EMPRESA SEXTANTE LTDA José Augusto Pinto de Abreu Gisele Villas Boas

5

6 Objetivo Introdução A questão da qualidade para software Comparação entre os sistemas de normas 6.1 ABNT NBR ISO/IEC x ABNT NBR ISO ISO/IEC x CMMI x MPS-BR Qual a melhor norma (e a melhor certificação) para mim? A Conclusões Anexos Sumário Normas técnicas e certificações para que servem? Os sistemas de normas para software e seus usos 5.1 Norma ABNT NBR ISO/IEC O que é a ABNT NBR ISO/ IEC Os processos do Perfil Básico Os requisitos da norma ISO/IEC Norma ABNT NBR ISO MR-MPS-SW Modelo de Referência MPS para Software 5.4 CMMI-DEV

7 Figuras Tabelas 23 Figura Crise do Software 24 Figura O setor de TI e as várias abordagens para a qualidade e a competitividade 25 Figura Ciclo de desenvolvimento de software 26 Figura Visão de processo (processos e subprocessos) 27 Figura visão de processo 33 Figura Interação entre os processos do Perfil Básico 34 Figura Elementos dos Processos da ISO/ IEC Figura Ciclo PDCA 43 Figura Modelo gráfico das interações entre as macroatividades típicas de um sistema de gestão consistente 45 Figura Modelo de um sistema de gestão da qualidade baseado em processos 52 Figura Estrutura do MR-MPS-SW 57 Figura Estrutura CMMI 76 Figura A.1 - Interrelacionamento da Acreditação com a Avaliação da Conformidade Tabela Visão consolidada dos Requisitos Obrigatórios do Perfil Básico Processo PM 37 Tabela Visão consolidada dos Requisitos Obrigatórios do Perfil Básico Processo SI 38 Tabela Atributos de Processo (SOFTEX, 2012a) 53 Tabela Níveis de maturidade do MR-MPS-SW (SOFTEX, 2012a) 54 Tabela Níveis de capacidade e de maturidade do CMMI-DEV (SEI, 2010) 56 Tabela Áreas de Processo do CMMI-DEV (SEI, 2010) 57 Tabela B.1 - Relação dos critérios de entrada da ISO/IEC (item 6.7) com os requisitos da ISO/IEC Tabela B.2 - Correspondência dos objetivos do Processo de PM Gerência de Projetos estabelecidos na ISO/ IEC com os requisitos da ISO/IEC Tabela B.3 - Correspondência dos objetivos do Processo de SI Processo de Implementação do Software estabelecidos na ISO/IEC com os requisitos da ABNT NBR ISO/IEC Tabela B.4 - Sumário da ABNT NBR ISO 9001:2008 Sistema de Gestão da Qualidade Requisitos 82 Tabela C.1 - Formulários e legendas da Análise Comparativa 86 Tabela C.2 - Correspondência dos Processos Gestão de Projetos (PM) e Implementação do Software (SI) estabelecidos na ISO/IEC com os Processos relacionados até o nível 3 do CMMI e até o nível C do MPS-BR 88 Tabela C.3 - Correspondência dos objetivos do Processo PM (Gestão de Projetos) estabelecidos na ISO/IEC com as práticas específicas do CMMI-DEV e os resultados esperados do MPS-BR 91 Tabela C.4 - Correspondência dos objetivos do Processo SI (Implementação de Software) estabelecidos na ISO/ IEC com as práticas específicas do CMMI- DEV e os resultados esperados do MPS-BR 101 Tabela C.5 - Atributos de Processo (AP) AP 2.1 e AP 2.2 e Resultados de Atributo de Processo (RAP) associados e Objetivo Genérico (GG) e Práticas Genéricas (GP) 108

8

9 1. Objetivo Analisar os modelos de normas e certificação mais relevantes no mercado brasileiro, aplicáveis a empresas de software, e disponibilizar diretrizes para auxiliar as micro e pequenas empresas a decidirem qual a mais conveniente para as suas necessidades. 2. Introdução Se no mercado, como estratégia competitiva, as empresas procuram diferenciar-se, já os clientes, por sua vez, são cada vez mais exigentes e procuram assegurar-se de que os seus fornecedores lhes entregam produtos ou serviços que atendam às suas expectativas e necessidades - para tanto, procuram estabelecer métodos que assegurem esses fornecimentos de acordo com a qualidade pretendida. Neste contexto, pode-se, os processos de produção e fornecimento são cada vez mais complexos. Decorre daí uma tendência natural de se estabelecerem referências para a qualidade dos produtos ou serviços e mecanismos imaginados para facilitar a verificação do atendimento a essa expectativa de qualidade. É assim que surgem as normas técnicas, os selos e certificações, que ganham cada vez mais importância no mercado, ao ponto de, em alguns segmentos, ser indispensável atender-se a essas normas e estar-se certificado para permanecer no mercado. O mundo do software não é estranho a esse quadro e, de fato, verifica-se um crescente número de iniciativas a fim de estabelecer padrões, normas técnicas, selos, aprovações, certificações e mecanismos semelhantes. Põe-se, então, um outro problema para as empresas: qual norma e certificação adotar para se manter competitivo e se diferenciar no mercado e/ou atender a clientes? Normas e certificações em software 9

10 Esta questão, que não tem uma resposta simples, é mais desafiadora ainda para as micro e pequenas empresas MPE, que contam com recursos limitados e não se podem dar ao luxo de tentativa e erro... Esta publicação procura analisar algumas iniciativas de normas, e consequentes certificações, relacionadas ao desenvolvimento de software que tem como público alvo as MPE ou são a elas aplicáveis, com o propósito de contribuir para esclarecer para os empresários o que estas normas e suas certificações envolvem, o que significam e quais as principais semelhanças, convergências, diferenças e divergências apresentadas. As normas aqui analisadas são a ABNT NBR ISO Sistemas de gestão da qualidade - Requisitos, a ABNT NBR ISO/IEC Engenharia de Software Perfis de ciclo de vida para micro-organizações (VSEs) - Parte 4-1: Especificações de perfil: Grupo Perfil Genérico, normas internacionais desenvolvidas pela ISO International Organization for Standardization e adotadas como Normas Brasileiras pela ABNT Associação Brasileira de Normas Técnicas, modelo de referência MR-MPS-DEV (de Modelo de Referência Melhoria de Processo de Software), desenvolvido no Brasil, e o modelo norte-americano CMMI (de Capabilty Maturity Model Integrated, ou modelo integrado de maturidade e capacidade), desenvolvido pelo SEI (Software Engineering Institute, ou Instituto de Engenharia de Software). 3. Normas técnicas e certificações para que servem? Nas sociedades, é cada vez mais intenso o uso de normas técnicas e de certificações. O setor de software não é alheio a essa dinâmica e atualmente é um dos mais ativos no que se refere à normalização. 10

11 Normas técnicas (ou simplesmente normas) são documentos que traduzem em termos tecnológicos as expectativas da sociedade em relação ao objeto da norma. As normas técnicas podem ser aplicáveis a produtos, serviços, processos, sistemas de gestão, competências de pessoas. São documentos que estabelecem requisitos de qualidade, requisitos de desempenho, requisitos de segurança, processos, procedimentos, formas, dimensões, classificações ou terminologias e glossários. Podem ainda estabelecer a maneira de medir ou de determinar características do produto. Usualmente, são construídas por consenso e de maneira participativa. Tecnicamente, a normalização é a o estabelecimento de regras comuns para as atividades humanas e seus resultados. Essas regras são estabelecidas de comum acordo entre os interessados nessas atividades e nos seus resultados. Assim, a normalização é uma atividade da sociedade e pode ser descrita como a sua autorregulação. A normalização é conduzida por organizações especializadas, normalmente pelos organismos de normalização. Por vezes, normas técnicas são desenvolvidas por estruturas mais informais, como consórcios de empresas ou de outras partes interessadas. Nesse caso, são chamadas de normas privadas. O uso de normas técnicas contribui para a melhoria do funcionamento do mercado por meio de linguagem precisa e comum. Isto se dá nas mais variadas situações e contextos, como por exemplo: O uso, pela empresa, para produzir e avaliar seus produtos ou serviços; Na relação comercial da empresa com seus clientes ou fornecedores; Pelo cliente ou consumidor, para a tomada de decisão na compra de um produto ou serviço; No estabelecimento e aplicação de mecanismos de avaliação de conformidade (auditorias, inspeções ou ensaios); Normas e certificações em software 11

12 Na aplicação de procedimentos para garantir a conformidade (certificação, declaração do fornecedor ou qualificação de fornecedores); Por um país ou empresa importadora para a garantia do atendimento aos requisitos que estabelece como necessários; Pela Justiça, para a verificação do cumprimento da legislação. Dentre os principais impactos percebidos pelo uso de normas técnicas, pode-se destacar, entre outros: A possibilidade objetiva de comparação entre produtos, processos ou serviços; A redução de litígios; A construção de bases claras para a concorrência; As normas podem ser desenvolvidas em diversos níveis, relacionados com a abrangência da sua aplicação e da participação no seu desenvolvimento. Os níveis de normalização são: Empresa normas elaboradas por uma empresa ou grupo de empresas com a finalidade de orientar as compras, a fabricação, as vendas e outras operações. Servem ainda para documentar o conhecimento técnico da empresa. Nacional normas elaboradas pelas partes interessadas (governo, empresas, consumidores e comunidade científica de um país) e emitidas por um Organismo Nacional de Normalização, reconhecido como autoridade para torná-las públicas. Aplicam-se ao mercado de um país e, frequentemente, são reconhecidas pelo seu ordenamento jurídico como a referência para as transações comerciais. Normalmente são voluntárias, isto é, cabe aos agentes econômicos decidirem se as usam ou não como referência técnica para uma transação. 12

13 Regional estabelecidas por um Organismo Regional de Normalização para aplicação num conjunto de países (uma região, como a Europa). São denominadas Normas Regionais e aplicáveis ao conjunto de países representados no Organismo Regional. Internacional normas técnicas, de abrangência mundial, estabelecidas por um Organismo Internacional de Normalização. As normas podem ser desenvolvidas em diversos níveis, relacionados com a abrangência da sua aplicação e da participação no seu desenvolvimento. Os níveis de normalização são: Empresa normas elaboradas por uma empresa ou grupo de empresas com a finalidade de orientar as compras, a fabricação, as vendas e outras operações. Servem ainda para documentar o conhecimento técnico da empresa. Nacional normas elaboradas pelas partes interessadas (governo, empresas, consumidores e comunidade científica de um país) e emitidas por um Organismo Nacional de Normalização, reconhecido como autoridade para torná-las públicas. Aplicam-se ao mercado de um país e, frequentemente são reconhecidas pelo seu ordenamento jurídico como a referência para as transações comerciais. Normalmente são voluntárias, isto é, cabe aos agentes econômicos decidirem se as usam ou não como referência técnica para uma transação. Regional estabelecidas por um Organismo Regional de Normalização para aplicação num conjunto de países (uma região, como a Europa). São denominadas Normas Regionais e aplicáveis ao conjunto de países representados no Organismo Regional. Internacional normas técnicas de abrangência mundial, estabelecidas por um Organismo Internacional de Normalização. Estes Organismos Internacionais de Normali- Normas e certificações em software 13

14 zação atuam em campos específicos, como a International Organization for Standardisation ISO (a maioria dos setores), a International Electrotechnical Commission IEC (área elétrica e eletrônica) e a International Telecommunications Union ITU-T (Telecomunicações). As Normas Internacionais são reconhecidas pela Organização Mundial do Comércio OMC como a base para o comércio internacional. No nível nacional, no Brasil, as Normas Brasileiras são as desenvolvidas e publicadas pela Associação Brasileira de Normas Técnicas ABNT 1, que é reconhecida pelo Estado Brasileiro como o Organismo Nacional do País. No nível internacional, as normas internacionais são desenvolvidas fundamentalmente no âmbito da International Organization for Standardisation ISO 2 (para a maioria dos setores), da International Electrotechnical Commission IEC 3, que cuida especificamente dos temas relacionados ao setor elétrico e eletrônico, e a International Telecommunications Union ITU-T (é um braço da ITU que é um órgão da Organização das Nações Unidas ONU), que trata de questões relativas ao campo das telecomunicações. A ISO foi fundada em 1947 e é uma organização privada, sem fins lucrativos. A ISO e a IEC constituíram um comitê técnico conjunto, o JTC1 4 (de Joint Technical Committee) que é o responsável pelas normas de TIC Tecnologia da Informação e Telecomunicações. De uma maneira geral, as normas desenvolvidas pelos organismos nacionais, regionais ou internacionais são reconhecidas como referência para o mercado no ordenamento jurídico dos diferentes países. Isso tem consequências importantes, dentre as quais a de serem usadas nos processos de compras públicas e também frequentemente se constituírem na base legal para o O JTC1 tem publicadas 2554 normas técnicas para TIC. 14

15 fornecimento de determinado produto, processo ou serviço. No caso brasileiro, o código de defesa do consumidor estabelece que, na ausência de regulamentos técnicos promulgados pelas autoridades do Estado, o atendimento às Normas Brasileiras (designadas por ABNT NBR) é obrigatório para os produtos e serviços oferecidos no mercado de consumo 5. No Brasil, as normas técnicas para software são desenvolvidas pelo ABNT/CB21, que é o órgão técnico da ABNT responsável por TIC. Convém assinalar ainda que o ABNT/CB21 também é o responsável pela participação brasileira nos trabalhos do JTC1. Como anteriormente mencionado, além das norma publicadas pelos organismos de normalização, há no mercado normas técnicas que são desenvolvidas por outras organizações, as chamadas normas privadas. Frequentemente, essas normas são bem aceitas e disseminadas e têm boa qualidade técnica. Por vezes, estão até mesmo consagradas no mercado como uma das referências e boas práticas. Contudo, deve-se observar que essas normas não gozam do estatuto das normas nacionais, regionais ou internacionais, sendo muitas vezes vedado o seu uso, por exemplo, em processos licitatórios de compras públicas. Aqui serão analisadas duas normas publicadas pela ISO e adotadas como Normas Brasileiras: a ABNT NBR ISO 9001 (doravante, para simplicidade de redação, será designada abreviadamente ISO 9001 ) e a ABNT NBR ISO/IEC (doravante designada abreviadamente como ISO/IEC ), que serão examinadas mais adiante, bem como o modelo de referência MR-MPS-DEV (de Modelo de Referência Melhoria de Processo de Software), desenvolvido no Brasil, e o modelo norte-americano 5 Artigo 39 da Seção IV Das Práticas Abusivas: É vedado ao fornecedor de produtos e serviços: Inciso 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). Normas e certificações em software 15

16 CMMI (de Capabilty Maturity Model Integrated, ou modelo integrado de maturidade e capacidade), desenvolvido pelo SEI (Software Engineering Institute, ou Instituto de Engenharia de Software). No contexto deste trabalho, e aplicando-se a conceituação apresentada, os modelos de referência aqui tratados são considerados como normas privadas. Complementares às normas técnicas são as certificações. A certificação é uma das maneiras de se fazer a avaliação da conformidade de algo (pode ser um produto, um processo, um serviço ou mesmo a competência de uma pessoa). Assim, é melhor examinar com um pouco mais de atenção do que trata a avaliação da conformidade para então se estudar o que é certificação. Avaliação da conformidade é qualquer atividade que tem como objetivo determinar, direta ou indiretamente, se os requisitos aplicáveis são atendidos. Estes requisitos podem estar estabelecidos numa norma, ou em outro documento equivalente, como um regulamento técnico ou uma especificação, ou mesmo um contrato (CNI, 2002 b, p. 8, apud ABNT, 1998). Ou seja, a norma técnica estabelece os requisitos aplicáveis e a avaliação da conformidade trata de verificar se esses requisitos efetivamente foram cumpridos. Os mecanismos utilizados para avaliar a conformidade são fundamentalmente as inspeções, os ensaios ou testes e as auditorias. Os resultados destas atividades são comparados com os requisitos especificados. A atividade de avaliação da conformidade pode ser desenvolvida nas mais variadas situações e pode ser executada por diversos agentes. Ela pode ser efetuada pela empresa fabricante de produtos ou prestadora do serviço; pode ser efetuada pelo cliente ou consumidor durante a aquisição de um produto ou serviço; pode ser executada por um organismo independente contratado para produzir uma avaliação isenta; ou pode ainda ser executada por um agente governamental para fins de fiscalização regulatória. 16

17 Em cada caso citado existem interesses, objetivos, necessidades e expectativas distintas, porém, independentemente da situação ou do agente executor desta atividade, o que se quer avaliar é o atendimento aos requisitos de uma norma ou regulamento técnico. Quando a avaliação da conformidade é desenvolvida para garantir a conformidade de um produto, serviço, sistema de gestão ou da competência de uma pessoa (profissional), adota se uma de três formas: Declaração do Fornecedor procedimento pelo qual um fornecedor dá garantia escrita de que um produto, processo ou serviço está em conformidade com os requisitos especificados. Qualificação de Fornecedor avaliação realizada pelo cliente (segunda parte) em relação ao fornecedor, de modo a verificar se o produto, processo, serviço ou sistema está em conformidade com uma norma ou outro documento normativo especificado. Certificação uma terceira parte (isto é, independente de quem fornece e de quem compra) dá garantia escrita de que um produto, processo ou serviço está em conformidade com os requisitos especificados. Nas relações comerciais, inclusive no comércio internacional, as três formas de garantia da conformidade citadas são amplamente utilizadas. Há vários tipos de certificação. Uma das classificações utilizadas se deve à função do que é objeto da certificação, como: Certificação de produtos ou serviços; Certificação de sistemas de gestão; Certificação de pessoas; Certificação de processos. Normas e certificações em software 17

18 A certificação de produtos e a de sistemas de gestão estão profundamente disseminadas no comércio internacional, mas no setor de software se observam exigências relacionadas com a certificação de processos, como o CMMI e o MPS-BR, e também de pessoas. A Certificação de Sistemas de Gestão (da Qualidade, Ambiental, de Saúde e Segurança Ocupacional, etc.) serve para demonstrar que determinada organização implementou e mantém um Sistema de Gestão em conformidade com os requisitos preconizados na norma escolhida como referência. As normas mais utilizadas internacionalmente são: ISO 9001 e a ISO A certificação é um meio técnico de comunicar ao cliente e às demais partes interessadas que os requisitos estabelecidos nas normas ou regulamentos técnicos são atendidos por intermédio de uma parte independente que goza de reputação no mercado. Dentre os benefícios que se podem perceber da aplicação da certificação à escala nacional, podem ser citados: Promoção da concorrência justa; Estímulo à melhoria contínua da qualidade; Promoção da proteção ao consumidor; Incremento das exportações; Fortalecimento do mercado interno; Agregação de valor à marca de produtos; Consolidação e disseminação da tecnologia nacional. Assim, a certificação é um meio de se comunicar com o cliente e é a atestação independente de que os requisitos de uma norma técnica, que é uma referência do interesse do cliente, são atendidos. Desta maneira, o cliente não precisa ele mesmo efetuar a verificação, que pode ser complexa e custosa. 18

19 Cumpre mencionar ainda que as certificações, em princípio, são voluntárias, isto é, são as empresas que decidem se querem obtê-las ou não. Contudo, quando estão em jogo aspectos como a saúde, a segurança de pessoas e bens, o meio ambiente, o Estado pode tornar obrigatória a certificação. Em princípio, esse não é o caso dos produtos de software. A certificação é efetuada por organizações especializadas, os chamados Organismos de Certificação, que são organizações independentes, designadas de terceira parte por serem necessariamente independentes dos interesses diretamente envolvidos. Com a disseminação e a proliferação das atividades de certificação, foi desenvolvido um mecanismo para avaliar e atestar a competência técnica e independência dos organismos de certificação, que é a Acreditação. Aqui, um organismo reconhecido, usualmente pelo Estado, que avalia os organismos de certificação e atesta a sua competência técnica para conduzir todo o processo de certificação, incluindo as verificações necessárias (auditorias, inspeções, exames e ensaios, quando for o caso). As atividades de certificação e de acreditação seguem regras estabelecidas em normas e guias internacionais publicados pela ISO. Essas regras são amplamente reconhecidas e consagradas. Cada país organiza as funções tecnológicas da normalização e regulamentação, da avaliação da conformidade e da metrologia. No caso brasileiro, o Sinmetro 6 - Sistema Nacional de Metrologia, Normalização e Qualidade Industrial, engloba as diversas funções mencionadas, além de algumas outras. No caso da acreditação, o Inmetro 7 o Instituto Nacional de Metrologia, Qualidade e Tecnologia, é o organismo nacional de acreditação do País. O Anexo A apresenta de maneira breve o funcionamento do Sinmetro Normas e certificações em software 19

20 No segmento de software, o mercado brasileiro tem a presença de certificações de processo: a norte-americana, CMMI-DEV, e a segunda, o modelo referência brasileiro, MR-MPS-SW. A despeito de serem certificações, não é usual chamá-las assim, mas sim como avaliação de aderência aos respectivos modelos. Neste trabalho, por se tratarem de certificações tecnicamente falando, serão assim designadas. Convém ainda acrescentar que essas certificações, como se verá mais adiante, são atribuídas em diversos níveis e o mercado tem demandado as empresas fornecedoras de software para que as tenham. Se, por um lado, até pouco tempo não havia Normas Brasileiras para a qualidade de software, e essas normas e certificações privadas eram, e ainda o são, por vezes exigidas, inclusive em editais de compras públicas, por outro, há empresas brasileiras de software que são certificadas segunda a norma ABNT NBR ISO 9001, de sistema de gestão da qualidade. Não é raro também existirem empresas que têm mais de uma dessas certificações. Perante esse cenário é que é as MPE podem se perguntar qual, afinal, deve ser a certificação que devem buscar, e se é que devem. 4. A questão da qualidade para software A qualidade é uma das características críticas para a competitividade de qualquer produto ou serviço e de qualquer empresa. Os conceitos da qualidade evoluíram bastante ao longo do tempo, passando-se de uma visão exclusiva das características específicas de um produto para uma visão relacionada com o seu uso. Em particular, a evolução conceitual foi mais pronunciada no final do século passado, culminando com o que se chamou por vezes da revolução da qualidade, que aconteceu especialmente a partir da década de 80 do século XX. É neste contexto que se desenvolvem as normas de sistemas de gestão da qualidade e se consagra 20

21 a definição da qualidade como ligada ao uso e ao atendimento das expectativas do cliente. O produto, assim, deixa de ter a sua própria qualidade, mas esta passa a ser a sua capacidade de atender às expectativas do cliente. Com efeito, entende-se hoje a qualidade como o grau no qual um conjunto de características inerentes a um produto, processo ou serviço satisfaz a requisitos (necessidades ou expectativas implícitas ou explícitas) 8. O setor de software, indústria naturalmente recente, por sua vez, também evoluiu profundamente desde a fase em que o desenvolvimento de software era considerado arte, sendo agora um dos setores mais robustos e dinâmicos da economia. Pois é um setor em que a criatividade e a inovação são características intrínsecas. A presença do software no dia a dia das pessoas e das organizações é absoluta. E essa evolução tem sido acompanhada pelo desenvolvimento de conhecimento, técnicas, métodos e processos que lhe dão suporte, como o é a própria Engenharia de Software. A qualidade é hoje central e estratégica para as empresas, e um fator decisivo para a introdução ou permanência nos mercados. Esse célere crescimento e desenvolvimento deu-se, contudo, com os seus custos, e um deles tem sido a própria qualidade dos serviços e produtos do setor ou, pelo menos, a sua percepção, tanto por parte dos clientes quanto dos próprios fornecedores. Logo, pode-se dizer que dentre os desafios que o setor de software enfrenta estão os seguintes 9 : a) Precariedade nas previsões e planejamentos os projetos de software atrasam e sofrem problemas de custo por falta de planejamento e controle porque não se prevê adequadamente quanto tempo e esforço serão necessários para produzi-lo de maneira que satisfaça as necessidades (requisitos) dos seus clientes. 8 Adaptada da definição da ABNT NBR ISO 9000: VILLAS BOAS, Gisele. Guia de uso e aplicação da série ABNT NBR ISO/IEC desenvolvimento de software para pequenas organizações. ABNT/SEBRAE, 2012 Normas e certificações em software 21

22 b) Baixa qualidade de processos e produtos a falta de planejamento e de previsibilidade leva a prazos estourados e a produtos de software que por vezes, ou não, atendem as necessidades do cliente ou atendem necessidades que não foram solicitadas originalmente. c) Requisitos mal definidos os requisitos, frequentemente, não são especificados. Quando o são, ou não estão completos ou apresentam contradições. A garantia de qualidade neste cenário é uma tarefa de tentativa e sorte. d) Alto custo para manutenção o que foi produzido não foi bem especificado e tampouco bem documentado, a manutenção corretiva - quando ocorrem erros ou falhas são difíceis de serem identificadas. Normalmente, isto acontece já em fase de implementação, quando se tem que contabilizar não só o custo do retrabalho como o custo de todo o esforço que foi gasto em vão. As manutenções evolutivas, embora sejam novas características adicionadas ao sistema, também podem ter o seu custo onerado quando se trata de um produto de baixa qualidade, carente de especificações e documentações. Não é incomum manutenções tornarem-se inviáveis devido às grandes dificuldades e aos altos custos de implementação. 22

23 Figura Crise do Software 10 Esta lista, ou listas bastante semelhantes, são frequentemente mencionadas. Percebe-se claramente que esses desafios são, no fundo, concernentes aos aspectos da qualidade. O setor não é indiferente a estes problemas e tem trabalhado intensamente para ultrapassá los usando diversas abordagens. Obviamente, um dos aspectos centrais do problema é que o software não é um produto convencional. O setor é mais bem descrito como de serviços do que propriamente de fornecedor de bens. Assim, as dificuldades relacionadas à qualidade do software é referente, naturalmente, à dificuldade de lidar com o tema da qualidade no setor de serviços. 10 VILLAS BOAS, Gisele. Qualidade de Software nas MPEs - Normas técnicas trazendo confiança. In: Exponorma, São Paulo/SP, Normas e certificações em software 23

24 Figura O setor de TI e as várias abordagens para a qualidade e a competitividade 11 Uma das possibilidades exploradas pelo setor para a qualidade foi a da adoção e implementação de sistemas de gestão da qualidade, como o estabelecido na norma ISO Publicou-se um documento da família ISO 9000 especificamente com diretrizes e orientações para a aplicação da norma no setor de software 12. Várias empresas adotaram a norma e mesmo algumas se certificaram. Contudo, o setor não se reconheceu na ISO 9000, dada a crescente complexidade do setor de software e o fato de que a norma ISO 9001 estabelece que a organização é que deve definir os aspectos técnicos dos seus processos. O setor sentiu falta de alguma outra referência para estabelecê-los e a adesão das empresas de software aos sistemas de gestão da qualidade conforme a norma ISO 9001 foi menor do que se esperava. 11 Idem, idem. 12 ABNT NBR ISO :1991. Normas de gestão da qualidade e garantia da qualidade. Diretrizes para a aplicação da ABNT NBR ISO 9001 ao desenvolvimento, fornecimento e manutenção de software, cancelada em

25 O setor de software então buscou diversas alternativas para tratar o tema da qualidade. Razão pela qual a engenharia de software procurou estabelecer e consagrar a abordagens por processos. De maneira esquemática, os principais processos envolvidos no desenvolvimento de software são os seguintes: Figura Ciclo de desenvolvimento de software 13 A abordagem por processos pretende chegar à qualidade de maneira indireta, assumindo que produtos de software desenvolvidos, aplicando-se integralmente os processos estabelecidos, devem resultar em produtos de qualidade. A abordagem por processos vem se desenvolvendo e sofisticando, e resulta em vários modelos que estão em uso; disseminados em maior ou menor grau. A abordagem por processos tem sido também objeto de normas técnicas, sejam normas nacionais 13 VILLAS BOAS, Gisele. Guia de uso e aplicação da série ABNT NBR ISO/IEC desenvolvimento de software para pequenas organizações. ABNT/SEBRAE, Normas e certificações em software 25

26 ou internacionais (ISO/IEC) ou ainda normas privadas, dentre as quais as mais conhecidas são as do modelo CMMI ou, no Brasil, do MPS-BR. Por esta abordagem, procura-se estabelecer os processos para o desenvolvimento do software e definir requisitos para esses processos. A implementação efetiva dos processos pode ser verificada mediante usuais auditorias de processos e pode-se mesmo atestar publicamente a efetiva implementação dos processos, por meio de uma certificação, por exemplo. Nesses modelos, os processos estabelecidos estão interligados à atividade técnica do desenvolvimento do software (a engenharia de software propriamente dita), e também com a atividade gerencial (os processos de suporte ou processos organizacionais, como por vezes são chamados). Embora o objeto desses processos seja comum (o desenvolvimento de software), o estabelecimento dos processos varia de modelo para modelo. Com efeito, é parte da lógica de processos que estes podem se desdobrar em subprocessos. Os processos, por outro lado, são constituídos por atividades. As figura 4.4 e 4.5 esclarecem a ideia: Figura Visão de processo (processos e subprocessos) 26

27 Figura visão de processo Assim, é possível estabelecer e descrever os processos envolvidos para realizar uma dada atividade de diversas maneiras, mas, consequentemente, os processos nem sempre são diretamente comparáveis. A título de ilustração, pode-se fazer uma analogia de um jogo de quebra-cabeças feito a partir da fotografia de uma paisagem. É fácil compreender que se podem criar diferentes quebra-cabeças a partir de uma mesma foto, ou seja, ainda que recortando a foto para fazer as peças de diferentes formas, ao final, resultarão na fotografia da paisagem. Obviamente, não há infinitas possibilidades de estabelecer os processos, mas certamente há mais de uma e nem sempre os processos estabelecidos numa solução são diretamente correlacionáveis com os processos estabelecidos noutra solução. Um nível adicional de complexidade tem sido a combinação de modelos de maturidade com os modelos de processos. Neste caso, avalia-se não apenas a existência ou implementação dos Normas e certificações em software 27

28 processos preconizados no modelo, mas também em que grau estes processos têm a capacidade de atingir os resultados esperados pelos modelos, resultando em níveis de maturidade. Várias das certificações de empresas de software existentes são deste tipo, como é o caso do CMMI e do MPS.BR. Outra abordagem ainda é a de se testar os softwares desenvolvidos frente a requisitos estabelecidos. Esta abordagem vai na linha da avaliação da conformidade de produtos. A dificuldade aqui diz respeito aos requisitos em relação aos quais se fazem os testes, pois não existem normas de produto para software como há na indústria. Não existem, por exemplo, normas para estabelecer os requisitos que o produto editor de texto deve cumprir considerando suas características específicas e seu desempenho e em relação aos quais os produtos possam ser testados e avaliados no mercado, como existem normas para produtos industriais. Na ausência dessas referências de desempenho esperado, o mais comum é testar o software em relação às características que o desenvolvedor planejou, para ver se ele faz aquilo que diz que faz. Naturalmente, o processo de testar o software pode ser bastante complicado e mesmo custoso. E resta saber como o cliente, que em última análise usará essa informação para decidir se faz, ou não, a compra, considerará esses resultados. Esta abordagem foi inclusive tentada como um mecanismo para a certificação de produtos de software, de maneira semelhante ao que se faz na indústria, mas com a ressalva que se mencionou, a de não se ter uma norma de referência para a avaliação. Convém agora, porém, voltar ao ponto inicial deste capítulo, que é a questão da qualidade para software. O ponto a realçar é o da qualidade, que é crítica, e que há diversas abordagens para se lidar com ela mas não se chegou ainda a uma solução definitiva para o problema. Os sistemas usados por modelos baseados em processos assumem uma abordagem indireta para a qualidade: assume-se que a qualidade é alcançada pela aplicação de processos bastante definidos. Os sistemas de gestão da qualidade, como 28

29 aqueles segundo a ISO 9001, estabelecem a qualidade como a referência para a gestão da empresa, mas não estabelecem como a empresa deve desenvolver o software. 5. Os sistemas de normas para software e seus usos Atualmente, no Brasil, as empresas do setor de software têm buscado a certificação como um instrumento de comunicação com os seus clientes, para promover diferenciação no mercado, assegurar aos seus clientes a sua competência e procurar penetrar, ou permanecer em determinadas fatias do mercado. As mais importantes, ou frequentes, têm sido, até então, a ISO 9001, o CMMI e o MPS-BR. Esta busca é decorrente da evolução da percepção da qualidade no mercado e de se procurar a competitividade. Como já mencionado, a questão da qualidade é uma questão candente para o setor e o mercado tem sido cada vez mais exigente quanto a isto. Particularmente, a partir dos anos 90, quando a qualidade passou a desempenhar em toda a economia um papel estratégico e decisivo, as iniciativas multiplicaram-se, no Brasil e no mundo. É por essa época que são publicadas as normas da série ISO 9000 e o Brasil engaja se no PBQP Programa Brasileiro da Qualidade e Produtividade. Esses anos constituem de fato o que se pode chamar e a revolução da qualidade. O mundo vive uma revolução tecnológica, com as tecnologias da informação e comunicação assumindo um papel cada vez mais relevante em todas as atividades, mudando hábitos, processos e culturas. O Brasil também almeja se tornar um relevante exportador de software e toma medidas e ações para promover e apoiar a exportação de software e as empresas. Normas e certificações em software 29

30 É nesse contexto que o CMMI começa a ganhar adeptos, no Brasil e no mundo. Muitas empresas também, acompanhando o que se passava em outros setores da economia, começam a adotar a ISO 9001 como referência para os seus sistemas da qualidade. Por essa época, tem-se a percepção de que o modelo CMMI é uma referência, mas também é um desafio. Os custos e esforços para a sua implementação são altos, o que dificulta sobremaneira a sua adoção, em especial pelas micro e pequenas empresas MPE. Toma-se então a iniciativa de se desenvolver um modelo brasileiro, compatível com o CMMI, mas que fosse mais acessível para as empresas, em especial as MPE. Surge o MPS-BR, Programa para melhoria do processo de software brasileiro e, no âmbito dele, o MR-MPS, modelo de referência de processos. Dessa maneira, o quadro que se apresenta é o seguinte: de um lado, empresas implementam (e são certificadas) sistemas de gestão da qualidade segundo a ISO De outro, empresas implementam o CMMI ou o MPS-BR. Há assim certa polarização em relação às soluções a serem adotadas para a qualidade. No entanto, a situação não é tão simples porque várias empresas implementam tanto a ISO 9001 quanto um dos modelos de processo. Há mesmo situações em que as empresas implementam o MPS-BR e também o CMMI. O resultado é mais custos para as empresas e certa falta de clareza do que o mercado quer. E isto é importante, o que os clientes querem. Pode-se dizer que, do lado dos clientes, a situação também não é clara. Há clientes que exigem um dos modelos de processos e outros exigem a ISO Já se disse que o setor não aderiu totalmente a ISO Com efeito, o setor de TI, no Brasil e no Mundo, é um dos poucos que ainda não se reconhece nesse conjunto de normas. E, consequentemente, ressente-se da ausência de uma clara referência internacional. A ISO tem desenvolvido bastantes normas para o setor (aliás, é o setor 30

31 em que há mais normas ISO/IEC publicadas) mas não contava, até então, com uma referência consagrada, e certificável, para a questão da qualidade das empresas de software 14. Contudo, mais recentemente, a ISO publicou as primeiras de uma série nova de normas, especificamente desenvolvidas para as MPE fornecedoras de software, a família ISO/IEC Essas normas estabelecem as referências para os processos a aplicar no desenvolvimento e fornecimento de software e são explicitamente elaboradas para atender às necessidades e características das MPE. Estas normas são certificáveis e, de maneira semelhante ao que ocorreu com as normas da série ISO 9000, a intenção é que se convertam na referência internacional para o mercado. Examinar-se-ão em seguida esses sistemas de normas em mais detalhe. 14 No acervo de normas do ISO/IEC/JTC1 há algumas normas mais recentes que procuram tratar dessas questões. Para os processos de engenharia de software e a sua avaliação foram publicadas as normas ABNT NBR ISO/IEC Tecnologia da informação - Avaliação de processo e ABNT NBR ISO/IEC Engenharia de sistemas e software - Processos de ciclo de vida de software. Foi ainda publicada recentemente a norma ISO/IEC Tecnologia da informação Gestão de serviços. Esta última segue a lógica dos sistemas de gestão, compatível, portanto, com a norma ISO As normas para segurança da informação ABNT NBR ISO/IEC Tecnologia da informação - Técnicas de segurança - Sistemas de gestão de segurança da informação - Requisitos também adotam o modelo de sistema de gestão. Foge ao escopo desta publicação a análise do acervo de normas internacionais. Recomenda-se uma visita ao site do JTC1 para mais informações acerca das normas publicadas. Normas e certificações em software 31

32 5.1 Norma ABNT NBR ISO/IEC O que é a ABNT NBR ISO/IEC O perfil básico do Grupo de Perfil Genérico 15 tem seus requisitos definidos na norma ISO/IEC , que tem por objetivo guiar uma VSE desenvolvedora de software no desenvolvimento e/ou manutenção de seus produtos, bem como no gerenciamento de seus projetos. O perfil básico é composto ainda pelo Guia de Engenharia e Gestão ABNT NBR ISO/IEC , documento que visa auxiliar as organizações na implementação dos requisitos definidos. Importante destacar que este guia não traz requisitos normativos. A norma ISO/IEC é uma norma internacional publicada e adotada como norma brasileira, definida como um Perfil VSE que trata de ciclo de vida software, basicamente dos processos de gestão de projetos e implementação de software. Tem como suas principais normas de base a ISO/IEC 12207, ABNT NBR ISO/IEC 12207:2009, Engenharia de sistemas e software Processos de ciclo de vida de software, e a ISO/IEC 15289, ISO/IEC 15289:2006, Systems and software engineering Content of systems and software life cycle process information products (Documentation). Além destas, em alguns pontos, a série busca também conformidade com a ISO Os processos do Perfil Básico O Perfil Básico define-se com dois processos: Gerência de Projetos (PM Project Management) e Implementação do Software (SI Software Implementation). 15 O Grupo de Perfil Genérico é destinado às empresas que desenvolvem softwares não-críticos e que não necessitam integração formal com outros sistemas. Entende-se aqui como não-críticos softwares cujo falha não possa causar impactos relacionados à segurança ou grandes prejuízos financeiros, ambientais ou sociais. (Adaptação ISO/IEC 29110, IEEE 610,12). 32

33 No Perfil Básico, é esperado que para iniciar o ciclo de vida de desenvolvimento de um projeto de software a organização tenha como entrada uma declaração de trabalho definida. E ao final do seu ciclo, o projeto terá como saída o software configurado para ser entregue ao cliente. O diagrama representado na figura a seguir ilustra a interação entre esses dois processos descritos na ISO/IEC : Figura Interação entre os processos do Perfil Básico 16 A descrição de processos da ISO/IEC segue a seguinte estrutura, e as seguintes notações são usadas para identificar os elementos dos processos: Processo identificado por seu nome e por uma sigla de duas letras (exemplo: Gerência de Projetos, PM); Objetivo do processo identificado por uma sigla composta pelas letras de identificação do processo, seguida por um ponto, pela letra O e uma numeração sequencial (exemplo: PM.O1); 16 ABNT ISO/IEC TR :2012 Engenharia de Software Perfis de ciclo de vida para micro-organizações (VSE) Parte 5-1-2: Guia de engenharia e gestão: Grupo perfil genérico: Perfil básico Normas e certificações em software 33

34 Atividade as atividades do processo são identificadas pela sigla do processo, ponto e uma numeração sequencial (exemplo: PM.1); Tarefa as tarefas das atividades são identificadas pela sigla da atividade à qual pertence, ponto e uma numeração sequencial (exemplo: PM.1.1); Entradas das atividades são identificadas pelo respectivo nome (exemplo: Declaração de Trabalho); Saídas das atividades são identificadas pelo respectivo nome (exemplo: Plano de Projeto). A figura a seguir mostra o relacionamento e o fluxo de interação entre os elementos dos processos: Figura Elementos dos Processos da ISO/IEC VILLAS BOAS, Gisele. Guia de uso e aplicação da série ABNT NBR ISO/IEC desenvolvimento de software para pequenas organizações. ABNT/SEBRAE,

35 Cada processo do Perfil Básico Grupo de Perfil Genérico possui um único propósito: ISO Gerência de Projetos (PM Project Management) O PROPÓSITO DO PROCESSO DE PM é estabelecer e manter sistematicamente as tarefas de implementação, visando os objetivos de qualidade esperada, tempo e custo. ISO Implementação do Software (SI Software Implementation) O PROPÓSITO DO PROCESSO DE SI é realizar sistematicamente as atividades de análise, projeto, construção, integração e testes para um novo software ou uma modificação, de acordo com os requisitos especificados. Como se vê na figura anterior, para cada um desses propósitos é estabelecido um conjunto de objetivos específicos. São esses os Objetivos do Processo. Para alcançar os objetivos do processo, são definidas atividades obrigatórias que recebem produtos de entrada e geram produtos de saída. Os produtos de entrada são gerados por atividades que podem ser intrínsecas ou extrínsecas ao processo e são, portanto, opcionais. Os produtos de saída são gerados pelas atividades realizadas ou pelas tarefas detalhadas de cada uma delas. Há ainda produtos internos que servem de apoio à realização das atividades e que são, também, opcionais. As atividades definidas como obrigatórias para cada processo são descritas no nível de macroatividades e devem ser executadas por meio de um conjunto de tarefas mais detalhadas. Entretanto, as tarefas descritas no Perfil Básico são opcionais. Isso significa dizer que a VSE deve avaliar a adequação do conjunto de tarefas Normas e certificações em software 35

36 sugerido, podendo optar por segui-las em sua totalidade, em parte ou, ainda, decidir por compor um novo conjunto de tarefas que alcance os resultados esperados pelas atividades obrigatórias Os requisitos da norma ISO/IEC Como já descrito no item anterior, a norma ISO/IEC :2012, parte 4 do Perfil Básico, foi desenvolvida considerando dois tipos de requisitos normativos: a) Requisitos mandatórios Como o próprio nome diz, são elementos obrigatórios e devem, necessariamente, ser implementados para que se obtenha um completo atendimento à norma em questão. São requisitos mandatórios: Os objetivos dos processos; As atividades descritas; Os produtos de saída gerados pela realização das atividades. b) Requisitos opcionais São representados por um conjunto de elementos por meio dos quais é possível se chegar aos elementos mandatórios. São requisitos opcionais os produtos de entrada para cada atividade e as tarefas detalhadas para cada atividade descrita. As tabelas 5.1 e 5.2 a seguir demonstram um resumo dos elementos que estão descritos como requisitos mandatórios na ISO/ IEC

37 Tabela Visão consolidada dos Requisitos Obrigatórios do Perfil Básico Processo PM O PROPÓSITO DO PROCESSO DE PM é estabelecer e manter sistematicamente as tarefas de implementação, visando os objetivos de qualidade esperada, tempo e custo. Objetivos do Processo Atividades Produtos PM.O1 O Plano de Projeto para a execução do projeto é desenvolvido de acordo com a Declaração de Trabalho e revisto e aceito pelo Cliente. As tarefas e os recursos necessários para completar o trabalho são dimensionados e estimados. PM.O2 O progresso do projeto é monitorado contra o Plano de Projeto e registrado no Registro de Status de Progresso. Ações corretivas para corrigir os problemas e desvios do plano são tomadas quando as metas do projeto não foram alcançadas. O encerramento do projeto é formalizado para obter o aceite do cliente, documentado no Registro de Aceitação. PM.O3 As Solicitações de Mudança são tratadas através de sua recepção e análise. Alterações nos requisitos de software são avaliadas quanto ao custo, cronograma e impacto técnico. PM.O4 São mantidas reuniões de revisão com a equipe de trabalho e os clientes. As decisões são registradas e monitoradas. PM.O5 Os riscos são identificados inicialmente e durante a condução do projeto. PM.O6 Uma Estratégia de Controle de Versão do software é desenvolvida. Itens de Configuração de Software são identificados, definidos e postos em baseline. As modificações e liberações dos itens são controladas e disponibilizadas ao Cliente e à Equipe de Trabalho. O armazenamento, manuseio e entrega dos itens são controlados. Planejamento do projeto Execução do Plano de Projeto Controle e avaliação do projeto Encerramento do projeto Declaração de Trabalho Plano do Projeto Registro de Aceitação Repositório de Projeto Registro de Reunião Configuração do Software PM.O7 A Garantia de Qualidade de Software é realizada para assegurar que produtos e processos de trabalho cumpram o Plano de Projeto e a Especificação de Requisitos. Normas e certificações em software 37

38 Tabela Visão consolidada dos Requisitos Obrigatórios do Perfil Básico Processo SI O PROPÓSITO DO PROCESSO DE SI é realizar sistematicamente as atividades de análise, projeto, construção, integração e testes, para um novo software ou uma modificação, de acordo com os requisitos especificados. Objetivos do Processo Atividades Produtos SI.O1. Tarefas das atividades são realizadas em cumprimento do Plano de Projeto. SI.O2. Requisitos de Software são definidos, analisados quanto à correção e testabilidade, aprovados pelo Cliente, colocados em baseline e comunicados. SI.O3. Um projeto de arquitetura e detalhamento é desenvolvido e posto em baseline. Ele descreve os itens de software e suas interfaces internas e externas. É estabelecida consistência e rastreabilidade aos requisitos de software. SI.O4. Os componentes de software definidos pelo projeto são produzidos. Testes unitários são definidos e realizados para verificar a consistência com os requisitos e com o projeto. É estabelecida rastreabilidade para os requisitos e para o projeto. SI.O5. Software é produzido fazendo a integração dos componentes de software e é verificado usando Casos de Teste e Procedimentos Teste. Os resultados são registrados no Relatório de Teste. Os defeitos são corrigidos e é estabelecida consistência e rastreabilidade ao Projeto Software. Iniciação da Implementação do Software Análise dos Requisitos do Software Projeto de Arquitetura e Detalhamento do Software Construção do Software Integração e Testes do Software Entrega do Produto Solicitação de Mudança Especificação de Requisitos Documentação do Usuário do Software Resultados de Validação Resultados de Verificação Projeto do Software Casos de Teste e Procedimentos de Teste Registro de Rastreabilidade Configuração do Software Componentes do Software 38

39 O PROPÓSITO DO PROCESSO DE SI é realizar sistematicamente as atividades de análise, projeto, construção, integração e testes, para um novo software ou uma modificação, de acordo com os requisitos especificados. Objetivos do Processo Atividades Produtos SI.O6. Uma Configuração de Software, que atende à Especificação de Requisitos conforme acordado com o Cliente, a qual inclui documentações do usuário, de operação e de manutenção é integrada, colocada em baseline e armazenada no Repositório do Projeto. Necessidades de alterações na Configuração do Software são detectadas e as devidas Solicitações de Mudança são iniciadas. SI.O7. Tarefas de Verificação e Validação de todos os produtos de trabalho necessários são realizadas usando critérios definidos para assegurar a consistência entre produtos de saída e entrada em cada atividade. Defeitos são identificados e corrigidos, Registros são armazenados em Resultados de Verificação/Validação. Guia de Operação do Produto Software Casos de Teste e Procedimentos de Teste Relatório de Teste Documentação de Manutenção 5.2 Norma ABNT NBR ISO 9001 A partir de meados dos anos 80 do século passado, houve uma mudança profunda na maneira de fazer negócios. Um dos aspectos mais importantes desse fenômeno foi o papel que a qualidade passou a desempenhar. O acirramento da competição, a intensificação da globalização e o papel cada vez mais destacado da tecnologia mudaram as relações de mercado. A qualidade assumiu o papel preponderante na competitividade e assistiu-se, de fato, um salto de qualidade nos produtos e serviços. Normas e certificações em software 39

40 Passou-se do controle da qualidade para a garantia da qualidade e desta para a gestão da qualidade. A qualidade passou a ser necessariamente um dos focos da gestão e da Alta Administração. Deixou de ser uma tecnicalidade ou um mero atributo de um produto. Os sistemas de gestão da qualidade constituíram a chave para resolver o problema de como assegurar a qualidade dos produtos ou serviços e a satisfação dos clientes. Neste percurso, os diversos países e organizações desenvolveram os seus sistemas de gestão da qualidade e, logo em seguida, normas de sistemas de gestão da qualidade. Se por um lado a proliferação de normas de sistemas de gestão da qualidade auxiliou a mudança necessária, por outro, passou também a ser um potencial entrave e complicador nos negócios quando se passava de uma atuação focada nos mercados nacionais para um foco no mercado internacional. A solução era o desenvolvimento e adoção de uma norma internacional como referência, a família ISO A certificação do sistema de gestão, de acordo com a ISO 9000, foi uma consequência natural. E, de fato, a partir da década de 80 a certificação de sistemas de gestão da qualidade ganhou impulso como um instrumento extremamente eficaz de comunicação de uma empresa com os seus clientes. A publicação da série de normas ISO 9000 constitui um marco deste percurso. A crescente importância da gestão da qualidade, evoluindo do controle da qualidade, como ferramenta para assegurar a qualidade pretendida pelos clientes, resultou na solicitação para que as empresas demonstrassem que o seu sistema de garantia da qualidade atendia às normas requeridas pelos seus clientes. Naturalmente, a diversidade de normas constituía uma dificuldade a mais e um custo adicional. Um dos principais méritos da série ISO 9000 é que ela representa um sólido e amplo consenso acerca dos sistemas de gestão da qualidade, aceita em todo mundo. Desta forma, a adoção da ISO 9000, substituindo as diversas normas nacionais diferentes, representou um salto que promoveu a competitividade das empresas numa escala sem precedentes. Pode-se dizer 40

41 que a série ISO 9000 é um dos pilares do processo de globalização das economias porque possibilitou o estabelecimento de uma linguagem comum para a qualidade e o consenso para os sistemas de gestão da qualidade. A certificação segundo a norma ISO 9001 representou uma profunda simplificação nos processos de transação e possibilitou que muitas empresas, em particular micro, pequenas e médias, tivessem a sua competência e a sua qualidade percebidas e reconhecidas. Desta maneira, a certificação segundo a ISO 9001, que hoje ultrapassou a casa do milhão de organizações no mundo, converteu-se em um dos instrumentos fundamentais para a competitividade no mercado global. A própria ISO ficou conhecida do cidadão comum. Contudo, é importante ressaltar que a certificação segundo a ISO 9001 é dirigida para a relação entre empresas, não entre a empresa e os consumidores. Isto é importante compreender: a certificação segundo a norma ISO 9001 não atesta a qualidade do produto em si mesmo, mas sim a capacidade de a empresa fornecer produtos ou serviços de acordo com o solicitado. Por isso se diz algumas vezes que a certificação segundo as normas ISO 9000 é uma certificação de processo e não de produto. Um Sistema de Gestão pode ser conceituado como um sistema destinado a assegurar que determinado resultado pretendido (e, portanto, planejado) por uma organização é obtido de maneira sistemática e consistente, ou seja, não acontece por acaso. Usualmente, um Sistema de Gestão pode ser representado através da lógica do ciclo do PDCA. O ciclo do PDCA é um agrupamento de letras que, em inglês, significa Plan-Do-Check-Act. Resumidamente, pode-se descrever as atividades do ciclo PDCA por: Plan (Planejar) identificar os requisitos aplicáveis à organização. Em seguida define-se a política de gestão e com base nestas informações (requisitos e políticas) de- Normas e certificações em software 41

42 terminam-se os objetivos e metas a serem perseguidos pelo empreendimento e os processos necessários para alcançá-los (programa de gestão). Do (Implementar) implementar e operacionalizar os processos de acordo com o programa de gestão, alocando recursos e definindo autoridades, responsabilidades e competências necessárias. Check (Verificar) monitorar, medir e analisar criticamente os resultados dos processos em relação à política, objetivos e metas e relatar os resultados. Act (Agir) implementar ações que ajudam a corrigir o que não está funcionado bem (ações corretivas) e, principalmente, para melhorar o que já foi feito (ações preventivas), melhorando continuamente a performance do sistema de gestão. Figura Ciclo PDCA 42

43 Figura Modelo gráfico das interações entre as macroatividades típicas de um sistema de gestão consistente A Figura 5.4 apresenta o modelo gráfico que ilustra as interações entre as macroatividades típicas de um sistema de gestão consistente e que tem os seguintes componentes mínimos: Política na política, são estabelecidos explicitamente os compromissos da organização em relação ao objeto do sistema de gestão. Constitui-se no compromisso da Alta Administração que passa a incorporar o objeto do sistema de gestão (qualidade, segurança, meio ambiente etc.) no centro das suas atenções e objetivos de gestão. Planejamento são estabelecidos os objetivos e metas que proporcionarão a implementação efetiva da política. São estabelecidas também a estrutura, responsabilidades e alocação de recursos necessários à implementação da política para assegurar que os objetivos e metas sejam alcançados. Normas e certificações em software 43

44 Frequentemente, são estabelecidos planos de gestão para se alcançar cada objetivo (com responsável, atividades, recursos necessários e prazos, por exemplo). Implementação e operação são estabelecidos os processos para implementação do planejado, incluindo os controles operacionais e os processos para a realização dos serviços, produtos ou outros objetos do sistema de gestão. Mecanismos de revisão, monitoramento e melhoria contínua são estabelecidos os mecanismos, autoridades e recursos para o monitoramento da aplicação da política, como processos de controle, auditorias internas, análises críticas, incluindo a análise crítica pela Alta Administração e a revisão dos objetivos e metas para assegurar a melhoria contínua. A essência da ISO 9001 é o atendimento às expectativas do cliente. A norma está concebida para ser implementada segundo a lógica de processos. 44

45 Figura Modelo de um sistema de gestão da qualidade baseado em processos 18 Convém referir algumas definições da norma: Sistema de gestão: sistema para estabelecer políticas e objetivos, e para atingir esses objetivos. Sistema de gestão da qualidade: é um sistema de gestão para dirigir e controlar uma organização no que diz respeito à qualidade. O sistema de gestão envolve: Estrutura organizacional; Autoridades e responsabilidades; Atividades de planejamento; Práticas; 18 ABNT NBR ISO 9001:2008 Sistemas de gestão da qualidade Requisitos. Normas e certificações em software 45

46 Procedimentos; Processos; Recursos. Um sistema para desenvolver, implementar, atingir, analisar criticamente e manter a política e objetivos da qualidade. A norma tem uma estrutura simples. Os seus capítulos são os seguintes: Introdução 1) Escopo 2) Referência normativa 3) Termos de definições 4) Sistema de gestão da qualidade 5) Responsabilidades da direção 6) Gestão de recursos 7) Realização do produto 8) Medição, análise e melhoria Anexo A (informativo) - Correspondência entre a ABNT NBR ISO 9001:2008 e a ABNT NBRISO 14001:2004 Anexo B (informativo) - Alterações entre a ABNT NBR ISO 9001:2000 e a ABNT NBR ISO 9001:2008 Bibliografia Os capítulos que contêm requisitos são os capítulos de 4 a 8. O capítulo 4 estabelece os requisitos para o sistema da qualidade. Refere que a organização deve: a) Determinar os processos necessários para o sistema de gestão da qualidade e sua aplicação por toda a organização; 46

47 b) Determinar a sequência e interação desses processos; c) Determinar critérios e métodos necessários para assegurar que a operação e o controle desses processos sejam eficazes; d) Assegurar a disponibilidade de recursos e informações necessárias para apoiar a operação e o monitoramento desses processos; e) Monitorar, medir onde aplicável e analisar esses processos; f) Implantar ações necessárias para atingir os resultados planejados e a melhoria continua desses processos. Esses processos devem ser gerenciados pela organização de acordo com os requisitos da Norma. O capítulo estabelece ainda requisitos para a documentação, e seu controle. O capítulo 5 trata da Direção da empresa e seu comprometimento e papel na gestão do sistema. Aborda questões como o foco no cliente, a política da qualidade, o planejamento, responsabilidades, autoridade e comunicação e a necessidade da análise crítica pela Direção. O capítulo 6, que trata da gestão de recursos, contém os requisitos relacionados ao provimento dos recursos necessários para implementar e manter o sistema e também para aumentar a satisfação dos clientes mediante o atendimento aos seus requisitos. Trata ainda dos recursos humanos, inclusive competência, conscientização e treinamento, da infraestrutura (edifícios e instalações, equipamentos e serviços de apoio) e do ambiente de trabalho. Para descrever o capítulo 7, realização do produto, é conveniente relacionar como está estruturado: 7.1 Planejamento da realização do produto 7.2 Processos relacionados a clientes Normas e certificações em software 47

48 7.3 Projeto e desenvolvimento 7.4 Aquisição 7.5 Produção e prestação de serviço 7.6 Controle de equipamento de monitoramento e medição No planejamento, a norma refere que a organização deve determinar, quando apropriado: a) Os objetivos da qualidade e requisitos para o produto; b) A necessidade de estabelecer processos e documentos e prover recursos específicos para o produto; c) A verificação, validação, monitoramento, medição, inspeção e atividades de ensaio requeridos, específicos para o produto, bem como os critérios para aceitação do produto; d) Os registros necessários para fornecer evidência de que os processos de realização do produto resultante atendem aos requisitos. Nos processos relacionados aos clientes, está referido que a organização deve determinar: a) Os requisitos especificados pelo cliente, incluindo os requisitos para entrega e para atividades pós-entrega; b) Os requisitos não declarados pelo cliente, mas necessários para o uso especificado ou pretendido, onde conhecido; c) Requisitos estatutários e regulamentares aplicáveis ao produto; d) Quaisquer requisitos adicionais considerados necessários pela organização. Há ainda requisitos relacionados com os processos de comunicação com o cliente, e com a análise crítica dos requisitos. 48

49 No item de projeto e desenvolvimento, trata-se de todos os aspectos relacionados com o planejamento do projeto e desenvolvimento, as entradas e as saídas do processo de projeto e desenvolvimento, a análise crítica, a verificação, a validação e ainda o controle de alterações. Em aquisição, trata-se de todos os aspectos relacionados com o que a organização compra para a realização do produto, inclusive a avaliação e seleção dos fornecedores e o controle do produto adquirido. Em 7.5 trata-se da produção propriamente dita e seu controle. Assim, estabelece requisitos para o controle da produção e prestação do serviço, validação dos processos de produção, identificação e rastreabilidade, da preservação do produto e também do que é propriedade do cliente e utilizado pela organização. Em 7.6 trata-se, como o próprio título indica, do controle do equipamento de monitoramento e medição. O capítulo 8, que trata de medição, análise e melhoria, aborda o monitoramento e medição da satisfação do cliente, de importância chave para a qualidade, a realização de auditorias internas, monitoramento e medição de processos e produtos, controle de produto não-conforme, análise de dados, melhoria contínua, ações corretivas e ações preventivas. Com esta breve descrição da norma, pode-se perceber a sua abrangência. Um ponto a destacar é que a norma não diz como as coisas têm que ser feitas, mas sim o quê. Isto é, a própria organização é que deve determinar as soluções apropriadas e as técnicas e métodos adequados para fornecer o produto. Destaque-se também a importância que é posta no cliente e na sua satisfação. A norma foi escrita de maneira a ser aplicável a qualquer organização, de qualquer porte e de qualquer setor. Normas e certificações em software 49

50 A norma evoluiu bastante desde as suas primeiras versões. Uma das críticas feitas a ela era a de que a norma gerava muita burocracia. A versão atual, aprimorada a partir da experiência prática de centenas de milhares de organizações dos mais variados setores reduziu substancialmente a burocracia necessária, com foco nos resultados. No Brasil, a norma está bastante disseminada em todos os setores. No próprio setor de software há um número expressivo de empresas com a norma implementada. A certificação no Brasil é realizada por 37 organismos de certificação acreditados pelo Inmetro. Como o mercado é livre na área voluntária, há ainda outros organismos que atuam no mercado brasileiro, normalmente com acreditações em outros países. 5.3 MR-MPS-SW Modelo de Referência MPS para Software 19 O MPS.BR - Melhoria do Processo de Software Brasileiro - nasceu em 2003 como um programa mobilizador, de longo prazo, sob a coordenação da Sociedade Brasileira para Promoção da Exportação de Software - SOFTEX, tendo como uma de suas metas definir e aprimorar um modelo de melhoria e avaliação de processos de software, visando preferencialmente às micro, pequenas e médias empresas, de forma a atender as suas necessidades de negócio. O modelo MPS foi definido com base nas normas ISO/IEC (ISO/IEC15504, 2003) e ISO/IEC (ISO/IEC12207, 2008) e em conformidade com o CMMI-DEV e sua estrutura está dividida em três componentes: Modelo de Referência (MR-MPS), Método de Avaliação (MA-MPS) e Modelo de Negócio (MN-MPS). Cada componente é descrito por meio de guias e/ou documentos do modelo MPS. 19 Guia Geral MR-MPS-SW,

51 O Modelo de Referência MPS para Software descreve os requisitos para que os processos das empresas estejam em conformidade com o MR MPS-SW 20. Ele contém a definição dos níveis de maturidade, dos processos e dos atributos do processo relacionados a cada nível de maturidade. O MR-MPS-SW define sete níveis de maturidade, sequenciais e cumulativos, descritos a seguir: Nível G (Gerenciado Parcialmente) Nível F (Gerenciado) Nível E (Parcialmente Definido) Nível D (Largamente Definido) Nível C (Definido) Nível B (Gerenciado Quantitativamente) Nível A (Em Otimização) A escala de maturidade começa no nível G e evolui até o nível A, quando a organização atinge a alta maturidade. Se comparado ao CMMI-DEV 21, o modelo possui três níveis avaliáveis a mais. A criação desta divisão em um maior número de níveis teve o intuito de melhor atender às pequenas e médias empresas, as quais poderão alcançar seus objetivos de melhoria em etapas intermediárias. Cada nível de maturidade é uma combinação dos processos e da capacidade dos processos. Os processos são descritos segundo o propósito e os resultados esperados. O propósito descreve o objetivo a ser atingido com a execução do processo e os resultados esperados estabelecem os que devem ser obtidos com a efetiva implementação do processo. Já a capacidade do processo é representada por um conjunto de atributos descritos em termos de resultados esperados. 20 SOFTEX, SEI, Normas e certificações em software 51

52 O progresso e o alcance de um determinado nível de maturidade do MR-MPS-SW se obtêm quando são atendidos os resultados esperados dos processos e dos atributos de processos estabelecidos para aquele nível. Os atributos de processo (AP) são uma característica mensurável da capacidade do processo. O atendimento aos atributos do processo (AP), pelo atendimento aos resultados esperados dos atributos do processo (RAP), é requerido para todos os processos no nível correspondente ao nível de maturidade, embora eles não sejam detalhados dentro do processo. 22 A figura a seguir apresenta a estrutura técnica do MR-MPS-SW: Figura Estrutura do MR-MPS-SW Nas tabelas a seguir estão relacionados cada atributo de processo e os processos e os atributos de processo definidos pelo modelo para cada nível de maturidade. 22 SOFTEX,

53 Tabela Atributos de Processo (SOFTEX, 2012a) Atributo de Processo Descrição Propósito AP 1.1 AP 2.1 AP 2.2 AP 3.1 AP 3.2 AP 4.1 AP 4.2 AP 5.1 AP 5.2 O processo é executado. O processo é gerenciado. Os produtos de trabalho do processo são gerenciados. O processo é definido. O processo está implementado. O processo é medido. O processo é controlado. O processo é objeto de melhorias incrementais e inovações. O processo é otimizado continuamente. Este atributo evidencia o quanto a execução do processo é gerenciada. Este atributo evidencia o quanto a execução do processo é gerenciada. Este atributo evidencia o quanto os produtos de trabalho produzidos pelo processo são gerenciados apropriadamente. Este atributo evidencia o quanto um processo padrão é mantido para apoiar a implementação do processo definido. Este atributo evidencia o quanto o processo padrão é efetivamente implementado como um processo definido para atingir seus resultados. Este atributo evidencia o quanto os resultados de medição são usados para assegurar que a execução do processo atinja os seus objetivos de desempenho e apoie o alcance dos objetivos de negócio definidos. Este atributo evidencia o quanto o processo é controlado estatisticamente para produzir um processo estável, capaz e previsível dentro de limites estabelecidos. Este atributo evidencia o quanto as mudanças no processo são identificadas a partir da análise de defeitos, problemas, causas comuns de variação do desempenho e da investigação de enfoques inovadores para a definição e implementação do processo. Este atributo evidencia o quanto as mudanças na definição, gerência e desempenho do processo têm impacto efetivo para o alcance dos objetivos relevantes de melhoria do processo. Normas e certificações em software 53

54 Tabela Níveis de maturidade do MR-MPS-SW (SOFTEX, 2012a) Nível de maturidade A B C D Atributos de Processo Processo - AP 1.1, AP 2.1, AP 2.2, Gerência de Projetos GPR (evolução) Gerência de Riscos GRI Desenvolvimento para Reutilização DRU Gerência de Decisões GDE Verificação VER Validação VAL Projeto e Construção do Produto PCP Integração do Produto ITP Desenvolvimento de Requisitos DRE AP 3.1, AP 3.2, AP 4.1, AP 4.2, AP 5.1 e AP 5.2 AP 1.1, AP 2.1, AP 2.2, AP 3.1, AP 3.2, AP 4.1, e AP 4.2 AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2 AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2 E Gerência de Projetos GPR (evolução) Gerência de Reutilização GRU Gerência de Recursos Humanos GRH Definição do Processo Organizacional DFP Avaliação e Melhoria do Processo Organizacional AMP AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP

55 Nível de maturidade F G Processo Medição MED Garantia da Qualidade GQA Gerência de Portfólio de Projetos GPP Gerência de Configuração GCO Aquisição AQU Gerência de Requisitos GRE Gerência de Projetos GPR Atributos de Processo AP 1.1, AP 2.1 e AP 2.2 AP 1.1 e AP CMMI-DEV O CMMI-DEV 23 é um modelo de maturidade e capacidade de processos de software criado pelo SEI (Software Engineering Institute) para atender às demandas do DoD 24 quanto à avaliação de riscos na contratação de seus fornecedores de software. O modelo consiste de boas práticas de engenharia de software para o desenvolvimento e manutenção de produtos e serviços e oferece uma estrutura e elementos chave para um processo de software, abrangendo todo o ciclo de produção, desde a concepção até a entrega e manutenção do software, representando ainda um caminho evolutivo para a organização em busca de um processo maduro e disciplinado. O CMMI-DEV possui dois tipos de representação: Representação contínua Representação por estágios Na representação contínua, as áreas de processos são organizadas em categorias e a implementação da melhoria ocorre por níveis de capacidade, enquanto que na representação por estágios 23 SEI, DoD - Department of Defense (Departamento de Defesa dos Estados Unidos). Normas e certificações em software 55

56 as áreas de processos são organizadas em níveis de maturidade. Na representação contínua, as áreas de processos podem ser avaliadas individualmente, segundo a estratégia e os objetivos de negócio da organização. Já na representação por estágios, a avaliação é realizada em todas as áreas de processos que compõem o nível de maturidade selecionado pela organização. Os tipos de representação diferem na seleção e organização dos componentes do modelo, mas utilizam o mesmo conjunto de processos e práticas. Embora as duas possibilidades de avaliação estejam disponíveis, o mercado não reconheceu valor na representação contínua e, como reflexo, a maioria das avaliações CMMI realizadas até esta data seguiram a representação por estágios. Os níveis indicam uma sequência lógica para a evolução das áreas de processo, na medida em que satisfaçam as exigências do modelo. Enquanto um nível de capacidade está relacionado a uma área de processo, os níveis de maturidade estão relacionados a um grupo de áreas de processos. Os níveis de maturidade e de capacidade definidos no CMMI-DEV estão relacionados na Tabela a seguir. Tabela Níveis de capacidade e de maturidade do CMMI-DEV (SEI, 2010) Nível Nível de capacidade (representação contínua) 0 Incompleto - 1 Realizado Inicial 2 Gerenciado Gerenciado 3 Definido Definido Nível de maturidade (representação por estágios) 4 - Gerenciado quantitativamente 5 - Em otimização 56

57 Com relação à sua estrutura, o CMMI-DEV é formado por componentes agrupados em três categorias: componentes requeridos, componentes esperados e componentes informativos. Eles auxiliam na interpretação do modelo, conforme apresentado na figura a seguir: Figura Estrutura CMMI Cada área de processo é um conjunto de práticas relacionadas que, implementadas conjuntamente, satisfazem os objetivos considerados importantes para constituir a melhoria do processo e, consequentemente, da organização. O CMMI-DEV é composto por 22 áreas de processos, que podem ser observadas na tabela a seguir com os respectivos níveis de maturidade e categorias. Tabela Áreas de Processo do CMMI-DEV (SEI, 2010) Nível de Maturidade Área de Processo Categoria 2 Monitoração e Controle do Projeto Gerência de Projeto (PMC) 2 Planejamento do Projeto (PP) Gerência de Projeto 2 Gerência de Requisitos (REQM) Gerência de Projeto Normas e certificações em software 57