1.

Introduo
Desde o incio da engenharia de software nos anos 60, existe uma grande preocupao em se criar softwares de boa qualidade. Durante quase 30 anos foram desenvolvidas prticas e mtodos de desenvolvimento de software que resultavam em produtos de boa qualidade. No incio dos anos 90, normas de anlise da qualidade dos sistemas comearam a ser estudadas mais profundamente e documentadas pelos rgos responsveis por criar e documentar padres e normas como a IEEE, ISO, ANSI e, no Brasil, a ABNT. Estas empresas comearam, ento, a publicar as normas de avaliao de qualidade de software que so utilizadas at hoje e so os documentos-base para a certificao das empresas desenvolvedoras de software. No contexto da qualidade de software, o conceito de qualidade parte dos princpios de que o software deve atender aos requisitos especificados e que este deve atender s necessidades dos usurios. Diante destes princpios, foram enunciadas algumas definies que juntas compem o conceito de qualidade de software. So elas : Software com pouco ou nenhum defeito; Software adequado ao uso; Software que atende s especificaes; Software produzido por uma empresa que possui certificado de qualidade; Software que possui confiabilidade, usabilidade e manutenibilidade. inegvel que software um dos componentes de maior importncia em qualquer atividade do negcio, uma vez que o tratamento da informao, de forma precisa e correta, diferenciar uma empresa de suas concorrentes. O software de computador uma dentre poucas tecnologias-chave que causaram impacto sobre quase todos os aspectos da sociedade. Ele um mecanismo para automatizar negcios, a indstria e o governo, um meio de transferir novas tecnologias, um modo de captar valiosa experincia para ser usada por outros, uma janela para o conhecimento corporativo coletivo.

O software fundamental em quase todos os aspectos dos negcios. Encontramos o software (freqentemente sem nos darmos conta dele) quando nos dirigimos ao trabalho, fazemos qualquer compra no varejo, paramos no banco, fazemos uma chamada telefnica, visitamos o mdico ou realizamos qualquer uma das centenas de atividades do dia-a-dia que refletem a vida moderna. O mercado global para software chegou a um e meio trilho de dlares, quando considerados softwares embutidos (em equipamentos) e desenvolvimento realizado por empresas de software. A pequena empresa desenvolvedora de software brasileiro, sobrevive apenas com contratos locais de pouca exigncia de produtividade e qualidade. Por isso, so poucos no Brasil, os negcios de software que tm condies de exportar. Apenas os que atendem os requisitos de qualidade o fazem. Para a melhora do desenvolvimento de software brasileiro, foi criado o conceito de fbrica de software. Oliveira e Neto (2003) definem que fbrica de software utiliza a metodologia de criao de software atravs da aproximao da abordagem da criao de produtos na gesto da manufatura. Sua principal caracterstica o reaproveitamento de cdigo de programas j desenvolvidos. Porm, no quesito qualidade aliada produtividade, seu conceito baixo. As fbricas de software vivem de projetos experimentais, baseados em propostas open-source (cdigo-livre), no aplicados comercialmente quase em sua totalidade.

2. Qualidade
Qualidade definida pela norma NBR ISO 8402, como a totalidade das caractersticas de uma entidade que lhe confere a capacidade de satisfazer s necessidades explcitas e implcitas. Entidade o produto propriamente dito, as necessidades explcitas so as prprias condies e objetivos propostos pelo produtor e as necessidades implcitas so condies, mais subjetivas, como as diferenas entre as necessidades dos usurios, a evoluo no tempo, as implicaes ticas, as questes de segurana e outras.

A qualidade de software, conformidade a requisitos funcionais e de desempenho explicitamente declarados, a padres de desenvolvimento claramente documentados e a caractersticas implcitas que so esperadas de todo software profissionalmente desenvolvido. Esta definio enfatiza, trs pontos chave: os requisitos de software, padres especificados e um conjunto de requisitos implcitos. Os requisitos de software so a base a partir da qual a qualidade medida. A falta de conformidade aos requisitos significa falta de qualidade. Padres especificados definem um conjunto de critrios de desenvolvimento que orientam a maneira segundo a qual o software passa pelo trabalho de engenharia. Se os critrios no forem seguidos, o resultado quase que seguramente ser a falta de qualidade. Os requisitos implcitos que freqentemente no so mencionados (por exemplo, o desejo de uma boa manutenibilidade) so tambm importantes. Se o software se adequar aos seus requisitos explcitos, e deixar de cumprir seus requisitos implcitos, a qualidade de software ser suspeita. A qualidade de software uma combinao complexa de fatores que variam de acordo com diferentes aplicaes e clientes que as solicitam. Os fatores que afetam a qualidade de software podem ser categorizados em dois grupos distintos. (i) fatores que podem ser medidos diretamente (por exemplo, erros por unidades de tempo etc) e (ii) fatores que podem ser medidos apenas indiretamente (por exemplo, usabilidade ou manutenibilidade).

3. Normas de Qualidade
A ISO (Organizao Internacional de Padres) publicou uma norma que representa a atual padronizao mundial para a qualidade de produtos de software. Esta norma chama-se ISO/IEC 9126 e foi publicada em 1991. Ela uma das mais antigas da rea de qualidade de software e possui traduo para o Brasil, publicada em agosto de 1996 como NBR 13596. Apesar da sua criao, poucos utilizam normas de qualidade de software no Brasil (DIAS, 2004).

