FUNDAÇÃO EDSON QUEIROZ UNIVERSIDADE DE FORTALEZA – …livros01.livrosgratis.com.br/cp005220.pdf · Figura 3.6: Visão do Software no sistema (NBR ISO/IEC 15271, 2000) 59 Figura

FUNDAÇÃO EDSON QUEIROZ

UNIVERSIDADE DE FORTALEZA – UNIFOR

Raimundo Sales Neto e Azevedo

Um Sistema de Gestão da Qualidade para Micro, Pequenas, e

Médias Empresas de software a partir da ISO 9001 e ISO/IEC

12207

Fortaleza

2005

Livros Grátis

http://www.livrosgratis.com.br

Milhares de livros grátis para download.

FUNDAÇÃO EDSON QUEIROZ

UNIVERSIDADE DE FORTALEZA – UNIFOR




12207

Dissertação apresentada ao Curso de Mestrado em Informática Aplicada (MIA) da Universidade de Fortaleza (UNIFOR), como requisito parcial para obtenção do título de Mestre em Informática.

Orientador: Prof. Dr. Arnaldo Dias Belchior

Fortaleza 2005




12207

Data de Aprovação: 11/11/2005

Banca Examinadora:

Prof. Dr. Arnaldo Dias Belchior

(orientador - UNIFOR)

Prof. Dr. José Bezerra da Silva Filho

(membro – UNIFOR)

Prof. Dra. Ana Cervigni Guerra

(membro – UNICAMP/CenPRA)

FICHA DE CATALOGAÇÃO

AZEVEDO, Raimundo Sales Neto. 2005. Um Sistema de Gestão da Qualidade para Micro, Pequenas, e Médias Empresas de software a partir da ISO 9001 e ISO/IEC 12207. Dissertação de Mestrado. Universidade de Fortaleza (UNIFOR).

Perfil do Autor: Graduado em Bacharelado em Ciência da Computação pela Universidade Estadual do Ceará (UECE). Especialista em Tecnologia da Informação pela Universidade Federal do Ceará (UFC). Professor de cursos de graduação em informática. Consultor certificado para Implementação do modelo de qualidade MR-mps Br.

RESUMO: A realidade das micros, pequenas e médias empresas brasileiras (MPMEs) de software é caracterizada pela escassez de recursos, que tem dificultado e até inviabilizado a implementação de modelos de qualidade, que permitam melhorar seu processo organizacional e adquirir a capacidade de gerenciar com eficácia o desenvolvimento e a manutenção de seus produtos ou serviços de software. Neste contexto, este trabalho propõe um Sistema de Gestão da Qualidade (SGQ) para MPMEs brasileiras de software, que visa o atendimento dos requisitos e a satisfação do cliente em sintonia com a contínua melhoria de seus processos. O SGQ está baseado na integração das abordagens da ISO 9001:2000 e na ISO/IEC 12207, e envolve um conjunto de procedimentos, que foram validados em um estudo de caso realizado em duas pequenas empresas de software brasileiras, que receberam a certificação ISO 9001 a partir desta proposta.

PALAVRAS-CHAVE: Qualidade de Processo de Software – ISO 9001 – Certificação – Garantia de Qualidade de Software – ISO/IEC 12207

DEDICATÓRIA

Dedico este esforço aos que sempre seguiram

comigo, na torcida, no caminho e nos Bons Combates da vida.

E, com especial carinho e orgulho, à minha esposa Sandra

e à minha filha Rebeca.

AGRADECIMENTOS

A Deus que ao longo de toda minha vida me inspirou, protegeu e abençoou com aqueles que

cruzaram meu caminho. Meus pais, avós e tios com suas bondade, dedicação à família,

seriedade e gentileza no trato com os outros. Meus irmãos pelo companheirismo e apoio.

A todos meus primeiros professores por desde cedo exigirem o raciocínio e despertarem o

interesse nos estudos. Aos meus atuais mestres: Prof. Pedro Porfírio, pela confiança

depositada desde o início do curso e por todo seu andamento e pelas suas inspiradoras

disciplinas, Prof. Vasco, pela sua exigente maneira de criar em nós novos conhecimentos.

Prof. Bezerra, pela sua capacidade de despertar os mais variados interesses e sempre

conseguir relacioná-los. Prof. Nabor, pelos seus questionamentos e desafios constantes. Prof.

Elizabeth pela forma tão suave de exigir sempre mais esforço e dedicação. Prof. Belchior que

pela sua paciência, orientação, conselhos e exemplo de dedicação, sintetizou todos os meus

diversos, dispersos e, às vezes, confusos interesses.

À organização do MIA nas pessoas da nossa incansável Tânia e do nosso dedicado

coordenador Prof. Plácido, pelo apoio, conselhos e exemplos de amor ao que fazem.

Aos amigos da turma IV. Em especial, Lívia, Pascale, Rejane e Frank pelos muitos momentos

de discussões, conversas, pesquisas, apoio, torcida e verdadeira amizade.

Aos profissionais e novos amigos que encontrei ao longo da aplicação deste trabalho, com

especial carinho e muita gratidão, Flávio Lenz, Francisco Pinto, Marum Simão Filho e demais

companheiros da SoftExport, André Chaves, Régis Melo, Márcia Néa e demais companheiros

da SoftSite, Sérgio Pisandelli e sua visão toda especial da Qualidade e Eduardo Molena pelas

suas análises e apontamentos da aplicação do trabalho.

Às minhas mulheres (Sandra e Rebeca) pela compreensão, apoio, dedicação, incentivo,

conselhos e mimos, meus sinceros agradecimentos e pedidos de desculpas pelas ausências e

privações que foram vítimas.

“A coisa não está nem na partida e nem na chegada, mas na travessia..." Guimarães Rosa

RESUMO

A realidade das micro, pequenas e médias empresas brasileiras (MPMEs) de software é

caracterizada pela escassez de recursos, que tem dificultado e até inviabilizado a

implementação de modelos de qualidade, que permitam melhorar seu processo organizacional

e adquirir a capacidade de gerenciar com eficácia o desenvolvimento e a manutenção de seus

produtos ou serviços de software. Neste contexto, este trabalho propõe um Sistema de Gestão

da Qualidade (SGQ) para MPMEs brasileiras de software, que visa o atendimento dos

requisitos e a satisfação do cliente em sintonia com a contínua melhoria de seus processos. O

SGQ está baseado na integração das abordagens da ISO 9001:2000 e da ISO/IEC 12207, e

envolve um conjunto de procedimentos, que foram validados em um estudo de caso realizado

em duas pequenas empresas de software brasileiras, que receberam a certificação ISO 9001 a

partir desta proposta.

PALAVRAS-CHAVE: Qualidade de Processo de Software – ISO 9001 – Garantia de

Qualidade de Software– Gerenciamento da Qualidade – ISO/IEC 12207

ABSTRACT

The reality of micro, small e median companies in Brazil (MSMCs) of software is

characterized by the scarcity of resources, that has made it difficult and until made

impracticable the implementation of quality models, that they allow to improve its

organizacional process and to acquire the capacity to manage with effectiveness the

development and the maintenance of its products or services of software. In this context, this

work considers a Quality Management System (QMS) for MSMCs Brazilian of software, that

aims at the attendance of the requirements and the satisfaction of the customer in tuning with

the continuous improvement of its processes. The QMS is based on the integration of the

approach of ISO 9001:2000 and ISO/IEC 12207, and involves a set of procedures, that had

been validated in a case study carried through in two small Brazilian companies of software,

whom they had received certification ISO 9001 to leave of this proposal.

KEYWORDS: Software Process Quality – ISO 9001 – Software Quality Assurance.- Quality

Management – ISO/IEC 12207

LISTAS DE ILUSTRAÇÕES LISTA DE FIGURAS Figura 2.1 - Relacionamento entre engenharia de processo, gerenciamento de projeto e engenharia do produto.(ROULLIER, 2001)

13

Figura 2.2 - Camadas da Engenharia de Software – (PRESSMAN, 2001) 19

Figura 2.3 - Relação entre modelos, padrões e normas (QUAGMIRE, 2005) 24

Figura 2.4 - Relacionamento entre os níveis de decisão, atores, ações e visões organizacionais Rezende (2000)

27

Figura 2.5 – Modelos de estrutura Organizacional (baseado em Prado(2000) e Maximiano(2004))

30

Figura 2.6 – Participação das atividades no segmento de serviços de informação – (IBGE, 2002 )

33

Figura 3.1: Mapa de representação da organização (CARVALHO, 2004) 44

Figura 3.2: Processo de Modelagem de Empresas (ROZENFELD, 2005) 45

Figura 3.3: Níveis de Qualidade de software baseada em Unhelkar (2003) 47

Figura 3.4: Qualidade de processo de software mais externa que o processo da Qualidade (UNHELKAR, 2003)

48

Figura 3.5: Modelo de um SGQ baseado em processo (NBR ISO 9001, 2000) 56

Figura 3.6: Visão do Software no sistema (NBR ISO/IEC 15271, 2000) 59

Figura 3.7: Processos de ciclo de vida de software (NBR ISO/IEC 12207, 1998) 60

Figura 3.8: Processos de ciclo de vida de SW - Regras e relacionamentos (NBR ISO/IEC 12207, 1998)

62

Figura 3.9: Efeito de recursividade dos processos da ISO/IEC 12207 (SINGH, 1999) 63

Figura 4.1: Relação do SGQ x Nível de decisão x Macro-processos x seções ISO 9001:2000

75

Figura 4.2: Relação das atividades de implantação do SGQ conforme seções da ISO 9001:2000

77

Figura 4.3: Seqüências e durações relativas das atividades de implantação do SGQ 80

Figura 4.4: Estrutura organizacional (Diretoria e o GSI) 98

Figura 4.5: Manual da Qualidade (Pisandelli, 2005) 101

Figura 4.6: Processo de melhoria e influências para os Padrões Institucionais 102

Figura 4.7: Relacionamento entre as ações, análise crítica e avaliação de eficácia 102

Figura 5.1: Relacionamento dos conceitos envolvendo a ISO 9000 (2000) 108

Figura 5.2: MUSSE com requisitos da ISO 9001:2000 112

Figura 5.3: Auto-treinamento CAFETEIRA para os desenvolvedores 113

Figura 5.4: Ampliação do uso do BugCentral 113

Figura 5.5: Estrutura organizacional da SoftExport 118

Figura 5.6: Marcação de pauta mínima para reuniões de análise crítica 119

Figura 5.7: Estrutura do SGQ na SoftExport 121

Figura 5.8: Manual da Qualidade da SoftExport 122

Figura 5.9: Organograma inicial da SoftSite 125

Figura 5.10: PDS-SS com os requisitos ISO 9001:2000 127

Figura 5.11: Ampliação do uso do DotProject 128

Figura 5.12: Marcação de Pauta Mínima para reuniões de Análise crítica 134

Figura 5.13: Estrutura do SGQ da SoftSite 136

Figura 5.14: Manual da qualidade da SoftSite 137

Figura 5.15: Estrutura organizacional SoftSite com visão de Produto Comercial 138

Figura 5.16: PDP-SS – Adaptado do modelo EUP 139

Figura I.1: Perspectiva Histórica da Qualidade 155

Figura II.1: Participação das MPEs na receita do setor de comércio e serviços – 1985/2001 (IBGE,2003)

159

Figura II.2: Participação da MPE no pessoal ocupado do setor de comércio e serviços – 1985/2001 (IBGE,2003)

159

Figura II.3: Participação dos segmentos nas MPEs de prestação de serviços – 2001 (IBGE,2003)

160

Figura II.4: Número de Empresas no Brasil (percentual) (SEBRAE,2004a) 160

Figura II.5: Números de pessoas ocupadas (percentual) (SEBRAE,2004a) 161

LISTA DE QUADROS Quadro 1.1: Modelo fractal de exposição de idéias 5

Quadro 2.1: Resumo sobre processos a partir das observações de Jamil (2001) 13

Quadro II.1: Características das MPMEs que envolvem a aplicação de disciplinas 162

Quadro II.2: Características das MPMEs que envolvem aspectos administrativos 163

Quadro III.1: Descrição da abordagem dos modelos 166

Quadro III.2: Trillium 167

Quadro III.3: SQPA-HP 168

Quadro III.4: Família ISO 9000 169

Quadro III.5: ISO 9000:2000 170

Quadro III.6: ISO 9001:2000 172

Quadro III.7: ISO 90003:2004 173

Quadro III.8: ISO 9004:2000 x ISO/IEC 90003:2004 x ISO 9004:2000 176

Quadro III.9: ISO/IEC 12207:1995 177

Quadro III.10: ISO/IEC 15504 178

Quadro III.11: ISO/IEC 15288:2002 179

Quadro III.12: TickIT 180

Quadro III.13: BOOTSTRAP 181

Quadro III.14: SW-CMM 182

Quadro III.15: CMMI 184

Quadro III.16: PSP - SEI 185

LISTA DE TABELAS Tabela 1.1: Resumo da distribuição das seções desta Dissertação 6

Tabela 2.1: Informações para os níveis do negócio (adaptado de LIMA(1.28) 15

Tabela 2.2: Relação de Normas ISO sobre diversos tipos de avaliação (ISO, 2005) 17

Tabela 2.3: Resumo de modelos que envolvem processos de capacidade, melhoria, maturidade ou avaliação

20

Tabela 2.4 – Número de empresas de informática e pessoal ocupado segundo porte da empresa (PAS, 2002)

33

Tabela 2.5 – Descrição do mercado de produtos e serviços de software (SOFTEX, 2002)

37

Tabela 2.6 – Distinção entre produtos e serviços de software (SOFTEX, 2002) 37

Tabela 3.1: Procedimentos obrigatórios pela ISO 9001:2000 (NBR ISO 9001, 2000) 57

Tabela 4.1: Descrição da equipe de implantação do SGQ 76

Tabela 4.2: Atividades de implantação do SGQ 77

Tabela 4.3: Informações necessárias para o registros das funções da organização 99

Tabela 4.4: Templates para o SGQ 103

Tabela 4.5: Procedimentos do SGQ e seus respectivos artefatos (templates) 104

Tabela 5.1: Processos e produtos da SoftExport, no início do projeto SGQ 110

Tabela 5.2: Atividades de implantação do SGQ na SoftExport 111

Tabela 5.3: Relação dos procedimentos implantados na SoftExport 115

Tabela 5.4: Papéis e Responsabilidade na SoftExport 116

Tabela 5.5: Matriz passo-a-passo dos processos de Gerência Projetos da SoftExport 123

Tabela 5.6: Novos documentos implantados após a Certificação da SoftExport 123

Tabela 5.7: Processos e produtos inicialmente encontrados na SoftSite 125

Tabela 5.8: Atividades de implantação do SGQ da SoftSite 126

Tabela 5.9: Relação dos procedimentos implantados na SoftSite 129

Tabela 5.10: Papéis e responsabilidades na SoftSite 130

Tabela 5.11: Novos documentos implantados após a certificação da SoftSite 138

Tabela I.1: Características das quatro grandes eras da Qualidade (XEXEO, 2004) 156

Tabela I.2. Amplitudes da Qualidade (MARCINEIRO,2001) 156

Tabela II.1: Critérios de enquadramento do porte de empresas brasileiras 157

Tabela II.2: Porte de empresas no mundo (MDIC,2002) 158

Tabela II.3 - Número de empresas formais no Brasil, por porte e setor de atividade – 2002 (SEBRAE,2004a)

160

Tabela II.4 - Número de pessoas ocupadas nas empresas formais, por porte e setor de atividade – 2002 (SEBRAE,2004a)

161

Tabela II.5 – Causas das dificuldades e razões para o fechamento das empresas (SEBRAE,2004b)

164

Tabela II.6 – Modelo de estruturação organizacional adaptada de Terence (2002) 165

Tabela III.1: Mapeamento ISO 9001:2000(Seções 4,5 e 6 ) , ISO/IEC 12207:1995/Amd1:2002 e CMMI

187

Tabela III.2: Mapeamento ISO 9001:2000(Seção 7 ) , ISO/IEC 12207:1995/Amd1:2002 e CMMI

188


189

LISTA DE ABREVIATURAS E SIGLAS

ADS Ambiente de Desenvolvimento de Software

CMM Capability Maturity Model

CMMI Capability Maturity Model Integration

GSI Grupo de Suporte Institucional

H Altura

KA Knowledge Area (SWEBOK)

KPA Key Process Area (CMM)

LH Linha do Horizonte

LT Linha de Terra

MDS Metodologia de Desenvolvimento de Software

MPE Micro e Pequena Empresa

MPME Micro, Pequena e Média Empresa

ODE Ontology based software Development Envirinment – Ambiente de desenvolvimento baseado em ontologia.

PA Process Area (CMMI)

PF Ponto de Fuga ou Ponto de Convergência

PME Pequena e Média Empresa

PV Ponto de Vista

RUP Rational Unified Process

SEPG Software Engineering Process Group

SGQ Sistema de Gestão da Qualidade

SQA Software Quality Assurance

SWEBOK Software Engineering Body of Knowledge

SUMÁRIO

Capítulo 1 – Introdução 1.1 O Problema 1 1.2 A Motivação 2 1.3 A Proposta do Trabalho 4 1.4 Organização do Trabalho 5 1.5 Considerações 6 Capítulo 2 - O Ambiente 7 2.1 Introdução 7 2.2 O ponto de vista disciplinar 7 2.2.1 Introdução 7 2.2.2 Definindo a Qualidade 8 2.2.3 Disciplinas relacionadas com a qualidade 11 2.2.4 Métricas e padrões 14 2.2.5 Considerações 16 2.3 O ponto de vista fisiológico 17 2.3.1 Introdução 17 2.3.2 A abordagem por processos 18 2.3.3 Modelos que envolvem processos 19 2.3.4 Montagem da perspectiva a partir da escolha de modelos 19 2.3.5 Considerações 24 2.4 O ponto de vista administrativo 25 2.4.1 Introdução 25 2.4.2 Definindo sistema 25 2.4.3 A empresa e o conceito de sistema 26 2.4.4 Delimitando as fronteiras organizacionais 32 2.4.5 Considerações 40 2.5 Considerações 40 Capítulo 3 – Linhas para um modelo 42 3.1 Uma interpretação sistêmica e integrada do ambiente 42 3.2 Um modelo para a garantia da qualidade 46 3.2.1 Introdução 46 3.2.2 Base para análise 47 3.2.3 A estrutura de atuação da qualidade 48 3.2.4 A montagem da estrutura da qualidade 50 3.2.5 Considerações 50 3.3 As linhas de inspiração 50 3.3.1 A realidade do ambiente de aplicação 51 3.3.2 O ponto de avaliação da ISO 9001:2000 51 3.3.2.1 a aplicação da ISO 9001:2000 52 3.3.2.2 Os pontos chaves da aplicação da ISO 9001:2000 54 3.3.2.3 A Estrutura da ISO 9001:2000 55 3.3.2.4 A aplicação da estrutura da ISO 9001:2000 56 3.3.2.5 Considerações 58 3.3.3 As linhas traçadas pela ISO/IEC 12207 59 3.3.3.1 A percepção da ISO/IEC 12207 pela ISO/IEC 15271 59 3.3.3.2 Os Macro-processos da ISO/IEC 12207 60 3.3.3.3 A estrutura da ISO/IEC 12207 61 3.3.3.4 As aplicações da estrutura da ISO/IEC 12207 62 3.3.3.5 Considerações 63 3.3.4 A estrutura, os papéis e as responsabilidades organizacionais 64 3.3.4.1 As realidades organizacionais 64 3.3.4.2 As necessidades organizacionais 64 3.3.4.3 As estruturas organizacionais 65 3.3.4.4 As responsabilidades organizacionais 66 3.3.4.5 Considerações 67 3.3.5 Considerações 68

3.4 A montagem da proposta 68 3.5 Considerações 69 Capítulo 4 - Um modelo para a gestão da qualidade 70 4.1 O ambiente do modelo 70 4.2 O foco no modelo de SGQ 70 4.3 O roteiro para implantação do SGQ 76 4.4 Um modelo para o SGQ 97 4.4.1 O ambiente preparado para receber o SGQ 97 4.4.2 Os pontos fundamentais do SGQ 99 4.4.3 As linhas para atuação do SGQ 1034.4.4 Os procedimentos do SGQ para MPMEs 1044.4.5 Considerações 1044.5 Considerações 105 Capítulo 5 – Considerações 1075.1 Às voltas com o problema 1075.2 A qualidade como foco das atenções 1075.3 As linhas de atuação do SGQ 1085.4 A aplicação do SGQ para MPMEs 1095.4.1 A aplicação do SGQ na SoftExport 1095.4.1.1 O SGQ e a empresa 1095.4.1.2 O foco do SGQ 1095.4.1.3 A aplicação da proposta 1105.4.1.4 O SGQ implantado 1205.4.1.5 Considerações 1225.4.2 Aplicação do SGQ na SoftSite 1245.4.2.1 O SGQ e a empresa 1245.4.2.2 O foco do SGQ 1245.4.2.3 A aplicação da proposta 1265.4.2.4 O SGQ implantado 1365.4.2.5 Considerações 1375.5 Conclusão deste trabalho 1395.5.1 Contribuição da proposta de SGQ 1405.5.2 Trabalhos futuros 141 Referências Bibliográficas 142 Apêndice I – A história da Qualidade 154I.1 O direcionamento do observador 154I.2 Os pontos de convergência 154I.3 As linhas mestras 154I.4 A montagem das perspectivas 154I.5 Considerações 156Apêndice II – As MPMEs 157II.1 O porte das empresas 157II.2 A distribuição do mercado 159II.3 Aspectos comuns à realidade das MPMEs brasileiras 162II.4 Outros aspectos a serem fortemente avaliados 164II.5 Considerações 165Apêndice III – Modelos que envolvem a qualidade 166III.1 Introdução 166III.2 Elementos para análise 166III.3 A apresentação dos modelos 166III.3.1 Oriundos de esforços próprios 167III.3.2 Oriundos de esforços mundiais reunidos 169III.3.3 Oriundos de necessidades e exigências de grandes clientes 180III.4 A montagem da perspectiva 186III.5 Considerações 186Apêndice IV – Manual da Qualidade 190

Apêndice V – Checklist para o levantamento geral da Empresa 191Apêndice VI – Procedimento de descrição do SGQ 192Apêndice VII – Procedimento de controle de documento 199Apêndice VIII – Procedimento de controle de registros do SGQ 205Apêndice IX – Procedimento para Auditoria Interna 210Apêndice X – Procedimento de controle de produto não-conforme 215Apêndice XI – Procedimento para ações corretiva, preventivas e de melhoria 219Apêndice XII - Procedimento de projeto e desenvolvimento de sistema 224

CAPÍTULO 1

INTRODUÇÃO

Como semeadores, agora é tempo de colher aquilo que duramente cultivamos.

1.1 O Problema

No Brasil, ao final do ano 2000, existiam 5.400 empresas ligadas à produção e à

comercialização de software, com um total de 158.000 funcionários. Fazendo-se um cálculo

simples, observa-se que, em média, há aproximadamente 29 funcionários por empresa, isto

constata uma maioria de pequenas e médias empresas nacionais na área de desenvolvimento

de software (PADUAN, 2003). O Ministério da Ciência e Tecnologia (MCT) considera micro

as empresas com até 9 funcionários; pequenas, as empresas com até 49 funcionários; e

médias, as com até 99 funcionários (MCT,2001).

Aliado a estes números, existem as empresas cujo desenvolvimento de software não é

uma atividade fim, isto é, o software gerado é para uso interno. Em ambos os setores

mencionados, micro, pequenas e médias empresas (MPME) e empresas de desenvolvimento

interno (EDI), o cliente deve ter suas necessidades satisfeitas e a confiança de que o produto

recebido esteja em conformidade com os requisitos especificados.

Toda empresa deveria perseguir o desenvolvimento de produtos de software de qualidade,

com procedimentos detalhados e documentados, registros, acompanhamentos, dados históricos

gerados e regidos por uma política institucional, que seja seguida por todos, e que evolua com a

maturidade de seus próprios processos. Para isto, a empresa necessita compor um Sistema de Gestão

da Qualidade (SGQ) que ligue os aspectos operacionais da garantia da qualidade com seus aspectos

gerenciais e estratégicos.

Atualmente, a realidade das empresas de desenvolvimento de software, independentemente

de seu porte, é ter o controle das fases de análise e programação, através do uso de metodologias de

desenvolvimento, alinhadas a ferramentas que, em geral, são usadas para a modelagem de banco de

dados, criação de diagramas e integração com a programação.

Em muitas empresas, a programação poderá até envolver ambientes de desenvolvimento

integrado (IDE), linguagens orientadas a objeto, transações on-line, computação distribuída e outras

tantas tecnologias e tendências. No entanto, observa-se que há uma deficiência no controle dos

2

projetos. Acontece com freqüência o estouro de prazos e custos, uma dissociação entre interesses do

cliente e o produto final. O produto é desenvolvido com as características da equipe do projeto e não

com as características definidas pela empresa. O uso de modelos (ou padrões) é feito de forma ad

hoc, e depende da competência e da habilidade de pessoas que compõem a equipe de projeto. O

desempenho só pode ser previsto através de habilidades individuais, e não por meio da capacidade

da organização.

Cassará (2003) aponta os seguintes elementos que contribuem para o aumento da

produtividade de uma organização:

O compartilhamento de informações, observando que as informações abrangem

também os resultados de todas as atividades e não somente a delegação delas;

O feedback para acompanhamento e possíveis ações corretivas e de melhoria;

O trabalho em equipe, a sinergia dos esforços e conhecimentos auxiliam nas discussões,

decisões, soluções criativas e na maior aceitação das escolhas tomadas em grupo;

A geração do conhecimento organizacional, elementos conhecidos e adotados, padrões

estabelecidos e compartilhados propiciam um ambiente de integração e possível de

melhoria. Uma idéia pode sempre ser melhorada, desde que vista.

As MPMEs enfrentam a mesma realidade de mercado e competição do mundo empresarial.

As rotinas administrativas, as relações com fornecedores, os clientes e colaboradores, as novas

perspectivas tecnológicas e as tendências econômicas e de mercado não podem ser negligenciadas.

Para que uma MPME de software possa sobreviver e seja competitiva é necessário que ela tenha um

direcionamento para melhorar seu processo organizacional e ter a capacidade para gerenciar o

desenvolvimento e a manutenção de seus produtos ou serviços. Seu foco principal deverá ser a

melhoria dos processos de desenvolvimento e manutenção de produtos e sistemas.

1.2 A Motivação

Segundo Campos (1992), os padrões (modelos) referem-se a tudo o que se unifica e

simplifica para o benefício das pessoas, sendo adotado por consenso. O padrão pode ser alterado

para a inclusão de procedimentos, conceitos e também métodos de medida. A criação e adoção de

padrões na organização é a situação ideal, pois a dependência do sucesso dos projetos deixa de estar

vinculado intimamente à equipe, ou a um funcionário em especial. Passa, então, a ser associada ao

conjunto proposto, discutido e validado das práticas gerais, que serão uma base confiável de

melhores técnicas aplicadas na organização. Desta forma, todas as equipes poderão adotar as

3

melhores práticas, terão um plano mestre a ser seguido, saberão que métricas utilizar para analisar

seu desempenho e poder corrigir algum desvio de rumo. Até os erros poderão servir como base de

aprendizagem e nortearão novos planejamentos e o amadurecimento dos processos.

Os padrões facilitam e auxiliam na implementação dos processos presentes no

desenvolvimento de software. Ramos (2003) relata a vantagem da padronização na reengenharia de

sistemas favorecendo o reuso e a manutenção. Os aspectos de melhoria de processos são também

relatados por Lemos et al (2003) quando diz: “A forma de descrição do processo através de padrões

facilita o aprendizado dos engenheiros de software, bem como a aplicação repetitiva de partes

isoladas do processo para prover refinamentos de forma a gerar um produto final com qualidade”.

Os padrões começam freqüentemente como diretrizes que descrevem uma aproximação

preferida e, mais tarde, com a adoção difundida, transformam-se em regulamentos de fato, isto é,

institucionalizam-se (PMBOK, 2004).

"Institucionalização" é um conceito importante na melhoria de processos e implica que o

processo é enraizado na maneira que o trabalho é executado, havendo um compromisso e uma

consistência ao se executar o processo.

Um processo institucionalizado é mais provável de ser seguido durante momentos de estresse.

Quando há mudanças nas exigências e nos objetivos, a execução do processo poderá também mudar

para assegurar que este permaneça eficaz. No CMMI, as práticas genéricas descrevem as atividades

que se dirigem aos aspectos da institucionalização (CHRISSIS, 2003).

No entanto, Tartarelli (2004), conclui: “com a padronização se ganha em produtividade e em

qualidade, mas perde-se em capacidade de inovação por causa da rigidez estrutural e pela perda da

visão sistêmica”. A adoção de modelos deve ser um item relevante no desenvolvimento do

software, mas nunca como solução única e estática. Portanto, uma vez definido um processo

organizacional, esse processo deverá passar por melhorias, quando se fizer necessário.

O processo deve ser conhecido por todos os seus envolvidos, para que possa ser utilizado

adequadamente, levando a organização a ter procedimentos padronizados. O padrão, assim

refletido, tornar-se-ia não o “ponto de partida”, mas a “linha de orientação” para as melhorias do

processo, pois um ponto gera possibilidades em várias direções, mas a linha orienta na direção

buscada.

4

1.3 A Proposta do Trabalho

A reduzida estrutura organizacional da MPME não se coaduna com modelos de maturidade

como o CMMI, que aponta para uma estrutura pesada e densamente povoada por inúmeras funções

e responsabilidades (CHAO LI et al, 2001). Na EDI, em geral, não há o interesse direto por uma

certificação, e sim pelos efeitos da implantação de um Sistema de Gestão da Qualidade (SGQ) na

redução de custos e na qualidade de seus produtos de software.

A abordagem genérica da ISO 9000 (NBR ISO 9000, 2000) da ISO 9001(NBR ISO 9001,

2000) faz com que o sistema de gestão da qualidade proposto, seja aplicado em qualquer

organização possuidora de processos, que recebam insumos como entrada, tendo como resultado

produtos intermediários ou finais. Essa abordagem, no entanto, é muito genérica para aplicação em

pequenas e médias empresas de desenvolvimento de software, em que grande parte dos

componentes da organização, pessoas, processos e atividades, estão diretamente ligados à rotina de

produção de software.

Quando a organização tem um histórico de produtos e clientes, os processos e metodologias

de desenvolvimento de alguma forma já existem e são aplicadas. As pessoas que participam da

empresa, a diretoria, os desenvolvedores, os analistas de sistemas, analistas de teste, os gerentes de

projeto, os designers e o suporte convivem diariamente com as rotinas do desenvolvimento. A

grande dificuldade está no entendimento da visão organizacional por esse grupo. As rotinas

administrativas e financeiras devem ser atendidas também neste contexto.

A abordagem da ISO/IEC 12207 (1995) e sua descrição do ciclo de vida do software

aproximam o ambiente da organização e suas atividades diárias de desenvolvimento de

software com os conceitos de sistemas, processos, atividades e tarefas de uma maneira clara

para todos na organização. Esta norma é aplicada ao processo de desenvolvimento de

software, e pode ser adaptada à ISO 9001, que é genérica para processo em geral.

A proposta deste trabalho é montar uma estrutura que tenha a visão de todos os

processos da organização, e que não seja grande e inviável para uma aplicação imediata, mas

que ao mesmo tempo possa ser continuamente enriquecida e crescer com a maturidade dos

processos e da própria organização, adotando a estrutura da ISO 9001 para a estruturação do

Sistema de Gestão da Qualidade (SGQ) dos processos organizacionais e para a criação e ou

organização da cultura da qualidade nas MPMEs e adaptando-a à estrutura descrita na

ISO/IEC 12207.

5

1.4 Organização do Trabalho

A observação do processo de desenho de uma perspectiva (MONTENEGRO, 1987) foi

fonte de inspiração na montagem do processo de escrever esta dissertação. Havia pontos de

vista a serem discutidos, processos a serem definidos e muitas fontes de referência a serem

analisadas. No entanto, faltava um elemento que norteasse o problema e uma provável

solução. A definição de sistema e de seus componentes realçou a idéia de recursividade que,

por sua vez, trouxe à tona a idéia dos fractais e inspirou o modelo resumido no quadro 1.1.

Quadro 1.1: Modelo fractal de exposição de idéias

MODELO FRACTAL

O direcionamento do observador: Sempre ao iniciar uma abordagem, o observador vai ser orientado para a percepção do ambiente que está prestes a ser descrito.

Os pontos de convergência: Durante a montagem da perspectiva, os pontos de convergência, ou de fuga, orientam a direção a ser seguida. Comportam-se como um objetivo a ser atingido e que orienta todas as ações a serem executadas.

As linhas mestras: As linha mestras são traçadas para auxiliar na montagem da perspectiva, e estão fortemente ligadas aos pontos de convergência. Elas não fazem parte perspectiva montada, mas influenciam diretamente no resultado final.

A montagem da perspectiva: A partir do posicionamento do observador, da determinação dos pontos de fuga e a definição das linhas mestras, a perspectiva começa a ser traçada em seu quadro de representação e será o resultado da integração e da mútua dependência de todos os componentes.

A perspectiva montada: A conclusão da abordagem, a perspetiva finalizada, é a interpretação da estrutura posicionada no quadro de montagem. Deve haver, pelo observador, o reconhecimento da realidade retratada; caso contrário, deve haver ajustes em seu posicionamento, nos pontos de convergência, nas linhas mestras ou no próprio quadro de montagem. As considerações presentes têm de sintetizar e representar a perspectiva final.

O trabalho se desenvolve no decorrer de cinco capítulos e em uma série de apêndices,

gerados a partir da experiência de certificação ISO 9001 em duas empresas.

O Capítulo 1, Introdução, identifica o problema e como enfrentá-lo, permitindo um

novo ciclo de abordagem no capítulo seguinte. Procura orientar o leitor.

O Capítulo 2, O ambiente, observa a organização por três aspectos distintos, mas

integrados; identifica pontos de referência para as argumentações.

O Capítulo 3, Linha para um modelo, apresenta vários modelos com abordagens

distintas da qualidade; esses modelos são discutidos e analisados para a elaboração do SGQ,

que são as linhas mestras do modelo. O Apêndice III oferece mais detalhes do levantamento

desses modelos.

O Capítulo 4, Um modelo para a gestão da qualidade em MPMEs, apresenta a

montagem da proposta do SGQ para MPMEs, descrevendo os passos para a sua implantação.

Ele configura a montagem da perspectiva.

6

O Capítulo 5, Considerações, apresenta as conclusões deste trabalho e define novas

perspectivas de continuidade do processo do SGQ.

1.5 Considerações

A distribuição de informações de todos os capítulos deste trabalho segue a orientação do

modelo apresentado no Quadro 1.1 e se encontra resumido na tabela 1.1. Tabela 1.1: Resumo da distribuição das seções desta Dissertação

Direcionamento do

Observador Os Pontos de Convergência

As Linhas Mestras Montagem da Perspectiva

Consideração

DISSERTAÇÃO 1 Introdução 2 O Ambiente 3 Linhas para um

Modelo 4 Um Modelo para a Gestão da Qualidade em MPMEs

5 Considerações

1 Introdução 1.1 O Problema 1.2 A Motivação 1.3 A Proposta do Trabalho

1.4 Organização do Trabalho

1.5 Considerações

2 O Ambiente 2.1 Introdução 2.2 O Ponto de vista Disciplinar

2.3 O Ponto de vista Fisiológico

2.4 O Ponto de vista Administrativo

2.5 Considerações

2.1 Introdução 2.1.1Direcionamento do Observador

2.1.2 O ponto de Convergência

2.1.3 As linhas Mestras

2.1.4 Montagem da Perspectiva

2.1.5 Considerações

2.2 O Ponto de Vista Disciplinar

2.2.1 Introdução 2.2.2 Definindo qualidade

2.2.3 Disciplinas Relacionadas com a Qualidade

2.2.4 Métricas e Padrões


2.3 O Ponto de Vista Fisiológico

2.3.1 Introdução 2.3.2 A Abordagem por Processos

2.3.3 Modelos que Envolvem Processos

2.3.4 Montagem da Perspectiva a partir da Escolha de Modelos


2.4 O Ponto de Vista Administrativo

2.4.1 Introdução 2.4.2 Definindo Sistema

2.4.3 A Empresa e o Conceito de Sistema

2.4.4 Delimitando as Fronteiras Organizacionais


3 Linhas para um Modelo

3.1 Uma Interpretação Sistêmica e Integrada do Ambiente

3.2 Um Modelo para a Garantia da Qualidade

3.3 As Linhas de Inspiração

3.4 A Montagem da Proposta

3.5 Considerações

3.2 Um modelo para a Garantia da Qualidade

3.2.1 Introdução 3.2.2 Base para Análise

3.2.3 A Estrutura de Atuação da Qualidade

3.2.4 A Montagem da Estrutura da Qualidade



3.3.1 A Realidade do Ambiente de Aplicação

3.3.2 O Ponto de Atuação da ISO 9001:2000

3.3.3 As Linhas traçadas pela ISO/IEC 12207

3.3.4 A Estrutura, os Papéis e as Responsabilidades Organizacionais


4 Um modelo para a Gestão da qualidade em MPMEs

4.1 O Ambiente do Modelo

4.2 O Foco do Modelo SGQ

4.3 O Roteiro para Implantação

4.4 Um Modelo do SGQ

4.5 Considerações

4.4 O modelo do SGQ

4.4.1 O Ambiente preparado para receber o SGQ

4.4.2 Os Pontos Fundamentais do SGQ

4.4.3 As Linhas para Atuação do SGQ

4.4.4 Os procedimentos do SGQ para MPMEs


5 Considerações 5.1 Às voltas com o problema

5.2 A qualidade como foco das atenções

5.3 As linhas de atuação do SGQ

5.4 A aplicação do SGQ para MPMEs

5.5 Conclusão deste trabalho

7

CAPÍTULO 2

O AMBIENTE

“Ambiente é tudo aquilo que envolve externamente uma organização.” Idalberto Chiavenato

2.1 Introdução

A complexidade do ambiente de desenvolvimento de software não é uma

exclusividade desse setor produtivo. Todas as organizações deparam-se com as

exigências de controle dos custos e da qualidade de seus produtos, de divulgação, de

conquista e fidelização de clientes, de domínio de novas técnicas e tecnologias, de

competição acirrada e de sobrevivência.

Chiavenato (1999) ao relatar, à luz da administração, que “ambiente é tudo aquilo

que envolve externamente uma organização”, mostra-o “muito amplo, vasto, difuso,

complexo” e que “não é possível apreendê-lo e compreendê-lo em sua totalidade”.

Assim, aconselha a sua segmentação a fim de melhor abordá-lo, sugerindo, então, dois

grandes ambientes: o macroambiente (geral), que envolve todas as organizações, e o

microambiente (específico), que constitui o foco onde cada organização atua

propriamente, englobando “seus clientes, fornecedores, concorrentes e agências

reguladoras”.

Torna-se evidente a necessidade do entendimento, da definição e da aplicação de

certos aspectos relacionados ao microambiente organizacional. Esses aspectos envolvem

diferentes modos de observar a organização – pontos de vista – os quais se inter-

relacionam de forma intrínseca, e que aqui foram classificados como: (i) ponto de vista

disciplinar, focando conceitos e disciplinas; (i) ponto de vista fisiológico, tratando de

modelos, estruturas e propostas para adequação ou padronização de seus processos; e

(iii) ponto de vista administrativo, envolvendo aspectos e práticas organizacionais.

2.2 O Ponto de Vista Disciplinar

2.2.1 Introdução

Muitos conceitos estão presentes no ambiente de desenvolvimento de produtos:

vários são inter-disciplinares; alguns podem ser adaptados, dependendo do ponto de

8

vista usado para sua análise; e, em outros, têm-se a nítida impressão que eles próprios se

confundem com seus objetivos. A seguir, são apresentadas algumas abordagens

importantes para o enquadramento desses conceitos.

2.2.2 Definindo a Qualidade

Produzir algo de qualidade exige primeiramente a compreensão do que é qualidade. O

conceito apresentado pela FPNQ – Fundação para o Prêmio Nacional da Qualidade

(CRITÉRIOS DE EXCELÊNCIA, 2004), adaptado da NBR ISO 8402 (1997), diz:

“Qualidade é a totalidade de características de uma entidade (atividade ou processo, produto,

organização, ou uma combinação destes), que lhe confere a capacidade de satisfazer as

necessidades explícitas e implícitas dos clientes e demais partes interessadas”. Neste contexto,

partes interessadas significa “indivíduo ou grupo de indivíduos com interesses comuns no

desempenho da organização e no ambiente em que opera. A maioria das organizações

apresenta as seguintes partes interessadas: (i) clientes; (ii) força de trabalho; (iii) acionistas e

proprietários; (iv) fornecedores; e (v) sociedade. A quantidade e a denominação das partes

interessadas podem variar em função do perfil da organização”.

Garvin (1984) aborda a qualidade baseado na visão de quatro grandes disciplinas: a

filosofia, a economia, o marketing, e a gerência de operações, cada uma delas com uma visão

diferenciada, mas complementar. Ele descreve cinco perspectivas para a definição de

qualidade:

• Visão transcendental: qualidade é algo que se reconhece, mas não se define;

• Visão do produto: qualidade é vista como uma variável precisa e mensurável; as

diferenças na qualidade refletem diferenças na quantidade de algum componente ou

atributo possuído por um produto;

• Visão do usuário: qualidade é atingir os objetivos;

• Visão da Manufatura: qualidade está relacionada às características do produto;

• Visão com base no valor: qualidade depende do valor que o cliente está disposto a

pagar.

Garvin (1984) identifica os seguintes parâmetros (dimensões) da qualidade:

• Qualidade de características funcionais intrínsecas ao produto: (i) desempenho

técnico ou funcional; e(ii) facilidade ou conveniência de uso.

9

• Qualidade de características funcionais temporais: (i) disponibilidade; (ii)

confiabilidade; (iii) manutenibilidade; e (iv) durabilidade.

• Qualidade de conformação

• Qualidade de serviços associados ao produto: (i) instalação e orientações de uso; e

(ii) assistência técnica.

• Qualidade da interface do produto com o meio: (i) interface com o usuário; e (ii)

interface com o meio ambiente (impacto no ambiente).

• Qualidade de características subjetivas associadas ao produto: (i) estética; (ii)

qualidade percebida e imagem da marca.

• Custo do ciclo de vida do produto para o usuário.

Belchior (1997) afirmou que “não se pode pensar em qualidade como sinônimo de

perfeição. Trata-se de algo factível, relativo, substancialmente dinâmico e evolutivo,

amoldando-se à granularidade dos objetivos a serem atingidos. Considerá-la como algo

absoluto e definitivo seria transportar-se para o inatingível e, com base neste sofisma,

propiciar entraves a qualquer esforço de produzi-la”. Portanto a qualidade vai depender

sempre da perspectiva do observador e de suas motivações e jamais se pode pensar em

qualidade como sinônimo de perfeição e sim uma direção que vai ajustando-se aos aspectos,

focos e momentos dos objetivos a serem atingidos.

Segundo Chiavenato (1999), existem dois conceitos de qualidade: (i) a qualidade

interna, que constitui a maneira pela qual uma organização administra a qualidade de

seus processos, produtos e serviços; e (ii) a qualidade externa, que é a percepção que o

cliente tem a respeito do produto ou serviço que compra ou utiliza. Para construir e

manter a imagem da qualidade externa, a qualidade interna é fundamental.

Pode-se observar que o conceito de qualidade é aplicado em inúmeras disciplinas e

que é um conceito dinâmico e dependente da análise do julgamento. O amadurecimento

do conceito de qualidade, mormente na área da produção industrial, evoluiu através de

muitos pesquisadores, como:

• Taylor: 1911 – Princípios da gerência científica;

• Fayol: 1916 – Teoria científica da administração;

• Juran: 1920 – Teoria da gerência da qualidade, controle e ciclo de melhoria;

10

• Shewhart: 1931 – Controle estatístico da qualidade ou controle estatístico de

processos;

• Demming: 1950 – Qualidade total;

• Ishikawa: 1950 – Diagrama de causa e efeito;

• Maslow: 1951 – Psicologia humanística e o auto-estudo;

• Crosby: 1952 – Conceito de zero defeitos.

Belchior (1997), relacionando qualidade e software também disse:

Quando se deseja um produto de software de alta qualidade, deve-se assegurar

que cada uma de suas partes constituintes possua alta qualidade (HUMPHREY, 1995).

Portanto, os resultados intermediários, no processo de produção, devem ser

imediatamente examinados após sua conclusão, procurando garantir que erros e

inadequações no produto sejam detectados o mais cedo possível, pois a qualidade final

do produto é uma função de todas as fases anteriores de seu ciclo de desenvolvimento.

(...) Qualidade, portanto, não significa somente excelência ou um outro atributo de um

certo produto final. A qualidade dever ser perseguida dentro da organização, pois,

certamente, é isto o que os usuários esperam de um produto.

Laudon (2001) afirma: “As soluções para os problemas de qualidade de software

incluem uma metodologia apropriada de desenvolvimento de sistemas, alocação de

recursos apropriados durante o desenvolvimento dos sistemas, o uso de medidas, atenção

à testagem, e o uso de ferramentas”. Menciona, também, a necessidade de ferramentas

para a gerência de projetos, a produção, o reuso e debugging de código e a geração de

testes.

Basili (1994), ao discutir a qualidade de software no contexto do TQM (Total

Quality Management, abordagem aplicada no Japão em 1950, formalmente nomeada

TQM somente em 1985), ressaltou que a qualidade é um conceito multidimensional,

fazendo a ligação entre a qualidade e a satisfação do cliente e seus elementos chaves.

Assim, os elementos do TQM são: (i) foco no cliente; (ii) melhoria de processo; (iii)

lado humano da qualidade; e (iv) dados, medidas, e análise. Nas dimensões da

qualidade, podem ser incluídas: (i) a entidade de interesse; (ii) o ponto de vista sobre

essa entidade de interesse; e (iii) atributos de qualidade dessa entidade.

A estreita relação dos conceitos acima de qualidade com o TQM levou Basili

(1994) declarar:

11

• Para melhorar a qualidade durante o desenvolvimento, precisamos de modelos

de processos de desenvolvimento;

• Para conseguir qualidade, todos os elementos do TQM precisam ser

observados;

• Quando os requisitos do cliente são verificados, o desafio é para refleti-los nos

processos de desenvolvimento dos produtos;

• As revisões e as inspeções de software são diferentes das inspeções industriais;

• No desenvolvimento do software, o reuso não deve ser limitado ao código;

• O que é medido é melhorado.

E ele concluiu:

O processo, o produto, os modelos e outras formas de experiência estruturada foram

definidos, usados, ou acumulados, e continuarão a ajudar na prática da engenharia de

software. (...) Entretanto, os desafios significativos permanecem. A transferência das

tecnologias de software para o desenvolvimento organizacional e a construção de uma

ponte sobre a lacuna entre o estado da arte e estado da prática necessitam dos esforços

dos pesquisadores e praticantes interessados.

A busca de qualidade e produtividade no desenvolvimento tem sido intensa.

Atualmente, tem-se evidenciado que a qualidade do produto depende, fortemente, da

qualidade e adequação de seu processo de desenvolvimento. Para dar suporte a isto, há

várias disciplinas que apóiam a qualidade, como é o caso da engenharia de software.

2.2.3 Disciplinas Relacionadas com a Qualidade

Segundo Futrell (2001), a engenharia de software é uma abordagem sistemática e

disciplinada para o desenvolvimento, a operação, a manutenção e a descontinuação de

software, através da aplicação prática de conhecimento e processos científicos.

Para Paula Filho (2001), a engenharia de software é uma arte, pois é idéia que se

materializa através das faculdades humanas, procurando gerar valor através: dos

recursos de processamento de informação, dos conhecimentos científicos e empíricos

(muitas práticas são adotadas porque funcionam, mesmo quando carecem de

fundamentação teórica satisfatória), de disciplinas específicas, de abstrações estruturais

e arquiteturais, transformadas em forma adequadas de uso (programas de computador), e

através de processos e ações sistemáticas. Assim, a engenharia de software usa

12

resultados da ciência e fornece problemas para estudo, fornecendo uma perfeita idéia de

retroalimentação.

Jamil (2001) diz:

Num paradoxo sem precedentes, os produtores de software passaram apenas em tempo

recentes a serem vistos e considerados uma “indústria”. A “Engenharia de Software”,

com suas teses, técnicas, modelos e estruturas de trabalho, passou a ser relevada nas

empresas usuárias, nos produtores e distribuidores com maior ênfase e como tópico a ser

desenvolvido nas escolas, entre os futuros projetistas de software. (...) Com a evolução

dos negócios e o crescimento da demanda por sistemas customizados e eficientes,

entregues em seu tempo certo, iniciou-se uma demanda por técnicas e modelos de gestão

mais eficazes, que permitissem a montagem de linhas produtivas de software, no sentido

de atender aos clientes com produtos com características semelhantes aos de quaisquer

outros, já “industrializados”.

Esta Visão de produto fica ainda mais clara com as seguintes características da

engenharia de software apontadas também por Jamil (2001):

Permitir o acompanhamento da satisfação dos usuários.

Controlar o desenvolvimento, o acompanhamento de custos e a montagem de

estruturas de evolução do projeto.

Criar mecanismos de ambiente de projeto, que forneçam condições para o

aprimoramento sucessivo do trabalho de desenvolvimento.

Dar condições de informação e treinamento de pessoal com os objetivos de

cada processo.

Gerenciar, interagir e comunicar com equipes de forma eficaz.

Estabelecer condições mercadológicas competitivas: preço, fornecimento e

distribuição, suporte e assistência técnica.

Desta forma, Jamil (2001) ainda revela:

Finalmente, nos deparamos com o fato de que o software é um produto

industrial, que seu projeto e fornecimento são peças de “Engenharia”, ou seja, de um

conjunto de disciplinas e métodos que visam possibilitar seu desenvolvimento eficiente

e em série, mesmo que tenha as particularidades inerentes de qualquer produto da era do

conhecimento. Assim sendo, caímos em um novo conceito – o de processo produtivo de

software. Este processo definiria, em termos elevados, como seriam montados os

13

projetos de software e como o produto, elaborado segundo este projeto, se encaixaria por

vez num sistema amplo, que é o universo da Aplicação do cliente.

Abaixo O Quadro 2.1 resume as observações de Jamil (2001)

Quadro 2.1 – Resumo sobre processos a partir das observações de Jamil (2001)

Roullier (2001) mostrou o relacionamento entre a engenharia do produto, a engenharia

de processo e o gerenciamento de projeto, conforme a Figura 2.1.

Figura 2.1 – Relacionamento entre engenharia de processo, gerenciamento de projeto e engenharia do produto (ROULLIER, 2001)

A engenharia do produto seria a encarregada do desenvolvimento e da manutenção dos

produtos e serviços de software através da metodologia de desenvolvimento (com uma

linguagem de representação, um modelo de ciclo de vida e um conjunto de técnicas).

O gerenciamento de projeto coordena e monitora o projeto, assegurando que processos

vinculados às atividades da engenharia do produto sejam seguidos.

14

A engenharia de processo, de uma forma mais abrangente, tem como função primordial

a definição e a manutenção dos processos da organização. O levantamento e a modelagem de

processos podem dar subsídios à construção, revisão ou melhoria de processos, buscando,

sempre, maior eficiência e eficácia, apoiando, por exemplo, processos de qualificação para a

certificação da qualidade, a seleção de tecnologia e a construção de sistemas de gestão

baseados em indicadores de desempenho (CAMEIRA, 2000).

A grande meta da engenharia de software é produzir sistemas, aplicações ou produtos de

alta qualidade (PRESSMAN, 2001). Levando em conta que a própria definição de qualidade é

ainda subjetiva, o processo de mensurar também se torna subjetivo.

2.2.4 Métricas e Padrões

Oliveira (2002) relatou: “a utilização de métricas e processos de medição tem como

principal objetivo a obtenção de meios para avaliar determinadas características de produtos e

processos de software, como também facilitar a identificação das necessidades de melhoria.”

E colheu as citações: “Não se pode controlar o que não se pode medir” (DeMARCO, 1989);

“um elemento chave em qualquer processo de engenharia é a medição” (PRESSMAN, 2001);

“você não pode prever nem controlar o que não pode medir” (FENTON E PFLEEGER,

1997).

Pressman (2001) cita Michael Math: “nós gerenciamos coisas ‘por números’ em muitos

aspectos de nossa vida (...); esses números nos dão discernimento e ajudam dirigindo nossas

ações”.

Também do conhecimento popular tem-se: “Quando se pode medir o que se está

falando, e expressá-lo em números, sabe-se algo sobre ele. Mas, quando não se pode medi-lo,

quando não se pode expressá-lo em números, seu conhecimento é escasso e insatisfatório”.

Travassos (2002) disse que “o objetivo principal da medição na engenharia de software

é aumentar a compreensão do processo e do produto, controlá-los definindo antecipadamente

as atividades corretivas, e identificar as possíveis áreas de melhoria” e relatou:

O estado de arte atual a respeito de empacotamento de experimentos indica a ausência de

normas internacionais aprovadas. De um lado, isso estimula a evolução dessa parte da

engenharia de software experimental fornecendo boas oportunidades e atraindo a atenção dos

pesquisadores. Por outro lado, o grande número de caminhos possíveis da evolução se

transforma numa certa anarquia trazendo a discordância sobre a interpretação dos conceitos

15

relevantes ao empacotamento, o conteúdo ótimo do pacote, e os meios da apresentação do

pacote.

Apesar de o autor estar falando especificamente de uma das importantes características

da experimentação, a necessidade da repetição, e a sua forma ideal de registro e

formalização, o empacotamento, a sua observação sobre a falta de um modelo pode ser

aplicada a várias outras disciplinas, enfatizando a necessidade de uma estrutura fundamental e

comum, que norteie e aponte caminhos possíveis.

Em Lima (2002) tem-se: “A medição é uma avaliação quantitativa de qualquer aspecto

do processo de engenharia de software, produto ou contexto. A medição serve para entender

ou ajudar no controle, na previsão e na melhoria do que produzir e como produzir” e, para a

elaboração de um Plano de medição, sugere métricas e seu relacionamento com o projeto e

aponta que “outro fator importante é a consciência de que as medições devem estar

intimamente relacionadas com os objetivos do negócio”. A Tabela 2.1 fornece algumas

informações referentes aos níveis de decisão envolvidos no negócio.

Tabela 2.1 – Informações para os níveis do negócio (adaptado de Lima(2002))

Níveis de análise Informações a serem coletadas

Organização Retorno do investimento, comparações, desempenhos.

Processo Custo das atividades, benchmarks, processos de controle estatístico.

Projeto Cronograma, custo dos recursos, crescimento, estabilidade.

Produto Confiabilidade, gerência de defeitos, manutenibilidade.

A medição se torna mais eficaz se for aplicada para coletar medidas em um processo já

estabelecido e padronizado – daí a grande importância dos padrões.

Parafraseando Carvalho (1981) em sua justificativa para adoção da avaliação baseada

em padrões “como critério para avaliação, os padrões servem como base para a análise e

comparação de um caso em particular com outros de mesma natureza e considerados como

executores de serviços de alta qualidade (...), sua aplicação pode ser verificada em qualquer

tipo de tarefa que requeira certo grau de uniformidade, tanto para o material empregado como

para a própria atividade desenvolvida”.

A justificativa acima foi baseada nos seguintes critérios para avaliação de serviços

bibliotecários: (i) avaliação baseada na opinião do usuário; (ii) avaliação baseada na

opinião de especialistas; (iii) avaliação baseada na comparação com outras instituições;

(iv) avaliação baseada em produtos quantificáveis; (v) avaliação baseada em processos

16

quantificáveis; (vi) avaliação baseada em custos em combinação, que produzam relações

de custo-benefício e custo-efetividade; (vii) avaliação baseada em padrões ideais.

A ISO (2005) diz como os padrões beneficiam a sociedade:

Para negócios, a adoção difundida de padrões internacionais significa que os fornecedores

podem basear o desenvolvimento de seus produtos e serviços nas especificações que têm

larga aceitação em seus setores. Isto, por sua vez, significa que os negócios que usam

padrões internacionais devem cada vez mais competir em muitos mais mercados em torno

do mundo.

Cameira (2000) em sua visão para adoção da engenharia de processos, revela-nos:

Uma questão mais operacional, mas importante, reporta-se ao fato que se deve definir

padrões ou práticas comuns à modelagem, claramente dirimindo as questões específicas ou

polêmicas inerentes à um determinado modelo, de forma que todas as pessoas ou toda a

equipe atuante no projeto tenham uma forma assemelhada de trabalhar e de descrever

processos. Isto é fundamental, pois não existem dois modeladores e dois entrevistados

idênticos na forma de pensar. Padrões e clara definição de questões específicas à

modelagem têm reflexos diretos na legibilidade, percepção da qualidade, e

homogeneidade.

Citando Chiavenato (1999):

O primeiro passo do processo de controle é estabelecer previamente os objetivos ou

padrões que se deseja alcançar ou manter. (...) Os objetivos servem de ponto de referência

para o desempenho ou resultados de uma organização, unidade organizacional ou atividade

individual. O padrão é um nível de atividade estabelecido para servir como um modelo

para a avaliação do desempenho organizacional.

Portanto, faz-se necessária a identificação de padrões que possam vir a ser

adotados para planejar, registrar, seguir, medir, avaliar, validar, acompanhar, gerenciar,

adaptar e readaptar o processo de software, tendo com fim último a própria qualidade de

software.


Conceitualmente, o software tratado como resultado da produção vai ser construído,

avaliado, melhorado e descontinuado. A elaboração, ou construção, envolve modelos,

processos e metodologias. Seu processo de avaliação pode ser dividido em duas grandes

abordagens: a avaliação dos produtos de software gerados, e a avaliação dos processos

envolvidos nesta produção.

17

Com base nas abordagens de Jamil (2001) e Roullier (2001), identificam-se o produto, a

engenharia do produto, o gerenciamento do projeto, e a gerência do processo. Na visão do

software com a perspectiva de produto e na visão do gerenciamento do projeto, têm-se

algumas importantes normas ISO como as relacionadas na Tabela 2.2. No entanto, a ênfase na

gerência do processo e na engenharia do produto vai continuar direcionando a nossa busca por

um modelo da qualidade para o processo produtivo (de software).

Tabela 2.2: Normas ISO sobre diversos tipos de avaliação (ISO, 2005)

2.3 O Ponto de Vista Fisiológico

2.3.1 Introdução

Sob o ponto de vista fisiológico, a organização é observada a partir de suas

atividades, processos e funções, descrevendo algumas formas possíveis das relações entre

a estrutura conceitual e o ambiente. O ponto de vista fisiológico examina atentamente a

abordagem dos processos que procuram garantir a qualidade do software. Entretanto,

neste momento do trabalho, o ambiente de aplicação é a organização em sua totalidade

sem nenhuma ação restritiva ou de adequação. A montagem de um modelo aplicável já

começa da identificação e da determinação das necessidades, dos conceitos e recursos

18

envolvidos, e no ambiente de aplicação e desenvolvimento, que são pertinentes à estrutura

organizacional.

2.3.2 A Abordagem por Processos

Para a adoção de uma abordagem por processos é preciso que haja a compreensão e o

gerenciamento da organização por meio de processos, visando à melhoria do desempenho e a

agregação de valor para as partes interessadas. Entretanto, para agregar valor ao produto, é

fundamental conhecer o cliente de cada processo e suas necessidades. A satisfação do cliente

é alcançada pela tradução de suas necessidades em requisitos para os produtos e seu

desdobramento para cada processo na cadeia de valor.

A identificação e a análise de processos levam ao melhor entendimento de como

funciona a organização. Assim, esses processos permitem a definição adequada de

responsabilidades, o uso eficiente dos recursos, a prevenção e a solução de problemas e a

eliminação de atividades redundantes. Quando o domínio dos processos é pleno, há

previsibilidade dos resultados, o que serve de base para implementar inovações e melhorias

(CRITÉRIOS DE EXCELÊNCIA, 2004).

A observação da complexidade envolvendo características da equipe de colaboradores,

nível de conhecimento da organização em engenharia de software, as atribuições de cada

função e a própria definição dessas funções, é o ponto determinante para a adoção de padrões

de processos e de todo um conjunto de ativos de processo (process assets) de software.

Porém, é necessário se ter um bom nível de maturidade para a definição e experimentação de

tais padrões.

Neste contexto, Bertollo (2003) define processos de software em ODE (Ontology

based software Development Environment): “a premissa do projeto de ODE é a seguinte: se as

ferramentas de um Ambiente de Desenvolvimento de Software (ADS) são construídas

baseadas em ontologias, a integração dessas ferramentas pode ser facilitada, pois os conceitos

envolvidos estão bem definidos na ontologia. Especialmente em ADS, ontologias reduzem

confusões terminológicas e conceituais, facilitando o entendimento compartilhado e a

comunicação entre pessoas com diferentes necessidades e pontos de vistas.”

Mesmo se tratando de processos, produtos e responsabilidades é a qualidade a camada

básica e o foco que orienta todas as outras abordagens. A Figura 2.2 representa esta orientação

(PRESSMAN, 2001).

19

Figura 2.2 – Camadas da Engenharia de Software (PRESSMAN, 2001)

2.3.3 Modelos que Envolvem Processos

A identificação da produção de software como um processo de produção industrial e

em conformidade com processos amadurecidos faz imperiosa a busca pela adoção e pelo

aprimoramento do processo produtivo.

Neste ínterim, são apresentados alguns importantes modelos que atendem ao

aprimoramento de ambos, produtos e produtores de software, através de uma abordagem por

processos. O Apêndice III deste trabalho faz um levantamento mais abrangente e envolve o

inter-relacionamento de conceitos, formas e resultados, que caracterizam cada modelo

apresentado. A Tabela 2.3 mostra um resumo deste levantamento.

2.3.4 A Montagem da Perspectiva a partir da Escolha de Modelos

Para se definir uma metodologia é necessário interagirem pessoas, papéis, perfis,

equipes, ferramentas, técnicas, processos, atividades, marcos, produtos de trabalho, padrões e

medidas para a qualidade. No entanto, também é necessário o entendimento das fronteiras, ou

dos limites dessa metodologia. A organização terá pequenos benefícios na aplicação de

processos de software se não esses não forem adaptados às suas necessidades e ao seu

ambiente de negócios (COCKBURN, 2000; RUSS, 2000; JOHNSON, 2000).

Este trabalho faz um levantamento nas maneiras de atuação de vários modelos, que

envolvem processos de capacidade, melhoria, maturidade ou avaliação. O SWEBOK (2004)

realiza um mapeamento entre as norma ISO 9001:2000, ISO/IEC 90003:2004, ISO/IEC

12207, ISO/IEC 15504, o CMMI, o TickIT, entre outros modelos. Há vários trabalhos

mapeando ou unindo modelos entre si: (i) ISO 9001:1994 e CMM (QING WUAG, 2000;

PITTERMAN, 2000; PAULK, 1994; CHAO LI, 2001; DAHUA JU, 2001); (ii) ISO

20

9001:2000 e CMMI (MUTAFELIJA, 2003); (iii) ISO 9001:1994 e ISO/IEC 12207:1995

(SINGH, 1999; AZEVEDO, 2004). Esses mapeamentos e uniões são fortes indícios da

complementariedade entre si dos modelos de melhoria e avaliação da qualidade, cabendo à

organização procurar seguir a orientação que mais se adequar à sua realidade e necessidades.

Tabela 2.3 – Resumo de modelos que envolvem processos de capacidade, melhoria, maturidade ou avaliação

21

Tendo-se a Tabela 2.3 como referência, os modelos SQPA e Trillium foram iniciativas

próprias de empresas para atender suas necessidades de estruturação e melhoria de processos,

mas que atualmente estão descontinuadas. Um das lições dessas iniciativas que se pode tirar é

que, em um dado momento de suas atividades, a organização buscou a qualidade de seus

processos, e pode criar e adaptar processos de acordo com suas características.

A evolução de conceitos e práticas globais faz com que seja necessária a avaliação

contínua dos processos, mesmo que estejam ou parecem estar sob controle, por um modelo

aceito e reconhecido globalmente como de excelência e referência. Essa evolução também fez

com que o Bootstrap e o CMM fossem descontinuados e, de certa forma, absorvidos por

outros modelos que adotaram algumas de suas características, como a ISO/IEC 15504 e o

CMMI.

O modelo abordado pela ISO/IEC 15504, por sua vez, já com atualizações desde sua

apresentação no projeto SPICE, é uma norma integradora e bastante flexível e que descreve

um conjunto de processos, considerados universais e fundamentais para a boa prática da

engenharia de software, que avalia a capacidade dos processos de uma organização e guia

para a melhoria desses processos de software (ANACLETO, 2003; SILVA,2003).

No entanto, Anacleto (2003) referindo-se ainda à ISO/IEC 15504 diz que “sua

aplicação prática ainda requer um esforço, tempo e experiência consideráveis, o que complica

sua aplicação em MPEs” (médias e pequenas empresas). Silva (2003), em relato de aplicação

em pequena empresa, diz que “foi necessário identificar os elementos essenciais da

abordagem e utilizá-los de forma eficiente e eficaz, compatíveis com as características de

agilidade das pequenas empresas de software’, e que “a experiência do CenPRA (Centro de

Pesquisa Renato Archer), que já realizou trabalhos em outras empresas, mostra que esta

adaptação é viável e necessária”. De qualquer forma, embora possível, esta norma não terá

aplicação imediata neste trabalho.

A aplicação do PSP (Personal Software Process) não é a motivação deste trabalho,

pois entende-se que uma organização deve ter bem definidos sua estrutura, seus processos e

seus papéis, para ser competitiva, qualquer que seja seu porte.

22

A abordagem por estágio do CMM / CMMI implica em uma estrutura pesada e

complexa de ser administrada rapidamente. Somente para o nível 2, é proposto cerca de 25

papéis ou grupos com várias responsabilidades e tarefas (ORCI, 2000). Essa abordagem

abre um leque grande de práticas, que precisam ser controladas em paralelo, independente da

estrutura e dos objetivos organizacionais.

Sommerville (2003) aponta três grandes problemas no modelo de maturidade de

capacitação do SEI. Primeiro, o modelo focaliza fortemente o gerenciamento de projeto e não

o desenvolvimento do produto, principalmente, mas não exclusivamente, em seu nível 2.

Segundo, o modelo exclui a análise de riscos como uma ferramenta fundamental do processo.

Terceiro, o domínio da aplicabilidade do modelo não é definido, reconhecido pelos próprios

autores como não aplicáveis a todas as organizações.

Existem dois grandes colaboradores para a proposta CMM/CMMI, fora a alta direção

da empresa. Um é o SEPG (Software Engineering Process Group), que é o coração do

CMM/CMMI, devendo conhecer a filosofia, os termos do modelo, ferramentas de apoio e os

processos de desenvolvimento da empresa, além de ser o divulgador das melhorias esperadas

pela adoção do modelo. O Outro é o grupo SQA (Software Quality Assurance), que será o

grupo capacitado para fazer o controle e a garantia da qualidade, avaliando a conformidade

das atividades reais com as práticas padrões adotadas, e coletando métricas para a reavaliação

dos processos e estimativas.

Uma das grandes complexidades dos modelos CMM/CMMI encontra-se exatamente

na atribuição destes dois grupos. Para a adoção de procedimentos e práticas padrões, o SEPG

estuda, adota, divulga e implanta os padrões, e o SQA verifica a conformidade (MARCZAK,

2003). O SEPG adota atividades que claramente devem ter em mente a qualidade como meta

a ser alcançada; não apenas a adoção dos padrões institucionais, que são muito importantes

para a organização, mas que são componentes de um sistema mais amplo e bastante integrado

que o SEPG, na sua essência, por si só não vislumbra. A implantação dessa visão ampla

também não pode ser a atribuição do SQA tradicional, pois verifica-se sua vocação

operacional claramente.

A ISO/IEC 15288 com sua aplicação em ambientes de soluções integradas entre

pessoas, sistemas, hardware e software, pode-se tornar um modelo complexo para uma

organização que não tem toda essa necessidade nos negócios nem a devida adequação

estrutural.

23

A ISO/IEC 90003, interpretação da ISO 9001:2000 específica para empresas de

software, aponta de forma bem detalhada e extensiva os processos de software mais

adequados e atuais em prática, e referencia os principais modelos e padrões adotados

mundialmente. Por isto, a organização precisa ser madura e bem estruturada para sua adoção.

No entanto, essa norma pode ser consultada para dispersar dúvidas na aplicação da ISO

9001:2000.

A ISO 9004:2000 propõe um modelo de melhoria para o Sistema de Gestão da

Qualidade, aprofundando, principalmente, os processos nos aspectos organizacionais. Torna-

se uma forte candidata para ser adotada na organização em um segundo momento, após a

estruturação fundamental recomendada pela ISO 9001:2000.

A ISO/IEC 12207, apesar de já se encontrar em revisão pelos Amendment-1:2002 e

Amendment-2:2004, oferece em sua versão de 1995, uma estrutura apropriada para as

organizações, que ainda não têm maturidade ou estrutura bem definida. Ela é adequada em

um primeiro momento de uma organização para definir seus processos. A possibilidade de a

organização representar, à sua maneira, seus objetivos e necessidades é aplicada por uma das

possíveis visões da norma e os de seus processos (MACHADO, 1998; SINGH, 1999;

TSUKUMO, 2004).

A ISO 9001:2000, com sua estrutura voltada para a definição e certificação de um

Sistema de Gestão da Qualidade (SGQ), é particularmente apropriada para uma organização,

que já tenha alguns processos de software. Em geral, as organizações sobrevivem em um

mercado acirrado, mas que não têm, na realidade a maturidade na administração de suas

rotinas organizacionais básicas como, por exemplo, os relacionamentos com o cliente, com o

fornecedor, com contratos de negócio, contratações, folhas de pagamento, contabilidade,

missão, objetivos e políticas.

O TickIT é uma certificação ISO 9001:2000 exclusiva para a organização de software.

Apesar de seu material não seja de domínio público, há indicações que realmente há um bom

relacionamento da ISO 9001:2000 com a ISO/IEC 12207.

24

A Figura 2.3 também apresenta que dentre os diversos modelos que envolvem

qualidade, processos, avaliação, capacidades, melhoria e diretrizes, tem-se uma convergência

para o CMM/CMMI e para a ISO 9001.

Figura 2.3 – Relação entre modelos, padrões e normas (QUAGMIRE, 2005)


Apresentou-se, a partir do ponto de vista fisiológico da organização, a importância de

processos e modelos que se apresentam para estruturar, avaliar, certificar e melhorar a própria

organização. Porém, observa-se que também há a necessidade de adaptação desses modelos

por mais simples ou genéricos que pareçam. O dilema da adoção de um modelo é

inversamente proporcional à estrutura organizacional – quanto menor a organização, maior o

dilema. O modelo proposto pela ISO 9001:2000 tem um alcance completo ao ambiente

organizacional; porém, não tem uma aplicação direta nas empresas de desenvolvimento de

software. A visão da organização como um todo, isto é, a visão sistêmica, é seu ponto forte.

A ISO 9001 procura envolver a organização em uma visão mais ampla da qualidade e

no atendimento aos anseios do cliente, porém não está diretamente ligada ao produto de

software. Uma possível integração do CMMI com a ISO 9001 poderia vir a ser uma solução

para isto. A implantação de um Sistema de Gestão da Qualidade daria a visão da qualidade a

todos os componentes organizacionais e humanos da empresa, pessoas, equipes de projeto,

grupos de especialistas e setores, departamentos e divisões em todas as áreas. Haveria a

adoção dos padrões institucionais, a gerência de projetos, a verificação dos requisitos e

padrões, a análise crítica dos fatos e ações e a adoção de ações corretivas, preventivas e de

25

melhoria. Com esta abordagem verificam-se que os planos estratégicos, gerenciais e

operacionais, que abrangem a qualidade estariam bem norteados e definidos.

2.4 O Ponto de Vista Administrativo

2.4.1 Introdução

A visão administrativa da organização vai ser a responsável pelas características e o

comportamento da empresa e estaria mais próximo do microambiente de Chiavenato (1999).

É nessa visão que se encontram os grandes desafios, pois a organização se torna visível para

clientes, fornecedores, concorrentes, observadores e colaboradores.

2.4.2 Definindo sistema

Rezende (2000) diz:

O mundo está arbitrariamente segmentado em diversas partes e separado em diferentes áreas.

Essas áreas estão bem definidas e regulamentadas, porém ainda permitem a existência de

pequenos espaços livres entre elas. Em contraponto, a Teoria Geral de Sistemas busca sua

justificativa básica de que a natureza não está dividida em partes, pois faz parte do ecossistema.

Também fazem parte do ecossistema, o sistema empresa e os demais sistemas existentes no

planeta, independentemente de ser software ou conter recursos computacionais.

O dinamismo conceitual de sistema propicia a idéia de que existem sistemas dentro de

outros sistemas com inúmeros processos de intercâmbio, onde cada um mantém uma forte

influência na estrutura do outro.

A estrutura fundamental dos sistemas é baseada na relação entre entradas, saídas,

processos e feedback. Onde entradas são recursos, oriundos do ambiente ou de outros

sistemas, usados para atingir, direta ou indiretamente, os objetivos do sistema. Processos são

os elementos dinâmicos que interligam os componentes do sistema e provoca a manipulação

das entradas. Saídas são os resultados do sistema final ou de forma intermediária, dos

componentes e processos, que serão considerados entradas para outros processos,

componentes ou sistemas. Feedback significa o retorno da informação, é o regulador do

sistema, podendo modificar ou reforçar os comportamento do sistema (MAXIMIANO,2004) .

Maximiano (2004) diz:

Uma das premissas mais importantes do moderno enfoque sistêmico é a noção de que a

natureza dos sistemas é definida pelo observador. (...) Para enfrentar a complexidade, é preciso

ter a capacidade de enxergá-la. Quem utiliza o enfoque sistêmico aprende a enxergar sistemas e

26

sua complexidade. Para enxergar sistemas, é preciso educar-se para perceber os elementos da

realidade como parte de sistemas. (...) Ampliando o foco, as fronteiras do sistema expandem-se

demasiadamente e a perspectiva se perde. (..) Para usar o enfoque sistêmico, é preciso aprender

a delimitar fronteiras de sistemas para entendê-los e manejá-los.

Desta forma, ainda segundo Maximiano (2004) , para analisar ou planejar sistemas

deve-se ter em integração os seguintes elementos: objetivos, componentes, processos e

administração e controle. Os objetivos são definidos ao se responder as seguintes perguntas:

(1) Qual a finalidade do sistema? (2) Que critérios se podem utilizar para avaliar a eficácia do

sistema? (3) Quem são os clientes do sistema? A clareza dos objetivos é fundamental para o

dimensionamento dos outros elementos. Os Componentes são esclarecidos ao se ter as

respostas das seguintes perguntas: (1) Quais são as partes do sistema? (2) Qual a natureza de

cada componente? (3) Onde esses componentes podem ser adquiridos? (4) Que se deve fazer

para obter a participação desses componentes? Os processos são as formas como os

componentes se relacionam, podem criar operações que transformam componentes ou

prestam serviços, e, por sua vez, são esclarecidos pelas respostas às perguntas: (1) Que

operações devem ser realizadas para que os objetivos sejam atingidos? (2) De que forma os

componentes do sistema devem ser organizados para que as operações sejam realizadas? (3)

Qual o tempo do ciclo do processo? O sub-sistema de administração e controle garante a

realização dos objetivos regulando o próprio funcionamento do sistema. As perguntas que

precisam ser respondidas são: (1) Como garantir a realização dos objetivos do sistema? (2)

Que informações indicam se o sistema está atingindo seus objetivos? (3) Como podem essas

informações ser obtidas? (4) Que decisões devem ser tomadas?

2.4.3 A empresa e o conceito de sistema

A partir da década de 60 começou a aplicação dos princípios da Teoria de Sistemas à

administração. A teoria sistêmica trata a organização como um sistema de componentes e

variáveis mutuamente interdependentes, fornecendo um contexto unificador para a moderna

teoria da organização e o exercício da administração, permitindo ver a organização como um

todo, identificando os seus diversos subsistemas e suas relações de interdependências mútuas,

bem como enfatizando as relações que a organização mantém com o meio ambiente

(SANTOS,2001).

As empresas são sistemas, pois segundo Rezende (2000) são a “junção de diversos

recursos, sejam humanos, materiais, financeiros e tecnológicos, que produzem e

comercializam produtos para a satisfação das necessidades das pessoas e de outras empresas

27

em troca de lucro e perenidade” e também são “organizações sociais, compostas de pessoas e

valores, que trabalham em conjunto e utilizam recursos para atingir objetivos, explorando um

negócio qualquer, por meio de gestão e direção dessas pessoas e desses valores”. Ainda

citando Rezende (2000), os principais objetivos de uma empresa são:

Satisfazer às necessidades dos clientes, buscando e mantendo-os;

Estar em permanente desenvolvimento;

Fazer parte de uma comunidade, elaborando produtos e gerando empregos;

Comercializar bens e serviços, obedecendo a padrões de qualidade;

Ter equilíbrio financeiro para seu crescimento;

Alcançar modernidade e competitividade;

Gerar lucro e perenidade.

Koontz (1981) afirmou: “A fim de possibilitar que as pessoas trabalhem eficazmente

para atingir metas, é preciso idealizar e manter uma estrutura intencional de papéis ou

funções”. Laudon (2001) diz: “Os elementos-chave de uma organização são suas pessoas, sua

estrutura e seus procedimentos operacionais, suas políticas e sua cultura”. A definição de

uma estrutura organizacional se faz necessária. Tradicionalmente a organização é referenciada

como uma estrutura piramidal, ora representando os níveis de decisão, ora descrevendo a

complexidade e o inter-relacionamento das informações, atividades e problemas, ora

representando as funções empresariais. A figura 2.4 foi adaptada de Rezende (2000) e

representa bidimensionalmente essa estrutura.

Figura 2.4: Relacionamento entre os níveis de decisão, atores, ações e visões organizacionais Rezende (2000)

O equilíbrio entre o tamanho dos níveis e das funções influencia no planejamento,

controle, coordenação e comunicação. Eis o ponto chave para se estabelecer a estrutura

28

organizacional ideal e sustentar todo este complexo inter-relacionamento. “A estrutura deve

ser projetada para que funcione, para que permita contribuições dos membros de um grupo e

para que auxilie as pessoas a atingir os objetivos eficientemente num futuro em mutação” diz

Koontz (1981).

Como elementos principais na mudança no ambiente empresarial, o conhecimento e a

informação influenciaram na transformação nas possibilidades para organizar e administrar. A

organização se tornou menos hierárquica, mais flexível e descentralizada. Essas mudanças

tornam a empresa mais dependente do conhecimento, da aprendizagem e da tomada de

decisão individuais (Laudon,2001). A informação precisa se transformar em conhecimento,

precisa ser distribuída, percorrendo todos os níveis da organização e se integrando ao dia-a-

dia do ambiente produtivo. Descrevendo a informação pode-se percebê-la como os objetivos

individuais da organização.

Sato (2003) detecta “com a competição global e a crescente preocupação com os

aspectos humanos e ambientais, a produtividade tradicional, que leva em consideração apenas

o capital e a mão-de-obra como fatores de produção, já não é suficiente para garantir a

sobrevivência e a competitividade das organizações. Surge assim o conceito de produtividade

sistêmica, que aborda de forma mais ampla o que se entende por produtividade em uma

organização”. A produtividade é a relação otimizada dos recursos de entrada para a

maximização dos resultados desejados. A produtividade sistêmica, descrita por vários

trabalhos (SATO,2003), (WEBER,1999), adota a visão da Teoria Geral do Sistema com a

interdependência dos fatores da produtividade, com o ambiente, a qualidade de vida e a não

dissociação das partes em relação ao todo.

A Gerência de Projetos é apontada como uma grande contribuição para a produtividade

sistêmica, pois está presente em todos os aspectos de controle e planejamento da organização.

Em relação ao gerenciamento de projetos, a década de 80 foi a Década da Qualidade e a de

90 a Década da Responsividade ( Resposta Rápida), a primeira década dos anos 2000 as

empresas passarão a depender também da capacidade de identificar e executar as melhores

práticas. O Planejamento Estratégico identificará e selecionará as melhores estratégicas e o

gerenciamento de projetos será o agente executor (PRADO, 2000). Ainda referenciando

Prado (2000), para evidenciar a evolução das transformações dos ambientes interno e externo

da organização, têm-se:

A importância do cliente na elaboração estratégica das empresas;

29

A grande competição entre as empresas implicando em prazos cada vez menores,

disputas internacionais freqüentes pelos recursos disponíveis e o rápido

desenvolvimento de novas economias, principalmente as do chamado terceiro

mundo;

O tempo médio de vida dos produtos tende a ficar cada vez menor;

Projetos gigantescos estão se tornando comuns em todas as empresas e no

governo. Muitos projetos são tocados por várias empresas ao mesmo tempo;

Alterações profundas na forma de administrar as empresas com a adaptação de

estruturas organizacionais mais adequadas, como o modelo matricial, o escritório

de projetos e a presença de comitês.

Para apoiar a produtividade sistêmica têm-se algumas estruturas importantes que podem

servir de inspiração, sendo envolvidas, integradas ou adaptadas, como a organização

matricial, a organização baseada em equipes, o Departamento de Serviços, o escritório de

projetos (EP, PMO – Project Management Office ou PO – Project Office), os comitês, os

círculos da qualidade (MAXIMIANO,2004), (KOONTZ,1981), (SATO,2003), (PRADO,

2000), (CHIAVENATO,1999). A seguir alguns detalhes de cada um dessas estruturas:

A Estrutura Matricial é um modelo de estrutura organizacional que, segundo Prado

(2000), mostra-se mais recomendada quando as habilidades e os recursos se encontram

espalhados por diversos departamentos funcionais da empresa. Os problemas interfuncionais

são administrados por um responsável que pode ser alocado temporariamente a esse grupo

interdisciplinar, que por sua vez também é temporário. Essa é uma estrutura híbrida entre o

modelo funcional tradicional e o modelo orientado por projetos. Como características dessa

abordagem organizacional têm-se: Maximização dos recursos (principalmente os

especializados) e economia de escala, compartilhamento de conhecimento entre diferentes

habilidades e especialidades, compartilhamento de poder pela presença de mais de uma

autoridade, satisfação das necessidades organizacionais de especialização e coordenação,

necessidade de definição clara das responsabilidades e autoridades. (CHIAVENATO,1999).

A figura 2.5 mostra esta estrutura.

30

Figura 2.5 – Modelos de estrutura Organizacional (baseado em Prado(2000) e Maximiano(2004))

A Abordagem por equipes consiste em juntar recursos para resolver problemas. Entre

os recursos têm-se as pessoas e os processos. As formas tradicionais de organização

fundamentam-se sobre as funções, os produtos/serviços, clientes, mercados regionais.

Excetuando-se a organização que adote abordagem por processos, todas, de alguma forma,

esquecem dos processos organizacionais que envolvem a produção e a entrega para os clientes

ou mercados. Todos usam os processo mas ninguém é o dono nem responde completamente

por ele, as fronteiras dos processos entre os grupos/departamentos/divisões usuários

normalmente são pontos críticos. As equipes operam todo o ciclo do processo, respondem por

ele e podem ser compostas com pessoas de departamentos/divisões/setores distintos (

conceitualmente iguais à estrutura matricial) ou como uma estrutura formal dentro do

organograma da organização (CHIAVENATO,1999).

O Departamento de Serviços, segundo Koontz (1981), é “um agrupamento de

atividades que poderiam ser realizadas em outros departamentos mas que são reunidas num

especializado com propósitos de eficiência, controle ou ambos.”. Como benefícios dessa

estrutura têm-se: A dedicação centralizada de um grupo especializado, a demanda flutuante

pelo serviço em vários departamentos pode ser melhor administrada.

31

O Escritório de Projetos tem um crescimento significante no segmento de informática

e é uma especialização do departamento de serviços para a gerência de projetos. A missão do

Escritório de Projetos é dar apoio no planejamento e acompanhamento do projeto,

envolvendo-se também com a criação e manutenção de padrões, normas e regulamentos,

auditoria e garantia da qualidade dos projetos, treinamento e consultoria em gerência de

projetos, participar em etapas iniciais da avaliação de riscos de um projeto e funcionar como

interface entre os projetos, a alta administração da empresa e usuários e/ou clientes, garantir a

troca de conhecimento entre os projetos e o desenvolvimento de futuros gerentes gerais,

aumentar a maturidade da gerência de projetos na empresa, ser o “Guardião das melhores

práticas” e um dos agentes da gerência à vista. (PRADO, 2000), (SATO,2003),

(BARCAUI,2004), (DINSMORE,2002). Vale citar a visão sistêmica e recursiva de Barcaui

(2004) sobre o papel do escritório de projetos na maturidade da empresa: “... Curiosamente, as

atribuições do Escritório podem ser atualizadas na medida em que se verifique que o nível de

maturidade da empresa também esteja crescendo. Mas, o próprio EP parece ser também uma

das partes fundamentais deste aumento de maturidade. Isso faz com que o desenvolvimento

do EP se torne algo recursivo dentro do processo de melhoria contínua da organização para

atingir um estágio mais alto de maturidade, independente do modelo adotado.”. Pode-se

ampliar esta abordagem ao próprio Departamento de Serviços mencionado anteriormente, no

momento que o serviço se torne a gerência de projetos ou outra função mais especializada

dentro da estrutura da organização.

O Comitê é um agrupamento de profissionais, sem vínculos hierárquicos e oriundos de

vários departamentos, que se reúnem periodicamente para tratar de assuntos específicos, com

os quais possuem alguma ligação. Pode também vir a ser composto pelos líderes de um

projeto. Tem um aspecto de menor poder e estrutura que o Escritório de Projetos, porém é o

local para coordenar as ações interdepartamentais e assegurar o cumprimento das metas dos

projetos, pois com a análise em grupo de situações comuns é possível chegar a um consenso

com menos desgastes e mais sinergia (PRADO, 2000).

A idéia dos Círculos da Qualidade ou Círculos de Controle da Qualidade (CCQ) foi

desenvolvida pelo Dr. Kaoru Ishikawa e aplicada no Sistema Toyota de Produção (a partir de

1950) e é um grupo voluntários de um mesmo setor ou área de trabalho, que se reúnem

regularmente para estudar e propor soluções de problemas que estejam comprometendo a

qualidade e a eficiência dos produtos. Nada impede que o grupo se forme com pessoas de

diferentes áreas de trabalho. Alguns outros objetivos também fazem parte da idéia, são eles:

32

Envolver as pessoas no processo de análise e resolução de problemas, melhorar a

comunicação do próprio grupo de trabalho e estimular um clima de criatividade, mentalidade

da qualidade, autocontrole e prevenção de falhas. Estes aspectos levam a um envolvimento e

compreensão de todos os envolvidos, ampliando sua visão e integrando seus objetivos,

responsabilidades, e atividades individuais com os do grupo ou por toda a organização

(MAXIMIANO,2004) . “Os membros do CCQ aprendem e, depois, ensinam a participar e a

desenvolver habilidades de comunicação grupal, técnicas de análise e soluções de problemas,

técnicas de mensuração e estratégias de qualidade.” (CHIAVENATO,1999)

A identificação de algumas estruturas organizacionais que se utilizam diretamente dos

conceitos de projetos e sistemas é uma questão prática para tentar trazer a realidade complexa

da organização para uma visão mais simples de ser percebida. Observam-se a atuação distinta

dos níveis operacionais, táticos e estratégicos, e mesmo assim se vêem elementos que estão

presentes nesses três níveis ao mesmo tempo. Esta é então a organização formalizada.

2.4.4 Delimitando as fronteiras organizacionais

Estudo divulgado pelo IBGE em 2001, As Micro e Pequenas Empresas Comerciais e

de serviços no Brasil – 2001(IBGE,2003), mostra que as micro e pequenas empresas nas

atividades de comércio e prestação de serviços são um importante segmento na geração de

emprego e renda uma vez que representam 80% de todo os segmentos das MPE’s e

correspondem a 22,3 % (168,2 Bilhões de Reais) em relação a receita total ( 752,9 Bilhões de

reais) e 60,8 % (7.290,7 Mil pessoas) em relação ao número de pessoas ocupadas ( 11.995,3

mil pessoas) incluindo nos dois totais as médias e grandes empresas de comércio e serviços. A

classificação em micro, pequenas, médias e grandes empresas está detalhada no Apêndice I.

No entanto, será usada a classificação do MCT (Micro até 9, Pequena de 10 a 49, Média de 50

a 99 e Grande com mais de 100 pessoas ocupadas).

Já em pesquisa de 2002 – PAS/2002 – Pesquisa Anual de Serviços – 2002

(PAS,2002), o IBGE divulgou que o segmento de serviços de informação (

Telecomunicações, Serviços de informática e serviços audiovisuais) gerou um faturamento

líquido de R$ 91,9 bilhões, tendo a atividade de telecomunicações a maior participação,

contribuindo com 65,1% do total (Figura 2.6). Por outro lado, esta atividade foi a que menos

absorveu mão-de-obra, representando 19,0% do total de 431 mil postos de trabalhos e foi

também a que apresentou menor parcela (4,0%) do total de 51 mil empresas que compunham

os serviços de informação. As atividades de informática, que vêm se expandindo rapidamente

33

desde a década passada, registraram a maior participação no número de empresas e de pessoas

ocupadas (80,9% e 59,1%, respectivamente) no segmento das atividades de informação,

porém sua participação na receita foi apenas de 21,9%. Por ser uma atividade caracterizada

pela prestação de serviços especializados, que vem se disseminando cada vez mais no País, a

remuneração paga em média foi de 6,7 salários mínimos. (IBGE,2002).

Figura 2.6 – Participação das atividades no segmento de serviços de informação – (IBGE, 2002)

Especificamente as atividades de informática, que englobam consultoria em sistemas

de informática, desenvolvimento de programas de informática, processamento de dados

(inclusive digitação), atividades de banco de dados, manutenção e reparação de máquinas de

escritório e de informática, estão detalhadas na tabela 2.4 (Gerado a partir do PAS/2002),

onde se pode identificar que apenas no índice de pessoal ocupado assalariado as MPMEs

estão a baixo das grandes empresas ( 38,4 % contra 61,6 %).

Tabela 2.4 – Número de empresas de informática e pessoal ocupado segundo porte da empresa (PAS-2002)

34

Já segundo a reportagem “Exportação de software deve atingir US$ 500 milhões”,

publicada no site da SOFTEX (Sociedade para a Promoção da Excelência de Software

Brasileiro) na seção Mercado de Software, em 24 de Fevereiro de 2005, as exportações

brasileiras de software devem atingir US$ 500 milhões até o final deste ano sem no entanto

considerar-se as vendas de software embarcado. O último levantamento oficial sobre as

vendas externas do setor foi realizado em 2001 pela própria SOFTEX e apontou exportações

da ordem de US$ 100 milhões. Em 2003, as receitas geradas com as vendas para fora do País

atingiram cerca de US$ 200 milhões. Ainda segundo dados da SOFTEX, o Brasil possui

atualmente 5.400 empresas produtoras de software, que respondem por 158 mil empregos

diretos (dando em média 29 funcionários para cada empresa). No total, o setor representa

0,71% do PIB brasileiro e mais de 50% das receitas totais da indústria de tecnologia da

informação. Os números são estimulantes e mostram que as MPMEs são um segmento em

franca expansão e têm presença tanto no mercado interno quanto no mercado externo.

Os números mostrados nos apontam para um ambiente em que as empresas com

atividades de informática se adequam na classificação de Micro, Pequenas e Médias Empresas

as MPMEs e se enquadram no seu comportamento e nas suas características. As micro,

pequenas e médias empresas (MPMEs) vêm sendo há muito tempo alvo de atenção de

analistas econômicos devido a seu potencial de geração de renda e de emprego (LA

ROVERE,2001). Segundo Rachid (2001) “As grandes empresas têm diminuído sua estrutura

pela redução dos níveis hierárquicos, da mudança da divisão em departamentos, da

terceirização das atividades, envolvendo desde atividades de apoio até atividades produtivas, e

do estabelecimento de novas formas de relação com os fornecedores.” Desta forma, “as

relações com grandes empresas representam uma das principais formas de inserção das

pequenas empresas na economia. Estas podem atuar como fornecedoras, subcontratadas,

revendedoras, autorizadas para prestar assistência técnica, franqueadas ou licenciadas das

grandes.”. Enquanto as grandes empresas têm vantagens materiais para gerar e adotar

inovações, as pequenas e médias empresas têm vantagens comportamentais relacionadas à sua

maior flexibilidade e capacidade de adaptação a mudanças no mercado. Desta forma, as

habilidades tecnológicas das grandes empresas, tendem a "contaminar" as MPMEs através

destas parcerias, e seus perfis estruturais internos buscarão similaridades gerenciais.

(SOUZA,2001). “No entanto, as pequenas empresas possuem um papel mais relevante do que

apenas complementar as lacunas deixadas pelas funções não exercidas pelas grandes

empresas”, ao auxiliarem na “desconcentração espacial das atividades econômicas” amenizam

35

os desequilíbrios regionais e auxiliam no desenvolvimento de áreas periféricas.

(MIGLIATO,2004) . Normalmente as empresas menores têm atividades diversificadas e

estruturas flexíveis que favorecem respostas rápidas a mudanças no mercado. Além disso,

estas empresas podem operar em nichos que apresentam uma alta taxa de inovação. Por

exemplo, enquanto a capacidade inovadora das empresas de software depende fortemente de

suas competências específicas, a inovação em empresas do setor têxtil depende também de

inovações em outros elos da cadeia produtiva, como o setor químico. Esta diversidade torna

extremamente complexa a definição de uma política geral de incentivos e apoio (LA

ROVERE,2001).

Um processo paralelo ao crescimento do mercado da terceirização está o fato da

desobrigação da própria empresa ter de garantir a qualidade de seus produtos e serviços uma

vez que parte dele está sendo feito fora de suas instalações. Isso não quer dizer que houve

uma queda na qualidade, pois as empresas terceiras têm por obrigação garanti-la. Como a

estrutura da empresa terceirizada normalmente não está pronta para eventuais inspeções e

auditorias nas suas contratadas, na verdade o que houve, foi a terceirização da própria função

da garantia da qualidade, onde empresas especializadas conferem um certificado, reconhecido

por todos os participantes, garantindo a adequação a um determinado padrão ou norma.

As organizações têm se defrontado cada vez mais com ambientes de incertezas e

rápidas mudanças, tendo de se anteciparem às necessidades do cliente, aos concorrentes, às

incertezas dos fornecedores e às mudanças nas leis e normas.(LA ROVERE,2004). Para

Terence (2002), a forma da empresa se tornar competitiva está na busca do aperfeiçoamento

contínuo de produtos, técnicas de vendas e processos através da adaptação constante de sua

estrutura organizacional a uma realidade de constantes incertezas que podem se tornar

ameaças ou oportunidades. Já segundo (LA ROVERE,2004), “No novo paradigma tecno-

econômico, as empresas estão lidando com produtos cada vez mais intensivos em

conhecimentos e tecnologia, cujos ciclos de vida têm diminuído e muitas vezes requerem

processos de produção flexíveis”. Neste contexto, é fundamental para qualquer empresa,

independente de seu porte, não apenas definir uma estratégia competitiva adequada como

também monitorar constantemente o seu desempenho, permitindo, quando necessário, ajustes

e adaptações.

Souza (2001) anuncia “um novo perfil de gestão industrial se configura na nova

economia do conhecimento praticado pelas líderes e seqüencialmente imitado pelas demais

36

indústrias: a) Desmantelamento hierárquico buscando a flexibilidade de suas estruturas; b)

Rapidez na entrada e saída dos mercados; c) Aprendizado e trabalho conjunto com as

MPMEs.”, e, em sua análise do sistema japonês de uso dos ativos acadêmicos, mostram “que

a dinâmica de interação entre o setor produtivo, as universidades, as instituições de apoio e

fomento e as instituições de intermediação levaram as empresas japonesas a uma trajetória de

aprendizagem e capacitação.”. Esse sistema desenvolveu uma forma organizacional que

enfatiza a aprendizagem e a inovação de forma “sistêmica e sinergética” entre os participantes

dessa interação. O processo se deu em estágios “passando por ‘aprender a produzir’, ‘aprender

a produzir com qualidade’, ‘aprender a inovar’ e ‘aprender a inovação sistêmica’”.

A pesquisa “A indústria de software no Brasil 2002”, parte de projeto do

SOFTEX/MIT (SOFTEX,2002), relaciona diretamente o Brasil a Índia e a China e aponta

outros países como destaque na produção de software: Argentina, Irlanda, Israel, México,

Rússia e Filipinas. Essa rica pesquisa revela que a Indústria Brasileira de Software tem hoje

um conjunto de realidades e caracteriza-se por uma forte demanda doméstica que desestimula

a exportação (Sétimo mercado de software mundial) , por uma fragmentação do mercado

nacional, com firmas de menor porte e avessas à cooperação e por uma inserção na economia

política mundial de Tecnologia da Informação (TI) mais desvinculada dos grandes centros

(principalmente Estados Unidos). Em relação à capacitação de processo observa-se que

apenas uma pequena parcela possui certificação de elevada maturidade no seu processo de

desenvolvimento de software (CMM nível 3 ou superior). Dentre as empresas com

certificação (CMM/ISO), a maioria está associada a produtos, enquanto as empresas de

serviços empregam métodos próprios, mas sem certificação, uma lacuna importante do ponto

de vista de afirmação internacional.

São características desta indústria: a alta velocidade na introdução de inovações

técnicas e no desenvolvimento de produtos, novos ou existentes; a competição acirrada; o

baixo investimento em capital fixo; e a capacidade criativa e intelectual da mão-de-obra, que é

o seu grande ativo.

A forma tradicional de tratar o software é a adoção de três grupos: Software de

pacote(Ex: Editor de texto), o serviço de software (Ex: desenvolvimento customizado,

manutenção) e o software embarcado (Ex: Software em celulares). Em virtude da maioria das

empresas desenvolvem simultaneamente atividades de produtos e serviços a tabela 2.5 mostra

uma expansão da classificação tradicional.

37

Tabela 2.5 – Descrição do mercado de produtos e serviços de software (SOFTEX,2002)

É fundamental a distinção entre produtos e serviços e as diferentes características das

empresas envolvidas. Na tabela 2.6 a baixo três razões para essa distinção.

Tabela 2.6 – Distinção entre produtos e serviços de software (SOFTEX,2002)

O trecho a seguir foi retirado da pesquisa SOFTEX/MIT (SOFTEX,2002) e determina

de forma clara a perspectiva buscada nesse trabalho:

A questão principal associada à distinção entre serviços de baixo e elevado valor

acrescentado é o fato de, embora o modelo básico de negócio seja o mesmo, existirem

diferenças significativas entre as duas realidades. Os serviços de baixo valor envolvem

normalmente aspectos como a manutenção de software ou a geração de código. As tarefas a

38

desenvolver são simples e bem especificadas pelo cliente, pelo que podem facilmente ser

divididas. Nesse sentido, a gestão da empresa está voltada para eficiência na gestão do

processo. A competição entre empresas é normalmente baseada em preço, sendo a sinalização

de requisitos mínimos de qualidade do processo dados pela história da empresa, ou pela

certificação dos processos. A realidade competitiva é normalmente dominada por empresas

locais, em particular para serviços que envolvem forte interação com os clientes, como

manutenção de software. No entanto, em situações em que a necessidade de interação é mais

reduzida, este serviço pode ser contratado à distância. Esta é atualmente a realidade da Índia,

através do offshore, a que se junta igualmente a modalidade associada à transferência de

recursos para o local do cliente (o onsite), solução viável à distância quando existem grandes

diferenciais no custo de salários entre as duas realidades. Pelo contrário, os serviços de elevado

valor envolvem incerteza relativa ao resultado (caso da P&D sub-contratada), ou partilha de

responsabilidade na definição do sistema (análise de requisitos). Por essa razão, o risco para o

cliente é maior e a sua possibilidade de avaliar a capacidade do fornecedor apenas com base na

qualidade do processo mais reduzida. Assim, tornam-se especialmente importantes aspectos

como a reputação. Este mercado é dominado por multinacionais de consultoria de sistemas,

muito embora existam sempre oportunidades locais para fornecer serviços a empresas menores

e com menos capacidade financeira. É neste segmento que algumas das empresas locais de

países em vias de desenvolvimento querem igualmente se posicionar, substituindo algum

déficit de reputação por experiência, forte capacitação de processo (e.g. através do uso das

melhores práticas de Engenharia de Software, que contribuam para a melhoria dos processos de

software, tais como ISO 9001:2000, certificação CMM ou SPICE) e custos drasticamente mais

baixos.

Outra importante pesquisa, MCT - Empresas Graduadas nas Incubadoras Brasileiras: 2001

(MCT,2001), relata as condições da empresas que passaram por um processo de incubação e

aponta que cerca de 99% se enquadram na classificação de MPMEs. Entre as conclusões

tiradas da pesquisa vale salientar a necessidade da aproximação Academia-empresa:

Grande parte deste universo é constituído por micro e pequenas empresas , tanto quando

avaliadas sob o ponto de vista do número de funcionários como pelo faturamento. Outro fator

que também evidencia o pequeno porte da grande maioria das empresas graduadas é a

limitação geográfica das atividades comerciais, tanto no Brasil como no exterior. Poucas são as

empresas exportadoras. Essa baixa taxa de crescimento pode ser atribuída em grande parte às

dificuldades para a capitalização dessas empresas. Razões de natureza cultural devem também

estar contribuindo para uma atitude pouco ousada diante do mercado. No Brasil , em muitos

casos os mercados locais podem viabilizar a sobrevivência de uma empresa que atue em um

nicho, com um produto inovador. Caberia um esforço dos organismos governamentais e

privados que participam deste movimento, e das próprias incubadoras, no sentido de estimular

39

o crescimento dessas empresas. (...) Confirma-se com esta pesquisa uma grande concentração

de empresas com perfil tecnológico, que está relacionado ao fato de o movimento de

Incubadoras no Brasil estar fortemente vinculado a universidades e institutos de pesquisa. Esse

conteúdo tecnológico pode ser verificado não apenas pela natureza dos produtos e serviços

ofertados, mas também pelo elevado grau de instrução dos sócios fundadores e de seus

funcionários, o que permite que a capacidade inovadora dos negócios se mantenha ao longo da

vida da empresa. (...) Ainda sobre os produtos comercializados, foi verificado que muitas

empresas terceirizam parte da produção e demonstram uma crescente preocupação com a

qualidade e com a competitividade de seus produtos, o que pode ser verificado com a redução

sistemática ao longo dos últimos três anos do número de peças defeituosas, dias parados ,

redução dos prazos de entrega e a crescente adoção de instrumentos de gestão empresarial. (...)

Podemos concluir que deve haver uma política de apoio às empresas graduadas, procurando

manter uma rede de articulação que possibilite a elas a procura de novos mercados no país e no

exterior, e que permita a identificação e a criação de novos mecanismos de capitalização que

viabilizem um crescimento sustentado dos empreendimentos. Vários passos já foram dados

com sucesso, e possibilitaram a introdução no mercado de um significativo número de novas

empresas, promissoras, antenadas com a tecnologia e com a inovação. O desafio agora é

desenvolver ferramentas e implementar serviços que possibilitem o crescimento dessas

empresas.

As pequenas empresas possuem algumas particularidades, decorrentes de sua

estrutura, que influenciam sua gestão e atuação no mercado. Desta forma, os estudos relativos

a técnicas de gestão são fundamentais para a melhor adaptação frente aos escassos

recursos.(TERENCE,2002), (BIDO,1999). Entre as principais particularidades está o aspecto

informal da administração com a ausência de regras e normas escritas e a inexistência de uma

clara definição de cargos, tarefas e responsabilidades.(TERENCE,2002). Carvalho (2004)

conclui que “Atualmente sente-se a necessidade fundamental de se desenvolver uma ‘teoria

Administrativa’ para as empresas de pequeno porte. Para isso, é preciso adequar os

instrumentos administrativos a partir do entendimento das variáveis do ‘mapa’

organizacional,”. Entretanto, “Esse entendimento não é fácil, mas necessário quando se

pretendem adequar as técnicas administrativas a fim de diminuir a lacuna existente entre a

literatura administrativa e a pequena empresa”. Daí a forte necessidade da aproximação com a

academia. Na grande maioria das vezes, as pequenas empresas não necessitam de técnicas

complexas de gestão e sim de formas adequadas, ou adaptadas, às suas especificidades e reais

necessidades.

40


O conceito de sistema encontra-se fortemente relacionado com a existência da

organização. Alguns dos aspectos da complexidade da organização estão na forma de

administrar esse conceito, controlando suas características, utilizando inúmeras abordagens e

tendências. É nesse ambiente que se encontram as maiores dificuldades, pois apesar de ser

clara sua presença é um ambiente complexo e muitas vezes hostil, pois de certa forma foge do

controle rotineiro dos administradores das empresas de software e todo seu tradicional

envolvimento com os aspectos técnicos do desenvolvimento. No Apêndice III, encontram-se

alguns dados também importantes e levantados durante as pesquisas.

2.5 Considerações

A evolução do conceito de qualidade reflete a importância do cliente, sua opinião, suas

necessidades e expectativas. Essa importância influencia diretamente nas características do

produto e nas relações de pré e de pós-venda, indiretamente os processos de controle e de

apoio devem estar bem adaptados para garantir a qualidade em todo o contexto do produto de

software.

A essência deste trabalho é a abordagem da qualidade de software integrada à visão

dos processos e sob a perspectiva do ambiente organizacional das MPMES. Dessa forma,

envolve diretamente a engenharia do processo, a engenharia do produto e o gerenciamento do

projeto. Segundo Belchior (1997) dois grandes aspectos estão presentes na estruturação

organizacional da qualidade:

Um programa de melhoria da qualidade leva ao estabelecimento de um sistema de qualidade,

que deve envolver aspectos técnicos e culturais, que são igualmente importantes. O aspecto

técnico envolve o desenvolvimento de padrões e procedimentos para implementar a qualidade

em todas as atividades. O aspecto cultural está diretamente relacionado com a aceitação da

qualidade por todos os indivíduos da organização.

No seu trabalho, Roullier (2001), argumenta que a Engenharia de Processos pode ser

vista como uma extensão da função tradicional da garantia da qualidade preconizando esta

atividade para definir, analisar, simular, implantar, avaliar, medir e melhorar os processos

organizacionais, tratando-os sob forma sistemática. Eis porém a grande dificuldade da

organização entender, definir, estruturar e gerenciar esses processos.

41

Inicialmente, para estruturar a proposta desta dissertação, foi mapeada a relação entre

os requisitos da norma ISO9001:2000 e as características comuns às KPA’s dos níveis 2 e 3

do CMM. No mapeamento não se relacionam os dois modelos diretamente, apesar de

semelhanças entre os dois verificou-se que existiam pontos que um modelo não cobriam um

relação ao outro, tanto no sentido CMMxISO quanto ISOxCMM. Para não se fazer dois

mapeamentos foi escolhido um terceiro elemento que serviu como estrutura comum de

análise, a Norma ISO/IEC 12207:1995. Exatamente neste momento foi verificada a grande

interação entre as normas ISO 9001:2000 e ISO/IEC 12207:1995, as duas normas poderiam se

complementar, uma criando o ambiente organizacional de gestão da qualidade e a outra

apontando uma abordagem direta aos processos de software.

A busca dessa estrutura organizacional da qualidade nos leva então à continuidade do

trabalho. A fundamentação buscada nas seções anteriores indica, ou aponta, um caminho que

foi encarado de forma integrada e envolveu fortemente todos os aspectos descritos.

42

CAPÍTULO 3 LINHAS PARA UM MODELO

“A inteligência dos ecossistemas, em contraste com tantas instituições humanas, manifesta-se na tendência predominante para estabelecer relações de cooperação que facilitem a integração harmoniosa de componentes

sistêmicos em todos os níveis de organização.” Fritjof Capra

3.1 Uma Interpretação Sistêmica e Integrada dos Ambientes

Dos Critérios de Excelência (2004), pode-se citar a Visão Sistêmica como uma “forma

de entender a organização, como sendo um sistema integrado à sociedade, onde o

desempenho de um componente pode afetar não apenas a própria organização, mas suas

partes interessadas.” E como este conceito é colocado em prática, tem-se:

As organizações são constituídas por uma complexa combinação de recursos, interdependentes

e inter-relacionados, que devem perseguir os mesmos objetivos e cujos desempenhos podem

afetar, positiva ou negativamente, a organização em seu conjunto. Um sistema organizacional

pode ser dividido em subsistemas e componentes, com menor grau de complexidade,

permitindo maior facilidade no gerenciamento de atividades e processos; porém, a tomada de

decisão, o gerenciamento dos processos e a análise do desempenho da organização devem

considerar o conjunto dos subsistemas e suas inter-relações. A visão sistêmica pressupõe que as

pessoas da organização entendam seu papel no todo, as inter-relações entre os elementos que

compõem a organização, bem como a importância da integração desta com o mundo externo.

Inclui a focalização de toda a organização na estratégia, o que significa monitorar e gerenciar o

desempenho com base nos resultados do negócio e no atendimento, harmônico e equilibrado,

das necessidades de todas as partes interessadas.

Calligaris (2001), ao descrever a relação do desenvolvimento do produto e a inovação

tecnológica, aponta que uma grande dificuldade no processo de desenvolvimento do produto é

a existência de diversas visões parciais das diversas áreas envolvidas. E exemplifica: “na

visão dos administradores, trata-se de algo mais abstrato e voltado para problemas

organizacionais e estratégicos”; “os engenheiros vêem o desenvolvimento do produto como

atividades específicas de testes e cálculos”; “os designers ou programadores visuais como

resultado de estudos de conceitos”; “os especialistas em qualidade, como a aplicação de

ferramentas específicas”. Ele afirma ainda que o processo de desenvolvimento de um produto

deve ser um todo integrado, para se chegar a um resultado final adequado, dependendo de

diversos fatores ligados às mais diversas áreas de conhecimento, e que “o processo inovador

tem-se caracterizado pela interação necessária entre os diferentes departamentos dentro das

organizações, como marketing, produção, P&D, entre outros.”.

43

Rozenfeld (2005) relata:

Para permitir a integração de empresas é preciso que todos os elementos que a compõem,

sejam eles homens, máquinas e sistemas computacionais, entre outros, sejam capazes de trocar

informações entre si numa profundidade além da simples troca física de dados. Isto passa

necessariamente pelo desenvolvimento de uma visão holística dentro da empresa, isto é, o

desenvolvimento de uma imagem única e integrada nas pessoas que fazem parte desta

organização. É por meio da atuação de pessoas possuidoras desta imagem ampla e integrada e,

portanto, capazes de considerar a interação entre múltiplos fatores, que se desenvolve e

sedimenta a integração da manufatura. Um dos mecanismos que podem auxiliar as pessoas a

obter esta imagem integrada da empresa são os modelos de empresa. Os modelos de empresa

são um tipo específico de modelo formado por um conjunto de modelos, que procuram

representar as diferentes visões da empresa. É formado por um conjunto consistente e

complementar de modelos descrevendo vários aspectos de uma organização.

Como aplicações e benefícios do modelo de empresas, ainda segundo o mesmo autor,

buscam-se:

• Obter uma maior compreensão da empresa;

• Adquirir e registrar conhecimentos para uso posterior;

• Racionalizar e garantir o fluxo de informações;

• Projetar e especificar uma parte da empresa (funções, informação, comunicação,

entre outros);

• Servir como base para análises de partes ou aspectos da empresa;

• Base para a simulação do funcionamento da empresa;

• Base para tomada de decisões sobre operações e a organização da empresa;

• Base para o desenvolvimento e implantação de software de forma integrada;

• Construção de uma cultura, visão e linguagem compartilhadas;

• Formalização do know-how e memória dos conhecimentos e práticas da empresa;

• Suportar decisões para melhoria e controle das operações da empresa, onde, inclui-

se a introdução dos recursos da tecnologia da informação como um dos principais

habilitadores para esta melhoria.

Segundo Carvalho (2004):

44

Um modelo representativo da organização serve para evitar a parcialidade pela

superespecialização, que induz os teóricos organizacionais a enfatizarem mais um aspecto da

organização em detrimento de outros também importantes. Assim, acredita-se na importância

de se adotar um “esquema” ou um “modelo” que contemple os aspectos essenciais e represente

assim a dinâmica de funcionamento da organização, a exemplo do que buscavam os teóricos

dos sistemas. Importante é aprender a ler a organização a partir de diferentes pontos de vistas,

pois somente dessa maneira é possível reconhecer as limitações de cada perspectiva.

A Figura 3.1 apresenta um mapa de representação de uma organização.

Figura 3.1 – Mapa de representação da organização (CARVALHO, 2004)

Uma vez que se consiga identificar na produção do software alguns aspectos da produção

industrial, tais processos podem certamente contribuir na adaptação de processos de software, isto é,

aspectos de outras áreas de conhecimento podem ser adaptados para a área de software. Neste

contexto, o Núcleo de Manufatura Avançada (NUMA, 2005) é um centro de excelência em

pesquisa fomentado pelo Ministério de Ciência e Tecnologia, através do PRONEX (Programa de

Apoio a Núcleos de Excelência), que agrega pessoas de diferentes áreas de conhecimento,

permitindo o desenvolvimento de trabalhos interdisciplinares.

A produção industrial também usa o conceito de análise de sistemas, conhecimento da área

de Sistemas de Informação, juntamente com os conceitos de processos de negócios para a

identificação da atuação da organização e o conceito de visões para a representação parcial da

realidade. “Cada visão pode conter a descrição de um aspecto específico do sistema tornando a

linguagem e a transmissão destes aspectos mais clara, se comparado com a descrição do sistema

45

numa única visão” (ROZENFELD, 2005). Esse conhecimento compartilhado e adequadamente

adaptado às necessidades é uma opção valiosa na adequação de processos.

A Figura 3.2 descreve o processo de modelagem de empresas segundo Rozenfeld (2005).

Figura 3.2 – Processo de Modelagem de Empresas (ROZENFELD, 2005)

Ainda segundo o mesmo autor:

Como entradas deste processo têm-se: conhecimento sobre a empresa (conhecimento sobre a empresa

que está sendo modelada e que reside espalhado entre todos os funcionários e as pessoas que

trabalham na organização); ontologia do domínio (uma formalização de algum conhecimento em

termos de conceitos abstratos e axiomas); biblioteca de modelos conjunto de modelos e objetos que o

profissional de modelagem ou a empresa já possuem e que podem ser reaproveitadas dependendo do

objetivo da modelagem. Os controles que guiam os modelos do processo são os objetivos para os quais

serão empregados os modelos, a metodologia de modelagem adotada e as métricas que avaliam o

andamento desse processo. A execução desse processo é de responsabilidade das pessoas (engenheiros

de empresa ou analistas de empresa) devidamente conhecedoras da ontologia do domínio do problema

da empresa e dos métodos de representação dos modelos. Como resultado final, obtém-se o próprio

modelo de empresa, composto por diversos modelos consistentes e coerentes entre si, tais como

modelos de processo, modelo de dados, entre outros.

As fábricas de software apóiam-se em alguns princípios do processo industrial como:

operações, tarefas, papéis, processos, ferramentas e ambiente de produção, elementos reusáveis,

medições de performance e relatórios de efetividades. No entanto, esta analogia pode ser aplicada

somente no objetivo de produção tipo industrial, não como modelo de implementação

(FERNSTRÖM, 2000; CHAO LI, 2001).

Gonçalves (2000) comenta que “os processos industriais, especialmente os de manufatura,

sempre tiveram seu desempenho acompanhado de perto pelas legiões de engenheiros de produção e

de técnicos da área industrial”. Ele levanta a questão de que “os processos típicos da área não fabril

e das empresas que não têm área fabril, no entanto, passaram despercebidos por décadas”, e justifica

46

que além de fornecer um conveniente nível de análise, a utilização do conceito de processos

“permite-nos ter uma visão melhor do comportamento gerencial, mais integrada e abrangente”. A

nova perspectiva das organizações de identificarem e focarem seus processos levará a novas

necessidades estruturais e comportamentais – o conhecimento realmente se apresentará como um

dos mais valiosos bens.

É nesse contexto de modelagem de empresas e determinação de processos, que a

proposta deste capítulo se insere, apresentando a integração sistêmica das visões conceituais,

fisiológicas e organizacionais, para gerar um modelo para a gestão da qualidade em uma

empresa de software, especificamente a micro, pequena ou média empresa (MPME). Para

isto, sugerir-se-á a criação de um grupo, setor, departamento, ou escritório da qualidade, que

atuaria nos mais diversos aspectos. Este elemento organizacional seria a figura da semente da

qualidade na empresa, atuando de forma continuada, envolvente e crescente, à medida que a

organização implante, amadureça e melhore seus processos. A semente já conserva em si toda

a essência da vida, mas se desenvolve de acordo com o ambiente. Germinando, pode crescer

de forma vigorosa ao longo do tempo.

3.2 Um Modelo para a Garantia da Qualidade

3.2.1 Introdução

Pesquisadores e trabalhos relacionam as tarefas de planejamento da garantia da

qualidade, supervisão, revisão, auditoria, registro, análise e o relato das informações, todas

como tarefas da garantia da qualidade de software (PRESSMAN, 2001; FIORINI, 1998;

PAULK, 1993a; PAULK,1993b; CMMI, 2002; VLIET, 2002). O grupo denominado SQA

(Software Quality Assurance) assume essas tarefas e claramente se posiciona nas atividades

de projetos. Essas atividades são importantes e necessárias; no entanto, não são suficientes

para o sucesso da organização como um todo.

Os mesmos pesquisadores e trabalhos também definem que, em um dado momento

dos níveis de maturidade de uma organização, um grupo deve existir para coordenar o

desenvolvimento e a manutenção dos processos de software – o SEPG (Software Engineering

Process Group). As áreas de processo (PA’s) do nível 3 do CMMI (2002) Foco no Processo

Organizacional, Definição do Processo Organizacional, e Treinamento Organizacional, a PA

do nível 4 Desempenho do Processo Organizacional, e a PA do nível 5 Preparação e

Inovação Organizacional descrevem a necessidade da organização pensar, definir, medir,

adaptar e melhorar seus processos padrões.

47

No CMMI, o SQA é descrito no nível 2 e o SEPG é apresentado no nível 3, agindo nos

processos do projeto e processos organizacionais respectivamente. Estatisticamente, uma

organização tem gastado em média 24 meses para a passagem de um nível para o outro do

CMMI, principalmente dos níveis 1 para o 2, e do nível 2 para o 3 (VLIET, 2002). Este tempo

é inviável para uma MPME se adaptar, organizar seus processos, produzir e sobreviver ao

mesmo tempo.

3.2.2 Base para Análise

Unhelkar (2003) propõe um novo cenário para a atuação da qualidade, que deve atuar

de forma geral, abrangendo a gerência, a modelagem, a programação e os processos. Na

gerência, com a administração do tempo, do orçamento, da funcionalidade e da qualidade. Na

modelagem, como uma maneira de melhorar a comunicação entre os envolvidos no

desenvolvimento. Na programação, com uso de padrões de desenvolvimento e o respeito aos

requisitos definidos para o produto. No processo, com a definição dos processos de produção,

que envolvem ingredientes chaves para o comprometimento com a qualidade.

A qualidade de software também pode ser vista por níveis e pelo contexto do controle

e da garantia da qualidade. O controle da qualidade atuando de uma forma mais operacional e

constatando o atendimento aos padrões e estabelecidos. A garantia da qualidade atuando no

âmbito dos processos. A Figura 3.3 dá a idéia desta visão integradora.

Figura 3.3 – Níveis de Qualidade de software baseada em Unhelkar (2003)

A qualidade do processo de software é mais abrangente que o processo de qualidade,

este está diretamente ligado à análise dos processos de software. A qualidade do processo de

48

software é aquela que tem uma visão mais abrangente, e analisa a relação e o desempenho dos

próprios processos. Esta disciplina inclui as atividades ou os passos que envolvem os bons

modelos e processos. A Figura 3.4 representa esta idéia.

Figura 3.4 – Qualidade de processo mais externa que o processo da Qualidade (UNHELKAR, 2003)

3.2.3 A estrutura de Atuação da Qualidade

Para definir a função que vai assumir as responsabilidades pela definição dos

processos e padrões da organização e dar conta de reconhecer a execução correta desses

processos nos projetos e no ambiente de desenvolvimento, é preciso sistematizar as rotinas da

qualidade e institucionalizá-las.

O SWEBOK (2004) relata que a Área de Conhecimento (KA) Processos de

Engenharia de Software pode ser examinada em dois níveis. O primeiro nível engloba

processos e atividades técnicas e gerenciais, que no ciclo de vida do software envolvem

aquisição, desenvolvimento, manutenção e retirada do produto. O segundo nível, a real

dedicação da KA, seria um meta-nível relacionado com a definição, a implementação, a

avaliação, a medição, a gerência, a mudança e a melhoria dos próprios processos do ciclo de

vida.

O SWEBOK (2004) descreve a KA Qualidade de Software como responsável pelos

fundamentos da qualidade de software, definindo e formalizando os aspectos que envolvem a

qualidade na organização, pelos processos de gerência da qualidade de software, aplicando a

perspectiva da qualidade nos processos, nos produtos e nos recursos, e definindo os processos,

49

os responsáveis, os requisitos para esses processos, as medições, as saídas e os canais de

feedback. No entanto, limita a atenção da gerência da qualidade de software e da qualidade de

processos de engenharia de software, para o suporte direto à qualidade do produto de

software.

Para Amorim (2004), em sua indicação da Gerência da Qualidade na composição da

lista de disciplinas do RUP (Rational Unified Process), “para que a nova disciplina proposta

para o RUP, Gerenciamento da Qualidade, exerça efetivamente seu papel nos projetos de

software, urge que seja estabelecido um conjunto de atividades de ‘gerenciamento da

qualidade’ no âmbito organizacional”. Além disso, esta ‘qualidade organizacional’ deve

existir necessariamente antes da instanciação da disciplina no nível do projeto em si. A autora

recomenda algumas dessas atividades de alcance organizacional:

• Definição dos objetivos da qualidade e de políticas de qualidade para a

organização;

• Estabelecimento de procedimentos, padrões e métricas institucionais da qualidade;

• Estabelecimento de papéis e da função da qualidade na organização;

• Formatação do perfil para os profissionais envolvidos no processo de software;

• Realização de treinamento para os envolvidos no processo, para a disseminação

dos conceitos da qualidade para a organização;

• Estabelecimento de controles sobre os custos das atividades de qualidade nos

projetos.

Para Sommerville (2003), enquanto a gerência de projeto é responsável por garantir

que o nível de qualidade exigido do produto seja atingido, “o gerenciamento da qualidade

envolve definir procedimentos e padrões que devem ser utilizados durante o desenvolvimento

de software e verificar se estão sendo seguidos por todos os envolvidos”. Além dessas

responsabilidades, os gerentes da qualidade devem também desenvolver uma “cultura da

qualidade”, encorajar as equipes para assumirem a responsabilidade pela qualidade de seu

trabalho, e desenvolverem novas abordagens para a melhoria dessa qualidade.

Sommerville (2003) ainda estrutura o gerenciamento da qualidade em três atividades

principais:

50

• Garantia da Qualidade: cuida da montagem de uma estrutura de procedimentos e de

padrões organizacionais, que apóiem o desenvolvimento de software de qualidade.

• Planejamento da Qualidade: adapta a partir dos padrões institucionais os

procedimentos e as necessidades para a qualidade de um projeto específico.

• Controle da Qualidade: preocupa-se com a definição e a aprovação de processos

para assegurem que procedimentos e padrões de qualidade, especificados para o

projeto, sejam seguidos pela equipe de desenvolvimento.

Esta necessidade de uma estrutura completa, envolvendo a qualidade dos produtos, a

eficácia do uso dos processos e a determinação dos processos institucionais, é o grande desafio

da organização.

3.2.4 A Montagem da Estrutura da Qualidade

O modelo cobrirá os níveis que garantam a preparação e a avaliação dos processos

institucionais, o enquadramento dos processos de desenvolvimento aos projetos, e o

acompanhamento dos requisitos de qualidade dos produtos estabelecidos.

Uma estrutura adequada para abrigar a qualidade deve ter aplicação de uma estrutura de

gerência de projetos (CASTELO BRANCO, 2001), uma avaliação da qualidade de produtos

(OLIVEIRA, 2002) e uma preocupação com os processos (ROULLIER, 2001). Amorim (2004)

sugere a incorporação da disciplina de gerenciamento da qualidade ao desenvolvimento de

software baseado no RUP. Algumas PA’s do CMMI poderiam ser aplicadas, mas só estão

prescritas para organizações dos níveis 3, 4 e 5 de seu pesado modelo.


Torna-se clara a dificuldade de implementação de uma estrutura da qualidade tão

completa e detalhada em qualquer tipo de organização, sem antever o alto volume de recursos

investidos. No entanto, torna-se evidente ainda a importância de a organização começar o mais

rápido possível a montagem de uma estrutura da qualidade, que dê apoio a essas necessidades,

de uma forma que consiga visualizar o desafio que se encontra a frente, e busque de forma

contínua e perseverante, o caminho da qualidade.


É necessária uma estrutura para abrigar a qualidade em todos os momentos que

envolvem a organização, adotando uma percepção da própria organização, definindo e

51

modelando seus princípios, suas políticas, seus objetivos, suas metas, seus recursos e

estruturas, até sua inserção no mercado.

3.3.1 A Realidade do Ambiente de Aplicação

Um dos grandes modelos mundiais de gestão da qualidade é a ISO 9001:2000. Um dos

principais fatores para sua aplicação é que ela pode abranger todas as áreas da organização,

dando assim uma visão sistêmica de toda sua estrutura organizacional.

Outro fator que deve ser mencionado é a possibilidade de certificação da organização

pela ISO 9001, que é reconhecida e adotada mundialmente. Entretanto, como sua aplicação é

indicada para qualquer tipo de organização, que contenha processos e produtos, sua aplicação

direta pelas MPMEs de desenvolvimento de software, a qual possui intrincada linguagem

técnica e restrita visão organizacional, poderá apresentar algumas dificuldades.

Estas dificuldades podem ser atenuadas com a associação da norma ISO/IEC 12207,

que utiliza a mesma percepção e linguajar técnicos já presentes no dia-a-dia da organização,

na adequação do Sistema de Gestão da Qualidade (SQA) à norma ISO 9001:2000

(AZEVEDO, 2004b). As MPMEs devem adotar uma estrutura que permita não somente a

implantação do SGQ, mas que consiga dar continuidade à qualidade e que, de maneira mais

forte ainda, adote o princípio de melhoria e evolução contínua de seus processos.

3.3.2 O Ponto de Atuação da ISO 9001:2000

ISO é a sigla da Organização Internacional de Normalização (International

Organization for Standardization). Este é o nome do grupo internacional de normalização

localizado em Genebra, Suíça. Essa organização foi fundada em 23 de fevereiro de 1947 e é

uma rede de institutos nacionais de padrões de 146 países, que trabalham em parceria com

representantes de organizações, de governos, de indústrias, de negócios e de consumidores. A

ISO é uma ponte entre setores públicos e privados.

A palavra ISO não é uma abreviação de International Organization for

Standardization, e sim derivada da palavra grega "isos", que significa “igual”. Igualdade

referindo-se à padronização. Isto evita que cada país crie seu próprio acrônimo baseado na

tradução de seu idioma (ISO, 2005).

As Normas da família ISO 9000 foram desenvolvidas com a finalidade de apoiar a

implementação de SGQs eficazes nas organizações, que apresentem uma estrutura baseada em

processos e produtos, independentemente de seus tipos ou tamanhos (NBR ISO 9000, 2000). No

52

Brasil, a ISO é representada pela ABNT – Associação Brasileira de Normas Técnicas (ABNT,

2005) – fundada em 1940. A ABNT é o órgão responsável pela normalização técnica no país,

fornecendo a base necessária ao desenvolvimento tecnológico brasileiro. A Norma ISO 9000 é

adotada pela ABNT com o nome NBR ISO 9000.

3.3.2.1 A Aplicação da ISO 9001:2000

As ISO 9000 e ISO 9001 foram elaboradas para orientar as organizações na implementação

eficaz de seu Sistema de Gerenciamento da Qualidade (SGQ). A partir da implementação desse

sistema, cujo foco é a garantia da qualidade, a empresa estará preparada para tratar com maior

agilidade e eficácia a ocorrência de problemas e satisfazer as expectativas de seus clientes. A

organização obtém benefícios mensuráveis nos processos que envolvem os requisitos da norma,

pois inicialmente já apresenta melhoria em suas atividades, atitudes com seus clientes e na

comunicação interna (MELLO, 2002). A qualidade vai sendo complementada, em seus processos e

produtos, por uma ação de melhoria contínua em todas as áreas da organização (PRESSMAN,

2001).

A ISO 9000 define os fundamentos e o vocabulário que envolvem e definem o SGQ. Para a

gerência e o controle de uma organização, a alta direção tem de ter uma visão sistêmica de todos os

processos e atividades, identificando os pontos de influência e de alcance de toda a estrutura

organizacional, envolvendo de forma integral clientes e fornecedores nos processos institucionais.

Para um fortalecimento da estrutura organizacional, devem-se considerar os tradicionais clientes

externos, mas também os clientes internos à organização, como usuários e mesmo outros processos

que integram em uma seqüência de entradas e saídas. Em apoio a essas necessidades a ISO 9000

identifica oito princípios para a gestão da qualidade (NBR ISO 9000, 2000; MELLO, 2002;

MUTAFELIJA, 2003):

• Foco no Cliente: o cliente deve ser um dos maiores focos da organização. A

organização tem de propiciar a ela própria condições de entender as necessidades, as

expectativas e os requisitos do cliente. A gerência do relacionamento com o cliente trata

a comunicação para medir sua satisfação e atuar nos resultados obtidos tanto em caso

positivo, quanto em caso de insatisfações.

• Liderança: estabelece uma unidade de propósitos e um envolvimento na direção dos

objetivos da organização, traduzindo a visão da organização em objetivos e metas

mensuráveis.

53

• Envolvimento das pessoas: a integração das potencialidades e habilidades individuais

acaba por criar um clima de crescimento pessoal, que se reflete no crescimento

organizacional.

• Abordagem de processo: a identificação do processo facilmente leva à identificação de

responsabilidades, entradas, saídas, medições, clientes e fornecedores internos e

externos e visibilidade para o gerenciamento.

• Abordagem sistêmica para a gestão: a identificação e a compreensão dos inter-

relacionamentos dos processos permitem o gerenciamento mais adequado das macro-

necessidades e dos recursos compartilhados por toda a estrutura organizacional.

• Melhoria contínua: este princípio é a mola mestra para o crescimento da organização. A

estrutura inicial pode até ser pequena, mas já deve apresentar as características de uma

abordagem crescente em complexidade e abrangência. A melhoria contínua deve-se

refletir nos produtos, processos e sistemas da organização.

• Abordagem factual para a toma de decisão: a tomada de decisão deve ser baseada

na análise de dados e informações levantados por métodos adequados.

• Benefícios mútuos nas relações com os fornecedores: a interdependência entre a

organização e seus fornecedores deve agregar valor a seus processos e produtos

mutamente.

No seguinte trecho transcrito desta norma tem-se outro enfoque nos processos:

Para que as organizações funcionem de forma eficaz, elas têm que identificar e gerenciar

processos interrelacionados e interativos. Freqüentemente, a saída de um processo resultará

diretamente na entrada do processo seguinte. A identificação sistemática e a gestão dos

processos empregados na organização e, particularmente, as interações entre tais processos são

conhecidos como ‘abordagem de processos’.

O SGQ de uma empresa possui um conjunto de diretrizes, que permite a seus clientes

avaliarem a capacidade dessa organização em fornecer produtos e serviços, que atendam os

requisitos especificados de forma consistente, fornecendo ainda uma estrutura para melhoria

contínua do desempenho da organização.

A aplicação eficiente da ISO 9001:2000 (a Norma) (NBR ISO 9001,2000) possibilita à

organização amadurecer suas atividades, pois disponibiliza discussões que envolvem todas

suas estruturas e atividades. O SGQ representa um subsistema do sistema de gestão

organizacional e tem como foco alcançar resultados em relação aos objetivos da qualidade,

54

para satisfazer às necessidades, expectativas e requisitos dos seus clientes. Segundo a ISO

9000:2000, os objetivos da qualidade complementam e se integram perfeitamente aos outros

objetivos da organização, tais como: os relacionados ao crescimento, à busca de recursos, à

lucratividade, ao meio ambiente e à segurança de clientes, fornecedores e colaboradores.

3.3.2.2 Pontos Chaves da Aplicação da ISO 9001:2000

A doutrina da família ISO 9000 não exige a definição de regras e modelos rígidos ou

alguma padronização dos SGQs para serem implementados pelas organizações. A idéia da

abordagem é que se faça uma linha de atuação que respeite os princípios da qualidade e siga

um roteiro de orientação “do que fazer” e não “de como fazer”. De acordo com a ISO

9000:2000, a política da qualidade em uma organização fornece uma base para estabelecer e

analisar criticamente os objetivos da qualidade. A política da qualidade e os objetivos da

qualidade são estabelecidos para proporcionar um foco nos rumos da organização. Ambos

determinam os resultados desejados e auxiliam a organização na aplicação de seus recursos

para alcançar esses resultados.

A organização deve aplicar sua política da qualidade para evidenciar o

comprometimento da alta direção para com a qualidade. Deve estar adequada aos propósitos

da organização, ser verdadeira e refletir os valores da empresa para todos os clientes,

funcionários e demais interessados.

Uma empresa que deseja certificar seu SGQ segundo a ISO 9001 (2000) deverá

considerar as seguintes questões:

Conhecer e demonstrar sua capacidade em entender e atender os requisitos dos

clientes;

Planejar e documentar todas as atividades que afetam a qualidade;

Qualificar pessoas nas competências necessárias à realização de tarefas;

Identificar e disponibilizar recursos materiais e humanos necessários para manter o

sistema da qualidade;

Registrar a execução das atividades;

Prevenir as não-conformidades e, se ocorrerem, devem ser registradas e tratadas;

Identificar os processos críticos para a satisfação dos clientes;

Manter um programa contínuo de avaliação do desempenho do sistema.

55

A ISO 9001:2000 deve ser entendida como sendo um caminho mínimo a ser seguido para a

implantação de seu SGQ da forma mais adequada à realidade da organização, levando em conta a

cultura organizacional, o mercado, seus recursos, seus produtos e processos internos.

3.3.2.3 A Estrutura da ISO 9001:2000

A ISO 9001:2000 define o SGQ como um conjunto de processos inter-relacionados e

interativos. Os processos e seus relacionamentos estão dispostos em nove seções, em que as quatro

primeiras (0 – Introdução, 1 – Objetivo, 2 – Referência normativa, e 3 – Termos e definições)

descrevem a abordagem e o alcance do SGQ. Objetivos juntamente com termos e definições são

usados no decorrer do documento. As cinco últimas seções mostram os aspectos normativos a

serem aplicados e avaliados em uma eventual certificação. Essa norma possui também dois anexos

informativos: um que mostra os relacionamentos entre as NBR ISO 9001:2000 e NBR ISO

14001:1996, e outro mostra a correspondência entre as versões de 1994 e 2000 da NBR ISO 9001.

A estrutura que realmente começa a detalhar o SGQ inicia-se na seção 4 – Sistema de

Gestão da Qualidade – que explicita a necessidade de implementação de um SGQ. A seção 5

– Responsabilidade da Direção – apresenta as responsabilidades aos executivos da

organização e o envolvimento direto nos processos de análise e de melhoria. A seção 6 –

Gestão de Recursos – evidencia o papel da alta direção para a garantia da implementação,

manutenção e melhoria do SGQ através de recursos necessários. A seção 7 – Realização do

Produto – oferece as estruturas necessárias para as operações que envolvem o ciclo de vida do

produto. A seção 8 – Medição, Análise e Controle – assegura que, ao ser implantada, a

organização tem acesso a dados e informações, que garantem o desempenho da organização.

Através dos requisitos de entrada, tem-se o levantamento do que o cliente espera do

produto, ou seja, suas necessidades e expectativas, as quais servirão de entrada para a seção 7

– Realização do Produto. O produto é o resultado de um processo. A direção da organização

deve fornecer recursos necessários para o gerenciamento do sistema de qualidade, deve

assegurar o foco nos requisitos do cliente, e que os processos apropriados sejam

implementados para atingir os objetivos da qualidade. Além de analisar criticamente o SGQ,

verificando a pertinência, a adequação, a eficácia e a eficiência desse sistema, no que diz

respeito à política da qualidade da empresa, aumentando desta forma a probabilidade de

melhorar a satisfação dos clientes.

Observa-se que tanto na entrada como na saída da realização do produto existe o

cliente. O foco de atenção dos processos está no cliente, tem-se a obrigação de ouvi-lo

56

sempre, pois a melhoria do SGQ envolve a realimentação das informações do cliente, onde é

verificado se o produto atende ou não aos requisitos de entrada definidos por ele. É nesta

seção que o processo de desenvolvimento de software vai ser diretamente inserido, mas é

também neste momento, pelo o fato de ser apropriada a qualquer tipo de organização, que a

Norma ISO 9001:2000 apresenta-se com uma abordagem genérica e com maior necessidade

de tratar as características que envolvem tecnicamente a produção de software.

Na seção 7, também é encontrada a descrição do maior volume de processo de toda a

norma. Entretanto, nela não é requerido nenhum daqueles procedimentos obrigatórios. A

justificativa é simples: as operações para a Realização do produto devem seguir a orientação

da norma, mas têm que ser adaptados à realidade de cada organização e seu produto, como

também às características e especificidades das empresas de software – daí a necessidade da

adaptação.

A Figura 3.5 representa uma visão do SGQ aplicado à norma ISO 9001:2000 e suas

seções (NBR ISO 9001,2000; MELLO, 2002; MUTAFELIJA, 2003). As seções da ISO

9001:2000 e seus subitens encontram-se relacionadas no Apêndice III.

Figura 3.5 – Modelo de um SGQ baseado em processo (NBR ISO 9001,2000)

3.3.2.4 A Aplicação da Estrutura da ISO 9001:2000

Par ter o SGQ estabelecido em conformidade com a ISO 9001, a organização deve (NBR

ISO 9001, 2000):

57

• Identificar os processos necessários para o SGQ e sua aplicação por toda a organização.

• Determinar a seqüência e a interação desses processos.

• Determinar critérios e métodos necessários, para assegurar que a operação e o controle

desses processos sejam eficazes.

• Assegurar a disponibilidade de recursos e informações necessárias, para apoiar a

operação e o monitoramento desses processos.

• Monitorar, medir e analisar esses processos.

• Implementar ações necessárias, para atingir os resultados planejados e a melhoria

contínua desses processos.

A documentação do SGQ deve incluir: declarações documentadas da Política da Qualidade

e dos Objetivos da Qualidade, do Manual da Qualidade, os Procedimentos Documentados, outros

documentos necessários à organização e Registros Requeridos pela norma.

A Norma recomenda que, para um gerenciamento eficaz, a melhor forma de atender aos

requisitos é a criação de procedimentos documentados. Os procedimentos são formas especificadas

para desenvolver uma atividade. Segundo a ISO 9001 (2000), “o termo ‘procedimento

documentado’ aparecer nesta norma, significa que o procedimento é estabelecido, documentado,

implementado e mantido”. Sendo assim, ela exige apenas a elaboração de seis procedimentos

descritos na Tabela 3.1 abaixo.

Tabela 3.1 – Procedimentos obrigatórios pela ISO 9001:2000 (NBR ISO 9001, 2000)

58

A existência de procedimentos, instruções e registros de trabalho formalizam

todas as atividades que afetam a qualidade. Isto exige a participação de todos os

indivíduos da organização. Portanto, a conscientização para com a qualidade aumenta,

uma vez que todos participam diretamente da implementação do sistema da qualidade,

pois são os principais responsáveis pelas atividades da empresa.

Para Mello (2002), um trabalho de adequação à ISO 9001 verifica primeiro se

existe uma política da qualidade definida pela Alta Administração e um sistema da

qualidade documentado, pelo qual essa política é implementada. A seguir, deve ser

verificado se tanto a política como o sistema estão entendidos e implementados em

todos os níveis da empresa. Deve ser verificado também se existem regras e

procedimentos formalizados para todos os processos da empresa. Se não existem, a

empresa deve defini-los, começando pelos obrigatórios. Se existem, deve ser

evidenciada que essas regras e procedimentos, uma vez definidos pela empresa, estão

sendo efetivamente seguidos. O manual da qualidade representa o SGQ em atividade na

organização e precisa refletir a total consciência das responsabilidades e requisitos

exigidos pela norma.

3.3.2.5 Considerações

É evidente que a abordagem da ISO 9001:2000 provoca uma visão sistêmica de

toda a organização. A alta direção deve retornar sua atenção para todos os seus

processos e atividades organizacionais e de desenvolvimento. A definição da Política da

Qualidade deve ser formalizada e tem de estar de acordo com os objetivos da

organização. Neste momento é discutido o destino da organização, sua missão, sua visão

de futuro, seus objetivos, suas metas, seus prazos, os responsáveis e os indicadores que

levam a um acompanhamento contínuo e controlado.

A aplicação dos preceitos e padrões desta norma pode ser validada pela

certificação oficial envolvendo uma terceira organização, registrada e autorizada para

esse fim, que constata a adequação à ISO 9001:2000 e a conformidade do que foi

planejado esteja sendo efetivamente cumprido. O processo de certificação é contínuo,

pois um terceiro envolvido, uma empresa certificadora, anualmente faz nova auditoria de

adequação e conformidade e, principalmente, de melhoria e evolução dos processos da

organização, tanto os que estão diretamente ligados à produção, quanto aos que dão

apoio e indiretamente estão ligados ao produto. Esta norma associa a qualidade do

produto à qualidade de todos os processos da organização.

59

3.3.3 As Linhas Traçadas pela ISO/IEC 12207

O conhecimento e a aplicação de ciclo de vida de software, de padrões de

programação, de padrões de gerências, de padrões de qualidade, de rotinas de testes, de

análises, de planejamentos, de acompanhamentos, de reuniões, de treinamentos, negociações e

entregas é uma realidade, quer estejam formalizados, completos ou sendo feitos de modo

informal ou sem os devidos controles. A ISO/IEC 12207 auxilia neste contexto.

3.3.3.1 A Percepção da ISO/IEC 12207 pela ISO/IEC 15271

Conforme o Relatório Técnico NBR ISO/IEC 12571/2000 – Tecnologia de

Informação – Guia para ISO/IEC NBR 12207 – Processos de Ciclo de Vida de Software

(NBR ISO 15271, 2000) “um sistema é uma combinação específica de processos de negócios,

hardware, software, operações manuais e recursos”, e ainda: “o software poderia estar

residente em um computador, fazer parte de um firmware ou integrado a um item de

hardware. Em qualquer caso, os processos de aquisição, fornecimento, desenvolvimento,

operação ou manutenção do software necessitam estar em concordância e harmonia com os do

sistema”. A Figura 3.6 ilustra esta integração.

Figura 3.6 – Visão do Software no sistema (NBR ISO/IEC 15271, 2000)

A filosofia da NBR ISO/IEC 12207 recomenda uma forma disciplinada e mais

rigorosa para o desenvolvimento e a manutenção de software, tentando reverter a imaturidade

que a disciplina de engenharia de software ainda tem em relação a outras áreas já tradicionais

da engenharia (MACHADO, 1998). Seguindo esta abordagem adotaram-se fortes vínculos

com o ambiente de engenharia de sistemas.

O Relatório Técnico NBR ISO/IEC 15271, “apóia a aplicação da NBR ISO/IEC

12207, quando utilizada como documento de requisitos e/ou modelo de orientação” e “deveria

60

ser entendido em sua totalidade, embora possa ser utilizado em situações particulares através

de referências às cláusulas específicas”.

3.3.3.2 Os Macro-processos da ISO/IEC 12207

A NBR ISO/IEC 12207 – Tecnologia da Informação – Processos de Ciclo de Vida de

Software (NBR ISO/IEC 12207:1998), cuja arquitetura utiliza uma abordagem sistêmica e usa

os conceitos de processos (conjunto de atividades inter-relacionadas, que transforma entradas

em saídas), atividades (engloba a utilização de recursos) e tarefas (expressa na forma de um

requisito, autodeclaração, recomendação ou ação permitida), descreve o ciclo de vida de

software em três macro-processos (Figura 3.7):

• Processos fundamentais: agrupam as partes que integram diretamente a produção

do software, sendo eles: Aquisição, Fornecimento, Desenvolvimento, Operação, e

Manutenção.

• Processos de apoio: os processos de apoio auxiliam outros processos na busca do

sucesso e da qualidade do projeto e são formados por: Documentação, Gerência de

configuração, Garantia da qualidade, Verificação, Validação, Revisão conjunta,

Auditoria, e Resolução de problema.

• Processos organizacionais: envolvem tipicamente políticas e práticas institucionais,

sendo compostos por: Gerência, Infra-estrutura, Treinamento e Melhoria.

Figura 3.7 – Processos de ciclo de vida de software (NBR ISO/IEC 12207, 1998)

61

Cada macro-processo é composto de processos que são compostos de um conjunto de

atividades, que por sua vez são compostas de um conjunto de tarefas. Os processos dessa

norma formam um conjunto abrangente e genérico na sua aplicação. Cada organização pode

selecionar o subconjunto apropriado para suas atividades, podendo adaptar inclusive para

projetos ou aplicações específicos.

3.3.3.3 A Estrutura da ISO/IEC 12207

A estrutura geral da ISO/IEC 12207 está configurada em dois princípios. O primeiro é

a Modularidade que faz com que seus processos comportem-se como módulos que se

distribuem fortemente coesos e fracamente acoplados. Assim, um processo individual é

dedicado a uma única função. Já o segundo princípio, a Responsabilidade, é distribuído para

grupos adequados que atuam no ciclo de vida do software. Desde o início da aplicação de seus

processos, essa norma considera a integração de todas as atividades e a qualidade. Portanto, a

qualidade está presente em todos os momentos do ciclo de vida (SINGH, 1999).

O alcance de sua estrutura também é apropriado para a utilização quando o software é

uma entidade independente, embutida ou integrada a um sistema (conjunto integrado que

consiste em um ou mais processos, hardware, software, recursos e pessoas, capaz de satisfazer

uma necessidade ou um objetivo definido).

Os processos da ISO/IEC 12207 não podem ser considerados como substitutos para

os processos definidos de gerência ou sistematizados para a engenharia de software.

Entretanto, a norma provê um framework com processos, atividades e tarefas relacionados

com o software e que podem ser identificados, planejados e postos em prática (SINGH,

1999).

Além dos três macro-processos, existem, na ISO/IEC 12207, os anexos A – Processo

de adaptação (normativo), e B - Orientação para adaptação (informativo). Prevendo as

variações em políticas e procedimentos organizacionais, métodos e estratégias de aquisição,

tamanho e complexidade dos projetos, requisitos e métodos de desenvolvimento do sistema,

sugere que todas as partes envolvidas nos projeto deveriam ser envolvidas nessa adaptação à

realidade da organização, seguindo regras e relacionamentos definidos (AZEVEDO, 2004).

O Anexo C – Orientações sobre processos e organizações (informativo) apresenta os

processos e seus relacionamentos sob importantes pontos de vista. A Figura 3.8 resume

estas visões.

62

Figura 3.8 – Processos de ciclo de vida de SW: Regras e relacionamentos (NBR ISO/IEC 12207, 1998)

3.3.3.4 As Aplicações da Estrutura da ISO/IEC 12207

Segundo a NBR ISO/IEC 15271 (2000), “a NBR ISO/IEC 12207 estabelece uma forte

ligação entre o sistema como um todo e o software”, e “até certo ponto a NBR ISO/IEC 12207 é

projetada para atuar dentro de um processo de engenharia de sistemas. Quando o software é parte de

um sistema total, o software é isolado do sistema, produzido e reintegrado ao sistema. Quando o

software constitui todo o escopo de interesse, as tarefas em nível de sistema podem ser tratadas

como uma orientação útil”.

Segundo Singh (1999), todos os processos distribuem suas atividades tendo inspiração no

ciclo PDCA (PLAN - Planejar, DO - Fazer, CHECK - Avaliar e ACT - Agir); os macro-processos e

todos seus processos se integram de maneira que os processos de desenvolvimento têm suporte dos

processos de apoio e são influenciados pelos processos organizacionais. A Figura 3.9 representa

essa integração e transmite que uma noção de recursividade, deve ser vista da seguinte forma: o

primeiro bloco contém o macro-processo organizacional; o do meio, os processos normalmente

aplicados em um projeto; e o terceiro, com três processos de apoio (1 – Documentação, 2 –

Gerência de Configuração e 3 – Resolução de Problemas) e o de Adaptação.

63

Na Figura 3.9, a elipse com indicação do sentido horário indica o ciclo PDCA. No bloco do

meio, os “O” no começo e no final do processo são o mesmo ponto. “( I ) V& V” indica

Independente V&V. “QA” é a garantia da qualidade. Dando a noção de recursividade tem-se a

notação “E:n”, que indica a execução de um dos quatro processos do último bloco, “U:n” indica o

uso do processo do último bloco. “T:SUB” significa tarefas de sub-contratação.

Figura 3.9 – Efeito de recursividade dos processos da ISO/IEC 12207 (SINGH, 1999)


A NBR ISO/IEC 12207:1998 é a versão brasileira para ISO/IEC 12207:1995, e o Relatório

Técnico NBR ISO/IEC 15271:2000 corresponde à versão brasileira para o ISO/IEC TR 15271:1998.

A norma internacional ISO/IEC 12207:1995 possui o Amendment-1 de 2002, que foi estudado e

referenciado neste trabalho, e o Amendment-2 de 2004 (trata das aquisições de software), que não

entra no escopo deste trabalho.

A importante complementação promovida pelo Amd 1:2002 à ISO/IEC 12207:1995, foi

influenciada por outras normas como a ISO/IEC 15504 (Information Technology – Process

Assessment), ISO/IEC 15939 (Software Engineering – Software Measurement Process), ISO/IEC

14598 (Product Evaluation) e IEEE 1517 (engenharia de domínio, gerência de ativos e reuso).

64

3.3.4 A Estrutura, os Papeis e as Responsabilidades Organizacionais

A aplicação fundamental da NBR ISO/IEC 12207:1998 neste trabalho foi seu

direcionamento para a organização de software, sua adoção de visões de abrangência e sua

interpretação pelo NBR ISO/IEC 15271:2000, e sua orientação para aplicação em projetos e na

organização com o um todo. Aponta fatores significativos a serem considerados em sua aplicação,

como: os papéis no ciclo de vida, as políticas organizacionais, o ciclo de vida do sistema como um

todo, os modelos de desenvolvimento, os tipos de software produzidos, a documentação, a avaliação

e as características dos projetos (SINGH, 1999).

3.3.4.1 As Realidades Organizacionais

Todos os aspectos que envolvem a estrutura organizacional das MPMEs de desenvolvimento

de software são potencialmente problemáticos. Nas micro-empresas não existem os níveis

hierárquicos e os dirigentes usam a maior parte do tempo nas tarefas operacionais. Nas Pequenas

empresas já há uma necessidade de uma organização administrativa e os dirigentes usam a maior parte

de seu tempo nas tarefas gerenciais; o restante do tempo, usam em tarefas operacionais e de direção.

As médias empresas, já com uma estrutura organizacional em funcionamento mais definida, exigem

dedicação exclusiva da direção em seus papéis e responsabilidades. Apesar destas particularidades

todas têm em comum, segundo Terence (2002), que “a inaptidão, na resolução dos problemas de

organização administrativa, é uma das causas mais freqüentes e graves de dificuldades”.

Baseado em IBGE (2003), PAS (2002), La Rovere (2004), (Silva, 2004) e Mendy (2003), as

especificidades presentes no ambiente das micro, pequenas e médias empresas são em grande parte

relativas aos aspectos administrativos, e em menor grau aos aspectos de aplicação de disciplinas e

conhecimento técnico. A definição da estrutura organizacional, dos papéis, funções e

responsabilidades a serem desempenhados pelos colaboradores, os produtos a serem

disponibilizados pela organização, a forma de acompanhamento de projetos e a definição de todos

os processos aplicados na organização são os maiores desafios de um modelo, pois o equilíbrio

dinâmico de todos esses aspectos se apresenta de forma independente do porte da organização.

3.3.4.2 As Necessidades Organizacionais

A organização precisa definir seu campo de atuação para coordenar todos os seus esforços

nesta direção; é preciso definir o “rumo do barco” para posicionar as velas e aproveitar todos os

ventos. Pois como disse Sêneca: “se num barco não se sabe a que porto se dirigir, nenhum vento lhe

será favorável”.

65

A questão do campo de atuação da organização é claramente alheia aos aspectos

tradicionalmente técnicos do desenvolvimento de software, mas, se não for dada ênfase a essa

questão, a sobrevivência num mercado tão competitivo estará fortemente comprometida.

A proposta de uma abordagem que envolva a área da qualidade é claramente uma alusão a

esta deficiência organizacional presente nas MPMEs de uma maneira geral, mas principalmente nas

de desenvolvimento de software. A qualidade não seria o foco da organização, e sim uma linha

apontando na direção dos objetivos da empresa. Uma linha traçada orienta os esforços ao longo da

organização.

A estrutura organizacional que adotar a qualidade como linha de orientação deve estar apta a

definir suas políticas, seus objetivos e sua missão. Com estes elementos definidos, validados e

entendidos por todos, os esforços e recursos começam a se alinhar e a serem efetivamente utilizados.

A adoção da qualidade pela organização, neste momento, ainda não está vinculada ao seu

aspecto de produção do software. O vínculo está no apoio necessário e envolve, quase que

exclusivamente, os aspectos administrativos e organizacionais. O lado técnico, entretanto, não pode

ser esquecido ou desvalorizado, ele só vai ser incorporado, em um segundo momento, de forma

mais adequada, e depois do amadurecimento destas “atribulações” organizacionais.

3.3.4.3 As Estruturas Organizacionais

Uma vez estabelecidos os rumos a serem seguidos pela organização, é preciso a definição da

estrutura organizacional que consiga guiar a empresa rumo aos seus objetivos. Ao longo do

caminho, a estrutura deve refletir aspectos que envolvam além dos processos de desenvolvimento de

software, os processos administrativos internos à organização e os processos que refletem as

negociações com os clientes e o atendimento de suas necessidades e expectativas.

O porte das MPMEs dificulta a adoção de modelos tradicionais de estruturação

organizacional, sendo muitos deles dispostos em vários níveis hierárquicos de decisão e contendo

diversos papéis. A estrutura ideal depende das características específicas de cada organização e de

seu conjunto de objetivos, recursos e área de atuação. No entanto, conforme Gonçalves (2000), “o

sucesso da gestão por processos está ligado ao esforço de minimizar a subdivisão dos processos

empresariais”. Isto é uma dificuldade a mais que se encontra à frente da organização: a de definir

apropriadamente os processos organizacionais.

Gonçalves (2000) pronuncia-se: “entender como funcionam os processos e quais são os

tipos existentes é importante para determinar como devem ser gerenciados para a obtenção do

66

máximo resultado”. A estrutura organizacional deve ter então um mínimo de processos que

consigam salvaguardar sua existência, e garantir a cobertura de todas suas atividades.

Gonçalves (2000) cita uma classificação geral de processos para uma organização:

• Processos de negócio: ligados à essência do funcionamento da organização e se

identificam tipicamente com a empresa.

• Processos organizacionais: são essenciais para a gestão do negócio; geralmente

apresentam resultados imperceptíveis aos clientes externos.

• Processos gerenciais: dão suporte aos processos de negócio.

A Adequação da estrutura organizacional não deixa de ser uma atividade administrativa que,

como já mencionado, não está nas grandes aptidões das MPMEs de desenvolvimento de software.

A linguagem e o ambiente puramente administrativo podem-se tornar um problema para a adoção

desses conceitos. Mesmo com essa classificação geral dos processos abordada, ainda se pode

identificar a organização de software com pelo menos três grandes áreas de atividades: (i)

desenvolvimento do software; (ii) administrativa; (iii) comercial. Há a necessidade premente de

indicar na organização quem vai encabeçar e levar à diante esta discussão sobre a estruturação da

própria organização.

3.3.4.4 As Responsabilidades Organizacionais

A definição de uma estrutura organizacional tem como conseqüência imposta à definição de

tarefas, papéis a serem desempenhados e suas responsabilidades e, da mesma forma, quem está

qualificado para assumir tais papéis, ou como fazer para capacitar quem não atende às exigências

dos papéis.

A organização, uma vez tendo seus objetivos, recursos e processos definidos, precisa definir

os papéis que devem dar apoio à sua estrutura. Uma vez mais, aparecem as limitações das MPMEs,

onde não existem recursos disponíveis para a grande variedade de atividades, tarefas e

responsabilidades, com as quais se envolve.

Uma particularidade das MPMEs de desenvolvimento de software brasileiras (ver detalhes

no Apêndice II) é atuar para a boa formação de sua mão-de-obra. Muitos de seus dirigentes têm

nível de graduação ou de pós-graduação. Os desenvolvedores em geral são estagiários de cursos

universitários e possuem certificações específicas de suas especialidades técnicas. É neste ambiente

de uma boa competência técnica, que a organização precisa também se destacar por seus aspectos

administrativos e organizacionais.

67

Possas (2003) afirma que as organizações devem aproveitar as atualizações tecnológicas

para uma integração maior de seus colaboradores, tanto os desenvolvedores, quanto os usuários.

Enquanto os usuários, conhecedores do negócio, podem contribuir na descrição dos requisitos, os

desenvolvedores também podem dar sua contribuição, pois podem facilitar e estimular o

aparecimento de novos pensamentos entre os usuários da organização. Segundo este autor, as

características e atividades de todos os colaboradores da organização podem ser compartilhadas,

entre elas ter-se-ia: ações de delegar e assumir responsabilidades, tomar iniciativa, enfrentar

situações, mobilizar recursos humanos, estar preparado para mudanças e transformações,

comunicar-se e negociar. A contribuição da formação técnica dos desenvolvedores dar-se-ia pela

sua faculdade de analisar, planejar e propor modificações e adaptações continuamente, quer pela

atuação em projetos e sistemas, quer pela própria característica de alterações constantes dos padrões

tecnológicos.

A criação de grupos de trabalho é uma alternativa aos limites organizacionais das MPMEs.

Um grupo, segundo Fiorini (1998), “é uma coleção de departamentos, gerentes e pessoas, que têm

responsabilidades por um conjunto de tarefas ou atividade”. Não existem limites para a formação

dos grupos nas organizações. O mesmo autor relata que pelo menos dez grupos de trabalho são

mencionados no CMM: Grupo de Engenharia de Software, Grupos Relacionados a Software, Grupo

de Processos de Engenharia de Software (SEPG), Grupo de Engenharia de Sistemas, Grupo de

Teste de Sistemas, Grupo de Garantia da Qualidade de Software (SQA), Grupo de Gerência de

Configuração de Software, Grupo de Treinamento, Outros Grupos de Engenharia, e Grupo dos

Envolvidos. Um grupo pode ser formado pela associação de outros grupos.


O grupo da qualidade (SQA) e o grupe de processos (SEPG) para a uma organização de

software é de grande importância; porém, novamente sobressai-se o estigma da falta de recursos.

Uma solução seria o acúmulo de papéis e de funções pelos colaboradores da organização, ou a

criação de grupos institucionais (externos à organização) que poderiam apoiar as atividades da

equipe do projeto ou produto, de forma independente. Uma estrutura organizacional adequada a

estas possibilidades deveria ser vinculada às necessidades e ao desempenho da própria organização.

A aproximação dos conhecimentos técnicos aos conhecimentos administrativos e

organizacionais deve acontecer de forma planejada e não de forma aleatória. A inexperiência

administrativa das MPMEs de desenvolvimento de software deve dar espaço à adoção de modelos

que apontem para a estruturação de processos, não só da área de desenvolvimento, mas para todas

as atividades da organização.

68


É somente no contexto da união dos três pontos de vista, disciplinar, fisiológico e

organizacional, no entendimento das necessidades de cada organização e no conhecimento das

limitações de cada organização é que a adoção de um modelo terá sucesso na sua aplicação. A

abordagem de processos antevê a presença do Sistema de Gestão da Qualidade (SGQ) integrando

toda a estrutura organizacional em busca da qualidade.

A definição dos processos organizacionais é meta obrigatória e tem como conseqüência a

apresentação do caminho para a adoção da estrutura organizacional, e do suporte necessário para o

funcionamento integrado de todas as atividades ligadas à produção do software, ou não.

3.4 A Montagem da Proposta

Schulmeyer (1999), quando aborda os princípios da qualidade elaborados por gurus como:

W. Edwards Demming, Joseph Juran, Kaoru Ishikawa, Ioji Akao, Philip Crosby, Shigeo Shingo

entre outros, e a revolução causada no mundo da economia por esses conceitos e princípios da

qualidade, fornece uma visão geral de como estes conceitos poderiam ser usados na indústria de

software. A qualidade não seria apenas “slogan ou objetivos arbitrários” e passaria a ser um meio de

melhoria real aplicada através de “estudos e ações sistemáticas”.

Sommerville (2003) ao se referir à ISO 9000:2000 apresenta-a como “um padrão

internacional, que pode ser utilizado para o desenvolvimento de um sistema de gerenciamento da

qualidade em todas as indústrias”. Ele ainda comenta que “A ISO 9001 é o mais geral dos padrões e

se aplica a organizações que se preocupam com o processo de qualidade de empresas que projetam,

desenvolvem e fazem manutenção de produtos.”

É precisamente o modelo de um Sistema de Gestão da Qualidade (SGQ) que se pretende

adotar e adaptar às necessidades e aos recursos das MPMEs no contexto brasileiro, implantando a

semente da qualidade e incorporando a cultura da qualidade, para que a organização possa melhorar

seus processos de forma contínua e escalonável. Inicialmente, requisitos mínimos serão atendidos,

mas em uma ação contínua de melhoria e do próprio amadurecimento dos processos, a organização

poderá planejar com eficiência sua trajetória de crescimento e a melhoria de seus processos

produtivos.

O modelo de SGQ para MPMEs proposto para empresas de desenvolvimento de software

neste trabalho está baseado no Sistema de Gestão da Qualidade da ISO 9001:2000. Ao final de sua

implantação, esse modelo pode ser integralmente validado, uma vez que existe o processo de

69

certificação oficial, quando é o SGQ da organização está em conformidade com a ISO 9001:2000 e

é executado, registrado e mantido em adequação a seus próprios preceitos.

No capítulo 2, foi apresentado o motivo da não adoção das instruções da norma ISO/IEC

90003:2004, que descreve justamente um SGQ em conformidade com a ISO 9001:2000 para

empresas de software. Uma das características desse modelo é a aproximação das atividades

administrativas no ambiente fortemente preenchido pelas atividades técnicas das MPMEs de

desenvolvimento de software.

O modelo de SQG proposto também se apóia fortemente na ISO/IEC 12207, utilizando seus

macro-processos (organizacionais, de desenvolvimento, e de apoio), como fundamento para a

criação de uma estrutura organizacional mínima exigida para o funcionamento da organização.

Outros elementos, já discutidos anteriormente, também estão presentes na linha de montagem do

modelo proposto: o grupo SEPG, o SQA (adaptado).

Segundo Schulmeyer (1999), várias companhias estão adotando o conceito de SEPG, pois

nele reside o ponto focal para a adoção e a avaliação de metodologias e processos. Na ausência

deste grupo na organização, o SGQ deve assumir suas responsabilidades e manter o esforço de

coordenar as atividades inerentes ao SGQ e às atividades ligadas ao SEPG. A adoção de processos

cria a necessidade de uma estrutura que defina-os, avalie-os, adapte-os, treine e implante-os de

forma que essas atividades se apresentem não de forma linear, mas de forma cíclica, e com a

possibilidade de aperfeiçoamento contínuo. Pela escassez de recursos na MPMEs, os conceitos de

grupos institucionais é parte integrante do modelo de SGQ proposto.

3.5 Considerações

O modelo de SQG proposto pode auxiliar as MPMEs em suas dificuldades administrativas

pela integração das normas ISO 9001:2000 e ISO/IEC 12207. Neste sentido, as atividades e tarefas

descritas no dia-a-dia das MPMEs de desenvolvimento de software, levarão seus colaboradores a

identificarem suas responsabilidades, em seus processos formalizados e documentados.

Esse modelo foi implementado com sucesso em duas empresas de pequeno porte, tendo sido

elaborado um roteiro comum, e seguido integralmente em ambas as empresas, que foram

certificadas pela ISO 9001 no prazo de doze meses, conforme apresentado no capítulo 4.

70

CAPÍTULO 4 UM MODELO DE SISTEMA DE GESTÃO DA QUALIDADE

PARA MPMEs

“Embora eu não acredite que uma planta possa nascer onde nada foi semeado, tenho muita fé na semente. Convença-me de que colocou ali uma semente, e eu estarei preparado para esperar maravilhas.”

Henry D. Thoreau

4.1 O Ambiente do Modelo

O modelo de Sistema de Gestão da Qualidade (SGQ) proposto para Micro, Pequenas e

Médias empresas (MPMEs) de desenvolvimento de software (no contexto brasileiro) está

fundamentado na ISO 9001 (2000), no que se refere a questões administrativas e

organizacionais, e na ISO/IEC 12207 (1995), no que tange a estruturação dos processos de

software. Outro aspecto importante na utilização da ISO/IEC 12207 foi a sua interpretação

pela ISO/IEC 15271 (2000), dando grande ênfase ao processo de adaptação às necessidades

da organização, com a liberdade de incluir novos processos ou suprimir algum dos propostos

na norma. Para a adaptação do SGQ à realidade das MPMEs, este trabalho baseou-se também

em Machado (1998), Singh (1999), Orci (2000), Qing e Wang (2000), Chao Li (2001), Paulk

(2003), Azevedo (2004a), Azevedo (2004b) e Pollice (2004). A aplicação do SGQ posposto

enseja na certificação oficial ISO 9001.

As MPMEs, em especial as de desenvolvimento de software, enfrentam algumas

dificuldades, destacando-se: (i) tomada de decisão intuitiva; (ii) poucos aspectos e planos

formalizados e documentados; (iii) dificuldade na comunicação; (iv) obstáculos na

distribuição de tarefas e responsabilidades; (v) empecilhos em encontrar e manter

colaboradores qualificados; (vi) pouca experiência e imaturidade administrativa e comercial;

(vii) absorção de tarefas técnicas pela alta direção; e (viii) estimativas deficitárias de prazos e

custos dos produtos. (Detalhadas e referenciadas no Apêndice II)

Destacam-se também algumas facilidades, como: (i) flexibilidade e rapidez de se

adequar às demandas do mercado; (ii) destreza na adaptação às mudanças tecnológicas; (iii)

estrutura organizacional simples e leve; (iv) propensão em se tornar um campo de treinamento

e formação de mão-de-obra especializada.

4.2 O Foco do Modelo do SGQ

O foco maior do SGQ para MPMEs é a obtenção da certificação ISO 9001. Além disso,

objetiva fazer uso das facilidades e vantagens decorrentes do porte deste tipo de organização e

71

do dinamismo associado à sua cultura de superação de dificuldades, e montar uma estrutura

voltada para a melhoria de seus produtos e processos. Isto permitirá à empresa, à medida de

seu amadurecimento organizacional, auto avaliar-se e poder evoluir, objetivando manter sua

certificação ISO 9001.

O SGQ visando centralizar as ações referentes à qualidade de processos e de produtos,

como também o atendimento das necessidades de seus clientes, deve ser discutido e adotado

pela alta direção da empresa.

A implantação do SGQ proposto deve ser realizada a partir dos 3 macro-processos da

ISO/IEC 12207, que servem como um tripé para as atividades das MPMEs de

desenvolvimento de software; Macro-processo Fundamental, Macro-processo Organizacional,

e Macro-processo de Apoio.

A estrutura dos macro-processos atende aos requisitos da ISO 9001 e reflete uma visão

sistêmica da empresa de software e de suas rotinas de produção e administrativas. Com isto, as

atividades e as tarefas descritas no cotidiano da empresa levarão seus colaboradores a identificarem

e situarem suas responsabilidades em seus vários processos formalizados. A aplicação da ISO 9001

a partir da ISO/IEC 12207 apoia-se essencialmente nessa identificação, levando a adequação da ISO

9001 ao perfil técnico das MPMEs de desenvolvimento de software.

Portanto, os requisitos para a certificação ISO 9001 foram enquadrados nos processos

de ciclo de vida do software, além de outros procedimentos importantes e necessários que

devem ser gerados, observando as necessidades e interesses da organização, como será

apresentado ao longo deste capítulo.

O planejamento da Qualidade deve ser realizado a partir das diretrizes determinadas

pela direção da empresa na política da qualidade e deve ser conectado com os objetivos para

qualidade. Nesse planejamento, devem ser levados em consideração os requisitos de gestão

da qualidade e a implementação de melhorias contínuas necessárias para atender à política da

qualidade, manter a integridade e o caráter evolutivo do SGQ. Essas melhorias serão

operacionalizadas mediante a implementação de mudanças no SGQ, de forma a mantê-lo

permanentemente atualizado e em consonância com os requisitos especificados por padrões e

modelos, que possam ser medidos e validados, além de estarem em harmonia com as

necessidades e os anseios dos clientes da organização.

As atividades que influenciam direta ou indiretamente a qualidade dos processos ou

produtos devem ser descritas de forma estruturada em Procedimentos e Tutoriais, que serão

72

utilizados para assegurar a correta realização das mesmas e o atendimento aos requisitos

especificados. Essa estrutura inclui atividades de verificação e de controle da qualidade nas

diversas etapas dos processos organizacionais, de apoio e de desenvolvimento, as quais serão

realizadas de forma planejada e obedecendo a requisitos e instruções definidas nos

procedimentos documentados do SGQ.

O SGQ deve ser mantido atualizado e sua eficácia dever ser melhorada de forma

contínua, de acordo com o estabelecido na Política da Qualidade e pelas diretrizes básicas da

alta administração. Suas características devem estar descritas em procedimentos

documentados, os quais devem ser elaborados de forma a descrever a metodologia de

realização das atividades relacionadas com a qualidade de processos e produtos.

A estrutura do SGQ para MPMEs é composta pelos seguintes tipos de documentos:

• Legais: documentos que englobam informações que fazem parte da estrutura legal

das atividades da organização. Por exemplo: leis, decretos, e portarias.

• Normalizadores: documentos que transcrevem os processos, obrigatórios ou

necessários, e que devem ser integrados entre si. Por exemplo: procedimentos.

• Operacionais: documentos que elaborados para serem seguidos por usuários e

colaboradores em forma de guias ou exemplos, que facilitem o entendimento,

orientem e garantam o fluxo das atividades e informações. Por exemplo: tutoriais.

• Tipo formulário: documentos que dão suporte ao registro de dados e devem ser

preenchidos quando foram realizadas atividades específicas. Por exemplo:

formulários, modelos.

• Registros: documentos que confirmam a ocorrência de um procedimento, um

processo, uma atividade ou uma tarefa, quando assim for estabelecido.

• Manual da Qualidade: documento central do SGQ, que registra suas atividades, a

descrição do escopo da certificação, e eventuais exclusões de pontos da ISO 9001

que não foram contemplados pela organização. Deve incluir também: as políticas da

qualidade, referências aos procedimentos documentados usados nas diferentes

atividades relacionadas com os processos administrativos e produtivos, e a descrição

da interação entre os processos do SGQ.

No SGQ de uma MPME, devem existir pelo menos 6 procedimentos documentados,

que são considerados procedimentos obrigatórios pela ISO 9001 e que fazem parte do Macro-

73

processo de Apoio. São eles:

• Procedimento de Controle de Documentos: define a metodologia para controle de

documentos do SGQ.

• Procedimento de Controle de Registros do SGQ: apresenta a metodologia para

identificar, armazenar, proteger, recuperar, reter, e descartar os registros do SGQ.

• Procedimento para Auditorias Internas da Qualidade: descreve a metodologia

utilizada para realização de auditorias internas do SGQ e estabelece os critérios para

qualificação de auditores internos da qualidade.

• Procedimento de Controle de Produto não-conforme: controla o produto não-

conforme. Um produto é considerado não-conforme, quando não atende a um ou

mais dos requisitos especificados. Os requisitos especificados podem pertencer ao

próprio produto, ao processo ou às atividades correlatas que geram ou tem relação

com o mesmo, bem como ao resultado esperado de um serviço.

• Procedimento para Ação Corretiva: delineia a metodologia para definição e

implementação de ações corretivas em qualquer etapa dos processos, produtos ou

em atividades relacionadas com os mesmos.

• Procedimento de Ação Preventiva: relata a metodologia para definição e

implementação de ações preventivas em qualquer etapa dos processos, produtos ou

em atividades relacionadas com os mesmos. As ações preventivas visam eliminar as

causas de não-conformidade potencial, ou seja, aquela não-conformidade que não

aconteceu, mas foi identificada.

Apesar de não serem obrigatórios pela ISO 9001, no SGQ proposto para MPMEs de

desenvolvimento de software devem existir também outros procedimentos documentados, que são

os considerados procedimentos necessários, pois complementam o controle da qualidade e

influenciam na distribuição de tarefas e responsabilidades, criando um conjunto integrado e

sistêmico. Os procedimentos necessários são distribuídos nos três macro-processos propostos a

partir da ISO/IEC 12207.

Constituindo o Macro-processo Organizacional têm-se os:

• Procedimento de Segurança: descreve o processo utilizado para o controle e

segurança dos dados da empresa.

74

• Procedimento de Responsabilidades da Direção: delineia as responsabilidades da

direção referentes ao processo de análise crítica do sistema da qualidade e

determinação do foco de atenção da empresa no cliente.

• Procedimento para Qualificação de Fornecedores: apresenta a metodologia para

avaliar e qualificar os fornecedores da empresa. A qualificação dos fornecedores é

realizada com base na capacidade de fornecer produtos/serviços de acordo com os

requisitos especificados.

• Procedimento para Qualificação Profissional: relata os papéis, as responsabilidades

e a qualificação profissional dos colaboradores, incluindo a composição da estrutura

organizacional da empresa.

Para o Macro-processo de Apoio têm-se os:

• Procedimento para descrição do SGQ: detalha o SGQ da empresa.

O Macro-processo Fundamental é formado pelo:

• Procedimento de Desenvolvimento de Sistemas: descreve a metodologia utilizada

para controle do processo de desenvolvimento de sistemas da empresa, segundo os

requisitos de controle da ISO 9001 e a rastreabilidade do produto.

Os procedimentos determinam (ou fazem referência), quando necessário, à utilização da

estrutura documental do SGQ. A responsabilidade pela gestão dos processos descritos nos

procedimentos documentados está definida no próprio corpo de cada documento, exceto no caso de

formulários, onde isto não é requerido. Quando necessária, a implementação dos documentos do

SGQ é precedida de treinamento das funções envolvidas, de forma a garantir a correta interpretação

e aplicação dos requisitos especificados. A Figura 4.1 representa o SGQ proposto, integrando os

Macro-processos da ISO/IEC 12207, as seções da ISO 9001 e uma estrutura hierárquica baseada

nos níveis estratégicos, tático-gerenciais e operacionais da organização.

75

Figura 4.1: Relação do SGQ x Nível de decisão x Macro-processos x seções ISO 9001 (2000)

76

4.3 O roteiro para a implantação do SGQ

O roteiro para implantação do SGQ e a sua posterior certificação estão divididos em um

conjunto de atividades desenvolvidas pelos envolvidos no processo. Antes mesmo de começar

as atividades propriamente ditas, a empresa deve montar a equipe de trabalho que deve

constar de um consultor (com experiência em certificação do SGQ em conformidade com a

ISO 9001), e de um profissional de seu quadro, que tenha conhecimento em gerência de

projetos e em processos, para ser o Representante da Diretoria (RD) da organização (papel

exigido oficialmente pela norma ISO 9001).

A Tabela 4.1 descreve o regime de trabalho da equipe responsável pela implantação e

certificação do SGQ com duas possibilidades para a sua criação. Independentemente do tipo

de equipe adotado, há o Grupo Interno (GI) da equipe de implantação formado por membros

efetivos da organização.

Tabela 4.1: Descrição da equipe de implantação do SGQ

Equipe Componentes Atividades Carga horária Consultor ISO 9001

Treinamento, Coordenação de reuniões, e Auditorias

1 dia por semana (6 horas)

Representante da Diretoria (RD)

Estudo da organização Elaboração, implantação e documentação dos novos processos

5 dias por semana (4 horas)

Tipo 1 Grupo interno

Estagiário Implantação e documentação dos processos


Consultor ISO 9001 Treinamento e Auditorias 1 dia por semana

(6 horas) Tipo 2

Grupo interno

Representante da Diretoria (RD)

Estudo da organização Elaboração, implantação e documentação dos novos processos


A maioria das atividades utilizadas no processo de implantação e certificação ISO 9001

(2000) enquadra-se em uma das seções desta norma (Figura 4.2); as que não se enquadram

foram adotadas como atividades complementares, embora necessárias. As seções da ISO 9001

são brevemente descritas a seguir:

• Sistema de Gestão da Qualidade (seção 4): estabelecimento, documentação e

implementação de um sistema de qualidade, descrevendo a necessidade dos

processos serem conhecidos e documentados.

77

• Responsabilidade da Direção (seção 5): integra a Alta Administração no próprio

processo de implantação do SGQ, validando e adotando, perante todos os

colaboradores, o processo da Qualidade.

• Gestão de Recursos (seção 6): apresenta os recursos disponíveis e necessários à

prática da qualidade.

• Realização do Produto (seção 7): mostra a implementação do produto à luz dos

procedimentos e requisitos do cliente.

• Medição, Análise e Melhoria (seção 8): descreve o processo de medição, análise e

melhoria, podendo retornar a qualquer das etapas de implantação.

Desta maneira, o processo de implantação do SGQ baseado na ISO/IEC 12207 segue a

ISO 9001 e usa suas atividades de medição, análise e melhoria (seção 8), para ajustar outras

atividades. A atividade de Responsabilidade da Direção assegura a validade e o alcance das

propostas e reafirma o apoio necessário a todo o processo.

Figura 4.2: Relação das atividades de implantação do SGQ conforme as seções da ISO 9001:2000

A seguir será apresentado o roteiro de implantação do SGQ com a descrição, as

finalidades, os envolvidos, os resultados esperados e algumas considerações sobre cada

atividade. A ordem desta apresentação não reflete a forma da execução das atividades, uma

vez que existem atividades que são executadas em paralelo. A Tabela 4.2 apresenta as 26

atividades propostas para a implantação do SGQ para MPMEs.

Tabela 4.2: Atividades de implantação do SGQ

ATIVIDADES ENTRADAS SAÍDAS N (*)

ENV (*)

A) Abertura dos trabalhos Prazos, RD, Estrutura do SGQ P GI,

D, C

B) Levantamento geral de processos e produtos

Checklist de levantamento geral

Levantamento Geral, Identificação de lideranças

4 GII, C

78

C) Estudo da ISO 9000 e ISO 9001 ISO 9000 e ISO 9001 Formação de auditores

internos P GI

D) Estudo da ISO/IEC 12207e ISO/IEC 15271

ISO/IEC 12207 e ISO/IEC 15271

Corpo de conhecimento evolutivo P GII

E) Estudo dos processos Levantamento geral

Mapas de processos versus Procedimentos da ISO 9001 necessários e obrigatórios

4 GII

F) Estudo dos produtos de software Levantamento geral

Mapa de produtos versus Procedimentos ISO 9001 necessários e obrigatórios

4 GII

G) Definição da Política da Qualidade Estrutura do SGQ Política da Qualidade,

escopo do SGQ 5 GI, D

H) Definição dos Objetivos da Qualidade

Política da qualidade, escopo do SGQ

Missão, visão de futuro, objetivos, metas, ações, prazos, responsáveis e indicadores

5 GI, D

I) Identificação de processos na ótica de Normas, Política e Objetivos da Qualidade

Mapa de processos, política e objetivos da qualidade

Mapa de processos atualizados 4 GI

J) Elaboração de procedimentos obrigatórios

Mapa de processos atualizados, Template Procedimento

Procedimentos obrigatórios (Tabela 4.6) 4 GI

K) Implantação dos procedimentos obrigatórios

Procedimentos obrigatórios gerados

Validação dos procedimentos 4 GI, C

L) Elaboração dos procedimentos não obrigatórios necessários

Mapa de processos atualizados, template de procedimento

Procedimentos necessários (Tabela 4.6) 7 GI

M) Identificação dos registros necessários e implementação dos controles requeridos

Tabela de controle de registros

Tabela de controle de registros preenchida 4 GI

N) Definição e alocação de recursos necessários

Mapa de processos, mapa de produtos Alocação de Recursos 6 GI, D

O) Identificar de funções e dos requisitos de competências necessários

Alocação de recursos Atividades definidas, estrutura organizacional

6 GI, D, C

P) Identificar necessidades de competências nos recursos humanos

Qualificação profissional requerida

Qualificação real encontrada na organização

6 GI, C

Q) Identificação de treinamento necessário Qualificação encontrada Mapa de treinamentos 6 GII,

C R) Verificação da eficácia do treinamento

Indicadores de aproveitamentos

Avaliação de eficácia do treinamento 6 GII

79

S) Implantação dos procedimentos não obrigatórios necessários

Procedimentos necessários Utilização e validação dos procedimentos 7 GII,

C

T) Análise Crítica pela Alta Direção

Resultados, avaliação de eficácia Avaliação do SGQ 5 GI, D

U) Validação e comprometimento da alta direção

Avaliação do SGQ Aprovação do SGQ 5 GI, D

V) Auditorias internas da qualidade

Roteiro de auditoria interna (AI) Relatório de convocação de AI, Relatório de AI, Relatório de não-conformidade

Registros de Auditoria 8 GI, C

W) Processos de Melhoria Avaliação de resultados Ações de melhoria 8 GII X) Ações corretivas e ou preventivas

Avaliação de resultados, e registros de não-conformidades

Ações corretivas e preventivas 8 GI,

D, C Y) Ajustes Finais Resultados Ajustes finais P GI Z) Certificação Oficial ISO 9001

Procedimentos, estrutura completa do SGQ Certificação ISO GI,

D, C LEGENDA N – Seção da ISO 9001:2000 ENV – Envolvidos

P – Proposto GI – Grupo de Implantação GII – Grupo Interno de Implantação

D – Diretoria C – Colaborador

O roteiro para implantação do SGQ possui ao todo 26 atividades. Dessas atividades,

somente três não estão diretamente ligadas aos requisitos solicitados pela ISO 9001, mas que

se adequam ao modelo proposto de um SGQ mais abrangente, envolvendo a gestão da

qualidade de forma evolutiva e integrada à realidade das MPMEs. Neste contexto, o próprio

SGQ “prova” do remédio que recomenda. A Figura 4.3 propõe uma seqüência e duração

relativas às atividades de implantação do SGQ.

80

Figura 4.3: Seqüências e durações relativas das atividades de implantação do SGQ

A seguir, serão apresentadas todas as atividades para a implantação do SGQ.

A) Abertura dos Trabalhos Descrição: É o ponto de partida para o projeto de implantação do SGQ; não é uma atividade

baseada diretamente nas seções da ISO 9001, mas tem ligação com o princípio do

envolvimento das pessoas, que é um dos oito princípios da gestão da qualidade segundo a

norma ISO 9000.

Finalidade: A apresentação da equipe de trabalho e do projeto de implantação de um Sistema

de Gestão da Qualidade e sua posterior certificação vai gerar uma questão de ordem em toda a

empresa. Todos os colaboradores da organização têm de conhecer os benefícios da adoção de

um SGQ e devem estar prontos para colaborar e participar do bom andamento das atividades.

Envolvidos: A equipe de implantação, e a alta direção. É importante que a alta direção faça a

abertura oficial e a apresentação formal da equipe de implantação aos colaboradores da

empresa.

Resultados: A evidência do envolvimento da alta direção, a determinação de prazos, a

81

autoridade dada à equipe de implantação com a formalização do Representante da Diretoria

(RD), o apoio dos colaboradores e a apresentação de lideranças dentro de suas respectivas

atividades, e o estabelecimento de reuniões periódicas.

Considerações: Apesar das expectativas positivas, pode ser criado muito cedo um clima de

ansiedade para a obtenção da Certificação ISO 9001.

B) Levantamento Geral de Processos e Produtos Descrição: Realiza-se a busca e coleta de informações sobre clientes internos e externos,

produtos desenvolvidos para uso próprio, produtos desenvolvidos sob encomenda, processos,

metodologias e padrões usados no desenvolvimento, ferramentas, infra-estrutura e tecnologias

de apoio, a disposição organizacional das atividades, identificando organogramas, papéis e

responsabilidades.

Finalidade: Esta atividade identifica a realidade em que se encontra a empresa no momento da

implantação do SGQ. Com base nas informações coletadas, as próximas atividades do roteiro

a serem executadas podem ser mais complexas ou não.

Envolvidos: Além da participação plena da equipe de implantação, também participam

intensamente todas as lideranças da organização, como a diretoria, os colaboradores mais

experientes, o pessoal do suporte tecnológico e o pessoal encarregado das atividades

administrativas. Vale salientar a importância do uso de um checklist de Levantamento Geral

(Apêndice V) no desempenho desta atividade, que pode até ser um roteiro para auditoria

interna.

Resultados: Integração da equipe de implantação com os colaboradores da organização,

levantamento e mapeamento de locais para pesquisas mais específicas posteriormente,

identificação de pontos fortes e fracos, levantamento aspectos de controles que já existentes e

utilizados regularmente na organização.

Considerações: O levantamento e a análise da situação atual da empresa propiciam uma

estimativa da duração das atividades subseqüentes deste roteiro.

C) Estudo da ISO 9000 e ISO 9001 Descrição: Durante o curso desta atividade é necessário que pelo menos o grupo de

implantação entenda os conceitos envolvidos nas normas ISO 9000 e ISO 9001.

Finalidades: É de fundamental importância esta atividade, pois prepara o grupo para ter uma

visão dos processos organizacionais sob a perspectiva da qualidade, buscando aspectos de

82

controle e registros, verificações e validações, análise crítica dos indicadores e números

gerados.

Envolvidos: Somente o grupo de implantação. O consultor, em primeiro momento, é

responsável por compartilhar sua experiência e interpretação das duas normas ISO. Ele

prepara também o papel obrigatório do Auditor da Qualidade, que pode ser também o RD,

Vale salientar que quem faz parte de um processo não poderá auditá-lo. Pode ser incluído

nesta atividade alguém do desenvolvimento para se capacitar na auditoria das outras

atividades da organização, inclusive o próprio SGQ.

Resultados: Entendimento dos aspectos cobertos pelas duas normas para aplicação e

mapeamento dos processos existentes e na definição de novos processos.

Considerações: O estudo do modelo do SGQ proposto pelas normas prepara o grupo da

qualidade para um entendimento mais efetivo dos processos, situando o grupo no ambiente de

aplicação do SGQ. O enfoque a ser desenvolvido é a identificação e a adequação de rotinas,

processos, metodologias e produtos da empresa à norma.

D) Estudo da ISO/IEC 12207 e ISO/IEC 15271 Descrição: Durante o decorrer da implantação do SGQ é preciso absorver conceitos que

envolvem o ciclo de vida do software. Embora inicialmente não sejam usados todos os

processos, as atividades e as tarefas prescritas na ISO/IEC 12207, a aplicação dos macro-

processos é relevante no SGQ proposto. O estudo da ISO/IEC 15271 durante a implantação

do SGQ pode auxiliar nas interpretações da norma ISO/IEC 12207.

Finalidades: Durante toda a implantação do SGQ, o grupo responsável não poderá perder o

foco técnico do desenvolvimento de software. No processo inicial de preparação e

implantação do SGQ, a evidência principal da aplicação da norma ISO/IEC 12207 é a

classificação dos três Macro-processos envolvidos no ciclo de vida do software, o Macro-

processo Fundamental, o Macro-processo Organizacional e o Macro-processo de Apoio, que

vão receber os processos obrigatórios e os necessários, segundo a norma ISO 9001. A

ISO/IEC 12207, com o Amd 1:2002 e o Amd 2:2004 podem ser consultados. Nesta norma,

destacam-se aspectos como a análise de contratos de aquisição e fornecimento, manutenção e

operação de software, gerência de projeto, e o princípio de melhorias.

Envolvidos: Somente o grupo interno de implantação e os interessados em fazer parte de um

grupo de estudo de processos de desenvolvimento.

Resultados: A evidência da preparação do ambiente do SGQ disposto nos três Macro-processos

83

da ISO/IEC 12207 para abrigar todos os processos a serem adotados. O surgimento da

“semente” de um grupo com as responsabilidades do SEPG (Software Engineering Process

Group).

Considerações: O acoplamento simultâneo dos conceitos envolvidos das quatro normas:

ISO/IEC 12207, o ISO/IEC 15271, a ISO 9001, e ISO 9000, favorece o entendimento da

abrangência do SGQ proposto. Neste contexto, a “semente” estaria sendo plantada e, com seu

amadurecimento e germinação, um SGQ evolutivo estaria se desenvolvendo. Por algum

tempo, no processo de implantação, esses quatro modelos serão suficientes. No entanto, com

o amadurecimento dos processos outros modelos e práticas podem ser incorporados, como por

exemplo: os Amd 1 (2002) e Amd 2 (2004) da ISO/IEC 12207, a ISO/IEC 90003 (2004), a

ISO/IEC 15504 (2003), o PMBOK (2004), a ISO 9004 (2000), o RUP (2003), e a EUP

(Enterprise Unified Proces), que é extensão do RUP.

E) Estudo dos Processos Descrição: Com base no levantamento geral, não somente o processo de software da empresa,

mas todos os processos levantados da empresa vão ser analisados. As atividades C (Estudo da

ISO 9000 e ISO 9001) e D (Estudo da ISO/IEC 12207 e ISO/IEC 15271) estudos das normas

(Atividades C e D) são as linhas mestras para evidenciar os limites e alcances desses processos.

Finalidades: Com um estudo detalhado dos processos da organização, a equipe de

implantação identifica o que já está em conformidade com a norma ISO 9001 (a norma que

vai certificar o SGQ), o que precisa ser adaptado e criado, além dos aspectos organizacionais,

de apoio e de desenvolvimento adotados.

Envolvidos: A equipe de implantação vai percorrer a organização através dos três macro-

processos, alocando colaboradores nestas três frentes de atuação simultâneas, direcionado o

diálogo para os respectivos pontos de atuação. Os colaboradores obtêm uma visão sistêmica

de suas funções, atividades e responsabilidades em relação ao todo e identificam suas

participações no processo de implantação e certificação do SGQ.

Resultados: A equipe de implantação adquire um elevado grau de integração com o grupo de

colaboradores e com as rotinas internas da organização. Um mapa das necessidades de

adequação à luz dos requisitos da ISO 9001 deve ser gerado para orientar diretamente na

elaboração dos procedimentos obrigatórios e necessários. Os processos não devem somente

existir; eles devem funcionar adequadamente e mostrar as evidências de seu uso.

Considerações: Mesmo que haja um processo, ou uma metodologia de desenvolvimento,

84

devem ser evidenciados os pontos de controle preconizados pela norma certificadora (ISO

9001) para o projeto e o desenvolvimento do produto como as entradas, as saídas, a

determinação de requisitos, as análises críticas, a verificação, a validação e o controle de

alterações dos requisitos. Caso não haja processos ou metodologias definidos, um

procedimento de desenvolvimento deve ser criado, documentado e implantado.

F) Estudo dos produtos de software Descrição: Os produtos de software usados pela empresa podem ter sido desenvolvidos

internamente ou adquiridos de terceiros. O estudo desses produtos disponibiliza uma relação

de ferramentas, suas aplicações e suas formas de uso.

Finalidades: O estudo desses produtos pode evidenciar que possíveis controles necessários já

se encontram em conformidade com a ISO 9001, ou que podem ser adequados, ou que devem

ser criados novos produtos para suprir determinadas obrigações.

Envolvidos: A equipe de implantação desenvolve um mapa de produtos usados e o nível de

adequação identificado de cada um. Evidenciar a necessidade de conhecimento das

funcionalidades e dos produtos para a elaboração de um catálogo de produtos, que se podem

transformar até em produtos comercializáveis.

Resultados: A equipe de implantação provoca uma mudança de visão dos colaboradores,

principalmente quanto ao conhecimento dos produtos desenvolvidos pela empresa, gerando um

ambiente de sinergia entre os colaboradores, e fomentando esforços de venda desses produtos.

Considerações: Muitas vezes os produtos desenvolvidos ou adquiridos para serviços internos

da empresa já podem contemplar os controles exigidos pela norma. Por exemplo, uma

ferramenta de controle as versões já poderá contemplar as necessidades de gerência de

configuração. Um software de comunicação no qual o cliente possa entrar em contato com a

empresa e registrar uma solicitação de melhoria do produto ou uma informação de eventuais

erros, isto pode indicar um procedimento para comunicação com o cliente.

G) Definição da Política da Qualidade

Descrição: O processo de definição da Política da Qualidade da empresa baseia-se em

reuniões de discussões entre a equipe de implantação e a alta direção da empresa. Uma

seqüência de reuniões deve ser programada e a política da qualidade da empresa, que passará

por sucessivos refinamentos, será fruto do amadurecimento desse processo.

Finalidades: A definição da política da qualidade da empresa envolve o conhecimento das

capacidades da empresa, suas limitações, ambições e recursos disponíveis. A definição da

85

política da qualidade consiste em efetivamente aceitar o processo de implantação do SGQ,

que deixa de ser algo abstrato, para evidenciar uma realidade palpável. Afirma o compromisso

assumido pela alta direção e evidencia para todos o desejo de melhor controlar e coordenar os

processos da empresa, preparando o escopo do SGQ, explicitado no Manual da Qualidade.

Envolvidos: A experiência do consultor é de grande importância, pois suas vivência e experiência

com processos tradicionalmente organizacionais e administrativos norteiam as discussões. A

diretoria tem participação intensa e é um dos momentos mais delicados da implantação.

Divergências e diferentes abordagens podem e devem surgir, mas um consenso deve prevalecer.

Resultados: É o momento aonde os aspectos técnicos, predominantemente presentes no dia-a-dia

das MPMEs, vêm à tona. Esta talvez, se não for uma das primeiras, com certeza é uma das mais

profundas discussões envolvendo aspectos organizacionais, administrativos e estruturais da

empresa. A identificação de uma realidade mais complexa que o cotidiano técnico promove o

amadurecimento dos envolvidos. O resultado desta atividade é um dos mais importantes, pois é

somente com a definição e a aprovação da política da qualidade, que várias atividades podem

iniciar ou serem efetivamente concluídas. O escopo do SGQ é o foco do processo de certificação,

segundo a ISO 9001, devendo estar explicitamente no Manual da Qualidade e, com o sucesso da

certificação, constará no Certificado Oficial emitido pela organização certificadora.

Considerações: Talvez este momento de discussão da estrutura administrativa e

organizacional da empresa, saindo da envolvente rotina técnica, seja a grande justificativa da

aplicação da ISO 9001 nas empresas. De fato, de uma forma mais ou menos organizada, as

MPMEs têm controle de técnicas de desenvolvimento de software. O que nelas é deficiente,

como evidenciado no Apêndice II, é o domínio de abordagens, e obrigações administrativas e

organizacionais. Mesmo que não seja obrigatório pela ISO 9001, é interessante que a empresa

aproveite esta oportunidade, para definir e registrar sua Missão e Visão de Futuro. Após esta

atividade, definitivamente está semeada a semente da qualidade.

H) Definição dos Objetivos da Qualidade Descrição: Atividade que, após a definição da Política da Qualidade, da Missão, e da Visão de

Futuro da empresa, define os objetivos da qualidade, as metas para atingir esses objetivos, as

ações para cumprimento dessas metas, os responsáveis pelas ações, os prazos, e os indicadores.

Finalidades: Evidenciar que houve uma análise crítica na definição dos objetivos da qualidade e

que estes estão bem integrados à Missão, Visão de Futuro, e Política da Qualidade da empresa.

Envolvidos: A equipe de implantação, mais uma vez pautada na experiência do consultor, deve

86

aproveitar o momento e envolver não somente os aspectos da qualidade, para a definição dos

objetivos, e sim estimular um debate mais amplo que alcance os diversos domínios da organização.

Resultados: A definição de um plano de objetivos que norteie o andamento dos trabalhos da

empresa e que possa ser acompanhado e cobrado principalmente nos registros de ocorrências,

cumprimento de prazos pelos responsáveis e na análise do comportamento dos indicadores,

para efetuar ações corretivas, preventivas ou de melhoria.

Considerações: Mais uma atividade que fortifica os aspectos administrativo-organizacionais e

leva ao amadurecimento das decisões e comportamento da alta direção da empresa. Ao final

dessa atividade e com a aprovação da Política da Qualidade, Missão, Visão de Futuro, Objetivos

da Qualidade, Metas, Ações, Responsáveis, Prazos e Indicadores de acompanhamento, é

necessária a divulgação de tudo isto para todos os colaboradores da empresa.

I) Identificação de Processos na Ótica de Normas, Política e Objetivos da Qualidade. Descrição: Os processos podem ser classificados como obrigatórios, aqueles que estão presentes em

todas as empresas independente de seu porte, e os necessários, aqueles que estabelecem um domínio

no processo produtivo, mas dependem do porte e da abordagem da empresa. Podem ainda estar

relacionado com os três macro-processos (organizacional, fundamental, e apoio).

Finalidades: Em todos os tipos de processos, a Política, os objetivos da Qualidade, a Missão

da empresa, a Visão de Futuro, as metas e as ações estabelecidas vão influenciar na forma e

no conteúdo dos procedimentos.

Envolvidos: A equipe de implantação com base nesta identificação e agora focando nos

Objetivos e Metas da Qualidade, estrutura um esboço dos processos que farão parte do SGQ.

Resultados: Os procedimentos obrigatórios do SGQ cobrem os seis processos exigidos pela ISO

9001: (i) Procedimento de controle de documentos; (ii) Procedimento de controle de registros

do SGQ; (iii) Procedimento para auditorias internas da qualidade; (iv) Procedimento de controle

de produto não-conforme; (v) Procedimento para ação corretiva; e (vi) Procedimento de ação

preventiva. Além dos obrigatórios, os seguintes procedimentos são necessários: (i)

Procedimento de segurança; (ii) Procedimento de Responsabilidades da Direção; (iii)

Procedimento para Qualificação de Fornecedores; (iv) Procedimento para Qualificação

Profissional; (v) Procedimento para descrição do SGQ; (vi) Procedimento de Desenvolvimento

de Sistemas. Vale salientar que os procedimentos que descrevem o SGQ têm que viabilizar os

processos de melhoria contínua do próprio SGQ.

Considerações: A apresentação destes procedimentos que constituem o SGQ é o reflexo da

87

integração dos pontos de vistas de todos os envolvidos na organização.

J) Elaboração de Procedimentos Obrigatórios Descrição: Atividade de montagem dos seis procedimentos exigidos explicitamente pela norma ISO

9001:2000 e representam os fundamentos de controle prognosticados para a gestão da qualidade.

Finalidades: Documentar os processos, todos componentes do Macro-processo de Apoio, para

dá início a uma nova abordagem para a gestão da qualidade, e não apenas voltada para

processos técnicos de desenvolvimento.

Envolvidos: A equipe de implantação com base nos estudos de processos e produtos da

empresa e com os requisitos exigidos pela ISO 9001 estabelece os seis procedimentos

obrigatórios apontando, sempre que possível, onde e como os processos e produtos existentes

se aplicam.

Resultados: Caso existam processos e produtos que tenham aspectos similares aos requisitos

apresentados, a equipe terá poderá montar os procedimentos em harmonia com os elementos

da empresa, que já são de uso e domínio dos colaboradores. No entanto, é necessário

evidenciar os novos aspectos que deverão ser observados e sob que perspectivas. Caso não

existam similaridades, a equipe terá de apresentar os novos procedimentos, validá-los, treinar

todos os envolvidos, evidenciar seu uso e observar a eficácia do treinamento.

Considerações: Esta atividade coloca a equipe de implantação em um processo mais

introspectivo, pois ela se volta para a elaboração de novos procedimentos baseados nas

exigências da ISO 9001 e nos “ativos” da empresa. É interessante, sempre que possível, a

equipe evidenciar os resultados desta atividade, para que não haja uma “quebra” de clima no

processo geral de implantação do SGQ. O Manual da Qualidade deve conter os

procedimentos relacionados com os respectivos processos apresentados.

K) Implantação de Procedimentos Obrigatórios Descrição: É a implantação dos procedimentos obrigatórios elaborados na etapa anterior na

empresa, junto com os colaboradores envolvidos, dos procedimentos.

Finalidades: A implantação no momento subseqüente à elaboração dos procedimentos

obrigatórios agrega um tempo adicional para o amadurecimento e eventuais ajustes que se

façam necessário nesses procedimentos. Essa implantação passa pelo treinamento dos

envolvidos.

Envolvidos: A equipe de implantação pode agendar a implantação e o treinamento dos

88

procedimentos para os envolvidos. Esta última abordagem pode ser mais difícil, pois os

processos estão muito interligados entre si e, ao final da elaboração de um determinado

procedimento, outro pode precisar ser revisado e alterado.

Resultados: Os procedimentos deverão ser absorvidos pelos colaboradores envolvidos, apesar

de todos fazerem parte do Macro-processo de Apoio, que tem como maior usuário o próprio

grupo da qualidade. Os procedimentos de controle de produto não-conforme, ação corretiva e

ação preventiva vão ser comuns a praticamente todos os colaboradores da empresa, pois não

envolvem somente os processos de desenvolvimento. Os procedimentos de Controle de

Documentos, Controle de Registros, e de Auditorias Internas vão ser seguidos basicamente

pelo grupo da qualidade, mas vão percorrer, durante a execução de seus respectivos

processos, todas as atividades dos colaboradores.

Considerações: Os primeiros procedimentos documentados e implantados devem apresentar

coerência e necessitam de sinergia dos colaboradores. Caso isto não aconteça, serão

considerados apenas como aspectos burocráticos necessários para se conseguir a certificação

ISO 9001. Esses procedimentos deverão se traduzir em um apoio efetivo aos aspectos da

gestão da Qualidade.

L) Elaboração dos Procedimentos não obrigatórios Necessários Descrição: Alguns procedimentos são sugeridos pela norma ISO 9001:2000 como

necessários, mas não obrigatórios e que ajudarão na percepção da abrangência do modelo de

SGQ proposto.

Finalidades: Esses procedimentos estão principalmente distribuídos no Macro-processo

Organizacional e robustecem as bases organizacionais que, nas MPMes de software, precisam

ser reforçadas ou implantadas.

Envolvidos: A equipe de implantação reforça os princípios da “semente” do SGQ e ela

própria assume o próprio SGQ. O estudo dos processos e produtos internos oferece grandes

subsídios para a eficiente elaboração de procedimentos, que estejam em conformidade com a

ISO 9001, mas não estejam longe da realidade da organização, pois o dia-a-dia das atividades

e os limitados recursos não permitem desperdícios. Esses procedimentos têm um alcance mais

direto nos colaboradores, que serão usuários dos processos e deverão seguir os procedimentos

implantados.

Resultados: Os processos passam a ter pontos de controle em toda a organização. Funcionam

como uma base para o alicerce organizacional, que começa a se configurar e, ao longo do

89

tempo, consolida-se naturalmente.

Considerações: Estes procedimentos têm a finalidade de captar o perfil da empresa e dar

ciência a todos, inclusive clientes, da capacidade e abrangência de seus processos e produtos.

O Manual da Qualidade deve ser complementado com os procedimentos relacionados com os

processos que constam no SGQ.

M) Identificação dos Registros Necessários e Implementação dos Controles Requeridos Descrição: A ISO 9001 exige como um de seus procedimentos obrigatórios a identificação e

o controle de todos os registros para o funcionamento dos processos e atividades da

organização.

Finalidades: Identificar os requisitos necessários para a implantação do SGQ e implementar

os controles desses requisitos.

Envolvidos: A equipe deve seguir as recomendações da ISO 9001 e pode inicialmente usar

uma matriz de controle de registros até elaborar o procedimento descrevendo o processo.

Resultados: A equipe de implantação experimenta os controles que estão sendo adotados para

a organização, e pode através de análise crítica preparar um procedimento condizente com a

realidade da organização e em conformidade com a norma.

Considerações: Esta atividade passa a fazer parte de um ciclo de melhoria contínua na

organização.

N) Definição e Alocação de Recursos Necessários Descrição: A ISO 9001 recomenda que para um adequado funcionamento dos processos e

atividades do SGQ sejam definidos os recursos necessários e que promovam meios e

ambiente adequados para os colaboradores exercerem suas funções.

Finalidades: A alocação de recursos é uma forma de garantia de sobrevivência do SGQ

durante a vida da organização. Esses recursos não precisam ser necessariamente financeiros,

embora seja coerente que a direção perceba que existe um custo envolvido no processo de

funcionamento do SGQ.

Envolvidos: A equipe de implantação discute com a diretoria que a necessidade de recursos

deve ser justificada e aprovada. Nas MPMEs, geralmente os recursos discutidos e

disponibilizados são de realocação de recursos humanos e adaptações de prazos.

Resultados: A maior parte desta atividade acontece quando é definida a cadeia iniciada pela

política da qualidade: os responsáveis e os prazos são definidos para cada ação

90

preestabelecida. Outros momentos exigem nova análise de definição e alocação de recursos.

O fato de existir esta discussão já é uma evidência do amadurecimento administrativo e do

conhecimento de uma limitação que precisa ser ajustada.

Considerações: As MPMEs têm limitados recursos para investir. O SGQ deve promover a

necessidade de sua existência, mostrando os efeitos positivos do investimento feito e uma

previsão de retorno através dos meios possíveis. A qualidade não pode ser quantificada como

um bem material, mas o SGQ deve evidenciar os ganhos diretos e indiretos na aplicação de

seus princípios.

O) Identificação de Funções e dos Requisitos de Competências Necessários Descrição: Identificar as funções e papéis que existem na empresa e verificar aos olhos da

ISO 9001 uma descrição integrada com os aspectos de capacitação para quem for exercê-los.

A qualificação profissional deve ter informações sobre: educação, treinamento, habilidades e

experiência.

Finalidades: As funções, papéis, responsabilidades e atividades dispostos por toda a

organização definem sua estrutura organizacional e mostram a capacidade de produção e a

amplitude da hierarquia das atividades. Descrever a estrutura e o relacionamento de papéis e

responsabilidades por toda a empresa.

Envolvidos: As limitações de recursos impossibilitam as MPMEs de possuírem uma equipe

com muitos componentes e uma distribuição de inúmeros papéis. O levantamento geral e o

estudo dos processos e produtos possibilitam também o levantamento das características do

ambiente de desenvolvimento de software. Um mapeamento das necessidades e do porte de

projetos e produtos identifica as funções necessárias, ou as mais adequadas, para o bom

atendimento dos compromissos internos e externos que envolvem os negócios da empresa.

Resultados: A equipe de implantação vai propor uma solução para estrutura organizacional a

partir da definição dos papéis definidos, especificando os papéis, responsabilidades e a

qualificação necessária para exercer a função.

Considerações: Outro momento importante para exercer atividades administrativo-

organizacionais, colaborando para o amadurecimento destes princípios nas MPMEs. A

estrutura matricial, o escritório de projetos, os círculos da qualidade, os grupos de trabalho

como o SEPG, podem ser útil na modelagem da estrutura organizacional da empresa, pois

permitem o compartilhamento e a maximização dos recursos. Outros aspectos que podem

nortear esta atividade é a especificação de funções que existem tradicionalmente, mesmo que

91

não existam pessoas em número suficiente para assumi-las com exclusividade, levando ao

acúmulo de funções por certo número de colaboradores. Dependendo da situação ou da etapa

de desenvolvimento, o colaborador pode assumir várias funções em um mesmo projeto ou

funções distintas em projetos diferentes.

P) Identificar Necessidades de Competências nos Recursos Humanos

Descrição: Identificar as competências necessárias para o desempenho das funções que foram

levantadas e aprovadas.

Finalidades: Relacionar os colaboradores com as funções exercidas e verificar se há um

enquadramento adequado da realidade com o esperado para o exercício de cada função.

Envolvidos: A equipe de implantação reavalia a estrutura organizacional, a rede de papéis,

responsabilidades e qualificação, enquadrando os colaboradores em situações reais vividas no

decorrer do exercício de suas atividades de trabalho.

Resultados: Com o relacionamento colaborador x função, a equipe analisa e registra a

necessidade de enquadramento às necessidades da função caso a caso.

Considerações: O confronto de uma realidade levantada e documentada seguida por análises de

desempenhos propicia o surgimento de novas necessidades ou de aperfeiçoamento do quadro de

colaboradores. A comparação da realidade constatada com os indicadores definidos como ideais

indica para empresa o nível de qualificação profissional e caminhos a serem seguidos.

Q) Identificação e Implementar Treinamento Necessário Descrição: Um novo processo ou alterações nos procedimentos existentes precisam ser

seguidos de divulgação e treinamento para os envolvidos deve ser registrado. A divergência

entre as qualificações do colaborador e a função que exerce também prova a necessidade de

treinamento ou outra adequação ao padrão definido.

Finalidades: Fazer com que todos os processos, procedimentos e qualificações propostas pelo

SGQ sejam efetivamente entendidos e executados da maneira como especificado.

Envolvidos: Mapas e escalas de treinamentos podem ser montados e um calendário com a

previsão e escalas podem ser definidas. O treinamento necessário pode envolver tanto uma

estrutura interna quanto externa. Este é um procedimento que se vai refletir em todos os

momentos do SGQ.

Resultados: Os registros dos treinamentos necessários e da capacitação dos colaboradores,

além de serem pontos sujeitos a não-conformidades com a norma, diminuem o risco de

92

qualificação eminente. Grupo qualificado e dentro dos padrões exigidos é um sinal de

controle dos processos e da qualidade final.

Considerações: As MPMEs de desenvolvimento de software detêm como característica uma

forte qualificação técnica; no entanto, este fato que poderia ser levado em conta como

somente positivo, tem como grande revés a alta rotatividade dos colaboradores. Uma estrutura

voltada para uma qualificação rápida e eficiente é recomendada. Além dos procedimentos

sugeridos pela ISO 9001, outros padrões devem existir para o processo de desenvolvimento,

como padrões de codificação, testes, e um ambiente de desenvolvimento integrado com

ferramentas apropriadas. Isto favorece um plano estratégico de treinamento ágil o suficiente

que consiga de maneira rápida e eficiente preparar os colaboradores recém chegados, mesmo

aqueles que não têm ainda experiência.

R) Verificação da Eficácia do Treinamento Descrição: Comprova através de evidências objetivas que um treinamento efetuado teve o

mérito de ser entendido e aplicado em alguma situação real.

Finalidades: Atividades que confirmam a pertinência do treinamento, garante que foi

executado de maneira eficiente e mostra que o colaborador já está pondo em prática o que foi

treinado.

Envolvidos: Atividade que se configura com permanente no SGQ, mantendo-o sob constante

avaliação e verificação.

Resultados: Os resultados neste momento comprovam o entendimento dos processos e

procedimentos implantados e treinados. O SGQ pode ser vinculado com o sucesso do que foi

planejado. Há, com a verificação da eficácia do treinamento, comprovação da adoção do SGQ

pelos colaboradores envolvidos e treinados.

Considerações: Como atividade permanente, a equipe de implantação já consegue efetivar os

processos de verificação da eficácia de uma ação. Alguns dos controles exigidos para o RD da

organização vão sendo aprendidos em paralelo com implantação do SGQ. O ponto culminante

de comprovação de eficácia desta ação é a certificação de uma organização que siga essa

proposta na implantação de seu SGQ.

S) Implantação dos Procedimentos não Obrigatórios Necessários Descrição: Consiste na implantação dos procedimentos necessários, que servirão de base para

envolver o SGQ por todas as atividades da empresa.

93

Finalidades: Com o complemento destes procedimentos, o SGQ assume uma forma mais

abrangente que percorre e integra os três macro-processos, fortalecendo a visão da

organização como uma entidade dependente da eficiência integrada de todos os seus

processos.

Envolvidos: Esta atividade deve ocorrer após a implantação dos procedimentos obrigatórios e

exige experiência na execução e acompanhamento das implantações, treinamentos e análises

críticas pela equipe de implantação. A agenda das implantações deve ser orientada pelos

Macro-processos e seus respectivos procedimentos documentados.

Resultados: Os procedimentos implantados nesta atividade distribuem-se por todas as

atividades da organização e têm alcance principalmente no Macro-processo Organizacional. A

equipe deve ter especial atenção neste momento, pois os aspectos organizacionais são os

pontos sensíveis das MPMEs.

Considerações: Assim como os primeiros procedimentos documentados e implantados devem

apresentar coerência e sinergia dos colaboradores, esses novos procedimentos têm que

traduzir o comportamento organizacional, pois devem refletir “como um espelho” a “cara” da

empresa.

T) Análise Crítica pela Alta Direção Descrição: A Análise Crítica, segundo a norma ISO 9000, é “atividade realizada para

determinar a pertinência, a adequação e a eficácia do que está sendo examinado, para alcançar

os objetivos estabelecidos”. Em todas as questões, a ISO 9001 orienta sempre uma análise

cuidadosa das causas e efeitos das atividades.

Finalidades: Em vários momentos da implantação a Alta Direção da organização valida as

próprias atividades do processo de implantação do SGQ, analisando os efeitos de sua adoção.

Envolvidos: Praticamente todas as atividades anteriores contam com a execução dessa

atividade para validar o processo de implantação.

Resultados: Esta é uma atividade recorrente no processo e direciona os trabalhos dos

integrantes do SGQ e dos colaboradores envolvidos em algum processo de análise crítica.

Considerações: A análise crítica não é uma exclusividade da alta direção. Apenas durante a

implantação do SGQ, a análise crítica feita pela alta direção é a instância mais indicada para

analisar o processo como um todo, validá-lo ou sugerir alterações.

U) Validação e Comprometimento da Alta Direção

94

Descrição: A validação é demonstrar que os resultados de um processo, quando executado,

cumpre com seus propósitos e os anseios do cliente. O processo a ser validado é a

implantação do SGQ e o próprio SGQ, com suas Políticas, Manual da Qualidade,

procedimentos e processos, e o cliente envolvido é exatamente o grupo de representantes da

organização (a alta direção).

Finalidades: Conseguir executar as atividades de validação no próprio processo de

implantação do SGQ.

Envolvidos: Utilizar as recomendações da ISO 9001 no próprio processo de implantação do

SGQ e ter orientações envolvendo a equipe de implantação.

Resultados: demonstrar a todos os colaboradores que a Alta Direção é participante do

processo de implantação do SGQ e aprova sua abordagem.

Considerações: A demonstração da confiança no processo de implantação deve se evoluir

naturalmente para as expectativas de melhoria de todos dos os processos da organização, uma

vez que estarão sendo vislumbrados por um sistema mais abrangente e integrador, pela gestão

da qualidade dos processos da empresa.

V) Auditorias Internas da Qualidade

Descrição: É um dos procedimentos obrigatórios, que analisa os processos implantados.

Finalidades: Avalia se os processos implantados estão em conformidade com a ISO 9001 e se

há adequação aos procedimentos que os regulam. As auditorias internas atuam também

treinando os integrante da equipe de implantação e outros colaboradores na função de

auditores da qualidade.

Envolvidos: As auditorias internas podem ser feitas por integrantes da empresa, devidamente

treinados para esta finalidade, desde que não estejam envolvidos com as atividades auditadas.

Resultados: O resultado da auditoria deve ser um relatório de não-conformidades apontadas,

se existirem, de recomendações, de disposições para correção imediata de alguma não-

conformidade encontrada, ações corretivas, de melhoria e preventivas.

Considerações: Os auditores da qualidade devem ser registrados e estarem devidamente treinados

para assumir esta função, devendo participar de auditoria sobre a supervisão geral do RD.

W) Processos de Melhoria Descrição: Processos de melhoria disparam ações que acrescentem funcionalidades a um

processo ou produto.

95

Finalidades: No processo de implantação do SGQ, esta atividade pode reconduzir a qualquer uma

das anteriores, desde que sejam analisados eventos que despertem a necessidade de melhoria e

adaptação. Essa atividade, não seria resultado de análise de um erro ou de uma não-conformidade.

Envolvidos: Para surgir uma melhoria no processo de implantação do SGQ, é necessário que

o SGQ seja realmente discutido e entendido pela equipe de implantação. Um grande indício

de amadurecimento é evocado.

Resultados: Ações de melhoria são cadastradas e atribuídas a um responsável e prazos são estabelecidos para o atendimento dessa ação.

Considerações: As ações de melhoria não devem ser vinculadas nem a um erro acontecido, ou

de provável acontecimento. As ações de melhoria são evidências de amadurecimento do SGQ.

X) Ações Corretivas e ou Preventivas Descrição: As ações corretivas são ações que devem ser tomadas para a eliminação das causas

de não-conformidades que já ocorreram, enquanto nas ações preventivas a não-conformidade

tem chances em potencial de acontecer.

Finalidades: Tanto as corretivas quanto as preventivas têm a intenção de eliminar as causa da

não-conformidade, reduzindo assim a possibilidade de novas ocorrências. No caso do

processo de implantação do SGQ, é mais uma utilização dos processos da ISO 9001 para a

vivência da equipe de implantação.

Envolvidos: O processo de definir uma ação corretiva ou preventiva não é trivial e é mais um

argumento da utilização da ISO 9001 na perspectiva de propiciar mais referencial de práticas

administrativas às MPMEs em seu processo de amadurecimento de seus controles organizacionais.

Resultados: A existência de um processo de definição das ações corretivas e preventivas.

Após uma análise crítica das causas da não conformidade uma ou mais ações corretivas (ou

preventivas) devem ser estabelecidas, juntamente com prazos, e alocadas a um responsável

que, no devido tempo, informa da efetiva execução daquela ação. Quem analisou e solicitou

uma ação, com o indicativo de sua conclusão, faz a validação da eficácia da ação tomada,

podendo reabri-la ou aprová-la como definitivamente concluída.

Considerações: Estes passos bem seguidos proporcionam uma ampliação da visão de

simplesmente corrigir erros e não-conformidades, passando assim para um patamar de

identificação e atuação nas causas dos erros.

Y) Ajustes Finais Descrição: Uma busca geral nas atividades executadas, listas de pendências, avaliação de

96

desempenhos e registros de auditorias pode sugerir ajustes, acertos ou melhorias no SGQ

antes de sua certificação oficial.

Finalidades: Revisar os passos e analisar criticamente o processo de implantação do SGQ,

identificando oportunidades de melhoria, ajustes, correções ou adaptações.

Envolvidos: Uma análise geral do processo de certificação podendo contar novamente com

todo o grupo de colaboradores e pronunciamento oficial da Alta Direção, mostrando a

adequação do SGQ e sua conformidade com a ISO 9001.

Resultados: Os resultados da evolução do desempenho organizacional podem ainda não ser

sentidos, mas as evidências de evolução e maior integração dos processos são visíveis e

acontecem sob controle análise de desempenho.

Considerações: Com possíveis ajustes a serem feitos, a empresa pode se voltar para a

validação oficial do SGQ em conformidade com a ISO 9001.

Z) Certificação Oficial ISO 9001 Descrição: A ISO 9001:2000 é uma norma que disponibiliza os requisitos de um SGQ. Uma

segunda organização independente deve ser contatada para proceder com o processo de

certificação oficial.

Finalidades: O processo de certificação aprova ou não o SGQ. Aponta pontos fortes e fracos e

ao final pode ou não sugerir a emissão do certificado da organização.

Envolvidos: A escolha do órgão certificador é fruto de negociação e de contrato, que poderá

ter uma pré-auditoria programada, agindo como uma consultoria que dá mais confiança à

implantação. A certificação oficialmente acontece cerca de 15 dias após a pré-auditora.

Resultados: primeiramente como resultado da pré-auditora, ajustes ou sugestões de melhoria

são recomendados. Em seguida a Certificação Oficial se dá após auditoria completa e

especializada. No caso de MPMEs, acontece entre um e dois dias.

Considerações: A Certificação tem validade de três anos. Após o primeiro ano de certificação

há uma Auditoria periódica para garantir que o SGQ, não somente sobreviveu, como evoluiu

e realmente está incorporado ao dia-a-dia da empresa. Como sugestão dos Auditores Oficiais,

um indício de que o SGQ evoluiu, há a percepção de que o número de ações corretivas tende a

ser cada vez menos em relação ao número de ações preventivas e de melhoria. A Certificação

Oficial, validando o SGQ, não é a garantia da colheita de bons frutos, mas, certamente, é a

“semente” da qualidade somente germinando.

97

4.4 Um Modelo para o SGQ de MPMEs

Esta seção do trabalho vai mostrar o SGQ gerado a partir da execução das atividades do

roteiro descrito anteriormente. No entanto, vale salientar que o SGQ resultante da aplicação

do roteiro pode ser adaptado, alterado ou melhorado a qualquer momento, pois podem

influenciar na estrutura do SGQ, a política da qualidade, a missão da empresa e assim por

diante. Esta necessidade é uma realidade e se apresenta de forma dinâmica. A seqüência

disposta a seguir não é uma ordem de implantação e sim o resultado da aplicação do roteiro de

implantação.

4.4.1 O Ambiente Preparado para Receber o SGQ O Sistema de Gestão da Qualidade está, como os demais sistemas de informação da

organização, sujeito a uma estrutura organizacional que dá sustentação a todas as atividades

empresariais, incluindo as atividades de desenvolvimento de software. Essa estrutura é

problemática nas MPMEs, pois existem inúmeras qualificações profissionais que são

necessárias ao longo do processo de desenvolvimento, mas não há tantas pessoas para assumir

integralmente cada uma delas.

Não existe uma maneira única de elaborar a estrutura e os papéis organizacionais na

empresa. O que pode ser elaborado é uma estrutura que seja viável e sustentável com a função

de identificar o mais claramente possível o papel e as responsabilidades de cada um na

organização e como suas atividades se conectam com a realidade funcional da empresa.

O SGQ proposto para MPMEs possui uma estrutura mínima, que pode ser melhorada e

adaptada, e almeja ser um ponto de partida inspirado na ISO/IEC 12207. Essa estrutura

identifica três macro-processos distintos, que servem de base para a estrutura organizacional.

O Macro-processo Fundamental, que inspira a geração de uma área técnica, administrando o

desenvolvimento do software e de produtos, bem como teria ingerência nos aspectos de infra-

estrutura tecnológica. O Macro-processo de Apoio promove a geração de uma área que

suporte as demais áreas (incluído aí o SGQ). O Macro-processo Organizacional guia a

geração da área administrativa com suas atividades relativas a pessoal, a vendas e a finanças,

em outras. Mesmo com essa estrutura mínima desenhada ainda não se tem uma solução para

agrupar as funções mais especializadas da organização.

O cotidiano das MPMEs de desenvolvimento de é cercado por atividades produtivas,

onde as fases de desenvolvimento são bem definidas. Pela escassez de recursos não deve

haver desperdícios, ociosidade, nem desvios ou acúmulos desnecessários de funções. A

98

criação de grupos de especialistas, como o escritório de projetos, os círculos da qualidade e

porque não o escritório da qualidade, poderia abrigar as funções de RD (Representante da

Diretoria) da ISO 9001, auditoria da qualidade, SEPG, entre outras. A figura 4.4 mostra a

proposta de criação de três áreas ou diretorias (inspirados nos três macro-processos) e o do

Grupo de Suporte Institucional.

Figura 4.4: Estrutura organizacional (Diretoria e o GSI)

É neste ambiente de funcionamento que se tem também de definir todos os papéis

necessários para a empresa conseguir satisfazer os requisitos e expectativas do cliente. O SGQ

baseado na ISO 9001 confirma a necessidade de a empresa administrar as funções,

responsabilidade e qualificação de seus colaboradores. Esta obrigação não limita a empresa a

seguir qualquer estrutura profissional, podendo ser usadas funções consagradas pelo mercado,

ou adaptadas de acordo com as necessidades de cada realidade de negócios.

Em geral, as MPMEs têm limitações na quantidade e não necessariamente na qualidade

de pessoal. As funções descritas nos procedimentos de qualificação profissional não implicam

em sua ocupação automática, ou que não haja mais de um colaborador na mesma função ou o

que acontece forma mais comum, que não haja o acúmulo de funções pelos colaboradores. O

controle destas situações deve ser efetivo e transparente para os colaboradores. Aqueles que

acumulam várias funções devem perceber qual o momento certo de atuar como o quê. Isto

fica claro na descrição de papéis, de subordinações, de responsabilidades, e de qualificação e,

mais ainda, na descrição da atuação de cada função nos diversos processos organizacionais.

99

O item qualificação pode-se compor de:

• Educação: indica o nível de escolaridade formal exigido pela função.

• Treinamento: complemento ao conhecimento escolar para o bom exercício da

função.

• Habilidades: são aptidões necessárias àqueles que exercem o papel.

• Experiência: histórico de atuações anteriores em outras funções.

A Tabela 4.3 orienta de forma geral como descrever essas funções, coma as colunas de

papéis, subordinação, responsabilidades e qualificação. Exemplifica com a descrição do papel

do RD.

Tabela 4.3: Informações necessárias para o registro das funções da organização

Papéis Subordinação Responsabilidades Qualificação

RD Diretoria

• Assegurar que os processos do SGQ sejam estabelecidos, implementados e mantidos

• Relatar à alta direção o desempenho do SGQ

• Conscientizar toda a organização sobre os requisitos do cliente

Educação: Nível superior em informática ou administração ou conhecimento equivalente. Treinamento: em Auditora do SGQ, ISO 9001:2000, ISO/IEC 12207 Habilidades: Visão sistêmica, boas relações com usuários e desenvolvedores. Experiência: 5 anos na área de desenvolvimento de sistemas, Gerência de projetos.

Aparentemente este é um controle exagerado e forte indício de burocratização, mas é

necessário lembrar o excesso de informalidade presente nas MPMEs. Com este formalismo a

organização vai estar mais segura ao enfrentar uma situação emergencial ao enfrentar o risco

da contratação inadequada de alguém para determinada função, por exemplo. A preparação de

um plano geral de treinamento também é facilitada ao confrontar a qualificação real dos

colaboradores com a qualificação ideal para as funções que exercem.

4.4.2 Os Pontos Fundamentais do SGQ

Inicialmente, é necessário que a direção tenha plena consciência de suas

responsabilidades e como um de seus primeiros atos no SGQ, formalize e divulgue a

nomeação do RD, “membro da organização que, independente de outras responsabilidades,

deve ter responsabilidade e autoridade para”: (i) comunicar-se diante do cliente e da direção

100

da empresa sobre o SGQ; (ii) assegurar processos do SGQ; e (iii) promover conscientização

dos clientes em toda a organização.

É necessária a existência de alguns pontos de convergência que são pré-requisitos para

orientação na implantação personalizada do SGQ. A ISO 9001 é genérica o suficiente para

promover uma grande gama infinita de perspectivas para a gestão da qualidade. No entanto,

ela tem elementos padrões, que devem existir e respeitar exigências que são motivos

suficientes, caso sejam não atendidas, para invalidar o SGQ. Estes pontos e momento de sua

definição já são importantes para qualquer SGQ, mas no caso das MPMEs, são mais

relevantes ainda, pois é o momento das discussões organizacionais, tão espaçosas em

empresas deste porte, passam a fazer da pauta de atividades. Essa atividade exige um alto

nível de maturidade da organização, pois traça o futuro de todas as outras atividades. Por isso

é uma das tarefas que deve ser executada no roteiro de implantação e não deve ter uma data

especificada para sua conclusão.

Segundo a ISO 9000 (2000), tem-se:

A política da qualidade e os objetivos da qualidade são estabelecidos para proporcionar um foco

para dirigir a organização. Ambos determinam os resultados desejados e auxiliam a organização na

aplicação de seus recursos para alcançar esses resultados. A política da qualidade fornece uma base

para estabelecer e analisar criticamente os objetivos da qualidade. Os objetivos da qualidade

precisam ser consistentes com a política da qualidade e o comprometimento para a melhoria

contínua, e seus resultados precisam ser medidos. O cumprimento dos objetivos da qualidade pode

ter um impacto positivo na qualidade do produto, na eficácia operacional, e no desempenho

financeiro, conduzindo assim à satisfação e confiança das partes interessadas.

Ampliando a ocasião e a responsabilidade da direção em relação aos aspectos

organizacionais, a direção deve incorporar em seus controles e definir a Missão, a Visão de

futuro, a Política da Qualidade e os Objetivos da Qualidade.

Outro ponto norteador das atividades do SQG é o Manual da qualidade, que deve conter

a referência de todos os procedimentos e sua disponibilização na estrutura da ISO 9001. A

Figura 4.5 apresenta a estrutura de um Manual da Qualidade idealizado por um consultor da

família das normas ISO 9000, e integrante da equipe de implantação do SGQ proposto nas

duas empresas, utilizadas como estudo de caso neste trabalho. Este consultor é o Sr. Sérgio

Pisandelli, que permitiu gentilmente a divulgação de seu trabalho.

Segundo um dos auditores da Empresa Certificadora BRTüV, que certificou as duas

empresas de nosso estudo de caso, classificou este Manual de Qualidade como “um modelo que

101

reflete, com eficácia, a integração dos processos da ISO 9001:2000 com os procedimentos

internos da organização e de todas as suas exigências”. Essas exigências são essencialmente: (i)

o escopo do SGQ, juntamente com os itens e justificativas para quaisquer exclusões; (ii) os

procedimentos documentados ou referências a eles; e (iii) a descrição da interação entre os

processos do SGQ.

Figura 4.5: Manual da Qualidade (Pisandelli, 2005)

Mais um ponto de apoio do SGQ é o processo de Melhoria, muito valorizado pela ISO

9001, e fundamental para as práticas adotadas, pois a organização deve ter em mente que o

SGQ sempre deve evoluir. Neste trabalho, o SGQ proposto tem com missão ser adequado

aos padrões da ISO 9001 e obter a certificação oficial desta norma. Paralelamente, adota

outros modelos como a ISO/IEC 12207, que resultará em evoluções e adaptações (Figura

4.6).

102

Figura 4.6: Processo de melhoria e influências para os Padrões Institucionais

Por último, mas não menos importante, tem-se a obrigação de integrar todos os

processos organizacionais com a visão da análise crítica, da verificação, da validação e a

verificação da eficácia das ações a serem adotadas. Isto envolve as disposições (ação para

eliminar uma não-conformidade encontrada), as ações corretivas (para eliminar a causas das

não-conformidades), as ações preventivas (onde as não-conformidades ainda não

aconteceram, mas são potenciais) e as ações de melhoria (ações que são tomadas que não

estão diretamente relacionadas com as não-conformidades).

Antes de indicar o responsável por determinada ação, tarefa, ou atividade é necessário

que sejam analisadas as causas e conseqüências dessas ações. Após o término dessas ações

também é necessária a avaliação da eficácia da ação tomada.

A Figura 4.7 apresenta um modelo genérico que reflete esta relação e mostra que

também a relação com os clientes pode adotar esse princípio.

Figura 4.7: Relacionamento entre as ações, análise crítica e avaliação de eficácia

103

4.4.3 As Linhas para Atuação do SGQ para MPMEs

O SGQ, como todo sistema de informação, tem rotinas de sua própria natureza que

correspondem às tarefas incumbidas para seu controle, atuação e manutenção. Na sua

implantação algumas rotinas são novas e ainda não fazem parte do dia-a-dia da organização.

Para evitar descontrole e padronizar sua execução, os modelos sugerem padrões de atuação na

execução de seus processos criando procedimentos, formulários e outros meios de orientação

prática e de determinação de roteiros a serem seguidos e que não devem se tornar dogmas. A

intenção não é burocratizar e sim dirigir o mais rápido possível os responsáveis ao

cumprimento eficaz de suas atividades.

O SGQ é composto de três grupos de procedimentos o Macro-processo de Apoio, o

Macro-processo Organizacional e o Macro-processo Fundamental. Cada macro-processo

possui uma série de procedimentos. Esses procedimentos, por sua vez, são compostos por um

conjunto de templates, que orientam ou complementam suas execuções. A Tabela 4.5

relaciona o conjunto de templates para o SGQ.

Tabela 4.4: Templates para o SGQ

Template Observação

Manual da Qualidade Apresenta a relação entre os processos da norma e os processos internos. (Apêndice IV)

Política da Qualidade Registra a política da qualidade, a missão da empresa, a visão de futuro e os objetivos da qualidade.

Lista de Fornecedores Qualificados Apresenta a lista de fornecedores aptos a negociarem com a empresa produtos que causem impacto na qualidade da empresa.

Procedimento Geral Modelo para criação de Procedimentos

Ata de Reunião Modelo de ata de reuniões de análise crítica pela diretoria

Pauta mínima de Análise Crítica Modelo de pauta mínima entre um ciclo de auditoria interna

Controle de Registros de Qualidade Controle de registros da qualidade

Checklist para o Levantamento Geral Checklist para o levantamento de informações iniciais da empresa. (Apêndice V)

Roteiro de Auditoria Interna Roteiro para auditoria interna do SGQ Relatório de Comunicação de Auditoria Interna Convoca os envolvidos para auditoria interna.

Relatório de Auditoria Relatório que contem os resultados de Auditoria Interna Relatório de Não-conformidade (RNC)

Caso não haja uma ferramenta adequada para o registro adequado inclusive das ações correspondentes.

Acompanhamento de RNC Caso não haja uma ferramenta adequada para o acompanhamento.

104

4.4.4 Os Procedimentos do SGQ para MPMEs

Os macro-processos com seus respectivos procedimentos estão na Tabela 4.6. A coluna

“Uso” recebe OBR para os procedimentos exigidos pela ISO 9001, e NEC para os

procedimentos necessários. A Coluna MP indica o macro-processo referente a cada

procedimento: MPO – Macro-processo Organizacional, MPA – Macro-processo de Apoio, e

MPF – Macro-processo Fundamental.

Tabela 4.5: Procedimentos do SGQ e seus respectivos artefatos (templates)

MP Procedimento Uso Descrição Apêndice Procedimento de descrição do SGQ NEC Distribui a documentação e descreve a

estrutura documental do SGQ. VI

Procedimento de Controle de Documentos OBR Descreve as obrigações com o controle

de documentos do SGQ. VII

Procedimento de controle de registros do SGQ OBR Descreve o controle de registros do

SGQ. VIII

Procedimento para auditoria interna do SGQ OBR Descreve os processo de auditoria

interna do SGQ. IX

Procedimento de controle de produto não-conforme OBR Descreve as ações a serem tomadas

para o controle adequado. X

MPA

Procedimento para ações corretivas, preventivas e de melhoria

OBR Descreve dois procedimentos obrigatórios e um necessário. XI

MPF Procedimento de Desenvolvimento de Sistemas NEC Descreve os requisitos de controle

necessários para a ISO 9001. XII

Procedimento de Segurança NEC Descreve o processo de acessos controlados e segurança de dados. NGD

Procedimento para qualificação profissional NEC Qualificação profissional. NGD

Plano Estratégico de Treinamento NEC Descreve o plano geral treinamento. NGD

Procedimento de Responsabilidades da Direção NEC Descreve o papel e a responsabilidades

do direção no SGQ. NGD

MPO

Procedimento para Qualificação de Fornecedores NEC

Descreve as ações que afetam a qualidade dos produtos da organização em função dos fornecedores.

NGD

LEGENDA NGD – Não gerado neste trabalho

MP – Macro-processos MPA – Apoio MPF – Fundamentais MPO – Organizacionais

USO – Proposto NEC – Necessário OBR – Obrigatório


Algumas críticas são feitas a alguns aspectos da aplicação da ISO 9001:2000 – o

processo de controle e qualificação de fornecedores é um deles. A crítica maior é que a ISO

9001 burocratiza a organização e promove o acúmulo de documentação desnecessária. Há um

risco de isto acontecer, mas no caso dos fornecedores, a ISO 9001 não prega o excesso de

105

controle. Em uma MPME, geralmente a maioria dos fornecedores é de serviços de

manutenção e de material de expediente. Neste caso, o controle deve ser feito diligentemente

se o produto ou serviço fornecido for diretamente ligado ao que é produzido na empresa. O

cliente não deve ser penalizado pela má qualidade embutida no produto por terceiros.

O SGQ, antes mesmo de ser definitivamente validado pela certificação oficial, pode

promover um “choque administrativo”, quando dentro de suas atribuições típicas promove a

discussão, através de reuniões de análise crítica, para a busca das causas dos problemas, e não

só a solução imediata deles (aspecto gerencial do SGQ). O amadurecimento deste princípio de

análise crítica envolve a substituição de ações corretivas pelas ações preventivas. Para isto, a

organização deve definir uma política de identificação e análise de indicadores que, do início

do processo de implantação até a certificação, pode ainda não existir e muitas vezes pode

resultar em um trabalho desgastante de coleta de inúmeros indicadores, que não transmitem

nada de útil, apenas se torna um consumidor de recursos.

O SGQ já implantado envolve o apoio de três Macro-processos que montam uma

perspectiva da organização e agrupa os processos de maneira que suportem as atividades

empresariais como um todo. O SGQ atuando pelo Macro-processo Organizacional conta com

processos que alcançam as atividades que dão sustentação à organização e aos dois outros

Macro-processos, disponibilizando recursos para a melhor prática de suas funções. Atuando

pelo Macro-processo Fundamental, o SGQ mapeia os processos de desenvolvimento dos

produtos pelos requisitos de controle, como levantamento de requisitos, análise propostas,

verificação e validação e contato com o cliente. O Macro-processo de apoio nitidamente é a

armação do SGQ e agrega os processos que garantem e controlam a qualidade (aspectos

operacionais e gerenciais de atuação do SGQ).

O SGQ com uma abordagem estratégica destaca-se pelo amadurecimento das

abordagens por processos, a busca constante de melhorias e a determinação de criar um clima

favorável de idéias dentro da organização, convocando à participação dos grupos de suporte

institucionais.

4.5. Considerações

No processo de implantação do SGQ para MPMEs, a estrutura organizacional vai-se

alterando devido ao amadurecimento dos conceitos. Nas atividades inicias o SGQ é

interpretado como uma entidade à parte da organização e, como tal, sofre alguma

“incompreensão”, ora por parecer complicar um processo que “já funciona”, ora para

106

“espionar as atividades funcionais”. A verdade é que enquanto o SGQ não for provado no

decorrer do processo, onde o controle em seus níveis mínimos é um grande aliado do processo

como um todo, o SGQ vai ser questionado e posto a prova a todo instante.

Foi relatado no decorrer deste trabalho que a linguagem administrativa da ISO 9001 ao

mesmo tempo aproxima e afasta os envolvidos nas atividades da organização. Aproxima

principalmente a direção da empresa (nas MPMEs, a diretoria têm forte atuação no

desenvolvimento técnico do produto de software), pois muitas vezes sente a necessidade de

ver seus negócios por outras perspectivas – a administrativa e de negócios. Pode afastar os

colaboradores, que desempenham papéis técnicos do processo produtivo, muitas vezes os

“donos do conhecimento”, outras vezes por inexperiência, ou falta de convívio

organizacional.

A introdução da ISO/IEC 12207, neste contexto, tende diminuir o “afastamento” dos

colaboradores da empresa de software, pois reforça a percepção de que o SGQ não tem

somente apelo administrativo, mas está também baseado e totalmente integrado ao ciclo de

vida do software, onde há funções de desenvolvimento, manutenção, operação, negociação,

levantamento de requisitos, de apoio, de gerência, de treinamento e, principalmente, de

melhoria de processos e produto.

Portanto, é necessária a “cumplicidade” de todos os membros na empresa, para que o

SGQ seja desmistificado (não seja o vilão da história) e passe a ser o fator de sinergia entre

todos na organização. Seu papel estará sendo realmente cumprido, quando ele se tornar fonte

de consultas e representar uma espécie de “zona de livre raciocínio”, e área propícia a

discussões sobre todos os processos organizacionais e não somente sobre qualidade.

Uma das principais funções do SGQ é deixar evidente que todos têm o privilégio de participar

de uma ocasião ímpar na empresa: o crescimento do domínio de seus processos, e o seu

amadurecimento. O que deve ser destacado é que a vivência do processo é um legado que vai ficar

com todos os envolvidos. O resultado final da certificação é uma decorrência de tudo isto.

107

CAPÍTULO 5

CONSIDERAÇÕES

“Cada um colhe, exatamente, aquilo que planta”. Adágio popular

5.1 Às Voltas com o Problema

A definição ou adaptação de um modelo não é trivial, deve ser estudado e colocado

defronte à realidade do ambiente (da empresa) e não propor que o ambiente se adapte a ele.

Uma vez adotado um modelo, a empresa não pode deixar de analisar outros modelos, nem

permitir que esse modelo se distancie da realidade de seus negócios e de sua estrutura

organizacional. Isto propicia a busca da melhoria contínua de seus processos.

A realidade do ambiente é apresentada no Apêndice II com a presença marcante das

MPMEs brasileiras no mercado de software. Essas empresas enfrentam graves problemas

neste desafiante e dinâmico mercado competitivo. Um dos problemas mais relevantes é a falta

de maturidade das MPMEs em suas atividades organizacionais. Portanto, a adoção de um

determinado modelo, teria que passar por vários níveis de controle, e ter como foco a

qualidade.

5.2 A Qualidade como Foco das Atenções

A organização precisa ser estruturada para que tenha uma visão abrangente que

permeie seus aspectos de controle, através de um conjunto de processos inter-relacionados;

uma visão de sua capacidade de adequação e de seus aspectos administrativos para que de

forma qualitativa, ágil e eficaz possa reagir aos estímulos do ambiente.

A Figura 5.1 apresenta os relacionamentos dos conceitos da ISO 9000 (2000) e mostra

o alcance da gestão da qualidade. Neste contexto, o planejamento da qualidade e a melhoria

da qualidade poderiam estar no nível estratégico da estrutura organizacional, a garantia da

qualidade estaria em um nível mais gerencial e, finamente, o controle da qualidade estaria

permeando o nível operacional. Assim sendo, o Sistema de Garantia da Qualidade (SGQ)

estaria presente e atuando, portanto, em toda a estrutura de atividades da organização: isto

proporciona as linhas de atuação do SGQ.

108

Figura 5.1: Relacionamento dos conceitos envolvendo a ISO 9000 (2000)

5.3 As Linhas de Atuação do SGQ

Segundo o MCT (2005), existem 561.690 certificados ISO 9001:2000 emitidos no

mundo; no Brasil, há 7.511 certificações válidas. Segundo o INMETRO (2005), no Brasil

existem 33 organizações credenciadas para certificação ISO 9001:2000.

A certificação ISO 9001 para empresas de software pode-se basear na ISO/IEC 90003

(2004), que é um guia para aplicação da ISO 9001:2000 para empresas de software (Apêndice

III). Apesar de a ISO/IEC 90003 (2004) estar em perfeita sintonia com o ambiente de

software, ela se apresenta de forma muito complexa, especialmente para a adoção em MPMEs

de software brasileiras. Isto porque, apesar do grande poder de adaptação dessas MPMEs, de

reação a mudanças, há uma latente imaturidade em sua estrutura organizacional. Daí este

trabalho propôs o SGQ para MPMEs brasileiras baseado na ISO 9001 (2000) e na ISO/IEC

12207 (1998), conforme o capítulo anterior.

O SGQ para MPMEs foi implantação em duas empresas de software em Fortaleza,

Ceará: a SoftExport e a SoftSite, sendo culminado com a certificação ISO 9001 de ambas as

empresas, validando e viabilizando esta proposta. Essas duas empresas permitiram-nos que

seus nomes e os resultados deste trabalho fossem divulgados.

109

5.4 A Aplicação do SGQ para MPMEs

O SGQ para MPMEs foi utilizado no processo de certificação da ISO 9001:2000 em

duas fábricas de software brasileiras, a SoftExport e a SoftSite, ambas dentro da classificação

de pequenas empresas com 21 e 30 colaboradores, respectivamente.

O processo de implantação do SGQ foi muito semelhante nestas duas empresas de

software. As atividades do roteiro de implantação foram seguidas e pequenas diferenças no

tempo de execução foram registradas.

5.4.1 Aplicação do SGQ na SoftExport

A aplicação do SGQ na SoftExport é apresentada nos seguintes itens: (i) o SGQ e a

empresa; (ii) o foco do SGQ; (iii) a aplicação da proposta (iv) o SGQ implantado; e (v)

considerações.

5.4.1.1 O SGQ e a Empresa

O SGQ para MPMEs começou a ser implantado na empresa SoftExport, em abril de 2003 e teve

sua certificação oficial ISO 9001:2000 em abril de 2004. A SoftExport é uma fábrica de software

localizada na cidade de Fortaleza, Ceará, com atuação também nas regiões Sul e Sudeste do País, cujo

principal objetivo é prestação de serviços de desenvolvimento de software, fazendo uso da tecnologia

J2EE. A empresa tinha perspectivas de exportação de software e um planejamento para atingir o mercado

internacional da Europa e Estados Unidos.

Para atingir níveis de confiabilidade, produtividade e qualidade a empresa passou pelo

amadurecimento de seus processos internos, que englobavam, desde metodologias de desenvolvimento,

até programas de qualificação do capital humano.

5.4.1.2 O Foco do SGQ

Visando atingir níveis aceitáveis de produtividade e qualidade, a SoftExport constituiu

um Grupo da qualidade tendo entre seus colaboradores profissionais com mestrado e com

certificados pela SUN, Microsoft, e PMP (Project Management Professional). Os papéis e as

responsabilidades já estavam definidos na empresa e alguns colaboradores acumulavam mais

de uma função. Na época deste estudo de caso, a empresa contava com 22 colaboradores: 1

deles era responsável pelas atividades administrativas e financeiras, e os outros 21 eram

colaboradores envolvidos nos processos de desenvolvimento dos produtos. Desses 21

110

colaboradores, três deles eram diretores da empresa: Um era designer e os demais estavam

envolvidos em atividades de desenvolvimento de software.

Dessa forma, a empresa está enquadrada na classificação de PE (Pequena Empresa). No

início deste projeto de certificação ISO 9001, a empresa já possuía vários processos definidos,

(Tabela 5.1), e outros processos ainda por definir. A empresa também possuía algumas

ferramentas desenvolvidas internamente para controle de comunicação de bugs e andamento

de testes aos desenvolvedores envolvidos com o projeto ou produto.

O grande papel do SGQ era o de centralizar os esforços da Gestão da Qualidade da

empresa, complementando, integrando e criando vínculos entre todos os processos,

colaboradores, produtos e clientes.

Tabela 5.1: Processos e produtos da SoftExport no início do projeto SGQ

Produtos e Processos Descrição

MUSSE

Metodologia Unificada de Desenvolvimento de Software da SoftExport. Adaptação das atividades de desenvolvimento de software baseada nas fases de concepção, elaboração, construção e transição do RUP (Rational Unified Process).

CAFETEIRA Processo de auto-treinamento voltado para colaboradores de todos os níveis no início de suas atividades na empresa.

TESTE Rotina de testes definida para o Analista de Testes, que testava as funcionalidades do produto e validava alterações em comparação com os requisitos do produto.

GUARDIÃO Processo de auditoria interna do uso adequado dos padrões de desenvolvimento adotados pela empresa, como código e banco de dados.

BUG-CENTRAL Ferramenta desenvolvida internamente para registro de erros detectados nos produtos desenvolvidos, comunicação dos responsáveis pela solução e acompanhamento dessas atividades.

FRAMEWORK Biblioteca desenvolvida internamente com práticas testadas e implementadas nos produtos desenvolvidos, possibilitando o aumento de produtividade e alto grau de sucesso no treinamento interno (Cafeteira).

5.4.1.3 A Aplicação da Proposta

A aplicação da proposta do SGQ para MPMEs na SoftExport cumpriu o roteiro de

atividades apresentado na Tabela 4.2. O Grupo de Implantação foi do Tipo 1: um consultor

ISO, o RD e um estagiário (Tabela 4.1).

A aplicação das atividades B (Levantamento geral dos processos e produtos), E

(Estudo dos processos), e F (Estudo dos produtos de software) de implantação do SGQ na

SoftExport está resumida na Tabela 5.1 apresentada anteriormente. A MUSSE (Metodologia

Unificada de Desenvolvimento de Software da SoftExport) foi avaliada e adaptada à ISO

9001:2000. A Tabela 5.2 apresenta as atividades de implementação do SGQ na SoftExport.

111

Tabela 5.2: Atividades de implantação do SGQ na SoftExport

ATIVIDADES DURAÇÃO (Dia)

(A) Abertura dos trabalhos 1 (B) Levantamento geral de processos e produtos 15 (C) Estudo das normas ISO 9000 e ISO 9001 15 (D) Estudo da ISO/IEC 12207 e ISO/IEC 15271 15 (E) Estudo dos processos 35 (F) Estudo dos produtos de software 20 (G) Definição da Política da Qualidade 30 (H) Definição dos Objetivos da Qualidade 30 (I) Identificação de processos na ótica de Normas, Política e Objetivos da Qualidade 10 (J) Elaboração de procedimentos obrigatórios 15 (K) Implantação dos procedimentos obrigatórios 10 (L) Elaboração dos procedimentos não obrigatórios necessários 25 (M) Identificação dos registros necessários e implementação dos controles requeridos 10 (N) Definição e alocação de recursos necessários 10 (O) Identificação de funções e dos requisitos de competências necessários 10 (P) Verificação de necessidades de competências nos recursos humanos 10 (Q) Identificação de treinamento necessário Ao longo (R) Verificação de eficácia do treinamento Ao longo (S) Implantação dos procedimentos não obrigatórios necessários 25 (T) Análise Crítica pela alta direção Ao longo (U) Validação e comprometimento da alta direção Ao longo (V) Auditorias internas da qualidade 3 x 2 dias (W) Processos de Melhoria Ao longo (X) Ações corretivas e ou preventivas 15 (Y) Ajustes finais 10 (Z) A Certificação Oficial ISO 9001 2 x 1dia (8 hs)

A Figura 5.2 mostra o diagrama de atividades da fase de concepção da MUSSE adequado

à ISO 9001.

112

Figura 5.2: MUSSE com os requisitos da ISO 9001:2000

O produto FRAMEWORK, além de tutoriais de ferramentas e os procedimentos do

SGQ, compuseram juntos aos demais modelos o CAFETEIRA, que é um processo de auto-

treinamento da empresa. A Figura 5.3 apresenta o CAFETEIRA para o papel de

desenvolvedores.

O registro de ocorrências e definição de tarefas para os responsáveis do

desenvolvimento era feita através do produto interno BugCentral (Figura 5.4). Esse produto

teve sua utilização ampliada e se tornou um centro geral de ações e comunicação (interna e

com o cliente externo).

113

Figura 5.3: Auto-treinamento CAFETEIRA para os desenvolvedores

Figura 5.4: Ampliação do uso do BugCentral

As atividades C (Estudo das normas ISO 9000 e ISO 9001) e D (Estudo da ISO/IEC

12207 e ISO/IEC 15271) de implantação do SGQ na SoftExport reuniram base suficiente para

a implantação segura e o entendimento da proposta de SGQ. As atividades G (Definição da

Política da Qualidade) e H (Definição dos Objetivos da Qualidade) resultaram em:

114

• Escopo do SGQ: Consultoria, desenvolvimento, implantação, comercialização,

transferência de tecnologia e suporte em sistemas informatizados, alocação de mão-

de-obra especializada e treinamento para qualificação profissional na área de

Análise e Desenvolvimento de Sistemas.

• Política da Qualidade: Promover soluções de Tecnologia da Informação, utilizando

as melhores práticas, com profissionais altamente qualificados, incentivando o

desenvolvimento regional, procurando ultrapassar as fronteiras tecnológicas, para

obter a plena satisfação dos clientes e colaboradores e a melhoria contínua dos

produtos e processos.

• Missão da SoftExport: Ser uma organização de referência no desenvolvimento de

projetos de Tecnologia da Informação.

• Visão de Futuro:

a) Estruturar uma equipe sólida, altamente qualificada e motivada, que permita o

desenvolvimento de soluções de Tecnologia da Informação continuamente melhoradas.

b) Conquistar mercados nacionais e internacionais através de produtos e processos

com padrões de qualidade reconhecidos pela sua excelência.

c) Assegurar rentabilidade dos negócios como forma de garantir a continuidade e

permanente melhoria da organização e da satisfação dos clientes e colaboradores.

d) Obter a satisfação, credibilidade e fidelidade de nossos clientes mediante o

fornecimento de soluções confiáveis e de relacionamentos transparentes e abertos.

e) Obter reconhecimento no mercado de Tecnologia da Informação, como empresa

organizada, moderna e capacitada.

• Objetivos da Qualidade:

a) Estabelecer Programa de Auto-Formação.

b) Estabelecer plano de qualificação profissional.

c) Definir plano de remuneração vinculado ao plano de cargos.

d) Aumentar o nível de qualificação dos colaboradores.

e) Melhorar a consistência do processo de desenvolvimento, minimizando erros e

retrabalho.

f) Conquistar e obter reconhecimento no mercado nacional e internacional.

g) Desenvolver Estratégia Comercial.

115

h) Certificação ISO 9001:2000.

i) Desenvolver Estratégia Financeira.

As atividades I (Identificação de processos na ótica de Normas, Política e Objetivos da

Qualidade), J (Elaboração de procedimentos obrigatórios), e L (Elaboração dos

procedimentos não obrigatórios necessários) geraram o SQ.P* (Sistema da

Qualidade.Procedimento): A (Apoio), O (Organizacional), e F (Fundamental). Na Tabela 5.3,

a coluna ISO especifica a obrigatoriedade ou não pela ISO 9001:2000. O SQ.PA05 engloba

tanto as ações corretivas quanto as ações preventivas em um único documento.

Tabela 5.3: Relação dos procedimentos implantados na SoftExport

Procedimentos ISO Descrição Classificação SQ.PA01 Obr Procedimento de Controle de Documentos Apoio SQ.PA02 Obr Procedimento de Controle de Registros da Qualidade Apoio SQ.PA03 Obr Procedimento para Auditorias Internas Apoio SQ.PA04 Obr Procedimento de Controle de Produto Não-conforme Apoio SQ.PA05 Obr Procedimento para Ações Corretivas, Preventivas e de Melhoria Apoio SQ.PA28 nObr Procedimento de descrição do Sistema de Gestão da Qualidade Apoio SQ.PF20 nObr Procedimento de Projeto e Desenvolvimento de Sistemas Fundamental MUSSE nObr Metodologia Unificada de Desenvolvimento de Software da SE Fundamental SQ.PO21 nObr Procedimento de Segurança Organizacional SQ.PO23 nObr Procedimento de Responsabilidades da Direção Organizacional SQ.PO24 nObr Procedimento para Qualificação de Fornecedores Organizacional SQ.PO27 nObr Procedimento para Qualificação Profissional Organizacional SQ.PO30 nObr Procedimento Estratégico de Qualificação Organizacional SQ.PO31 nObr Procedimento de Treinamento – CAFETEIRA Organizacional

A atividade K (Implantação dos procedimentos obrigatórios) foi a que mais se

apresentou distante do dia-a-dia da empresa. A implantação de procedimentos obrigatórios em

MPMEs necessita de um período razoável de amadurecimento, para que alcance sucesso em

seu processo de implantação.

A atividade M (Identificação dos registros necessários e implementação dos controles

requeridos) foi efetuada a partir do template apresentado no Apêndice V. A atividade N

(Definição e alocação de recursos necessários) contou com a participação efetiva da

diretoria, no levantamento da capacidade, e de recursos e aportes financeiros.

As atividades O (Identificação de funções e dos requisitos de competências

necessários), P (Verificação de necessidades de competências nos recursos humanos), Q

(Identificação de treinamento necessário), e R (Verificação de eficácia do treinamento)

identificaram e definiram papéis responsabilidades (Tabela 5.4) e a estrutura da organização

(Figura 5.5). O papel do RD é exercido também pelo Guardião, cujas responsabilidades se

adicionaram às responsabilidades requeridas pela ISO 9001:2000.

116

Tabela 5.4: Papéis e responsabilidades na SoftExport

PAPÉIS SUBORDI- NAÇÃO

RESPONSABILIDADES QUALIFICAÇÃO

Conselho Diretor

- Analisar oportunidades de negócio; - Validar metodologia de

desenvolvimento; - Administrar conflitos; - Tratar assuntos administrativos; - Análise dos indicadores de qualidade; - Delegação de responsabilidades.

- Formado por quatro diretorias: Executiva, Financeira, Administrativa, e Tecnologia.

Diretor Executivo

Conselho Diretor

- Administrar área comercial; - Propor melhorias nos Code- Conventions;

- Atuar como relações públicas da organização;

- Analisar criticamente Propostas / Contratos.

Educação: superior na área administrativa ou de Informática ou equivalente. Treinamento: procedimentos SE aplicáveis; administração de custos e orçamentos. Habilidades: gerente de negócios; gerente de projetos; Experiência: 5 anos de análise, projeto, desenvolvimento, implantação e manutenção de sistemas; atividades administrativas; atividades financeiras.

Diretor

Administrativo

Conselho Diretor

- Responder pelas atividades administrativas.

Educação: superior na área administrativa ou equivalente. Treinamento: procedimentos SE aplicáveis; administração de custos e orçamentos; administração de RH. Habilidades: gerente de negócios. Experiência: 5 anos de análise, projeto, desenvolvimento, implantação e manutenção de sistemas; atividades administrativas; atividades financeiras.

Diretor Financeiro

Conselho Diretor

- Administrar orçamentos e recursos financeiros.

Educação: superior na área administrativa ou equivalente. Treinamento: procedimentos SE aplicáveis; administração de custos e orçamentos. Habilidades: gerente de negócios. Experiência: 5 anos de análise, projeto, desenvolvimento, implantação e manutenção de sistemas; atividades administrativas; atividades financeiras.

Diretor de Tecnologia

Conselho Diretor

- Administrar infra-estrutura técnica; - Administrar a Política da Qualidade; - Administrar Projetos; - Propor e definir Code-Conventions.

Educação: superior na área de informática ou equivalente. Treinamento: procedimentos SE aplicáveis; administração de dados; administração de redes. Habilidades: gerente de projetos; adaptação em novas atividades; absorção de novas técnicas e tecnologias. Experiência: 5 anos de análise, projeto, desenvolvimento, implantação e manutenção de sistemas; atividades administrativas; atividades de gerência de projetos.

Gerente de Negócios

Diretoria Executiva

- Identificar as necessidades do cliente;

- Avaliar e viabilizar possíveis soluções;

- Definir requisitos iniciais junto ao cliente;

- Fornecer o conhecimento no ramo de negócio para resolver problemas;

- Interagir com empresas externas; - Elaborar propostas / contratos.

Educação: superior na área de informática ou equivalente; Treinamento: procedimentos SE aplicáveis; Habilidades: analista de sistemas; organização; capacidade de negociação; capacidade de decisão; capacidade de gerência equipes; capacidade de resolução de problemas. Experiência: 3 anos de análise, projeto, desenvolvimento, implantação e manutenção de sistemas; uso de ferramentas de gerência de projetos; atividades comerciais.

Gerente de Projetos

Diretoria Técnica

- Planejar e acompanhar o projeto; - Gerenciar prazos, custos e recursos; - Negociar, registrar e divulgar acordos com o cliente;

- Assessorar a equipe no entendimento e atendimento dos requisitos;

- Auxiliar o cliente na condução de testes de aceitação do produto final;

- Coletar indicadores da qualidade.

Educação: superior na área de informática ou equivalente. Treinamento: procedimentos SE aplicáveis; tutoriais institucionais SE aplicáveis. Habilidades: analista de sistemas; capacidade de decisão; organização; capacidade de resolução de problemas práticos; capacidade de gerência equipes. Experiência: 2 anos de análise, projeto, implantação, desenvolvimento e manutenção de sistemas; uso de ferramentas de gerência de projetos; e de modelagem.

Guardião

Diretoria Executiva

- Auditar o cumprimento dos padrões e normas organizacionais;

- Verificar o uso de tutoriais; - Gerenciar o SGQ.

Educação: superior na área de informática ou equivalente. Treinamento: procedimentos SE aplicáveis; tutoriais institucionais SE aplicáveis; Habilidades: raciocínio lógico; organização; controle; disciplina.

117

Experiência: lógica de programação, análise, projeto, desenvolvimento, implantação e manutenção de sistemas; uso de ferramentas para modelagem.

Analista Infra-estrutura.

Diretoria de Tecnologia.

- Dar suporte à infra-estrutura da Empresa (BD, SO, Redes);

- Implantar e administrar rotinas de segurança de dados e informações;

- Preparar estrutura e gerência de manutenção de equipamentos de informática.

Educação: superior na área de engenharia, informática ou equivalente; Treinamento: procedimentos SE aplicáveis; tutoriais institucionais SE aplicáveis Habilidades: interesse em hardware; capacidade de comunicação; capacidade de trabalhar em equipe. Experiência: noções de sistemas operacionais, eletrônica, eletricidade, sistemas de comunicação.

Gerente Administrativo

Diretoria Administrativa.

- Executar as atividades administrativas e de logística; - Selecionar, avaliar, qualificar e acompanhar fornecedores; - Gerenciar recursos humanos; - Avaliar necessidades de treinamento.

Educação: superior na área administrativa ou equivalente. Treinamento: procedimentos SE aplicáveis. Habilidades: utilização dos aplicativos do Office/Internet;. Experiência: prática bancária/Administrativa;

Analista de Negócio

Diretoria Executiva

- Atendimento a clientes; - Prospecção de clientes e de negócios; - Comercialização de produtos e serviços da empresa;

- Acompanhamento pós-venda; - Auxílio na elaboração de propostas / contratos.

Educação: superior na área administrativa, informática ou equivalente. Treinamento: procedimentos SE aplicáveis. Habilidades: técnicas; comercial. Experiência: não requerida.

Analista de Sistemas

Gerente de Projeto

- Gerar modelo de arquitetura; - Gerar modelo de banco de dados; - Gerar modelo de interface; - Gerar modelo de análise do projeto; - Implementar e testar seus próprios modelos.

Educação: superior na área de informática ou equivalente. Treinamento: procedimentos SE aplicáveis; tutoriais Institucionais SE. Habilidades: raciocínio lógico; capacidade de análise, comunicação e concentração; trabalhar em equipe. Experiência: linguagem de programação orientada a objeto; 1 ano de análise, projeto, desenvolvimento, implantação e manutenção de sistemas; uso de ferramentas Case.

Analista de Suporte

Gerente de Projeto

- Realizar implantação de sistemas; - Gerência migrações e integração de dados;

- Dar suporte à infra-estrutura do projeto.

Educação: superior na área de informática, eletricidade, eletrônica ou conhecimento equivalente. Treinamento: procedimentos SE aplicáveis; tutoriais institucionais SE aplicáveis. Habilidades: atenção a detalhes; curiosidade e espírito de pesquisa; visão generalista; Experiência: conhecimento de sistemas operacionais, sistemas de comunicação, eletricidade e eletrônica.

Desenvolvedor Gerente de

Projeto

- Implementar os modelos e documentações geradas pelos analistas de sistemas;

- Implementar os testes das aplicações; - Fazer a automatização dos testes de funcionalidades.

Educação: superior na área de informática ou equivalente. Treinamento: procedimentos SE aplicáveis; tutoriais institucionais SE aplicáveis. Habilidades: raciocínio lógico. Experiência: linguagem de programação orientada a objeto

Web-Designer Gerente de

Projeto

- Entender e implementar as necessidades do projeto no que se - refere a identificação visual, navegação e ergonomia.

Educação: superior na área de informática ou equivalente. Treinamento: procedimentos SE aplicáveis; tutoriais institucionais SE aplicáveis. Habilidades: percepção e harmonia de formas e cores; Experiência: uso de ferramentas de gráficas; desenvolvimento de sites e home pages .

Analista de Testes

Gerente de Projeto

- Realizar teste de unidade e de integração;

- Reportar para a equipe de desenvolvimento as falhas e pendências encontradas.

Educação: superior na área de informática ou equivalente. Treinamento: procedimentos SE aplicáveis; tutoriais institucionais SE aplicáveis. Habilidades: atenção a detalhes Experiência: conhecimento de lógica de programação.

Estagiário / Bolsista

Coordenador da área a qual foi designado

- Auxiliar às funções ou responsáveis pela área designada

Educação: superior na área de informática ou equivalente. Treinamento: procedimentos SE aplicáveis; tutoriais institucionais SE aplicáveis. Habilidades: atenção a detalhes. Experiência: conhecimento de lógica de programação.

118

Legenda: GSI – Grupo de Suporte Institucional, GP – Gerente de Projeto RD – Representante da Diretoria, GUA – Guardião, ADM – Gerente administrativo INF – Analista de Infra-estrutura, Neg – Analista de Negócio, GN – Gerente de negócio

Figura 5.5: Estrutura organizacional da SoftExport

A atividade S (Implantação dos procedimentos não obrigatórios necessários) cobriu

essencialmente os processos técnicos do desenvolvimento de software. Portanto, mais

próximo da rotina diária dos colaboradores e da empresa. Os procedimentos já tinham

maturidade embutida.

As atividades T (Análise Crítica pela alta direção) e U (Validação e comprometimento

da alta direção) foram executadas constantemente ao longo do projeto de implantação do

SGQ. Percebeu-se que a aceitação do projeto pela alta direção é primordial. Durante a

implantação do SGQ até a sua Certificação foram realizadas 13 reuniões registradas em atas e

verificadas pelas auditorias internas e de certificação (Figura 5.6).

A atividade V (Auditorias internas da qualidade) é uma atividade obrigatória pelos

requisitos da ISO 9001 e se aplicou como processo de treinamento para a formação dos

auditores internos. Conforme definido no SP.PA03 a SoftExport usava um intervalo de 4

meses para cada auditoria interna por ano.

119

Figura 5.6: marcação de pauta mínima para reuniões de análise crítica

As atividades W (Processos de Melhoria) e X (Ações corretivas e ou preventivas) que

aconteceram ao longo do processo de implantação validaram e avaliaram os processos no

momento de suas aplicações e implantações, a auditoria interna também propiciou fonte

segura de melhoria e correções.

A atividade Y (Ajustes finais) aconteceu para pequenos acertos nos procedimentos e

processos gerais, oriundos análise da eficácia das ações corretivas, preventivas e de melhoria

aplicadas até então e registradas na ferramenta BugCentral.

A atividade Z (Certificação Oficial ISO 9001) reuniu toda a empresa e foi executada em

um dia completo com a presença de dois auditores, um especialista em software verificando

os processos técnicos que envolviam o desenvolvimento de software e o outro, o auditor

chefe, os processos gerais. Um relatório com pontos fracos e fortes é apresentado e será

utilizado no ano seguinte, na auditoria de acompanhamento, como parâmetro de evolução do

SGQ. Como resultado da auditoria têm-se as seguintes seções do relatório de auditoria:

2 - Strengths, weaknesses, improvement potential(s) 2.1 - Strengths / Pontos fortes • 7.1, 7.3, 7.5.1 2.2 - Weaknesses / Pontos fracos • 5.6.2, 8.4, 8.5, 8.5.3 2.3 - Improvement potential(s) / Oportunidades de Melhoria • Avaliar a possibilidade em otimizar o mapeamento e interação entre os

processos do sistema de gestão da qualidade no que diz respeito ao 7.1 e 7.5.2. • Desenvolver novas fontes para alavancar a tomada de ações preventivas.

120

2.4 – Observation to be considered in the next audit / Observações a serem consideradas na próxima auditoria. - 5.3-b – Evidenciar claramente no texto da política da qualidade o comprometimento com a melhoria contínua da eficácia do sistema de gestão da qualidade. - 5.4.1 – Avaliar a possibilidade em agrupar os quatro primeiros objetivos da qualidade, listados na Matriz de Desdobramento da Política e Objetivos da Qualidade, em um único objetivo direcionado para auto-formação e qualificação dos colaboradores. - 5.6.2 – Caracterizar nos indicadores da qualidade(gráficos) as metas objetivando facilitar a análise da situação evidenciada em relação a expectativa da SoftExport. - 5.6.2 – c- Evidenciar claramente que foram analisados os indicadores de processo e de produto durante a reunião de análise pela alta direção. - 7.2.3 – Extratificar as reclamações de clientes por tipo e volume, criando um indicador da qualidade, e avalia-lo nas reuniões de análise crítica pela alta direção no ítem “Realimentação do Cliente”.

5.4.1.4 O SGQ Implantado

Ao final do processo de implantação do SGQ e de sua aprovação e certificação a

empresa validou a estrutura do SGQ (Figura 5.7), seu Manual da Qualidade (Figura 5.8) e o

escopo da certificação.

121

Figura 5.7: Estrutura do SGQ na SoftExport

122

Figura 5.8: Manual da Qualidade da SoftExport


As atividades que envolveram os processos técnicos foram mais facilmente cumpridas

pelo Grupo Interno de implantação. A falta de experiência nas atividades administrativas

também se refletiu no Grupo Interno embora o consultor tivesse essa experiência. As rotinas

organizacionais que foram implantadas ficaram na responsabilidade de uma só pessoa que já

acumulava várias funções administrativas. As atividades mais envolventes foram as que

relacionaram os processos e produtos existentes na empresa com os requisitos da Norma ISO

9001:2000, pois como resultado geral o SGQ foi implantado sem grandes alterações nas

rotinas e processos que já existiam na empresa.

Com o amadurecimento do SGQ, implantado com a filosofia de auto-evolução, no

decorrer do ano de 2004 estudou-se e implantou-se um processo de gerência de projetos

baseado no PMBOK, representado na Figura 5.9 abaixo e foram criados e implantados novos

procedimentos documentados e templates (Tabela 5.5). Esta experiência de continuidade e

evolução, no entanto, está fora do escopo deste trabalho e deve ser observada como

possibilidade de futuros trabalhos.

123

Tabela 5.5: Matriz passo-a-passo dos processos de Gerência Projetos da SoftExport

Tabela 5.6: Novos documentos implantados após a certificação da SoftExport

Procedimentos ISO Descrição Classificação SQ.PO40 nObr Procedimento de Gerência Integrada de Projetos Organizacional SQ.CL00 nObr Check-List de prospecção Fundamental SQ.CL10 nObr Check-List de alteração de requisitos Fundamental SQ.DP00 nObr Documentação de Iniciação do Projeto Fundamental SQ.DP10 nObr Documento de Especificação Inicial de Requisitos Fundamental SQ.DP11 nObr Contrato de Requisitos Fundamental SQ.DP12 nObr Plano do Projeto Fundamental/Apoio SQ.DP30 nObr Modelo de Cronograma Integrado de Gerência de

Projetos e Desenvolvimento Fundamental/Apoio

SQ.DP40 nObr Plano de Gestão da Qualidade do Projeto Apoio

Os documentos da Tabela 5.5 pertencem ao SGQ, mas têm a seguinte diferenciação: (i)

CL indica checklists, e (ii) DP indica templates que geram documentos para cada projeto

individualmente.

124

5.4.2 Aplicação do SGQ na SoftSite

A aplicação do SGQ na SoftSite também é apresentada nos seguintes itens: (i) o SGQ

e a empresa; (ii) o foco do SGQ; (iii) a aplicação da proposta (iv) o SGQ implantado; e (v)

considerações.

5.4.2.1 O SGQ E A Empresa

O SGQ para MPMEs começou a ser implantado na empresa SoftSite, em abril de 2003 e teve sua

certificação oficial ISO 9001:2000 em maio de 2004. A SoftSite atua no mercado local de Fortaleza

como fábrica de software, e também sendo terceirizada (outsourcing), para prestação de

serviços em desenvolvimento de software e treinamentos.

A empresa possui mão-de-obra especializada, principalmente na linguagem JAVA,

suprindo tanto as necessidades internas de mão-de-obra como formava para o mercado

profissionais com formação adequada e na maioria dos casos com certificações oficiais. Como

fábrica de software, atuava no ambiente WEB, nas plataformas PowerBuilder, J2EE, PHP e

DELPHI. Durante o processo da certificação, a empresa voltou-se exclusivamente para o

ambiente JAVA. Com esta definição de atuação, a organização planejava atuar no mercado

local, nacional e internacional. O escopo da certificação ISO 9001:2000 envolveu todos estes

aspectos.

5.4.2.2 O Foco do SGQ

A atuação no competitivo mercado de outsourcing e a escassez de desenvolvedores no

ambiente JAVA fizeram com que a empresa tivesse que formar profissionais de forma rápida

e confiável. A certificação SUN era o alvo da maioria dos treinamentos disponíveis da

empresa. A função de treinamento era exercida pelo Centro de formação Java (CFJ), uma

divisão administrativa da SoftSite. As ações da empresa concentravam-se, então, no

CFJ/Treinamento, nos clientes de outsourcing e nos clientes da fábrica de software. Essas

ações deveriam estar relacionadas em uma visão integrada, para que fossem conduzidas

adequadamente. O SGQ proposto deveria atender a esta missão de integração.

Papéis e responsabilidades bem como uma estrutura organizacional já havia na

organização. A maturidade técnica estava presente na forma de atuação no mercado e na

conquista de clientes. Alguma maturidade também se observava na própria estrutura física das

125

divisões das atividades. A Figura 5.10 apresenta a estrutura organizacional no início na

implantação do SGQ para MPMEs proposto.

Figura 5.9: Organograma inicial da SoftSite

A empresa tinha na fábrica de software um total de 30 colaboradores. Destes três eram

responsáveis por atividades operacionais administrativas e financeiras (com as atividades que

envolviam o CFJ e outsourcing), e os outros 27 eram colaboradores envolvidos nos processos

de desenvolvimento dos produtos. Destes 27 colaboradores, dois eram também os diretores,

um era designer e os demais estavam envolvidos nas atividades de desenvolvimento de

software (análise, codificação, implantação e manutenção). Assim sendo, a empresa estava

enquadrada na classificação de PE (Pequena Empresa). As atividades do outsourcing

envolviam as necessidades e regras do ambiente do cliente.

A empresa já possuía um processo de desenvolvimento definido e usava ferramentas

para controle de versões, além de um ambiente integrado de desenvolvimento. Ela também

desenvolvia uma biblioteca própria integrada a esse ambiente de desenvolvimento. O

processo de treinamento do CFJ era usado na formação de seus desenvolvedores. A Tabela

5.6 apresenta os processos e produtos inicialmente encontrados na SoftSite.

Tabela 5.7 Processos e produtos inicialmente encontrados na SoftSite

Produtos e Processos Descrição

PDS-SS Processo de Desenvolvimento de Sistemas da SoftSite. Adaptação das atividades de desenvolvimento de software baseada nas fases de concepção, elaboração, construção e transição do RUP (Rational Unified Process).

CFJ Processo de treinamento para qualificar seus colaboradores nas atividades da empresa. O processo era composto de “trilhas”, que definiam módulos para a formação direcionada para as áreas de atuação no mercado.

FRAMEWORK Biblioteca desenvolvida internamente com práticas testadas e implementada em todos os produtos desenvolvidos, possibilitando aumento de produtividade.

126

O grande papel do SGQ era o de centralizar os esforços da Gestão da Qualidade da

empresa, complementando, integrando e criando vínculos entre todos seus processos,

colaboradores, produtos, clientes e as diversas áreas de atuação da SoftSite. Como já era

esperado, as atividades administrativas precisavam também de um enfoque mais adequado e

os aspectos técnicos precisavam ser entendidos e usados por todos.

5.4.2.3 A Aplicação da Proposta

A aplicação da proposta do SGQ para MPMEs na SoftSite cumpriu o roteiro de

atividades apresentado na Tabela 4.2, que foi adaptado na Tabela 5.7. O Grupo de

Implantação foi do Tipo 2: um consultor ISO e o RD como funcionário em tempo integral,

entretanto desempenhando outras atividades administrativas.

Tabela 5.8 Atividades de implantação do SGQ na SoftSite

ATIVIDADES DURAÇÃO (Dia)

(A) Abertura dos trabalhos 1 (B) Levantamento geral de processos e produtos 20 (C) Estudo das normas ISO 9000 e ISO 9001 15 (D) Estudo da ISO/IEC 12207 e ISO/IEC 15271 15 (E) Estudo dos processos 45 (F) Estudo dos produtos de software 40 (G) Definição da Política da Qualidade 30 (H) Definição dos Objetivos da Qualidade 30 (I) Identificação de processos na ótica de Normas, Política e Objetivos da Qualidade 20 (J) Elaboração de procedimentos obrigatórios 15 (K) Implantação dos procedimentos obrigatórios 10 (L) Elaboração dos procedimentos não obrigatórios necessários 35 (M) Identificação dos registros necessários e implementação dos controles requeridos 15 (N) Definição e alocação de recursos necessários 5 (O) Identificação de funções e dos requisitos de competências necessários 5 (P) Verificação de necessidades de competências nos recursos humanos 5 (Q) Identificação de treinamento necessário Ao longo (R) Verificação de eficácia do treinamento Ao longo (S) Implantação dos procedimentos não obrigatórios necessários 25 (T) Análise Crítica pela alta direção Ao longo (U) Validação e comprometimento da alta direção Ao longo (V) Auditorias internas da qualidade 3 x 2 dias (W) Processos de Melhoria Ao longo (X) Ações corretivas e ou preventivas 15 (Y) Ajustes finais 15 (Z) A Certificação Oficial ISO 9001 2 x 1dia (8 hs)

A aplicação da atividade A (Abertura dos trabalhos) possibilitou à equipe e aos

participantes da empresa entender e adotar o modelo de implantação do SGQ proposto. Os

127

trabalhos foram acompanhados principalmente pelo consultor ISO, e os resultados foram

observados e colhidos pelo autor da proposta.

A aplicação das atividades B (Levantamento geral dos processos e produtos), E (Estudo

dos processos) e (iii) F (Estudo dos produtos de software) usados pela empresa está resumida

na Tabela 5.6. O PDS-SS foi avaliado e adaptado para evidenciar os requisitos sugeridos pela

ISO 9001:2000. A Figura 5.11 mostra o diagrama de atividades do PDS-SS baseado nas fases

do RUP já adequado à norma ISO 9001:2000.

Figura 5.10: PDS-SS com os requisitos da ISO 9001:2000

A comunicação interna da empresa era baseada na ferramenta DotProject (2005), que

registrava as ocorrências e a definição de tarefas aos responsáveis do desenvolvimento. O

produto teve sua utilização ampliada e se tornou um centro geral de ações e comunicação

(interna e com o cliente externo). A Figura 5.12 representa o uso ampliado do produto.

As atividades (Estudo das normas ISO 9000 e ISO 9001) e D (Estudo da ISO/IEC

12207 e ISO/IEC 15271) reuniram uma base suficiente para a implantação segura e o

entendimento da proposta de SGQ.

128

Figura 5.11: Ampliação do uso do DotProject

As atividades G (Definição da Política da Qualidade) e H (Definição dos Objetivos da

Qualidade) resultaram em:

• Escopo do SGQ: Desenvolvimento de sistemas informatizados, fornecimento de

recursos humanos especializados (outsourcing) e treinamentos para qualificação

profissional em análise e desenvolvimento de sistemas.

• Política da Qualidade: Desenvolver sistemas, fornecer recursos humanos e

treinamentos especializados em tecnologia da informação com objetivo de satisfazer

seus clientes, atendendo a seus requisitos técnicos, estatutários e regulamentares.

Promover ações de qualificação profissional dos colaboradores e escolha de

tecnologias e parcerias afinadas com nossos objetivos da qualidade.

• Missão da SoftSite: Atuar nas áreas de desenvolvimento, consultoria, apoio e

treinamento, para permitir a implementação de soluções em tecnologia da

informação.

• Visão de Futuro: Alcançar novos mercados internos e externos, sendo referência

através de treinamento e do desenvolvimento de soluções em tecnologia da

informação.

129

• Objetivos da Qualidade:

a) Consolidar produtos próprios ou de parceiros para estabelecimento de uma

plataforma de vendas em escala comercial.

b) Ter presença comercial em mercados internos e externos.

c) Aumentar o número de clientes tornando a empresa referência no

treinamento e desenvolvimento de sistemas de tecnologia da informação.

d) Qualificar a equipe, através de permanentes ações de treinamentos para

qualificação profissional, visando atender satisfatoriamente nossos clientes.

e) Utilizar plenamente a gestão de projetos, para melhor execução dos nossos projetos.

f) Melhorar continuamente a qualidade dos processos de treinamento.

As atividades I(Identificação de processos na ótica de Normas, Política e Objetivos da

Qualidade), J (Elaboração de procedimentos obrigatórios), e L (Elaboração dos

procedimentos não obrigatórios necessários) geraram a estrutura PC* (Procedimento). Na

Tabela 5.8, a coluna ISO especifica a obrigatoriedade ou não pela ISO 9001:2000.

Tabela 5.9 Relação dos procedimentos implantados na SoftSite

Procedimentos ISO Descrição Classificação PC01 Obr Procedimento de Controle de Documentos Apoio PC02 Obr Procedimento de Controle de Registros da Qualidade Apoio PC03 Obr Procedimento para Auditorias Internas Apoio PC04 Obr Procedimento de Controle de Produto Não-conforme Apoio PC05 Obr Procedimento para Ações Corretivas, Preventivas e de Melhoria Apoio PC14 nObr Procedimento de descrição do Sistema de Gestão da Qualidade Apoio PC07 nObr Procedimento de Projeto e Desenvolvimento de Sistemas Fundamental

PDS-SS nObr Processo de Desenvolvimento de Sistemas da SoftSite Fundamental PC06 nObr Análise de Propostas e Contratos Organizacional PC08 nObr Procedimento para Qualificação de Fornecedores Organizacional PC09 nObr Procedimento de Responsabilidades da Direção Organizacional PC10 nObr Procedimento de Controle de Propriedade de Cliente Organizacional PC11 nObr Procedimento de Identificação e Rastreabilidade de Produtos Organizacional PC12 nObr Procedimento de Preservação do Produto Organizacional PC13 nObr Procedimento para Recursos Humanos Organizacional PC15 nObr Procedimento de Rotina de Backup Organizacional

A atividade K (Implantação dos procedimentos obrigatórios) foi a atividade que mais

se apresentou distante do dia-a-dia da empresa. Os procedimentos obrigatórios devem ter um

tempo de amadurecimento maior para um efetivo sucesso do processo de implantação.

A atividade M (Identificação dos registros necessários e implementação dos controles

requeridos) foi efetuada a partir do template apresentado no Apêndice V. A atividade N

130

(Definição e alocação de recursos necessários) contou com a participação da diretoria, do

levantamento da capacidade, recursos e aportes financeiros.

As atividades O (Identificação de funções e dos requisitos de competências

necessários), P (Verificação de necessidades de competências nos recursos humanos), Q

(Identificação de treinamento necessário), e R (Verificação de eficácia do treinamento)

identificaram e definiram os papéis responsabilidades na Tabela 5.9 (onde E = exigível, e D =

desejável), e a estrutura da organização (Figura 5.10). O papel de RD é exercido pelo

Assistente Gerencial, cujas responsabilidades se adicionaram às responsabilidades requeridas

pela ISO 9001:2000.

Tabela 5.10: Papéis e Responsabilidades na SoftSite

Requisitos de Competência: Web Designer Descrição Trainee Júnior Sênior

EDUCAÇÃO E D E D E D 2º Grau Completo x - x - x - Graduação em Informática ou conhecimento equivalente - x x - x - Especialização em Informática ou conhecimento equivalente - x - x - x Mestrado em Informática ou conhecimento equivalente - x - x - x TREINAMENTO Técnicas de Web Designer (deve manter atualizado) - x - x x - HABILIDADES Criatividade x - x - x - Facilidade de Comunicação x - x - x - Bom Relacionamento com a Equipe de Trabalho x - x - x - Conhecimento de Técnicas de Usabilidade - x - x - x EXPERIÊNCIA 1 ano na função ou similar x - - - - - 2 anos na função ou similar - x x - - - 3 anos ou mais na função ou similar - x - x x - Requisitos de Competência: Analista de Suporte Java

Descrição Trainee Júnior Sênior EDUCAÇÃO E D E D E D 2º Grau Completo x - x - x - Graduação em Informática ou conhecimento equivalente - x x - x - Especialização em Informática ou conhecimento equivalente - x - x - x Mestrado em Informática ou conhecimento equivalente - x - x - x TREINAMENTO Unified Modeling Language – UML (Continuado) - x x - x - Banco de Dados (Continuado) - x x - x - Linguagem de Programação (Continuado) - x x - x - Sun Certified Programmer x - x - x - Sun Certified Web Component Developer - x x - x - Sun Certified Java Developer - x - x - x Sun Certified Business Component Developer - x - x x - Sun Certified Enterprise Architect - x - x - x Sun Certified Mobile Application Developer - x - x - x HABILIDADES Liderança - x x - x - Facilidade de aprendizado de novas tecnologias x - x - x - Facilidade de Comunicação x - x - x - Bom Relacionamento com a Equipe de Trabalho x - x - x - Bom Relacionamento com Clientes x - x - x - EXPERIÊNCIA

131

1 ano na função ou similar x - - - - - 2 anos na função ou similar - x x - - - 3 anos ou mais na função ou similar - x - x x - Requisitos de Competência: Programador Power Builder

Descrição Trainee Júnior Sênior EDUCAÇÃO E D E D E D 2º Grau Completo x - x - x - Graduação em Informática ou conhecimento equivalente - x x - x - Especialização em Informática ou conhecimento equivalente - x - x - x TREINAMENTO Unified Modeling Language – UML (Continuado) - x - x x - Banco de Dados (Continuado) - x - x x - Linguagem de Programação (Continuado) - x x - x - Sybase Certified Power Builder Developer - x - x - x HABILIDADES Conhecimento de Linguagem de Programação x - x - x - Lógica de Programação x - x - x - Conhecimento em Banco de Dados - x x - x - Unified Modeling Language – UML - x x - x - Bom Relacionamento com a Equipe de Trabalho x - x - x - EXPERIÊNCIA 1 ano na função de programador - x x - x - 2 anos na função de programador - x - x x - 3 anos na função de programador - x - x - x Requisitos de Competência: Programador Java

Descrição Trainee Júnior Sênior Educação E D E D E D 2º Grau Completo x - x - x - Graduação em Informática ou conhecimento equivalente - x x - x - Especialização em Informática ou conhecimento equivalente - x - x - x Treinamento Unified Modeling Language – UML (Continuado) - x - x x - Banco de Dados (Continuado) - x - x x - Linguagem de Programação (Continuado) - x - x x - Sun Certified Programmer - x x - x - Sun Certified Web Component Developer - x - x x - Sun Certified Java Developer - x - x - x Sun Certified Business Component Developer - x - x - x Sun Certified Enterprise Architect - x - x - x Sun Certified Mobile Application Developer - x - x - x Habilidades Conhecimento de Linguagem de Programação x - x - x - Lógica de Programação x - x - x - Conhecimento em Banco de Dados - x x - x - Unified Modeling Language – UML - x x - x - Bom Relacionamento com a Equipe de Trabalho x - x - x - Experiência 1 ano na função de programador - x x - x - 2 anos na função de programador - x - x x - 3 anos na função de programador - x - x - x Requisitos de Competência: Programador Microsoft

Descrição Trainee Júnior Sênior Educação E D E E E E 2º Grau Completo x - x - x - Graduação em Informática ou conhecimento equivalente - x x - x - Especialização em Informática ou conhecimento equivalente - x - x - x Treinamento Unified Modeling Language – UML (Continuado) - x - x - x Banco de Dados (Continuado) - x - x - x Linguagem de Programação (Continuado) - x - x - x

132

Microsoft Certified Professional (VB/C#) - x x - x - Microsoft Certified Professional (SQL) - x - x x - Microsoft Certified Application Developer - x - x - x Microsoft Certified Solution Developer - x - x - x Habilidades Conhecimento de Linguagem de Programação x - x - x - Lógica de Programação x - x - x - Conhecimento em Banco de Dados - x x - x - Unified Modeling Language – UML - x x - x - Bom Relacionamento com a Equipe de Trabalho x - x - x - Experiência 1 ano na função de programador - x x - x - 2 anos na função de programador - x - x x - 3 anos na função de programador - x - x - x Requisitos de Competência: Analista de Sistemas

Descrição Trainee Júnior Sênior Educação E D E D E D 2º Grau Completo x - x - x - Graduação em Informática ou conhecimento equivalente - x x - x - Especialização em Informática ou conhecimento equivalente - x - x - x Mestrado em Informática ou conhecimento equivalente - x - x - x Treinamento Unified Modeling Language – UML (Continuado) - x x - x - Banco de Dados (Continuado) - x x - x - Gerência de Projetos (Continuado) - x x - x - Linguagem de Programação (Continuado) - x x - x - Rational Unified Process (RUP) - x x - x - PMBOK - x - x x - Habilidades Liderança - x x - x - Gestão Eficaz de Recursos - x x - x - Facilidade de Comunicação x - x - x - Bom Relacionamento com a Equipe de Trabalho x - x - x - Bom Relacionamento com Clientes x - x - x - Experiência 1 ano na função ou similar x - - - - - 2 anos na função ou similar - x x - - - 3 anos ou mais na função ou similar - x - x x - Requisitos de Competência: Diretor Técnico / Comercial

Descrição E D Educação 2º Grau Completo x - Graduação em Informática ou conhecimento equivalente - x Especialização em Informática ou conhecimento equivalente - x Mestrado / Doutorado em Informática ou conhecimento equivalente - x Treinamento Unified Modeling Language – UML (Continuado) - x Banco de Dados (Continuado) - x Linguagem de Programação (Continuado) - x Habilidades Gestão Eficaz de Recursos x - Facilidade de Comunicação e Liderança x - Bom relacionamento com os diferentes níveis hierárquicos x - Bom Relacionamento Interpessoal e com Clientes x - Gerência de Projetos de Tecnologia da Informação x - Experiência Não requerida - - Requisitos de Competência: Assistente Gerencial

Descrição Educação E D

133

2º Grau Completo x - Graduação na Área Administrativa ou conhecimento equivalente x Especialização em Área Administrativa - x Treinamento Sistema de Gestão da Qualidade ISO 9001 x - Auditoria de SGQ ISO 9001 x - Tratamento de Produto Não Conforme na ISO 9001 x - Habilidades Facilidade de Comunicação e Relacionamento Interpessoal e com Clientes x - Facilidade de Lidar com Diversos Níveis Hierárquicos x - Utilização dos aplicativos do Office/Internet x - Experiência 6 meses na função ou similar - x Requisitos de Competência: Diretor de Desenvolvimento de Negócios e Projetos

Descrição Educação E D 2º Grau Completo x - Graduação em Informática ou conhecimento equivalente - x Especialização em Informática, MBA Empresarial ou Conhecimento Equivalente

- x

Mestrado / Doutorado em Informática ou conhecimento equivalente - x Treinamento Unified Modeling Language – UML (Continuado) - x Banco de Dados (Continuado) - x Linguagem de Programação (Continuado) - x Habilidades Gestão Eficaz de Recursos x - Facilidade de Comunicação e Liderança x - Bom relacionamento com os diferentes níveis hierárquicos x - Bom Relacionamento Interpessoal e com Clientes x - Gerência de Projetos de Tecnologia da Informação x - Experiência Não requerida - - Requisitos de Competência: Gerente de Projetos

Descrição Educação E D 2º Grau Completo x - Graduação em Informática ou conhecimento equivalente x - Especialização em Informática ou conhecimento equivalente x - Mestrado em Informática ou conhecimento equivalente - x Treinamento Unified Modeling Language – UML (Continuado) x - Banco de Dados (Continuado) x - Gerência de Projetos (Continuado) x - Linguagem de Programação (Continuado) x - Rational Unified Process (RUP) - x PMBOK x - Habilidades Liderança x - Gestão Eficaz de Recursos x - Facilidade de Comunicação x - Bom Relacionamento com a Equipe de Trabalho x - Bom Relacionamento com Clientes x - Gerência de Projetos de Tecnologia da Informação x - Experiência 1 ano na função ou similar - - 2 anos na função ou similar x x 3 anos ou mais na função ou similar - x

134

A atividade S (Implantação dos procedimentos não obrigatórios necessários) cobriu

principalmente os processos organizacionais, deixando clara a maturidade administrativa

presente nas atividades e abordagens da empresa. Os procedimentos técnicos do

desenvolvimento de software também foram contemplados e já tinham maturidade embutida.

As atividades T (Análise Crítica pela alta direção) e U (Validação e comprometimento

da alta direção) foram executadas constantemente ao longo do projeto de implantação do

SGQ. A aceitação do projeto pela alta direção foi primordial. Os outros colaboradores

observam o interesse demonstrado e a aplicação de todos os itens da proposta inclusive pela

própria direção. Durante a implantação do SGQ até a sua Certificação ISO 9001:2000 foram

realizadas 14 reuniões registradas em atas e verificadas pelas auditorias internas e de

certificação (Figura 5.13).

Figura 5.12: Marcação de pauta mínima para reuniões de análise crítica

A atividade V (Auditorias internas da qualidade) é uma atividade obrigatória pelos

requisitos da norma ISO 9001 e se aplicou como processo de treinamento para a formação dos

auditores internos. Conforme definido no PC03, a SoftSite terá intervalo de 4 meses para cada

auditoria interna.

As atividades W (Processos de Melhoria) e X (Ações corretivas e ou preventivas), que

aconteceram ao longo do processo de implantação, validaram e avaliaram os processos no

momento de suas aplicações e implantações, a auditoria interna também propiciou fonte

segura de melhoria e correções.

135

A atividade Y (Ajustes finais) aconteceu para pequenos acertos nos procedimentos e

processos gerais, oriundos análise da eficácia das ações corretivas, preventivas e de melhoria

aplicadas até então e registradas na ferramenta DotProject (2005).

A atividade Z (Certificação Oficial ISO 9001) reuniu toda a empresa e foi executada em

um dia completo com a presença de dois auditores. Um desses auditores era especialista em

software, verificando os processos técnicos que envolviam o desenvolvimento de software, e

o outro era o auditor chefe, que verificou os processos gerais. Um relatório com pontos fracos

e fortes foi apresentado, para servir de base para a próxima avaliação anual, na auditoria de

acompanhamento, como parâmetro de evolução do SGQ. Como resultados da auditoria têm-se

as seguintes seções do relatório de auditoria:

2.1 - Strengths / Pontos fortes • 7.1, 7.3, 7.5.1 2.2 - Weaknesses / Pontos fracos • 5.6.2, 8.4, 8.5, 8.5.2, 8.5.3 2.3 - Improvement potential(s) / Oportunidades de Melhoria • 4.2.3 - Avaliar a possibilidade em otimizar o mapeamento e interação entre os

processos do sistema de gestão da qualidade no que diz respeito ao 7.1 e 7.2 3 7.3.

• 5.6.2 – Avaliar a possibilidade de extratificar as não conformidades por tipo e por

volume e analisá-las nas reuniões de análise crítica pela alta direção com o intuito de tomar ações corretivas para evitar sua reincidência.

• 8.2.2 – Avaliar a possibilidade em detalhar o relatório de auditoria interna,

indicando claramente, quais as evidências objetivas observadas em cada um dos requisitos auditados.

• 8.5.2 – Evidenciar claramente no campo verificação da eficácia no RNC

eletrônico, qual a evidência objetiva verificada para justificar a eficácia da ação corretiva.

• 8.5.3 - Desenvolver novas fontes para alavancar a tomada de ações preventivas. 2.4 – Observation to be considered in the next audit / Observações a serem consideradas na próxima auditoria.

5.3-b – Evidenciar claramente no texto da política da qualidade o comprometimento com a melhoria contínua da eficácia do sistema de gestão da qualidade.

5.6.2 – Caracterizar nos indicadores da qualidade (gráficos) as metas objetivando facilitar a análise da situação evidenciada em relação à expectativa da SOFTSITE.

5.6.2 – c- Evidenciar claramente que foram analisados os indicadores de processo e de produto durante a reunião de análise pela alta direção.

7.2.3 – Estratificar as reclamações de clientes por tipo e volume, criando um indicador da qualidade, e avalia-lo nas reuniões de análise crítica pela alta direção no item “Realimentação do Cliente”.

136

7.4 – Evidenciar claramente que as não conformidades oriundas de fornecedores são tratadas através de RNC (Relatório de Não Conformidade).

8.2.3/8.2.4 – Evidenciar claramente quais e como são medidos os produtos e processos do sistema de gestão da qualidade, indicando, caso seja possível, onde são registradas estas medições.

8.5.2 – Evidenciar no Dot-Project a causa raiz da não conformidade para que a magnitude da ação corretiva tomada possa realmente eliminar a causa da não conformidade.

5.4.2.4 o SGQ Implantado

Ao final do processo de implantação do SGQ (Figura 5.14) e de sua aprovação e

certificação, a empresa validou a estrutura do SGQ, seu Manual da Qualidade (Figura 5.15) e

o escopo da certificação.

Figura 5.13: Estrutura do SGQ na SoftSite

137

Figura 5.14: Manual da Qualidade da SoftSite


As atividades que envolveram os processos organizacionais foram mais facilmente

realizadas pelo Grupo Interno de implantação; no entanto, as atividades técnicas tiveram um

pouco de dificuldade. Essa dificuldade foi contornada com a participação mais efetiva do

corpo técnico, que se envolveu nas definições adequações dos requisitos da ISO 9001:2000.

Como a empresa já possuía uma estrutura organizacional madura, as atividades

administrativas foram facilmente adequadas às necessidades do SGQ. Os macro-processos de

Apoio e Fundamental precisaram ser mais formalizados e adequados à ISO 9001:2000. Desta

forma, o processo de treinamento interno foi mais intensificado.

Após a Certificação ISO 9001 da SoftSite, esta empresa reforçou o grupo da Qualidade

e novos processos foram estudados e integrados ao SGQ. O fator de melhoria contínua da

proposta foi naturalmente implementado. No decorrer do ano de 2004, estudou-se também o

PMBOK e um processo de Gerência de Projetos foi adaptado às características empresa. Os

novos procedimentos e templates estão relacionados na Tabela 5.10.

138

Merece registro a intensa transformação da SoftSite, despertada pela estruturação

organizacional, implantação do SGQ para MPMEs proposto, e as formalidades implantadas

de reuniões de análise crítica e processos de ações de melhoria.

Tabela 5.11: Novos documentos implantados após a certificação da SoftSite

Procedimentos ISO Descrição Classificação PC16 nObr Procedimento de Gerência de Projetos Organizacional PC17 nObr Simulador de Custos Fundamental/Organizacional PC18 nObr Simulador de Prazos Fundamental/Organizacional PC19 nObr Iniciação do Projeto Fundamental/Apoio PC20 nObr Planejamento de Escopo e Requisitos Fundamental/Apoio PC21 nObr Planejamento de Recursos do Projeto Fundamental/Apoio PC22 nObr Plano de Gerência de Riscos do Projeto Fundamental/Apoio PC23 nObr Controle de Requisitos Fundamental/Apoio

A empresa, através da análise de satisfação de seus clientes, identificou a potencialidade

um de produto de software desenvolvido para um determinado cliente como um produto em

formato comercial. Esta abordagem de comercialização de um produto ficou mais intensa a

partir de setembro de 2004 com sua reorganização estrutural (Figura 5.16), a incorporação de

novos papéis e responsabilidades, e do processo de desenvolvimento. Isto levou em conta uma

estrutura baseada tanto em projeto de software, quanto na evolução do produto e a

“customização” do cliente.

Figura 5.15: Estrutura Organizacional SoftSite com visão de Produto Comercial

A Figura 5.17 representa o novo fluxo de atividades do PDP-SS (Procedimento de

Desenvolvimento e Produção da SoftSite), que é uma evolução do processo anterior (Figura

5.11), inspirado no modelo EUP (Enterprise Unified Process) (2005). Esse modelo expande

139

em duas fases o RUP: (i) produção: que agrupa atividades que se destacam pelo envolvimento

com o produto comercial da empresa, (ii) retirada: que agrupa as atividades que se destacam

pelo envolvimento com as retiradas e atualização de versões do produto.

Figura 5.16: PDP-SS adaptado do modelo EUP

5.5 Conclusão deste Trabalho

O período de implantação do SGQ para MPMEs até a certificação ISO 9001 durou

exatamente doze meses nas duas empresas citadas. Após o árduo processo de certificação, o

SGQ deve continuar suas atividades e promover a estruturação de indicadores de qualidade,

para preparar a empresa para a etapa de revalidação do próprio SGQ, que se dará em torno de

um ano depois.

A expertise das fábricas de software (as duas empresas deste estudo de caso) agora

procurar agregar valor aos produtos de software desenvolvidos, facilitando futuras adaptações

do produto. Com isto, já é sentida a satisfação dos clientes ao receberem seus produtos, e a

satisfação dos próprios colaboradores das empresas por poderem tirar o melhor proveito da

tecnologia (de produto e processo) que manuseiam.

140

5.5.1 Contribuições da Proposta de SGQ

As principais contribuições do SGQ para MPMEs são:

• O mapeamento entre a ISO 9001(2000) e a ISO/IEC 12207 (1998), integrando os

requisitos de certificação com os processos de ciclo de vida de software, utilizando

três frentes de ação: os macro-processos organizacionais, fundamentais, e de

apoio. Isto facilitou o diálogo entre os colaboradores da empresa.

• O levantamento e o estudo de produtos de software da empresa ao longo do

processo de certificação, com o intuito de atender a itens obrigatórios de controle

da norma certificadora.

• A identificação de itens necessários, no contexto de empresas de software e à luz

da ISO/IEC 12207, que favoreciam o processo de certificação.

• A identificação e adequação de rotinas, processos, metodologias e produtos da

empresa à norma certificadora, ao longo do estudo dessa norma pelo grupo de

implantação do SGQ.

• A elaboração de um conjunto detalhado de procedimentos obrigatórios exigidos

pela ISO 9001, que podem servir de guia para a certificação de MPMEs de

software (esses procedimentos foram utilizados nas duas pequenas empresas do

estudo de caso).

• A elaboração de um conjunto detalhado de procedimentos necessários baseados na

ISO/IEC 12207, que também podem servir de guia para a certificação de MPMEs

de software (esses procedimentos foram também utilizados nas duas pequenas

empresas do estudo de caso).

As principais lições aprendidas com a proposta do SGQ para MPMEs são:

• O apoio explícito da alta administração da empresa é de fundamental; mais do que

isto, é necessário que a própria alta administração se envolva diretamente com os

participantes do processo de certificação e, desta forma, envolvendo todos os

colaboradores da empresa.

• As definições de Visão, Política, e Objetivos da Qualidade motivaram a diretoria a

definir e acompanhar todos os processos, que realmente interessavam e motivavam

o controle da estrutura organizacional.

141

• O levantamento e o estudo dos processos de desenvolvimento de software

adotados pela empresa proporcionaram aos participantes do processo, uma rápida

integração com as rotinas e com os desenvolvedores. Isto levou a identificação de

vários produtos que poderiam ser utilizados nos processos de gerenciamento e

desenvolvimento da empresa. Alguns desses produtos já se adequavam a itens de

controle obrigatório da norma certificadora.

• O resultado do levantamento e estudos de processos e produtos internos também

pode ser citado com importante momento em que a realidade da organização pode

ser percebida, podendo agir como um integrador das diferentes visões da

organização.

• A identificação dos papeis e das responsabilidades da organização, descrevendo

suas atividades e qualificações necessárias. Vale salientar que um colaborador

pode assumir vários papéis.

• A utilização da estrutura da norma ISO 9001:2000 no próprio processo de

certificação foi gradualmente criando o clima de SGQ e facilitando seu

amadurecimento;

O processo de melhoria contínua do SGQ acentuou a necessidade de evoluções

controladas e passíveis de serem implementadas e validadas, pois a cada ano o SGQ é

reavaliado e recomendado oficialmente, desde que as evoluções realizadas sejam compatíveis

e focada na melhoria dos controles e processos organizacionais da empresa.

5.5.2 Trabalhos futuros

Como alguns trabalhos futuros desta proposta, podemos sugerir:

• os resultados do SGQ para MPMEs de software podem ser estendidos e validados

nos anos seguintes ao ano da certificação oficial;

• a incorporação dos processos de gerência de projetos da própria norma ISO/IEC

12207, juntamente com o Amd 1:2002 e o Amd 2 :2004;

• Evidenciar os aspectos evolutivos do SGQ, com a possibilidade da adoção da

ISO/IEC 90003:2004;

• a aplicação da ISO/IEC 15504 em áreas de interesse específicas para a proposta de

negócio da empresa.

142

REFERÊNCIAS BIBLIOGRÁFICAS

ABNT, 2005, ABNT – Associação Brasileira de Normas Técnicas - Disponível em: <http://www.abnt.org.br>.

ALBUQUERQUE, Adriano B. 2001, Qualidade de Websites de Comércio Eletrônico. Dissertação (Mestrado) – Mestrado em Informática Aplicada (MIA), Universidade de Fortaleza (UNIFOR). Disponível em <http://www.unifor.br/pls/oul/p_tese_defendida_ncm?p_nr_curso=83>. Acesso em Janeiro de 2004.

AMORIM, Lívia N., Belchior, Arnaldo D., 2004, Gerenciamento da Qualidade: uma nova disciplina para o RUP. XXX Conferencia Latinoamericana en Informática–CLEI . Arequipa – Peru. 2004

ANACLETO, Alessandra, Wangenheim, Christiane G. V., Salviano, Clênio F., Savi, Rafael., 2003, 15504MPE – Desenvolvendo um Método para Avaliação de Processo de Software em MPEs Utilizando a ISO/IEC 15504. V Simpósio Internacional de Melhoria de Processo de Software – SIMPROS. Recife – PE. 2003.

AZEVEDO, Raimundo S. N. e, Matos, Ana C. M., Simão, Marum, Cesar, Flávio L. Belchior, Arnaldo D. 2004a Certificação ISO 9001:2000 – a experiência da SoftExport. III Simpósio Brasileiro de Qualidade de Software – SBQS. Brasilia – DF. 2004

AZEVEDO, Raimundo S. N. e, Belchior, Arnaldo D., Simão, Marum, Cesar, Flávio L., 2004b, Um modelo para certificação ISO 9001:2000 em PMEs. XXX Conferencia Latinoamericana en Informática – CLEI . Arequipa – Peru. 2004

BARCAUI, André B., Quelhas, Osvaldo, 2004, Perfil de Escritórios de Gerenciamento de Projetos em Organizações atuantes no Brasil – 2004, Revista Pesquisa e Desenvolvimento em Engenharia de Produção, No.2, p.38 – 53, Julho de 2004.

BASILI, V. R., Kan, S. H., Shapiro, L. N., 1994 , “Software quality: An overview from the perspective of total quality management, IBM Systems Jornal, Vol 33, No.1, 1994. Disponível em <http://www.research.ibm.com/journal/sj/331/kan.pdf> . Acesso em Jan/2004.

143

BATISTA, Gabriela F., Souza, Francisco J. C., Piñón, Hernán., 2003, Gestão Transparente e Integrada em Projetos para CMM 2. V Simpósio Internacional de Melhoria de Processo de Software – SIMPROS. Recife – PE. 2003.

BELCHIOR, A. D., 1997, Um modelo fuzzy para avaliação da qualidade de software, Tese de Doutorado, UFRJ-COOPE, Maio, Rio de janeiro.

BERTOLLO, Gleidson. Falbo, Ricardo de Almeida, 2003, – Apoio Automatizado de Processos de Software em Níveis. II Simpósio Brasileiro de Qualidade de Software. SBQS.

BIDO, Diórgenes de S., 1999, Implementação de Sistemas da Qualidade para a busca de Certificação em Pequenas e Médias empresas do ramo automotivo. Dissertação (Mestrado). Faculdade de Economia, Administração e Contabilidade -Universidade de São Paulo. Disponível em <http://www.teses.usp.br>. Acesso em Janeiro de 2005.

CALLIGARIS, Aline B., Magierski, Danielle, Torkomian, Ana L. V., Pizzinatto, Nádia K., Netto, Antônio V. ,2001, A influência do Programa de inovação tecnológica em Pequenas Empresas (PIPE/FAPESP) no desenvolvimento de produto. 3º Congresso Brasileiro de Gestão de Desenvolvimento de Produto. Florianópolis – SC, 25-27 de Setembro/2001. Disponível em <http://www.cientistasassociados.com.br/artigos/published.htm>. Acesso em Janeiro de 2005.

CAMEIRA, Renato F., Caulliraux, Heitor M., 2000, Engenharia de Processos de negócios: Considerações metodológicas com vistas à análise e Integração de processos. III SIMPOI – Simpósio de Administração da Produção Logística e Operações Internacionais. São Paulo, Brasil, Setembro 2000. Grupo de Produção Integrada/COPPE & POLI / UFRJ. Disponível em: <www.gpi.ufrj.br/artigos>. Acesso em Jul 2004.

CAMPOS, Vicente Falconi., 1992, Qualidade total: Padronização de empresas, Belo Horizonte, QFCO.

CARVALHO, Kristiane C., 2004, Gestão das informações sobre o ambiente na pequena empresa: Estudo comparativo de casos sobre o processo estratégico no setor de serviços (hoteleiro) da região de brotas –SP. Dissertação (Mestrado). Escola de Engenharia de São Carlos-Universidade de São paulo, 2004. Disponível em <http://www.teses.ups.br>. Acesso em Janeiro de 2005.

CARVALHO, Maria C. R. de, 1981, Estabelecimento de padrões para bibliotecas universitárias, Edições UFC, Fortaleza.

CASSARÁ, Antônio C., 2003, Compartilhamento de informações e valorização dos indivíduos na empresa e seus reflexos na produtividade: Um caso prático. Capítulo 1- em Gestão do conhecimento em pequenas e médias empresas/ coordenação José Cláudio Terra, Isak Kruglianskas. – Rio de Janeiro: Campus.

144

CASTELO BRANCO, Eliseu, 2001, Um Modelo para Avaliação da Qualidade da Gerência de Projetos de Software. Dissertação (Mestrado) – Mestrado em Informática Aplicada (MIA), Universidade de Fortaleza (UNIFOR). Disponível em <http://www.unifor.br/pls/oul/p_tese_defendida_ncm?p_nr_curso=83>. Acesso em Janeiro de 2004.

CHAO LI, Hauizhang Li, Mingshu Li., 2001, A Software Factory Model on ISO 9000 and CMM for Chinese Small Organizations, IEEE, 2001.

CHIAVENATO, Idalberto, 1999, Administração nos novos tempos, 2ª Edição – Rio de Janeiro : Campus.

CHRISSIS, M. B., Konrad, M., Shrum, S., 2003, CMMI Guidelines for Process Integration and Product Improvement. Addison Wesley.

CMMI, 2002a, Capability Maturity Model Integration, Version 1.1. CMMI for Software Engineering. Staged Representation, CMU/SEI-2002-TR-029, ESC-TR-2002-029. August 2002.

CMMI, 2002b, Capability Maturity Model Integration, Version 1.1. CMMI for Software Engineering. Continuous Representation, CMU/SEI-2002-TR-028, ESC-TR-2002-028. August 2002.

CMMI, 2002c, Capability Maturity Model Integration, Version 1.1. CMMI for Systems Engineering, Software Engineering, Integrated Product and Process Development, and Supplier Sourcing. Staged Representation, CMU/SEI-2002-TR-012, ESC-TR-2002-012. March 2002.

CÔRTES, Mário L., 1998, Material da Disciplina Análise e Projeto de Sistemas de Informação II. UNICAMP. Disponível em <http://www.ic.unicamp.br/~cortes/mc726>. Acesso em Julho de 2004.

CRITÉRIOS DE EXCELÊNCIA, 2004, Critérios de Excelência 2005: O estado da arte da gestão para a excelência do desempenho e o aumento da competitividade, Fundação para o Prêmio Nacional da Qualidade – FNPQ.

COCKBURN, Alistair.,2000, Selecting a Project´s Methodology. IEEE. July/August 2000.

DAHUA JU.,2001, China´s Budding Software Industry. IEEE 2001

145

DINSMORE, Paul C., 2002, Project Offices: Best Practices Help Ride Out The Storm, Artigo publicado na revista PM Network – Maio 2002. Disponível em <http://www.dinsmore.com.br/nova/artigos.htm>. Acesso em Julho de 2004.

FERNSTRÖM, Christer, Närfelt, Kjell-Håkan, Ohlsson, Lennart. , 2000, Software factory principles, architecture, and experiments. IEEE software. Março 2000.

FIORINI, Soeli T., Staa, Arndt, Baptista, Renan M.,1998, Engenharia de Software com CMM. Rio de Janeiro. Brasport, 1998.

FUTRELL, Robert, Shafer, Donanld, Shafer, Linda, 2001, Quality software project management. Software Quality Institute Series. Prentice Hall PTR. 2001. USA.

GARVIN, David A. ,1984 , What does “Product Quality” Really Mean?. Sloam Management Review Association.

GONÇALVES, José E. L., 2000, As empresas são grandes coleções de processos. Revista de Administração de Empresas – RAE. Jan/Mar. 2000. V.40, n-1, p6-19. São Paulo.

HUMPHREY, Watts S., 1999, Introduction to the Personal Software Process. SEI serie in software engineering. Addison-Wesley. United States. 1999.

IBGE, 2003, Instituto Brasileiro de Geografia e Estatística. As Micro e pequenas empresas comerciais e de serviços no Brasil: 2001 / IBGE, Coordenação de Serviços e Comércio. – Rio de Janeiro : IBGE, 2003.

INMETRO, 2005, Instituto Nacional de Metrologia, Normalização e Qualidade Industrial, Empresas Certificadas ISO 9001, Disponível em: <http://www.inmetro.gov.br/gestao9000/>. Acesso em: 10 de Junho de 2005.

ISO, 2005, International Organization for Standardization., Disponível em <http://iso.org>. Acessos Diversos de 2003 a 2005

ISO/IEC 12207:1995, Amd 1:2002, 2002, Software engineering Information technology -- Software life cycle processes, ISO – International Organization for Standardization, Geneva, Switzerland.

ISO/IEC 15504-1, 2004, Information technology -- Process assessment -- Part 1: Concepts and vocabulary, ISO – International Organization for Standardization, Geneva, Switzerland.

146

ISO/IEC 15504-2, 2003, Information technology -- Process assessment -- Part 2: Performing an assessment, ISO – International Organization for Standardization, Geneva, Switzerland.

ISO/IEC 90003, 2004, Software engineering – Guidelines for the application of ISO 9001:2000 to computer software. First edition, ISO – International Organization for Standardization, Geneva, Switzerland.

JAMIL, George L.,2001, Repensando a TI na empresa moderna: Atualizando a Gestão com a tecnologia da Informação – Rio de Janeiro, Axcel Books do Brasil Editora.

JOHNSON, Donna L., Brodman, Judith B., 2000, Applying CMM Project Planning Pratices to Diverse Environments. IEEE. July/August 2000.

KOONTZ, Harold, O’donnell Cyril., 1981, Fundamentos da Administração. Traduzido por Carlos Afonso Malferrari– 1981 – São Paulo, Biblioteca Pioneira de Administração e Negócios/ Livraria Pioneira Editora.

LA ROVERE, Renata L., 2001, Perspectivas das Micro, Pequenas e Médias Empresas no Brasil. Revista de Economia Contemporânea, Rio de Janeiro, vol. 5 edição especial. Disponível em <http://www.ie.ufrj.br/revista/pdfs>. Acesso em Novembro de 2003.

LA ROVERE, Renata L., 2004, O debate acerca de Políticas para Micro, Pequenas e Médias Empresas (MPMEs) – Instituto de Economia /UFRJ. Disponível em <http://www.iets.inf.br/acervo/Artigos.htm>. Acesso em Janeiro de 2004.

LAUDON, Kenneth C., Laudon Jane P., 2001, Sistemas de Informação. Quarta Edição. Traduzido por Alexandre Oliveira – Rio de Janeiro, LTC – Livros Técnicos e Científicos Editora S.A.

LEMOS, Gizelle S., Recchia, Edson L., Penteado, Rosângela D., Braga, Rosana T.V., 2003, Padrões de reengenharia auxiliados por diretrizes de Qualidade de software. SugarLoafPLOP 2003 - The Third Lantin American Conference on Pattern Languages od Programming, Disponível em <http://www.cin.ufpe.br/~sugarloafplop>. Acesso em Julho de 2004

LIMA, Osias. S. Jr., 2002, Análise de Pontos por Função Fuzzi. Dissertação (Mestrado) – Mestrado em Informática Aplicada, Universidade de Fortaleza (UNIFOR). Disponível em <http://www.unifor.br/pls/oul/p_tese_defendida_ncm?p_nr_curso=83>. Acesso em Janeiro de 2004.

MACHADO, Cristina A. F., Jaeger Neto, José I., Mordini, Loraine G., Frossard, Ronaldo S., 1998, Processos de Ciclo de Vida de Software – Norma ISO/IEC 12207. Disponível em <http://www.qualidadesoftware.org.br/?section=downloads>. Acesso em Janeiro de 2004.

147

MARCINEIRO, Nazareno. 2001, Implantação do Gerenciamento pela qualidade total na Polícia Militar de Santa Catarina: Um estudo de caso. Dissertação de mestrado da Universidade Federal de Santa Catarina, Centro Tecnológico. 2001.

MARCZAK, Sabrina, Sá. Luciana, Caccato, Ilmari, Audy, Jorge, Antunes, Dante., 2003, Uma proposta de Organização e funcionamento da função de Garantia da qualidade de software em um contexto de implantação do SW-CMM. II Simpósio Brasileiro de Qualidade de Software. Fortaleza, Brasil. 2003.

MAXIMIANO, Antônio C. A., 2004, Teoria Geral da Administração: Da Revolução urbana à Revolução Digital. – 2004 – São Paulo, Editora Atlas S.A.

MCT, 2001, Empresas Graduadas nas Incubadoras Brasileiras: 2001 / MCT, Secretaria de Política Tecnológica Empresarial. – Brasília: MCT, 2001

MDIC, 2002, Ministério do Desenvolvimento, Indústria e Comércio Exterior. Micro, Pequenas e Médias Empresas: Definições e Estatísticas Internacionais. Publicado pela Secretaria do Desenvolvimento da Produção, Departamento de Micro, Pequenas e Médias Empresas. 2002.

MELLO, Carlos H. P., da Silva, Carlos E. S., Turrioni, João B., de Souza, Luiz G. M., 2002, ISO 9001:2000: Sistema de gestão da qualidade para operações de produção e serviços. São Paulo: Atlas, 2002.

MENDY, Mariana. Oliveira, Lúcia., 2003, – Conhecimento em ação, a mobilização de conhecimento, uma ferramenta competitiva em contextos adversos: Uma experiência no Uruguai. Capítulo 3- em Gestão do conhecimento em pequenas e médias empresas/ coordenação José Cláudio Terra, Isak Kruglianskas. – Rio de Janeiro: Campus, 2003.

MIGLIATO, Antônio L. T., 2004, Planejamento estratégico situacional aplicado à pequena empresa: Estudo comparativo de casos em empresas do setor de serviço (hoteleiro) da região de Brotas - SP. Dissertação (Mestrado Escola de Engenharia de São Carlos-Universidade de São paulo, 2004. Disponível em <http://www.teses.usp.br>. Acesso em Janeiro de 2005.

MONTENGRO, Gildo A. 1987, A Perspectiva dos profissionais: Sombras, Insolação e Axonometria. São Paulo. Editora Edgard Blücher Ltda. 1987

MUTAFELIJA, Boris. Stromberg, Harvey.,2003, Systematic Process Improvement Using ISO 9001:2000 and CMMI.Artech House Computing Library. Boston – USA. 2003.

NAVEIRO, Ricardo, 2005, Saiba mais sobre a Engenharia de Produção. Disponível em <http://www.abepro.org.br/saiba_mais_1.htm>. Acesso Janeiro de 2005.

148

NBR ISO 9000, 2000, Sistemas de gestão da qualidade – Fundamentos e vocabulário, ABNT, Rio de Janeiro.

NBR ISO 9001, 2000, Sistemas de gestão da qualidade – Requisitos, ABNT, Rio de Janeiro.

NBR ISO 9004, 2000, Sistemas de gestão da qualidade – Diretrizes para melhorias de desempenho, ABNT, Rio de Janeiro.

NBR ISO/IEC 8402, 1997, Gestão da qualidade e garantia da qualidade - Terminologia, ABNT, Rio de Janeiro.

NBR ISO/IEC 12207, 1998, Tecnologia da Informação: processos de ciclo de vida de software, ABNT, Rio de Janeiro.

NBR ISO/IEC 15271. 2000. Tecnologia da Informação: Guia para ISO/IEC NBR 12207 - processos de ciclo de vida de software .ABNT. Rio de Janeiro.

NUMA, 2005, Núcleo de Manufatura Avançada – NUMA – Escola de Engenharia de São Carlos da USP. Disponível em <www.numa.org.br>. Acesso em Janeiro de 2005.

OLIVEIRA, Kelly R., 2002, AdeQuas – Ferramenta Fuzzy para avaliação de Qualidade de Software. Dissertação (Mestrado) – Mestrado em Informática Aplicada (MIA), Universidade de Fortaleza (UNIFOR). Disponível em <http://www.unifor.br/pls/oul/p_tese_defendida_ncm?p_nr_curso=83>. Acesso em Janeiro de 2004.

ONEPINE, (2004), People, organisations, theory, models, concepts united, Disponível em <http://www.onepine.info>. Acesso em Dez/2004.

ORCI, Terttu, Laryd, Astrid., 2000, CMM for Small Organisations – Level 2. Umeå University, Technical Report, UMINF-00.20, 2000. Disponível em <http://www.cs.umu.se/~jubo/projects/qmse>. Acesso em Março de 2003.

PADUAN, Roberta et al, 2003. Tesouro Escondido. EXAME. São Paulo. v.37, n.13. 2003.

PAS, 2002, Instituto Brasileiro de Geografia e Estatística. Pesquisa Anual de Serviços -2002 / IBGE, Coordenação das Estatísticas Econômicas e Coordenação de Serviços e Comércio. – Rio de Janeiro : IBGE, 2002.

PAULA FILHO, Wilsom P., 2001. Engenharia de Software: Fundamentos, Métodos e Padrões. LTC – Livros Técnicos e Científicos S.A. 2001. Rio de Janeiro.

149

PAULK, M. C.; Chrissi, M. B.; Weber, C. v., 1993a, Capability Maturity Model for Software, Version 1.1; Software Engineering Institute, Carnegie Mellon University; CMU/SEI-93-TR-24, ESC-TR-93-177, Disponível em <http://www.sei.cmu.edu>. Acesso em Abril de 2003.

PAULK, M. C.; Chrissi, M. B.; Weber, C. v., 1993b, Key Pratices of the Capability Maturity Model, Version 1.1; Software Engineering Institute, Carnegie Mellon University; CMU/SEI-93-TR-25, ESC-TR-93-178; Disponível em <http://www.sei.cmu.edu>. Acesso em Abril de 2003.

PAULK, Mark C., 1994, A Comparison of ISO 9001 and the Capability Maturity Model for Software. CMU/SEI-94-TR-12. 1994.

PAULK, Mark. C.; Using the Software CMM with Good Judgment. Software Engineering Institute, Carnegie Mellon University. Disponível em <www.sei.cmu.edu>. Acesso em Abril de 2003.

PFLEEGER, S.L., 1998 Software engineering - theory and pratice. Nova Jersey, Prentice-Hall Inc., 1998.

PICCHI, Flávio A., Agopyan, Vahan, 1993, Sistemas da qualidade na construção de edifícios, Boletim Técnico da Escola Politécnica da USP – Departamento de Engenharia de Construção Civil. São Paulo. EPUSP. 1993.

PITTERMAN, Bill., 2000, Telcordia Technologies: The Journey to High Maturity IEEE. July/August 2000.

PMBOK Guide 2004 Edition. “A Guide to the Project Management Body of Knowledge”, Disponível em <http://www.pmi.org>. em Dezembro 2004.

POLLICE, Gary; Augustine, Liz; Lowe, Cris; Madhur, Jas; Software Engineering for Small Projects a RUP-Centred Approach; Addison Wesley. Janeiro 2004.

POSSAS, Paulo H., 2003, A informatização e a competência: Uma nova proposta para a ação dos profissionais desenvolvedores de sistemas tecnológicos. II WEIMIG – II Workshop de Educação em Computação e Informática do Estado de Minas Gerais. 2003. In www.inf.pucpcaldas.br/eventos/weimig2003/artigos/weimig2003. Em Novembro de 2004.

PRADO, Darci S. do, 2000, Gerenciamento de Projetos nas Organizações. Série Gerência de Projetos – Volume 1. 2000, Editora de Desenvolvimento Gerencial. Belo Horizonte – MG.

150

PRESSMAN, Roger S., 2001, Software engineering: a practitioner’s approach – Fifth Edition – McGraw Hill series in computer science– New York

QING WANG, 2000, A Modeling of Software Quality Management Base ISO 9001. The 4th World Multiconference on Systemics, Cybernetics and Informatics SCI 2000 and The 6th International Conference on Informatic Systems, Analysis and Sythesis ISAS.

RACHID, Alessandra, BRESCIANI FILHO, Ettore and GITAHY, Leda., 2001, Relations between small and large auto parts manufactures and the diffusion of production management practices. Gest. Prod., Dec. 2001, vol.8, no.3, p.319-333. ISSN 0104-530X.

RAMOS, Ricardo A., Pazin Anderson., Penteado, Rosângela Ap.D, 2003, Reengenharia de Sistemas Orientados a Objetos para Sistemas Orientados a aspectos. CLEI- Conferencia Latinoamericana de informatica 2003.

REZENDE, Denis A., 2000, A Tecnologia da informação aplicada a sistemas de informação empresarial. São Paulo, Editora Atlas S.A.

ROCHA, Ana R. C., Maldonado, José C., Weber, Kival C., 2001,Qualidade de Software: Teoria e Prática. São Paulo: Pratice Hall, 2001

ROBERTS JR, Tom L., Gibson, Michael L., Fields, Kent T., Rainer Jr, R. K., 1998, Factors that impact implementing a system development methodology. IEEE Transactions on software engineering, Vol.24, No. 8, Aug/1998.

ROULLIER, Ana Cristina, 2001, “Gerenciamento de Projetos de Software para Empresas de Pequeno Porte”, Tese de Doutorado, UFPE.

ROZENFELD, H., Amaral, D.C. ,2005, Modelagem de Empresas. NUMA – Núcleo de Manufatura Avançada – Escola de Engenharia de São Carlos. Disponível em: <http://www.numa.org.br/conhecimentos/conhecimentos_port/index.html>. Acesso em Janeiro de 2005.

RUSS, Melissa L., McGregor, John D., 2000, A software Development Process for Small Projects. IEEE. Septembre/October 2000.

SANTOS, Pedro C., 2001, O Processo de Adaptação da Estrutura Organizacional do Banco Central do Brasil do Período 1964 - 2000, Tese de Mestrado, UFSC-Programa de Pós-graduação em Engenharia de Produção, Setembro, Florianópolis - Santa Catarina. Disponível em <http://teses.eps.ufsc.br/tese.asp>. Acesso em Julho 2004.

151

SATO, Carlos E. Y., Dergint, Dario E.A., Hatakeyama, Kazuo, 2003, A utilização do escritório de projetos como instrumento para a melhoria da produtividade sistêmica das organizações, 2003, Disponível em <http://www.ppgte.cefetpr.br/semanatecnologia/comunicacoes>. Acesso em Janeiro 2004.

SCHULMEYER, G. Gordon, McManus, James I., 1999, Handbook of software quality assurance. 3rd edition. 1999. Prentice Hall – PTR. Upper Saddle River, NJ.

SEBRAE, 2004a, Serviço Brasileiro de Apoio às Micro e Pequenas Empresas, MPEs em números. Disponível em: <http://www.sebrae.com.br/br/aprendasebrae/mpeemnumeros.asp>. Acesso em Dezembro de 2004.

SEBRAE, 2004b, Serviço Brasileiro de Apoio às Micro e Pequenas Empresas, Fatores condicionantes e Taxa de mortalidade de Empresas no Brasil. Disponível em: <http://www.sebrae.com.br/br/mortalidade_empresas/index.asp>. Acesso em Dezembro de 2004.

SILVA, Odair J., Borges, Carlos A., Salviano, Clênio F., Crespo, Adalberto N., Roullier, Ana C., 2003, Aplicação da ISO/IEC TR 15504 na Melhoria do Processo de Desenvolvimento de Software de uma Pequena Empresa. V Simpósio Internacional de Melhoria de Processo de Software – SIMPROS. Recife – PE. 2003.

SILVA, Carlos A. V. da. , 2004, Redes de cooperação de micro e pequenas empresas: Um estudo das atividades logísticas no setor metalúrgico de Sertãozinho-SP. Dissertação (Mestrado) – Escola de Engenharia de São Carlos - Universidade de São Paulo, 2004. Disponível em <http://www.teses.usp.br>. Acesso em Janeiro de 2005.

SINGH, Raghu., 1999, International Standard ISO/IEC 12207 Software Life Cycle Processes. Federal Aviation Administration. 1999. In www.abelia.com/docs/ em Dezembro de 2004.

SOFTEX, 2002, A indústria de Software no Brasil 2002: Fortalecendo a Economia do Conhecimento / do Massachussets Institute of Technology – MIT; Brasil Coordenação geral Sociedade SOFTEX. – Campinas: SOFTEX, 2002. 80 p. : il. Capítulo Brasil do Projeto: Slicing the Knowledge-Based Economy (KBE) in India, China and Brazil: a tale of three software industries.

SOMMERVILLE, Iam., 2003, Engenharia de Software; Tradução André Maurício de Andrade Ribeiro. São Paulo: Addison Wesley, 2003.

SOUZA, Daniel; REIS, Dálcio, 2001, Otimização dos ativos acadêmicos - Uma condicionante à gestão tecnológica em PMES : O caso Paraná. In: Anais do IX Seminário de la Asociación Latinoamerica de Gestión Tecnológica, San Jose, Costa Rica, Outubro de 2001. Disponível

152

em <http://www.ppgte.cefetpr.br/cocentes/permanentes/dalcio/artigos.htm>. Acesso em Janeiro de 2004.

SWEBOK , 2004, A Guide to the Software Engineering Body of Knowledge. IEEE Version 2004. Disponível em <www.swebok.org>. Acesso em Dezembro de 2004.

TARTARELLI, Rubens V., WinckIer, Walter S., Kronmeyer Filho, Oscar R., 2004, Aprendizagem organizacional em fábricas de software. Disponível em <http://www.pmirs.org/PMI20_Frame.rtm>. Acesso em Junho de 2004.

TERENCE, Ana C. F.,2002, Planejamento Estratégico como ferramenta de competitividade na Pequena Empresa: Desenvolvimento e avaliação de um roteiro prático para o processo de elaboração do planejamento. Dissertação (Mestrado). Escola de Engenharia de São Carlos - Universidade de São Paulo, Disponível em <http://www.teses.usp.br>. Acesso em Janeiro de 2004.

TRAVASSOS, Guilherme H., Gurov, Dmytro, Amaral, Edgar A. G., 2002, Introdução à Engenharia de Software Experimental. RT-ES-590/02 – Programa de Engenharia de Sistemas e Computação – COPPE / UFRJ. Rio de Janeiro.

TRILLIUM, 2004, The Trillium Model. Mirror site of the University of Houston Clear Lake. Disponível em <http://www.sqi.gu.edu.au/trillium/> Acesso em Dezembro de 2004.

TSUKUMO, Alfredo N., Rêgo, Claudete M., Salviano, Clênio F., Azevedo, Glaucia F., Meneghetti, Luciano K., Costa, Márcia C. C., Carvalho, Mário B., Colombo, Regina M. T., 2004, Qualidade de Software: Visões de Produto e Processo de Software. 2ª Escola Regional de Informática – II ERI, UNIMEP, Junho de 1997. Disponivel em <http://www.psphome.hpg.ig.com.br/donwloads>. Acesso em Fevereiro de 2004.

UNHELKAR, Bhuvan., 2003, Process Quality Assurance for UML-Based Project. Addison Wesley. Boston USA. 2003.

VLIET, Hans V., 2002, Software Engineering: Principles and practice. Second Edition. John wiley & Sons ltd. Vrije Universiteit, Amsterdam.2000.

XEXEO, Geraldo, 2004, Qualidade Total, Material da disciplina Tópicos Especiais em Engenharia de Software. UFRJ. Disponível em <http://www.cos.ufrj.br/~xexeo/TEES/> Acesso em Dezembro de 2004.

WEBER, K. C.; Amaral, H. G.,1999, Software Quality and Productivity in Brazil. In: ISESS’99 4th International Software Engineering Standards Symposium, Curitiba, Brazil, 17-22 May.

153

WHITTAKER, James A., Voas, Jeffrey M., 2002, 50 Years of Software: Key Principles for Quality. IT Pro. November/December 2002. IEEE. 2002

ZIMMER, Barbara. 1989, Software quality and productivity analysis at Hewlett Packard. 1989 IEEE.

154

APÊNDICE I

UMA PERSPECTIVA HISTÓRICA DA QUALIDADE

“A vida só pode ser compreendida olhando-se para trás; mas só pode ser vivida olhando-se para frente." Soren Kierkegaard

I.1 O Direcionamento do Observador

A qualidade de software apresenta-se dentro de uma perspectiva histórica, envolvendo

várias perspectivas de visão do mundo. Ela é fruto da experiência e do êxito de abordagens

aplicadas em várias áreas do conhecimento. A intenção deste apêndice é situar a Qualidade, e

mais especificamente a qualidade de software, em um contexto de acontecimentos, que

influenciaram a sim próprios. As perspectivas envolvidas para esta análise serão idéias da

Administração, da Economia, da Produção/Indústria, da psicologia, e da própria qualidade.

I.2 Os Pontos de Convergência

Como elemento de controle para a montagem desta perspectiva, aponta-se a ordem

cronológica como elemento comum a todas as áreas analisadas.

I.3 As Linhas Mestras

As linhas mestras que irão orientar na elaboração da perspectiva estão relacionadas

com a complexidade dos elementos envolvidos na abordagem e nos estilos de gestão.

I.4 A Montagem da Perspectiva

A partir de pesquisas do surgimento dos principais conceitos que englobam a

Qualidade, outros fatos foram levantados e relacionados nessa mesma perspectiva temporal.

Os conceitos e os outros elementos serão resumidamente descritos a seguir. As fontes de

pesquisa foram: Picchi (1993), Côrtes (1998), Marcineiro (2001), Whittaker (2002), Xexeo

(2004), Critérios de Excelência (2004), e ISO (2005).

A Figura I.1 representa este relacionamento temporal. A “Fita Funcional ISO*”

apresenta um histórico de publicações de norma e padrões, que envolvem software e sistemas,

como se seguem:

• ISO 9000: Quality Management Systems : publicada em 1987, a partir da BS 5750

(1979 Inglaterra); foi revisada em 1994 e em 2000.

155

Figura I.1 Perspectiva Histórica da Qualidade

• ISO/IEC 6592: Information Technology – Guidelines for Documentation of

Computer – based Applications Systems; publicada em 1990 e revisada em 2000.

• ISO 9126: Software Engineering – Product Quality; publicada em 1992, e com suas

partes atualizadas em 2001, 2003 e 2004.

• ISO/IEC 12207: Information Technology – Software Life Cycle Processes;

publicada em 1995, revisada em 2002 (Amd 1) e em 2004 (Amd 2).

156

• ISO/IEC 15504: Information Technology – Process Assessment; publicada a partir do Projeto

SPICE em 1993; tornou-se a ISO/IEC 15504 em 2003, com partes revisadas em 2004.

• ISO/IEC 90003: Software Eengineering – Guidelines for the Application of ISO 9001:2000

to Computer Software; publicada em 1997 como ISO 9000-3, revisada em 2004.

• ISO/IEC TR 15271: Guide to ISO/IEC 12207 ; publicada em 1998.

• ISO/IEC 15288: Systems Engineering – System life cycle processes; publicada em 2002.

I.5 Considerações

Uma das abordagens importantes está descrita na Tabela I.1 e representa as quatro

grandes eras da atuação da qualidade, e podem resumir as tendências e os conceitos que foram

usados nesse trabalho. A proposta de um SGQ é situada entre a garantia da qualidade, através

de processos de auditoria, portanto ainda com o conceito de inspeção, processos do controle

estatístico da qualidade, mas com ênfase na evolução estratégica da qualidade. A Tabela I.2

representa a amplitude da abordagem da qualidade.

Tabela I.1 – Características das quatro grandes eras da Qualidade (XEXEO, 2004)

Inspeção

Controle Estatístico da

Qualidade

Garantia da Qualidade

Gestão Estratégica da Qualidade

Objetivo Detecção Controle Coordenação Impacto Estratégico Visão sobre Qualidade

Problema para resolver Problema para resolver Problema para resolver

Oportunidade estratégica

Ênfase Uniformidade Uniformidade Prevenção Mercado e Consumidor Métodos Calibração e medidas Ferramentas e técnicas

estatísticas Programas e sistemas Planejamento estratégico

Papel dos profissionais da

qualidade

Inspeção, classificação, contagem e ordenação

Manutenção e aplicação de métodos

estatísticos

Medidas e planejamento da

qualidade

Estabelecimento de objetivos, educação e

treinamento Responsabilidade

por qualidade Departamento de inspeção Departamento de

qualidade e produção Todos Todos, com forte liderança

da alta administração Orientação e abordagem

Qualidade inspecionada Qualidade controlada Qualidade construída Qualidade gerenciada

Tabela I.2 – Amplitudes da Qualidade (MARCINEIRO, 2001)

Amplitude Descrição Controle da Qualidade

Utilização de técnicas operacionais para atender aos requisitos da qualidade. O foco do controle é o produto ou o serviço examinados.

Sistema da Qualidade

Estrutura organizacional, responsabilidade, procedimentos, processos e recursos para implementação da gestão da qualidade. O foco é o processo de trabalho.

Garantia da Qualidade

Todas as ações planejadas e sistematizadas, necessárias para garantir que um produto ou serviço atenda aos requisitos da qualidade. O foco também é o processo.

Gestão da Qualidade

Aspecto da função geral que determina e implementa a política da qualidade. O foco é a organização como um todo.

Visão Estratégica da Qualidade

A qualidade entendida como caminho para assegurar à organização uma vantagem competitiva de mercado. O foco é o mercado. Para tanto, poderão ser necessários trabalhos de revisão da Missão, Visão e Estrutura Organizacional.

157

APÊNDICE II

O RETRATO DAS MPMEs BRASILEIRAS

II.1 O Porte das Empresas

Para estimar o porte das empresas, podem-se adotar critérios de ordem qualitativa ou

quantitativa. Os qualitativos referem-se à estrutura interna da empresa, são mais subjetivos,

difíceis de definir e de mensurar, mas representam com sua visão dinâmica e com maior

veracidade, a natureza da empresa e seus aspectos administrativos. Como exemplos têm-se:

tecnologia empregada, estrutura da organização, nível de especialização da mão-de-obra,

utilização de técnicas administrativas, entre outros.

Os critérios quantitativos são mais diretamente definidos e fáceis de medir, são, em

geral, de ordem econômica e/ou contábil e têm uma visão estática da realidade da

organização. Como exemplos, têm-se: o número de empregados, o faturamento, o lucro, os

investimentos, entre outros tantos (TERENCE, 2002; MIGLIATO, 2004).

Pela facilidade de levantamento e uma vez que são os mais facilmente mensuráveis,

adotou-se o critério quantitativo para evidenciar a classificação do porte das empresas. A

Tabela II.1 mostra uma relação entre o valor da receita e o número de pessoas ocupadas e os

órgãos definem critérios de enquadramento do porte de empresas no Brasil.

Tabela II.1 – Critérios de enquadramento do porte de empresas brasileiras

Critérios de Enquadramento Valor da receita (R$) No. de pessoas ocupadas BNDES

Micro Pequena

Média Grande

Receita operacional anual bruta Até 1.200 mil

De 1.200 mil a 10.500 milDe 10.500 mil a 60.000 mil

Mais de 60.000 mil

Const.& Ind Com & Serv SEBRAE Micro

Pequena Média

Grande

Até 19

De 20 a 99 De 100 a 499

A partir de 500

Até 9De 10 a 49 De 50 a 99

A partir de 100Lei No.9841 de 05/10/1999

Micro Pequena

Decreto 5.028/2004 de 31/03/2004 Micro

Pequena

Até 244.000,00

De 244.000,00 a 1.200 mil

Até 433.755,14De 433.755,14 a 2.133.222,00

MCT Micro

Pequena Média

Grande

Até 9

De 10 a 49De 50 a 99

A partir de 100

158

A Tabela II.2 mostra algumas referências para a definição do porte das empresas em

algumas partes do mundo. A tabela foi formulada a partir de documento do MDIC (2002)

(Ministério do Desenvolvimento, Indústria e Comércio Exterior).

Tabela II.2 – Porte de empresas no mundo (MDIC, 2002)

Micro Pequena Média Indústria Comércio e

Serviços Indústria Comércio e Serviços Indústria Comércio

e Serviços

Número de empregados 1 – 10 1 – 5 11 – 40 6 – 30 41– 200 31 – 80

Mer

cosu

l

Faturamento anual em US $ 400 mil 200 mil 3,5

milhões 1,5

milhões 20 milhões 7 milhões

Agropecuária 270 mil 1,8 milhão 10,8 milhão Indústria e Mineração 900 mil 5,4 milhão 43,2 milhão

Comércio 1,8 milhão 10,8 milhão 86,4 milhão

Fatu

ram

ent

o an

ual e

m

Peso

Serviços 450 mil 3,24 milhão 21,6 milhão Arg

entin

a

Número de empregados Até 4 5 – 50 51 a 300 Manufatureiras e

Mineração Até 500 empregados

Não manufatureiras (US $) Receita anual de

6 milhões

Esta

dos

Uni

dos

Serviços de informática Faturamento médio anual de 21 milhões

Número de empregados Até 9 10 – 49 50 – 249 Volume de Negócios

ou Balanço anual total (Euros)

7 milhões

5 milhões

40 milhões

27 milhões Uni

ão

Euro

péia

Independência administrativa % 25 25

Irlan

da

Número de Empregados Até 10 11 – 50 51 – 250

Irã

Número de empregados Até 9 10 – 49 50 – 99

Número de empregados 50 100

Isra

el

Faturamento anual US $ 5 milhões 20 milhões

Investimentos em ativos US $ 208.334,00

Índi

a

Movimento anual de negócios da empresa Até 625.000,00

Ind. Const. Civil e Transportes Até 100 empregados

Agricultura, C&T Até 60 empregados Comércio varejo e

Serviços Até 30 empregados Rús

sia

Outros Até 50 empregados

Pequenas Médias Grandes Megaempresas

Chi

na

Faturamento US $

De 602 mil a 6,2 milhões

De 6,2 milhões a 12,05 milhões

De 12,05 milhões a 24,09 milhões

De 24,09 milhões até

60,24 milhões

159

II.2 A Distribuição Do Mercado

Várias pesquisas e estudos apontam a participação das MPMEs no estrato produtivo

brasileiro, entre elas, o estudo divulgado pelo IBGE em 2003 (IBGE,2003). Essa pesquisa

mostra que as micros e pequenas empresas (MPEs), nas atividades de comércio e prestação de

serviços, são um importante segmento na geração de emprego e renda, uma vez que

representam 80% de todo o segmento, correspondendo a 22,3 % em relação à receita total e

60,8 % em relação ao número de pessoal ocupado do setor de comércio e serviços, incluindo

as médias e grandes empresas (Figura II.1, II.2, e II.3).

Figura II.1 – Participação das MPEs na receita do setor de comércio e serviços – 1985/2001 (IBGE, 2003)

Figura II.2 – Participação das MPEs – pessoal ocupado do setor de comércio e serviços – 1985/2001 (IBGE, 2003)

Ainda a partir de IBGE (2003), a Figura II.3 estratifica os setores de serviços levantados

no ano de 2001. Observar que as atividades de informática englobam: Consultoria em

sistemas de informática, Desenvolvimento de programas de informática, Processamento de

dados (inclusive digitação), Atividades de banco de dados, Manutenção e reparação de

máquinas de escritório e de informática.

160

Figura II.3 – Participação dos segmentos nas MPEs de prestação de serviços – 2001 (IBGE, 2003)

Pelos dados do SEBRAE (2004a) tendo por referência sua classificação para o porte

das empresas, seguem a Tabela II.3 e Tabela II.4 com os valores e suas respectivas

representações gráficas (Figura II.4 e Figura II.5).

Tabela II.3 – Número de empresas formais no Brasil, por porte e setor de atividade – 2002 (SEBRAE,2004a)

Micro Pequena Média Grande Total Atuação Nº % Nº % Nº % Nº % Nº % Indústria 439.013 90,7 37.227 7,7 6.548 1,4 1.430 0,3 484.218 100,0 Construção 116.287 91,9 8.282 6,5 1.694 1,3 221 0,2 126.484 100,0 Comércio 2.337.889 95,4 105.891 4,3 4.862 0,2 2.846 0,1 2.451.488 100,0 Serviços 1.712.418 92,3 122.609 6,6 10.548 0,6 10.605 0,6 1.856.180 100,0 TOTAL 4.605.607 93,6 274.009 5,6 23.652 0,5 15.102 0,3 4.918.370 100,0

Figura II.4 – Número de Empresas no Brasil (percentual) (SEBRAE, 2004a)

161

Tabela II.4 – Número de pessoas ocupadas nas empresas formais, por porte e setor de atividade – 2002 (SEBRAE, 2004a)

Micro Pequena Média Grande Total Atuação Nº % Nº % Nº % Nº % Nº % Indústria 1.571.608 23,7 1.471.254 22,2 1.322.673 20,0 2.256.721 34,1 6.622.256 100 Construção 356.660 27,3 339.777 26,0 327.135 25,0 284.005 21,7 1.307.577 100 Comércio 4.664.545 58,9 1.772.233 22,4 327.443 4,1 1.161.426 14,7 7.925.647 100 Serviços 3.374.388 28,8 2.206.611 18,8 722.852 6,2 5.402.593 46,2 11.706.444 100 Total 9.967.201 36,2 5.789.875 21,0 2.700.103 9,8 9.104.745 33,0 27.561.924 100

Figura II.5 – Números de pessoas ocupadas (percentual) (SEBRAE, 2004a)

O MCT (2001) através de uma pesquisa, produziu informações bastante interessantes ao

descrever um grupo de empresas incubadas, mostrando-nos uma forma de aproximação da

academia, com suas pesquisas e anseios para aplicá-las, e do ambiente de produção.

Certamente uma das maiores contribuições que esse grupo de empresas (as incubadoras)

introduz na sociedade, é uma nova cultura empresarial que valoriza aspectos que são relevados

pela maioria do universo de pequenas empresas brasileiras e até mesmo por alguns grandes

grupos empresariais. Essa afirmação pode ser facilmente verificada por algumas das

conclusões da pesquisa relacionadas a seguir: - Cerca de 30% dos empreendedores possuem

pós-graduação; - Consideram e valorizam a relação com universidades e institutos de pesquisa;

- Desenvolvem atividades sistemáticas de inovação, com investimentos elevados com P&D; -

Demonstram preocupação com a busca de informações e com a proteção da tecnologia através

do sistema de patentes; - Investem em média cerca de 6% do faturamento em treinamento; -

Cerca de 30% das empresas oferecem participação nos lucros para os funcionários; -

Consideram importante a elaboração e revisão periódica dos planos de negócio. Uma outra

característica do grupo é que a grande maioria dos sócios, normalmente reunidos em grupos de

2 ou 3, possui formação técnica (55% em engenharia ou informática) e com grande

concentração de jovens (54% tinham menos de 30 anos quando criaram a empresa). A

passagem por uma incubadora contribuiu inegavelmente para que estes empresários buscassem

uma permanente capacitação e complementação de sua formação em áreas voltadas para o

162

empreendedorismo e negócios. A característica de juventude se repete entre os empregados,

onde 4 em cada 5 funcionários também têm menos de 30 anos. Outro destaque desse grupo de

empreendedores é que cerca da metade deles já havia tido alguma experiência anterior na área

de negócios.

II.3 Aspectos Comuns à Realidade das MPMEs

Um grande número de especificidades ou características relacionadas a MPMEs pode

ser observado no Quadro II.1 e Quadro II.2, que foram baseados em IBGE (2003), PAS

(2002), La Rovere (2004), Silva (2003), MCT (2001) e Mendy (2003). Não necessariamente

todas essas características apresentem-se ao mesmo tempo em todas as MPMEs. No entanto,

elas refletem uma ocorrência mais comum neste porte de organização. As características

presentes no ambiente das micros, pequenas e médias empresas foram classificadas em

relação aos Aspectos de aplicação de disciplinas, e Aspectos administrativos.

ASPECTOS DE APLICAÇÂO DE DISCIPLINAS

1. Falta de experiência para organizar a produção, de credibilidade do empresário; 2. Estratégia e tomada de decisão intuitiva e pouco formalizada; 3. Inexistência de dados quantitativos e não existência de indicadores de avaliação de

performance produtiva; 4. Sistema de informação simples; 5. Dificuldade em comunicar ou em distribuir as tarefas entre responsáveis; 6. Dificuldade em encontrar as pessoas com as qualificações necessárias ou perda de

colaboradores importantes; 7. Impacto de eventos conjunturais negativos (crise cambial ou setorial); 8. Falta de experiência para a comercialização (impossibilidade de garantir a

assistência pós-venda, falta de estrutura comercial sólida, fraca visibilidade no mercado, apresentando desarticulação entre os sistemas de compras, de produção e de vendas);

9. Dificuldade de definição dos objetivos de médio ou longo prazo; 10. Horizonte de planejamento muito curto, pois seus administradores ficam presos num

círculo vicioso onde a resolução de problemas diários impede a definição de estratégias de longo prazo e de inovação;

11. Alto grau de autonomia na tomada de decisões; 12. Racionalidade econômica, política e familiar; 13. Não organizam informações relacionadas à empresa de forma adequada; 14. Ausência de planos formais; 15. Dependência diante de certos funcionários; 16. Compreensão equivocada do que os clientes querem.

Quadro II.1 – Características das MPMEs que envolvem a aplicação de disciplinas

163

ASPECTOS ADMINISTRATIVOS

1. Baixa intensidade de capital, que é financiado, basicamente, pelos proprietários; 2. Altas taxas de natalidade e de mortalidade: demografia elevada; 3. Forte presença de proprietários, sócios e membros da família como mão-de-obra ocupada nos

negócios; 4. Poder decisório centralizado; 5. Estreito vínculo entre os proprietários e as empresas, muitas vezes não se distinguindo, em

termos contábeis e financeiros, pessoa física e jurídica; 6. Registros contábeis pouco adequados; 7. Contratação direta de mão-de-obra; 8. Alta rotatividade de colaboradores provocando retrabalhos e falhas de qualidade 9. Utilização de mão-de-obra sem experiência, não qualificada ou semiqualificada, nos setores

de comércio atacadista, nas atividades de informática e nos serviços técnico-profissionais prestados à empresa, tem-se o uso intenso de TI e/ou forte presença de mão-de-obra qualificada com formação profissional universitária e trajetória de capacidade inventiva;

10. Baixo investimento em inovação tecnológica; 11. Maior dificuldade de acesso ao financiamento de capital de giro; 12. Relação de complementaridade e subordinação com as empresas de grande porte; 13. Dificuldade de acesso ao mercado de ações devido ao alto custo de entrada, ou de abertura do

capital, rentabilidade financeira limitada apesar do faturamento, custos para demanda de crédito, prazo lento de amortização;

14. Demora no recebimento dos pagamentos, que gera uma inadimplência crônica; 15. Carga tributária elevada para as receitas geradas. 16. Tomam decisões de uma maneira reativa; 17. Estão proporcionalmente menos engajadas em atividades inovadoras que as grandes empresas;18. Flexibilidade e rapidez às demandas do mercado; 19. Heterogeneidade de universo de atuação e mercado; 20. Possibilidade de criação de laços de cooperação através de alianças estratégicas e/ou criação

de clusters (aglomerações setoriais e espaciais de empresas); 21. Área de atuação limitada, praticamente restrita à sua localização; 22. A sua atividade produtiva não ocupa posição de destaque em relação ao mercado; 23. Ter falta de poder de barganha nas negociações de compra e venda; 24. Ausência de uma política clara de desenvolvimento de fornecedores; 25. Insuficiência da estratégia comercial. Ações insuficientes para a penetração no mercado; 26. Capacidade de gerar uma classe empresarial genuinamente nacional aumentando o estoque de

conhecimento nacional; 27. Insuficiência de capital inicial próprio, capacidade de autofinanciamento limitada,

rentabilidade financeira medíocre; 28. Fraca capacidade de geração de recursos, receitas irregulares, crise de liquidez, dificuldade de

capitalização e de acesso a financiamento; 29. Dificuldade de avaliação da demanda e do mercado potencial (previsão exageradamente

otimista, leque de produtos insuficiente para rentabilizar a distribuição, desaparecimento repentino de um grande comprador, cálculo errado do preço e margens beneficiárias);

30. Fraca maturidade organizacional; 31. Estrutura simples e leve; 32. Fraca especialização; 33. Horizonte temporal de curto prazo; 34. Propensão a riscos calculados; 35. Dificuldades para competir no que se refere a prazos e custos dos produtos; 36. São um campo de treinamento de mão-de-obra especializada e formação de empresários; 37. Visão subestimada da concorrência; 38. Situação extra-organizacional fora de seu controle.

Quadro II.2 – Características das MPMEs que envolvem aspectos administrativos

164

II.4 Outros Aspectos a serem Fortemente Avaliados

Apontando o grande número de insucessos nos empreendimentos do segmento de

MPMEs, o SEBRAE (2004b) mostra que os dados da pesquisa permitem concluir, reunindo

respostas estimuladas e espontâneas, que as causas da alta mortalidade das empresas no Brasil

estão fortemente relacionadas, em primeiro lugar, a falhas gerenciais na condução dos

negócios, seguida de causas econômicas conjunturais e tributação (Tabela II.5). As falhas

gerenciais, por sua vez, podem ser relacionadas à falta de planejamento na abertura do

negócio, levando o empresário a não avaliar de forma correta, previamente, dados importantes

para o sucesso do empreendimento, como a existência de concorrência nas proximidades do

ponto escolhido, a presença potencial de consumidores, dentre outros fatores.

Tabela II.5 – Causas das dificuldades e razões para o fechamento das empresas (SEBRAE, 2004b)

165

II.5 Considerações

Os assuntos administrativos e a própria estrutura organizacionais são elementos

importantes que devem chamar a atenção da direção da empresa. Tão importantes quanto o

próprio domínio e o conhecimento envolvidos na produção, as tarefas administrativas

precisam ser compreendidas, bem estruturadas e coerentes com o porte e as necessidades da

empresa. A Tabela II.6 sugere um modelo de estruturação organizacional.

Tabela II.6 – Modelo de estruturação organizacional adaptada de (TERENCE, 2002)

Porte Representação Características

Micro Não existe separação de níveis hierárquicos. O dirigente utiliza a maior parte do tempo em tarefas operacionais do empreendimento. O tempo restante com tarefas funcionais.

Pequena

A empresa já necessita de uma organização administrativa, exige um nível administrativo entre o “chefe” e os trabalhadores. O dirigente tem a maior parte do tempo nas áreas funcionais e o restante em tarefas operacionais e da direção.

Média O cargo de cúpula exige dedicação em tempo integral. A inaptidão, na resolução dos problemas de organização administrativa, é uma das causas mais freqüentes e graves de dificuldades deste estágio.

Grande A função de direção suplanta a capacidade de uma pessoa, dividindo-se em coordenação de níveis médios e estabelecimento de objetivos empresariais.

166

APÊNDICE III

MODELOS QUE ENVOLVEM A QUALIDADE ”Certa vez afirmou o mestre Confúcio: ‘Um homem nunca pode receber ajuda do que não conhece. Se ele não entender a natureza não compreenderá Deus. Da mesma maneira, se não sabe quem está a seu lado, não terá amigos. Sem amigos não pode estabelecer um plano. Sem plano não consegue dirigir ninguém. Sem direção o

país mergulha no escuro. E, nem os dançarinos sabem com que pé deverão dar o próximo passo. ’.” Conto Chinês

III.1 INTRODUÇÃO

A identificação da produção de software como um processo de produção industrial e em

conformidade com processos amadurecidos nos leva à busca pela adoção e pelo refinamento

dos processos produtivos. Serão apresentados vários modelos de processos bastante

referenciados, que têm promovido o aprimoramento de produtos e produtores de software. A

forma de definição do modelo é importante e identifica a linha seguida para sua criação.

III.2 ELEMENTOS PARA A ANÁLISE

Para padronizar a abordagem e criar uma base comparativa entre os processos, os

aspectos no Quadro III.1 serviram de direcionamento e, sempre que possível, estarão presentes

na análise de cada processo em questão.

MODELO O direcionamento do observador:

Aponta o ambiente de aplicação do modelo. Os pontos de convergência:

Apontam conceitos e outros modelos que estão relacionados com o modelo em questão, podendo ser conceitos externos aplicados ou conceitos definidos pelo próprio modelo.

As linhas mestras: Apontam os elementos que distinguem sua abordagem e estabelecem as suas características.

A montagem da perspectiva: Aponta os aspectos que envolvem a implantação do modelo, levando em conta: Estrutura para implantação, Tempo, Custo, Versões, responsáveis pela elaboração e atualização do modelo, e Certificação Oficial.

A perspectiva montada: Aponta as vantagens da aplicação do modelo, Aponta as desvantagens da aplicação do modelo e as fontes de pesquisa.

Quadro III.1: Descrição da abordagem dos modelos

III.3 A APRESENTAÇÃO DOS MODELOS

Os modelos pesquisados são, ou foram em um período, adotados ou referenciados

globalmente e estão dentro da seguinte classificação por sua origem de elaboração: (i) oriundos

a partir de esforços mundiais reunidos e compartilhados (e.g.: normas ISO); (ii) oriundos a

partir das necessidades e exigências de grandes clientes (e.g.: modelos do SEI); e (iii) oriundos

167

de esforços individuais e que se tornaram modelos de referência para uma classe de produtos ou

com abrangência maior. A apresentação será feita através de quadros individualizados.

III.3.1 Oriundos de Esforços Próprios

TRILLIUM O direcionamento do observador:

Usado pela Bell Canada para avaliar o desenvolvimento de produtos e dar suporte à capacidade de fornecedores de telecomunicações (em prospecção, ou já existentes) ou de produtos baseados em tecnologia da informação. Pode ser usado como referência em um programa de melhoria interna de capacidade. O modelo cobre os aspectos do ciclo de vida do desenvolvimento do software, a maioria das atividades de desenvolvimento e suporte de produtos e sistemas, e um número significativo de atividades relacionadas com o marketing. Atende a quatro diferentes propósito de aplicação: 1) Em avaliação de capacidade, 2) Em avaliação de capacidade de associação (cliente/fornecedor), 3) Em auto-avaliação de capacidade e 4) Em programa de melhoria contínua.

Os pontos de convergência: TQM – Total Quality Management (Gerência da Qualidade Total), Ciclo PDCA (Planejar, Fazer, Controlar e Agir), Capability (Capacidade); Modelo Baseado no CMM-SW, ISO 9001:1994, ISO 9000-3, nos critérios do Prêmio Nacional da Qualidade Malcolm Baldrige (USA), na coleção de padrões IEEE para engenharia de software (1993) e na IEC 300:1984.

As linhas mestras: Baseado no CMM, possui a seguinte estrutura hierárquica: Área de capacidade, Roteiros, Níveis, e Práticas. Para cada Área de capacidade há um ou mais roteiros; as Práticas estão distribuídas em cada um dos cinco níveis. Cada prática referencia o modelo de origem. Suas sete áreas de capacidade e seus respectivos roteiros são:

Área de Capacidade Roteiro 1. Qualidade de Processo Organizacional 1.1 Gerência da Qualidade

1.2 Engenharia de Processo de Negócio 2. Gerência e Desenvolvimento de Recursos Humanos 2.1 Gerência e Desenvolvimento de Recursos Humanos

3. Processos 3.1 Definição de Processos 3.2 Gerência de Tecnologia 3.3 Engenharia e Melhoria de Process 3.4 Medições

4. Gerência

4.1 Gerência de Projetos 4.2 Gerência de Subcontratação 4.3 Relacionamento Cliente-Fornecedor 4.4 Gerência de Requisitos 4.5 Estimativas

5. Sistema da Qualidade 5.1 Sistema da Qualidade

6. Práticas de desenvolvimento

6.1 Processos de Desenvolvimento 6.2 Técnicas de Desenvolvimento 6.3 Documentação Interna 6.4 Verificação & Validação 6.5 Gerência de Configuração 6.6 Reuso 6.7 Gerência da Confiabilidade

7. Ambiente de Desenvolvimento 7.1 Ambiente de Desenvolvimento

8. Suporte ao Cliente

8.1 Sistema de Reação a Problemas 8.2 Engenharia de Usabilidade 8.3 Modelagem do Custo do Ciclo-de-vida 8.4 Documentação do Usuário 8.5 Engenharia de Cliente 8.6 Treinamento de Usuários

A montagem da perspectiva:

O material é de domínio público. Não foram encontradas evidências do tempo necessário para sua implantação. Não foram encontradas evidências do custo de sua implantação. O modelo foi iniciado em 1982; a versão 1.0 Draft foi edita em Ago/1991; a versão 3.0 (atual) foi editada em Dez/1994. Não foram encontradas evidências de Certificação Oficial. É o resultado do projeto da parceria entre Bell Canada, Northem Telecom e Bell-Northem Research.

A perspectiva montada: Adaptado a partir de modelos consagrados, e com uma visão de negócio, sendo voltado para projetos de grande porte. Sua atualização foi descontinuada. Informações coletadas em Dez/2004 na web http://www.sqi.gu.edu.au/trillium/ (TRILLIUM,2004).

Quadro III.2: Trillium

168

SQPA - HP O direcionamento do observador:

Usado pela Hewlett Packard (HP) para avaliar o estado de um laboratório-HP, fazer comparações com o desempenho de outros laboratórios-HP e com informações já coletadas do desempenho geral da indústria de software. O SQPA, aplicado por um grupo externo ao laboratório, é muito mais um modelo de análise do que de auditoria, pois identifica os pontos fortes e fracos do laboratório, identificando áreas para melhoria e fazendo recomendações.

Os pontos de convergência: TQC – Total Quality Control (Controle da Qualidade Total), Benchmark, conceitos que envolvem as áreas de marketing, suporte industrial e vendas, considerações da cultura da empresa, agentes de mudança, metodologias e a participação de fatores humanos nos negócios. O protótipo de Caper Jones foi adaptado para a realidade corporativa da HP

As linhas mestras: Seu foco compreendem oito áreas chaves que impactam no desenvolvimento de software.

Áreas chaves 1. Metodologias 2. Mudança de Staff 3. Controle e Gerência de Projetos 4. Ambiente de Programação 5. Ferramentas 6. Remoção e Prevenção de Defeitos 7. Ambiente Físico 8. Medições

Com base em questões padronizadas, são coletadas informações verbais e numéricas, através de entrevistas e questionários. As questões envolvem a descrição de ferramentas, de métodos, de processos de desenvolvimento, de avaliação de atividades e percepção sobre estes e de outros elementos do ambiente de desenvolvimento Os passos do processo são :

Processo de avaliação Duração1. Pedido de avaliação pelo laboratório. 2. Reuniões inicias para troca de informações (tamanho, modelo organizacional e descrição dos produtos). +/- 2 dd

3. Entrevistas formais para registro de respostas numéricas e narrativas do questionário padrão. +/- 2 dd4. Análise inicial, incluindo comparação estatística com os Laboratórios-HP e a indústria. +/- 2 dd5. Apresentação dos resultados aos gerentes de P&D (pontos fortes e fracos, restrições, gráficos comparativos e recomendações de melhoria) nas oito áreas chaves. +/- 2 h

6. Diagnóstico do Laboratório (conferência dos resultados com especialistas para prescrever atividades específicas). 3 a 4 S

7. Resultado arquivado na base de dados. 8. Resultado resumido em relatório escrito e enviado à gerência de P&D.


O processo foi divulgado não detalhando o questionário e as entrevistas. Não foram encontrados dados sobre o tempo necessário para sua implantação. Sabe-se que em torno de 4 semanas os resultados são divulgados. Não foram encontradas dados do custo de sua implantação. O modelo foi desenvolvido a partir de 1984 e, até 1989, ainda era utilizado. Não confere uma certificação oficial, mas é gerado um relatório de melhoria do processo.

A perspectiva montada: Adaptado a partir de comparações com resultados tabelados. É baseado em entrevistas e respostas do questionário padrão, aplicado em projetos e laboratórios de qualquer porte da HP; analisa as oito áreas chaves envolvidas no desenvolvimento de software. Informações coletadas de Zimmer (1989).

Os Resultado de cada área chave são mapeados no gráfico radar e têm as seguintes Interpretações em três intervalos: 1 – 2.5 : Acima dos padrões, contribuição para o sucesso do projeto; 2.6 – 3.5 : Normal; 2.6 – 5.0 : Deficiente, ou risco para o sucesso do projeto

Quadro III.3: SQPA-HP

169

III.3.2 Oriundos de esforços mundiais reunidos

Família ISO 9000

O direcionamento do observador: A Série ISO 9000 pode ser vista como uma família composta de normas, diretrizes, cadernos, relatórios técnicos (TR) e especificações técnicas (TS), que desde sua primeira publicação (1987) tem obtido reputação (e adoção) mundial para o estabelecimento de Sistemas de Gestão da Qualidade (SGQ).

Os pontos de convergência: TQM – Total Quality Management (Gerência da Qualidade Total), Ciclo PDCA (Planejar, Fazer, Controlar e Agir), e na identificação de oito princípios de gestão da qualidade:

Princípios para gestão da qualidade 1. Foco no cliente 5. Abordagem sistêmica para a gestão 2. Liderança 6. Melhoria contínua 3. Envolvimento de pessoas 7. Abordagem factual para tomada de decisão 4. Abordagem de processos 8. Benefícios mútuos nas relações com os fornecedores

As linhas mestras: Composição Propósito

ISO 9000:2000 - Sistemas de gestão da Qualidade – Fundamentos e vocabulário. Estabelece termos e definições fundamentais da família 9000.

ISO 9001:2000 - Sistema de gestão da qualidade - Requisitos Avalia a capacidade de uma organização em atingir os requisitos do cliente e regulamentares. É a norma certificadora do SGQ.

ISO 9004:2000 - Sistema de gestão da qualidade – Diretrizes para melhoria de desempenho. Guia para a melhoria contínua do SGQ de uma organização.

ISO 19011:2002 - Diretrizes para auditoria de sistemas de gestão da qualidade e/ou ambiental.

Verificação da capacidade do sistema em atingir os objetivos da qualidade definidos. Usada internamente e na auditoria de fornecedores.

ISO 10005:1995 - Gestão da qualidade – Diretrizes para planos da qualidade. ISO/FDIS 10005 - Sistema de gestão da qualidade – Diretrizes para Planos da Qualidade.

Diretrizes para auxiliar na preparação, análise crítica, aceitação e revisão de planos da qualidade. (FDIS – Final Draft International Standard).

ISO 10006:2003 – Sistema de gestão da qualidade – Diretrizes para gerência da qualidade em projetos.

Auxilia a organização a assegurar a qualidade de processos e produto do projeto.

ISO 10007:2003 - Sistema de gestão da qualidade – Diretrizes para gestão da configuração.

Assegura que um produto complexo continue a funcionar, quando componentes são alterados individualmente.

ISO 10012:2003 - Sistema de gestão de medições – Requisitos para processo de medição e equipamentos de medida.

Indica as características principais de um sistema de calibração para assegurar que as medições sejam feitas de forma precisa.

ISO 10013:2001 - Diretrizes para documentação de sistemas de gestão da qualidade.

Desenvolvimento e manutenção de manuais da qualidade, feitos para necessidades específicas.

ISO/TR 10014:1998 - Diretrizes para a gestão econômica da qualidade. ISO/DIS 10014 - Sistema de gestão da qualidade – Diretrizes para a realização de benefícios financeiros e econômicos.

Como atingir benefícios econômicos e financeiros da aplicação do sistema de gestão.

ISO 10015:1999 – Gestão da qualidade – Diretrizes para treinamento.

Desenvolvimento, implementação, manutenção e melhoria das estratégias e sistemas para treinamento que afetam a qualidade dos produtos.

ISO 90003:20034 – Engenharia de Software - Diretrizes para a aplicação da ISO 9001:2000 para software.

Orientação para organizações na aplicação da ISO 9001:2000 para a aquisição, fornecimento, desenvolvimento, operação e manutenção de software e serviços de suporte relacionados.

Existem ainda muitos outros documentos que estão voltados à orientação da ISO 9001 em uma série de aplicações

Aplicação na educação, nas indústrias automotivas, de aparelhos e laboratórios médicos, de petróleo e de alimentos e bebidas, etc.

A montagem da perspectiva: O material é de domínio público, mas liberado após pagamento. A série 9000 reflete as abordagens de gestão nas práticas organizacionais e tem como normas primárias as quatro primeiras normas citadas acima. Não foram encontradas evidências do tempo necessário para sua implantação, uma vez que existem vários módulos independentes. O custo de sua implantação envolveria a aquisição dos materiais, eventual consultoria e a certificação pela ISO 9001. A série foi desenvolvida a partir de 1987. Cada componente tem uma versão integrada, mas independente. A Certificação Oficial dá-se somente pela ISO 9001. É elaborada e mantida pela ISO (International Organization for Standardization) (ISO, 2005).

A perspectiva montada: De aplicação genérica é adotada como padrão internacional. Envolve a capacitação total para a garantia da qualidade de produtos e serviços, sugerindo modelos para as atividades e áreas complementares para essa capacitação. A série procura adaptar o modelo genérico da ISO 9001 para modelos específicos de produção (entre eles o desenvolvimento de software com ISO 90003:2004). Informações retiradas da ISO (2005) e de Mello (2002).

Quadro III.4: Família ISO 9000

170

Quadro III.5: ISO 9000:2000

ISO 9000:2000 O direcionamento do observador:

A ISO 9000:2000 descreve os fundamentos de sistemas de gestão da qualidade (SGQ) e define os termos relacionados. A implementação e a manutenção de um SGQ pode ser o fundamento para sucesso das organizações, pois, baseado na melhoria contínua do desempenho, o SGQ deve levar em consideração, simultaneamente, as necessidades de todas as “partes interessadas” envolvidas nos processos de produção (cliente, colaboradores, e fornecedores).

Os pontos de convergência: Fazendo parte da Família ISO 9000, a ISO 9000 (2000) tem os mesmos pontos de convergência.

As linhas mestras: A Norma é descrita em 4 itens e um anexo que estão resumidos abaixo.

0. INTRODUÇÃO 0.1. Generalidades 0.2. Princípios de gestão da qualidade

1. OBJETIVO E CAMPO DE APLICAÇÃO 2. FUNDAMENTOS 3. TERMOS E DEFINIÇÕES

2.1. Justificativas para sistemas de gestão da qualidade. 3.1 Relacionados com a qualidade: qualidade, requisito, classe, satisfação do cliente, capacidade,

2.2. Requisitos para SGQ e requisitos para produtos.

3.2 Relacionados com a gestão: sistema, sistema de gestão, SGQ, política da qualidade, objetivo da qualidade, gestão, Alta Direção, gestão da qualidade, planejamento da qualidade, controle da qualidade, garantia da qualidade, melhoria da qualidade, melhoria contínua, eficácia, eficiência.

2.3. Abordagem de sistema de gestão da qualidade. 3.3 Relacionados com a organização: Organização, estrutura organizacional, infra-estrutura, ambiente de trabalho, cliente, parte interessada.

2.4. Abordagem de processos. 3.4 Relacionados com o processo e o produto: processo, produto, empreendimento, projeto e desenvolvimento, procedimento.

2.5. Política da qualidade e objetivos da qualidade. 3.5 Relacionados com as características: característica, característica da qualidade, garantia de funcionamento e rastreabilidade.

2.6. Função da Alta Direção no SGQ.

3.6 Relacionados com a conformidade: conformidade, não-conformidade, ação preventiva, ação corretiva, correção, retrabalho, reclassificação, reparo, refugo, concessão, permissão de desvio e liberação.

2.7. Documentação. 2.7.1 Valor da documentação. 2.7.2 Tipos de documentos usados em SGQ’s.

3.7 Relacionados com a documentação: informação, documento, especificação, manual da qualidade, plano da qualidade e registro.

2.8. Avaliação de SGQ’s. 2.8.1 Processos de avaliação do SGQ. 2.8.2 Auditoria do SGQ. 2.8.3 Análise crítica de SGQ. 2.8.4 Auto-avaliação.

3.8 Relacionados com o exame: evidência objetiva, inspeção, ensaio, verificação, validação, processo de qualificação e análise crítica.

2.9. Melhoria contínua

3.9 Relacionados com a auditoria: auditoria, programa de auditoria, critérios da auditoria, evidência da auditoria, constatação da auditoria, conclusão da auditoria, cliente da auditoria, auditado, auditor, equipe de auditoria, especialista e competência.

2.10. Função das técnicas estatísticas 3.10 Relacionados com a garantia da qualidade para os processos de medição.

2.11. SGQ’s e outros enfoques de sistema de gestão 2.12 Relação entre SGQ’s e modelos de excelência

ANEXO A A.1 Introdução. A.4 Relação associativa. A.2 Conteúdo de uma entrada de vocabulário e a regra de substituição. A.5 Diagramas de conceito. A.3 Relações entre o conceito e sua representação gráfica. A montagem da perspectiva:

O material é de domínio público mas liberado após pagamento. A ISO 9000 fornece esclarecimentos e definições e não é aplicada individualmente. Ela não é de implantação. O custo envolve a aquisição do texto da norma, eventual consultoria e a certificação pela ISO 9001. A Norma foi desenvolvida desde de 1987 e no momento deste trabalho está na versão 2000. É elaborada e é mantida pela ISO.

A perspectiva montada: Organizações que buscam vantagens através da implantação de um SGQ, definindo linguagem comum entre cliente, colaboradores, fornecedores e analisadores. Não é de aplicação e deve se associada a outra norma da série. Informações retiradas da ISO (2005) da Norma ISO 9000:2000 (NBR ISO 9000,2000).

171


A ISO 9001:2000 avalia a capacidade da organização de entender os e atender aos requisitos do cliente, os regulamentares, e os da própria organização. Para isso, é necessária a adoção de um Sistema de Gestão da Qualidade (SGQ) adequado à realidade da organização, influenciada por objetivos, necessidades, processos, tamanho e estrutura organizacionais e pelos próprios produtos e/ou serviços fornecidos.

Os pontos de convergência: Fazendo parte da Família ISO 9000, a ISO 9001 tem os mesmos pontos de convergência: Auditorias de Adequação aos requisitos da Norma e Auditorias de Conformidade das práticas aos processos adotados.

As linhas mestras: A Norma é descrita em 9 itens e dois anexos, que estão resumidos estruturalmente abaixo.

Item da norma Sub-item da Norma Terceiro nível do item da Norma

0. Introdução

0.1 Generalidades 0.2 Abordagem de processo 0.3 Relação com a ISO 9004 0.4 Compatibilidade com outros SG’s

---

1. Objetivo 1.1 Generalidades 1.2 Aplicação ---

2. Referência normativa --- --- 3. Termos e definições --- ---

4. Sistema de gestão da qualidade

4.1 Requisitos gerais 4.2 Requisitos de documentação

4.2.1 Generalidades 4.2.2 Manual da qualidade 4.2.3 Controle de documentos 4.2.4 Controle de registros

5. Responsabilidade da direção

5.1 Comprometimento da direção 5.2 Foco no cliente 5.3 Política da qualidade 5.4 Planejamento 5.5 Responsabilidade, autoridade e comunicação 5.6 Análise crítica pela direção

5.4.1 Objetivos da qualidade 5.4.2 Planejamento do SGQ 5.5.1 Responsabilidade e autoridade 5.5.2 Representante da direção 5.5.3 Comunicação interna 5.6.1 Generalidades 5.6.2 Entradas para a análise crítica 5.6.3 Saídas da análise crítica

6.Gestão de recursos

6.1 Provisão de recursos 6.2 Recursos humanos 6.3 Infra-estrutura 6.4 Ambiente de trabalho

6.2.1 Generalidades 6.2.2 Competências, conscientização e treinamento

7. Realização do produto

7.1 Planto. da realização do produto 7.2 Processos relacionados a clientes 7.3 Projeto e desenvolvimento 7.4 Aquisição 7.5 Produção e fornecimento de serviço 7.6 Controle de dispositivos de medição e monitoramento.

7.2.1 Determinação de requisitos relacionados ao produto 7.2.2 Análise crítica dos requisitos relacionados ao produto 7.2.3 Comunicação com o cliente 7.3.1 Planejamento do projeto e desenvolvimento 7.3.2 Entradas de projeto e desenvolvimento 7.3.3 Saídas de projeto e desenvolvimento 7.3.4 Análise crítica de projeto e desenvolvimento 7.3.5 Verificação de PD 7.3.6 Validação de PD 7.3.7 Controle de alteração de PD 7.4.1 Processo de aquisição 7.4.2 Informações de aquisição 7.4.3 Verificação de produto adquirido 7.5.1 Controle de produção e fornecimento de serviço 7.5.2 Validação dos processos de produção e fornecimento de serviço 7.5.3 Identificação e rastreabilidade 7.5.4 Propriedade do cliente 7.5.5 Preservação do produto

8. Medição, análise e melhoria

8.1 Generalidades 8.2 Medição e monitoramento 8.3 Controle de produto não-conforme 8.4 Análise de dados 8.5 Melhorias

8.2.1 Satisfação dos clientes 8.2.2 Auditoria interna 8.2.3 Medição e monitoramento de processos 8.2.4 Medição e monitoramento de produto 8.5.1 Melhoria contínua 8.5.2 Ação corretiva 8.5.3 Ação preventiva

Anexo A Correspondência entre a ISO 9001:2000 e a ISO 14001:1996 Anexo B Correspondência entre a ISO 9001:2000 e a ISO 9001:1994

A montagem da perspectiva: O material é de domínio público, mas liberado após pagamento. A ISO 9001 é a norma que define, implanta e certifica o Sistema de Gestão da Qualidade (SGQ) podendo ser aplicada individualmente. O custo envolve a nomeação de um responsável pelo SGQ nomeado pela direção (RD), a aquisição do texto da norma, eventual consultoria e a certificação por terceiros autorizados. A certificação, reavaliada anualmente, vale por 2 anos, quando nova certificação é necessária. Não há níveis de avaliação, mas o tempo de manutenção da certificação é o maior indicador de domínio e amadurecimento dos processos do SGQ, pois a norma espera uma melhoria contínua em todos os aspectos de controle. A norma foi desenvolvida desde 1987 e hoje está na versão 2000. Foi elaborada e é mantida pela ISO (2005).

172

ISO 9001:2000 (continuação)

A perspectiva montada: Possui autoridade mundial e alta aplicabilidade, é um modelo resultante da relação harmoniosa dos elementos da organização, clientes, fornecedores, colaboradores e a alta direção. É de aplicação básica e genérica, separando o planejamento e a execução, definindo e estruturando responsabilidades e competências necessárias para o bom desempenho das funções. Com a aplicação da análise crítica, a organização tem o contato com a necessidade de estabelecer políticas, objetivos, metas e recursos para a qualidade, para orientar ações corretivas, preventivas e de melhoria. Nitidamente, observa-se a ênfase na realização do produto (7), Responsabilidade da direção (5) e Medição, análise e melhoria. Informações colhidas da ISO (2005), da NBR ISO 9001:2000, e de Mello (2002).


ISO/IEC 90003:2004 O direcionamento do observador:

A ISO 90003:2004 é um padrão internacional fornece diretrizes para organização na aplicação da ISO 9001:2000 para aquisição, fornecimento, desenvolvimento, operação e manutenção de software. É independente da tecnologia, ciclo de vida, processos de desenvolvimento, estrutura organizacional e seqüência de atividades aplicadas ou adotadas na organização. A utilização dessa norma é apropriada para ser aplicada em produção de software, que seja parte de um contrato comercial com outra organização. É usada para dar suporte ao processo de uma organização que comercialize ou produze hardware, ou é relacionada com serviços de desenvolvimento de software. Ela não adiciona ou altera os requisitos da ISO 9001.

Os pontos de convergência: Fazendo parte da Família ISO 9000, a ISO/IEC 90003 tem os mesmos pontos de convergência. Sua estrutura segue a ISO 9001. Há em todo seu conteúdo referências adicionais às ISO/IEC 12207, ISO/IEC 15271, ISO/IEC 9126, ISO/IEC 14598, ISO/IEC 15939, e ISO/IEC 15504.

As linhas mestras: Devido fazer referências a outros padrões e normas, a ISO/IEC 90003 complementa e estende a estrutura da ISO 9001. Excepcionalmente, o quadro com suas características se encontra na página seguinte a este quadro (por ser muito extenso).

A montagem da perspectiva: O material é de domínio público, mas liberado após pagamento. A ISO/IEC 90003 é a norma que orienta a implantação do SGQ em adequação com a ISO 9001 em organizações que produzem software. No entanto, não certifica. Como é baseada na ISO 9001, segue sua estrutura e, como apresentado no item “As linhas mestras” (próxima página):

a) Acrescenta dois subitens de três níveis de detalhes (“7.1.1 Ciclo de vida de software”, e “7.1.2 Planejamento da qualidade”);

b) Acrescenta todos os subitens de quatro níveis de detalhes (Ex. 7.2.1.1 Requisitos relacionados com o cliente);

c) Acrescenta orientações específicas de software (especifica SW) em vários itens através de seus subitens, salientando-se que todos os subitens do item “7 Realização do produto” têm orientações e/ou os acréscimos mencionados em b);

d) O item “5.4.2 Planejamento do SGQ” apresenta uma importante orientação: O planejamento pode ocorrer nos níveis organizacionais, de projeto, e de produto.

e) A ISO/IEC 12207:1995 e ISO/IEC 12207:1995/Amd.1:2002 inspiraram fortemente todos as orientações.

O custo envolve a indicação de um responsável pelo SGQ nomeado pela direção (RD e com experiência em desenvolvimento de software). Envolve também a aquisição da norma (incluindo a ISO/IEC12207 e seu Amd.1:2002), eventualmente consultoria, além da certificação ISO 90012000 por terceiro autorizado. Essa norma foi desenvolvida a partir da ISO 9000-3, que dava orientação à implantação da ISO 9001:1994. Foi elaborada e é mantida pelo comitê ISO/IEC JTC 1.

A perspectiva montada: Como é uma norma internacional tem autoridade mundial e aplicabilidade específica para organizações que produzem software. É um modelo resultante de forte integração com outras normas que também tratam de software. Mantém a estrutura e todas as orientações da ISO 9001:2000 e inclui novos conceitos, orientações e itens relativos ao software. Sua orientação, no entanto, está fortemente relacionada com o item “7. Realização do produto”. A ISO/IEC 90003:2004 cobre todas as atividades da produção de software. Informações obtidas da Norma ISO/IEC 90003 (2004).

173

ISO/IEC 90003:2004 (Continuação - As linhas mestras)ISO 9001:2000 x ISO/IEC 90003:2004

1. Objetivo 1. Escopo 1.1 Generalidades (especifica SW)1.2 Aplicação (especifica SW)

2. Referência normativa Não muda 3. Termos e definições Iintroduz novos conceitos e termos introduzindo novos conceitos e termos relacionados com SW.


4.1 Requisitos gerais (especifica SW) 4.2 Requisitos de documentação

4.2.1 Generalidades (especifica SW) 4.2.2 Manual da qualidade 4.2.3 Controle de documentos 4.2.4 Controle de registros 4.2.4.1 Evidência de conformidade dos requisitos 4.2.4.2 Evidência de operação efetiva 4.2.4.3 Retenção e disposição


5.1 Comprometimento da direção 5.2 Foco no cliente 5.3 Política da qualidade 5.4 Planejamento 5.5 Responsabilidade, autoridade e comunicação 5.6 Análise crítica pela direção

5.4.1 Objetivos da qualidade 5.4.2 Planejamento do SGQ *Organizacional/projeto/produto 5.5.1 Responsabilidade e autoridade 5.5.2 Representante da direção 5.5.3 Comunicação interna 5.6.1 Generalidades 5.6.2 Entradas para a análise crítica (especifica SW)5.6.3 Saídas da análise crítica


6.1 Provisão de recursos 6.2 Generalidades 6.3 Infra-estrutura (especifica SW)6.4 Ambiente de trabalho

6.2.1 Generalidades 6.2.2 Competências, conscientização e treinamento (especifica SW)


7.1 Planejamento da realização do produto 7.2 Processos relacionados a clientes 7.3 Projeto e desenvolvimento 7.4 Aquisição 7.5 Produção e fornecimento de serviço 7.6 Controle de dispositivos de medição e monitoramento (especifica SW)

7.1.1 Ciclo de vida de software 7.1.2 Planejamento da qualidade 7.2.1 Determinação de requisitos relacionados ao produto 7.2.1.1 Requisitos relacionados com o cliente 7.2.1.2 Requisito adicionais determinados pela organização 7.2.2 Análise crítica dos requisitos relacionados ao produto 7.2.2.1 Interesse da organização 7.2.2.2 Riscos 7.2.2.3 Representante do cliente7.2.3 Comunicação com o cliente 7.2.3.1 Generalidades 7.2.3.2 Comunicação com o cliente durante o desenv. 7.2.3.3 Com.com o cliente durante operação e manutenção 7.3.1 Planejamento do projeto e desenvolvimento 7.3.1.1 Planejamento de projeto e desenvolvimento 7.3.1.2 Revisão, verificação e validação 7.3.1.4 Interfaces 7.3.2 Entradas de projeto e desenvolvimento (especifica SW)7.3.3 Saídas de projeto e desenvolvimento (especifica SW)7.3.4 Análise crítica de projeto e desenvolvimento (especifica SW)7.3.5 Verificação de PD (especifica SW)7.3.6 Validação de PD 7.3.6.1 Validação 7.3.6.2 Testes 7.3.7 Controle de alteração de PD (especifica SW)7.4.1 Processo de aquisição 7.4.1.1 Produtos adquiridos 7.4.1.2 Controle de produtos adquiridos 7.4.2 Informações de aquisição (especifica SW)7.4.3 Verificação de produto adquirido (especifica SW)7.5.1 Controle de produção e fornecimento de serviço 7.5.1.1Produção e fornecimento de serviço em SW 7.5.1.2 Versões 7.5.1.3 Replicação 7.5.1.4 Entrega 7.5.1.5 Instalação 7.5.1.6 Operação 7.5.1.7 Manutenção 7.5.2 Validação dos processos de produção e fornecimento de serviço (especifica SW)7.5.3 Identificação e rastreabilidade 7.5.3.1 Visão geral 7.5.3.2 Processo de gerência de configuração 7.5.3.3 Rastreabilidade 7.5.4 Propriedade do cliente (especifica SW)7.5.5 Preservação do produto (especifica SW)


8.1 Generalidades (especifica SW)8.2 Medição e monitoramento 8.3 Controle de produto não-conforme (especifica SW)8.4 Análise de dados (especifica SW) 8.5 Melhorias (especifica SW)

8.2.1 Satisfação dos clientes (especifica SW)8.2.2 Auditoria interna (especifica SW)8.2.3 Medição e monitoramento de processos (especifica SW)8.2.4 Medição e monitoramento de produto (especifica SW)8.5.1 Melhoria contínua (especifica SW)8.5.2 Ação corretiva (especifica SW)8.5.3 Ação preventiva (especifica SW)

Anexo A Diretrizes na implementação da ISO 9001:200 com utilização de padrões ISO/IEC JTC 1/SC 7 e ISO/TC 176 Anexo B Planejando em ISO/IEC 90003 e ISO/IEC 12207


174


A ISO 9004:2000 fornece orientação para um SGQ mais amplo do que o especificado pela ISO 9001:2000, amparando a Alta Direção que deseja uma melhoria contínua do desempenho global da organização. Quando comparada com o que na ISO 9001:2000 está como objetivos de satisfação de cliente e qualidade do produto, a ISO 9004:2000 está, de forma estendida, como satisfação das partes interessadas e o desempenho da organização. As duas normas possuem a mesma estrutura geral. Podemos observar diretamente pelo acompanhamento dos itens, que há uma ampliação do alcance dos itens “7. Realização do produto”, “8. Medição, análise e melhoria”, “6. Gestão de recursos”, e “5. Responsabilidade da direção”.

Os pontos de convergência: Fazendo parte da Família ISO 9000, a Norma ISO 9000:2000 tem os mesmos pontos de convergência.

As linhas mestras: O quadro a seguir compõe uma montagem comparativa entre as estruturas das normas ISO 9001:200 x ISO/IEC 90003:2004 x ISO 9004:2000.

ISO 9001:2000 ISO 9004:2000 ISO/IEC 90003:2004

0. Introdução

0.1 Generalidades (MD) 0.2 Abordagem de processo (MD) 0.3 Relação com a ISO90040.3 Relação com a ISO9001 0.4 Compatibilidade com SG’s (MD)

Não Há na 90003

1. Objetivo 1. Escopo

1.1 Generalidades (SW) 1.2 Aplicação (SW)

2. Referência normativa

Não Muda na 90003 Não Muda 9004

3. Termos e definições introduz novos Não Muda 9004


4.1 Requisitos gerais (SW) 4.1 Gestão de processos e sistemas 4.2 Requisitos de documentação4.2 Documentação 4.3 Uso dos princípios da gestão da Qualidade

4.2.1 Generalidades (SW)4.2.2 Manual da qualidade 4.2.3 Controle de documentos 4.2.4 Controle de registros 4.2.4.1 Evidência de conformidade dos requisitos 4.2.4.2 Evidência de operação efetiva 4.2.4.3 Retenção e disposição


5.1 Comprometimento da direção 5.1Recomendações gerais 5.2 Foco no cliente 5.2 Necessidades e expectativas das parte interessadas 5.3 Política da qualidade (MD) 5.4 Planejamento 5.5 Responsabilidade, autoridade e comunicação 5.6 Análise crítica pela direção

5.1.1 Introdução 5.1.2 Aspectos a serem considerados 5.2.1 Generalidades 5.2.2 Necessidades e expectativas 5.2.3 Requisitos estatutários e regulamentares 5.4.1 Objetivos da qualidade (MD) 5.4.2 Planejamento do SGQ *Organizacional/projeto/produto 5.4.2 Planejamento da qualidade 5.5.1 Responsabilidade e autoridade (MD) 5.5.2 Representante da direção (MD) 5.5.3 Comunicação interna (MD) 5.6.1 Generalidades (MD) 5.6.2 Entradas para a análise crítica (SW) (MD) 5.6.3 Saídas da análise crítica (MD)


6.1 Provisão de recursos6.1 Recomendações gerais 6.2 Recursos humanos 6.2 Pessoas 6.3 Infra-estrutura (SW) (MD) 6.4 Ambiente de trabalho (MD) 6.5 Informação 6.6 Fornecedores e parceiros 6.7 Recursos naturais 6.8 Recursos financeiros

6.1.1 Introdução 6.1.2 Aspectos a serem considerados 6.2.1 Generalidades 6.2.1 Envolvimento de pessoas 6.2.2 Competências, conscientização e treinamento (SW) (MD) 6.2.2.1 Competências 6.2.2.2 Conscientização e treinamento

175

ISO 9004:2000 (Continuação) ISO 9001:2000 ISO 9004:2000 ISO/IEC 90003:2004


7.1 Planejamento da realização do produto 7.1 Recomendações gerais 7.2 Processos relacionados a clientes 7.2 Processos relacionados a partes interessadas 7.3 Projeto e desenvolvimento 7.4 Aquisição 7.5 Produção e fornecimento de serviço 7.5 Operações de produção e serviço 7.6 Controle de dispositivos de medição e monitoramento (SW) (MD)

7.1.1 Ciclo de vida de software7.1.2 Planejamento da qualidade7.1.1 Introdução 7.1.2 Aspectos a serem considerados 7.1.3 Gestão de processos 7.1.3.1 Generalidades 7.1.3.2 Entradas, saídas e análise crítica de processo 7.1.3.3 Validação de produto e processo e alterações 7.2.1 Determinação de requisitos relacionados ao produto 7.2.1.1 Requisitos relacionados com o cliente 7.2.1.2 Requisito adicionais determinados pela organização7.2.2 Análise crítica dos requisitos relacionados ao produto 7.2.2.1 Interesse da organização 7.2.2.2 Riscos 7.2.2.3 Representante do cliente7.2.3 Comunicação com o cliente 7.2.3.1 Generalidades 7.2.3.2 Comunicação com o cliente durante o desenv. 7.2.3.3 Com.com o cliente durante operação e manutenção7.3.1 Planejamento do projeto e desenvolvimento 7.3.1.1 Planejamento de projeto e desenvolvimento 7.3.1.2 Revisão, verificação e validação 7.3.1.4 Interfaces7.3.1 Recomendações gerais 7.3.2 Entradas de projeto e desenvolvimento (SW)7.3.2 Entrada e saída de projeto e desenvolvimento 7.3.3 Saídas de projeto e desenvolvimento (SW)7.3.3 Análise crítica de projeto e desenvolvimento 7.3.4 Análise crítica de projeto e desenvolvimento (SW)7.3.5 Verificação de PD (SW)7.3.6 Validação de PD 7.3.6.1 Validação 7.3.6.2 Testes7.3.7 Controle de alteração de PD (SW)7.4.1 Processo de aquisição (MD) 7.4.1.1 Produtos adquiridos 7.4.1.2 Controle de produtos adquiridos7.4.2 Informações de aquisição (SW)7.4.2 Processo de controle de fornecedor 7.4.3 Verificação de produto adquirido (SW)7.5.1 Controle de produção e fornecimento de serviço 7.5.1.1Produção e fornecimento de serviço em SW 7.5.1.2 Versões 7.5.1.3 Replicação 7.5.1.4 Entrega 7.5.1.5 Instalação 7.5.1.6 Operação 7.5.1.7 Manutenção7.5.1 Operação e realização 7.5.2 Validação dos processos de produção e fornecimento de serviço (SW) 7.5.2 Identificação e rastreabilidade 7.5.3 Identificação e rastreabilidade 7.5.3.1 Visão geral 7.5.3.2 Processo de gerência de configuração 7.5.3.3 Rastreabilidade7.5.3 Propriedade do cliente 7.5.4 Propriedade do cliente (SW)7.5.4 Preservação de produto 7.5.5 Preservação do produto (SW)

176

ISO 9004:2000 (Continuação)

ISO 9001:2000 ISO 9004:2000 ISO/IEC 90003:2004


8.1 Generalidades (SW)8.1 Recomendações gerais 8.2 Medição e monitoramento 8.3 Controle de produto não-conforme (SW)8.3 Controle de não-conformidade 8.4 Análise de dados (SW) (MD) 8.5 Melhorias (SW)

8.1.1 Introdução 8.1.2 Aspectos a serem considerados 8.2.1 Satisfação dos clientes (SW)8.2.1 Medição e monitoramento do desempenho do sistema 8.2.1.1 Generalidades 8.2.1.2 Medição e monitoramento da satisfação do cliente 8.2.1.3 Auditoria interna 8.2.1.4 Medições financeiras 8.2.1.5 Auto-avaliação 8.2.2 Auditoria interna (SW)8.2.2 Medição e monitoramento de processos 8.2.3 Medição e monitoramento de processos (SW)8.2.3 Medição e monitoramento de produto 8.2.4 Medição e monitoramento de produto (SW)8.2.4 Medição e monitoramento da satisfação das partes interessadas 8.3.1 Generalidades 8.3.2 Análise crítica e correção das não conformidades 8.5.1 Melhoria contínua (SW)8.5.1 Generalidades 8.5.2 Ação corretiva (SW) (MD) 8.5.3 Ação preventiva (SW) 8.5.3 Prevenção contra perdas 8.5.4 Melhoria contínua da organização

Anexo A

Correspondência entre NBR ISO9001:2000 e NBR ISO 14001:1996 Diretrizes na implementação da ISO 9001:200 com utilização de padrões ISO/IEC JTC 1/SC 7 e ISO/TC 176Diretrizes para auto-avaliação

Anexo B Correspondência entre NBR ISO9001:2000 e NBR ISO 9001:1994 Planejando em ISO/IEC 90003 e ISO/IEC 12207 Processo de melhoria contínua

Legenda do quadro

Descrição Exemplo de Representação Itens comuns às ISO 9001 e ISO 9004 estão escritos de forma normal 7. Realização do produto Itens comuns às ISO/IEC 90003 e ISO 9004 estão em itálico sublinhado 7.1.2 Planejamento da qualidadeItens somente da ISO 9004 estão em negrito e sublinhados tracejados 7.1.3 Gestão de processos Itens somente da ISO/IEC 90003 estão em itálico sublinhado e cortado 7.5.1.3 ReplicaçãoItens somente da ISO 9001 estão escritos de forma normal e cortados 8.1 GeneralidadesItens comuns às ISO 9001 e ISO 90003 que diferem nas suas descrições (SW)Itens comuns às ISO 9001 e ISO 9004 que diferem nas suas descrições (MD) Mais detalhada A montagem da perspectiva:

O material é de domínio público, mas liberado após pagamento. A ISO 9004:2000 também é aplicada individualmente, contendo em quadros destacados o conteúdo da ISO 9001:2000. Ela é de implantação e melhoria de desempenho global. O custo envolve a aquisição do texto da norma, consultoria envolvendo vasta área de atuação organizacional (possivelmente de um grupo). Vai além das necessidades para certificação pela ISO 9001. Essa norma foi desenvolvida desde 1987 e hoje está na versão 2000. Foi elaborada e é mantida pela ISO (2005).

A perspectiva montada: Organizações que buscam vantagens através da implantação de um SGQ integrado com outros sistemas de gestão para alcançar, manter e melhorar o desempenho e a capacidade global da organização. A estrutura estendida, em relação à ISO 9001, torna-a uma norma pesada de ser implantada e de complexa implantação. Informações retiradas da ISO (2005) e da ISO 9004:2000 (2000).

Quadro III.8: ISO 9001:2000 x ISO/IEC 90003:2004 x ISO 9004:2000

177

A montagem da perspectiva: É de domínio público porém, comprada. Os custos e tempo de implantação dependem do tamanho e da extensão do ambiente de engenharia de software e da diversidade da organização, tamanho e complexidade de seus projetos, pessoal e qualidade envolvidos, e da maturidade de seus fornecedores e clientes. A norma deve ser bem entendida, para que realmente se torne uma ferramenta de orientação. A versão de 1995 tem emendas: Amd 1:2002 e Amd 2:2004. Não há certificação oficial e o comitê ISO/IEC-JTC1-SC7 é o responsável técnico.

A perspectiva montada: Disciplina os aspectos envolvidos no ciclo de vida do software, é de linguagem técnica de alcance a todas as partes envolvidas. Não está vinculada a uma estrutura de desenvolvimento específica. A abordagem, após o AMENDMENT 1, deixou a norma ISO/IEC 12207 mais detalhada com alterações nos macro-processos organizacionais (adicionando três novos processos) e de apoio (adicionando um processo). Ficou um pouco mais extensa e de maior complexidade na implementação ou adaptação. Informações colhidas da NBR ISO/IEC 12207 (1998), ISO/IEC 12007 (1995), Amd 1 (2002), ISO/IEC 15271 (2000).

ISO/IEC 12207:1995

O direcionamento do observador: O propósito da norma ISO/IEC 12207 é estabelecer um framework comum para descrever o ciclo de vida do software, para que todos os participantes do negócio, clientes, fornecedores, desenvolvedores, operadores, mantenedores, gerentes, suportes, usuários e observadores, tenham o mesmo entendimento dos processos, das atividades e tarefas envolvidas. A norma provê a construção de blocos para a definição de modelos, estratégias e planos de projetos e da própria organização, cobrindo os processos de aquisição, fornecimento, desenvolvimento, operação e manutenção do software e gerência, controle, treinamento e melhoria no próprio modelo. Descreve ainda processos de apoio tanto nas atividades de software como organizacionais.

Os pontos de convergência: Estabelece uma arquitetura de alto nível do ciclo de vida de software, de sua concepção a sua descontinuação. É baseada no conceito de processos, atividades e tarefas. Os processos descritos se inter-relacionam-se e obedecem a princípios de responsabilidade (que parte é responsável pelo processo) e de modularidade (coesão, e acoplamento). Outro forte conceito encontrado é o de adaptação: todos os processos devem ser adaptados apropriadamente para aplicação em cada tipo de organização e projeto, independentemente de sua metodologia ou tecnologia de desenvolvimento de software. As diferentes visões dos processos são úteis tanto para a adaptação, quanto para aplicação específica. Influenciou a ISO/IEC15504 e as normas da família ISO 9000. Referenciou as normas ISO/IEC 15939 (medições), ISO/IEC 14598 (avaliação de produtos) e IEEE 1517 (engenharia de domínio, gerência de ativos e reuso). Existem publicadas normas com diretrizes para sua aplicação, ISO/IEC TR 15271:1998, e a ISO/IEC TR 16326:1999. O inter-relacionamento dos processos e a aplicação recursiva dos processos de apoio e organizacionais apresentam influência do ciclo PDCA.

As linhas mestras: Três grandes processos delineiam a estrutura desta norma, sendo compostos por outros processos. O Quadro abaixo já contem as alterações do Amd 1:2002 dessa norma: inclusão dos processos gerência de ativos, gerência de reuso e engenharia de domínio no macro-processo organizacional, e o processo de usabilidade no macro-processo de apoio.

Quadro III.9: ISO/IEC 12207:1995

178

Os pontos de convergência: Sua elaboração foi baseada em normas e métodos já existentes, como O CMMI, STD/Compita, Trillium/Bell, SQPA/HP, Bootstrap/EC, SAM/BT, HelthCheck/BT, ISO/IEC 12119:1995, ISO/IEC 9126 e da Série ISO 9000. Teve forte influência da ISO/IEC 12207 e sua arquitetura dos processos de ciclo de vida do software e do CMMI herdou o conceito de níveis de maturidade de processo, e se inspirou em sua forma contínua.

As linhas mestras: Há duas dimensões definidas pelo modelo de referência: A dimensão de processo (que é avaliado e enquadrado em um determinado nível de capacidade – ISO/IEC 12207) e a dimensão de capacidade (estabelecendo a graduação da capacidade do processo avaliado – CMMI). Dimensão processo Descrição

Cliente - Fornecedor Processos que impactam diretamente o cliente/fornecedor. Engenharia Processos que especificam, implementam ou mantêm um sistema e/ou produto de software. Projeto Processos que estabelecem o projeto, e coordena e gerencia seus recursos. Suporte Processos que habilitam e apoiam a execução de outros processos no projeto. Organização Processos que envolvem processos e recursos em busca do objetivos organizacionais. Dimensão capacidade Descrição

Nível – 0 Não-executado: Há falhas gerais na execução dos processos, não são identificadas a saídas dos processos. Nível – 1 Informalmente-executado: A processo depende de esforço individual para sua execução. Nível – 2 Planejado-e-seguido: Há a execução dos processos como foram planejados. Nível – 3 Bem-definido: Há processos documentados, adaptação de padrões organizacionais. Nível – 4 Quantitativamente-controlado: Detalhadas medidas são coletadas e analisadas. Nível – 5 Continuamente-melhorado: Processos são melhorados independentemente de tecnologia.

A partir dos resultados coletados da avaliação, o modelo de referência pode seguir para a melhoria de processos ou para a determinação da capacidade de processo.


O material é domínio público mas liberado sob pagamento. O tempo necessário para sua implementação varia do porte da organização e seus processos. Não foram encontradas evidências do custo de sua implantação mas uma consultoria se faz necessária pela complexidade e abrangência do modelo. Não há uma Certificação Oficial.

A perspectiva montada: Organizações que buscam vantagens através da avaliação de seus processos para melhoria de desempenho e a capacidade global da organização. A organização pode ter sua estrutura de processos mapeada apontando todos os níveis de capacidade atingidos pela avaliação. Informações colhidas da ISO (2005), da ISO/IEC 15504-1(2004) e ISO/IEC 15504-2(2003) e Rocha et al. (2001).

ISO/IEC 15504 O direcionamento do observador:

A ISO/IEC 15504 surgiu do projeto SPICE (Software Process Improvement and Capability dEtermination), em 1993. Em 1998, foi publicada como TR (Technical Report) através de um conjunto de nove documentos com a proposta de melhoria dos processos e de determinação da capacidade de processos de uma organização. Atualmente, a ISO/IEC 15504 é composta de cinco partes. O framework de avaliação pode ser usado em processos de planejamento, gerência, monitoramento, controle e melhoria dos processos de aquisição, fornecimento, desenvolvimento, operação, evolução e suporte de software.

Parte Descrição ISO/IEC 15504-1:2004 Tecnologia da Informação – Avaliação de Processos – 1: Conceitos e vocabulário ISO/IEC 15504-2:2003/Cor 1:2004 Tecnologia da Informação – Avaliação de Processos – 2: Executar uma avaliação ISO/IEC 15504-3:2004 Tecnologia da Informação – Avaliação de Processos – 3: Guia para a avaliação

ISO/IEC 15504-4:2004 Tecnologia da Informação – Avaliação de Processos – 4:Guia para melhoria de processo e determinação de capacidade de processo

ISO/IEC FCD 15504-5 Tecnologia da Informação – Avaliação de Processos – 5: Um exemplo de Modelo de avaliação de processo

Quadro III.10: ISO/IEC 15504

179

ISO/IEC 15288:2002 O direcionamento do observador:

A ISO/IEC 15288 – System engineering – System life cycle processes é o primeiro padrão ISO a tratar dos processos do ciclo de vida de sistemas integrando hardware, processos, procedimentos, software e relações humanas. Foi publicado em 2002. A estrutura deste padrão abrange o ciclo de vida de sistemas (não naturais), cobrindo da concepção à retirada de uso do sistema. Esta estrutura fornece apoio para a avaliação e a melhoria do ciclo de vida do projeto inclusive padronizando e avaliando a relação entre clientes e fornecedores. A própria norma tem um processo de adaptação que a disponibiliza para inúmeras aplicações. Todos seus processos estão definidos com base na relação propósito do processo, as saídas e as atividades envolvidas.

Composição Descrição Propósito Descreve em alto nível o objetivo geral do processo. Saídas É um resultado observado pelo sucesso da execução do processo. Atividades Define a composição estrutural de um processo

Os pontos de convergência: Sua elaboração usou como referência a ISO 9001:2000 e a ISO/IEC12207:1995, entretanto, sua elaboração já inspirou atualizações da própria ISO/IEC 12207, da ISO/IEC 90003 e da ISO/IEC 15504.

As linhas mestras: Processos Sub-processos

De Acordos Aquisição e Fornecimento

Organizacionais Gerência do ambiente organizacional, gerência de investimento, gerência de processos de ciclo de vida, gerência de recursos e gerência da qualidade

Do Projeto Planejamento do projeto, Avaliação do projeto, controle do projeto, tomada de decisão, gerência de risco, gerência de configuração, usabilidade e gerência da informação

Técnicos Definição de Stakeholders, análise de requisitos, projeto da arquitetura, implementação, integração, verificação, transição, validação, operação, manutenção e disposição.

Especiais Adaptação Os sistemas quando analisados podem assumir estágios pré-definidos.

Estágio Descrição Concepção Há a análise de necessidades e desenvolvimento de soluções. Desenvolvimento Projeta um produto que é um item executável Produção Produção, inspeção e teste do item Utilização Operação e uso do item Suporte Mantém e suporta o item Retirada Retira, descarta e registra o item


O material é domínio público mas liberado sob pagamento. O tempo necessário para sua implementação varia do porte da organização e seus processos. Não foram encontradas evidências do custo de sua implantação mas uma consultoria se faz necessária pela complexidade e abrangência do modelo. Observa-se uma integração entre a ISO 9001:2000, a ISO/IEC 12207, ISO/IEC 15288 e a ISO/IEC 15504. Existe ainda a ISO/IEC 19760:2003 Systems engineering -- A guide for the application of ISO/IEC 15288 (System life cycle processes).

A perspectiva montada: A organização tem a visão integral dos aspectos técnicos, organizacionais, de projeto e de relacionamento com clientes e fornecedores, envolvendo todas as partes do produto final. Informações através dos sites: http://www.jtc1-sc7.org, http://www.15288.com e http://www.software.org/quagmire/descriptions/iso-iec15288.asp.

Quadro III.11: ISO/IEC 15288:2002

180

III.3.3 Oriundos de necessidades e exigências de grandes clientes

TickIT O direcionamento do observador:

O TickIT é uma iniciativa do DTI (Department of Trade and Industry do Reino Unido) que se dirige ao uso dos padrões da Série ISO 9000 para sistemas de qualidade no desenvolvimento de software. Sua operação foi incluída aos padrões do BSI (British Standards Institution) pelo DTI. O BSI é um dos corpos de certificadores TickIT acreditados pelo UKAS (United Kingdom Accreditation Service). É aplicado em companhias envolvidas no desenvolvimento de software, independentemente do tamanho da área de desenvolvimento. Existe portanto uma certificação TickIT. O TickIT guia a organização na definição e execução de um Sistema da qualidade que cobre todos os processos essenciais do ciclo de vida do software e é baseada na estrutura da ISO 9001.

Os pontos de convergência: O padrão mais fortemente integrado é a Norma ISO 9001:2000, a ISO/IEC 12207:1995, a ISO/IEC 15504, o CMM e os critério de excelência do EFQM (European Foundation for Quality Management) – Orientação a resultados, foco no cliente, liderança e constância de propósitos, gerência por processos e fatos, desenvolvimento e envolvimento das pessoas, aprendizagem e melhoria contínuas, desenvolvimento de parcerias e a responsabilidade social.

As linhas mestras: É baseado possui um guia oficial que descreve sua estrutura completa e aponta os aspectos destinado às diferentes audiências de sua aplicação: Gerentes sênior, staff operacional dos fornecedores, colaboradores internos, grupo de certificadores e autoridades de acreditação, auditores interno e externos e consultores em TI.

Composição do Guia Comentário Parte A: Introdução ao TickIT e ao processo de certificação

Informações gerais sobre as operações de TickIT e como ele se relaciona com outras iniciativas da qualidade como a melhoria de processos

Parte B: Diretrizes para Clientes

Contribuição do cliente para a qualidade dos produtos e serviços entregues. Com o ponto de vista do cliente na no desenvolvimento do projeto de desenvolvimento.

Parte C: Diretrizes para Fornecedores

Indica como organizações podem avaliar e melhorar efetivamente seu SGQ.

Parte D: Diretrizes para Auditores

Guia na condução de avaliações para auditores.

Parte E: Requisitos de Sistemas de gerência da qualidade de software – Perspectiva de padrões

Ajuda organizações a produzir e providenciar serviços relacionados com software, interpretando a os requisitos da Norma ISO 9001:200

Parte F: Requisitos de Sistemas de gerência da qualidade de software – Perspectiva de processos

Identifica e elabora práticas para controlar continua e efetivamente o SGQ. Baseada nos requisitos da ISO/IEC 12207:1995.

Apêndice 1: Gerenciamento e avaliação de processos de TI Apêndice 2: Estudo de caso: Usando o EFQM Excellence Model. Apêndice 3: Estudo de caso: ISO/IEC 15504 – Compatible Process assessments. Apêndice 4: Estudo de caso: A maneira CMM para melhoria de processo de software. Apêndice 5: Padrões para referência Glossário de termos Índice A montagem da perspectiva:

O material é domínio da BSI. O tempo necessário para sua implantação se compara com o da ISO 9001:2000. Não foram encontradas evidências do custo de sua implantação. O modelo foi desenvolvido a partir de 1991, a versão atual versão está na Quinta edição, mas ainda não incorpora a ISO/IEC 90003:2004. A Certificação Oficial além do logo da ISO 9001:2000 carrega também o logo do TickIT.

A perspectiva montada: Com o TickIT, a certificação serão em três ciclos anuais que compreendem uma avaliação do sistema de gerência da qualidade, continuando as avaliações seguidas por um re-avaliação e por uma re-certificação no terceiro ano. Todas as avaliações são conduzidas por avaliadores do TickIT. Informações coletadas em Dez/2004 na web: http://emea.bsi-global.com/Tickit/index.xalter#Software,http://www.tickit.org/index.htm, http://www.efqm.org/Default.aspx?tabid=1 e http://www.cse.dcu.ie/essiscope/sm5/approach/tickit-2.html

Quadro III.12: TickIT

181

BOOTSTRAP O direcionamento do observador:

O Bootstrap foi financiado pela European Commission dentro do programa ESPRIT ( programa de tecnologias da informação, de 1993, integrando projetos industriais de P&D e de processos de medidas). Seu objetivo era desenvolver uma metodologia para a avaliação do processo do software, medições quantitativas, e melhoria, e validá-la aplicando a um número de companhias. Após a conclusão do projeto do ESPRIT o instituto Bootstrap foi estabelecido, portanto é um modelo de maturidade.

Objetivos do Bootstrap Prover suporte para a avaliação da capacidade através das melhores práticas Incluir como referência dessas melhores práticas padrões internacionais reconhecidos Dar suporte à avaliação de como o padrão de referência foi implementado na organização Garantir a confiabilidade e a repetibilidade da avaliação Identificar pontos fortes e fraquezas na organização Dar suporte ao planejamento de melhoria com resultados apropriados e confiáveis Dar suporte à realização dos objetivos da organização Ajudar a aumentar a eficácia dos processos ao implementar requisitos padrões Fazer uma distinção entre organização, metodologia e tecnologia.

Os pontos de convergência: O projeto tinha o objetivo de ampliar e adaptar o modelo de maturidade do SEI (CMM) para torná-lo aplicável a uma gama mais ampla de empresas [a3.69]. A versão 3.0 do Bootstrap foi desenvolvida garantindo a conformidade com a ISO/IEC 15504 (à época ainda projeto SPICE) e a ISO/IEC 12207. O Bootstrap pode ser aplicado em pequenas e médias organizações ou em departamentos de software em grandes organizações.

As linhas mestras:

Características Observações

Processo de avaliação Os resultados da avaliação são as principais entradas para prover ações de melhoria

Modelo de processo 6 níveis de capacidade (0-Incompleto, 1-Realizado, 2-Gerenciado, 3-Estabelecido, 4-Previsível e 5-Em otimização)

Questionários Possui 2 questionários para coletar dados sobre: A) a organização do desenvolvimento de SW e B) os projetos

Apresentação dos resultados Baseado na acreditação do avaliador e por regras padrões de escores e rateios Guias melhoria de processo Identifica os processo de maior impacto na realização dos objetivos Base de dados Todas as avaliações estão numa base comum.

A montagem da perspectiva: O material é domínio do Instituto Bootstrap. O tempo necessário para sua implantação deve se comparar com o do CMM. Não foram encontradas evidências do custo de sua implantação. O modelo foi desenvolvido a partir de 1993, a última versão oficial foi a 3 e sua última menção foi em 2000, não constando estar ainda sendo aplicada.

A perspectiva montada: Informações coletadas em Dez/2004 na web: http://www.cse.dcu.ie/essiscope/sm5/approach/boot-1.html, http://www.cordis,lu/esprit/src/results/res_area/st/st2.htm e http://www.bootstrap-institute.com.

Quadro III.13: BOOTSTRAP

182

SW-CMM O direcionamento do observador:

O sw-CMM (Capability Maturity Model - Software) é um modelo de maturidade de processo de software, documentado na sua versão v1. 0 em 1990, desenvolvido pelo SEI (Software Engineering Institute of Carnegie Mellon University), em parceria com representantes da indústria, para estabelecer um modelo de avaliação de fornecedores de software para o Departamento de Defesa do governo americano. O CMM consiste em dois enfoques para a avaliação da maturidade de uma organização, um é a avaliação do processo de software, que determina o estágio real de seu processo de software, o outro é avaliação da capacidade do software, para qualificar a capacidade de fornecedores de software.

Pontos de convergência: O modelo completo do CMM envolve várias áreas de aplicação, como: CMM-People, CMM-Software Acquisition, CMM-Software Engineering e CMM-Integrated Product Development. O SW-CMM é um framework que descreve os elementos-chave de um processo de software efetivo, levando a organização por um caminho evolutivo de melhoria. Integração de grupos internos que estabelecem atividades que complementam e apoiam a estrutura de cada KPA. Forte apoio gerencial já na implantação do nível 2. Abordagem voltada para gerência de processos.

As linhas mestras: É composto de cinco níveis de maturidade que se interagem em uma abordagem completa da organização.

Nível Foco Gerencial Organizacional Engenharia 1-Inicial Heróis Ad hoc

2-Repetível Gerência de projetos

Gestão de Requisitos Planejamento de projeto de SWAcompanhamento projeto SW Gestão de Subcontratação Garantia da Qualidade Gestão de configuração

3-Definido Processos de engenharia

Gestão integrada de software Coordenação entre grupos

Foco no processo organizacional Definição do processo organizacional Programa de treinamento

Engenharia de produto de SW Revisão por pares

4-Gerenciado

Qualidade de processos e produtos

Gestão quantitativa de processo Gestão da qualidade de

SW

5-Em otimização

Melhoria contínua

Gestão de alteração de projeto Gestão de alteração de tecnologia

Prevenção de defeitos

Operacionalmente cada nível tem uma decomposição em partes menores, excluindo-se o nível 1.

Nível de maturidade KPA

Características comuns: Compromissos para executar

Habilidades para executar Atividades

Medições e análises Verificação da implementação

Práticas chave

Prevê forte estrutura baseada na definição e documentação de processos, a cargo do SEPG (Software Engineering Process Group), na garantia do cumprimento dos processos estabelecidos, com a presença em todos os projetos da figura do SQA(Software Quality Assurance), na gerência dos projetos fortemente focada no nível 2, em medições e nas análises dos resultados dessas medições.

A montagem da perspectiva: Relatos indicam que para evoluir de um nível para outro a organização leva em média dois anos, envolvendo vários grupos internos e consultores externos. Havia a certificação oficial de terceiros acreditados pelo SEI. A presença de consultoria é necessária mesmo com o apoio de estruturas internas da organização. A versão mais difundida foi a v1. 1. Atualmente foi substituído pelo CMMI, que integrou as várias áreas do CMM que existiam sem uma relação mais forte entre si.

A perspectiva montada: É um modelo normativo, onde as práticas detalhadas caracterizam os tipos normais de comportamento que seriam esperados em uma organização que desenvolve projetos em larga escala num contexto de contratação governamental, necessita de uma estrutura adequada que nem sempre está disponível em todas as organizações, a certificação já no nível 2 abre possibilidades de negócios, principalmente no mercado norte-americano. Informações retiradas dos TR24.93 (PAULK, 1993a) e TR25.93 (PAULK,1993b) colhidos no site do SEI (http://www.sei.cmu.edu).

Quadro III.14: SW-CMM

183

CMMI O direcionamento do observador:

O CMMI (Capability Maturity Model Integration) é um conjunto de documentos oficiais do SEI composto por Modelos e Módulos. A integração possibilitou a combinação de diferentes estruturas e vocabulários em um só modelo com várias visões. O CMMI tem duas forma de aplicação, uma em estágios semelhante ao CMM e uma de forma contínua semelhante à abordagem da ISO/IEC15504. É um modelo de maturidade de processo de software. Há quatro áreas de conhecimento que são apresentadas na seleção de um modelo.

Modelo Áreas de Conhecimento

CMMI-SE/SW/IPPD/SS v1.1 Engenharia de sistemas, engenharia de software, desenvolvimento integrado de processo e produto e análise de fornecedores.

CMMI-SE/SW/IPPD v1.1 Engenharia de sistemas, Engenharia de software e desenvolvimento integrado de processo e produto

CMMI-SE/SW v.1.1 Engenharia de sistemas, Engenharia de software CMMI-SW v.1.1 Engenharia de software CMMI Acquisition v1.0 Processo de aquisição

pontos de convergência: O modelo foi desenvolvido pelo SEI (Software Engineering Institute of Carnegie Mellon University), em parceria com representantes da indústria, da academia e do governo norte-americano, a partir do CMM-SW versão v2.0, do CMM-IPD, EIA/IS 731(Electronic Industries Alliance) e da ISO/IEC 15504. No lugar das KPA’s do CMM existem as PA’s (Áreas de processo).

As linhas mestras: O CMMI é formado pela distribuição, nas PA’s, de seus componentes agrupados em três categorias:

Grupo Descrição Componentes Requerido

Essencial para avaliar a atendimento da área de processo. Obrigatório.

Somente as declarações dos objetivos específicos e objetivos genéricos

Esperado Descreve o que é preciso para atender aos componentes requeridos. Somente as declarações das práticas específicas e práticas genéricas

Informativo

Ajuda no entendimento dos objetivos e práticas e como fazer para alcançá-los.

Títulos e notas dos objetivos específicos e genéricos, títulos e notas das práticas específicas e genéricas, Sub-práticas, produtos de trabalho típicos, ampliação de disciplinas, elaboração de práticas genéricas e referências.

O CMMI-Estágio é composto de cinco níveis de maturidade que se interagem em uma abordagem completa da organização. Continua sendo observando o enfoque gerencial no nível 2.

Nível Foco Gerencial Organizacional Engenharia 1-Inicial Heróis Ad hoc

2 Repetível

Gerência de projetos

Gestão de Requisitos Planejamento de projeto Controle e monitoração de projeto Gestão de contrato com fornecedor Medição e análise Garantia Qualidade processo e produto Gestão de configuração

3 Definido

Gerência de projetos de forma e proativa Qualitativa

Gestão integrada de projeto Gestão de riscos Resolução e análise de decisão Integração de Ambiente Organizacional (CMMI-SE/SW/IPPD/SS)

Foco no processo organizacional Definição do processo organizacional Treinamento organizacional Integração de Times (CMMI-SE/SW/IPPD/SS)

Desenv. de requisitos Solução técnica Verificação Validação Integração de produtos

4 Gerenciado

Controlado de forma Quantitativa

Gestão quantitativa de processo Desempenho de processo organizacional

5 - Em otimização

Melhoria contínua Determinação e análise de causa Preparação e inovação

organizacional

Operacionalmente cada nível tem uma decomposição em partes menores, organizando seus componentes, excluindo-se o nível 1.

Objetivos específicos Práticas específicas

Produtos de trabalho típicos Sub-ptáticas Ampliação de disciplinas Notas Referências Nível de

maturidade Área de processo

Objetivos genéricos

Características comuns: Compromissos para executar

Habilidade para executarImplementação da Direção

Implementação da Verificação

Práticas genéricas

Produtos de trabalho típicos Sub-ptáticas Elaboração de práticas genéricas Notas Referências

184

Quadro III.15: CMMI

CMMI (continuação) As linhas mestras:

O CMMI-Contínuo é composto de áreas de processos que se agrupam em quatro categorias. Cat. Gestão de processo Gestão de projeto Engenharia Suporte

Áre

a de

Pro

cess

o

Foco no processo organizacional (OPF) Definição de processo organizacional (OPD) Treinamento organizacional (OT) Desempenho do processo organizacional (OPP) Inovação e Implantação na organização (OID)

Planejamento de projeto (PP) Controle e monitor. de projeto (PMC) Gestão de contrato de fornecedor (SAM) Gestão de projeto integrada (IPM) Gestão de riscos (RSKM) Integração de times (IT) Gestão de fornecedores integrada (ISM)

Gestão de requisitos (RM) Desenvolvimento de requisitos (RD) Solução técnica (TS) Integração de produtos (PI) Verificação (VER) Validação (VAL)

Gestão de configuração (CM) Garantia da qualidade de produto e processo (PPQA) Medição e Análise (MA) Análise de decisão e resolução (DAR) Integração de ambiente organizacional (OEI) Análise e Resolução de causas (CAR)

Para cada área de processo, o nível de capacidade consiste de práticas específicas e genéricas que, quando executadas, atingem um conjunto de objetivos esperados e uma classificação baseada em seis níveis de capacidade (de 0 a 5). Cada área descreve seus objetivos e práticas específicos e seus objetivos e práticas genéricos indicando seus respectivos níveis de capacidade. Operacionalmente cada área de processo tem uma decomposição em partes menores e se enquadram em determinado nível.

Objetivos específicos Práticas específicas

Produtos de trabalho típicos Sub-práticas Ampliação de disciplinas Notas Referências Área de

processo

Objetivos genéricos Práticas genéricas

Produtos de trabalho típicos Sub-práticas Elaboração de práticas genéricas Notas Referências

Níveis de capacidade:

0.Incompleto1.Executado

2.Gerenciado3.Definido

4.Gerenciado quantitativamente5.Em otimização

Categoria PA Objetivos Práticas Nível

Práticas base, são as práticas específicas que atendem ao nível 1 de capacidade N – 1

N – 2

Esp

ecífi

cos

Objetivos específicos para cada PA

Esp

ecífi

cos

Prática avançadas, são práticas específicas que atendem aos níveis superiores ao nível 1. Atingem até o Nível 3, conforme o CMU/SEI-2002-TR-011. N – 3

Atingir os objetivos específicos Executar as Práticas base N – 1

Institucionalizar um processo gerenciado

Estabelecer uma Política organizacionalPlanejar o processo

Prover recursosEstabelecer responsabilidades

Treinar pessoasGerenciar configurações

Identificar e envolver stakeholders relevantesMoniorar e controlar o processo

Avaliar objetivamente a aderênciaRevisar situações com a alta direção

Nív

el -

2

Institucionalizar um processo definido Estabelecer um processo definidoColetar informações de melhoria N – 3

Institucionalizar um processo gerenciado quantitativamente

Estabelecer objetivos quantitativos para o processoEstabilizar desempenho de subprocesso N – 4

Cat

egor

ia

Áre

a de

Pro

cess

o

Gen

éric

os

Institucionalizar um processo em otimização

Gen

éric

os

Garantir melhoria de processo contínuaCorrigir a causa-raiz de problemas N – 5

A montagem da perspectiva: Documentado na sua versão primeira versão em 2001, desenvolvido pelo SEI (Software Engineering Institute of Carnegie Mellon University), em parceria com representantes da indústria, da academia e do governo norte-americano, a partir do CMM-SW versão v2.0, do CMM-IPD, EIA/IS 731 e da ISO/IEC 15504. A estrutura é bastante complexa e precisa de consultoria especializada para sua aplicação, sendo necessária a composição na empresa de grupos de apoio e a ser treinado no modelo a ser implantado. Com mais detalhes que o CMM, sua expectativa de implantação também é de dois anos por nível de evolução.

A perspectiva montada: É um modelo normativo, que disponibiliza um framework completo para sua aplicação, envolvendo a organização dos componentes, métodos de avaliação, artefatos associados e material de treinamento. Informações retiradas dos relatórios CMU/SEI-2002-TR-028 (2002b) (CMMI–SW–v1.1–Continuous Representation), CMU/SEI-2002-TR-029 (2002a) (CMMI–SW-v1.1–Staged Representation) e CMU/SEI-2002-TR-012 (2002c) (CMMI–SE/SW/IPPD/SS-v1.1–Staged Representation) disponíveis gratuitamente no site do SEI (http://www.sei.cmu.edu).

185

Quadro III.16: PSP - SEI

PSP - SEI O direcionamento do observador:

O PSP (Personal Software Process) é um processo de auto-melhoria projetado para auxiliar o engenheiro de software a administrar, controlar e melhorar a sua própria maneira de trabalhar, pois mostra como gerenciar a qualidade de seus projetos, assumir compromissos que possam ser cumpridos e melhorar estimativas e planejamento. É um framework de formulários, exercício, diretrizes e procedimentos de software que apoia a iniciativa a melhoria do desempenho individual.

Os pontos de convergência: Em 1989, Watts Humphrey, que participou do desenvolvimento do CMM e do TSP (Team Software Process), aplicou os princípios do CMM às práticas do desenvolvimento do software de um único colaborador. Possui sete níveis de evolução. Faz relação com todas os cinco níveis do CMM e envolve quase todas as suas KPA’s. (N5: Gerência de mudança do processo, Gerência de mudança da tecnologia e prevenção de defeitos. N4: Gerência quantitativa do processo, gerência da qualidade do software. N3: Foco no processo corporativo, definição do processo corporativo, gerência integrada do software, engenharia do produto de software, revisão por pares. N2: Planejamento de projetos, acompanhamento de projetos, garantia de qualidade do software)

As linhas mestras:

A evolução da habilidade do engenheiro de software está baseada na aplicação e adoção de disciplina, medidas, estimativas, planejamento e gerência da qualidade pessoais. A estrutura do PSP para essa evolução está fortemente relacionada com o treinamento completo na série de sete versões do processo (PSP0 até PSP3). Cada versão composta por um conjunto de registros, formulários e padrões.

A montagem da perspectiva: A experiência mostra que os benefícios se dão somente quando a equipe inteira do desenvolvimento termina todos os 10 exercícios, e isso se dá após um treinamento que dura 2 ou 3 semanas, em tempo integral. Não há certificação, mas há necessidade de autorização para ser instrutor oficial do PSP.

A perspectiva montada: Os métodos do PSP são: seguir um processo definido, planejar o trabalho, guardar dados, usar esses dados para analisar e melhorar os processo. “enquanto isso soa conceitualmente fácil, na prática não é fácil. Isso faz com que o principal foco do PSP seja a melhoria do ambiente de trabalho que dá suporte às práticas do PSP. Essa é a principal razão que o SEI desenvolveu o TSP (Team Software Process)” . Retirado de 8-PSP Discipline em http://www.sei.cmu.edu/publications/documents/00.reports/00tr022/00tr022chap08.html. Informações em http://www.sei.cmu.edu/tsp/psp.html, http://www.software.org/quagmire/descriptions/psp.asp, http://www.ic.unicamp.br/~cortes/mc726/cap6.pdf e Humphrey (1999).

186

III.4 A MONTAGEM DA PERSPECTIVA

Os modelos apresentados são de aplicação direta em organizações que mostram

capacidade de aplicar os conceitos de processos, de inter-relacionamento desses processos e

que tenham uma estrutura para implementar, implantar, acompanhar, avaliar, evoluir a

capacidade de desenvolvimento de software. A maturidade da organização é um elemento

favorável à aplicação e, principalmente à adaptação, dos modelos na realidade da estrutura

organizacional.

III.5 CONSIDERAÇÕES

Observa-se em quase todos os modelos mostrados:

• Referência à norma ISO 9001, em suas versões 1994 e 2000;

• Referência à norma ISO/IEC 12207:1995;

• Referência recursiva devido aos constantes processos de atualização e melhoria dos

processos. Um modelo atualizado faz referência a outro, que por sua vez ao ser

atualizado faz referência ao primeiro. Formando assim afinidades entre todos eles;

• Alguns conceitos podem ser usados em outros para sua complementação, adaptação,

clareza e/ou até mesmo melhoria. Caso da figura de grupos de trabalho do CMM e

CMMI (SEPG e SQA);

• O processo de adaptação à realidade da organização, sendo muito bem referenciado

na norma NBR ISO/IEC 12207(1998) e NBR ISO/IEC 15271 (2000).

A seguir a Tabela III.1 mostra um mapeamento entre a ISO 9001:2000, a ISO/IEC

12207:1995 e o CMMI, montada a partir de Mutafelija (2003), ISO/IEC 90003 (2004) e NBR

ISO 9001 (2000).

187

Tabela III.1: Mapeamento ISO 9001:2000(Seções 4,5 e 6 ) , ISO/IEC 12207:1995/Amd1:2002 e CMMI

CMMI ISO 9001:2000

ISO/IEC 12207:1995

e Amd.1:2002 * PA** N Práticas 4. Sistema de gestão da qualidade

Todas GP 2.1, 2.2, 2.3, 2.6, 2.8, 2.9, 3.1, 3.2 OPD 3 SP 1.1 OPF 3 SP 1.1, 2.2

4.1 Requisitos gerais Referências Gerais

SAM 2 GP 2.2, 2.7, 2.8, 2.9 SP 1.3, 2.2 4.2 Requisitos de documentação 6.1 e F.2.1

Todas GP 2.1 4.2.1 Generalidades

OPD 3 SP 1.1, 1.2, 1.3 Todas GP 2.2 4.2.2 Manual da qualidade OPD 3 SP 1.1 Todas GP 2.6 CM 2 Todas

4.2.3 Controle de documentos

PP 2 SP 2.3 Todas GP 2.6 CM 2 GP 2.2 SP todas

4.2.4 Controle de registros

PPQA 2 SP 2.2 5. Responsabilidade da direção 5.1 Comprometimento da direção Todas GP 2.1, 2.3, 2.10

Todas GP 2.7 5.2 Foco no cliente RD 3 SP 1.1-1, 1.1-2, 1.2, 2.1, 3.3, 3.4, 3.5 Todas GP 2.1 5.3 Política da qualidade OPF 3 SP 1.1

5.4 Planejamento Todas GP 4.1 OPF 3 SP 1.1 QPM 4 SP 1.1, 1.2, 1.3

5.4.1 Objetivos da qualidade

OPP 4 SP 1.3 Todas GP 2.2, 3.1 5.4.2 Planejamento do SGQ OPD 3 Todas

5.5 Responsabilidade, autoridade e comunicação

5.5.1 Responsabilidade e autoridade Todas GP 2.4 5.5.2 Representante da direção OPF 3 GP 2.4

OPD 3 GP 2.1 5.5.3 Comunicação interna OPF 3 GP 2.10 SP 1.1

5.6 Análise crítica pela direção Todas GP 2.6, 2.10 5.6.1 Generalidades OPF 3 SP 1.2, 1.3 Todas GP 2.10 5.6.2 Entradas para a análise crítica PMC 2 SP 1.6, 1.7, 2.1, 2.2, 2.3 Todas GP 2.10 5.6.3 Saídas da análise crítica PMC 2 SP 1.6, 1.7, 2.1, 2.2, 2.3

6.Gestão de recursos Todas GP 2.3 6.1 Provisão de recursos PP 2 SP 2.4

6.2 Recursos humanos 6.2.1 Generalidades F.3.3.1, F.3.3.2 Todas GP 2.5

Todas GP 2.5 OT 3 SP 1.1, 1.2, 1.3, 1.4, 2.1, 2.2, 2.3 PP 2 SP 2.5

6.2.2 Competências, conscientização e treinamento

OEI 3 SP 1.3 Todas GP 2.3 6.3 Infra-estrutura 7.2, F.3.2 OEI 3 SP 1.2 Todas GP 2.3 PP 2 SP 2.4

6.4 Ambiente de trabalho

OEI 3 SP 1.2

188

Tabela III.2: Mapeamento ISO 9001:2000(Seção 7 ) , ISO/IEC 12207:1995/Amd1:2002 e CMMI CMMI ISO 9001:2000 ISO/IEC 12207:1995

e Amd.1:2002 * PA** N Práticas 7. Realização do produto

Todas GP 2.2, 3.1 OPD 3 SP 1.1, 1.2, 1.3 IPM 3 SP 1.1, 1.3, 1.4 PP 2 SP 1.1,1.2,1.3,1.4,2.1,2.2,2.3,2.4,2.5,2.6, 2.7

7.1 Planejamento da realização do produto

5.2.4, 5.3.1, 6.1, 6.2, 6.3, 6.4, 6.5, 6.6, 6.7, 6.8, F.2

QPM 4 GP 2.3 SP 1.1, 1.2 7.2 Processos relacionados a clientes

RD 3 SP 1.1, 1.2, 2.1, 2.2, 2.3, 3.1, 3.2 RM 2 SP 1.1

7.2.1 Determinação de requisitos relacionados ao produto

5.3.2, 5.3.3, 5.3.4, F.1.3.1, F.1.3.2, F.1.3.4 TS 3 SP 1.2

RD 3 GP 2.7, 2.10 SP 1.1, 2.1, 3.5 VER 3 GP 2.7 SP 2.2

7.2.2 Análise crítica dos requisitos relacionados ao produto

5.2.1, 5.2.6, 6.4.2.1, 6.6, F.3.1.5

RM 2 GP 2.6, 2.7 SP 1.1, 1.2, 1.3, 1.5 RD 3 GP 2.7 RM 2 SP 1.2 MA 2 SP 2.4

7.2.3 Comunicação com o cliente 5.2.5.6, 5.2.6, 5.2.7, 6.6 F.1.4.2

IPM 3 SP 2.1,.2.2, 2.3 7.3 Projeto e desenvolvimento F.1.3.4, F.1.3.5

PP 2 Todas IPM 3 SP 1.1,1.3,1.4,2.1,2.2,2.3,3.1,3.2,4.1,4.2,4.3 CM 2 Todas RD 3 GP 2.2, 2.8, 2.9 RM 2 GP 2.2, 2.8, 2.9 TS 3 GP 2.2, 2.4, 2.7, 2.8, 2.9

SP 1.1, 1.2, 1.3, 2.1, 2.2, 2.3, 2.4, 3.1, 3.2 PI 3 GP 2.2, 2.4, 2.7 SP 1.1, 1.2, 1.3, 2.1, 2.2 VER 3 GP 2., 2.4, 2.7 SP 1.1 VAL 3 GP 2.2, 2.4, 2.7 SP 1.1

7.3.1 Planejamento do projeto e desenvolvimento

5.2.4, 5.3.1

QPM 4 SP 1.1, 1.2, 1.3 7.3.2 Entradas de projeto e desenvolvimento RD 3 GP 2.7, 2.10 SP 1.1,1.2,2.1,3.2,3.3,3.4,3.5

TS 3 Todas 7.3.3 Saídas de projeto e desenvolvimento 5.3.5, 5.3.6, 5.3.7 IPM 3 SP 1.1 PMC 2 GP 2.7 SP 1.4, 1.6, 1.7 7.3.4 Análise crítica de projeto e

desenvolvimento 5.3.4.2, 5.3.5.6, 5.3.6.7, 6.6.3, F.2.6 TS 3 GP 2.8

7.3.5 Verificação de PD 5.3, 6.4, F.1.3, F.2.4 VER 3 GP 2.6 SP 1.1,1.2,1.3,2.1, 2.2, 2.3, 3.1, 3.2 VAL 3 GP 2.6 SP 1.1, 1.2, 1.3, 2.1, 2.2 7.3.6 Validação de PD 5.3, 6.5, F.1.3, F.2.5 PI 3 GP 2.6 CM 2 Todas TS 3 GP 2.6

7.3.7 Controle de alteração de PD 5.5.2, 5.5.3, 6.1, 6.2, F.2.1, F.2.2

PI 3 GP 2.6 7.4 Aquisição

SAM 2 GP 2.6, 2.9 SP 1.1, 1.2, 2.2, 2.3 TS 3 SP 1.1, 1.2, 1.3, 2.4

7.4.1 Processo de aquisição 5.1, F.1.1

PI 3 SP 3.1 7.4.2 Informações de aquisição 5.1.2, F.1.1.1 SAM 2 SP 1.1, 1.3, 2.1

SAM 2 SP 1.3, 2.1, 2.2, 2.3 7.4.3 Verificação de produto adquirido 5.1.5, F.1.1.4 VER 3 SP 3.1

7.5 Produção e fornecimento de serviço TS 3 GP 2.2, 2.3, 2.6, 2.8 SP 3.1, 3.2 7.5.1 Controle de produção e

fornecimento de serviço 5.3.12, 5.4.4, 5.5, 6.3.3, 6.8, F.1.3.11, F.1.4.2, F.1.5, F.2.8

PI 3 SP 3.1, 3.2, 3.3, 3.4

VAL 3 Todas 7.5.2 Validação dos processos de produção e fornecimento de serviço

RD 3 SP 3.5 CM 2 SP 1.1, 1.3, 2.1, 2.2, 3.1 RM 2 SP 1.4

7.5.3 Identificação e rastreabilidade 6, F.2.2

PI 3 SP 3.1, 3.2, 3.3 7.5.4 Propriedade do cliente Não coberta pelo CMMI 7.5.5 Preservação do produto PI 3 SP 3.4

VER 3 G.P 2.8 VAL 3 GP 2.8

7.6 Controle de dispositivos de medição e monitoramento.

MA 2 GP 2.1, 2.2, 2.8, 2.9, 2.10

189


CMMI ISO 9001:2000 ISO/IEC 12207:1995 e Amd.1:2002 * PA** N Práticas

8. Medição, análise e melhoria Todas GP 2.2, 2.8 MA 2 GP 2.2 SP 1.1, 1.2, 1.3, 1.4

8.1 Generalidades 7, F.3.3

QPM 4 SP 2.1, 2.2, 2.3, 2.4 8.2 Medição e monitoramento

MA 2 SP 1.1, 1.2, 2.2 8.2.1 Satisfação dos clientes PMC 2 SP 1.5 OPF 3 GP 2.1, 2.2, 2.4 SP 1.1, 1.2, 1.3, 2.1, 2.2 PPQA 2 GP 2.2, 2.4, 2.6, 2.9 SP Todas

8.2.2 Auditoria interna 6.3, 6.7, F.2.3, F.2.7

MA 2 SP 2.4 Todas GP 2.8, 4.2 MA 2 GP 2.2 SP 1.2, 1.3, 1.4 QPM 4 SP 2.2, 2.3

8.2.3 Medição e monitoramento de processos

7.3.2, 7.3.3, F.3.3.2

PMC 2 SP 2.1, 2.2, 2.3 MA 2 SP 2.1 VAL 3 SP 1.3, 2.1, 2.2 VER 3 SP 1., 1.3, 2.1, 2.2, 2.3, 3.1, 3.2 RM 2 SP 1.1 SAM 2 SP 1.3 PPQA 2 PS 1.2

8.2.4 Medição e monitoramento de produto

5.3, F.1.3

CM 2 3.2 VER 3 GP 2.4 SP 1.3, 3.2 VAL 3 GP 2.4 SP 1.3, 2.2 PMC 2 SP 2.1, 2.2, 2.3

8.3 Controle de produto não-conforme 6.2, 6.8, F.2.2, F.2.8

CM 2 Todas Todas GP 2.8, 3.2 MA 2 SP 2.2, 2.3, 2.4 OPF 3 SP 1.2, 1.3 OPP 4 SP 1.1, 1.2, 1.3, 1.4, 1.5 RD 3 SP 1.1, 1.2, 2.1, 3.1, 3.2, 3.3, 3.4 QPM 4 SP 1.4 CAR 5 SP 1.1, 1.2

8.4 Análise de dados

SAM 2 SP 2.2 8.5 Melhorias

Todas GP 5.1 OPF 3 SP 1.1 OID 5 SP 1.1

8.5.1 Melhoria contínua 7.3, F.3.3

MA 2 SP 1.1, 1.2, 1.4, 2.1, 2.2 Todas GP 5.2 CAR 5 Todas OPF 3 SP 2.1, 2.2, 2.3

8.5.2 Ação corretiva 6.8, F.2.8

PMC 2 SP 2.1, 2.2, 2.3 Todas GP 5.2 OPF 3 SP 2.4

8.5.3 Ação preventiva 7.3.2, F.3.3.2

CAR 5 SP 1.1, 1.2, 2.1, 2.2, 2.3 * Corresponde às seções da Norma ISO/IEC 12207:1995 e ISO/IEC 12207:1995/Amd.1:2002. ** As PAs descritas netas tabelas estão descritas no Quadro III.15

190

APÊNDICE IV MANUAL DA QUALIDADE

191

APÊNDICE V CHECKLIST PARA O LEVANTAMENTO GERAL DA EMPRESA

<Logo> Levantamento Geral ISO-9001

191/2 __________________________________________________________________________ Reunião: <dd/mm/aaaa > Participantes : Conhecimento da Organização: A. Qual é o principal negócio da organização?

B. Qual é o mercado que atinge?

C. Quais seus principais concorrentes?

D. Qual sua participação no mercado?

E. Como está definida a estrutura da organização?

F. Quais os papéis organizacionais?

G. Quais são as instalações e equipamentos disponíveis?

H. Quais os recursos destinados ao SGQ?

I. Quais as expectativas de melhoria e evolução do SGQ?

J. Quais as expectativas ou necessidades para a certificação oficial do SGQ?

K. Quais seus propósitos e objetivos?

L. Quais seus produtos de vendas?

M. Quais produtos são de uso interno?

N. Quais seus serviços?

O. Quais seus processos organizacionais?

P. Quais seus processos fundamentais?

Q. Quais seus processos de apoio?

R. Quais os controles internos?

S. Como são distribuídas as informações, tarefas ou atividades entre os colaboradores?

T. Quais as atividades relacionadas à qualificação profissional?

U. Como são reconhecidos os requisitos e as expectativas do cliente?

V. Qual o escopo da certificação?

W. Quais são a Missão e a Visão de Futuro da organização?

X. Quem são seus principais clientes?

Y. Quem são seus principais fornecedores?

Z. De que forma a organização realiza seu Planejamento Estratégico?

192

192

APÊNDICE VI

PROCEDIMENTO DE DESCRIÇAO DO SGQ

<LOGO>

PROCEDIMENTO DE DESCRIÇÃO DO SGQ

VERSÃO < x.x>

<Código>

193

< logo > PROCEDIMENTO DE DESCRIÇÃO DO SGQ 2/7

_________________________________________________________________________________________________________________

ÍNDICE

1 INTRODUÇÃO...............................................................................................................................194

1.1 Objetivo ............................................................................................................................................... 194 1.2 Glossário.............................................................................................................................................. 194 1.3 Referências .......................................................................................................................................... 194

2 APLICAÇÃO..................................................................................................................................194 3 RESPONSABILIDADES.................................................................................................................194 4 CONDIÇÕES GERAIS....................................................................................................................194

4.1 Sistema de Gestão da Qualidade.......................................................................................................... 194 4.2 Requisitos Gerais................................................................................................................................. 195

4.2.1 Características gerais do SGQ ..................................................................................................... 195 5 CONDIÇÕES ESPECÍFICAS ..........................................................................................................195

5.1 Estrutura Documental do Sistema da Qualidade ................................................................................. 195 5.2 Planejamento da Qualidade ................................................................................................................. 197

5.2.1 Estrutura ...................................................................................................................................... 197 5.2.2 Novos produtos............................................................................................................................ 197

<Código> Versão <x.x> Data: 6/1/2006

194


_________________________________________________________________________________________________________________

HISTÓRICO DAS REVISÔES

Data Versão Autor Descrição

13/09/2005 V 1.0 Raimundo Sales Estruturação deste procedimento.

1 INTRODUÇÃO 1.1 Objetivo

O objetivo deste procedimento é descrever o Sistema de Gestão da Qualidade (SGQ) da <empresa>.

1.2 Glossário

Item Definição

SGQ Sistema de Gerência da Qualidade

1.3 Referências Não há.

2 APLICAÇÃO Este procedimento é o padrão adotado na < empresa > para descrever o SGQ.

3 RESPONSABILIDADES É responsabilidade do Representante da Direção (RD) o gerenciamento das atividades relativas ao SGQ.

Na .............. a função que assume as responsabilidades do RD é o ..........

4 CONDIÇÕES GERAIS

4.1 Sistema de Gestão da Qualidade

A < empresa > possui um SGQ que atende os requisitos da ISO 9001. Esse sistema é mantido atualizado e sua eficácia é melhorada de forma contínua, de acordo com o determinado em sua Política da Qualidade e pelas diretrizes básicas da Direção.


195


_________________________________________________________________________________________________________________

Suas características estão descritas em procedimentos documentados, os quais são elaborados de forma a descrever a metodologia de realização das atividades relacionadas com a qualidade de processos e produtos.

4.2 Requisitos Gerais

4.2.1 Características gerais do SGQ • O SGQ abrange os processos e as atividades relacionadas com a qualidade de produtos e

serviços oferecidos pela < empresa >. • A responsabilidade pela execução dessas atividades e suas interfaces, quando aplicável,

encontram-se definidas explicitamente nos procedimentos documentados. • O SGQ determina a seqüência e a interação dos processos da empresa, mediante

procedimentos documentados, que descreve o relacionamento existente entre suas diferentes atividades.

• Define, quando aplicável, os critérios e métodos necessários que permitem assegurar que a operação e o controle desses processos seja eficaz.

• Assegura, mediante requisitos de Programação Orçamentária, a disponibilidade de recursos relativos à Implementação, Manutenção e Melhoria contínua do SGQ, Gestão de Pessoal, Infra-estrutura e ao Ambiente de Trabalho.

• Assegura a disponibilidade de informações necessárias para a adequada operação e monitoramento dos processos e atividades correlatas.

• Permite o monitoramento, a medição e a análise dos processos, quando requerido, permitindo desta forma uma adequada Análise Crítica dos mesmos pela Alta Direção.

• Determina a necessidade de definir, implementar e verificar a eficácia das ações necessárias para atingir os resultados planejados e a melhoria contínua dos processos.

• Permite, mediante adequada qualificação de fornecedores e a aplicação de controles e critérios preestabelecidos, monitorar produtos e processos adquiridos externamente.

5 CONDIÇÕES ESPECÍFICAS

5.1 Estrutura Documental do Sistema da Qualidade A estrutura documental do Sistema da Qualidade atende aos seguintes critérios:

• Leis, decretos, portarias ................................. (Documentos legais) • Manual da Qualidade ..................................... (Documento Principal do SQ) • Procedimentos ................................................ (Documentos Normalizadores) • Tutorais ........................................................... (Documentos Operacionais) • Formulários / Modelos .................................... (Suporte para registros de dados) • Registros ......................................................... (Resultados / evidências)

O Manual da Qualidade, inclui:

• A descrição do escopo de certificação. • Faz referência aos procedimentos documentados utilizados nas diferentes atividades

relacionadas com os processos administrativos e produtivos. • Descreve a interação entre os processos do SGQ.


196


_________________________________________________________________________________________________________________ • Política da Qualidade. • Aprovação pela Diretoria. • Revisão do documento.

As atividades que influenciam direta ou indiretamente a qualidade dos processos ou produtos são descritas em Procedimentos e Tutoriais, que são utilizados para assegurar a correta realização das mesmas e o atendimento aos requisitos especificados.

No SGQ, existem 13 procedimentos documentados em três tipos de procedimentos: organizacionais, de apoio, e fundamentais.

Procedimentos Organizacionais: são procedimentos institucionais empregados que contribuem para a melhoria da empresa e estão fora do domínio de um único projeto.

• PO21 – Procedimento para Segurança • PO23 – Procedimento de responsabilidades da direção • PO24 – Procedimento para qualificação de fornecedores • PO27 – Procedimento de qualificação profissional • PO30 – Programa Estratégico de Qualificação

Procedimentos de Apoio: são procedimentos que auxiliam e contribuem para o sucesso e a qualidade do projeto e ou produto.

• PA00– Procedimento para descrever o SGQ • PA01 – Procedimento de controle de documentos • PA02 – Procedimento de controle de registros do sistema da qualidade • PA03 – Procedimentos para auditorias internas da qualidade • PA04 – Procedimento de controle de produto não-conforme • PA05 – Procedimento para ação corretiva e ação preventiva

Procedimentos Fundamentais: são procedimentos usados diretamente no ciclo de vida do software.

• PF20 – Procedimento de projeto e desenvolvimento de sistemas • METODOLOGIA - Metodologia de Desenvolvimento de Software da < empresa >

Os procedimentos determinam (ou fazem referência), quando necessário, a utilização de documentos operacionais, técnicos e ou para suporte de registros e dados, tais como Tutorais e Formulários.

Os registros da qualidade necessários são definidos nas diferentes fases operacionais, assim como os formulários aplicáveis como suporte dessa informação e dos dados.

A responsabilidade pela gestão dos processos descritos nos procedimentos documentados está definida no próprio corpo de cada documento, exceto no caso de formulários, onde não é requerido.

Quando necessário, a implementação dos documentos do SGQ é precedida de treinamento das funções envolvidas, de forma a garantir a correta interpretação e aplicação dos requisitos especificados.


197


_________________________________________________________________________________________________________________

Quando as atividades relacionadas requerem treinamento específico para qualificação das funções envolvidas, o mesmo é realizado e seus resultados são registrados de forma documentada.

5.2 Planejamento da Qualidade

O planejamento da qualidade é realizado a partir das diretrizes determinadas pela Direção da < empresa > na Política da Qualidade e deve ser coerente com os Objetivos para Qualidade.

Neste planejamento, são levados em consideração os requisitos de gestão da qualidade e a implementação de melhorias contínuas necessárias para atender a Política da Qualidade e manter a integridade do SGQ.

Estas melhorias são operacionalizadas mediante implementação de mudanças no SGQ, de forma a mantê-lo permanentemente atualizado e em consonância com os requisitos especificados pelos clientes.

5.2.1 Estrutura

As atividades que influenciam direta ou indiretamente a qualidade, são realizadas de forma estruturada. Essa estrutura inclui atividades de verificação e controle da qualidade nas diversas etapas dos processos, as quais são realizadas de forma planejada e obedecendo a requisitos e instruções definidas nos procedimentos documentados do SGQ.

Quando requerido, os critérios de aprovação e rejeição estão definidos nos documentos aplicáveis e são aplicados para avaliar a qualidade dos produtos.

Métodos apropriados de identificação permitem conhecer, em etapas apropriadas dos processos, a situação de inspeção e ensaios e o status dos produtos.

As etapas dos processos onde atividades de verificação e controle da qualidade são realizadas, assim como a documentação aplicável está definidas no fluxograma denominado “Plano Geral da Qualidade”.

5.2.2 Novos produtos

Quando novos produtos, resultado de novas parcerias ou ampliação dos negócios da empresa são incorporados aos processos da < empresa >, o tratamento a eles dispensado é similar aos produtos tradicionais, de acordo com o descrito no SGQ e no Plano Geral da Qualidade.

Nos casos em que é necessário tratamento diferenciado, os requisitos específicos são definidos individualmente, de forma documentada, e comunicados às funções envolvidas, como requerido.


198


_________________________________________________________________________________________________________________

PLANO GERAL DA QUALIDADE

INÍCIO

MANUAL DA QUALIDADE

POLÍTICA DA QUALIDADE

ORGANIZAÇÃO

RESPONSABILIDADE / AUTORIDADE RECURSOS

ANÁLISE CRÍTICA PELA DIREÇÃO

REPRESENTANTE DA DIREÇÃO

NOVOS PRODUTOS SISTEMA DA QUALIDADE PLANEJAMENTO DA

QUALIDADE

DOCUMENTOS DO SISTEMA DA QUALIDADE

PROCEDIMENTOS DE APOIO

PA00 PA01 PA02

PA03 PA04 PA05

Metod

PF20

PROCEDIMENTOS FUNDAMENTAIS

DOCUMENTOS LEGAIS

* DOCUMENTOS COMPLEMENTARES

PROCEDIMENTOS ORGANIZACIONAIS

PO24 PO27 PO30

PO21 PO23

Projeto * Documentos Complementares Tutoriais – Registros - Formulários - NORMAS


199

APÊNDICE VII PROCEDIMENTO DE CONTROLE DE DOCUMENTOS

<LOGO>

PROCEDIMENTO DE CONROLE DE DOCUMENTOS

VERSÃO < x.x>

<Código>

200

< logo > PROCEDIMENTO DE CONTROLE DE DOCUMENTOS 200/6

_________________________________________________________________________________________________________________

ÍNDICE

1 INTRODUÇÃO...............................................................................................................................201



4.1 Definições............................................................................................................................................ 202 4.1.1 Documento Normativo ................................................................................................................ 202 4.1.2 Documentos Legais ..................................................................................................................... 202 4.1.3 Manual da Qualidade................................................................................................................... 202 4.1.4 Procedimento............................................................................................................................... 202 4.1.5 Instrução de Trabalho / Tutoriais................................................................................................. 202 4.1.6 Especificação Técnica ................................................................................................................. 202 4.1.7 Outros Documentos Complementares ......................................................................................... 203

4.2 Controle de Documentos do SGQ ....................................................................................................... 203 4.2.1 Data de Validade dos Documentos do SGQ................................................................................ 203 4.2.2 Documentos Normativos do SGQ ............................................................................................... 203

5 CONDIÇÕES ESPECÍFICAS ..........................................................................................................203 5.1 Documentos de Origem Interna........................................................................................................... 203

5.1.1 Emissão de Documentos.............................................................................................................. 203 5.1.2 Alteração de Documentos............................................................................................................ 203

5.2 Documentos e Dados de Origem Externa............................................................................................ 204 5.3 Documentos e Dados de Origem Interna............................................................................................. 204 5.4 Controle ............................................................................................................................................... 204

5.4.1 Distribuição, Cancelamento, Recolhimento, e Expurgo .............................................................. 204

<Código> Versão <x.x> Data: 6/1/2006 200

201


_________________________________________________________________________________________________________________

HISTÓRICO DAS REVISÔES

Data Versão Autor Descrição 13/09/2005 V 1.0 Raimundo Sales Estruturação deste procedimento.

1 INTRODUÇÃO

1.1 Objetivo O objetivo deste procedimento é descrever o Sistema de Gestão da Qualidade (SGQ) da <empresa>.

O objetivo deste procedimento é definir a metodologia para o controle de documentos do SGQ da <empresa>.

1.2 Glossário

Item Definição SGQ Sistema de Gerência da Qualidade

1.3 Referências [1] SQ.PO21 – Procedimento de Segurança.

2 APLICAÇÃO Este procedimento é o padrão adotado na < empresa > para o controle de documentos do SGQ.

3 RESPONSABILIDADES É responsabilidade do Diretor / Gerente da área de aplicação:

a) A análise crítica, atualização, aprovação, e cancelamento dos documentos da qualidade antes de sua emissão ou substituição.

b) Assegurar que:

• Alterações e a situação da versão atual dos documentos sejam identificadas.

• As versões pertinentes de documentos aplicáveis estejam disponíveis nos locais de uso.

• Os documentos permaneçam legíveis e prontamente identificáveis.

• Documentos de origem externa sejam identificados e que sua distribuição seja controlada.


202


_________________________________________________________________________________________________________________

c) Evitar o uso não intencional de documentos obsoletos e aplicar identificação adequada nos casos em que sejam retidos por qualquer propósito

Essas atividades podem ser realizadas de forma individual ou conjunta.


4.1 Definições

4.1.1 Documento Normativo O documento normativo tem como objetivo descrever processos, procedimentos ou características previamente estabelecidas. Exemplo: Manual da Qualidade, Procedimentos, Instruções de trabalho, Tutoriais, Normas de Origem Externa.

4.1.2 Documentos Legais São leis, decretos, portarias, regulamentos, códigos, normas, incluindo dados de origem Federal, Estadual, Municipal ou de Órgãos Competentes Públicos ou Privados, encarregados de regulamentação de atividades e cujas determinações afetam direta ou indiretamente a qualidade dos produtos ou serviços da empresa.

Nota: As normas externas, que afetam os processos de desenvolvimento, estão definidas no documento “A Legislação Brasileira”, editado anualmente pelo MCT - Secretaria de Política de Informática. Os textos legislativos contidos neste volume, estão disponíveis selecionando-se a opção Legislação em http://www.mct.gov.br/sepin.

4.1.3 Manual da Qualidade Documento que define o escopo da Certificação, faz referência aos procedimentos aplicáveis e descreve a interação entre os processos do SGQ.

4.1.4 Procedimento Forma especificada de executar uma atividade ou um conjunto de atividades inter-relacionadas ou interativas que transformam insumos (entradas) em produtos (saídas).

4.1.5 Instrução de Trabalho / Tutoriais Define e descreve de forma estruturada como se realiza uma atividade específica.

4.1.6 Especificação Técnica Define requisitos especificados.

Nota 1: Uma especificação técnica pode ser um documento de origem externa, quando emitido por um cliente, fornecedor ou parceiro que não pertence à organização, para descrever requisitos especificados de um produto ou processo que não é desenvolvido ou realizado na organização. Nota 2: Folhetos, manuais comerciais de referência para comercialização de produtos, manuais descritivos e similares, não são considerados documentos do SGQ, exceto quando indicado explicitamente.


203


_________________________________________________________________________________________________________________

4.1.7 Outros Documentos Complementares Existem outros documentos complementares de origem externa que podem ser aplicados, quando requerido nas atividades do SGQ.

A emissão de revisões desses documentos de origem externa é de responsabilidade da fonte onde se origina. Para atualização é realizada uma verificação periódica dos mesmos ou, se requerido, a qualquer momento no caso de pesquisa eletrônica.

4.2 Controle de Documentos do SGQ

4.2.1 Data de Validade dos Documentos do SGQ A data de validade dos documentos de origem interna é a registrada como data da aprovação da versão de referência, que conta no Histórico de Revisão, de cada documento.

4.2.2 Documentos Normativos do SGQ

4.2.2.1 Original É a última versão aprovada do documento que se encontra disponível para uso.

4.2.2.2 Cópia Controlada • É a cópia válida do documento original. Sua reprodução não autorizada, através de

qualquer meio, não é permitida. • Quando seja requerida uma cópia controlada, deve ser feita uma solicitação ao responsável

pela documentação, que se encarregará de sua emissão e controle. • As cópias controladas devem ser identificadas com os dizeres “Cópia Controlada”. • O conceito de “Cópia controlada” não se aplica aos formulários os quais podem ser

reproduzidos de forma direta por duplicação ou impressos, respeitando a versão válida. • Os formulários não requerem identificação como “Cópia Controlada”.

4.2.2.3 Cópia não Controlada • São cópias de um documento, utilizadas para conhecimento informal ou para outros fins

que não a aplicação nas atividades as quais se refere. • São identificadas com os dizeres “Cópia não controlada”.


5.1 Documentos de Origem Interna

5.1.1 Emissão de Documentos. Antes de emitir um documento, o mesmo deve ser aprovado.

5.1.2 Alteração de Documentos • As alterações de documentos ou tabelas de dados do SGQ são realizadas a partir da

abertura de uma versão. • A aprovação da alteração, é realizada pela mesma função, que realizara a análise crítica e

aprovação original, ou por função autorizada. • Os documentos obsoletos são substituídos pela nova versão, após liberação para uso. • Cópias físicas são retiradas dos locais de uso e eliminadas para evitar seu uso não

intencional.


204


_________________________________________________________________________________________________________________ • Os originais obsoletos são preservados, quando requerido para eventual consulta,

comprovação legal e ou preservação da memória institucional.

5.2 Documentos e Dados de Origem Externa

5.2.1.1 Aquisição de Documentos O responsável pela área de aplicação solicita ao órgão emitente ou distribuidor do documento, o envio da última versão emitida, revisada ou reeditada, para efeito de utilização ou atualização.

Na impossibilidade da aquisição de exemplares originais de documentos e ou tabelas de dados de origem externa, as cópias são validadas com um carimbo “Conforme original”.

O controle de um documento de origem externa é realizado de forma análoga aos de origem interna.

5.3 Documentos e Dados de Origem Interna

5.4 Controle

O controle dos documentos do SGQ é feito pelo sistema <sistema>

5.4.1 Distribuição, Cancelamento, Recolhimento, e Expurgo

5.4.1.1 Distribuição de Cópias Controladas

A distribuição de cópias controladas dos documentos do SGQ é realizada mediante a abertura de um documento denominado Posto de Cópias, cujo conteúdo é controlado.

5.4.1.2 Cancelamento O cancelamento de documentos é realizado automaticamente, após aprovação da versão correspondente.

5.4.1.3 Arquivamento Os originais dos documentos da qualidade (exceto aqueles elaborados em meio exclusivamente físico) e suas revisões anteriores são arquivada em meio eletrônico, para garantir a preservação da sua integridade.

Os originais e suas cópias controladas, quando emitidos em meio físico, são arquivados em pastas.

Para segurança e garantia de preservação dos documentos e dados em meio eletrônico é realizado periodicamente backup que está descrito no procedimento SQ.PO21 – Segurança [1].

5.4.1.4 Expurgo de Documentos Obsoletos As cópias controladas dos documentos, tabelas de dados em meio físico e ou eletrônico e os formulários obsoletos são recolhidos dos locais de uso ou guarda e eliminados ou excluídos.

As cópias controladas (em meio físico) canceladas são removidas dos postos de cópias para evitar sua utilização não intencional.


205

APÊNDICE VIII PROCEDIMENTO DE CONTROLE DE REGISITROS DO SGQ

<LOGO>

PROCEDIMENTO DE CONROLE DE REGISTROS DO SGQ

VERSÃO < x.x>

<Código>

206

< logo > PROCEDIMENTO DE CONTROLE DE REGISROS DO SGQ 2/6

_________________________________________________________________________________________________________________

ÍNDICE

1 INTRODUÇÃO...............................................................................................................................207



4.1 Registros da Qualidade........................................................................................................................ 207 4.2 Controle ............................................................................................................................................... 208 4.3 Registros oriundos de fornecedores..................................................................................................... 208 4.4 Disponibilidade de registros ................................................................................................................ 208

5 CONDIÇÕES ESPECÍFICAS ..........................................................................................................208 5.1 Identificação ........................................................................................................................................ 208

5.1.1 Apresentação ............................................................................................................................... 208 5.1.2 Meio............................................................................................................................................. 208 5.1.3 Origem......................................................................................................................................... 208 5.1.4 Armazenamento........................................................................................................................... 208 5.1.5 Proteção ....................................................................................................................................... 209 5.1.6 Acesso ......................................................................................................................................... 209 5.1.7 Recuperação ................................................................................................................................ 209 5.1.8 Retenção ...................................................................................................................................... 209 5.1.9 Descarte ....................................................................................................................................... 209


207


_________________________________________________________________________________________________________________

HISTÓRICO DAS REVISÕES


1 INTRODUÇÃO

1.1 Objetivo Este procedimento define a metodologia para identificar, armazenar, proteger, recuperar, reter e descartar os registros do SGQ da <empresa>.

1.2 Glossário

Item Definição SGQ Sistema de Gerenciamento da Qualidade

1.3 Referências [1] Tabela de Controle de Registros da Qualidade

2 APLICAÇÃO Este procedimento é o padrão adotado na < empresa > para o controle de registros do SGQ.

3 RESPONSABILIDADES É responsabilidade do Representante da Direção (RD):

• Definir a metodologia a ser aplicado para identificação, armazenamento, proteção, recuperação, retenção e descarte dos registros do SGQ:

• Implementar os controles a serem realizados nos registros do SQQ. • Orientar os responsáveis das áreas quanto à necessidade de que os registros da qualidade sejam

realizados de forma legível e armazenados e mantidos para permitir sua pronta recuperação, evitando danos, deterioração e perdas que comprometam a integridade das informações.

• Controlar os registros da qualidade como definido neste procedimento. • Solicitar a inclusão / alteração / cancelamento de registros da qualidade.


4.1 Registros da Qualidade Registro de qualidade são informações documentadas de forma sistemática ou recebidas pela empresa, que evidenciam objetivamente a execução de uma determinada atividade relacionada com o SGQ.


208


_________________________________________________________________________________________________________________

4.2 Controle O método utilizado para realizar as atividades de identificação, armazenamento, proteção, recuperação, retenção e descarte dos registros do SGQ está descrito no formulário denominado Tabela de Controle de Registros da Qualidade [1].

4.3 Registros oriundos de fornecedores Os registros da qualidade oriundos de fornecedores recebem o mesmo tratamento que os Registros de origem interna, e são identificados como Registros de origem externa.

4.4 Disponibilidade de registros Quando acordado em contrato, os registros estão disponíveis para avaliação pelo cliente ou seu representante, durante 0o período acordado.


5.1 Identificação Identificação é a forma pela qual os registros são denominados.

5.1.1 Apresentação Forma em que se apresenta o registro:

• (CB) Carimbo • (FM) Formulário • (RL) Relatório • (CT) Certificado • (RE) Registro Eletrônico

5.1.2 Meio Forma na qual os registros são mantidos:

• (CF) Cópia física. • (EL) Meio eletrônico.

5.1.3 Origem A origem dos documentos está definida pela descrição do local de coleta. Essa origem pode ser:

• Administração (AD) • Desenvolvimento (DE) • Comercial (CL) • Suporte (SU) • Sistema da Qualidade (SQ) • Origem Externa (EXT) • Origem Interna (INT)

5.1.4 Armazenamento Armazenamento são as formas de guardar de maneira organizada os meios que contém os registros da qualidade. Para armazenamento dos registros podem ser utilizados os seguintes suportes:

• Pasta Eletrônica (PE) • Pasta Colecionadora (PC) • Pasta Suspensa (PS) • Caixa de Arquivos (CA)


209


_________________________________________________________________________________________________________________ • Envelope (EN)

A guarda é realizada em mobiliário (ou meio eletrônico): Servidor (Rede) (SE) • Arquivo (AR) • Estante (ES) • Armário (AM) • Gaveta (GV)

O local de guarda pode ser: Administração (AD) • Desenvolvimento (DE) • Comercial (CL) • Suporte (SU) • Sistema da Qualidade (SQ)

5.1.5 Proteção São as medidas de segurança que devem ser adotadas para preservar os registros da qualidade:

• Os registros emitidos em fax são fotocopiados. (FC) • Os registros são mantidos em ambientes, protegidos contra umidade e poeiras. (AP) • Os registros emitidos por meio eletrônico são mantidos para segurança em backup (BU).

Nota: cópias de segurança do backup devem ser mantidas em ambiente externo à empresa.

5.1.6 Acesso O acesso aos registros está distribuído em dois níveis de autorização:

• Livre (LI): não requer autorização para consulta. • Restrito (RE): a consulta é permitida mediante autorização do responsável pela área de

controle. Nota: Os Auditores do Sistema da Qualidade têm acesso livre em ambos níveis, durante o processo de auditoria.

5.1.7 Recuperação Recuperação é o processo de ordenação (indexação) dos registros da qualidade em seus suportes para arquivamento, com objetivo de facilitar a localização das informações. Para indexação genérica dos registros são utilizadas uma ou mais das seguintes ordenações:

• Alfabética (AF) • Assunto (AS) • Código (CO) • Cronológica (CR) • Numérica (NU) • Categoria (CT)

Quando necessário, outro tipo de ordenação pode ser utilizada.

5.1.8 Retenção Retenção é o prazo definido para que os registros sejam mantidos. O tempo de retenção dos registros é definido em meses, salvo quando indicado de forma diferente.

5.1.9 Descarte Descarte é o destino definido para os registros depois de cumprido o prazo de retenção. A disposição pode ser:

• Expurgar (EX) • Preservar (PV)


210

APÊNDICE IX Procedimento para Auditoria Interna

<LOGO>

PROCEDIMENTO PARA AUDITORIA INTERNA DO SGQ

VERSÃO < x.x>

<Código>

211

< logo > PROCEDIMENTO PARA AUDITORIA INTERNA DO SGQ 211/5

_________________________________________________________________________________________________________________

ÍNDICE

1 INTRODUÇÃO...............................................................................................................................212


2 APLICAÇÃO..................................................................................................................................212 3 RESPONSABILIDADES.................................................................................................................212

3.1 Representante da Direção .................................................................................................................... 212 3.2 Auditor................................................................................................................................................. 212

4 CONDIÇÕES GERAIS....................................................................................................................212 4.1 Objetivos da Auditoria......................................................................................................................... 212 4.2 Requisitos para Qualificação de Auditores da Qualidade.................................................................... 213

4.2.1 Escolaridade, treinamento e conhecimentos específicos ............................................................. 213 4.3 Atividades do Auditor ......................................................................................................................... 213

5 CONDIÇÕES ESPECÍFICAS ..........................................................................................................213 5.1 Seleção do Auditor .............................................................................................................................. 213 5.2 Periodicidade da Auditoria .................................................................................................................. 213 5.3 Programação das Auditorias ................................................................................................................ 213 5.4 Comunicação da Auditoria .................................................................................................................. 213 5.5 Reunião de Abertura............................................................................................................................ 214 5.6 Execução da Auditoria......................................................................................................................... 214 5.7 Evidências Objetivas ........................................................................................................................... 214 5.8 Relatório de Auditoria ......................................................................................................................... 214 5.9 Resultado das auditorias ...................................................................................................................... 214


212


_________________________________________________________________________________________________________________



1 INTRODUÇÃO

1.1 Objetivo Este procedimento define a metodologia utilizada para realização de Auditorias Internas do SGQ da <empresa> e estabelecer os critérios para qualificação de auditores internos da qualidade

1.2 Glossário

Item Definição SGQ Sistema de Gerenciamento da Qualidade RNC Relatório de Não-Conformidades

1.3 Referências [ 1 ] Relatório de Auditoria

[ 2 ] Relatório de Não-Conformidade

2 APLICAÇÃO Este procedimento é o padrão adotado na < empresa > para auditorias internas do SGQ.

3 RESPONSABILIDADES

3.1 Representante da Direção Coordenar e realizar as Auditorias Internas do Sistema da Qualidade.

3.2 Auditor Realizar as Auditorias do Sistema da Qualidade.


4.1 Objetivos da Auditoria As auditorias do SGQ são realizadas de forma planejada e sistemática, sendo documentadas e possuem os seguintes objetivos:

• Verificar a eficácia do SGQ no atendimento aos objetivos da qualidade; • Verificar a conformidade dos elementos do SGQ, com os requisitos especificados; • Permitir a realimentação do SGQ para subsidiar o processo de melhoria contínua do mesmo. • Verificar o atendimento de requisitos regulamentares exigidos.


213


_________________________________________________________________________________________________________________

4.2 Requisitos para Qualificação de Auditores da Qualidade

4.2.1 Escolaridade, treinamento e conhecimentos específicos • Curso sobre Formação de Auditores de Sistema de Qualidade ISO 9001. • Conhecimento da estrutura e documentação do SGQ.

4.3 Atividades do Auditor • Elaborar o Planejamento de auditorias internas. • Definir os requisitos de recursos necessários para realização de cada auditoria. • Informar ao responsável pelo setor a ser auditado, a data da auditoria, o escopo da mesma, assim

como os horários e a duração prevista. • Analisar criticamente a documentação relacionada com as atividades a serem auditadas, para

verificar sua adequação com os requisitos da ISO 9001. • Realizar a reunião de abertura da auditoria com o responsável pela área a ser aditada; • Realizar análise crítica da documentação da área auditada durante a auditoria, verificando sua

conformidade com as atividades executadas; • Analisar criticamente, junto ao responsável pela área auditada os resultados da auditoria; • Abrir as ocorrências para emissão dos RNC. • Elaborar e apresentar o relatório de Auditoria Interna do Sistema da Qualidade; • Realizar a reunião de encerramento da auditoria com os responsáveis pelas áreas auditadas;


5.1 Seleção do Auditor • As auditorias são realizadas por Auditores da Qualidade (AQ), qualificados como indicado na

seção 4.2. • As atividades dos AQ são independentes das atividades a serem auditadas.

5.2 Periodicidade da Auditoria • É realizado um ciclo completo de auditorias internas do SGQ a cada três meses. • Auditorias especiais e ou de acompanhamento podem ser realizadas a qualquer tempo.

5.3 Programação das Auditorias • O escopo e a abrangência da auditoria são definidos de forma a atender às necessidades de

avaliação do setor auditado. • A programação e a freqüência da auditoria são definidas considerando a situação e importância da

atividade a ser auditada. Essa situação depende do maior ou menor grau de conformidade dessa atividade, com os requisitos especificados.

• Auditorias de acompanhamento, quando necessário, são programadas para verificar a eficácia de ações corretivas e preventivas requeridas.


5.4 Comunicação da Auditoria O Auditor comunica antecipadamente de forma documentada ao responsável pela área auditada da realização da auditoria.

214


_________________________________________________________________________________________________________________

5.5 Reunião de Abertura O Auditor convoca os responsáveis pelas unidades a serem auditadas, para a reunião de abertura da auditoria, onde são esclarecidos entre outros, detalhes tais como:

• Escopo e objetivos da auditoria; • Plano da auditoria, seqüência e roteiro; • Estabelecimento do canal de comunicação entre a equipe auditora e os auditados; • Horários e duração prevista da auditoria; • Documentação aplicável; • Previsão de encerramento.

5.6 Execução da Auditoria A auditoria é realizada de acordo com o planejamento elaborado, dentro do escopo definido e atendendo os horários e roteiros pré-estabelecidos. Eventuais alterações devem ser negociadas com os responsáveis pelas áreas envolvidas. O processo de auditoria atende as seguintes etapas básicas:

• Análise da documentação e sua adequação. • Verificação dos processos e sua conformidade. • Verificação de registros. • Identificação, análise e registro de evidências objetivas. • Emissão, quando necessário de RNC [2]. • Registros dos resultados. • Elaboração do Relatório de Auditoria [1].

5.7 Evidências Objetivas As evidências objetivas são dados que apóiam a existência ou veracidade de alguma coisa e são coletadas a partir das entrevistas, exames da documentação e observação de atividades e condições nas áreas auditadas.

5.8 Relatório de Auditoria O Relatório de Auditoria [1] tem como objetivo informar os resultados, sendo preparado pelo Auditor que é responsável pela sua exatidão e completeza. Contém:

• Avaliação do auditor sobre os resultados das atividades auditadas e sua adequação e conformidade ao SGQ.

• Avaliação da capacidade da atividade auditada de atender os objetivos da qualidade definidos. • Registros das não-conformidades, observações e evidências objetivas, se requerido.

5.9 Resultado das auditorias • Os resultados das auditorias são levados ao conhecimento dos responsáveis pela administração das

áreas auditadas, através do “Relatório de Auditoria” [1]. • Os Relatórios de Não-conformidade [2], quando houver, são abertos pelo Auditor e encaminhados

ao responsável pela área, para permitir a adoção de ações corretivas para eliminar as não-conformidades detectadas.

• Quando necessário, ações preventivas são definidas. • A eficácia das ações corretivas e preventivas é avaliada pelo Auditor, após sua implementação. • As atividades de auditoria são registradas e informadas à Alta Administração, para efeitos de

Análise Crítica do Sistema da Qualidade. • A reunião de encerramento é realizada para apresentar os resultados finais de auditoria. • As auditorias são consideradas encerradas quando o Auditor elabora e apresenta o Relatório de

Auditoria. <Código> Versão <x.x> Data: 6/1/2006

215

APÊNDICE X Procedimento de Controle de Produto não-conforme

<LOGO>

PROCEDIMENTO DE CONTROLE DE PRODUTO NÃO-CONFORME

VERSÃO < x.x>

<Código>

216

< logo > PROCEDIMENTO DE CONTROLE DE PRODUTO NÃO-CONFORME 216/4

_________________________________________________________________________________________________________________

ÍNDICE

1 INTRODUÇÃO...............................................................................................................................217



4.1 Produto não-conforme ......................................................................................................................... 217 4.2 Atividade de controle de produto não-conforme ................................................................................. 217 4.3 Determinação de Ações para Eliminar a não-conformidade Detectada............................................... 218 4.4 Causa ................................................................................................................................................... 218

5 CONDIÇÕES ESPECÍFICAS........................................................................................................218 5.1 Identificação e Registro ....................................................................................................................... 218


217


_________________________________________________________________________________________________________________


Data Versão Autor Descrição

19/09/2005 V 1.0 Raimundo Sales Estruturação deste procedimento.

1 INTRODUÇÃO

1.1 Objetivo Este procedimento define a metodologia utilizada para realização de Auditorias Internas do SGQ da <empresa> e estabelecer os critérios para qualificação de auditores internos da qualidade

1.2 Glossário

Item Definição

SGQ Sistema de Gerenciamento da Qualidade. Produto Resultado de uma atividade ou processo. Serviço Na abrangência deste procedimento, também é considerado um

produto. Não Conformidade Não atendimento a um requisito especificado.

1.3 Referências [ 1 ] RNC - Relatório de Não Conformidade

2 APLICAÇÃO Este procedimento é o padrão adotado na < empresa > para o controle de não-conformidade.

3 RESPONSABILIDADES A função responsável pelo processo de controle de produto não-conforme é definida pelo Diretor / Gerente da área, aonde foi identificado o produto não-conforme, em função da importância e abrangência da não-conformidade, assim como dos processos envolvidos.


4.1 Produto não-conforme Um produto é considerado não-conforme, quando não atende a um ou mais dos requisitos especificados. Os requisitos especificados podem pertencer ao próprio produto, ao processo ou às atividades correlatas que geram ou têm relação com o mesmo, bem como ao resultado esperado de um serviço.

4.2 Atividade de controle de produto não-conforme O controle de produto não conforme inclui as seguintes atividades, quando aplicáveis:

• Identificar o produto não-conforme (como apropriado).


218


_________________________________________________________________________________________________________________

• Avaliar as características e abrangências da não-conformidade. • Segregar o produto, quando aplicável. • Definir uma ação para disposição do produto não-conforme. • Definir a execução de ações para impedir seu uso pretendido ou aplicação original do produto não-

conforme. • Definir e implementar ações para eliminar a não-conformidade detectada. • Manter os registros requeridos sobre o controle de produto não-conforme, a identificação da

natureza da não-conformidade, a distribuição de produto não-conforme e quaisquer ações subseqüentes executadas, incluindo quando aplicável às concessões obtidas de funções autorizadas ou do cliente.

• Notificar as funções envolvidas do resultado destas atividades.

4.3 Determinação de Ações para Eliminar a não-conformidade Detectada É a definição da ação que vai ser adotada com o produto não-conforme. Essa ação pode-se enquadrar em uma das seguintes opções:

• Liberar ou aceitar para uso autorizada por função competente e ou pelo cliente, como aplicável. • Utilizar para uso alternativo diferente do original. • Determinar sua devolução ao fornecedor. • Determinar sua eliminação ou sucateamento. • Adotar ações para eliminar a não-conformidade detectada tais como:

a) Retrabalhar ou reprocessar. b) Consertar, corrigir, ajustar. c) Substituir, trocar, alterar. d) Outras ações necessárias.

4.4 Causa A causa de uma não-conformidade, é toda prática, ação ou atividade que é identificada como responsável pela ocorrência desta não-conformidade.


5.1 Identificação e Registro • Quando em qualquer etapa de um processo for detectado um produto não-conforme, o mesmo é

identificado. • A identificação deve ser realizada de forma a assegurar que o produto não-conforme não seja

utilizado involuntariamente. Esta identificação deve ser adequada ao tipo de produto não-conforme. • A ocorrência da não-conformidade é registrada de forma documentada. Quando a não-

conformidade for detectada após a entrega ou início de uso, são adotadas medidas adequadas para eliminar seus efeitos ou potenciais efeitos.

• A ocorrência da não-conformidade é registrada de forma documentada emitindo um Relatório de Não Conformidade (RNC) [1], se for decorrente de processos / atividades ou de auditoria.

• Quando o produto não-conforme é corrigido, ele deve ser novamente verificado para demonstrar sua conformidade com os requisitos estabelecidos.

• Quando requerido pelo contrato, o uso ou reparo proposto do produto não-conforme, é relatado de forma documentada ao cliente (ou seu representante) para fins de concessão.

• Este relatório é utilizado como registro da concessão.


219

APÊNDICE XI Procedimento para Ações Corretivas, Preventivas e de

Melhoria

<LOGO>

PROCEDIMENTO PARA AÇÕES CORRETIVAS, PREVENTIVAS E DE MELHORIA

VERSÃO < x.x>

<Código>

220

< logo > PROCEDIMENTO PARA AÇÕES CORRETIVAS, PREVENTIVAS E DE MELHORIA 2/5 _________________________________________________________________________________________________________________

ÍNDICE

1 INTRODUÇÃO...............................................................................................................................221



4.1 Reclamações do cliente ....................................................................................................................... 222 5 CONDIÇÕES ESPECÍFICAS ..........................................................................................................222

5.1 Análise da causa da não-conformidade ............................................................................................... 222 5.2 Definição das ações corretivas ............................................................................................................ 222

5.2.1 Implementação de um plano de ação........................................................................................... 222 5.2.2 Verificação de eficácia ................................................................................................................ 222

5.3 Definição das ações preventivas.......................................................................................................... 222 5.3.1 Implementação de um plano de ação........................................................................................... 222 5.3.2 Verificação de eficácia ................................................................................................................ 223

5.4 Ação de melhoria................................................................................................................................. 223 5.5 Registros.............................................................................................................................................. 223


221




1 INTRODUÇÃO

1.1 Objetivo

Este procedimento tem como objetivo descrever a metodologia da <empresa>, para definição e implementação de ações corretivas e preventivas em qualquer etapa dos processos, produtos ou em atividades relacionadas com os mesmos.

1.2 Glossário

Item Definição SGQ Sistema de Gerenciamento da Qualidade. Não Conformidade Não atendimento a um requisito especificado. Disposição Ação aplicada diretamente sobre um produto não-conforme. Ação Corretiva Ação para eliminar a causa de uma não-conformidade ocorrida e

identificada Ação Preventiva Ação para eliminar a causa de uma não-conformidade ainda não

ocorrida,mas identificada. Ação de Melhoria Ação que caracteriza um aumento na capacidade de atendimento a

requisitos.

1.3 Referências [ 1 ] Procedimento de Controle de Produto Não-Conforme [ 2 ] Acompanhamento de RNC [ 3 ] Relatório de registro de Não-Conformidade (RNC)

2 APLICAÇÃO Este procedimento é o padrão adotado na < empresa > para o controle de não-conformidade.

3 RESPONSABILIDADES A responsabilidade pela definição, aprovação e pelo controle de ações corretivas e preventivas, assim como pela verificação da eficácia das mesmas é do Diretor / Gerente da área identificada como origem da não-conformidade (real ou potencial) ou de função especialmente designada.

4 CONDIÇÕES GERAIS São atividades relacionadas com a definição, aprovação e controle de ações corretivas e preventivas:


• Analisar criticamente as não-conformidades (reais ou potenciais), incluindo o efetivo tratamento das reclamações de clientes (subseção 4.1) e aquelas identificadas em produtos, processos e atividades relacionadas, para identificar a causa e definir as ações (corretivas ou preventivas) apropriadas aos efeitos dessas não-conformidades.

222


• Implementar as ações definidas. • Aplicar controles para assegurar que essas ações estão sendo tomadas e são efetivas. • Analisar criticamente os resultados das ações aplicadas para verificar sua eficácia. • Gerenciar a documentação correspondente e manter registros destas atividades • Notificar as funções envolvidas do resultado destas atividades.

4.1 Reclamações do cliente As reclamações de cliente devem ser avaliadas previamente pelo responsável pela área que deu origem à reclamação, de forma a permitir a caracterização da não conformidade, como indicado no procedimento denominado Controle de Produto Não-Conforme [1]. A partir desta caracterização, o responsável define as ações necessárias. Registrando-as no RNC [3].


5.1 Análise da causa da não-conformidade A partir da caracterização da ocorrência (não-conformidade real ou potencial), quando requerido, é realizada a análise da mesma para identificar a causa considerando as possíveis origens, tais como: materiais, serviços, produtos, equipamentos, mão de obra, informações, e procedimentos.

5.2 Definição das ações corretivas A seguir é realizada a definição das ações a serem adotadas, suas áreas de aplicação, o responsável e o prazo para sua implementação. Quando necessário, podem ser definidos os custos previstos.

5.2.1 Implementação de um plano de ação Um plano de ação pode ser definido, quando necessário, para implementação das ações corretivas. Este plano pode envolver diversas atividades e sua implementação está condicionada ao tipo e quantidade de ações corretivas definidas. As responsabilidades pela implementação, acompanhamento e verificação da eficácia são estabelecidas a partir das situações e de seus passos abaixo. Essas ações são cadastradas pelo Gerente de projetos para os responsáveis e analisadas criticamente após sua solução. Um roteiro a ser seguido poderia ser:

1. Identificar a causa da não-conformidade; 2. Estabelecer claramente a proposta, descrevendo as ações a serem implementadas, os resultados

esperados e determinando os responsáveis envolvidos; 3. Depois de implementada, é requerida a verificação da eficácia da ação de forma a comprovar o

resultado esperado e identificar possíveis desvios passíveis de correção.

5.2.2 Verificação de eficácia O responsável pela verificação da eficácia, analisa o resultado das ações e, se a não-conformidade e suas causas foram efetivamente eliminadas, procede-se ao encerramento da ocorrência registrando as observações que se fizerem necessárias. Caso a eficácia não for comprovada, o plano é revisto a partir das observações realizadas e as mudanças requeridas são implementadas. O ciclo se repete tantas vezes quanto for necessário, até a efetiva eliminação da não-conformidade e suas causas.

5.3 Definição das ações preventivas As ações preventivas visam eliminar as causas de não-conformidade potencial, ou seja, aquela não-conformidade que não aconteceu mas foi identificada.

5.3.1 Implementação de um plano de ação Um plano de ação pode ser definido, quando necessário, para implementação das ações preventivas. Este plano pode envolver diversas atividades e sua implementação estar condicionada ao tipo e à quantidade de ações preventivas definidas. As responsabilidades por implementação, acompanhamento e verificação da


223


eficácia são estabelecidas a partir das situações e de seus passos abaixo. Essas ações são cadastradas pelo Gerente de projetos aos responsáveis e analisadas criticamente após sua solução. Um roteiro a ser seguido poderia ser:

1. Identificar as não-conformidades potenciais. Para tanto podem ser verificadas as tendências de indicadores, reuniões de lições aprendidas ou outras evidências em reuniões periódicas com a equipe, ou a qualquer momento;

2. Identificar as possíveis causas das não-conformidades potenciais; 3. Estabelecer ações a ser implementadas, os resultados esperados e os responsáveis envolvidos; 4. Verificar a eficácia de forma a comprovar os resultados esperados e identificar outras não-

conformidades potenciais.

5.3.2 Verificação de eficácia O responsável pela verificação da eficácia, analisa o resultado das ações e se os resultados esperados foram efetivamente alcançados. Procede-se ao encerramento da ocorrência registrando as observações que se fizerem necessárias. Caso a eficácia não for comprovada, o plano é revisto a partir das observações realizadas e as mudanças requeridas são implementadas. O ciclo pode ser repetido tantas vezes quanto for necessário.

5.4 Ação de melhoria Uma ação de melhoria fica caracterizada, quando sua implementação traz como resultado um aumento na capacidade de atendimento de requisitos de um produto ou processo. Essa ação de melhoria não requer a identificação de uma situação de não-conformidade, seja ela real ou potencial. As responsabilidades por implementação, acompanhamento e verificação da eficácia são estabelecidas a partir das situações e de seus passos abaixo.

1. Identificação da oportunidade de melhoria; 2. Estabelecer claramente a proposta de melhoria, descrevendo as ações a serem implementadas, os

resultados esperados e determinando os responsáveis envolvidos; 3. Depois de implementada, é requerida a verificação da eficácia da ação de forma a comprovar a

melhoria esperada e identificar possíveis desvios passíveis de correção.

5.5 Registros Os registros destas atividades são mantidos pelo procedimento [1] e pelo acompanhamento de RNC [2].


224

APÊNDICE XII Procedimento de Desenvolvimento de Sistemas

<LOGO>

PROCEDIMENTO DE DESENVOLVIMENTO DE SISTEMAS

VERSÃO < x.x>

<Código>

225

< logo > PROCEDIMENTO DE DESENVOLVIMENTO DE SISTEMAS 2/6

_________________________________________________________________________________________________________________

ÍNDICE

1 INTRODUÇÃO...............................................................................................................................226


2 APLICAÇÃO..................................................................................................................................226 3 RESPONSABILIDADES.................................................................................................................226 4 CONDIÇÕES GERAIS....................................................................................................................226 5 CONDIÇÕES ESPECÍFICAS ..........................................................................................................227

5.1 Projeto e Desenvolvimento.................................................................................................................. 227 5.1.1 Entradas de Projeto e Desenvolvimento ...................................................................................... 227 5.1.2 Saídas de Projeto e Desenvolvimento.......................................................................................... 227 5.1.3 Verificação de Projeto e Desenvolvimento.................................................................................. 227 5.1.4 Validação de Projeto e Desenvolvimento .................................................................................... 227 5.1.5 Alterações de Projeto e Desenvolvimento ................................................................................... 227 5.1.6 Registros ...................................................................................................................................... 227

5.2 Análise de Propostas e Contratos ........................................................................................................ 227 5.2.1 Identificação e Definição de Requisitos Relacionados ao Produto.............................................. 228 5.2.2 Análise Crítica dos Requisitos Relacionados ao Produto ............................................................ 228 5.2.3 Registros ...................................................................................................................................... 228

5.3 Identificação, Rastreabilidade e Preservação de Produtos................................................................... 228 5.3.1 Produtos entregues ao cliente ...................................................................................................... 228 5.3.2 Produtos de propriedade do cliente.............................................................................................. 229 5.3.3 Registros ...................................................................................................................................... 229


226


_________________________________________________________________________________________________________________



1 INTRODUÇÃO

1.1 Objetivo

Este procedimento tem como objetivo descrever a metodologia da <empresa> para definição e implementação de ações corretivas e preventivas em qualquer etapa dos processos, produtos ou em atividades relacionadas com os mesmos.

1.2 Glossário Item Definição

SGQ Sistema de Gerenciamento da Qualidade.

1.3 Referências [ 1 ] Metodologia de Desenvolvimento de Software (se houver) [ 2 ] Controle de Registros do Sistema de Qualidade. [ 3 ] Tutorial da Ferramenta de Controle de Versões. [ 4 ] Procedimento de Segurança

2 APLICAÇÃO Este procedimento é o padrão adotado na < empresa > para o desenvolvimento de seus produtos de software.

3 RESPONSABILIDADES A responsabilidade pela realização do controle do processo de desenvolvimento de sistemas, controle dos produtos é da Diretoria, do Gerente de projeto ou de função designada para este fim.

4 CONDIÇÕES GERAIS O processo de projeto e desenvolvimento de sistemas é realizado de forma planejada a fim de poder determinar os passos necessários e a seqüência operacional requerida para cada etapa ou estágio. A comunicação com o cliente, e realizada de duas formas básicas:

1. Através de reuniões para avaliação e levantamento de informações relativas ao produto, antes de iniciar o efetivo desenvolvimento.

2. Mediante reuniões continuadas de avaliação e análise do produto onde são consideradas questões relativas a: • Consultas, contratos, pedidos, reclamações, alterações ou emendas aos requisitos contratados; • Reclamações, questionamentos, sugestões ou ajustes devidamente registros.


227


_________________________________________________________________________________________________________________ A análise crítica, verificação e validação das diferentes etapas ou estágios são realizadas, levando em consideração as características particulares de cada projeto e são estabelecidas durante o planejamento ou ao longo do processo de desenvolvimento, como aplicável. As responsabilidades e autoridades requeridas para o desenvolvimento de um produto são definidas no planejamento e, se requerido, podem ser alteradas em etapas posteriores, se assim for necessário. As interfaces entre diferentes grupos envolvidos no processo são definidas durante o planejamento, assim como as responsabilidades entre grupos para assegurar uma comunicação eficaz.


5.1 Projeto e Desenvolvimento O processo de desenvolvimento da < empresa > é realizado de acordo:

• [Indicar as atividades do processo • Referenciar o documento da Metodologia utilizada [1], quando for caso.]

5.1.1 Entradas de Projeto e Desenvolvimento As entradas são estabelecidas a partir da definição dos seguintes requisitos: a) Requisitos operacionais, de funcionamento e desempenho. b) Requisitos estatutários e regulamentares aplicáveis. c) Requisitos de informações referentes a projetos anteriores semelhantes, quando aplicável. d) Informações ou requisitos essenciais ao projeto de desenvolvimento, não declaradas, porém necessários.

5.1.2 Saídas de Projeto e Desenvolvimento Nas etapas definidas no planejamento são realizadas análises críticas do projeto, como forma de avaliar se: a) Os resultados do projeto atendem os requisitos especificados para o mesmo. b) Identificar a existência de problemas e propor ações corretivas requeridas.

5.1.3 Verificação de Projeto e Desenvolvimento A verificação é realizada nas etapas do projeto definidas no planejamento, as quais estão relacionadas com o tipo de projeto e suas características específicas, de forma a assegurar que as saídas do projeto atendam os requisitos de entrada.

5.1.4 Validação de Projeto e Desenvolvimento A validação é realizada em fases ou etapas definidas previamente durante o planejamento, para assegurar que o produto resultante atenda aos requisitos para aplicação especificada ou uso intencional. A validação pode ser realizada antes ou durante a entrega ou a implementação do produto dependendo das características operacionais do mesmo.

5.1.5 Alterações de Projeto e Desenvolvimento As alterações realizadas são identificadas, analisadas criticamente, verificadas, validadas e aprovadas antes de sua implementação, para avaliar seus efeitos em partes componentes do produto em desenvolvimento ou já entregue ao cliente.

5.1.6 Registros Registros destas atividades são mantidos como descrito no procedimento Controle de Registros do Sistema da Qualidade [2].

5.2 Análise de Propostas e Contratos A análise de propostas e contratos determina se os requisitos relacionados ao produto estão definidos e entendidos, como forma de assegurar que a < empresa > tenha condições de atendê-los e satisfazer desta forma o cliente.


228


_________________________________________________________________________________________________________________

• As propostas e/ou contratos referem-se ao Desenvolvimento, à Implantação, à Comercialização, à Transferência de Tecnologia e ao Suporte de Sistemas Informatizados.

• A análise crítica de propostas e/ou contratos é realizada para assegurar que os requisitos do cliente e do produto podem ser atendidos. Essa análise é realizada antes de estabelecer qualquer compromisso com o cliente.

• Quando houver alterações posteriores à aprovação de uma proposta e/ou contrato, as mesmas serão analisadas criticamente e aprovadas antes de sua implementação.

5.2.1 Identificação e Definição de Requisitos Relacionados ao Produto Antes de emitir uma proposta ou elaborar um contrato devem ser claramente identificados e definidos os requisitos relacionados ao produto de forma a permitir que os mesmos sejam entendidos e estabelecidos antes de sua aceitação. Devem ser identificados e definidos:

• Os requisitos especificados pelo cliente, incluindo aqueles referentes ao processo de entrega (implementação) e pós-entrega (suporte) ;

• Requisitos não declarados pelo cliente, mas que serão necessários para utilização do produto (hardware, treinamento, infra-estrutura e outros);

• Requisitos estatutários e regulamentares relacionados ao produto; • Outros requisitos adicionais determinados pelo cliente ou pela < empresa > que possam influir no

produto, em sua utilização ou no suporte.

5.2.2 Análise Crítica dos Requisitos Relacionados ao Produto As propostas e/ou contratos são analisadas criticamente antes de sua emissão e/ou aprovação para assegurar que os requisitos especificados podem ser atendidos. A análise crítica deve assegurar que:

• Os requisitos de produto (e, quando aplicável, os requisitos de suporte) estão definidos. • Os requisitos da proposta e/ou contrato diferentes daqueles manifestados originalmente estão

entendidos e resolvidos. • A < empresa > tem capacidade de atender os requisitos definidos.

5.2.3 Registros Os registros das atividades devem ser mantidos. Como evidência da análise crítica deve ser no próprio documento a citação: “Analisado Criticamente e Aprovado”, onde constam o nome (ou assinatura) do responsável pela aprovação, sua função, e a data na qual foi realizada a análise.

5.3 Identificação, Rastreabilidade e Preservação de Produtos

5.3.1 Produtos entregues ao cliente A identificação e a rastreabilidade de produtos entregues ao cliente devem ser realizadas preferencialmente através de um Sistema de Controle de Versão [3], garantindo-se que os registros permaneçam armazenados em meio eletrônico. Sejam as seguintes atividades de controle:

• O sistema de controle de versão mantém registros das alterações realizadas nos produtos, disponibilizando para uso a mais atualizada delas. O cliente sempre recebe a versão mais atualizada, e a mesma é substituída, quando requerido, após alterações e/ou adequações.

• Os produtos da < empresa > podem ser comercializados para diferentes clientes e são identificados a partir de um nome específico a cada produto / serviço que facilite sua compreensão. Suas eventuais versões são administradas pelo Sistema de Controle de Versões.

• Quando o cliente estiver utilizando uma versão anterior (não atualizada) do produto, e solicitar serviços de suporte, a nova versão é instalada exceto disposição em contrário.


229


_________________________________________________________________________________________________________________

• O armazenamento dos produtos intermediários (durante o desenvolvimento) ou finais (produto acabado) é realizado em meio eletrônico.

• Os produtos intermediários / finais são disponibilizados em ambiente digital e enviados via meio eletrônico ao cliente.

• A proteção dos produtos é realizada mediante a utilização de antivírus apropriados e backup dos arquivos, descrito no Procedimento Segurança [4].

5.3.2 Produtos de propriedade do cliente A < empresa > terá os cuidados necessários para proteger os produtos de propriedade do cliente, quando estiverem sob sua responsabilidade.

• Os cuidados para a proteção dos produtos de propriedade do cliente incluem atividades para:

A) Identificação: quando o produto de propriedade do cliente é recebido pela < empresa > para uso ou incorporação ao produto, este é identificado antes de sua liberação. Esta identificação varia em função do tipo, tamanho e forma do produto, podendo utilizar para isto: - Manuais, - Logotipos, - Componentes de software, etc.

B) Verificação: antes de sua liberação para uso, os produtos de propriedade do cliente são verificados de forma a comprovar sua integridade e adequação.

C) Proteção: os produtos fornecidos pelo cliente para utilização e ou aplicação no produto final são protegidos de forma a evitar danos ou inadequações para seu uso. Esta proteção depende do tipo, tamanho e forma do produto e é definida para cada caso em particular. Entre outras, podem ser consideradas as seguintes formas de proteção: - Backup ou copia de mídia. - Fotocópia de documentação. - Copia de segurança.

D) Salvaguarda: quando o produto fornecido pelo cliente incluir dados e ou informações confidenciais, são adotadas salvaguardas para evitar sua divulgação ou conhecimento por pessoas não autorizadas. Essa salvaguarda pode ou não incluir um contrato ou acordo documentado de confidencialidade, conforme requisitado pelo cliente.

E) Extravio, dano ou inadequação: quando a propriedade do cliente for perdida ou sofrer inadequação para uso o mesmo é informado de forma documentada descrevendo o acontecimento. Quando necessário, cópias ou substitutos dos produtos são solicitados, como aplicável. São mantidos registros desta comunicação, a qual pode ser realizada de diversas formas, como e-mail, ofício, correspondência. Cópia desta comunicação deve ser preservada conforme controle de registros.

F) Propriedade intelectual e/ou conhecimento: quando o produto fornecido pelo cliente incluir propriedade intelectual e ou conhecimento, sua preservação e salvaguarda é garantida. Sua utilização indevida ou comunicação para funções não autorizadas é vedada, assim como sua divulgação ou uso sem referências à propriedade.

5.3.3 Registros São mantidos registros da relação de versões e clientes em meio eletrônico para efeito de identificação, rastreabilidade e preservação do produto.


Livros Grátis( http://www.livrosgratis.com.br )

Milhares de Livros para Download: Baixar livros de AdministraçãoBaixar livros de AgronomiaBaixar livros de ArquiteturaBaixar livros de ArtesBaixar livros de AstronomiaBaixar livros de Biologia GeralBaixar livros de Ciência da ComputaçãoBaixar livros de Ciência da InformaçãoBaixar livros de Ciência PolíticaBaixar livros de Ciências da SaúdeBaixar livros de ComunicaçãoBaixar livros do Conselho Nacional de Educação - CNEBaixar livros de Defesa civilBaixar livros de DireitoBaixar livros de Direitos humanosBaixar livros de EconomiaBaixar livros de Economia DomésticaBaixar livros de EducaçãoBaixar livros de Educação - TrânsitoBaixar livros de Educação FísicaBaixar livros de Engenharia AeroespacialBaixar livros de FarmáciaBaixar livros de FilosofiaBaixar livros de FísicaBaixar livros de GeociênciasBaixar livros de GeografiaBaixar livros de HistóriaBaixar livros de Línguas










http://www.livrosgratis.com.br/cat_1/administracao/1







http://www.livrosgratis.com.br/cat_2/agronomia/1







http://www.livrosgratis.com.br/cat_3/arquitetura/1







http://www.livrosgratis.com.br/cat_4/artes/1







http://www.livrosgratis.com.br/cat_5/astronomia/1







http://www.livrosgratis.com.br/cat_6/biologia_geral/1









http://www.livrosgratis.com.br/cat_8/ciencia_da_computacao/1











http://www.livrosgratis.com.br/cat_9/ciencia_da_informacao/1











http://www.livrosgratis.com.br/cat_7/ciencia_politica/1









http://www.livrosgratis.com.br/cat_10/ciencias_da_saude/1











http://www.livrosgratis.com.br/cat_11/comunicacao/1







http://www.livrosgratis.com.br/cat_12/conselho_nacional_de_educacao_-_cne/1















http://www.livrosgratis.com.br/cat_13/defesa_civil/1









http://www.livrosgratis.com.br/cat_14/direito/1







http://www.livrosgratis.com.br/cat_15/direitos_humanos/1









http://www.livrosgratis.com.br/cat_16/economia/1







http://www.livrosgratis.com.br/cat_17/economia_domestica/1









http://www.livrosgratis.com.br/cat_18/educacao/1







http://www.livrosgratis.com.br/cat_19/educacao_-_transito/1









http://www.livrosgratis.com.br/cat_20/educacao_fisica/1









http://www.livrosgratis.com.br/cat_21/engenharia_aeroespacial/1









http://www.livrosgratis.com.br/cat_22/farmacia/1







http://www.livrosgratis.com.br/cat_23/filosofia/1







http://www.livrosgratis.com.br/cat_24/fisica/1







http://www.livrosgratis.com.br/cat_25/geociencias/1







http://www.livrosgratis.com.br/cat_26/geografia/1







http://www.livrosgratis.com.br/cat_27/historia/1







http://www.livrosgratis.com.br/cat_31/linguas/1







Baixar livros de LiteraturaBaixar livros de Literatura de CordelBaixar livros de Literatura InfantilBaixar livros de MatemáticaBaixar livros de MedicinaBaixar livros de Medicina VeterináriaBaixar livros de Meio AmbienteBaixar livros de MeteorologiaBaixar Monografias e TCCBaixar livros MultidisciplinarBaixar livros de MúsicaBaixar livros de PsicologiaBaixar livros de QuímicaBaixar livros de Saúde ColetivaBaixar livros de Serviço SocialBaixar livros de SociologiaBaixar livros de TeologiaBaixar livros de TrabalhoBaixar livros de Turismo

http://www.livrosgratis.com.br/cat_28/literatura/1







http://www.livrosgratis.com.br/cat_30/literatura_de_cordel/1











http://www.livrosgratis.com.br/cat_29/literatura_infantil/1









http://www.livrosgratis.com.br/cat_32/matematica/1







http://www.livrosgratis.com.br/cat_33/medicina/1







http://www.livrosgratis.com.br/cat_34/medicina_veterinaria/1









http://www.livrosgratis.com.br/cat_35/meio_ambiente/1









http://www.livrosgratis.com.br/cat_36/meteorologia/1







http://www.livrosgratis.com.br/cat_45/monografias_e_tcc/1







http://www.livrosgratis.com.br/cat_37/multidisciplinar/1





http://www.livrosgratis.com.br/cat_38/musica/1







http://www.livrosgratis.com.br/cat_39/psicologia/1







http://www.livrosgratis.com.br/cat_40/quimica/1







http://www.livrosgratis.com.br/cat_41/saude_coletiva/1









http://www.livrosgratis.com.br/cat_42/servico_social/1









http://www.livrosgratis.com.br/cat_43/sociologia/1







http://www.livrosgratis.com.br/cat_44/teologia/1







http://www.livrosgratis.com.br/cat_46/trabalho/1







http://www.livrosgratis.com.br/cat_47/turismo/1







Documents

FUNDAÇÃO EDSON QUEIROZ UNIVERSIDADE DE FORTALEZA – …livros01.livrosgratis.com.br/cp005220.pdf · Figura 3.6: Visão do Software no sistema (NBR ISO/IEC 15271, 2000) 59 Figura