A Norma ISO 9126 define a Qualidade de Software como: A totalidade de caractersticas de um produto de software que lhe confere a capacidade de satisfazer necessidades explcitas e implcitas. Ao se fazer a escolha pela Norma ISO/IEC 9126 como referncia para levantamento dos aspectos de qualidade, buscou-se uma profunda anlise abrangendo toda a qualidade do produto e das aplicaes de software. O modelo de qualidade, definido na ISO/IEC 9126-1 utilizado como referncia para o processo de avaliao da qualidade de produtos de software est subdividido em duas partes: modelo de qualidade para as caractersticas externas e internas e modelo de qualidade para qualidade em uso. A norma NBR ISO/IEC 12119 estabelece requisitos de qualidade de um software tipo pacote e fornece instrues para testar esse software em relao aos requisitos definidos. Seu escopo refere-se ao pacote de software, na forma oferecida no mercado, e no aos processos de desenvolvimento e fornecimento de software. Essa norma baseia-se na norma original ISO/IEC 9126. Ambas as normas possuem muitos requisitos em comum mas, para a anlise dos requisitos de qualidade dos sistemas integrados de gesto, a norma ISO 9126 produtos mas a anlise tcnica sob a perspectiva do negcio. O processo de avaliao dos produtos de software est definido na srie de normas ISO/IEC 14598, que deve ser utilizada em conjunto com a srie ISO/IEC 9126. 4. ISO/IEC 9126 (NBR 13596) A norma ISO/IEC 9126 (NBR 13596) lista o conjunto de caractersticas que devem ser verificadas em um software para que ele seja considerado um software de qualidade. Esta norma abrange seis grandes grupos de caractersticas Funcionalidade foi considerada mais adequada por permitir no somente a anlise tcnica pura dos

 Desempenho Usabilidade Manutenibilidade Confiabilidade Portabilidade A anlise de qualidade utilizada neste trabalho foi baseada nas mtricas da NBR ISO/IEC 9126 sendo descritas cada uma das caractersticas e como elas foram aplicadas na avaliao de qualidade dos Sistemas Integrados de Gesto. importante ressaltar que o emprego dos requisitos descritos na NBR ISO/IEC 9126 para a anlise em questo foi preparado com o objetivo de identificar os requisitos de qualidade que geraram resultados positivos para a organizao e no medir o grau de satisfao dos usurios uma vez que estes dois aspectos podem estar interrelacionados ou no. 4.1. Funcionalidade De acordo com a norma NBR ISO/IEC 9126 , a funcionalidade de um software a medida da capacidade das funes de um software de satisfazer as necessidades designadas em seu projeto. A funcionalidade de um software dividida em 5 subcaractersticas: Adequao; Acurcia; Interoperabilidade; Segurana de acesso; Conformidade. De acordo com a NBR ISO/IEC 9126, a adequao de um software a presena de um conjunto de funes e sua apropriao para as tarefas. A pergunta-chave de avaliao descrita pela NBR ISO/IEC 9126 para este requisito : O sistema se prope a fazer o que apropriado?. Apesar de cada empresa possuir processos internos prprios para a administrao do negcio, as

empresas fabricantes de ERPs desenvolvem seus pacotes de software baseadas nos processos de negcio considerados melhores pelo mercado e por suas experincias na rea. Isso faz com que o mercado possua pacotes que atendem aos mais diferentes tipos de empresa. Porm todos devem possuir funcionalidades apropriadas para otimizar as tarefas dirias requeridas pelo negcio, permitindo diminuio no tempo e eficcia na execuo dessas tarefas. Segundo a norma, a acurcia a gerao de resultados ou efeitos corretos pelo sistema. Isto inclui todas as informaes de sada obtidas a partir do processamento das informaes inseridas no sistema. A pergunta-chave de avaliao descrita pela NBR ISO/IEC 9126 [3] para este requisito : O sistema faz o que se prope de maneira correta?. Em sistemas integrados de gesto, a acurcia est ligada diretamente gerao de relatrios pertinentes gerados a partir do interrelacionamento e transformao dos dados armazenados em bancos de dados em informaes que auxiliam os diversos nveis de uma empresa na tomada de decises. Muitos destes relatrios so gerados a partir de ferramentas de Business Inteligence que segundo o Institucional Business Intelligence descreve as habilidades das corporaes para acessar dados e explorar as informaes (normalmente contidas em um DataWarehouse/DataMart), analisando-as e desenvolvendo percepes e entendimentos a seu respeito, o que as permite incrementar e tornar mais pautada a tomada de deciso. A capacidade de gerao de informaes confiveis um fator de essencial importncia em um sistema integrado de gesto e est intimamente ligado ao processo de tomada de decises. Segundo a norma, interoperabilidade a capacidade de interagir e interoperar com outros sistemas de acordo com o especificado. A pergunta-chave de avaliao descrita pela NBR ISO/IEC 9126 para este requisito : O software passvel de compor uma interface com outro sistema?. Um sistema integrado de gesto deve suportar interao com outros sistemas, de forma que se tenha a possibilidade de importar dados de outro sistemas, exportar consultas e relatrios para formatos convenientes e at mesmo

a capacidade de mudana de um sistema integrado para outro, permitindo a migrao dos dados e a minimizao dos impactos de transio. Uma questo importante o esforo necessrio para acoplar um sistema a outro. No estudo de caso realizado neste trabalho, as perguntas-chave utilizadas para medir a capacidade de interoperabilidade dos ERPs avaliados foi: O sistema interage de forma satisfatria com outros sistemas? De acordo com a norma, a segurana dos dados a capacidade de evitar acesso no autorizado a programas e dados. A segurana dos dados um aspecto bastante delicado em qualquer sistema, pois existem informaes da empresa que no podem estar disponveis para todos os usurios. Em um sistema integrado de gesto, esse aspecto ainda mais importante, pois existem informaes de toda a empresa circulando entre os diversos mdulos existentes, sendo assim necessrio que os ERPs possuam a capacidade de limitar as aes dos usurios impedindo que dados sigilosos sejam visualizados por pessoas no autorizadas. Nesses sistemas, o gerente delimita as aes dos usurios, emitindo que estes s acessem as funcionalidades referentes s suas atividades. Os ERPs devem ter a instrumentao como um fator de qualidade, que so atributos de software. que permitem a mensurao de uso, assim como auditoria de acessos, que tambm so atributos de software que fornecem uma auditoria dos acessos ao software e aos dados. A pergunta-chave de avaliao descrita pela NBR ISO/IEC 9126 [3] para este requisito : Evita acesso no autorizado aos dados?. No estudo de caso realizado neste trabalho, as perguntas-chave utilizadas para medir o grau da segurana de acesso aos dados dos ERPs avaliados foram: O sistema possui boa flexibilidade para criao de tipos de usurios com acessos bem distribudos s suas informaes? e O sistema capaz de proteger as informaes adequadamente com ferramentas tipo criptografia e outras?. De acordo com a NBR ISO/IEC 9126 [3], a conformidade a consonncia do software com normas, convenes e regulamentaes. Este requisito tem o objetivo de garantir que o software est de acordo com os padres de representao e com o processamento de informaes, utilizadas mundialmente.

A pergunta-chave de avaliao descrita pela NBR ISO/IEC 9126 [3] para este requisito : Est de acordo com as normas, leis, etc?. Por serem sistemas de integrao de organizaes, os ERPs so desenvolvidos de forma a suportar todas as normas, convenes e regulamentaes de todas as regies do mundo. Isto inclui formatos, medidas, tamanhos e seus relacionamentos. No estudo de caso realizado neste trabalho, as perguntas-chave utilizadas para medir o grau de aceitao da adequao dos ERPs avaliados foram:O ERP suporta os processos de negcio do seu departamento ou da sua empresa com eficcia? e O ERP d sua suporte a todos os processos oferecidos pelo fornecedor?. 4.2. Desempenho A NBR ISO/IEC 9126 [3] define o desempenho ou performance de um sistema como a medida do tempo de resposta e do uso eficiente dos recursos do sistema. Por esta definio, possvel ento identificar dois critrios de avaliao: Tempo de resposta ; Utilizao dos recursos do sistema. O tempo de resposta definido como o tempo decorrido entre a solicitao de uma operao no sistema e a apresentao completa deste resultado para o usurio. Este critrio de avaliao extremamente varivel, pois est diretamente relacionado com o ambiente computacional no qual o sistema ser executado. Esse ambiente compreende os servidores e/ou estaes em que estes sistemas sero instalados, o ambiente de rede e os softwares bsicos utilizados. A pergunta-chave de avaliao descrita na NBR ISO/IEC 9126 [3] para este requisito : Qual o tempo de resposta, velocidade de execuo?. Por serem sistemas integrados, os ERPs possuem uma base de dados nica que deve atender a todos os usurios. Alm disso, pelo seu prprio conceito, o sistema deve ser utilizado por todo ou quase todo o quadro funcional da organizao. Isto faz com que, no caso dos ERPs, o tempo de resposta seja um requisito ainda mais varivel. Cabe equipe de trabalho definir um tempo de resposta aceitvel para a organizao de acordo com seu tamanho e necessidades e projetar o ambiente que ir hospedar o sistema de gesto de forma a cumprir este plano. Tempos de

resposta muito grandes tendem a criar insatisfao nos usurios e desmotivar os usurios a utilizar o sistema. Por isso, o tempo de resposta dos sistemas deve ser monitorado periodicamente para que a equipe tcnica possa trabalhar para mantlo em um nvel aceitvel para os usurios. No estudo de caso realizado neste trabalho, a pergunta-chave utilizada para medir o grau de aceitao do tempo de resposta dos ERPs avaliados foi: O tempo de resposta do sistema aceitvel?. O nvel de utilizao dos recursos do sistema medido atravs do impacto resultante do tempo de processamento e quantidade de memria, utilizados durante a execuo de um sistema. Este impacto percebido pelo usurio, principalmente quando este possui outros programas sendo executadas simultaneamente com o sistema em questo. Este requisito tambm um requisito varivel, porm menos varivel que o tempo de resposta. O nvel de utilizao dos recursos do sistema pode variar de acordo com o tipo de transao efetuada no sistema, mas transaes iguais utilizam sempre recursos equivalentes. A pergunta-chave de avaliao descrita na NBR ISO/IEC 9126 [3] para este requisito : Quanto recurso o sistema utiliza? Durante quanto tempo?. No caso dos sistemas integrados de gesto, grande parte das informaes deve ser inserida no sistema em tempo real o que faz com que, na prtica, a maioria dos usurios do sistema abram o sistema ao chegarem na empresa e permaneam com este em execuo at o fim do expediente. Os sistemas integrados de gesto so desenvolvidos utilizando a arquitetura cliente / servidor e o nvel de utilizao dos recursos do sistema ser avaliado nas mquinas cliente e no nas mquinas servidoras. Um bom nvel de utilizao dos recursos do sistema pelos ERPs imprescindvel para que o impacto nos computadores dos usurios garanta o bom andamento da rotina de trabalho dos seus usurios. No estudo de caso realizado neste trabalho, a pergunta-chave utilizada para medir o grau de aceitao do tempo de resposta dos ERPs avaliados foi: O sistema funciona bem simultaneamente com outros sistemas?.

4.3. Usabilidade A interface um dos elementos importantes na aceitao de um software. A interface a poro visvel do software com o qual ele interage. uso coerente que, a qualidade de um software est intimamente relacionada com o grau de satisfao do usurio com o sistema. O usurio , portanto, o principal avaliador de um sistema e, sua satisfao, um elemento que caracteriza a qualidade de um software. No contexto da criao de software a usabilidade representa um enfoque que situa o usurio (antes do sistema), no centro do processo. Esta filosofia, denominada projeto centrado no usurio, incorpora desejos e necessidades do usurio desde o incio do processo do projeto e especifica que estas necessidades devem ficar frente de qualquer deciso de projeto. Alguns autores associam a usabilidade a princpios tais como: facilidade de aprendizado; facilidade de lembrar como realizar uma tarefa aps algum tempo; rapidez no desenvolvimento de tarefas; baixa taxa de erros; satisfao subjetiva do usurio. A usabilidade tambm pode ser entendida como o esforo necessrio para utilizar o software e para o julgamento individual deste uso por determinado conjunto de usurios. Ou ainda como a preocupao com a interao do usurio em um sistema por meio da interface. De acordo com a norma NBR ISO/IEC 9126 [3], a usabilidade de um software a medida do esforo necessrio na utilizao de um software assim como a avaliao de seu uso pelos usurios. A usabilidade de um software dividese em 3 subcaractersticas: Inteligibilidade; Apreensibilidade; Operacionalidade.

10

Segundo a norma, inteligibilidade a medida da facilidade do usurio em reconhecer a lgica de funcionamento do produto e sua aplicao. A perguntachave de avaliao descrita pela NBR ISO/IEC 9126 [3] para este requisito : fcil entender o conceito e a aplicao?. Um sistema integrado de gesto precisa ser projetado de forma que haja lgica na seqncia dos passos necessrios para a execuo de uma operao a fim de que o usurio consiga entender seu funcionamento e possa associ-la nas suas tarefas do dia-a-dia. Para avaliar a inteligibilidade, o estudo de caso realizado neste trabalho, utilizou a seguinte pergunta-chave: fcil encontrar as operaes desejadas no sistema?. Outra subcaracterstica a apreensibilidade, que consiste na medida da facilidade de utilizao do software pelo usurio. A pergunta-chave de avaliao descrita pela norma para este requisito : fcil aprender a usar o sistema. Um bom entendimento dos usurios em relao utilizao de um sistema depende, e muito, da qualidade do treinamento ministrado. Para isso, necessrio que os materiais de treinamento reflitam as operaes/passos para a realizao de determinada tarefa no sistema. Durante o treinamento em um ERP, os instrutores precisam apresentar o fluxo de redesenho dos processos de negcio da empresa para que estes sejam compreendidos pelos usurios e possam ser aplicados no sistema. A pergunta utilizada para medir a apreensibilidade dos ERPs avaliados foi: Foi fcil aprender a utilizar o sistema atravs do treinamento ministrado?. Outra subcaracterstica da usabilidade a operacionalidade que, de acordo com a NBR ISO/IEC 9126 [3], definida como a medida da facilidade de operao do sistema. A perguntachave de avaliao descrita pela norma para este requisito : fcil de operar e controlar o sistema?. O principal ponto a ser avaliado nessa subcaracterstica a interface do sistema. Ela a porta de entrada do sistema para o usurio. Portanto, indispensvel que tenha uma boa apresentao, pois, caso contrrio, pode causar uma averso do usurio na utilizao do software.

11

desejvel que o software utilize uma interface com elementos grficos ou figuras representando operaes do sistema visando tornar a interao com o usurio o mais intuitivo possvel. Para avaliar a operacionalidade, o estudo de caso realizado neste trabalho, utilizou a seguinte pergunta-chave: fcil de operar e controlar as operaes desejadas no sistema?. 4.4. Manutenibilidade Manuteno de software definida como o processo de modificao de um produto de software, componente ou sistema aps a sua instalao, de forma a corrigi-lo, melhor-lo ou adapt-lo para uma mudana no ambiente operacional. Manutenibilidade de software o atributo que caracteriza a facilidade de modificao ou adaptao de um software. muitas vezes quantificada em termos do tempo mdio requerido para efetivar a reviso do software para eliminar um erro. Esse atributo muito significativo para um software, na medida que a etapa de manuteno pode consumir at 65% do custo total de um produto. A NBR ISO/IEC 9126 [3] define a manutenibilidade como a medida do esforo necessrio para fazer modificaes ou correes no software. A manutenibilidade pode ser subdividida em 4 subcaractersticas: Analisabilidade; Modificabilidade; Estabilidade; Testabilidade. A analisabilidade o grau de facilidade em detectar e encontrar falhas no sistema quando elas ocorrem. Todo software apresenta falhas aps sua implantao. Estas falhas podem ser subdivididas em falhas internas e falhas externas de sistema. As falhas externas so originadas por atividades adversas realizadas por recursos externos ao sistema (usurios, sistema operacional, hardware, etc.) e que causam impactos negativos no

12

software. As falhas internas so aquelas originadas em operaes realizadas pelo software como erros de identificao de variveis, acessos errados a bancos de dados, etc. Apesar das diversas ferramentas que existem atualmente para auxiliar os desenvolvedores em rastrear as falhas internas dos sistemas, at hoje a deteco destas falhas a atividade que mais consome tempo dos desenvolvedores aps a implementao. Esta subcaracterstica da norma tem, portanto, o objetivo de medir at onde o software possui ferramentas efetivas de deteco de erros. A pergunta-chave de avaliao descrita na NBR ISO/IEC 9126 [3] para este requisito : fcil encontrar uma falha quando ocorre?. A modificabilidade o grau de facilidade em se efetuar modificaes e adaptaes no sistema. Aps o processo de deteco das falhas internas do sistema, descrito no pargrafo anterior, estas falhas devem ser corrigidas. A correo das falhas internas de sistema pode ocorrer desde o processo de modelagem at o processo de codificao. Em ambos os casos, a correo geralmente feita atravs de alteraes no cdigo fonte do sistema. A perguntachave de avaliao descrita na NBR ISO/IEC 9126 [3] para este requisito : fcil modificar e adaptar o sistema?. Os pacotes integrados de gesto, por no serem sistemas fechados mas adaptveis s organizaes, so muito passveis de erros aps as alteraes efetuadas como configuraes e customizaes. Estas alteraes so geralmente realizadas com a utilizao de ferramentas ou pseudo-linguagens de programao geralmente presentes nos sistemas com o objetivo de viabilizar estas alteraes. Os ERPs, em sua grande maioria, tambm possuem ferramentas eficazes de identificao de erros que trabalham juntamente com as ferramentas de alterao para corrigi-los. Outro aspecto relacionado com estas duas subcaractersticas o suporte ao usurio. Os problemas apresentados pelos usurios durante a utilizao do Sistema podem ser falhas de origem interna ou externa. Cabe equipe responsvel pelo suporte tcnico identificar o problema, sua causa e acompanhar a resoluo do problema at o seu trmino. Alguns ERPs tambm possuem ferramentas internas de suporte ao usurio como ferramentas

13

de mirroring, em que a equipe tcnica capaz de compartilhar a sesso em execuo com o usurio. Este aspecto tambm ser avaliado no estudo de caso contido neste trabalho. Outra subcaracterstica pertencente manutenibilidade a estabilidade. A estabilidade a medida do grau de confiabilidade que o sistema proporciona aps uma modificao em sua estrutura. Muitas vezes uma alterao no sistema, at mesmo com o objetivo de resolver um problema, pode acabar gerando mais problemas que o problema original. Cabe ao sistema garantir o mnimo de integridade de suas estrutura aps alteraes. A pergunta-chave de avaliao descrita na NBR ISO/IEC 9126 [3] para este requisito : H grande risco quando se faz alteraes?. No caso dos sistemas integrados de gesto, as ferramentas de alterao disponveis no possuem tanta flexibilidade como uma linguagem de programao possui para um sistema convencional. Este fato acaba se tornando um aspecto positivo pois garante uma maior estabilidade do sistema em caso de modificaes. A ltima subcaracterstica de manutenibilidade a testabilidade. A testabilidade a medida da facilidade de testar as alteraes realizadas no sistema. Toda alterao precisa ser testada e validada para que possa ser incorporada ao ambiente de produo dos sistemas. A pergunta chave de avaliao descrita na NBR ISO/IEC 9126 [3] para este requisito : fcil testar o sistema quando se faz alteraes?. Ferramentas de suporte a testes ainda no so muito comuns nos ERPs. Isto se deve ao fato dos sistemas integrados de gesto possurem um ambiente exclusivo para testes de correo de erros e modificaes do sistema. Este ambiente chamado de Quality Assurance e um ambiente exatamente igual ao ambiente de produo que executado em paralelo com o objetivo nico de permitir a realizao de testes. Para avaliar as ferramentas de manutenibilidade, o estudo de caso realizado neste trabalho utilizou as seguintes perguntas-chave: Ao ocorrer uma falha, fcil encontr-la e corrigi-la no sistema? , O sistema de fcil atualizao?, A flexibilidade do sistema permitiu as customizaes necessrias

14

para atender s necessidades do negcio? e As ferramentas de customizao so eficientes e de fcil utilizao?. 4.5. Confiabilidade Confiabilidade e disponibilidade so caractersticas cada vez mais desejveis em sistemas de computao, pois a cada dia aumenta a dependncia da sociedade em sistemas automatizados e informatizados. Confiabilidade a medida mais usada na avaliao de sistemas e seu nvel de rigor deve ser alto, isto , so inaceitveis operaes incorretas do sistema, mesmo em curtos perodos de tempo. Confiabilidade no pode ser confundida com disponibilidade. Um sistema pode ser altamente disponvel mesmo apresentando perodos de inoperabilidade, desde que esses perodos sejam curtos e no comprometam a qualidade do servio. De acordo com a norma NBR ISO/IEC 9126 [3], a confiabilidade de um software refere-se capacidade do software de manter seu nvel de desempenho, sob condies estabelecidas, por um perodo de tempo. A maioria dos mtodos propostos para avaliao desta caracterstica tem como princpio o nmero de defeitos ocorridos no programa ou o nmero de falhas ocorridas. A perguntachave de avaliao descrita na NBR ISO/IEC 9126 [3] para este requisito : O sistema imune a falhas?. Tem 3 subcaractersticas: Maturidade; Tolerncia a Falhas; Recuperabilidade. Conforme a norma NBR ISO/IEC 9126 [3], a maturidade de um software refere-se freqncia com que as falhas de sistema acontecem. Todos os softwares apresentam falhas eventuais, porm a freqncia com que elas acontecem determinam a maturidade do software em questo. A perguntachave

15

de avaliao descrita na NBR ISO/IEC 9126 [3] para este requisito : Com que freqncia o sistema apresenta falhas?. Por falha entende-se a ocorrncia (ou possibilidade de ocorrncia) de qualquer evento que provoque um desvio relativo aos parmetros de funcionamento desejados. Estes parmetros de funcionamento dependem do tipo de sistema informtico e servios que ele presta, e incluem geralmente a confidencialidade dos dados, a integridade dos sistemas e sua disponibilidade permanente. As falhas tm diversas origens; de acordo com o tipo de falha temos a considerar um conjunto de procedimentos para minimizar a probabilidade destas ocorrerem. As falhas de hardware podem ser reduzidas com um aumento da qualidade dos componentes. Devemos, contudo, atender tambm aos aumentos nos custos. Mais comuns so as falhas de software: mesmo a mais testada das aplicaes pode possuir bugs que s se revelam em situaes muito particulares. Para que se possa desenvolver um produto com maturidade, contamos com a tecnologia dos testes. Os testes esto deixando efetivamente de ser meros exterminadores de bugs para se tornar algo que faz parte do processo de maturidade do software. No caso dos sistemas integrados de gesto existe um ambiente chamado Quality Assurance que um ambiente igual ao ambiente de produo que executado em paralelo com o objetivo de permitir a realizao de testes. No estudo de caso realizado neste trabalho, as perguntas-chave utilizadas para medir a maturidade dos ERPs avaliados foram: O sistema no apresenta falhas com freqncia? e O sistema est disponvel a maior parte do tempo?. A tolerncia a falhas, segundo a norma NBR ISO/IEC 9126 [3], refere-se manuteno do nvel de desempenho em caso de falhas. Os sistemas no devem interromper seu funcionamento mesmo na presena de falhas de alguns componentes (hardware, software e dados). Entenda-se como a eliminao completa dos inconvenientes da ocorrncia de uma falha a idia de que os utilizadores no devem notar qualquer alterao de funcionamento. A pergunta chave de avaliao descrita na NBR ISO/IEC 9126 [3] para este requisito : Ocorrendo falhas, como o sistema reage?.

16

Falhas so inevitveis, mas as conseqncias das falhas, ou seja, o colapso do sistema, a interrupo no fornecimento do servio e a perda dos dados podem ser evitados pelo uso adequado de tcnicas viveis e de fcil compreenso. O conhecimento dessas tcnicas habilita o usurio a implementaras mais simples, ou exigir dos fornecedores solues que as incorporem. Entretanto, as solues que toleram falhas tm um certo custo associado. Sistemas mais robustos em relao a falhas so preocupaes para projetistas de sistemas crticos, como ERPs. Falhas nesses servios podem ser catastrficas para a imagem e a reputao das empresas. Sendo assim, os sistemas de tolerncia a falhas so absolutamente imprescindveis em quaisquer sistemas, principalmente nos sistemas integrados de gesto, porm no devem servir de base para um menor cuidado na reduo das probabilidades de ocorrncia de falhas. De acordo com a norma NBR ISO/IEC 9126 [3], recuperabilidade refere-se a capacidade de se restabelecer e restaurar dados aps falha, ou seja, atributos de software que evidenciam a sua capacidade de restabelecer seu nvel de desempenho e recuperar os dados diretamente afetados, em caso de falha, e o tempo de esforo para tal. A pergunta-chave de avaliao descrita na NBR ISO/IEC 9126 [3] para este requisito : O sistema capaz de recuperar dados em caso de falha? Como citado anteriormente, existem dois tipos de falhas: falhas de hardware e falhas de software. Tratando-se de falhas de hardware, o aspecto mais grave das falhas a perda de dados por danos irreparveis em unidades de armazenamento, a soluo a realizao de cpias de segurana com frequncia. Esta uma das solues que assegura a recuperabilidade no caso de falhas de hardware. No caso de falhas de software necessria uma ferramenta de recuperao de dados. As ferramentas de recuperabilidade ainda no so muito comuns entre os ERPs. Seus servidores de banco de dados e aplicao possuem estratgias e ferramentas de backup muito eficientes e, caso ocorram falhas que resultem em perdas de dados, estas so normalmente recuperadas atravs da restaurao do backup do servidor correspondente.

17

No estudo de caso realizado neste trabalho, as perguntas-chave utilizadas para avaliar a recuperabilidade dos ERPs avaliados foram: Em caso de falha no sistema, as ferramentas de recuperao de dados proporcionam uma recuperao eficiente dos dados (velocidade, facilidade, consistncia, etc)?. 4.6. Portabilidade Segundo a norma NBR ISO/IEC 9126 [3] a portabilidade de um software refere-se capacidade do software em ser transferido de um ambiente para outro, ou seja, o esforo e as medidas necessrios para transferir um programa de uma configurao de hardware e/ou ambiente de software para outra. A perguntachave de avaliao descrita na NBR ISO/IEC 9126 [3] para este requisito : fcil de usar em outro ambiente?. Para empresas que desenvolvem software para vrios clientes, a portabilidade e independncia de plataforma so normalmente fatores de qualidade essenciais. A independncia de plataforma ainda mais crtica pois a grande base de hardware e software instalada no pode ser trocada sem maiores custos e traumas. Assim empresas que tm clientes com plataformas diferentes tm que desenvolver software independente de plataforma sob pena de multiplicar custos desnecessariamente. Alm disso, a portabilidade complementar para eliminar os custos com pequenas adaptaes e recompilao quando migra-se o software de um ambiente para outro. Em uma abordagem de mais baixo nvel, a portabilidade tambm est ligada escolha das estruturas de dados utilizadas pelo software. Elas devem ser implementadas de acordo com as decises de projeto. Em projetos de sistemas, as operaes tm um vnculo bastante forte com as estruturas de dados e a no observao dessa realidade pode causar problemas no s de portabilidade, mas tambm de manutenibilidade. Segundo a norma NBR ISO/IEC 9126 [3], a portabilidade tem as seguintes subcaractersticas: Adaptabilidade; Capacidade para ser instalado;

18

 Capacidade para substituir; Conformidade. Segundo a norma NBR ISO/IEC 9126 [3], a adaptabilidade de um software refere-se capacidade de ser adaptado em ambientes diferentes. A perguntachave de avaliao descrita na norma para este requisito : fcil adaptar o sistema a outros ambientes?. A adaptabilidade a outros ambientes pode referir-se a diversos aspectos: infra-estrutura (hardware,software), culturas empresariais, regras e leis de localidade e moedas. Quanto infra-estrutura, o sistema deve ser adaptvel ao sistema operacional utilizado, ao sistema gerenciador de banco de dados escolhido e deve manter a performance utilizando os equipamentos disponveis. Quanto cultura empresarial, o sistema deve ser adaptvel aos processos da empresa, ou seja, deve apoiar os processos de negcio da organizao, minimizando os esforos. Quanto s regras e leis, o sistema deve utilizar como unidade monetria, a moeda corrente, respeitar a legislao vigente, a tributao e as normas locais. A adaptabilidade aos requisitos de gesto faz coincidir a utilizao das solues com as necessidades da organizao. A pergunta-chave utilizada para medir a adaptabilidade dos ERPs avaliados foi: O sistema fcil de adaptar a outros ambientes?. Segundo a norma NBR ISO/IEC 9126 [3] a capacidade para ser instalado refere-se facilidade de instalao do software. A pergunta-chave de avaliao descrita na norma para este requisito : fcil instalar o sistema em outros ambientes?. De acordo com a norma, a capacidade para substituir refere-se substituio para outro software. A pergunta-chave de avaliao descrita na norma para este requisito : fcil usar o sistema para substituir outro?. Os sistemas integrados de gesto disponveis no mercado atualmente so sistemas muito portveis. Devido portabilidade conferida aos sistemas pelo advento dos compiladores multi-plataforma, como a linguagem Java, e a grande variedade de sistemas gerenciadores de bancos de dados, estas caractersticas no so

19

caractersticas de diferenciao dos ERPs. Outrossim, a substituio de um sistema integrado de gesto por outro uma questo delicada e que deve ser levada em considerao. Os ERPs como qualquer outro sistema, tambm possuem um tempo de vida til e, um dia, precisaro ser substitudos ou atualizados. Assim os seguintes requisitos: manuteno, confiabilidade e pertinncia na migrao das informaes contidas nos bancos de dados, baixo impacto e transparncia para o usurio durante o processo de substituio podem ser considerados fatores de diferenciao entre estes tipos de sistemas. A pergunta utilizada para medir a adaptabilidade dos ERPs avaliados foi: fcil utilizar o sistema para substituir outro ERP?. 5. Estudo de Caso - Metodologia Toda organizao, ao decidir implantar um ERP, possui expectativas com relao ao sistema no sentido de aumentar sua vantagem competitiva no mercado. A avaliao da qualidade de um ERP envolve muito mais do que a verificao da adequao do mesmo a padres especificados: significa acessar de forma acurada as diferentes percepes dos clientes e gerenciar as evidncias. Dentre os mtodos de avaliao de qualidade existentes, o mtodo escolhido para a anlise do modelo proposto foi o SERVQUAL. O mtodo SERVQUAL foi escolhido justamente por possibilitar uma anlise de qualidade baseada na diferena entre a expectativa do cliente e o resultado obtido. As expectativas do cliente consistem em sentimentos dinmicos e complexos. Exceder as expectativas de um cliente pode ser uma ao delicada, pois ele espera o melhor resultado de um investimento de grande envolvimento da organizao. Pesquisas tm demonstrado existncia de uma zona de tolerncia entre expectativas e percepes. Estudo realizado em 1991 por Parasuraman, Zeithaml e Berry [2] com consumidores finais e corporativos concluiu que os clientes, de forma geral, esperam que as empresas e seus produtos realizem aquilo que eles so supostos a fazer. A pesquisa tambm identificou que o preo e os esforos dedicados a um projeto so fatores que influenciam na expectativa do

20

cliente. Quanto maior o custo, melhor o produto ou servio esperados. Foi criado, ento, em 1998 o mtodo SERVQUAL pelos mesmos autores. O SERVQUAL, sigla criada a partir das primeiras palavras do termo Service Quality, foi inicialmente criado para medir a qualidade de servios. A primeira pesquisa que deu origem ao mtodo foi realizada em 1995 com executivos das reas de marketing, operaes, gerncia snior e relacionamento com o cliente de quatro grandes empresas norte americanas de setores diferentes (somando um total de quatorze executivos) e com 12 grupos foco de clientes destas empresas (sendo trs para cada uma). Como resultado, os autores identificaram quatro fatores que influenciam a percepo de qualidade do servio pelo clientes diretamente relacionados empresa e um diretamente associado ao cliente. Com a identificao dos fatores, foi estruturado o Modelo dos GAPs. O GAP 1 a diferena entre o servio esperado pelo cliente e a percepo do gerente responsvel pela prestao do servio sobre a expectativa do cliente. O GAP 2 a diferena entre a percepo do gerente responsvel pela prestao do servio sobre a expectativa do cliente e a especificao do servio. O GAP 3 a diferena entre a especificao do servio e a prestao do servio. O GAP 4 a diferena entre a comunicao e a prestao do servio. A diferena entre o servio percebido e o esperado o GAP 5, que uma juno dos GAPs 1, 2, 3 e 4. Este GAP tambm chamado de hiato e, quanto maior o seu valor, maior a insatisfao do cliente uma vez que o resultado percebido muito diferente do esperado. Em contrapartida, quanto menor o GAP, maior a satisfao do cliente pois o resultado percebido est prximo do resultado esperado. Neste estudo, os GAPs sero medidos atravs da aplicao de um questionrio cujas perguntas foram extradas do estudo realizado no captulo anterior. As medidas dos GAPs sero ento normalizadas de forma a proporcionar uma melhor anlise dos resultados medidos.

21

5.1. Atributos A avaliao dos ERPs foi realizada em todos os nveis: Implementao, Produto e Treinamento. fase de implementao no foi dada muita nfase, pois o desenvolvimento dos softwares integrados de gesto so realizados de acordo com o modelo CMM (Capability Maturity Model). Esse modelo foi desenvolvido pelo Instituto de Engenharia de Software (SEI) e consiste na premissa de que um processo de software funcionar de forma satisfatria se possuir ferramentas e equipamentos que suportem a realizao de tarefas, visando a simplificao e a automatizao do trabalho, alm de pessoas treinadas nos mtodos e ferramentas para que possam realizar as atividades do dia-a-dia de forma correta. O CMM prope a avaliao da capacidade e maturidade de uma organizao e indica aes para melhoria. Para avaliar a qualidade dos ERPs como produtos e do treinamento realizado para sua utilizao, foram aplicados testes, cujas perguntas esto de acordo com as normas NBR ISO/IEC 9126 [3]. A fase de treinamento no foi muito explorada; esta fase geralmente realizada pelas empresas de consultoria responsveis pela implantao do sistema nas empresas. Os testes foram direcionados a trs pblicos distintos: Usurios, Equipe Tcnica e Gerentes. O primeiro conjunto de atributos refere-se percepo do ERP por parte dos empregados encarregados pela operao dos processos de negcio da empresa. Os atributos utilizados nesse conjunto foram: Adequao do ERP aos processos de negcio da empresa; Tempo de resposta do sistema; Interao com outros sistemas; Grau de maturidade do sistema; Facilidade em encontrar as funes necessrias para a realizao de determinada tarefa no sistema; Facilidade em aprender a utilizar o sistema; Facilidade na operao do sistema.

22

J o segundo conjunto de atributos refere-se percepo dos gerentes da empresa usuria do ERP, dedicados em tomar decises capazes de fazer sua empresa se destacar das demais. Os atributos abordados nesse conjunto foram: Atendimento aos processos de negcio da empresa; Grau de confiabilidade nas informaes geradas pelo ERP para a tomada Facilidade em encontrar as funes necessrias para a realizao de Facilidade em aprender a utilizar o sistema; Facilidade na operao do sistema; Garantia de acesso a dados sigilosos e operaes crticas do sistema Sucesso na implantao do ERP. O terceiro conjunto de atributos refere-se percepo das qualidades dos

de decises; determinada tarefa no sistema;

somente por pessoas autorizadas;

ERPs pela equipe tcnica, responsvel pela garantia do bom funcionamento do sistema. Os atributos avaliados pela equipe tcnica foram: Freqncia de falhas do sistema; Disponibilidade do sistema; Nvel de desempenho do sistema de acordo com a demanda dos usurios; Segurana na transmisso de dados via web; Garantia de acesso a dados sigilosos e operaes crticas do sistema somente por pessoas autorizadas; Facilidade de atualizao do sistema; Grau de interao com outros sistemas; Nvel de adaptao do sistema em outros ambientes; Facilidade em substituir o sistema anterior pelo ERP; Facilidade de encontrar e corrigir falhas; Recuperao de dados em caso de falhas.

23

No questionrio destinado gerncia, foi formulada uma pergunta para avaliar se a implantao do projeto foi um sucesso ou no. Esta a perguntachave para a anlise da avaliao dos ERPs, e mostra o grau de satisfao aps 2 anos do incio da utilizao do ERP. O questionrio aplicado aos usurios dos ERPs (operacionais, equipe tcnica e gerncia) utiliza graus de 1 a 5 de acordo com os seguintes critrios em relao ao grau de importncia e/ou do desempenho da subcaracterstica no ERP: 1 Discordncia 2 Discordncia parcial 3 Concordncia 4 Concordncia alta 5 Concordncia plena 5.2. A Amostra O amostra deste estudo de caso composto de trs organizaes que utilizam 3 ERPs diferentes. So eles : R/3: Sistema Integrado de Gesto da SAP, empresa que est no mercado de e-business desde 1972, terceira empresa de software do mundo e primeira em software de gesto empresarial segundo o histrico da Companhia. Segundo informaes da SAP, possui 17.000 clientes espalhados em 120 pases e o ERP mais utilizado em todo o mundo, principalmente por empresas de grande porte. Oracle e-Business Suite: ERP da Oracle , empresa fundada em 1977 e com mais de 40.000 funcionrios. Segundo informaes da Oracle, utilizado em 24 empresas, totalizando 5.000 usurios no mundo e 250 no Brasil, e est no mercado h 4 anos. Este ERP o principal concorrente do R/3 da SAP e o ERP preferido das organizaes de mdio porte. AP7: ERP da Microsiga Software S/A, empresa nacional criada em 1983 e eleita em 2003 a melhor empresa de software de 2002. Segundo informaes da Microsiga, utilizado por cerca de 6.000 clientes e o sistema de gesto nacional

24

de maior expresso no mercado de ERPs. muito utilizado em organizaes de pequeno e mdio porte. O universo de pesquisa foi constitudo de 3 empresas (A,B,C) de grande porte, cuja avaliao foi realizada em escritrios localizados no Rio de Janeiro. A tcnica utilizada foi a de levantamento de dados e, os questionrios foram passados pessoalmente para que pudessem ser esclarecidos os objetivos da pesquisa e o preenchimento do questionrio. A empresa A uma empresa de economia mista do ramo de comrcio e distribuio de petrleo e derivados. Foi criada em 1971 , e a maior distribuidora de petrleo e derivados do pas desde 1974. Possui cerca de 8 mil funcionrios e mais de 10.000 grandes clientes entre indstrias, termoeltricas, companhias de aviao e frota de veculos leves e pesados. A empresa A utiliza o SAP R/3 como seu sistema integrado de gesto h aproximadamente 2 anos. A pesquisa foi aplicada na sua sede localizada no Rio de Janeiro. A empresa B. uma empresa que oferece servios nas reas de engenharia, tecnologia e construo de materiais e estruturas para as indstrias de petrleo e gs, como plataformas flutuantes e fixas, dutos de gs/leo etc. Esta multinacional francesa foi fundada em 1958 e tem 19.000 funcionrios em todo o mundo, sendo 1.500 no Brasil. A empresa B usa o Oracle e-Business Suite como seu ERP h cerca de 3 anos, quando foi implantado. A pesquisa foi aplicada no Rio de Janeiro, onde localiza-se sua filial brasileira. A empresa C uma das cinco maiores empresas big five da rea de consultoria no mundo. Esta multinacional possui cerca de 103.000 funcionrios no mundo e aproximadamente 1.100 funcionrios no Brasil. O nosso estudo foi realizado atravs da filial desta empresa no Rio de Janeiro. Este empresa uma empresa conceituada no mercado principalmente por prestar consultoria e integrar as equipes de projetos de implantao de sistemas integrados de gesto em vrias grandes empresas no Brasil. A empresa C est no mercado de consultoria h 45 anos e utiliza o AP 7 da Microsiga como seu sistema integrado de gesto em suas filiais situadas no Brasil

25

h 2 anos. Por participarem em projetos de implantao de diversos sistemas de gesto, seus funcionrios, gerentes e equipe tcnica contriburam com uma anlise extremamente rigorosa e completa do AP 7, o que proporcionou a este estudo uma anlise acurada deste ERP com relao ao mercado mundial de ERPs. Conforme citado anteriormente, o ERP um sistema cuja utilizao amadurece com o passar do tempo. Propositalmente, as 3 empresas citadas implantaram seus ERPs na mesma poca para que os resultados obtidos fossem consistentes. Foram passados em cada empresa, 3 tipos de questionrios diferentes (usurios, equipe tcnica e gerncia), totalizando 18 questionrios por empresa sendo 10 direcionados a usurios, 5 destinados equipe tcnica e 3 a gerentes. Ao todo, foram 54 questionrios respondidos. Assim, por este pequeno nmero de respostas esta pesquisa poder ser considerada como estudo de caso. 5.3. Resultados R/3 da Sap Plotando-se os Gaps normalizados das respostas apresentadas nos questionrios obtem-se o seguinte grfico com valores mdios:

26

Atravs da anlise do grfico, acima, pode-se concluir que o ERP foi melhor avaliado na percepo gerencial e pior avaliado na percepo operacional. A anlise sugere que a interface do R/3 poderia ser melhor desenvolvida, assim como o treinamento ministrado e a facilidade para modificao do software para melhor adaptao aos objetivos da empresa no qual o ERP ser instalado. Oracle Business Suite Plotando-se os Gaps normalizados das respostas apresentadas nos questionrios obtem-se o seguinte grfico com valores mdios:

Atravs da anlise do grfico acima, pode-se concluir que o ERP foi melhor avaliado na percepo operacional e pior avaliado na percepo tcnica. O resultado, sugere que o Oracle Business Sute possa ser melhorado em relao deteco e correo de falhas, problema este, que pode afetar no desempenho da empresa como um todo. AP7 da Microsiga Plotando-se os Gaps normalizados das respostas apresentadas nos questionrios obtem-se o seguinte grfico com valores mdios.

27

Atravs da anlise do grfico acima, pode-se concluir que o ERP foi melhor avaliado na percepo operacional e pior avaliado na percepo gerencial. 6. Concluses

A anlise do grfico demonstrativo da mdia dos GAPs para as 3 percepes analisadas (operacional, gerencial e tcnica), acima, sugere que: a) - A empresa A que utiliza o ERP R/3 da SAP avaliou que este software muito bom do ponto de vista tcnico, ou seja, possui ferramentas eficientes de

28

manuteno, atualizao, deteco e correo de falhas, alm de outros requisitos avaliados pela equipe tcnica. Do ponto de vista gerencial, foi bem avaliada, porm necessita de alguns ajustes para que o percentual de satisfao possa aumentar. Do ponto de vista operacional, os usurios tambm o avaliaram bem, sendo que foi o que obteve maior GAP, possivelmente, os usurios no tiveram treinamento adequado, ou tiveram dificuldades em operar o sistema, enfim, inmeros fatores que refletiram no maior GAP encontrado para este software na empresa A. b) A empresa B que utiliza o ERP Oracle Business Sute da Oracle avaliou o software de forma linear, visto que os GAPs encontrados nas 3 percepes esto praticamente na mesma ordem de grandeza. Destaque para a percepo tcnica que o avaliou melhor que as demais, e tambm para a percepo operacional que obteve o maior GAP, sendo pior avaliado sob esta percepo, possivelmente ocorreram os mesmos problemas citados para o R/3 na empresa A. c) - A empresa C que utiliza o AP7 da Microsiga tambm avaliou muito bem o software sob o ponto de vista tcnico e operacional, porm sob o ponto de vista gerencial precisa de alguns ajustes para que o percentual de satisfao aumente, possivelmente esse GAP foi influenciado por tempo e custo de implantao. Mas ainda assim, sua avaliao quando comparada aos outros 2 softwares se destaca por seus GAPs ficarem bem abaixo dos demais. Ressaltamos que este software foi o melhor avaliado, curiosamente por ser um software nacional e mais utilizado por empresas de pequeno porte. Dentro das limitaes do Estudo de Caso realizado, os dados levantados sugerem que o AP7 da Microsiga foi o sistema melhor avaliado. Uma das hipteses que isto pode ser decorrente do fato do sistema ser um sistema nacional e, por isso, no ter gerado grande expectativas quanto sua qualidade. Uma outra hiptese a possibilidade do sistema ter sido projetado e desenvolvido no contexto do projetos de software nacionais, respeitando a cultura e atendendo com eficincia exigncias da legislao brasileira.

29

O estudo de caso realizado neste trabalho serviu no somente para testar o mtodo assim como valid-lo. A principal evidncia de validade do mtodo foi a comparao realizada entre o GAP da pergunta-chave sobre o sucesso de implantao dos sistemas integrados de gesto das empresas estudadas e a mdia geral dos GAPs normalizados das respectivas empresas. O GAP da pergunta-chave sobre o sucesso de implantao dos sistemas integrados de gesto das 3 empresas estudadas ficou abaixo dos 50%, o que nos leva a concluir que as gerncias das 3 organizaes consideram o projeto de implantao um sucesso. Da mesma forma, a mdia geral dos GAPs normalizados da avaliao dos requisitos das 3 empresas tambm ficou abaixo dos 50%, o que leva a concluir que os requisitos de qualidade dos sistemas estudados foram considerados bons. Pela comparao destas duas medies conclui se que o mtodo utilizado consistente e, em termos genricos, permite tambm concluir que : Os Sistemas Integrados de Gesto cujos projetos de implantao possuem bons requisitos de qualidade proporcionam a satisfao da gerncia da organizao quanto ao resultado final da implantao. Este mtodo tambm muito abrangente e flexvel pois permite uma anlise detalhada de todos os requisitos de maior relevncia para um ERP assim como manipular separadamente resultados de um ou mais requisitos combinados. Esta caracterstica proporciona ao mtodo flexibilidade para ser utilizado em qualquer fase do projeto ou at mesmo antes ou aps o incio do mesmo auxiliando as organizaes em importantes processos de tomada de deciso como implantao, atualizao ou substituio do ERP.

30

7. REFERNCIAS BIBLIOGRFICAS BERRY,L,L PARASURAMAN. A Servios de marketing: Competindo atravs da Qualidade. 1ed. So Paulo: Maltese. 1995. MENDES, Juliana Veiga; FILHO, Edmundo Escrivo. Sistemas Integrados de Gesto ERP em Pequenas Empresas: Um Confronto entre o Referencial Terico e a Prtica Empresarial. So Paulo: Gesto & Produo, v.9, n.3, dez. 2002. p.277-296. NBR ISO/IEC 9126-1:2003 - Tecnologia de informao Engenharia de software Qualidade de produto Parte 1:Modelo de qualidade. Esta norma cancela e substitui a NBR 13596 (julho 2003).

31